Page 1 of 1

Verilog implementation problems

Posted: Tue Sep 19, 2017 1:04 pm
by getafixx
Hey guys,

Working with my Altera FPGA dev board and I can't seem to get even a basic game like Tetris to load on anything other than GBC and GBA. I've been doing it in Verilog, and I get the Nintendo logo on my original DMG and Pocket, but then it goes to a blank screen every time. All 32K games like Tetris or Dr Mario work perfectly on a GBA or GBC console, though.

Here's my super simple mapper below, where FL_xxx is the flash memory:

Code: Select all

module no_mapper(

input not_wr, not_rd, not_cs,

input  [15:0] addr,
output [7:0]  data,

input  [9:0]  SW,
input  [3:0]  KEY,

output [21:0] FL_ADDR,
input  [7:0]  FL_DQ,
output 		  FL_OE_N,FL_CE_N,FL_RST_N,FL_WE_N
);


assign FL_ADDR  = {6'b000000,SW[0],addr[14:0]};
assign FL_OE_N  = not_rd;
assign FL_RST_N = 1'b1;
assign FL_WE_N  = 1'b1;
assign FL_CE_N  = addr[15];

assign data     = FL_DQ;

endmodule
I've got FL_ADDR[15] wired to a switch, so I can toggle between two 32K games, for testing.

The board I'm using is a simple pass-through that connects the pins of the console to a 40-pin IDE header in order to interface with the GPIO pins on the FPGA.

Anyone have any ideas of what could be at fault?

Re: Verilog implementation problems

Posted: Tue Sep 19, 2017 4:03 pm
by infiniteneslives
If it's working on older GB's and not more recent ones, then sounds like you logic is working as expected.

I'm not too familiar with how the GBC & GBA differ in bus accesses compared to GB(p). Have you tried to research this? Perhaps something going on differently at boot to detect cart type? Perhaps it's accessing at different speeds? How is your setup wired? Big long wires to a dev board? These are the types of things I would suspect vs your verilog. The fact it works on oldies but not new sounds like your biggest clue.

Re: Verilog implementation problems

Posted: Tue Sep 19, 2017 4:12 pm
by lidnariq
Backwards. It's working on newer ones, but not older ones.

We know that the different generations of game boy use different bootstraps, but I don't know if that's relevant. Maybe it's a voltage level thing? i.e. maybe the original DMG is 5V CMOS and the GBC only requires 3V levels?

I'd throw a logic analyzer at the problem to see if I could figure out what was going on.

Re: Verilog implementation problems

Posted: Tue Sep 19, 2017 5:25 pm
by getafixx
Yeah it's the other way around. Newer ones work, older ones don't.

Could be voltage-level related, as my dev board is running at 3.3V TTL levels, where the console would want 5V TTL (or CMOS? can't recall). Should still be good enough to register a high (1) for TTL/CMOS, though, but it's the only possible thing I can think of if my code isn't the problem. The original DMG and Pocket, as well as GBC all run at the 5V levels natively. I'm using a 6" IDE cable to run between the console and the dev board, so I don't think excessive length is at fault.

I was thinking maybe the double-speed mode of the GBC/GBA could be a factor, but that shouldn't really be enabled without the MBC5 running, which I haven't written yet. I've got a basic MBC1 and MBC2 mapper running as well, but neither of those work on the original models either. Again, work fine on the GBC and GBA.

Re: Verilog implementation problems

Posted: Tue Sep 19, 2017 5:48 pm
by lidnariq
getafixx wrote:Should still be good enough to register a high (1) for TTL/CMOS, though, but it's the only possible thing I can think of if my code isn't the problem.
In a fully 5V CMOS system that's not TTL compatible, 3.3V as logic high is really dodgy. I know I've found a few of these over the years—e.g. the SNES's SA-1's mask ROM.

Mind, I don't know whether that's true of the DMG.

I don't think this is it, but: the DMG/GBC verify the ROM corresponding to the logo at different times. The old ridiculous gameboy modem wouldn't work on newer consoles because of that.

Have you checked whether the CPU has halted at a specific address when boot fails?

Re: Verilog implementation problems

Posted: Tue Sep 19, 2017 10:08 pm
by gekkio
What kind of flash are you using? I don't see any immediate problems with the code, but the speed and expected memory timings of the flash could be a cause for problems so a datasheet would be helpful.

Also, I'm curious: which Altera dev board are you using that is 5V tolerant?

Re: Verilog implementation problems

Posted: Tue Sep 19, 2017 11:34 pm
by calima
Krikzz's new Everdrive GB X series had a problem on Gameboy Pockets, it failed to start on them because that system took longer to ramp up to full voltage than the others. The FPGA then failed to initialize itself. It did work on the original DMG, but perhaps yours has a similar issue, just being less tolerant than it.

Try your DMG or Pocket with a power adapter.

Re: Verilog implementation problems

Posted: Wed Sep 20, 2017 9:35 am
by getafixx
lidnariq wrote: Have you checked whether the CPU has halted at a specific address when boot fails?
Waiting to get a logic analyzer so I can check that on a scope, but it does appear to hang after the Nintendo logo. When trying Dr Mario I get a split second "fuzz" noise that loops, but nothing on any other title i've tried.
calima wrote: Try your DMG or Pocket with a power adapter.
Tried that first, made no difference unfortunately.
gekkio wrote:What kind of flash are you using?
Also, I'm curious: which Altera dev board are you using that is 5V tolerant?
It's S29GL032 and it's on a DE1 board, and I don't believe speed to be the issue honestly. Yes, it is NOT a 5V tolerant dev board at the moment. I'm going to make a passthrough board that adds level translation though, so that part will be fixed soon.

**Update** Interestingly, when I try this on a dev cart I made for the Gameboy a while back, this same code works fine on all systems, including SGB. That cart is running a Xilinx CPLD and the same 29GL032 flash. So this may be isolated to the Altera FPGA somehow... The plot thickens.

Re: Verilog implementation problems

Posted: Wed Sep 20, 2017 10:46 am
by gekkio
It's S29GL032 and it's on a DE1 board, and I don't believe speed to be the issue honestly. Yes, it is NOT a 5V tolerant dev board at the moment.
Cyclone II seems to have a maximum rating of 4.6 V on the IO pins, so this doesn't seem like a great idea to do with a $150 dev board. I wouldn't be surprised if something has broken or behaving weirdly because of this...
I looked at the S29GL032 data sheet and couldn't see any obvious problems. Your Xilinx board also works, so this definitely hints at some Altera issues like the maximum voltage rating.

I'm not very familiar with Verilog, but I don't see any obvious code that handles putting the GB data pins into high-impedance mode. Is that in some other file or are you always driving the GB data pins?
Also, how have you configured the GB pins? Are you using bus hold, pull-up/pull-down resistors or any other special settings? Which IO standard and drive strength settings are you using?

PS. If you're curious about the read timings of 1st generation Game Boys, look at this: https://gekkio.fi/files/rubbish/M1.png
It describes a fetch cycle but normal reads have the same timing. Data is sampled at T4, RD is not pulsed on each read but chip select (A15 in case of $0000-$7FFF) is.

Re: Verilog implementation problems

Posted: Wed Sep 20, 2017 10:52 am
by infiniteneslives
**Update** Interestingly, when I try this on a dev cart I made for the Gameboy a while back, this same code works fine on all systems, including SGB. That cart is running a Xilinx CPLD and the same 29GL032 flash. So this may be isolated to the Altera FPGA somehow... The plot thickens.
The fact it was working on some systems showed signs that your code was already working on the DE1.

I don't suspect it's related to what's going on here, but something to keep in mind.. Synthesis tools and underlying hardware all differ between vendors. I've had issues where Lattice diamond will synthesize two completely different things depending on which synthesis tool I select. That issue seems to be mostly corrected with recent updates. Anyway, my only real point is here is that "your code" is widely open to interpretation, hdl's are no where near as standardized as languages like C. Part of this is simply because the underlying hardware varies from one device to another, and things like timing constraints can become a concern. Any number of things can cause the same hdl code to work on one system, but not another so it's good to keep that in mind.

Unfortunately your DE1 board throws a huge wrench into your system that could be the source of a large number of issues. For reasons like this I typically avoid dev boards and start all projects with a prototype board as close to the end design as I can imagine. Highly likely a number of things will crop up, or disappear when you migrate between the DE1 and what I assume is the excessively smaller device on your end project. This is effectively what you're already seeing between the DE1 and xilinx board.

Re: Verilog implementation problems

Posted: Wed Sep 20, 2017 1:33 pm
by getafixx
Yeah, I figure it's always better to have a dedicated dev board for each system. But it starts getting to be a nuisance if you have to make any revision changes to the design and have to order more boards. I thought it would be nice to have a dedicated platform that can handle anything I throw at it, and just use pass-through boards. Also saves on assembly time for each prototype.

Anyways, I'll play with it some more and report back if I find anything out.

Thanks for the pointers so far everyone!