C64 Jiffydos

[DarkstarII]

I would like to see if you can implement Jiffydos in the C64 mode of the Mega65. Current hardware like Commodore 1541, 1571, 1581 and others like Rear Admiral Thunderdrive and uIEC/SD adapters that use it will lose the speed benefits.

[FeralChild64]

Open ROMs already contains JiffyDOS implementation - but for now I had to disable it in the MEGA65 build, as there are some timing problems leading to data damage (happens with original JiffyDOS ROM too). Currently Open ROMs implementation is not as fast as the original one, due to missing specialized LOAD protocol support, but is still several times faster than original CBM code.

[lgblgblgb]

Even if IEC timing is perfect: I would say, it's kinda non-trivial to implement Jiffydos for C64 mode of C65 (or MEGA65) the reason that it's kinda non-standard KERNAL with various modifications, like even move to C65 mode on boot, and all the patches to call the "in-computer" DOS for accessing the internal drive, also for example tape routines are removed, maybe new stuff is there instead, and who knows. Maybe it's possible though to slightly modify a Jiffydos ROM for C65/MEGA65, which works then, minus, you can't access easily the internal drive anymore (including the possibility of "mounted" D81 from the SD-card). That would need more serious effort to have a snapshot on the heavily modded C64 KERNAL used in C64 mode of C65, and try to implement Jiffydos support in it ...

[gardners]

@FeralChild64 if you are able to quantify the timing problems, this would be great, as I am trying to track down and squash all IEC port timing problems.

The one I know may contribute, is the CPU internal timing is always at 40MHz, and the CPU then just waits many cycles before executing the next instruction, if set to 1MHz. This means both reads and writes to the IEC port happen 3 cycles earlier than expected. But as the difference is equal, it "shouldnt" affect things. But I'd welcome your input on this. Otherwise, there is a problem with badlines happening at the wrong time, that I need to fix, which will be making JD sad when badline emulation is on. Does disabling it allow JD to work without problems?

[FeralChild64]

Last time I tried (last year...) both mine and original JiffyDOS implementations were producing an error (damaged byte) every couple of bytes, randomly. My implementation running with disabled badlines was producing one error each few kilobytes - this wasn't really that visible to the user, but for example crunched software did crash.

Is this '3 cycles earlier' read/write relevant to LDx/STx only, or for every instruction? My implementation uses LDA, ORA and EOR for reading CIA #2 port A, depending on a bit pair received.

I'll try to retest it and find out which bits are misinterpreted (just not today, it will require several tests) - maybe this will give us some clue.

[gardners]

It applies to any instruction: Because the CPU runs at 40MHz, the IEC port will see the event (or the IEC port event will be seen) within 100ns of the instruction starting. Since almost all accesses will be with XXX $nnnn type instructions, those all take 4 cycles on a real C64, i.e., ~4,000ns, with the write/read occurring at about 3,000ns, this explains the "3 cycles early", in that 2,900ns = ~ 3 cycles.

[FeralChild64]

Some updates:

1. [offtopic] It seems that my routine to detect PAL/NTSC (https://github.com/MEGA65/open-roms/blob/master/src/kernal/init/setup_pal_ntsc.s - stolen from Codebase 64) hangs on MEGA65 if NTSC is enabled. I'll try to check it in more details - maybe I did something wrong, if I won't find anything I'll create a ticket (but really not tonight).

2. When I switch MEGA65 to NTSC mode, my JiffyDOS loading is stable if badlines are disabled, there are no transfer errors. Is it possible, that the '1 MHz' clock is slightly too slow? Please keep in mind, that my implementation is reverse-engineered and tuned by trial-and-error on VICE and Ultimate 64; timing might not be precisely the same as the original JiffyDOS implementation.

[gardners]

Yes, it is possible that it is very slightly too slow, because the frame rate is exactly 50Hz. 50Hz x (625/2) lines x 63 cycles / line = 984375 Hz But it should apparently be 985248 Hz , so we are running at about 99.9% speed, i.e., we should drop less than one cycle per thousand, which I wouldn't have thought would cause problems -- but who knows. To fix this, we need to go from 540000 cycles per frame to 540486 cycles per frame. I can most easily increase it to 540000 + 625 by making each raster line one clock tick narrower.

But this also reminds me: I've seen C64s with clocks that are up to +/- 3% away from nominal speed. So I'd be a bit surprised if this was enough to cause the problem.

As for the PAL/NTSC detection, can you please debug what value it gets for the max raster number? It might be that we have an out-by-one somewhere for the NTSC max raster number.

[gardners]

Please check max raster in NTSC, and let me know. Synthesising the above fix for PAL clock speed adjustment.

[gardners]

On frequency variation, 50ppm error on the crystal would imply a best-case tolerance of ~50Hz, which is much tighter than I have observed on real C64s. Would be interesting for some folks to measure it on various machines. In any case, as JiffyDOS byte transfers take <1,000 cycles, I'm not confident that this fix will be successful.

Is JiffyDOS incorrectly guessing that a PAL machine is NTSC? Or is the code the same for both video standards?

[gardners]

Bitstream for test: http://cores.dev.mega65.org/experimental/mega65r3-20210209.10-develo-ac1aac0.bit

[FeralChild64]

Unfortunately, no change regarding JiffyDOS in this build (not a surprise, the speed difference is really very small). Bits that get flipped seem to be random at first glance, but I'll try to analyze the results in more detail.

No, my JiffyDOS code does not check for PAL/NTSC - the instruction timing should be valid for both clocks.

Regarding the VIC RASTER register - it goes up to $FF, something else must be the reason; I'll try to write some more sophisticated tests (but this is a topic for another ticket). [edit] Found out what's the behavior, will describe it in a moment in a dedicated ticket.

[gardners]

ok. I'm also not surprised that the tiny speed difference has no effect.

Paul.

On Wed, 10 Feb 2021 at 05:38, FeralChild64 notifications@github.com wrote:

Unfortunately, no change regarding JiffyDOS in this build (not a surprise, the speed difference is really very small). Bits that get flipped seem to be random at first glance, but I'll try to analyze the results in more detail.

No, my JiffyDOS code does not check for PAL/NTSC - the instruction timing should be valid for both clocks.

Regarding the VIC RASTER register - it goes up to $FF, something else must be the reason; I'll try to write some more sophisticated tests (but this is a topic for another ticket).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/mega65-core/issues/358#issuecomment-776171568, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOTYKECH2NTRAHZPOR73S6GB3DANCNFSM4W67SVBA .