DSR authoring and memory usage?

[+jedimatt42]

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:

 

https://goo.gl/photos/vRvgdZwDRdqV6duE8

 

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!

-M@

[+InsaneMultitasker]

One thought pops into mind: are you certain that all bytes of each file are being copied into VRAM by your DSR? Specifically, are you calculating the total bytes using both the total sector count AND the EOF offset? When you encounter an EOF offset of '0' are you counting it as 256 bytes?

 

The EA5 loaders use the header /within/ the image file to determine how much to copy, where to copy it, and whether or not another file needs to be loaded. This is not the same as how the DSR computes the total size of the file to copy from the 'disk' device.

Edited April 3, 2017 by InsaneMultitasker

[+jedimatt42]

One thought pops into mind: are you certain that all bytes of each file are being copied into VRAM by your DSR? Specifically, are you calculating the total bytes using both the total sector count AND the EOF offset? When you encounter an EOF offset of '0' are you counting it as 256 bytes?

 

 

Thanks, I did not realize the eof-offset of zero meant a full sector. I'll be writing that down. I'm using 256(sectors-1) + eofOffset.

 

The EA5 loaders use the header /within/ the image file to determine how much to copy, where to copy it, and whether or not another file needs to be loaded. This is not the same as how the DSR computes the total size of the file to copy from the 'disk' device.

 

You are my hero! I fixed my TIFILES decoder:

 

     @staticmethod
     def byteLength(bytes):
-        return ((ti_files.getSectors(bytes)-1) * 256) + ti_files.eofOffset(bytes)
+        eofsize = ti_files.eofOffset(bytes)
+        if eofsize == 0:
+            eofsize = 256
+        return ((ti_files.getSectors(bytes)-1) * 256) + eofsize

And now it works!!! AMBULANCE works great, and the sound track to MOONPATROL IS CORRECT!!! You just made my weekend!

 

Thanks!

-M@

[Opry99er]

The Insane One strikes again.

[+Schmitzi]

Hi, looks great (y) But, what does it mean, a "disk-less disk system" ?

Is it to store/read data from inside a Supercart´s memory, like from a disk ?

thx

[+arcadeshopper]

Tipi

 

Sent from my LG-H830 using Tapatalk

[Omega-TI]

But, what does it mean, a "disk-less disk system" ?

 

Tipi

 

Looks like Schmitzi needs to get on an airplane and hookup with all of us at Fest West 2017.

 

https://www.youtube.com/watch?v=PcQZXL_0aGA

[+jedimatt42]

Hi, looks great (y) But, what does it mean, a "disk-less disk system" ?

Is it to store/read data from inside a Supercart´s memory, like from a disk ?

thx

Well, I was thinking I meant solid state instead of rotating media. However, my system doesn't care what the media is, and I realize now that you have asked, that your files could quite easily be on a USB floppy drive.

 

I'll have to include that in the Fest West demo. For grins and giggles.

 

-M@

[+Schmitzi]

cool

[+Ksarul]

If you want truly weird, I have USB LS120 and LS240 drives, which would put them right into the range of TI hard disks. . .

[+jedimatt42]

If you want truly weird, I have USB LS120 and LS240 drives, which would put them right into the range of TI hard disks. . .

That's funny That tech didn't stick around.

 

-M@

[RickyDean]

If you want truly weird, I have USB LS120 and LS240 drives, which would put them right into the range of TI hard disks. . .

Yea, I have a couple of LS120's around, gonna try one on the systems, sometime.