TI Disk Controller DSR dissassembly?

[+retroclouds]

Is there a disassembly available of the standard TI-Disk Controller DSR ?

 

Reason I'm asking is that I have some File reading stuff in assembly that works fine in JS99er and classic99 but which locks up on the TI-99/4a with PEB and standard TI-Disk Controller.

I'm currently using a modified version of Paolo Bagnaresi DSRLNK code.

 

What I'm trying to come up with, is a scratchpad memory map of the minimal requirements for doing file I/O (I'll post the memory map at a later time)

For that I collected information from the documents posted in the Development Resources Thread, classic99 source code (mainly disk.cpp and ScratchPadCorruptList), Thierry's site, jedimat's TIPI source code, etc.

 

Even though there are many documents describing File I/O and DSR's floating around, there seems to be still quite some confusion as far as the exact used memory location are concerned.

The standard for me would be the TI-99/4A Disk Controller and go from there.

 

... and while we're at it. Is there a disassembly of the Editor/Assembler DSRLNK available somewhere? 

 

[Stuart]

http://www.unige.ch/medecine/nouspikel/ti99/download.htm#disass

 

A couple of headings down from the top of the page, "The disk controller card ROM"

 

Also appears to be the code for DSRLNK a bit further down the page (ea3.txt)?

[+FALCOR4]

Also, here are the original TI sidecar FDC DSR listings.  One time in the past I compared them to Thierry's disassembly of the PEB DSR and there were some changes so, beware.

 

 

TI sidecar FDC DSR.zip

[JJB]

In addition there is an excellent book called "Technical Drive" by Monthy Schmidt; for the project I am working on I did a comparison with Thierry's commented disassembly and there are some differences too. 

 

I did try to contact Monthy to see if he was ok with scanning and saving a copy on whtech but no response (interesting chap BTW). His book also contains commented disassembly of the Corcomp and RS232 devices. Any suggestions on the forum how to go about this?

 

Cheers,

 

Jochen

[Tursi]

12 hours ago, retroclouds said:

Is there a disassembly available of the standard TI-Disk Controller DSR ?

 

Reason I'm asking is that I have some File reading stuff in assembly that works fine in JS99er and classic99 but which locks up on the TI-99/4a with PEB and standard TI-Disk Controller.

I'm currently using a modified version of Paolo Bagnaresi DSRLNK code.

Please send me your test so I can fix Classic99.

 

Remember that you can patch in the real TI disk controller ROM in Classic99 which allows you to single step through it in conjunction with the disassembly.

 

[+TheBF]

18 hours ago, retroclouds said:

Is there a disassembly available of the standard TI-Disk Controller DSR ?

 

Reason I'm asking is that I have some File reading stuff in assembly that works fine in JS99er and classic99 but which locks up on the TI-99/4a with PEB and standard TI-Disk Controller.

I'm currently using a modified version of Paolo Bagnaresi DSRLNK code.

 

What I'm trying to come up with, is a scratchpad memory map of the minimal requirements for doing file I/O (I'll post the memory map at a later time)

For that I collected information from the documents posted in the Development Resources Thread, classic99 source code (mainly disk.cpp and ScratchPadCorruptList), Thierry's site, jedimat's TIPI source code, etc.

 

Even though there are many documents describing File I/O and DSR's floating around, there seems to be still quite some confusion as far as the exact used memory location are concerned.

The standard for me would be the TI-99/4A Disk Controller and go from there.

 

... and while we're at it. Is there a disassembly of the Editor/Assembler DSRLNK available somewhere? 

 

I ran into issues around DSR scratchpad use as well so I will be very happy to see the results of your research.

I thought I had a lot more free memory below the 8300 workspace than I really have which I wanted for task variables.

From what I remember the DSR uses a workspace somewhere in the >83C0 area.

 

[+mizapf]

Maybe you could also try MAME and its debugger; as you know, it uses the original TI floppy controller DSR. At least you can check whether it also locks up there.

[+retroclouds]

Thank you for all the valuable input. I knew this was the right place to ask. ?

Please bare with me while I go through the details.

 

 

 

 

 

Edited October 6, 2019 by retroclouds

[+Lee Stewart]

You may have already read this, but GPL Interface Specifications for the 99/4 Disk Peripheral is my go-to document for all things related to the details of the TI disk DSR, especially for levels 1 and 2 access.

 

...lee

[+retroclouds]

17 hours ago, Tursi said:

Please send me your test so I can fix Classic99.

 

Remember that you can patch in the real TI disk controller ROM in Classic99 which allows you to single step through it in conjunction with the disassembly.

 

Yes, I'll prepare and send you the test, probably tomorrow.

 

One thing to note is, that if I set "Break on Disk Corrupt" the execution halts with the following Debug warning:
Warning: DSRLNK functions should store the DSR address of the device name entry at >83D2!  (Got >4019)

 

So classic99 did catch that something is fishy.

 

It seems that the DSRLNK is saving an invalid address out of the DSR header to >83D2
That could explain that the card is turned on, but the actual "bl *R9" branches to an invalid location in the Disk Controller ROM and then goes bananas.

 

What steps would I need to do to patch the real TI disk controller ROM in classic99?  
I made a custom cart with the disk controller ROM at >4000, but the TI-99/4a title screen does not appear and I see a lot of debug messages.

According to the debug messages it seems it is having issues with the DSR powerup routine.
 

[+retroclouds]

8 hours ago, mizapf said:

Maybe you could also try MAME and its debugger; as you know, it uses the original TI floppy controller DSR. At least you can check whether it also locks up there.

 

That's something I would like to try. I've successfully compiled MAME on my Ubuntu desktop machine and it works so far.

The thing is that I don't have any ROMs at this time. Well the ones I do have do not work, although I configure MAME to use my directories it keeps saying the selected software is missing files.

 

Probably will have to invest more time in getting MAME properly configured

[Tursi]

2 hours ago, retroclouds said:

So classic99 did catch that something is fishy.

 

What steps would I need to do to patch the real TI disk controller ROM in classic99?  

 

Just change the disk configuration:

 

Take the disk warning debug with a grain of salt. It's well intentioned but I haven't proven it all out. When it gives you a message like that, your first job is to answer the question "is that true?"  (I /do/ use it myself when I need to debug disk stuff, that's why it's there, we just haven't run enough cases through it for me to be fully confident.)

 

 

[Tursi]

2 hours ago, retroclouds said:

One thing to note is, that if I set "Break on Disk Corrupt" the execution halts with the following Debug warning:
Warning: DSRLNK functions should store the DSR address of the device name entry at >83D2!  (Got >4019)

This check is called on entry to the Classic99 DSRLNK (which is the only place these tests can be done - you get very little checking on the TI controller). It checks that the current PC matches the value stored at >83D2, which is supposed to be the DSR entry point.

 

It's entirely possible to call any DSR without setting any magic values in scratchpad. However, you run into problems if the DSR assumes you did. And the TI disk controller makes a lot of those assumptions. It doesn't seem to use >83D2 though, and I didn't document why I put that check in. ? (It does say "should" instead of "MUST", the terminology is important on those ones).

 

What's interesting is that >4019 is a meaningful value (at least it's in DSR space), but it's meaningless in the TI disk controller ROM. In the Classic99 ROM, it's the address of the unused byte right after the string "DSK1"

 

[+mizapf]

@retrocloudsAll ROMs can be found on Whtech. Have a look at the folders "System ROMs" and "Cartridges".

Edited October 7, 2019 by mizapf

[+retroclouds]

ok, I was able to resolve the lockup. 

 

These were the steps I did (well there were quite a few more, but only the below are relevant to the described issue (I also spend quite a few time chasing the DSR chain due to issues in my DSRLNK version).

 

1. By activating the TI Disk Controller ROM in classic99 I was able to reproduce the same behaviour I experienced on the TI-99/4a itself.

2. To further diagnose the issue I printed the full TI Disk Controller ROM disassembly on paper

3. Basically the first DSR call I traced was the equivalent of "call files(1)" via DSR subprogram >16 (set #number of files) which already didn't return and stayed in the DSR.

4. One of the first things the subprogram does is "BL @>4724". I copied that part of the DSR  below. You see the part where 2 bytes of VDP memory is read and returned to R8, well that didn't work out.

5. The problem was that the VDP address to read from is fetched from scratchpad >8370 and I still had that memory location set to >0000 instead of >37D7. 

6. I also had to make sure that VDP range >37D7 up to >37DC contains the words: >00AA,>3FFF, >1100

 

... and now it works on the real hardware too.

 

DSR disassembly (as found on Thierry's site):

*---------------------------------------
* Preparation subroutine
* Sets up the 4 custom subroutines
* Gets a few pointers to VDP buffers
*  >8358: copy of VIB  >8366: VDP stack ptr (grows down from drive info)
*  >8354: PAB          >8356: ptr to end-of-buffer
*---------------------------------------
A4724  INCT 7                 stop scanning upon return
A4726  MOV  11,10             save return address
       STWP 9                 get workspace (should be >83E0)
       AI   9,>FF20           top of scratch/pad mem (>8300)
       LI   0,A4690           entry to 4 custom routines
       MOV  0,@>005C(9)       put it in >835C
       MOV  9,0
       AI   0,>004E           workspace for these four (>834E)
       MOV  0,@>005A(9)       put it in >835A
 
       MOV  @>0070(9),8       highest free address in VDP mem
A4744  INCT 8                 point to "end-of-buffer" word
       BL   @A4B76            read 2 bytes from VDP address R8, into R0
       MOV  8,2               save current R8
       MOV  0,8               get end-of-buffer word
       MOVB @>FBFE(15),1      get CRU of controller that reserved this mem
       CB   12,1              same as ours?
       JNE  A4744             no: use end-of-buffer to link to next buffer
       AI   8,>FEF6           yes: point to volume information block
       MOV  8,@>0058(9)       save it in >8358
       AI   8,>FFF6           point to disk drive info (drive #, last tracks)
       MOV  8,@>0066(9)       save in >8366: VDP stack ptr (DECT before writing)
       BLWP @>005A(9)         save R7 (return address)
       DATA >0100
       MOV  @>0056(9),7       ptr to PAB: end of DSR name
       MOV  7,3               save it
       S    @>0054(9),7       beg of DSR name
       MOV  2,@>0056(9)       >8356: ptr to "end-of-buffer" word in VDP mem
       DEC  7                 point to name length byte
       CLR  2
       BLWP @>005A(9)         set VDP to read from address in R2
       DATA >00E2
       MOVB @>FBFE(15),2      get name length byte
       SWPB 2                 make it a word
       S    @>0054(9),2       minus DSR name size: lenght of .parameters
       AI   7,>FFF7           point to top of PAB
       MOV  7,@>0054(9)       save it in >8354
       B    *10
*

 

 

 

 

[+retroclouds]

Attached is a first draft version of my minimal scratchpad memory map for doing file I/O with the standard TI Disk Controller.

This attached file was create with LibreOffice Calc, but I guess it can be opened in Microsoft Excel as well.

 

Warning: There are still a few locations missing in the memory range >8370->83FF that I need to clarify and that are not yet in the map!

As a workaround for now I basically loaded >8370->83FF with values I dumped while running Editor/Assembler and that gets me a working version on the TI-99/4a.

 

data00008370  data >37D7,>9E80,>00FF,>0000,>0075,>0080,>0000,>151B  
data00008380  data >6117,>6FE1,>0000,>0000,>0000,>0000,>0000,>0000
data00008390  data >0000,>0000,>0000,>0000,>0000,>0000,>0000,>0000        
data000083a0  data >0000,>0000,>0000,>0000,>0000,>0000,>0000,>0000
data000083b0  data >0000,>0000,>0000,>0000,>0000,>0000,>0000,>0000
data000083c0  data >5C2D,>0000,>0000,>0200,>FFFF,>FF00,>0484,>0000
data000083d0  data >0874,>0000,>E000,>05D6,>0070,>83E0,>0074,>2002
data000083e0  data >0000,>0002,>0000,>0000,>0000,>0000,>0000,>0000
data000083f0  data >0000,>0006,>4000,>02BA,>0006,>9800,>0108,>8C02

 

But some of these values can be removed, so have to do more testing.

Memory Map for DSR operations.ods

[+retroclouds]

12 hours ago, mizapf said:

@retrocloudsAll ROMs can be found on Whtech. Have a look at the folders "System ROMs" and "Cartridges".

Thanks. I want to give this a try. Basically want to see what I can accomplish with the MAME debugger.

[Tursi]

1 hour ago, retroclouds said:

5. The problem was that the VDP address to read from is fetched from scratchpad >8370 and I still had that memory location set to >0000 instead of >37D7. 

6. I also had to make sure that VDP range >37D7 up to >37DC contains the words: >00AA,>3FFF, >1100

But how did you get into the case where either of those were untrue? The scratchpad >8370 is set by the console at powerup, and modified by the disk DSR during the power up hook, and the VDP bytes are written by the disk DSR at powerup. Did your code erase them?

 

It's not really safe to just blindly set >8370 to >37D7 -- that's only the value for 3 FILES with the TI disk controller. It will be different for a different value of CALL FILES or some different devices (for instance, the CF7 reserves an extra 6 bytes).

 

(Classic99 should have reported "Disk buffer header corrupted at >xxxx" for the missing VDP header, and "Top of VRAM pointer changed..." for the modification to >8370)

 

Edited October 7, 2019 by Tursi

[+retroclouds]

22 hours ago, Tursi said:

But how did you get into the case where either of those were untrue? The scratchpad >8370 is set by the console at powerup, and modified by the disk DSR during the power up hook, and the VDP bytes are written by the disk DSR at powerup. Did your code erase them?

 

It's not really safe to just blindly set >8370 to >37D7 -- that's only the value for 3 FILES with the TI disk controller. It will be different for a different value of CALL FILES or some different devices (for instance, the CF7 reserves an extra 6 bytes).

 

(Classic99 should have reported "Disk buffer header corrupted at >xxxx" for the missing VDP header, and "Top of VRAM pointer changed..." for the modification to >8370)

 

 

I'm using my spectra library that basically clears all of scratchpad and VDP RAM upon program initialisation.

That's the reason why I'm interested in building a memory map for scratch pad and VRAM, so I know what memory locations are "reserved" and/or  what values are expected.

 

I know I'm learning this the hard way, and takes longer but it does help me a lot better to understand file I/O & DSR architecture.

Most of the gaming stuff I programmed on the TI-99/4a in 9900 assembly, runs basically very isolated as barely anything "external" is used.

Now with the file I/O it's a different thing, but I guess that's part of the fun.

 

I'm not at my Windows Desktop machine, I think I've seen the Disk buffer header corrupted at >xxxxx debug message before. 

Quick question; would it be possible to add a buffer with scrollbar to the classic99 debug pane? That way if messages roll off the screen I can still review them by scrolling up?

[Tursi]

I've thought about it before, but since I usually use the Visual Studio debugger for big things it hasn't been a priority for me. That doesn't help you, of course. But this does! Try out DebugMon - https://www.osronline.com/article.cfm^article=99.htm

 

Classic99 sends all debug out through the OutputDebugString API, so any debug monitor can capture it, display it, log it, etc.

 

Looks like it was replaced with DebugView, that's what I actually run. https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

 

Edited October 9, 2019 by Tursi