|
Post by tlr on Jan 2, 2006 18:12:49 GMT -5
A quick utility to test alternate kernals in ram. It will load and install a custom kernal at $01e000-$01ffff. Additionally you can save the currently active kernal rom to a file. The only way to disable the kernal is currently pressing the reset button. kernalpatcher-20060102.prg
|
|
|
Post by David Murray on Jan 2, 2006 22:55:47 GMT -5
What would happen if you tried to use the original kernal from a 1980's era C64? I know the load from flash-ram feature wouldn't work. What about everything else?
|
|
|
Post by tlr on Jan 3, 2006 3:40:20 GMT -5
What would happen if you tried to use the original kernal from a 1980's era C64? I know the load from flash-ram feature wouldn't work. What about everything else? The first thing I tried. It works. The new DTV V2 registers won't be setup on reset and 'restore'. This will be problematic if the kernal is flashed but not for ram-test, as the registers are already setup when running the test utility. Also tape load does not work. It assumes that play is always pressed, so if you do "load" it blanks the screen an tries to search for a file. (press "esc" to exit)
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 3, 2006 8:30:13 GMT -5
Remember that the original KERNAL doesn't set the 16 C64 colors, so it might be possible that you won't see a thing after that.
|
|
|
Post by tlr on Jan 3, 2006 8:54:14 GMT -5
Yes, like Graham says, never flash an older kernal that doesn't set up the DTV registers.
|
|
|
Post by David Murray on Jan 3, 2006 9:14:54 GMT -5
Will this program dump a kernel from a real C64? Does it have to have the upper memory for that?
|
|
|
Post by tlr on Jan 3, 2006 9:40:24 GMT -5
Will this program dump a kernel from a real C64? Does it have to have the upper memory for that? I haven't tested it, but I think it will work fine. New version of the kernal patcher: kernalpatcher-20060103.prgWhen running test kernal it will let you select to install a hook at $18000. When installed, holding the left button and pressing reset will restart the kernal under test in ram. This will only work on units with the DTV V2 kernal (or compatible) installed in flash, as that has the "DTV80" check. @graham: After doing some tests, it seems that the DTV powers up in NTSC mode (as specified in the DTV Programming document), and that there are readable colors in the palette by default.
|
|
|
Post by suschman on Jan 4, 2006 15:03:57 GMT -5
After doing some tests, it seems that the DTV powers up in NTSC mode (as specified in the DTV Programming document), and that there are readable colors in the palette by default. Yep, starts up in NTSC after a reset, even after kernal patch so mybe you can add a short video init routine before the hook to get pal after button+reset. Hi Kernal Patcher works, but i have problems with jiffy dos. I get slightly to unusable scrambled directory with it and a jiffy-1541, more scrambled by @$ then bei usual directory lading. also loading programs is nearly impossible then, so there is something wrong working with the speedloader. i duno what´s going on there . Suschman
|
|
|
Post by tlr on Jan 4, 2006 16:43:25 GMT -5
After doing some tests, it seems that the DTV powers up in NTSC mode (as specified in the DTV Programming document), and that there are readable colors in the palette by default. Yep, starts up in NTSC after a reset, even after kernal patch so mybe you can add a short video init routine before the hook to get pal after button+reset. This was intentional, so you will see what the kernal would do if you were to put it in flash. Maybe I could put an option for it though. Kernal Patcher works, but i have problems with jiffy dos. I get slightly to unusable scrambled directory with it and a jiffy-1541, more scrambled by @$ then bei usual directory lading. also loading programs is nearly impossible then, so there is something wrong working with the speedloader. i duno what´s going on there . I'll have to look in the rom to see what could be wrong. Is it the same rom-image for PAL/NTSC?
|
|
|
Post by x1541 on Jan 7, 2006 3:35:56 GMT -5
Kernal Patcher works, but i have problems with jiffy dos. I get slightly to unusable scrambled directory with it and a jiffy-1541, more scrambled by @$ then bei usual directory lading. also loading programs is nearly impossible then, so there is something wrong working with the speedloader. i duno what´s going on there . Suschman This remembers me of my PAL C128DCR, which also has similar problems with Jiffydos! Other users also confirmed this. It seems Jiffy has timing problems on some PAL machines. I guess the problems go away if you run the DTV in NTSC mode ... On my 128 the problem is solved when I hook up more serial devices, because they slow down the signals on the bus. But I doubt the DTV has strong enough IEC drivers to operate more than maybe two devices?
|
|
|
Post by tlr on Jan 7, 2006 6:33:44 GMT -5
Kernal Patcher works, but i have problems with jiffy dos. I get slightly to unusable scrambled directory with it and a jiffy-1541, more scrambled by @$ then bei usual directory lading. also loading programs is nearly impossible then, so there is something wrong working with the speedloader. i duno what´s going on there . Suschman This remembers me of my PAL C128DCR, which also has similar problems with Jiffydos! Other users also confirmed this. It seems Jiffy has timing problems on some PAL machines. I guess the problems go away if you run the DTV in NTSC mode ... It won't be solved by that. The only thing that is changed are where the emulated badlines reside. The crystal is still the same frequency, so the duration of a CPU cycle will still be exactly the same. On my DTV it is 31.5279MHz / 32 = 985246.875 Hz, compared to 985250 Hz for the original PAL c64 or 1022727 Hz for the NTSC c64. The frequency of the DTV is very close to an original c64 so it's not the difference here that does it. When you say that it works when connecting two drives, I assume that this is because the timing is really bad for PAL systems, and adding an extra drive will speed up positive edges on the IEC-bus (by adding an extra pull-up).
|
|
|
Post by x1541 on Jan 7, 2006 8:15:13 GMT -5
You're right about the crystal change needed. Didn't think of that. The 128DCR has only one set of pull up resistors and the serial lines are all very short and on the PCB. No wires! Also, one external drive is not enough to make the internal one work. But, an external Jiffydos drive will always work! So I had quite a hard time when I tried to find out why the internal drive kept failing regularly I tried several fixes, but simply adding an extra set of pull-ups was not enough. So I created a dongle with some capacitors tied to the RESET line (which is at +5V), to slow down the negative edges. This was the best I could come up with. (with open collector logic as used on the IEC bus the positive edges are slow, as they are only "driven" by the pull ups. The negatives are fast because they are driven actively).
|
|
|
Post by tlr on Jan 7, 2006 8:32:22 GMT -5
You're right about the crystal change needed. Didn't think of that. The 128DCR has only one set of pull up resistors and the serial lines are all very short and on the PCB. No wires! Also, one external drive is not enough to make the internal one work. But, an external Jiffydos drive will always work! So I had quite a hard time when I tried to find out why the internal drive kept failing regularly I tried several fixes, but simply adding an extra set of pull-ups was not enough. So I created a dongle with some capacitors tied to the RESET line (which is at +5V), to slow down the negative edges. This was the best I could come up with. (with open collector logic as used on the IEC bus the positive edges are slow, as they are only "driven" by the pull ups. The negatives are fast because they are driven actively). Actually tie-ing a capacitor from +5V to the signal will mostly slow down the positive edges. When the open-collector outputs go active they will charge the capacitor quite quickly, but when the go inactive the resistor has to discharge through the pull-up which will be slower the higher the capacitance.
|
|
|
Post by suschman on Jan 7, 2006 8:47:36 GMT -5
This remembers me of my PAL C128DCR, which also has similar problems with Jiffydos! Other users also confirmed this. It seems Jiffy has timing problems on some PAL machines. I guess the problems go away if you run the DTV in NTSC mode ... Nop, this problem remains even if jiffy starts on uninitialised dtv hardware (after pressing reset) which seems to be something ntsc like, i still have not looked how the internal prozessor and cia timings are effected. DTV1 Had this problem, not more then one drive worked. We hoked over six devices to the DTV2 and all worked, so the drivers are ok . Greets
|
|
|
Post by tlr on Jan 7, 2006 8:57:43 GMT -5
suschman: If you have the possibility try to put caps from CLK, DATA and ATN to ground and see if it fixes the problem. This would be mostly equivalent to the fix Nicolas speaks about. Value I don't know... 1nF? @nicolas: What caps did you use? On all of the pins? Still, if this information is correct, the JiffyDOS is not very well timed for PAL-systems and should be corrected.
|
|