Non Destructive DSR Dumps

[atrax27407]

For those of you who wish to dump DSRs from your devices without desoldering the chip itself, here is a series of non-destructive utilities that I have used for many years. With these files, you can dump and save individual DSRs ranging in size from 2K to 64K. All that is required is that you know the CRU address of the DSR and its length.All of these files load individually as E/A-3 files and must be loaded from the F'WEB kernel since they use some of the internal routines contained therein. The base routine was written by Tony McGovern for me on one of my trips to Oz. The output file names and input CRU address are configurable in the program. I have used the lowest possible disk cofiguration (i.e., SSSD) to make these files available to all. Enjoy!

DSRDUMP.dsk

Edited November 19 by atrax27407

[atrax27407]

Quick Docs:

 

1) Load F'WEB

2) Load the appropriate dump file for the length of the DSR.

3) Enter the CRU address of the device.

4)Change the output device as needed.

[+arcadeshopper]

also https://github.com/jedimatt42/fc_romdump

for force command

[atrax27407]

The ROMDUMP program for FORCE COMMAND appears to be limited to a max of 8K. While relatively uncommon, there are TI DSRs that are larger than 8K. Give me a few days and I'll put together a size chart of the various DSR sizes.

 

Edited November 20 by atrax27407

[+arcadeshopper]

36 minutes ago, atrax27407 said:

The ROMDUMP program for FORCE COMMAND appears to be limited to a max of 8K. While relatively uncommon, there are TI DSRs that are larger than 8K. Give me a few days and I'll put together a size chart of the various DSR sizes.

 

@jedimatt42

[atrax27407]

Here are some general sizes for DSRs:

 

AVPC            2K

 

RS232          4K

 

FDC              8K   (except TIFDC has two 4 K chips)

 

Myarc HFDC  16K

 

Geneve         16K

 

CorComp PES 16K

 

SNUG EVPC     64K

 

Some cards with a 4K DSR can use either a 2732 or a TMS2532 and you need to check the specs. In any case, it is wise to check the chip used on the card (i.e., 2716, 2732, TMS2532, 2764, 27128, or other).

 

 

[+jedimatt42]

Any tool to dump roms would have to be told how the particular card bank switched them. I would guess that most of them just need some CRU bit setting. I am not aware of a convention for guessing that.

 

The tool in my GitHub is not general purpose, but more of an example in ForceCommand. It was good enough for me to grab what I wanted to change in my Corcomp controller, and easier to write than taking the shell off the card and popping the ROM into an eprom reader ( it was already socketed )

 

It wouldn't be hard to prompt for crubits to set. But at this point are there really any roms left to dump?

[Gary from OPA]

What I would like to see is a tool that scans your cards and based on a checksum of all known dumps tells you what version of each DSR you have currently, as there is like 4 different Corcomp DSRs for each of their cards. And same for the myarc ones.

Edited November 25 by Gary from OPA

[+retroclouds]

47 minutes ago, Gary from OPA said:

What I would like to see is a tool that scans your cards and based on a checksum of all known dumps tells you what version of each DSR you have currently, as there is like 4 different Corcomp DSRs for each of their cards. And same for the myarc ones.

I have such a program as a cartridge image. Did this a few years back. My checksum library is a bit limited though as it only contains the cards I physically have in my posession. Also with DSRs in RAM that also contain volatile data (thinking about the HRD4000B) it’s kinda difficult to do checksumming, if I remember correctly.

 

Having said that, I’ll did out the cartridge image and source code.

 

Found the cartridge image, but not the source code yet.

 

[Gary from OPA]

I grabbed the "disk image" from the first post, and I tried loading some of the object files, but it must be an "bad image" as the DSR8K one comes up with illegal TAG Char. and the others are worse, some are only filled with >27 as you can see in the attached screenshot.

 

anyone have a working copy of this program?

 

[atrax27407]

Apparently, there was an error in the original file that rendered the contents corrupted. Here is a replacement file that is in the form of a TI archive (vn 3.03) with a TIFILES header. Sorry for the inconvenience. 

DSRDUMP

[atrax27407]

Here is the base dump source code. Change the hex value of the DSR length to whatever you require. 

DSRDUMP1

[apersson850]

On 11/22/2024 at 5:23 PM, atrax27407 said:

Here are some general sizes for DSRs:

Although technically not a DSR, the p-code card has a program stored in DSR space.

 

It's 12 K. The last 4 K are bankswitched with CRU bit 1F80. There are also "holes" in the DSR space in the last 4 K part, since there are GROM access ports decoded to these addresses. Makes it impossible to calculate a checksum if you look at the whole memory area, since the values read from the GROM read data and read address ports will differ all the time.

Edited November 27 by apersson850

[atrax27407]

Rather than try to catalog all of the DSR variants, I used generalities. There are numerous examples of "strange" configured DSRs (ex, the TI FDC DSR which occupies two 4K TMS2532s instead of a singly 8K chip).

[apersson850]

Yes, but that you'll not notice when you read out the memory. Bank switched memory will be very noticeable.

[+InsaneMultitasker]

On 11/25/2024 at 12:10 AM, retroclouds said:

Also with DSRs in RAM that also contain volatile data (thinking about the HRD4000B) it’s kinda difficult to do checksumming, if I remember correctly.

The more recent ROS versions I released contain a CRC value that is validated by CFG during the load process.  You are correct that the ramdisk dsr is volatile once loaded, as some dsr space is also used for data.  I believe that Fred also validates the IDE dsr upon loading, perhaps there are others as well. 🙂