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.

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.

_________________If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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.

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.

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?

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.

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.

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.pngIt 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.

**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.

_________________If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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.

Who is online

Users browsing this forum: No registered users and 2 guests

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