+retroclouds Posted October 5, 2019 Share Posted October 5, 2019 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? Quote Link to comment Share on other sites More sharing options...
Stuart Posted October 5, 2019 Share Posted October 5, 2019 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)? Quote Link to comment Share on other sites More sharing options...
+FALCOR4 Posted October 5, 2019 Share Posted October 5, 2019 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 Quote Link to comment Share on other sites More sharing options...
JJB Posted October 5, 2019 Share Posted October 5, 2019 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 6, 2019 Share Posted October 6, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 6, 2019 Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 6, 2019 Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted October 6, 2019 Author Share Posted October 6, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 6, 2019 Share Posted October 6, 2019 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 3 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted October 6, 2019 Author Share Posted October 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted October 6, 2019 Author Share Posted October 6, 2019 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 6, 2019 Share Posted October 6, 2019 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.) 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 6, 2019 Share Posted October 6, 2019 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" 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 7, 2019 Share Posted October 7, 2019 (edited) @retrocloudsAll ROMs can be found on Whtech. Have a look at the folders "System ROMs" and "Cartridges". Edited October 7, 2019 by mizapf 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted October 7, 2019 Author Share Posted October 7, 2019 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 * Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted October 7, 2019 Author Share Posted October 7, 2019 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 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted October 7, 2019 Author Share Posted October 7, 2019 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 7, 2019 Share Posted October 7, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted October 8, 2019 Author Share Posted October 8, 2019 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? 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 9, 2019 Share Posted October 9, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.