Grab ROM from expansion board ?

[peo]

Is there (there probably is, but I cannot find it) a ready-made tool for grabbing the ROM from any expansion board, giving parameters as start address, size and file name ?

I could probably write one myself if I dust off my old (like 25+ years since) assembly language knowledge..

Trying to get along with a Grandslam controller that refuses to autoboot, want to grab the ROM to compare it to the already grabbed 4.9 (by Stone).
The suggested tool "expdump" does not dump anything except the start address, size and some other info (not the ROM code).

I also have some of the hardware on the "wanted roms" list, both Trumpcard AT and Trifecta 500 LX. Have not started these up yet, have to take care of the disks in them first.

[Toni Wilen]

There is no easy automatic way because ROM size can't be detected automatically and accidentally accessing IO space can hang the system. Sometimes rom offset isn't pointing at the start of ROM. Actual ROM size does not necessarily match mapped space, for example it is common to have 2 banks in ROM, one for autoboot enabled and another for autoboot disabled jumper state.

Manual way is easy enough with any monitor program (like mon165.lha from Aminet), "] <start> <length> <name>" to save address space to a file. No need for separate program. It can be also used to examine the ROM space easily with m -command.

GrandSlam ROM is mapped at board base + $8000.

Attach expdump from other boards, thanks. Trifecta ROM is still MIA, Trumpcard AT two different versions are already dumped but there can be others.

[peo]

I was not looking for the easy, automatic way, but just any way
mon165 might do it easy enough, but this functionality could easily be added to expdump.

I think even AsmOne can do that on the command line, but it is a long time since I programmed on the Amiga.

The output from expdump with Oktagon 2008 attached to the A500 (using the Grandslam expansion box, to check that interface), gave me start: 00e90000, size: 00010000 (64k).

[Toni Wilen]

Originally Posted by peo

I was not looking for the easy, automatic way, but just any way
mon165 might do it easy enough, but this functionality could easily be added to expdump.

I think even AsmOne can do that on the command line, but it is a long time since I programmed on the Amiga.

Yes but it isn't really worth the trouble. mon does not need any extra libs and works with all KS versions.

The output from expdump with Oktagon 2008 attached to the A500 (using the Grandslam expansion box, to check that interface), gave me start: 00e90000, size: 00010000 (64k).

Thats the board address space and there is chance of hang if you try to dump whole address space (depends on implementation). HD controller IO space needs to be located somewhere.

Usually ROM start is same as exp dump er_InitDiagVec (offset from start of board) and size is either 8k, 16k or 32k.

[peo]

Originally Posted by Toni Wilen

Usually ROM start is same as exp dump er_InitDiagVec (offset from start of board) and size is either 8k, 16k or 32k.

So, for the Oktagon:
BoardAddr : 00e90000
BoardSize : 00010000
er_Type : d1
er_Product : 05
er_Flags : 00
er_Reserved03 : 00
er_Manufacturer : 082c
er_SerialNumber : 00000000
er_InitDiagVec : 0001
{0xd1,0x05,0x00,0x00,0x08,0x2c,0x00,0x00,0x00,0x00,0x00,0x01}

InitDiagVec = 1, this means offset = 0 (and start = BoardAddr) ?
Just crashed (as you said) on dumping 64k from the start address.

Best option could be to try dumping in 8,16,32 etc up to "BoardSize" until crash.

[Toni Wilen]

Strange. Diagvec should be 0100 for Oktagon.

Oktagon also has quite special ROM mapping, it is in two parts with different mapping. It is not a good HD controller for testing ROM dumping.

[peo]

Dumping Oktagon crashed at 8k.. Successfully dumped 4k, but got only (what I think is) garbage.. Have to try with Gransdlam now that I know the tool.

[peo]

Forgot the upload button on the attachment

Grandslam, 32k extracted from offset $8000.

BoardAddr : 00e90000
BoardSize : 00010000
er_Type : d1
er_Product : 34
er_Flags : 00
er_Reserved03 : 00
er_Manufacturer : 0840
er_SerialNumber : 00000000
er_InitDiagVec : 8000
{0xd1,0x34,0x00,0x00,0x08,0x40,0x00,0x00,0x00,0x00,0x80,0x00}

[peo]

Looks like I got nothing than trash in the dump again (nothing ASCII-readable like the 4.9 bootrom grabbed by Stone)

[Toni Wilen]

Originally Posted by peo

Looks like I got nothing than trash in the dump again (nothing ASCII-readable like the 4.9 bootrom grabbed by Stone)

It is valid. Because ROM is 8-bit (and board has only single ROM chip) but bus is 16-bit, only even bytes (byte 0=first rom byte, byte 1=garbage, byte 2=second rom byte and so on) are mapped to ROM chip.

"Unfortunately" your dump is identical to already dumped v4.9.

[Toni Wilen]

Originally Posted by peo

Dumping Oktagon crashed at 8k.. Successfully dumped 4k, but got only (what I think is) garbage.. Have to try with Gransdlam now that I know the tool.

I re-checked Oktagon ROM config, it can't be easily dumped with software because IO and ROM are interleaved. First 2048 bytes are even only ROM data, next comes 4096 byte "pseudo DMA space" (no ROM mapped there, hardware dumped ROM chip has $ff in this space, accessing this space without active transfer will most likely hang the system), then comes remaining 65536-4096-4096 bytes of ROM data, only in odd bytes. Even bytes hit SCSI and EEPROM chips.

$0000-$0fff: 4096 bytes of even only ROM data (2048 ROM total)
$1000-$1fff: don't touch
$2000-$fffff: 57344 bytes of odd only ROM data (28672 ROM bytes)

I can create single ROM image if you dump first and last space. $2000+ space will hit some IO addresses but it shouldn't cause hangs. ROM/IO mapping is rarely as complex as in Oktagon. But it probably is more optimal to check the device version first: "version oktagon.device"

Assuming first board:

] e90000 1000 ram:rom1.bin
] e92000 e000 ram:rom2.bin

btw, Trifecta please, it is the most interesting one

EDIT: Your 4k Oktagon dump after splitting is identical to beginning of 6.12 ROM. But because it is only "loader" part, main rom part can be different.

[peo]

Originally Posted by Toni Wilen

btw, Trifecta please, it is the most interesting one

EDIT: Your 4k Oktagon dump after splitting is identical to beginning of 6.12 ROM. But because it is only "loader" part, main rom part can be different.

"Really soon now"

[peo]

I mean.. really soon

Did two dumps, starting from e90000+10000 and e91000+10000, no crash even with that dumping before InitDiagVec (and maybe overdumping with the start from e91000)

[Toni Wilen]

Thanks! Does the board work? ROM dump can't be valid, same 64-byte pattern repeats 4 times (after splitting odd and even bytes). Perhaps ROM chip or A500 side connector has contact problems.

00001c00h: 00 06 00 BF E0 01 67 F6 20 1F 4E 75 2F 0B 26 6F ; ...¿à.gö .Nu/.&o
00001c10h: 00 08 41 FA 00 08 26 88 26 5F 4E 75 00 24 56 45 ; ..Aú..&ˆ&_Nu.$VE
00001c20h: 52 3A 20 74 72 69 66 65 63 74 61 2E 64 65 76 69 ; R: trifecta.devi
00001c30h: 63 65 20 76 34 2E 33 72 31 00 64 6F 73 2E 6C 69 ; ce v4.3r1.dos.li
00001c40h: 00 06 00 BF E0 01 67 F6 20 1F 4E 75 2F 0B 26 6F ; ...¿à.gö .Nu/.&o
00001c50h: 00 08 41 FA 00 08 26 88 26 5F 4E 75 00 24 56 45 ; ..Aú..&ˆ&_Nu.$VE
00001c60h: 52 3A 20 74 72 69 66 65 63 74 61 2E 64 65 76 69 ; R: trifecta.devi
00001c70h: 63 65 20 76 34 2E 33 72 31 00 64 6F 73 2E 6C 69 ; ce v4.3r1.dos.li
00001c80h: 00 06 00 BF E0 01 67 F6 20 1F 4E 75 2F 0B 26 6F ; ...¿à.gö .Nu/.&o
00001c90h: 00 08 41 FA 00 08 26 88 26 5F 4E 75 00 24 56 45 ; ..Aú..&ˆ&_Nu.$VE
00001ca0h: 52 3A 20 74 72 69 66 65 63 74 61 2E 64 65 76 69 ; R: trifecta.devi
00001cb0h: 63 65 20 76 34 2E 33 72 31 00 64 6F 73 2E 6C 69 ; ce v4.3r1.dos.li
00001cc0h: 00 06 00 BF E0 01 67 F6 20 1F 4E 75 2F 0B 26 6F ; ...¿à.gö .Nu/.&o
00001cd0h: 00 08 41 FA 00 08 26 88 26 5F 4E 75 00 24 56 45 ; ..Aú..&ˆ&_Nu.$VE
00001ce0h: 52 3A 20 74 72 69 66 65 63 74 61 2E 64 65 76 69 ; R: trifecta.devi
00001cf0h: 63 65 20 76 34 2E 33 72 31 00 64 6F 73 2E 6C 69 ; ce v4.3r1.dos.li
00001d00h: 17 7C 00 04 00 08 42 AB 00 0A 93 C9 2C 78 00 04 ; .|....B«..“É,x..
00001d10h: 4E AE FE DA 27 40 00 10 42 2B 00 0E 41 EB 00 14 ; N®þÚ'@..B+..Aë..

[peo]

It works, at least the memory expansion (8MB) passed fully, which makes sure that the side connector is ok.
Might be something with the dump done with the HDD enable switch turned off.. I'll do another dump with the switch in the on-position.

[peo]

Big difference (in compressed file size).. HDD enabled, and I also had to connect one drive to make it past waiting.. Took the drive prepped with TCUtils that I booted on Oktagon as well, boots up fine with the Trifecta.

[Toni Wilen]

Now it looks correct!

00001ce0h: 52 3A 20 74 72 69 66 65 63 74 61 2E 64 65 76 69 ; R: trifecta.devi
00001cf0h: 63 65 20 76 34 2E 33 72 31 00 64 6F 73 2E 6C 69 ; ce v4.3r1.dos.li
00001d00h: 62 72 61 72 79 00 46 69 6C 65 53 79 73 74 65 6D ; brary.FileSystem
00001d10h: 2E 72 65 73 6F 75 72 63 65 00 74 72 69 66 65 63 ; .resource.trifec
00001d20h: 74 61 2E 64 65 76 69 63 65 00 46 61 73 74 46 69 ; ta.device.FastFi
00001d30h: 6C 65 53 79 73 74 65 6D 00 00 65 78 70 61 6E 73 ; leSystem..expans
00001d40h: 69 6F 6E 2E 6C 69 62 72 61 72 79 00 74 69 6D 65 ; ion.library.time
00001d50h: 72 2E 64 65 76 69 63 65 00 00 49 43 44 44 65 76 ; r.device..ICDDev
00001d60h: 54 61 73 6B 00 00 49 43 44 44 65 76 50 72 6F 63 ; Task..ICDDevProc
00001d70h: 00 00 74 72 61 63 6B 64 69 73 6B 2E 64 65 76 69 ; ..trackdisk.devi
00001d80h: 63 65 00 00 44 46 30 3A 00 00 74 72 69 66 65 63 ; ce..DF0:..trifec
00001d90h: 74 61 2E 52 6F 6D 54 61 67 00 49 43 44 20 54 72 ; ta.RomTag.ICD Tr
00001da0h: 69 66 65 63 74 61 20 64 69 73 6B 20 64 65 76 69 ; ifecta disk devi
00001db0h: 63 65 00 00 48 E7 01 12 26 6F 00 10 2E 2F 00 14 ; ce..Hç..&o.../..

First 1024 bytes are hidden "under" IO space which means 100% full dump is only possible with rom reader but it isn't important. Most likely it is filled with $ff's.

I'll upload merged version tomorrow, it is getting late..

[peo]

Pretty fast with that old Seagate Barracuda 2.1GB (ST32550M)..
http://peo.yliniemi.se/amiga/HD/DiskSpeed-Trifecta.txt

[Toni Wilen]

Split ROM image now in the zone expansion rom archive and quick emulation check seems to confirm it is valid (both SCSI and IDE drive is detected, SCSI emulation needs some fixes first before it can boot)

Trifecta SCSI controller is DMA capable which makes test results quite nice, especially CPU usage. IDE is usual PIO.

EDIT: autoboot off switch probably messes up the ROM addressing instead of disabling it. I guess they run out of chip logic space..

[peo]

Oktagon ROM part1 + part2 attached.

Also did the DiskSpeed run on Oktagon, same disk, and FastRAM with Supra 500RX.
(Standard A500, Supra 500RX, Grandslam expansion box, Oktagon 2008, Seagate Barracuda ST32550M)

http://peo.yliniemi.se/amiga/HD/DiskSpeed-Oktagon.txt
(about half the speed of Trifecta)