Use actual gameboy carts?

[Qiangong2]

Is it possible to use actual gameboy cartridges with this?

[zephray]

Yes it's supported. The internally simulated cartridge use the same signal and pinout as the real cartridge, so you can just connect a real cartridge there. I was planning to make a demo hardware with real cartridge, but didn't quite have time to do.

[blazer82]

Jumping in here.. I actually built hardware with a real cartridge slot and got Tetris working. I needed to invert some of the signals (RD, WR, CS, RST) because they're active low and I think you got them active high in your HDL. Not a problem, though!

Tetris is fairly simple and doesn't use anything else besides RD and the address bus and data bus. I could not get Super Mario Land to work, however. All I get is scrambled output on the screen. I suppose it has something to do with it using MBC1. Did any of you get this working properly and maybe has any idea what I'm doing wrong?

Anyway, I'll try to debug this and will report any findings here.

[zephray]

@blazer82 Hi, great that you got it working! The active high was more or less a coding style issue, I wanted to keep all internal signals active high, and invert them as needed in the top-level when interfacing with hardware. But as with all coding style issues, that's just personal preference.

Regarding the MBC1 issue, I would assume you've stripped out the mbc5.v implementation and wired the bus directly to the cart. One issue I can think of is that the current vb implementation doesn't generate CS signal. Cartridges with builtin RAM could rely on this signal to function correctly. Try implement the CS logic and see if it make any difference. (Ideally it should also check the address range to see if it should be asserted, but as a quick starting point, assign cs = rd | wr; (or assign cs_n = rd_n & wr_n;) should do the trick.

[blazer82]

@zephray Thanks for the quick response! You're right, CS isn't being driven right now yet it is wired up inside the cartridge, so it's probably used for something. I'll have a look at that and try your proposed solution and then report back.

Also, I agree regarding the active signals: In code I think active high makes more sense yet electrically I prefer active low. I can totally see why you did this and it's no hassle to just invert it.

[blazer82]

@zephray having cs = rd & wr which would make it active low whenever rd or wr is active low kind of makes sense yet it did not work. Got the same garbage on the screen.

I then tried cs = ~(gb_a >= 16'hA000 && gb_a <= 16'hFDFF) since I read somewhere that it's supposed to be active for addresses in that range only. This change got me stuck in a bootrom loop. At least, that's something new 😅

[zephray]

Just checked that Super Mario Land works in the simulator so I guess this shouldn't be a compatibility issue with the core itself... (./sim/verilator/vb_sim SuperMarioLand.gb --nostop --mbc). I noticed that the cartridge doesn't have any kind of RAM builtin, so the cartridge shouldn't do anything with address higher than A000.

[blazer82]

Sounds promising, thanks for testing that out! I suppose I must have something wrong with the wiring in HDL.

I was also thinking that Super Mario Land isn’t supposed to have RAM and you’re right the switchable ROM should all be below 0x8000.

I’m gonna investigate further 😊

[blazer82]

I fixed it! Turns out CS isn't needed and I have it pulled up all the time.

The issue was me still being a total noob in terms of FPGA programming and not knowing how to properly wire up the data bus for read and write operations. After some googling I figured it out and it works like a charm.

As the issue was never with VerilogBoy and I now confirmed that it indeed works with real cartridges, I suggest closing this issue 😊