search

msinger / dmg-schematics

Reverse engineered schematics of the Game Boy's DMG-CPU B chip
Creative Commons Attribution Share Alike 4.0 International
15 stars 14 forks source link

CPU: Wrong OSC_STABLE input #117

Closed msinger closed 2 years ago

msinger commented 2 years ago

On CPU sheet, the OSC_STABLE (T15) input of the CPU is not 16Hz. It is output of TABA.

rgalland commented 2 years ago

Well spotted.

msinger commented 2 years ago

You forgot updating the ports of the CPU sheet symbol on the top sheet. 16Hz is still there and RESET_RELEASE is not connected.

Also I hate to nag, but I don't think RESET_RELEASE is a good name. Because for the CPU this not only gets signaled when the reset is released. It also happens after waking up from STOP instruction. STOP instruction causes OSC_ENABLE to swicth off. When the CPU gets the WAKE signal, then it rises OSC_ENABLE again, then TABA again takes some time until it signals stable oscillator back to the CPU. When in STOP mode, the CPU doesn't get reset, otherwise it wouldn't continue running after the STOP instruction. That's why I think RESET_RELEASE doesn't quite fit. Most of the other parts of the chip are reset during STOP mode, so for them it would be true that the reset is released at that point. But this signal goes to the CPU specifically.

rgalland commented 2 years ago

Yes, I wouldn't mind giving it a more meaningful name but could not come with anything. Did you want to call OSC_STABLE? Is this a name you got from the Z80 documentation? Also do you what the relation is between CLK_ENA and OSC_ENA. It looks like CLK_ENA can only go high when reset stops otherwise TUBO would prevent the 16Hz signal to be seen by ASOL.

msinger commented 2 years ago

No, I think I came up with OSC_STABLE on my own after experimenting a lot with the simulation. You are correct. The CPU must not pull CLK_ENA high before OSC_STABLE is high. Otherwise some of the reset signals will not go away. I already documented somewhat about this on my page http://iceboy.a-singer.de/doc/dmg_cpu_connections.html in row T11. I concluded that the CPU has to do the following and implemented that in my simulation:

  1. On reset, initially keep CLK_ENA low. OSC_ENA can be high immediately.
  2. When OSC_STABLE rises, CPU drives CLK_ENA high. Now CPU starts actually running, because now it has all clocks.

When CPU encounters a STOP instruction it drives OSC_ENA and CLK_ENA low. When WAKE goes high, then it repeats from step 1. (OSC_ENA=high; wait for OSC_STABLE; CLK_ENA=high)

When CPU encounters a HALT instruction it drives CLK_ENA low, but keeps OSC_ENA high of course. Now the rest of the system is still clocked, but the CPU misses most of its clocks and won't continue executing. An interrupt will cause the CPU to drive CLK_ENA high again. It doesn't use WAKE, because WAKE is only for waking up if there is no clock at all. When in HALT the CPU still has some clock.

Yes, I would call it OSC_STABLE.

rgalland commented 2 years ago

Thank you for the explanation, it makes a lot of sense. I'll have to check my VHDL code but I think that's how I implemented STOP and HALT instructions. The signal will be renamed in the next commit to OSC_STABLE but I can leave the issue open until then.