The Kanji ROM NuBus Card

[Dandu]

I have found a Kanji ROM Card for the Macintosh II, a NuBus card form Japan.

I suppose the card contain Kanji font, like the Macintosh Plus ROM from Japan i have found earlier

I have used SlotsDump to dump the ROM, but the size is only 4 KB. Is there a way to dump the ressources ?

I assume that the card works in the same way as the Macintosh Plus ROM, and that older versions of KanjiTalk load the data from the ROM rather than from a floppy disk, but I only have a Macintosh IIsi and it does not support KanjiTalk 1.0, which is based on System 3.

 

[Arbee]

I have a real full ROM dump of the KanjiTalk NuBus ROM card. I haven't yet committed it to MAME because I have no idea how the ROMs are organized or what software would recognize and use the card. (KanjiTalk versions of System 6 and 7 don't behave any differently when the card is or isn't present that I can tell).

 

[joevt]

I have found a Kanji ROM Card for the Macintosh II, a NuBus card form Japan.

I suppose the card contain Kanji font, like the Macintosh Plus ROM from Japan i have found earlier

I have used SlotsDump to dump the ROM, but the size is only 4 KB. Is there a way to dump the ressources ?

I assume that the card works in the same way as the Macintosh Plus ROM, and that older versions of KanjiTalk load the data from the ROM rather than from a floppy disk, but I only have a Macintosh IIsi and it does not support KanjiTalk 1.0, which is based on System 3.

SlotsDump only grabs the part of the ROM that contains the DeclData.
SlotsGrab was updated to round the size to the nearest power of 2.
You could modify the last commit in my SlotsDump GitHub repository to make SlotsGrab capture 1 MiB or 16 MiB or whatever.
Since the address is FExxxxxx then 16 MiB would be the max size to grab. If the ROM is smaller than 16 MiB, then maybe it will show the ROM as being repeated multiple times?

The slot resources appear to have a 32-bit value that increases with each resource which means it may be an offset in the ROM?
The last offset is 0x90888 which is less than 1MiB so maybe the ROM is 1 MiB max. I would just try 16 MiB to see if it works. Maybe it will be 16 copies of the same ROM.

 

[Dandu]

I have a real full ROM dump of the KanjiTalk NuBus ROM card. I haven't yet committed it to MAME because I have no idea how the ROMs are organized or what software would recognize and use the card. (KanjiTalk versions of System 6 and 7 don't behave any differently when the card is or isn't present that I can tell).

I think it will work with KanjiTalk 1.0 and not with the other

 

[Arbee]

Correct, the ROMs are 1MiB in size (2x 512KiB).

 

[Arbee]

Here. It's 2 16-bit wide chips, so it's likely the data is interleaved to make the 32 bits for NuBus.

 

[joevt]

@Arbee , from your dumps, it appears the 4KiB DeclData is in a separate rom chip (341-0607-A.bin) than the 1MiB data.

Therefore, SlotsGrab should not be used to grab the ROM because the DeclData uses only byte lane 3 while the rest of the memory space may be using all 4 byte lanes (32-bits).

@Dandu , try SlotsMem instead.
https://github.com/joevt/SlotsDump/releases

SlotsMem is an app that grabs the entire 16MiB of the slot memory space from all 4 byte lanes instead of just byte lane 3. Then we can see how the dumps of the ROM chips, 342-0605-A.bin and 342-0608-A.bin, are arranged in the address space.
I have not tested this app since I don't have a NuBus Mac. If there's a problem, then I can try to debug it in emulation.

We know DeclData is 16K at the end of the address space in byte lane 3. Perhaps the other two ROMs are at the beginning of the address space in byte lanes 1,2,3,4.

 

[Arbee]

Correct, the DeclData's a separate EPROM. A SlotsMem dump should show how the data is properly laid out as you said.

 

[Dandu]

I will try, thank you !