CPU parts

[msinger]

Hey, I noticed you tried to identify the CPU parts. Just wanted to give you my thoughts on that. Of course I could be wrong, but I strongly believe that the part in the upper left, that you suspect to be the sequencer, is actually the 4-bit ALU. It looks like it is made out of four similar vertical slices, one for each bit. The slices can't be perfectly identical because of the 0x66 and 0x99 comparators that may be in there for the DAA instruction. It also looks similar like the ALU in the Z80, but since it misses some functionality, like parity flag and stuff, it just looks similar, not identical. I suspect that they route simple register-to-memory LD instructions through the ALU as well, because the result at the top of the ALU is very close to the external data bus tri-state buffers. This would mean that the internal data bus(es) are organized a bit different compared to the Z80.

The sequencer logic could be in the top right, that you labeled "WTF?".

The bottom part are the register banks and most likely also a 16-bit incrementer/decrementer for PC and SP addresses, which can output it's result to the address lines to the right of the register bank. Contrary to some believe out there in the internet, I don't think that they have a 16-bit adder that can add anything else than +1 and -1 to an address. The required clock cycles needed by 16-bit ADD instructions are long enough so that those additions can be serialized through the regular 4-bit ALU. I've already implemented the CPU in that way and it works out well.

I'm very excited about your project and that we might finally have some schematics for the CPU soon. And I'd like to figure out if my assumptions described above are correct. I dreamed of this for soooo long. :)

[ogamespec]

Thanks for the great description of the ports! And for those notes :)

Yes, I'm beginning to suspect that the Sequencer is right-top, since that's where the `Wakeup' signal comes in.

I need to untangle more wires, which is what I'm doing now. :D

[msinger]

The labels used in my CPU port list come from Furrtek's schematic. I haven't updated them yet on that page, but we (Régis and I) have used more descriptive labels on the CPU symbol on page 3 in our schematics here (or I should say Régis' schematics, he did all of the work; I just reviewed it):
http://iceboy.a-singer.de/doc/dmg_cpu_b_sch.pdf

For the clock inputs we are not sure yet, if those names make sense. The others you could update in your netlist picture. They make more sense than "FROM_CPU5".

[msinger]

Hey @ogamespec ,
I know the answer to this:

Why SM83?
I don't know, everyone calls the DMG CPU core the SM83 and so do we.

There is a manual from Sharp:
https://archive.org/details/1996_Sharp_Microcomputer_Data_Book/page/n147/mode/2up
On page 148 of this PDF (or page 140 if you look at the original page numbers of the scan), it describes four microcomputers (SM8311, SM8313, SM8314 and SM8315). They all contain a CPU core that is labeled "SM83CPU" in the diagram on the next few pages, which has exactly the same instruction set and the same timings that the Game Boy CPU has. That is why we call the Game Boy CPU "SM83". It seems to be the official name from Sharp for this core. I think @Gekkio found this originally, but I'm not sure. Before we knew about this document, most people called the CPU "LR35902", because this was the label that was printed on the first batch of the rev. 0 chips. It seems to be that LR35902 is the name of the SoC as a whole, and SM83 is the name of the CPU core that was used inside. But I think we can't be 100% sure that they really called this CPU SM83 back in 1989, or if they retroactively labeled it that when they reused it for those microcomputers in this 1996 data book.

Another thing: I thought this could be helpful for understanding the ALU, if it is actually similar to the Z80's, which I don't know for sure:
http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html
https://github.com/gdevic/A-Z80

I'm trying to recreate the layout for all the cells:
http://iceboy.a-singer.de/doc/dmg_cells.html
I just finished the SRAM blocks. But I'm still struggling with the IO pads at the border. There are those huge winding metal structures that I suspect to be ESD protection diodes, but on one side of those suspected diodes I always see one additional faint edge in the background that I can't really make sense of with my naive understanding how a diode might be implemented in this technology. Also, for the input pads, there must be a trace on the active/doped layer behind the metal, that I can't see. So, I don't know if there is still something left of your DMG chip. And I don't know how much work that would be. If it is not too much trouble to snap a few pictures from some of the IO pads, I would really much appreciate that. What also concerns me is the unbonded input pad at the top, which is directly connected to the CPU core. I wonder if there is a pull-up resistor inside, so that it is not floating all the time. It's not that important of course, I just would like to know for completeness sake. So only if you have time for that.

[ogamespec]

Hello again 😃

There is a manual from Sharp..

Great, I'll add those findings to the Readme :)

...understanding the ALU...

According to the description the original Z80 uses a 4-bit ALU. What I see in the SM83 doesn't really look like a 4-bit "calculator" because its input and output are 8-bit values. I have a little bit left to put it in the simulation.

...snap a few pictures from some of the IO pads...

I'll see what's left of the chip :) If possible, it would be good to mark on the "locator" the places where you are interested in seeing the poly. I don't know if I have the patience to take pictures of the whole chip (about 800 shots), but I can do some small places :)

[msinger]

Ok, even if it is an 8 bit ALU, the way the bits are handled each on their own could still have some similarities. Just a thought. :)

What I'm interested in is this trace on the right side of the RST IO for example, I marked it with a red arrow:
http://iceboy.a-singer.de/dmg_cpu_b_map/?wires=0&view=line[]&line[0]=-143.75,249.52,-143.75,248.89,-147.08,248.89,-147.08,247.86&line[1]=-146.31,251.06,-145.25,249.28,-145.06,250.03,-145.27,249.30,-146.09,249.42&line[2]=-146.64,240.80,-146.64,242.83,-148.08,242.83,-148.08,247.23,-149.58,247.23,-149.58,246.59&line[3]=-148.11,245.91,-143.63,245.91&mark[0]=-147.09,247.91
It ends under the metal stuff where I placed the blue marker. It somehow has to be connected to the other structure that I marked with red lines, that is connected to the input of the CMOS inverter on the far left side of the cell. You can see poly layer going on on the left side, right before the inverter's input. So poly is visible under the metal. But the trace on the right, that I'm interested in, is not visible. So I think it's not poly, but n- or p-doped instead.
The stuff around the border of this cell, with the huge amount of vias, I believe are diodes for protection. There are many fine edges around them, which I don't fully understand which ones may be poly and which ones may be doped areas.

Then other IOs, like SIN for example, have this windings that are partially hidden, which I would like to see:
http://iceboy.a-singer.de/dmg_cpu_b_map/?wires=0&view=mark[0]&mark[0]=-169.36,240.50
Maybe those are pull-ups?

I haven't tried to figure out this oscillator circuit yet, so I don't know how hard it would be, but having a better shot of it could definitely help:
http://iceboy.a-singer.de/dmg_cpu_b_map/?wires=0&view=mark[0]&mark[0]=-118.84,240.72
The SCK IO also has a bit more complicated logic and I don't know why yet:
http://iceboy.a-singer.de/dmg_cpu_b_map/?wires=0&view=mark[0]&mark[0]=-178.22,239.53

Then there are cells that must be connected to each other, but I can't see a trace between them:
http://iceboy.a-singer.de/dmg_cpu_b_map/?wires=0&view=-109.77,172.16,-107.13,174.58&line[0]=-109.42,173.66,-109.55,173.66,-109.55,173.50,-109.42,173.50&line[1]=-109.41,173.15,-109.55,173.15,-109.55,172.99,-109.42,172.99&line[2]=-109.42,172.81,-109.56,172.81,-109.56,172.63,-109.42,172.63
I indicated these invisible connections with those small red U-shaped lines below the cells.
And here:
http://iceboy.a-singer.de/dmg_cpu_b_map/?wires=1&view=-161.62,143.70,-158.64,149.30
They are already marked with yellow wires that can be switched on and off in the menu in the top right corner.

And the last point of interest (my interest at least) are those spare cells here:
http://iceboy.a-singer.de/dmg_cpu_b_map/?wires=0&view=mark[0]&mark[0]=-82.56,153.63
Of course they don't do anything, but they are unique. They are not used anywhere else on the chip, so I have no clue what function they would have if they were properly connected somewhere. It's just curiosity.

Thanks, and again, only if it doesn't bother you too much. I'll take everything I can get. :)

[ogamespec]

Hi!

I plan to be in my lab the other day. The thing about all these places on the right side of the SoC is good, because I definitely remember that the top pads are ground to "meat" (they are above the SM83 core).

Regarding the ALU: I found out for sure that the SM83 uses a regular 8-bit CLA Adder. Those strange structures on top of the ALU, similar to heat sinks, are just CLA generators.

[msinger]

I noticed, the description about STOP mode, that you have copied from the 1996 Sharp Databook into sm83.md is not true for Game Boy.

STOP mode on Game Boy disables the external crystal and the device is fully un-clocked. (The only exception can be the serial port, if it was put into slave mode. Then it can get a clock from the master device on the SCK pin.)

Disabling of the external crystal oscillator is done by CPU pin T14. It is connected directly to the CK1 and CK2 pins.

Therefore STOP mode can't be exited by timer interrupts. It can also not be exited by serial port, even though it can be externally clocked in slave mode. It can only be exited by joypad interrupt, when someone presses a button.
If neither of the button matrix output pins P14 or P15 is driven low before entering STOP mode, then the device will never wake up and has to be switched off and on again.

I also did quite some testing on that. So it is not just theory. The crystal really is dead during STOP mode.

About the IF register: Have you found any remnants of that? If not, then I would say, it was never there in the first place. I think Sharp has drawn it into the overview diagram of the CPU just for simplicity. In the Game Boy, this register is external to the CPU. You can find it on page 10 of our schematic, mapped onto address FF0F.

In the top left corner of page 7 you can see the CPU_WAKEUP signal, which wakes the CPU from STOP mode. It is basically just OR'ing the four button pins P10-P13 together. The latch (AWOB) is always enabled (in transparent/bypass mode), when clocks are disabled. So BOGA_1MHz must be high in STOP mode; you can verify that at the top of page 6, by following BOGA_1MHz back to OSC_ENA. If OSC_ENA (CPU T14) is low, then BOGA is always high. There is nothing else that goes into CPU_WAKEUP, which could possibly wake the system up.

[ogamespec]

About the IF register: Have you found any remnants of that? If not, then I would say, it was never there in the first place. I think Sharp has drawn it into the overview diagram of the CPU just for simplicity.

Yes, I found the IF. It's just used as a memory cell for the Priority Encoder circuit.

On STOP Mode, I think I'll just supplement the section with your remarks, if you don't mind :)

[ogamespec]

I will add here all the finds on the bottom I wrote about in Discord on the gbdev server.

• SP and PC registers do not contain an incrementer/decrementer inside. They load a value onto dedicated Inc/Dec beforehand, increment/decrement there, and the result is put back onto SP/PC again.
• Also the bottom part contains two 8-bit registers (I called them TempLo/TempHi) for storing intermediate results.
• Only the IE register ($FFFF) is programmatically accessible. The IF register is used internally and is not accessible in any way.
• The "Thingy" circuit is just used to control the increment/decrement.
• "Inc/Dec" seems to be a generalized incrementer/decrementer which is simultaneously used as an address bus tristate. It also seems to be used for INC/DEC opcodes (bypassing ALU).
• There's nothing else of interest there. Small logic for connecting registers and buses, which is now called "DataPath" in modern design.

[msinger]

Interesting. So the Inc/Dec seems to be similar to the Z80. The incremented value can be driven directly onto the address bus. Did I understand this correctly?
Is the address for the IE register fully hardcoded, or can part of it be influenced by external signals?
The hidden TempLo and TempHi registers do also exist in the Z80. They are called WZ there. (WZ for the combined 16-bit. W for the high byte. Z for the low byte.) Here you can see. Maybe it would be a good idea to call them the same. :)

[ogamespec]

Did I understand this correctly?

Yes. The Inc/Dec circuit and why we need TTBx signals from Thingy is already being prepared.

Is the address for the IE register fully hardcoded, or can part of it be influenced by external signals?

Hardcoded. For this purpose there is a "breadcrumped" combinatorics, which checks that all values of Ax are equal to 1.

The hidden TempLo and TempHi registers do also exist in the Z80. They are called WZ there. (WZ for the combined 16-bit. W for the high byte. Z for the low byte.) Here you can see. Maybe it would be a good idea to call them the same. :)

Done :)

[msinger]

I was checking out your descriptions of the two unbonded pins in your HDL and I remembered that the Game Boy Color also had a NMI. So I was wondering if the LoadIR is also there. It turned out, directly next to the NMI pin is a pin called M1, which could stand for memory cycle 1, which would be somehow equivalent to LoadIR. Maybe it is exactly this pin. I know, you don't like to change signal names all the time. ;) I just wanted to let you know, in case you haven't seen this yet.

This is from the Game Boy Color Service Manual.

[msinger]

I tested it. I'm very sure M1 is the LoadIR signal. I measured this during the boot ROM was running:

Zoomed in between the two close pulses:

And at the end of the boot ROM, when it gets stuck in the endless loop (JR -2):

This actually fits the JR instruction, which has three memory cycles.

[ogamespec]

I originally suspected that its name SYNC (by analogy with 6502), but since there is already an official name, we can rename it.
I'm not a fan of renaming signals, because I have to correct 100500 sources (psd sources of topology, description on the wiki, HDL) and make sure everything is renamed :)

[msinger]

I know, but if you rename it later, then it could soon be 201000 places where you have to change it. 😄

[ogamespec]

#213

[msinger]

I also changed it everywhere. And I updated the descriptions of the CPU ports. I changed the names that were originally taken from Furrtek's schematics and used the correct names from ours. I also added a description for the not-connected R13, based on your layout.