DSR Dump

[atrax27407]

I am on a never-ending quest for TI (and other) DSRs. Some years ago, Tony McGovern (of Funnelweb fame) came up with a non-destructive DSR dump that runs only out of F'WEB since it uses some of the internal routines in the FW file. All the user must know is the length of the target DSR and the CRU address and the program will do the rest - just fill in the prompts. The CRU addresses are general knowledge or can be found in the docs for the PEB card or standalone device. As for the DSR length, if you don't know what it is, simply select the 8K file. The DSR can be edited with an appropriate Hex editor to the proper length if less than 8K. The steps are as follows:

 

1) Load the FW file (E/A5) with the Editor Assembler cartridge (or appropriate loader).

 

2) Use the loader in F'WEB to load the appropriate DSR dump file (i.e., 2K, 4K, 8K, or 16K). Those files are E/A3 (Load and Run files)

 

3) Enter the CRU address and destination (i.e., DSK1.DSRDUMP1) at the prompts.

 

4) Press <ENTER> 

 

I would appreciate it if you would send me copies of the DSR dumps for my collection.

DSRDUMP.dsk

Edited April 17, 2022 by atrax27407

[atrax27407]

For use in a running system. Will NOT work with loose chips.

[+arcadeshopper]

weirdest thing, this won't work on a sidecar rs232. I've tried it on 2 systems, one with combo tipi/32k and the sidecar and the other with pbox and the sidecar..both get me a bunch of 00's in the dump. 

with easybug I can enable the DSR and view it with m4000 just fine 

 

while the dump program works fine with the pbox rs232

 

/shrug

 

 

[apersson850]

Does it know about the different quirks for memory mapping that exists? Lite the 12 K ROM in the p-code card?

[atrax27407]

The program only passes two parameters. It looks for the entered CRU address and saves the designated number of bytes to a changeable disk volume/filename. It should work on a sidecar as well as a PEB but for some reason it doesn't work on the sidecar. Here is the complete source code - maybe one of you assembly gurus can figure it out.

DSRSRCE.dsk

[+jedimatt42]

Generally dumping a ROM is as easy as enabling the crubase bit 0, copying the data into VDP or expansion ram, and then SAVE-ing it or WRITE-ing it to a file..  So, I didn't read the code above, just wrote something fresh, and it seemed to work for Arcadeshopper to dump the sideport RS232 rom. 

 

So here is a thing that I threw together mostly last night... a little cleanup today. Runs in Force Command (requires version 2.0 or better of Force Command)

 

jedimatt42/fc_romdump: TI-99/4A DSR ROM dumper for Force Command (github.com)

 

TIFILES executable and DSK image if that's handy... 

 

(NOT AN EA5 FILE / Force Command can run on anything that has a cartridge port, 32K ram, and some type of disk)

[apersson850]

It's the paged ROMs that are tricky. Like Extended BASIC in the cartridge, or the p-code card in the box. Different ways to handle the paging.

[+jedimatt42]

Extended Basic isn't tricky, you just use CSAVE. 

 

This may be called ROMDUMP, but it only aims at non-bank switching DSR ROMs.

 

The context of the thread is important.

[+Ksarul]

2 hours ago, jedimatt42 said:

Extended Basic isn't tricky, you just use CSAVE. 

 

This may be called ROMDUMP, but it only aims at non-bank switching DSR ROMs.

 

The context of the thread is important.

I think the issue identified with the p-Code card might be relevant to the contect though, as it uses a CRU-switched 12K DSR. I think the HFDC DSR may also be larger than 8K. I'm not sure if there were any other large ones ATM.

[Tursi]

I don't mean to be contrary.. but there's no code in that FW listing for paged DSRs, or even guessing what it's trying to dump. It appears to just copy to VDP then SAVE.

 

It's jumping to predefined functions that are not commented, so there is some guesswork here on my part. But there seems to be enough context to see what it's doing

 

I think the problem is here:

* Dump DSR to VDP
 
       LI   R0,>0100          >0001 for 16 bit HRDs >0100 for 8
       LDCR R0,8

Any CRU that's not fully decoded in hardware (for at least 8 bits) will be turned on then immediately turned off by this code. I can't say for sure that's what is happening, but I don't remember needing more than one SBO to turn on the Horizon, so I'm not sure what this is trying to do.

 

After that, the code literally hardcodes a single copy of 8k from >4000:

       BLWP *R9
       DATA VDPBUF            Move DSR into VDP 6 bytes from beginning
       DATA >4000,DSRLEN      Assume no problems in reading address

Then it saves it to disk and exits.

[atrax27407]

Depending on which one of the "dump" software programs you load, it dumps 2K, 4K, 8K, or 16K chunks. The size is changeable in the source. I have included several additional besides the 8K dump. The HFDC, for example, is a 16K DSR. That still doesn't answer the question of why it works flawlessly on PEB cards but not on sidecars.

Edited April 19, 2022 by atrax27407

[atrax27407]

1 hour ago, Tursi said:

* Dump DSR to VDP

  LI   R0,>0100          >0001 for 16 bit HRDs >0100 for 8      

  LDCR R0,8

 That section of code is to accommodate dumping Horizon Ram disk DSRs (i.e., HRDs) >0001 for 16 bit Horizons and >0100  for 8 bit Horizons. At least, that's what Tony told me when he wrote it for me in 1990.  

[+mizapf]

Over time, I gathered quite a collection of specialized ROM dumpers for various cards and systems, for the purpose of getting authentic ROMs for MAME. (Ciro @ti99iuccertainly remembers all the tools to get the 99/8 ROMs and GROMs on a disk image.) In the end I had a kind of template program and a part that I had to adapt; this often required to have a look at the schematics.

[+InsaneMultitasker]

IMHO, the Horizon Ramdisk DSR is not meant to be dumped.   Once loaded into the ramdisk, the DSR modifies itself through various operations and is no longer "pristine".   Users should only load the DSR (ROS) using a distribution file or a personal saved copy; the former also comes with a CRC self-check during the initial DSR load operation.

 

As for the CRU operation, with exception of the 8k/32k "dsr" ram chip, the ramdisk "sectors" are addressed in a 2k window and depending on the ramdisk age/type, this is done with either an 8-bit or a (slightly inaccurate) "16 bit" cru operation. Removing the ramdisk-specific code from this dump program would be a good thing...

 

14 hours ago, Ksarul said:

I think the issue identified with the p-Code card might be relevant to the contect though, as it uses a CRU-switched 12K DSR. I think the HFDC DSR may also be larger than 8K. I'm not sure if there were any other large ones ATM.

HFDC is 16K banked in 4K pieces (and RAM is banked on 1k boundaries in the other 4k space).  Other examples include banked DSRs, like the Myarc FDC, SCSI card, IDE, etc. 

[apersson850]

The p-code card keeps the first 4 K the same. The last 4 K are switched with CRU bit 1F80.

[atrax27407]

The program was written in the days of ROS 8.14 - 30+ years ago. 

[ti99iuc]

18 hours ago, mizapf said:

[...] Ciro @ti99iuccertainly remembers all the tools to get the 99/8 ROMs and GROMs on a disk image [...]

Oh yes, this was one of the unforgettable and exciting experience had in the community, make the TI99/8 immortal