Latching the Real Time Clock (RTC) in MBC3

Discussion of programming and development for the original Game Boy and Game Boy Color.
Post Reply
DarthWader
Posts: 4
Joined: Fri Nov 08, 2019 8:20 pm

Latching the Real Time Clock (RTC) in MBC3

Post by DarthWader » Fri Nov 08, 2019 8:38 pm

Hey guys, new user here.

I'm working on a VHDL implementation of the MBC3, with RTC. Everything's going great, it plays games just fine, but I'm struggling to read the RTC data.

I understand what the wiki says:

Code: Select all

[b]6000-7FFF - Latch Clock Data (Write Only)[/b]
When writing 00h, and then 01h to this register, the current time becomes latched into the RTC registers. The latched data will not change until it becomes latched again, by repeating the write 00h->01h procedure. This is supposed for <reading> from the RTC registers. This can be proven by reading the latched (frozen) time from the RTC registers, and then unlatch the registers to show the clock itself continues to tick in background.
In my code, I made a register, RtcLatchReg, which will hold this signal. On the rising edge of RtcLatchReg, the RTC data would be 'latched' into my 'buffer register'. The problem is, it's possible to 'latch' the RTC data into the buffer while the data is in the process of incrementing, which can result in the data being meta-stable. This is because the signal that clocks the RTC registers is asynchronous to the signal that clocks RtcLatchReg.

So my questions is: How do I latch the data safely? I noticed that the MBC3 uses the CLK signal from the cartridge edge, and I strongly suspect it is needed here for something. I'm not sure how to interface these two asynchronous clock domains.

I think the wiki says to wait 4 cycles in between latching and reading the RTC data? I'm not sure what requires 4 cycles to complete, but I assume it has to do with synchronizing some signal between these 2 domains?

Any help would be greatly appreciated, I can elaborate on anything else if needed.

lidnariq
Posts: 8792
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Latching the Real Time Clock (RTC) in MBC3

Post by lidnariq » Fri Nov 08, 2019 9:24 pm

The classic PLA advice is to quantize your low speed clock using your high-speed one. So instead of counting on a rising edge of the 32khz crystal, you count on a edge of the 1MHz signal from the connector, if the current quantized crystal value also had an edge.

In this case, however, you want something that can continue running even when the 1MHz signal has stopped (because the gameboy is off). I'm not entirely certain how to resolve this.

(Also, I assume the RTC will completely destroy your backup battery's lifetime, but maybe you found some kind of PLD that isn't too bad)

nocash
Posts: 1092
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Latching the Real Time Clock (RTC) in MBC3

Post by nocash » Fri Nov 08, 2019 11:26 pm

How about retries...

1st cycle, incremented=false
2nd cycle, do latching
3rd cycle, need_retry=incremented
4th cycle, if need_retry then do_latching

Something like that, the separate 3rd and 4th cycle should make sure that an increment flag change won't occur together with the retry.

Or, copy the the 32khz timer to a 1mhz timer at gameboy power up, then you won't have to deal with the 32khz during operation at all.

User avatar
getafixx
Posts: 362
Joined: Tue Dec 04, 2012 3:28 pm
Location: Canada

Re: Latching the Real Time Clock (RTC) in MBC3

Post by getafixx » Sat Nov 09, 2019 12:49 pm

Would it not be easier to just use a dedicated RTC chip (something like this) and relay that info back to the CPLD/FPGA when the console needs it? Keeps power consumption from the CPLD away from the battery.

DarthWader
Posts: 4
Joined: Fri Nov 08, 2019 8:20 pm

Re: Latching the Real Time Clock (RTC) in MBC3

Post by DarthWader » Sat Nov 09, 2019 1:18 pm

getafixx wrote:Would it not be easier to just use a dedicated RTC chip (something like this) and relay that info back to the CPLD/FPGA when the console needs it? Keeps power consumption from the CPLD away from the battery.
That was actually my first plan, using a calendar RTC chip with a parallel interface. The problems I ran into were:
-converting BCD to binary
-converting binary back to BCD
-combining DayOfMonth, Month, and Year into a total count of days.
-converting a day count in binary back to Year, Month, and DayOfMonth in BCD

The RTC chip approach sounded easy at first, but eventually I gave up on it. I really did like how it handled latching the clock data for me.
I want to try a simpler approach using only a CPLD, and if the power consumption doesn't work out, I may try the RTC chip again.
The ispMACH-4000 series CPLDs from Lattice seem like they MIGHT work out. I only need to power about 32 macrocells from the backup battery.

DarthWader
Posts: 4
Joined: Fri Nov 08, 2019 8:20 pm

Re: Latching the Real Time Clock (RTC) in MBC3

Post by DarthWader » Sat Nov 09, 2019 3:08 pm

nocash wrote:How about retries...

1st cycle, incremented=false
2nd cycle, do latching
3rd cycle, need_retry=incremented
4th cycle, if need_retry then do_latching

Something like that, the separate 3rd and 4th cycle should make sure that an increment flag change won't occur together with the retry.

Or, copy the the 32khz timer to a 1mhz timer at gameboy power up, then you won't have to deal with the 32khz during operation at all.
I was actually just thinking about this just yesterday. I think it would be best to sample until 2 consecutive samples match? Here's a flow chart I made yesterday to represent this idea.
Samples of the RTC data would be taken on the rising edge of the 1 MHz clock.
The best case is labeled in green (2 cycles), and red is worst (4 cycles):
Image

I'm curious if this approach would actually work.
Someone correct me if I'm wrong, but a 'meta-stable' state is neither logic high nor low. So if my sample was meta-stable, is it still possible to compare it to the previous sample?

I'm still pretty newbie with digital design, especially asynchronous stuff.

nocash
Posts: 1092
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Latching the Real Time Clock (RTC) in MBC3

Post by nocash » Sat Nov 09, 2019 10:34 pm

Chedking for two consecutive identical values sounds even better than my idea.
I have no idea what meta-stable means... it sounds like slang meaning unstable, or not-stable?
Yes, you can compare that without problems, there may be garbage when the time changes from old to new...
...old, old, old, garbage, new, new, new...
So, if your comparision gets twice the same value then you know that it isn't the garbage one.
That, assuming that the garbge lasts for only one clock cycle.

nocash
Posts: 1092
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Latching the Real Time Clock (RTC) in MBC3

Post by nocash » Sat Nov 09, 2019 10:50 pm

Apart from the extra cost, I would recommend an exteral RTC, too (unless the cpld can be powered down, with only the the rtc circuit running at low power consumption).

Bcd conversion really isn't difficult, you only need shift+add operations to implement the multiply by 10. Months and leap years are kinda annoying in maths, implementing that in logic may be even more annoying than doing it in software.

As you mentioned a parallel rtc chip instead of a cheaper and smaller serial rtc... did you plan to do the bcd/day conversions on the fly? That would be unneccessarily complicated, it would be easier to convert the values once at power up, and then use your own logic (like what you are doing now).

lidnariq
Posts: 8792
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Latching the Real Time Clock (RTC) in MBC3

Post by lidnariq » Sat Nov 09, 2019 10:52 pm

Electronic metastability cannot be compared. It's a value that's neither 1 nor 0 nor high-impedance, and if that value matters to some subsequent logic, that later logic will also be metastable. (e.g. NAND(X,0) is safely 1, but NOR(X,0) is X)

Even when I took PLD lab class in college, we didn't really touch on multiple clock domains, so I can't really say anything more helpful, unfortunately.

DarthWader
Posts: 4
Joined: Fri Nov 08, 2019 8:20 pm

Re: Latching the Real Time Clock (RTC) in MBC3

Post by DarthWader » Sun Nov 10, 2019 1:37 pm

Well here is the VHDL I've made so far. I have no idea if the RTC code will work at all, since I still need to buy a chip with enough macrocells to fit it. It will be a while before I can try it out, so if anyone wants to test/optimize/play with it, feel free. An oscillator will be required to generate the 32.768 KHz signal, "RTC_CLK".

If nothing else, if you remove all of the RTC code, it functions perfectly well as MBC5 (and maybe MBC1 + 2, haven't tested enough games yet), and will fit on a 32-cell device. It is also compatible with either SRAM or FRAM.


Using a CPLD with a dedicated RTC chip was difficult, but I may take another crack at it. I have a strong feeling I could make it work with an FPGA.
Attachments
Multi MBC.txt
(6.3 KiB) Downloaded 25 times
Last edited by DarthWader on Mon Nov 11, 2019 6:26 pm, edited 1 time in total.

nocash
Posts: 1092
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Latching the Real Time Clock (RTC) in MBC3

Post by nocash » Sun Nov 10, 2019 11:34 pm

lidnariq wrote:Electronic metastability cannot be compared.
For sure it can be compared. If the result makes sense depends on what you doing.

Obviously, an address decoder that checks "if unstable=8000h then do something crtically" wouldn't work well.

But a check for "if latched_1st_read=2nd_read then latch is stable" should work perfectly fine (assuming that at least one of the two reads was stable, which should be the case if the timer increments only once per 32768hz) (well, and assuming that the increment has finished within whatever clock rate being used for 1st and 2nd read).

lidnariq
Posts: 8792
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Latching the Real Time Clock (RTC) in MBC3

Post by lidnariq » Mon Nov 11, 2019 1:32 am

Metastable values are both simultaneously 0 and 1, or are neither 0 nor 1, whichever is less convenient to the programmer. They will randomly resolve to 0 or 1 at some random point in the future - hence metastable. They only meaningfully exist in feedback paths (such as latches), and the logic calculated from other metastable values.

Comparing two values doesn't become more resolvable if both of them is held in latches instead of only one; either way a metastable value can propagate through it, as long as the truth value of the metastable value matters to the final calculation. (e.g. comparing b'000' to b'00X' is metastable, but comparing b'010' to 'b00X' is safely unequal)

nocash
Posts: 1092
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Latching the Real Time Clock (RTC) in MBC3

Post by nocash » Mon Nov 11, 2019 3:26 am

Oops, okay, the latched value can stay in unstable state if the source was unstable?
I wasn't aware of that... but here's a bit about it, too https://en.wikipedia.org/wiki/Metastabi ... ectronics)
Now I am wondering if that could occur in software (and emulation), too. For example:

Code: Select all

 mov  a,[open_bus]   ;get random garbage
 call display_a      ;display garbage value
 call display_a      ;display another garbage value?

User avatar
TmEE
Posts: 712
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: Latching the Real Time Clock (RTC) in MBC3

Post by TmEE » Mon Nov 11, 2019 4:00 am

The metastable state cannot generally pass a clocked register and will stabilise between the clocks, but in a sausage of combinatorial logic you could have a row of gates that are all in their linear region with essentially undefined state.

Post Reply