Home Page Forums MAME MAME The mystery of the "nodump" Status SARPC ROM

Hi,

sorry for maybe posting a MAME Beginner question here....

How can I understand the nodump Status of SARPC
as listed on: http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=sarpc&search_id=
for SARPC-ROMs:
1203,191-01.bin
1203,192-01.bin
which are listed as 2 MB-ROMs.

Does "NoDump" mean, these ROM Chip exists, but no-one was yet able to dump them?
Are these RiscOS-ROMs or maybe ROMs/Software which are inside the StrongARM-CPU?

btw. These maybe not the correct StrongARM/RiscOS v3.70/v3.71-ROMs which are listed here?!: https://www.marutan.net/rpcemu/manual/romimage.html
/ https://www.4corn.co.uk/aview.php?sPath=/roms
(They are 4*1 MB Size (RiscOS 3.70 for RiscPC StrongARM) or 1*4 MB Size (RiscOS 3.71 for RiscPC StrongARM)).

NO_DUMP means the ROMs are known to exist but haven't been dumped yet. Someone who knows more about that driver would have to say if those are correct.

OK. Thank you for confirmation/explanation.

Shouldn´t MAME complain about NO_DUMP ROMS and display "romset sarpc is best available"

When I yet audit with:
MAME -verfiyroms sarpc
I get:
romset "sarpc" not found!

As e.g. 19in1 which contains a NO_DUMP-ROM:

\MAME>mame -verifyroms 19in1
19in1 : 19in1_eeprom.bin (512 bytes) - NOT FOUND - NO GOOD DUMP KNOWN
romset 19in1 [39in1] is best available
1 romsets found, 1 were OK.

(I have created a SARPC.ZIP which contain the other three SARPC-ROMfiles as lsited here:
\MAME>mame -listroms sarpc
ROMs required for driver "sarpc" (including devices "kb_pcat101", "ps2_keybc").
Name Size Checksum
1203,191-01.bin 2097152 NO GOOD DUMP KNOWN
1203,192-01.bin 2097152 NO GOOD DUMP KNOWN
ef6805u3p-b__1394080.u2 4096 CRC(7d2a52f3) SHA1(ac739dc0408ea0b3be60f85b7a2eb822753a054c)
72x8455.zm82 2048 CRC(7da223d3) SHA1(54c52ff6c6a2310f79b2c7e6d1259be9de868f0e)
128251-001.u3 2048 CRC(da968f1e) SHA1(ac45a4d0f30b046ada300f1d105bcf0fb2db318a)
)

The RiscOS 3.70 roms you mention are available here, and are not even that expensive: http://www.cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=ACO-RO370

They're also available for free download at the site the OP mentioned. Does RiscOS 3.70 exist for multiple hardware types or is there only one? If so, it's the correct ROMs for the driver and we can get rid of the NO_DUMP.

While we're talking about the RiscPC driver, I'd like some eyes on whether or not the default BIOS (3.71) is actually a good dump.

As it is currently, the first instruction it executes does a R15-relative load of R15, fetching the value 0x224 from address 0x118 in ROM, and thereby branching to that address.

In the current dump of 3.71 that MAME has, that location is just a table containing 0xF0000000 masked with rightward-walking bits, followed by the corresponding inversions, as depicted (partially) here:



The first valid code appears to be at 0x30C, which it eventually runs to by what looks like blind chance.

RiscOS 4.02 (-bios 1) meanwhile does the same fetch from address 0x118, but in that case the value it fetches is 0x117EC, which contains definitively valid code.

I only ran across this while trying to diagnose why a7000p regressed as a result of my MMU/TLB-related changes back in October of last year, but at this point I'm more or less convinced that the a7000p driver with the default BIOS (RiscOS 3.71) only showed its boot text by pure chance, and not out of any prior validity before my changes.

I've checked my 3.71 dump against the rom in the Acorn Classic Rom collection and they are identical, so the dump should be good.

Given that, how does the ROM behave in the version where it did display boot text? Does it somehow fall out of that walking bits pattern into real code?

The RiscOS 3.50 and RiscOS 3.60 dumps have the same issue with a table at 00000224 instead of executable-looking code. I can't tell what exactly is going on here, since these dumps also contain code that jumps to 00000224 from either 00000080 or 000000E0.

Do any of the non-MAME emulators that these dumps run correctly in have a debugger?