Gameboy Development Forum

Initially, I was using an Atmel CPLD, atf1504asl. I think something was wrong with either the hardware or the software (WinCUPL), because some of the pins on that Atmel dev board just never seemed to work. I finally caved and bought the Xilinx Platform Cable 2 so I could use their software. It's been much better since.

Without any of the RTC code, I'm using 30 macrocells. I'm trying out the XC9572XL to see if I can pull this off with only 72 cells, if not I can upgrade to the 96-cell device. I like how this device family has 5v tolerant IO, and runs at 3v. This circuit was going to have to generate 3v anyway for my Flash and FRAM, so it works out.

I was originally looking at the XC2C128 to hold both the MBC logic and the RTC all on one device, but I'm afraid it will still drain the backup battery too fast. I think Xilinx Power Analyzer estimated about 19uA, including the CoolClock feature. I think it will also require another regulator to supply 1.8v? Also some way to switch to backup power...

Basically, device selection has been a 3-way tug of war between board space, power draw, and voltage requirements.

*EDIT: The 5v IO isn't going to be important in the end, but it's very useful for prototyping, since my flash chip and FRAM are both 5v parts.

Last edited by WeaselBomb (2019-10-07 17:58:31)

Keep going WeaselBomb, it really seems like you're gaining quite a lot experience

Too bad your original plan won't work out. Was power your only concern to remove implementing the RTC directly on the CPLD?
How did you arrive at 61 macrocells? I get 6 bit (seconds) + 6 bit (minutes) + 5 bit (hours) + 10 bit (days + carry) = 27 bits, so the rest is all routing and logic?

Oscillators are here, but I think my VHDL skills might need some work to make this happen. I could easily do it if everything were contained on the CPLD, but I haven't found a combination of parts that will allow me to do that. Maybe an FPGA could get better power consumption? I haven't every looked into those.

I'm working with the DS1501 RTC chip. I can access every register that I need with 4 address lines (0x00 through 0x0F). There are some extra RAM registers beyond that, but they use Indirect Addressing, so I'm not sure how useful those will be (it takes 2 clock cycles to access a register using indirect addressing, instead of the usual 1 cycle with direct addressing).

The DS1501 has 2 control registers, A and B. The states of these registers are unknown after initial power-on. I'm thinking it would be best to set both of these registers after every boot-up? These registers are at addresses 0x0E and 0x0F, respectively.

REGISTER MAP
Register     Description

0x00          Seconds
0x01          Minutes
0x02          Hours
0x03          DayOfWeek (1-7)
0x04          Date (1-31)
0x05          Month (1-12), Oscillator On/Off
0x06          Year
0x07          Century
...              ...
0x0E          Control A
0x0F          Control B

I will need a dedicated data bus to read/write data from/to the RTC. It can't share the same data bus as everything else, since it will need to be converted by the CPLD before it is read by the CPU (we can't have the RTC and the CPLD trying to output on the data bus at the same time!).

For control signals, I will also need to generate Write Enable (WE), Output Enable (OE) and Chip Select (CS) signals to read and write the RTC. Last, I have another clock signal, generated by my new oscillator, that will be used to "drive" the RTC register reads/writes.

The RTC has 2 sets of RTC registers, only one is accessible. I think of these like the "latch registers" on the MBC3.
The Most Significant Bit (MSB) in Control B is the Transfer Enable (TE). Clearing this bit "freezes" or "latches" the RTC registers, allowing us to read them safely, without worrying about them incrementing mid-read. Setting this bit "unfreezes" the RTC registers, and they resume incrementing once per second.

*EDIT:
If I wanted to do everything on the CPLD, I would need a very low power device, since it would need to run from a coin battery. The CoolRunner 2 is the best one I've found so far. Even then, the datasheet says its quiescent current can go as low as 12 microamps. So, that means there's no way to go below that current, right? With my CR2025 at 170 mAh, that would completely drain the battery after 14,167 hours, or 1.6 years. Ideally, I'd like it to last at least 5 years. I just don't know if that's possible on a CPLD.

Last edited by WeaselBomb (2019-10-17 17:52:57)

I've been studying a little VHDL, but I'm definitely out of my comfort zone here. I don't have any solid progress to report unfortunately, just some musings about how I might approach reading and writing the RTC.

Accessing the seconds, minutes, and hours registers isn't going to be problematic. I can access those and convert to binary in one cycle easily.

Getting the day counter in the correct format will be the main challenge. I'll need to access the Date, Month, and Year registers together, all in one CPU cycle, calculate the total number of days, and convert that to binary.
For the lower 8 bits, I'm thinking just assigning the total number of days to that register will work (I'm not sure how VHDL handles overflows yet). For the 9th bit, I will need to see if the day counter is over 255. For the carry bit, I need to see if it is over 510. The halt flag will actually come from the month register (this RTC chip has an oscillator enable bit located in the Month register).

Control Registers A and B on the RTC chip will need to be set on every startup, since their values aren't "valid" when applying power for the first time. I think it's best to just set them every time.

To latch the RTC, I just have to toggle bit 7 of Control Register B (called the "transfer enable" bit in the datasheet). At first, I was confused as to how I could set this bit without affecting the other 7 bits, but I think it can be done by tri-stating the other data lines?

I wonder if this can be done with a state machine? Just spitballing, but I'm picturing these states:
-doNothing
-readDate
-readMonth
-readYear
-writeControlA
-writeControlB

On startup, I could default to state 'writeControlA', which would always move to 'writeControlB', then 'doNothing'.
If I am in state 'doNothing' and the CPU tries to access either of the day registers, I could move to 'readDate', then 'readMonth', 'readYear', and finally return to 'doNothing'. I would accumulate the day count on every state change.

Here's an incomplete draft of this idea, I'll update when I figure out more. Basically, states are enumerated from 0-5, and the state starts at 4 on startup, which should initialize both control registers.

type state_type (DoNothing, Latch, DayOfMonth, Month, Year, CtrlA, CtrlB);
signal state, nextState : state_type;

test : process(state)
begin
    case (state) is
        when DoNothing =>
            RTC_ADDR <= "0000";

                when Latch =>
                        RTC_ADDR <= "1111";
                        nextState <= DoNothing;

        when DayOfMonth =>
            RTC_ADDR <= "0100";
            nextState <= Month; --month reg next

        when Month =>
            RTC_ADDR <= "0101";
            nextState <= Year;

        when Year => --Year register
            RTC_ADDR <= "0110";
            nextState <= DoNothing;

        when CtrlA =>
            RTC_ADDR <= "1110";
            nextState <= CtrlB;

        when CtrlB =>
            RTC_ADDR <= "1111";
            nextState <= DoNothing;

        when others =>
            -- shouldn't ever reach this state
            RTC_ADDR <= "0000";
            nextState <= DoNothing;

    end case;
end process test;

Last edited by WeaselBomb (2019-10-21 17:49:14)

Tauwasser wrote:

I don't think you need to initialize the RTC control registers on every boot, just once for initial configuration.

I agree, it would be better to only initialize once. The only problem is I'm not sure how to detect if it has been previously initialized?

Tauwasser wrote:

The DS1501 is a relatively expensive part. I think you chose it because of its parallel address and data bus, correct?

Yes, this part is pretty pricey for what it is. I'm using it for now because it had several useful features for prototyping, like an integrated crystal and battery, plus the ability to output a 32.768 KHz frequency signal. In production, I would definitely go for a cheaper part.

I'm thinking this idea isn't going to work either. The timing is just too tight. This RTC chip has an access time of 70 - 120 ns, depending on VCC. By the time I figure out what register I need to access, AND wait for the required access time, there isn't enough time left to read 3 registers and load data on the bus. I guess I need to be able to read the day counter registers in single reads.
Maybe FPGAs can do what I need? Maybe I should re-consider a larger CPLD? I would love the ability to power down all logic EXCEPT the RTC logic, to save power when running from a backup battery. A device with a dedicated battery input pin would be even better.

At this point, I'm out of ideas and I'm not sure if I will come up with any more. I'm really not satisfied with leaving RTC unfinished, but I really don't know what to do about it.

Yep, you're correct. The registers on the gameboy side and the RTC side are buffered and clock domain crossing is performed using the PHI/CLK pin on the Game Edge Connector. That's why latching the clock and reading from it is supposed to be spaced out by some clock cycles in code.

Ok, I don't think using a synchronizer (handshake) to pass the RtcLatch signal across the clock domain would be wise here, since the 32.768 KHz clock is so much slower than the 1 MHz clock.
Each oscillation of the slow clock takes about 30.5 microseconds, whereas the fast clock takes about 1 microsecond. Passing the RtcLatch signal through a 2-flip-flop synchronizer would then require up to 61 microseconds, meaning we could potentially have to wait up to 61 cycles (at 1 MHz) to latch the clock data, which is way too slow.

Correct me if I'm wrong, but the FIFO idea doesn't work either, because it would also require synchronizing read/write signals, which would, once again, be too slow.

Sampling the data multiple times has me intrigued. I figure it might be possible to sample the RTC until 2 matching samples are read? Samples would be read on the rising edge of the 1 MHz clock. I think this is a common method for reading dedicated RTC chips, actually.
I made a flow chart to visualize the possible outcomes for this technique. The best case is labeled in green (2 cycles), and the worst case in red (4 cycles).


I'm curious if this approach could work. The idea is that within 4 cycles of the 1 MHz clock, there could only be 1 transition of the RTC data, at most.

Last edited by WeaselBomb (2019-11-09 19:59:50)

Hi WeaselBomb,

sorry for not getting back to you sooner. Anyway, your thoughts on meta-stability assume that you can detect meta-stability when that is usually not the case. Meta-stability means that it takes a long time for an output to settle to a final value. The two register pipeline works because while the first stage might become meta-stable due to the inputs transitioning while the register was clocked, the second stage will still see a logical 0 or 1 due to threshold voltages. Each additional register stage makes true metastability mucht more unlikely. This means if you can encode the value you are trying to synchronize between clock domains appropriately, you will only ever have an uncertainty of a single bit (the bit that switched). Gray coding is one popular solution to this problem, which is why you often read about FIFOs for design with rational clocks as they employ gray counters for their address counters.

However, your problem isn't that complicated, since your "count pulse" is only a single bit, so at most you might miss one edge. And that count pulse signifies when it's safe to transfer the clock registers (many bits) as they are not counting up at that moment. The other way around (going from high-speed clock to low-speed clock) takes even more synchronization time as the slow clock needs to be able to recognize the write and overwrite the register in the slow clock domain. Nintendo indicates that one should wait 4 clock cycles between these register accesses when writing individual registers and between latching the registers and reading them.

As for your fitting problem, you rightfully concluded that too many signals are being read at one place in your design. Seeing your current design, I strongly suspect the cascaded sequence of if statements that cause the problem. They all act on the rising edge, so they would all have to go through multiple Look-Up Tables (LUTs) in order to be available at one specific FB all at once. I'm not sure how you currently constraint timing, but you definitely should look into that. Adding sensible timing constraints will give you more insight into your design and allow the fitter to make proper decisions about placement and propagation delays.

Real life has been pretty busy lately, so not much has been done as far as coding.

I think in the end, the best solution will probably be using the MachX02 FPGA from Lattice (40 I/O pins, 256 cells). It would be nice to use a Xilinx FPGA, but all of their current offerings have way too many I/O, and ultra-low voltages that I don't want to use.
I've bought a Lattice JTAG programmer from China, and I plan on getting a MachX02 breakout board sometime in the next 2 weeks. This FPGA should have enough cells to do everything I need, and I could even read the RTC data into its registers on startup. The only real challenge would be writing to both copies of the RTC data during gameplay.

Anyways, that's where I'm at for now. Still not sure if my latching logic is OK, but we'll get there when we get there I guess.

Whoa, that's looking really good.

I don't have experience with MachXO devices, but obviously double check decoupling and power sequencing. Most of these devices don't like it when voltage is applied to pins before the core voltage has stabilized.
I see you chose to have a ground plane without thermal relief. That might make soldering harder for the RTC chip and the decoupling capacitors of the MachXO (U4). I presume X1 is an SMD part, else you might have too little space for a discrete crystal.

Your vias are smaller than what many cheap pcb manufacturers specify without surcharge (most use 0.3mm, e.g. OSH Park, Seeed Studio). Minimum annular ring therefore doesn't match either.
You have a little neckdown from pad to trace but you didn't really center the traces for each pad. That's probably negligible though as you will hand-solder and presumably not rework the board multiple times.

If the cyan region is where gold is applied, you might not want the edge of the pads and the end of this region overlapping exactly. Instead ease off a little so a bit of the upper part of each pad is covered by solder resist.
I see you chose to use AIN as WE# for the flash, but I don't see a pull-up on the pin which might cause spurious writes if the pin is not connected to a Game Boy or a device that properly pulls it high.
You might also want to add a capacitor to the #WE line which you leave unpopulated in the initial run. That way you can adjust setup times in case the timing between the two Game Boy and the requirements of your components does not match or the timing of the two voltage translators is off.

cYa,

Tauwasser

WeaselBomb wrote:

Tauwasser wrote:

I see you chose to have a ground plane without thermal relief. That might make soldering harder for the RTC chip and the decoupling capacitors of the MachXO (U4)

Yes, thermal relief is a topic I don't know much about, let me make sure I understand. The problem is that the ground plane is overlapping the pads, which will cause the plane to act as a heatsink? Meaning the iron will have to be applied for longer? How would I fix this? Could I run a trace to connect the pad to the ground plane instead?

Yes, you understood the problem. In most EDA tools, this is just an option when creating the polygon pour (e.g. KiCad) or a design rule (e.g. Circuit Studio, Altium):



This automatically results in these pad connections:

WeaselBomb wrote:

I was planning on soldering these boards either on a hot plate or in a reflow oven. Will this still be an issue in that case? I'm thinking since the entire board will be heated at the same time, the thermal relief wouldn't be necessary.

It can become an issue, because islands of differences of heat can still result. On a hot plate this shouldn't matter too much, but reflowing can result in cold solder joints.

WeaselBomb wrote:

Maybe the ideal solution would be to not connect these pads to copper pours, but instead connect them to vias which will connect to copper pours underneath?

No, don't do that unnecessarily. It will make production more difficult and you don't really gain anything here.
I usually connect pads to polygon pours with 0.2mm spokes or 0.4mm/0.5mm if a larger current is supposed to go through them and the size permits it.

WeaselBomb wrote:

I went back and upsized the vias to .4 mm inner, .65 outer. So the .4 mm inner should satisfy that first problem. Do you think I should increase  difference between inner and outer to at least .3 mm, or are these values ok? I'm unfamiliar with minimum annular ring specifications.

These measures are close for OSH Park for instance. Basically, the annular ring measurement is half of the pad diameter minus the drill size, so (0.65mm-0.4mm) / 2  = 0.25mm/2 = 0.125mm, which is 0.002 less than 5 mil OSH Park requires. I personally go for 0.3mm drill and 0.6mm or 0.7mm pad diameter when there aren't any other considerations.

WeaselBomb wrote:

I actually hadn't heard of neckdown before now, and I'm not sure what to do about it. I originally thought it would be best to have the trace width around the same width as the pad, to reduce impedance as much as possible. So I should probably reduce the trace width if I run into 'tombstoning' during reflow?

Tombstoning will only be an issue for light components with few pads like resistors and capacitors. For a whole IC to tombstone or short circuit pads would be unusual. For ICs it's more done to make soldering easier and when reworking the change of accidentally ripping a whole track off along with a pad is greatly reduced. In your case here, I'd do nothing for now. You're above the limit that cheap places can safely manufacture, so I wouldn't push it to 0.15mm track for 0.2mm pads or something like that.

WeaselBomb wrote:

For this, I went with a 10K pull-up. It's displayed as R1 near the center of the board.

Ah, I missed that one. 

You might want to put a series resistor between the battery plus lead and the V_Backup pin of the DS1390 to limit inrush current. 10k should be more than adequate.

You can also aim to minimize cross-talk by spacing some of the tracks out a bit more. That's especially visible on the 5V-side of the high address lines and the data lines.

You're doing pretty well for this being your second board.

WeaselBomb wrote:

Ok, I found the thermal settings in DipTrace and added thermal reliefs to my copper pour. Good to know how that works now.

Oh, that's what that is. I was wondering what software package that was

WeaselBomb wrote:

This must be what that resistor is for on retail cartridges! I remember trying to figure out why that was there a long time ago. So it actually protects the battery? I assume this is pretty standard practice for boards that use batteries then?

It's one of the reasons it's there. There are also industry requirements to get certification to minimize reverse charging current. Basically, the current must be limited as well if there was a (possibly destructive) event in the rest of the circuit that would connect a higher voltage to the positive battery terminal and thus "charge" the battery. If the current is too high, the battery might leak or explode and that's supposed to be avoided as well. UL for instance requires either two diodes in series or a diode and a series resistor.

Your ‎DS1390U is already rated to fulfill the UL requirement on that pin (which is curious, since they allow trickle charge by software). Therefore I expect some kind of diode to already be present in the device, like the MM1134 used by Nintendo (which uses a Schottky diode internally). However, actual resistors that can dissipate energy are physically big (and thus take up a lot of area in comparison to transistors) and usually not included on-chip.

WeaselBomb wrote:

Is there a good rule of thumb for track clearance? I just decided to use the same clearance as the width of the track (.204 mm). That's something I spent a lot of time thinking about and trying to read up on before saying forget it. It seemed like everyone had a different opinion.

You're right that everybody has their own opinion. I use track width or a bit more as a rule of thumb as well. In serious cases you would want to compute the coupling for high-frequency signals using a program like Si9000 to make sure that your design fulfills desired impedance requirements, but the Game Boy signals are super slow so you can get away with pretty much anything.

WeaselBomb wrote:

I've gone ahead and spaced out some of those 5v traces.

Looks better to me.

WeaselBomb wrote:

Cross-talk is something I'm concerned about on this board since it seems so dense in the center.

Well, you haven't shown the bottom side yet

WeaselBomb wrote:

Also, for driving DIR on the voltage translators, I noticed it goes from 5v side to 3v side when DIR = low. So it should be fine to drive that using the /WR signal from the cart edge?
I did notice the DIR pin was referenced to the 3v VCC, so the 5v /WR signal might cause it to transition from high to low too slowly. To compensate, I've added a pull-down resistor, R5.

I would expect it to be fine. I don't see the need for a pull-down resistor at all, since the datasheet (Nexperia) indicates that the threshold voltages are the same for 3V3 and 5V0. If anything, I'd be concerned about the #WR not rising quickly enough, because old CMOS/TTL stuff like the Game Boy tends to drive signals high by using a FET in its linear (resistive) region whereas driving low is usually through a FET in saturation region (so acts like a short).

However, it's highly unlikely that this is going to be a problem since your voltage translator has a propagation delay in the nanosecond region.
When I originally talked about adding a capacitor in my last post I was only thinking about the MachXO's setup/hold time requirements.

WeaselBomb wrote:

You really want to have the ground plane surround the RTC crystal pads and possibly connect the ground island north of the RTC's GND pin to the pin as well.
This will help avoid leakage current and capacitance mismatch. Often you even see a so-called guard ring around the pads that forms a star connection (only connected in one point) with the actual ground plane, e.g. see this Stackoverflow Answer.

cYa,

Tauwasser

Last edited by Tauwasser (2020-01-02 23:14:07)