Mac IIci MDU / RBV registers

[Guy Madison]

I am tinkering with a Mac IIci emulator of my own for ROM modifications, does anyone know the mappings of the MDU and RBV registers?

At boot I see reads of the boot vector followed by a curious write to rom, which looks like its tweaking some control registers. Since the next thing it does is start scanning DRAM memory my guess is its the DRAM controller mappings.

post_rom_read_memory_32: 0x00000000 -> offset: 0x00000000 0x368CADFE
post_rom_read_memory_32: 0x00000004 -> offset: 0x00000004 0x4080002A
post_rom_read_memory_16: 0x4080002A -> offset: 0x0000002A 0x00004EFA
rom_read_memory_16: 0x4080002C -> offset: 0x0000002C 0x00000060
rom_read_memory_16: 0x4080008C -> offset: 0x0000008C 0x000046FC
rom_read_memory_16: 0x4080008E -> offset: 0x0000008E 0x00002700
rom_read_memory_16: 0x40800090 -> offset: 0x00000090 0x00004E70
rom_read_memory_16: 0x40800092 -> offset: 0x00000092 0x0000203C
rom_read_memory_32: 0x40800094 -> offset: 0x00000094 0x00002000
rom_read_memory_16: 0x40800098 -> offset: 0x00000098 0x00004E7B
rom_write_memory_16: 0x368CADFC 0x00000010 <----------------- DRAM controller ?
rom_write_memory_32: 0x368CADF8 0x40800098 <----------------- DRAM controller ?
rom_write_memory_16: 0x368CADF6 0x00002700 <----------------- DRAM controller ?
dram_read_memory_32: 0x00000010 -> offset: 0x00000010 0x00000000
dram_read_memory_16: 0x00000000 -> offset: 0x00000000 0x00000000
dram_read_memory_16: 0x00000002 -> offset: 0x00000002 0x00000000
dram_read_memory_16: 0x00000004 -> offset: 0x00000004 0x00000000

I would assume someone has figured out what the Mac IIci rom is doing at this point.. if there is a disassembly of this available that would be great.

Thanks ahead of time.

 

[zigzagjoe]

I am tinkering with a Mac IIci emulator of my own for ROM modifications, does anyone know the mappings of the MDU and RBV registers?

At boot I see reads of the boot vector followed by a curious write to rom, which looks like its tweaking some control registers. Since the next thing it does is start scanning DRAM memory my guess is its the DRAM controller mappings.

post_rom_read_memory_32: 0x00000000 -> offset: 0x00000000 0x368CADFE
post_rom_read_memory_32: 0x00000004 -> offset: 0x00000004 0x4080002A
post_rom_read_memory_16: 0x4080002A -> offset: 0x0000002A 0x00004EFA
rom_read_memory_16: 0x4080002C -> offset: 0x0000002C 0x00000060
rom_read_memory_16: 0x4080008C -> offset: 0x0000008C 0x000046FC
rom_read_memory_16: 0x4080008E -> offset: 0x0000008E 0x00002700
rom_read_memory_16: 0x40800090 -> offset: 0x00000090 0x00004E70
rom_read_memory_16: 0x40800092 -> offset: 0x00000092 0x0000203C
rom_read_memory_32: 0x40800094 -> offset: 0x00000094 0x00002000
rom_read_memory_16: 0x40800098 -> offset: 0x00000098 0x00004E7B
rom_write_memory_16: 0x368CADFC 0x00000010 <----------------- DRAM controller ?
rom_write_memory_32: 0x368CADF8 0x40800098 <----------------- DRAM controller ?
rom_write_memory_16: 0x368CADF6 0x00002700 <----------------- DRAM controller ?
dram_read_memory_32: 0x00000010 -> offset: 0x00000010 0x00000000
dram_read_memory_16: 0x00000000 -> offset: 0x00000000 0x00000000
dram_read_memory_16: 0x00000002 -> offset: 0x00000002 0x00000000
dram_read_memory_16: 0x00000004 -> offset: 0x00000004 0x00000000

I would assume someone has figured out what the Mac IIci rom is doing at this point.. if there is a disassembly of this available that would be great.

Thanks ahead of time.

See page 184 onwards of the Blue Book vol2. Pretty sure there's another source that treats the RBV/MDU in more detail, but I can't recall it.
You might also find the supermario source interesting reading: https://github.com/elliotnunn/sys7.1-doc-wip/

 

[Arbee]

ROM writes are common at Apple to trigger breakpoints on hardware debuggers. The IIgs source leak actually included a list of what writes map to what breakpoints, but we weren't so lucky for the Mac.

The MDU/RBV registers are all in the I/O space, not the ROM. There's some info in Guide to the Maicntosh Family Hardware.

See also my implementation:

mame/src/mame/apple/maciici.cpp at master · mamedev/mame

MAME. Contribute to mamedev/mame development by creating an account on GitHub.

github.com

mame/src/mame/apple/rbv.cpp at master · mamedev/mame

MAME. Contribute to mamedev/mame development by creating an account on GitHub.

github.com

mame/src/mame/apple/pseudovia.cpp at master · mamedev/mame

MAME. Contribute to mamedev/mame development by creating an account on GitHub.

github.com

You can see what the ROM's doing in great detail by just running the "maciici" machine in MAME with the -debug switch.

 

[Guy Madison]

Ok great, thanks for the heads up. I was looking at the MAME stuff and thought I would just integrate what I needed as I figured it out.

I am looking for this... MDU User Manual, Michael Dhuey, June 1988.. its not in the blue book.

I use the same 68k emulator as MAME does, Musashi its all in C and while MAME works... man its all in C++ and you have to build all of it, and what would I learn if I just used MAME.

I was at Apple in CoreGraphics when we ported QuickDraw to Carbon, that may be interesting work to be done also.

 

[Arbee]

You actually can build just one driver or just one manufacturer's machines in MAME, but I do understand.

You *can* learn a lot using MAME though, our debugger to use on the emulated systems is crazy powerful.

Try these.

 

[zigzagjoe]

You actually can build just one driver or just one manufacturer's machines in MAME, but I do understand.

You *can* learn a lot using MAME though, our debugger to use on the emulated systems is crazy powerful.

Try these.

Do you have a doc for the GLUE chip? I've noticed on the two LBs I've tested it doesn't qualify /ROMOE with /AS; curious if that's by intention or not.

 

[Guy Madison]

You actually can build just one driver or just one manufacturer's machines in MAME, but I do understand.

You *can* learn a lot using MAME though, our debugger to use on the emulated systems is crazy powerful.

Try these.

Thank you for the attached files.

 

[Guy Madison]

I am just hacking my way through it, hell I am retired.. what else do I have to do all day.

 

[Guy Madison]

I have so far built a facility to trace the execution, dump the assembly and all the memory ops to go with it.. I will put it up on Github at some point.

 

[Arbee]

Do you have a doc for the GLUE chip? I've noticed on the two LBs I've tested it doesn't qualify /ROMOE with /AS; curious if that's by intention or not.

The IIci's GLUE chip? No, I don't.

 

[zigzagjoe]

The IIci's GLUE chip? No, I don't.

Ah, no, the GLUE chip used in Mac II/IIx/IIcx/SE30. Address decode/glue logic + DRAM controller. PN# 344S0602

 

[Arbee]

Ahh, no, don't have anything on that.

 

[zigzagjoe]

Ahh, no, don't have anything on that.

Ah well! Appreciate you looking. Just found that behavior odd as it leads to the ROM becoming active during indeterminate states between bus cycles, very odd...