CD32 ROM (KS + extended) REAL DUMP

[pucci]

this roms have part number 391640-03
the MAME cd32 bios have this name: 391640-03.u6a
but the CRC are different:
d3837ae4 (MAME)
a4fbc94a (WINUae)

why?

[Toni Wilen]

WinUAE checksum is from real CD32 ROM (this is rare). KS and extended parts are interleaved, not just appended.

[pucci]

what type of interleaved is used?

i tried with this two roms:
- CD32 ROM (KS + extended) (from WINUAE bios)
- 391640-03.u6a (from MAME cd32 bios)

1) split original roms in two parts: ORIGINAL -> A + B
2) interleaved mixing (using mix2.exe) of A + B = C
3) interleaved mixing (using mix2.exe) of B + A = D

neither C or D are correct

[Toni Wilen]

It is different than normal interleave:

A = KS ROM
B = EXT ROM

byte 1 of A
byte 0 of A
byte 1 of B
byte 0 of B
byte 3 of A
byte 2 of A
byte 3 of B
...

[pucci]

i tried with the utility INTERL.EXE (found on this forum) that does the correct interleave.

i test it with two dummy file:
FILE1 -> 0A 1A 2A 3A
FILE2 -> 0B 1B 2B 3B
INTERL FILE1 FILE2 FILE3
FILE3 -> 1A 0A 1B 0B 3A 2A 3B 2B

so i think that INTERL.EXE is the right tool

but INTERL "CD32 KS ROM v3.1 (1e62d4a5)" "CD32 extended ROM (87746be2" "CD32 ROM (KS + extended) REAL DUMP"
give me a wrong CRC32 (c9da5a71 instead of a4fbc94a)

[Toni Wilen]

What if you switch ROMs? (EXT first and then KS)

[pucci]

first (trivial) discovery

CD32 ROM (KS + extended) (CRC32 f5d4f3c8) [taken from winuae recognized bios - ID 64]
and
391640-03.u6a rom (CRC32 d3837ae4) [taken from MAME CD32 bios]

are the same roms with half split parts inverted

CD32 ROM (KS + extended) first half --> CRC32 87746be2
CD32 ROM (KS + extended) second half --> CRC32 1e62d4a5

391640-03.u6a first half --> CRC32 1e62d4a5
391640-03.u6a second half --> CRC32 87746be2

and winuae recognized bios
CD32 KS ROM v3.1 [ID 18] --> CRC32 1e62d4a5
CD32 extended ROM [ID 19] --> CRC32 87746be2
have the same CRC32 of half parts of the two roms above (391640-03.u6a and CD32 ROM (KS + extended))

if i try this:

INTERL "CD32 ROM (KS + extended) first half" "CD32 ROM (KS + extended) second half" result
result CRC32 is 4bbf6acc

and if i try this:

INTERL "CD32 ROM (KS + extended) second half" "CD32 ROM (KS + extended) fisrt half" result
result CRC32 is c9da5a71

the correct CRC32 for CD32 ROM (KS + extended) REAL DUMP is a4fbc94a

maybe the problem is with INTERL? i think it use byte of 16 bits, maybe i must try an interleaving with byte of 8 bits?

[pucci]

no clue to solve this problem?

[pucci]

Originally Posted by Toni Wilen

It is different than normal interleave:

A = KS ROM
B = EXT ROM

byte 1 of A
byte 0 of A
byte 1 of B
byte 0 of B
byte 3 of A
byte 2 of A
byte 3 of B
...

can INTRL.EXE do this interleaving? YES









so, let's try with real CD32 Roms



CD32 KS ROM v3.1 - CRC32 1E62D4A5



CD32 extended ROM - CRC32 87746BE2



INTERL CD32 KS ROM v3.1 + CD32 extended ROM



Bad checksum: i got C9DA5A71 instead of A4FBC94A



INTERL CD32 extended ROM + CD32 KS ROM v3.1



Bad checksum: i got 4BBF6ACC instead of A4FBC94A



CD32 ROM (KS + extended) REAL DUMP definition taken from WinUAE source

so i think that this

A = KS ROM
B = EXT ROM

byte 1 of A
byte 0 of A
byte 1 of B
byte 0 of B
byte 3 of A
byte 2 of A
byte 3 of B

is not the correct interleave

[Toni Wilen]

Your program isn't interleaving correctly. Check your screenshots, they show duplicate pairs (1411 1411 F94E F94E..)

Correct first 16 bytes:

14 11 F8 00 00 00 28 00 FC 4A 10 00 6A 01 31 08

[pucci]

Originally Posted by Toni Wilen

Your program isn't interleaving correctly. Check your screenshots, they show duplicate pairs (1411 1411 F94E F94E..)

Correct first 16 bytes:

14 11 F8 00 00 00 28 00 FC 4A 10 00 6A 01 31 08

you said that correct interleaving is:

A = KS ROM
B = EXT ROM

byte 1 of A
byte 0 of A
byte 1 of B
byte 0 of B
byte 3 of A
byte 2 of A
byte 3 of B

byte 1 of KS ROM --> 14
byte 0 of KS ROM --> 11
byte 1 of EXT ROM --> 14
byte 0 of EXT ROM --> 11
byte 3 of KS ROM --> F9
byte 2 of KS ROM --> 4E
byte 3 of EXT ROM --> F9
byte 2 of EXT ROM --> 4E

RESULT: 14 11 14 11 F9 4E F9 4E

if you see image above, the INTERL does the correct interleaving as you said because first 7 bytes of CD32 KS ROM v3.1 and CD32 extended ROM are eguals (and so it's normal that result have duplicate pairs)

the correct first 16 bytes that you reported is:

14 - byte 1 of B
11 - byte 0 of B
F8 - byte 5 of B
00 - byte 4 of B
00 - byte 9 of B
00 - byte 8 of B
28 - byte 13 of B
00 - byte 12 of B
FC - byte 17 of B
4A - byte 16 of B
10 - byte 21 of B
00 - byte 20 of B
6A - byte 25 of B
01 - byte 24 of B
31 - byte 29 of B
08 - byte 28 of B

so i think that this is the correct interleaving:

all first 16 bytes are taken from file B (CD32 extended ROM) in this sequence: 1 0 5 4 9 8 13 12 17 16 21 20 25 24 29 28
in other shape:
FOR x=0 TO ... DO takebyte(1+x*4) takebyte(0+x*4)

now, when first 262144 bytes are taken from file B, how the seguence goes on?
- same sequence form file A?
- remaining bytes form file B?
...

[Toni Wilen]

I guess I misunderstood or explained badly or something (This is very uninteresting topic, why do you need to create this ROM image?)

Above was DeInterleave method (algorithm that WinUAE uses to create "normal" 2x internal ROM images from official CD32 ROM image)

[pucci]

Thanks for the info Toni, in the meantime i solved the mistery by myself:

take CD32 extended ROM and do this:
FOR x=0 TO 65535 DO takebyte((x*4)+1) takebyte((x*4)+0)
the result is file A

take CD32 KS ROM v3.1 and do this:
FOR x=0 TO 65535 DO takebyte((x*4)+1) takebyte((x*4)+0)
the result is file B

take CD32 extended ROM and do this:
FOR x=0 TO 65535 DO takebyte((x*4)+3) takebyte((x*4)+2)
the result is file C

take CD32 KS ROM v3.1 and do this:
FOR x=0 TO 65535 DO takebyte((x*4)+3) takebyte((x*4)+2)
the result is file D

binary copy A+B+C+D and the result is REAL CD32 Rom dump

i put in The Zone! a zip file (REAL_CD32_CONVERTER.ZIP) that automates the process (you must only supply plain CD32 rom named as "CD32.ROM" and you will get "CD32REAL.ROM")

Thanks again for the info and for the help, i think that all topic are interesting if they help to better understand the operation of the emulator or real Amiga hardware

Hi, can the file REAL_CD32_CONVERTER.ZIP be attached to this thread or re-uploaded to the Zone?

EDIT: Nevermind, found it!

[pucci]

Originally Posted by draxx

Hi, can the file REAL_CD32_CONVERTER.ZIP be attached to this thread or re-uploaded to the Zone?

EDIT: Nevermind, found it!

where do you found?

[digiflip]

has anyone using this tool mentioned in thread made a custom cd32 3.1.4 rom?

[quantum8]

I asked this question on other forums but no-one seemed interested as apparently 3.1.4 removed support for C2P routines or something along those lines.

[midimax]

3.1.4 does (unfortunately) not support CD32 first of all.

[reinauer]

Thanks to LIV2, this srec_cat call produces the right image:

srec_cat Kick31.rom -Binary -Byte_Swap -Split 4 0 2 -Offset 0x40000 \
Kick31.rom -Binary -Byte_Swap -Split 4 2 2 -Offset 0xC0000 \
Extended.rom -Binary -Byte_Swap -Split 4 0 2 -Offset 0x00000 \
Extended.rom -Binary -Byte_Swap -Split 4 2 2 -Offset 0x80000 \
-Output KS31_CD32.rom -Binary

[RoC]

Yesterday I decided to test the KS 3.2 on the CD32. So far, no success on the real hardware, but it works on WinUAE. I am fully aware this approach is not supported, therefore consider this as a kind of test

These are the findings, in case they could be somehow useful:

- With the new Remus, started from the A1200 KS32 modules and replaced the exec with the one on the CD32's adf. I am not sure whether there are other modules to be added/replaced.
- Combined the above 512KB with the 512KB CD32 3.1 extended rom.
- The LIV2 script that reinauer posted works just fine. Thanks. I downloaded the Windows 10 flavour of the srec_cat and removed the back-slashes
- I later noticed that the Eprom Tool v 0.90 includes a juicy "Create Amiga CD32 rom" which performs the same with a couple of clicks. In my case, both approaches returned a 1MB rom with CRC 65DE0458.

The 1MB CD32 KS 3.2 works on WinUAE. I pointed WinUAE to that as a single 1MB rom without extended one. It shows the CD32 splash screen and then boot to the Workbench 3.2. I didn't test more than that, so there might be something else not working.

The problem is now to burn the physical rom. It seems to me that the rom should be divided in half (I mean not ODD and EVEN) and then these two half should be byte-swapped before burning them on the 27C800 respectivelly as bank #0 and bank #1. However this does not work. I don't really know what the usual "HI/LO split" does so I am going to investigate. Will test more in the coming days and possibly try HxD to manually cut in half.

Edit #1:

Physical kickstart shows the splash screen :-) It doesn’t require an additional byteswap and the two banks have to be exchanged from what the tool proposes. Now it doesn’t boot the TF330, so investigating what else is required (beside cd32 exec) in Remus.

Edit #2:
For the record, I managed to make it work on the CD32 with the TF. Apparently, the problem was to create the extended one with Remus as well ( I was using the original 40.60 before).