So I might be working on a disk-less disk system for the 4A. I've been fighting with hardware stability issues while testing DSR features, like all that catalog stuff that makes DM2K so fun to use.
I assumed my problems with the LOAD opcode had been data corruption in my breadboard hardware. I know it happens. So I eliminated it by implementing a cheap Pearson hash on the data in 64 byte chunks, and re-sending a chunk until it comes across with an agreed hash. This is working great. I see the retries, and final corrections. All data is transmitted from the data-store to the TI this way. So I'm confident the data is coming across correct. A few EA5 games work, lots of them don't. I'm loading both with XB2.7's option B, TI-Writer/Editor Assembler, and with DM2K.
Here is an example of something that doesn't work, Ambulance:
I don't believe it is data corruption in the image transmission anymore. I have checked that these images load fine on emulation. After adding the transmission error correction, the symptom is extremely (100%) repeatable. You can see in that video, the game loaded. Sprites are a mess, running at full speed, and the train's graphics are messed up. My own ambulance moves at a snails pace. But it does move only when I command it.
Centipede loads fine. Clowns load fine. Moonpatrol has a glitch. The audio track does not play through properly, and it loops back pre-maturely.
I'm using the WP that I was dumped into when my DSR device routine is called, >83E0. The docs I have say I'm allowed to use R0 - R10... which with the hashing and retrying, I am using all of them. I copy the PAB bytes 0-9 into scratchpad FAC space, >834A. The docs say I'm allowed to use >834A - >836D.
I mess with >834A - >8353, and >836A - >836D, and >83E0 as WP (R0-R10) I use R11 of course with BL/RT, but put it back per contract for returning from DSR routines. ( Writing out a story like this generates ideas, so I moved that >836A - >836D down to >835A -> 835D to stay within the FAC, which we know is restored from VDP upon DSR completion. No change. )
Anyone trek here before me, and experience gaps in the docs that might lead to these symptoms?
Upon success for a LOAD request, I'm not updating the PAB in VDP at all. But I think it is a fishy protocol that doesn't want to know how much data was loaded... unless that is why our Program Image files have size parameters in the beginning of the data.
I'm also not using a File Control Block in VDP ( or at all ) - My device brings no RAM to the party that the 9900 can see. It looks like I shouldn't need any.
I've found a few already... I'm mostly working off of these:
Device Service Routine Specification Version 2.0 '1983
File Management Specification Version 2.5 '1983
(From over in the dev resources thread)
My next step is probably to write a program that audits itself so I can determine in what way the program is corrupted.
I'd like this to be solid before I implement any write operations.
Desperate for insight!