Gameboy Development Forum

Been doing a lot of work on this lately; I had been putting findings in here but I'm not just editing the first post instead.

Last edited by endrift (2022-02-04 05:29:13)

I’ve been mucking around with this, and I think it actually makes a fair bit of sense if you think about how the silicon underneath likely works.

First, some observations:
• The HuC-3 controller is only connected to A15-A13 and D6-D0.  Addresses are effectively masked with 0xE000 and data is effectively masked with 0x7F.  Anything written in the most significant bit is ignored by the HuC-3 controller, and it always reads floating bus (generally high).
• This is a conventional setup where the ROM and RAM chips have their data lines and low address lines connected directly to the cartridge bus.  It’s not like the MAC-GBD in the Pocket Camera where data and addresses are routed through logic inside the controller.
• HuC-3 pins 2, 3 and 4 are run out to the hex inverter U5 which drives the audio transducer via a resistor ladder.  This means it can produce eight levels.  Not bad – that’s two whole bits more than the TAMA6 chip has.
• I strongly suspect that if you decapsulated the HuC-3 chip, you’d find that the real-time clock and tone generator functionality are implemented using a 4-bit microcontroller rather than a dedicated real-time clock.
• Timekeeping is likely accomplished just by counting cycles.  The “Watch” part of Nintendo’s Game & Watch line works like this – everything’s done using a 4-bit microcontroller (Sharp SM5A, SM510, SM511 or SM512) with no dedicated real-time clock hardware.  This would explain why it uses minute-of-day and day counters rather than DHMS registers: tt’s easier to do it that way on a microcontroller.
• The “registers” accessible to the host are likely just a window into the microcontroller’s memory.  Consider that the Capcom QSound™ DSP (used for CPS-2, CPS-2, ZN-1 and ZN-2) works this way: it’s an AT&T DSP16 with internal program ROM, and the “registers” written by the host CPU are just the first 256 words of its internal RAM (this is why the sample bank, sound stage position and reverb contribution registers are at unintuitive offsets – it simplifies the DSP program to organise them like that).

With this in mind, the host interface to the microcontroller makes sense:
• The data written to 0x0B is conceptually two values: a 3-bit command in bits 6-4, and a four-bit operand in bits 3-0 (bit 7 is black-holed).
• The data read from 0x0C is conceptually two values: the same 3-bit command in bits 6-4, and a four-bit response in bits 3-0 (bit 7 is floating).
• The command doesn’t so much “leak” from 0xB to 0xC, you’re just seeing the same register.
• Writing 0xB and reading 0xC has no direct side effects.  It just sets or gets the data in the mailboxes.
• Bit 0 of 0xD is a semaphore.  It’s set (1) when the microcontroller is ready to execute a command.  The host clears it (writes 0) to request that the microcontroller execute the command written to 0xB.  The microcontroller detects this, executes the command, possibly sets the response that can be read in bits 3-0 of 0xC, and then sets the semaphore to indicate that it’s ready for another command.

With this in mind, the host program behaviour makes sense:
• Select 0xD (semaphore).
• Wait until bit 0 is set (microcontrolller ready for command).
• Select 0xB (command/operand).
• Write command (high nybble) and operand (low nybble), e.g. 0x62 for command 0x6, operand 0x2.
• Select 0xD (semaphore).
• Write 0xFE, clearing the semaphore so the microcontroller will execute the command.
• Wait until bit 0 is set again (command completed).
• Select 0x0C (command/result).
• Read result/command and use result value from from low nybble.

There are eight possible commands.  We definitely know what five of them do:
• 0x1: Read register and increment address.
• 0x3: Write register and increment address.
• 0x4: Set register address low nybble.
• 0x5: Set register address high nybble.
• 0x6: Execute extended command specified by parameter.

Commands 0x0, 0x2 and 0x7 are unknown.

We definitely know what four of the sixteen possible extended commands do:
• 0x0: Atomically copy real-time clock counters to registers 0-6.
• 0x1: Atomically copy registers 0-6 to real-time clock counters.
• 0x2: Some kind of status request – host software expects response 0x1.
• 0xE: Used to trigger tone generator.

Of course, working out what all the “registers” do is the hard part.  Given it’s likely using a microcontroller core, all kinds of behaviours could be programmed in.

Last edited by cuavas (2022-09-13 02:34:48)

I suspected that there was indeed a microcontroller in there, given how complex this mapper operates. The semaphore makes a bit of sense here, I observed it took some (undeterminable) amount time before it ended up being set again, and if I did not actually wait I did not get expected behavior (I called this the "busy" bit). I would dare believe too the microcontroller has different internal ROMs on different games. I wasn't able to trigger "bing bong" sound that Robopon sometimes plays using my Pocket Family GB2 cartridge. I also see Pocket Family GB2 using different registers for the alarm compared to Robopon. The RTC regs appear to stay static anyways, possibly due to the RTC latching command.

On another note on Pocket Family GB2, it executes command "0x20", some time at bootup. I'm not sure what this does, and seems to be exclusive to Pocket Family GB2? May be again hinting at different internal roms (where that does something in Pocket Family GB2, but not Robopon).

cuavas wrote:

Timekeeping is likely accomplished just by counting cycles.  The “Watch” part of Nintendo’s Game & Watch line works like this – everything’s done using a 4-bit microcontroller (Sharp SM5A, SM510, SM511 or SM512) with no dedicated real-time clock hardware.  This would explain why it uses minute-of-day and day counters rather than DHMS registers: tt’s easier to do it that way on a microcontroller.

This would be interesting, and I suppose would just mean the crystal connected to the mapper is just for all its operation rather than just the RTC. I could suspect that's why it was seemingly random how much time it took for the busy bit to go high anyways, due to the nature of my cart swapping and it would start poking the mapper at a random point in time. Suppose it's in some loop constantly checking the busy bit to determine if to execute the command and where in that loop it is currently at determines how much time it takes until it goes high again?

Last edited by CasualPokePlayer (2022-09-17 07:27:47)

https://gbhwdb.gekkio.fi/cartridges/huc3.html

gekkio has some HuC3 carts listed here, which all show only a date code and the letter A on the HuC3 chip. Unsure what A could even be if it's just on all carts, maybe marking a hardware revision with the chip but the early revision never actually shipped (or just very rare if it did ship)?

Last edited by CasualPokePlayer (2022-09-17 07:33:34)