It is currently Mon Nov 18, 2019 1:54 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Fri Nov 08, 2019 8:38 pm 
Offline

Joined: Fri Nov 08, 2019 8:20 pm
Posts: 4
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:
[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.


Top
 Profile  
 
PostPosted: Fri Nov 08, 2019 9:24 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8684
Location: Seattle
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)


Top
 Profile  
 
PostPosted: Fri Nov 08, 2019 11:26 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1053
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.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Nov 09, 2019 12:49 pm 
Offline
User avatar

Joined: Tue Dec 04, 2012 3:28 pm
Posts: 361
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sat Nov 09, 2019 1:18 pm 
Offline

Joined: Fri Nov 08, 2019 8:20 pm
Posts: 4
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.


Top
 Profile  
 
PostPosted: Sat Nov 09, 2019 3:08 pm 
Offline

Joined: Fri Nov 08, 2019 8:20 pm
Posts: 4
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.


Top
 Profile  
 
PostPosted: Sat Nov 09, 2019 10:34 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1053
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.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Nov 09, 2019 10:50 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1053
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).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Nov 09, 2019 10:52 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8684
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sun Nov 10, 2019 1:37 pm 
Offline

Joined: Fri Nov 08, 2019 8:20 pm
Posts: 4
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 2 times


Last edited by DarthWader on Mon Nov 11, 2019 6:26 pm, edited 1 time in total.
Top
 Profile  
 
PostPosted: Sun Nov 10, 2019 11:34 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1053
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).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Mon Nov 11, 2019 1:32 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8684
Location: Seattle
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)


Top
 Profile  
 
PostPosted: Mon Nov 11, 2019 3:26 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1053
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 ... lectronics)
Now I am wondering if that could occur in software (and emulation), too. For example:
Code:
 mov  a,[open_bus]   ;get random garbage
 call display_a      ;display garbage value
 call display_a      ;display another garbage value?

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Mon Nov 11, 2019 4:00 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 711
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
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.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group