Maybe this will finally lead to exploiting C128 features by the scene ;)
I wouldn't count on it.
You also have a BURST load, and you can probably say 1571 required, to which you get another 2mhz CPU which you can burst transfer data. For faster loading and streaming.
said 32 clocks don't take any 128 CPU or Drive CPU
so on the drive you can GCR decode(given the Drive has 64 clocks to play with you could probably even deflate on the drive) and get the next byte ready while the hardware transfers the byte. So you can send a byte in 32 clocks, and then send one instantly again.
To which the 128 has a 32 clock window to grab it in(sadly a 1Mhz NMI handler would take longer than this, but on 2Mhz you could use the NMI - I think not actually worked out all clock variants).
Also you can Burst transfer and bit bang at the same time.
but the time it doesn't have to spend loading and installing the loader
Quote:said 32 clocks don't take any 128 CPU or Drive CPUNot quite, at least writing the next byte into the latch and reading a byte on the other side plus storing it require a few cycles as well.
Quote:so on the drive you can GCR decode(given the Drive has 64 clocks to play with you could probably even deflate on the drive) and get the next byte ready while the hardware transfers the byte. So you can send a byte in 32 clocks, and then send one instantly again.Sending data during fetch+decode might be possible, especially by using the optimised GCR read+decode+checksumming approach which i haven't ported from 1541 to 1571 yet. It could do that already, thanks to 2 MHz mode and some suitable tables in ROM, but alas, without spare cycles to speak of. Sending data while reading from disk would not work with an IRQ loader, but at least the screen could remain enabled while loading.
Decompression on the drive side would likely have more drawbacks than gain. There's no RAM to store a dictionary or previously-depacked data, and the serial transfer will remain the bottleneck even with BURST.
Quote:To which the 128 has a 32 clock window to grab it in(sadly a 1Mhz NMI handler would take longer than this, but on 2Mhz you could use the NMI - I think not actually worked out all clock variants).NMI is probably prohibitive either way. But polling would work and leave spare cycles for some interleaved code doing other stuff. Quote:Also you can Burst transfer and bit bang at the same time.That's an interesting idea! :) Quote:but the time it doesn't have to spend loading and installing the loaderHmm, i've mostly regarded the install prodedure as a fire&forget action, so never really benchmarked that. I've had some plans to let the drive fetch its custom loader code directly from disk, rather than the roundabout way of loading a file into computer memory and then uploading the custom drive code to the drive. But i scrapped those plans for the sake of easier usage.
VS bit banging where all 32 clocks are eaten on both 128 and Drive.
4 lda $dd00 2 lsr 2 lsr 4 eor $dd00 2 lsr 2 lsr 4 eor $dd00 2 lsr 2 lsr 4 eor $dd00 4 sta somewhere
Well does the GCR read + decode + checksumming take 64 or more clocks ( given we are running at 2mhz not 1 mhz), if so or about that much, instead of STA RAM,x inx can you not just STA CIA REG ??
I mean even if it was just an RLE of level data or something, still gets you more disk space with zero effort on the 128 side, so your game gets more CPU time.
Well I'm loading a one shot game, such as Dropzone and Kung Fu Master, so I only need to load once.
If you can do on the fly GCR decode without the fancy tricks at 2Mhz ( the 1571 internals book claims you can ) that would free up a lot more RAM right?
IOr if you have the speed and you can dump data directly down the SSR, could one use the data as Huffman and hence you can deflate Huffman code off the disk?
In my loading case it has a bitmap and music playing, with the 128 version it can keep them going right till the end. On the 64 version it need to load in all the data. Remove the bitmap, music and then deflate. The disk is here http://cloud.cbm8bit.com/oziphantom/autoboot_dropzone.d64 use Boot or let autoboot load the 128 version. LOAD "*",8,1 to load the C64 version.
