Game Genie Game mini-jam

[Memblers]

It might be worth splitting this off into another thread, so I'll do that depending on how the conversation goes.

One thing that's been bugging me for a while, I could swear that I remember that somebody years ago contacted David Galoob about the GG ROM, who said it's public domain, then it started being included with emulators, but maybe it's not these days. What bugs me is that I never could find the email about it, it must have been in the NESdev email list, but I don't have a complete archive of that. I think public domain, legally, isn't a license, but morally it should be OK to use it as such.

This is very interesting. Unfortunately, I couldn't find any mention of it in our bb0, bb1, or bb2 archives, though I'm not familiar enough with NESdev history to know what those actually cover, how much stuff isn't in them, or where that remaining material might be.

I just checked, unfortunately my email subscription on the email list was with hotmail, I only recall using the web interface with that address.. so there's almost zero chance of it finding it in my own personal backups (would be LS-120 disks from that era, lol). So my only reference I guess is myself when I added it to the NESdev front page. I'm not even sure when that was, it predates when I started keeping an update history in Aug 2000. And on my PC I have FCE Ultra, version Beta 4, document says "Also a feature unique to this emulator(at the current time) is authentic Game Genie emulation!", Filedate of this FCEU is Jan 18 1999. I ran it in DOSBox and it loads GENIE.ROM dated Dec 13 1998 in the same folder, headerless 16+8 NROM.

I guess it would may be difficult to simply email Mr. Galoob, and then awkward to be like "hey do you remember when some nerd emailed you 30 years ago..". If someone did want to try that route though, I searched and can confirmed that he's still around, and easily found someone on Facebook recently saying he's in contact with him, helping him sell Micro Machines from a warehouse find (the toys, not the game). I remember the names of some of the people who likely were on the list at that time, but not who was writing about that.

I suppose another slim possibility was it happened on #nesdev IRC. I don't think so, I want to say this predated me joining the IRC channel, but I could always be remembering some detail wrong.

Beware..! I believe it's possible to permanently fry the GG ASIC with incorrect usage. I'm pretty sure it's caused by running the cartridge (exiting Genie mode), without initializing the GG registers in the way the original code does. It doesn't happen immediately, it seemed like there might be days or even weeks of daily use between failures, but I had to socket both chips on my GG because I fried at least 3 ASICs myself, probably some more for earliest Cheapocabra devkit users. ESD event coincidence is still possible but doubtful. After making a software change, it's lasted for years without failing.

Does this suggest some kind of sustained bus conflict? Is there anything about what we know about the chip that would let us guess what's going on here and how to avoid it?

Patent 5112051 has a lot of drawings, showing a controller, and a block with power on timing (related to $FFF0-$1 writes maybe?), but I don't know anything beyond the drawings, or try to look up the text that references it.

As I remember, what I did was the usual $FFF0-1 thing, then later write to the $8000 control register, which can be quite a long while later. The fix, as far as I can tell, was when I started setting the address, data, and compare registers - writing $FF to them. I started assuming even though the codes are disabled, this uninitialized stuff is the problem, in game mode.

[Memblers]

Beware..! I believe it's possible to permanently fry the GG ASIC with incorrect usage. I'm pretty sure it's caused by running the cartridge (exiting Genie mode), without initializing the GG registers in the way the original code does. It doesn't happen immediately, it seemed like there might be days or even weeks of daily use between failures, but I had to socket both chips on my GG because I fried at least 3 ASICs myself, probably some more for earliest Cheapocabra devkit users. ESD event coincidence is still possible but doubtful. After making a software change, it's lasted for years without failing.

Have you tried to get the dice of these photographed? It'd be nice if we could figure out why the software does what it does, especially those writes to $FFFx.

Based on this anecdote it kinda sounds like it might be an asynchronous reset...

There was a recent decap of a 2C07 that sustained massive damage and the damage was visible.

I haven't tried, if there's someone who will take them I'd gladly desolder and mail some. There is an epoxy blob version, also. I don't remember if I saved the dead ASICs or not, but I'm sure I could come up with a few examples in both formats.

[drludos]

I wrote a small invitro for the jam. NTSC-only because I'm lazy. (The QR code redirects to this thread.)

Uses Famitone 5 by nesdoug and Shiru.

ggjam_invitro_000.png

Woaw, this is awesome! Very cool intro, and with beautiful graphics and nice music.
It's very motivational and inspiring !

The "low-res" graphics are quite nice, it gives the whole intro a "retro" feel.

[Fiskbit]

I just checked, unfortunately my email subscription on the email list was with hotmail, I only recall using the web interface with that address.. so there's almost zero chance of it finding it in my own personal backups (would be LS-120 disks from that era, lol). So my only reference I guess is myself when I added it to the NESdev front page. I'm not even sure when that was, it predates when I started keeping an update history in Aug 2000. And on my PC I have FCE Ultra, version Beta 4, document says "Also a feature unique to this emulator(at the current time) is authentic Game Genie emulation!", Filedate of this FCEU is Jan 18 1999. I ran it in DOSBox and it loads GENIE.ROM dated Dec 13 1998 in the same folder, headerless 16+8 NROM.

It looks like the earliest messages we have in the bb0 archive are from April 1999. The bb1/bb2 archive seems to start around October 2000. I'd love to expand these archives if anyone has additional material. I'm interested in having these viewable online at some point, since I think they're very interesting from a historical perspective and would also help answer useful questions like yours about the communication with Galoob.

[lidnariq]

It is now the 17th! Have fun writing something!

Jroweboy has made a template to use llvm-mos for anyone who wants a really easy quickstart https://github.com/jroweboy/llvm-mos-game-genie-jam

[Punch]

This is a great idea for a jam! I’m in

[freem]

If anyone needs letters/numbers, I've whipped up a few and included them in an archive as both PNG and NEXXT nss files. Feel free to use them.

big-ish letters and numbers:

big-ish_letters.png

big-ish_numbers.png

small letters test:

small_letters_test.png

smaller letters (with lowercase):

smaller_letters.png

lowercase_letters.png

[drludos]

Thanks @freem for sharing the letters and numbers, they are gorgeous!

Good luck everyone, I'm eager to see what you create!

[matthughson]

Just out of curiosity, could a GG ROM theoretically interact with the cart that it is connected to? For example, reading CHR ROM data, or accessing SRAM, etc?

[Dwedit]

I think interaction would be very limited, there's a one-time register write to disable the Game Genie ROM and return back to normal cartridge mode. You could still write to system RAM, jump to system RAM, and enable the cartridge from your RAM code. Not sure if cartridge WRAM is accessible or not.

Also the original Game Genie ROM is only 4KB in size, but it is mirrored to fill 16KB. Has it been confirmed that putting a 16KB PRG ROM on a board will work?

[lidnariq]

Just out of curiosity, could a GG ROM theoretically interact with the cart that it is connected to? For example, reading CHR ROM data, or accessing SRAM, etc?

In Configuration Mode:

* /ROMSEL is not forwarded to the attached cart, which means no functionality in the $8000-$FFFF range can be accessed, and
* the signal that enables the GG ROM is enabled (low) in the $C000-$FFFF range, and that in turn prevents M2 from reaching the cart in those reasons; this means that access to $C000-$FFFF won't be seen at all, and access to $8000-$BFFF will look like access to $0000-3FFF.
* We don't know what the attached cart sees if the software tries to access $4000-$7FFF. (so we don't know if SRAM is accessible)
* PPU A13 is not forwarded to the attached cart, which means that its CHR ROM is not accessible
* PPU /A13 is unchanged, because the GG assumes that the cart has jumpered that to enable nametables in the normal place. (the games that don't do this are incompatible; they either always enable nametables (PPU A13 is always high) or they enable CHR ROM at the normal time (PPU /A13 when it's high) and either way get in a bus conflict with the GG CHR generator.

Also the original Game Genie ROM is only 4KB in size, but it is mirrored to fill 16KB. Has it been confirmed that putting a 16KB PRG ROM on a board will work?

Yes, it's "just" a physical space problem. We know that the ASIC enables its ROM when A14=1 and /ROMSEL=0. The 24-pin mask ROM there doesn't have space for a 28-pin DIP ROM, but having to use DIP isn't a concern

[lidnariq]

An entry from Qalle on the discord

https://codeberg.org/qalle/nes-genie-vortex

A demo for the NES. Uses only Game Genie's CHR ROM data. Shows colourful horizontal lines that appear to be spinning clockwise around the vertical axis in a vortex, viewed from the side. Assembles with ASM6. Not interactive, no audio. Tested on FCEUX only.

GPL3

Not a raster effect!

[Memblers]

It is unfortunate that the GG can't get back into it's configuration mode. On the circuit boards there is some kind of unused thing on there, I always hoped it would be some kind of reset for that, I doubt it is, but I don't know.

If anyone needs letters/numbers, I've whipped up a few and included them in an archive as both PNG and NEXXT nss files. Feel free to use them.

Thanks, I'll use this. It's tempting to write a variable width renderer for this, but I should focus on other features first.

* We don't know what the attached cart sees if the software tries to access $4000-$7FFF. (so we don't know if SRAM is accessible)

Sucks that I don't have a good way to set up my NES right now, that could be tested with GTROM by using the LEDs.

Jroweboy has made a template to use llvm-mos for anyone who wants a really easy quickstart https://github.com/jroweboy/llvm-mos-game-genie-jam

Thanks for this! Very interesting to see CA65 usable with llvm-mos. This setup failed for me at first, it was trying to use a tool called 'Ninja' but it worked after I installed it. https://github.com/ninja-build/ninja/releases I just dropped Ninja.exe in my VS Code/bin folder. I don't know if there is a VS extension for that, the word Ninja turns up a lot of results in the "marketplace".

[matthughson]

I don't really have anything to show yet, but just to throw my hat into the ring:

I'm using the llvm-mos template shared by jroweboy, so I'll be writing my entry in C++. I don't really have spare time for this, so I'll just be putting a few hours in during lunches at work here and there.

My current plan is to make a CONTROLLER + ZAPPER game. My thought is that this could be played in single player (left hand controller, right hand zapper) or in co-op (P1 controller, P2 Zapper).

P1 will control a character from a top-perspective. All they can do is move. Enemies will move in from the sides of the screen trying to destroy a core at the center of the screen. P1 just tries to avoid getting hit. P2 will use the zapper to shoot the enemies, and try to survive as long as possible. Kind of like Robotron, but using the zapper as a gun. It's actually a lot like the homebrew DATAMAN now that I think about it.

See GIF for super minor progress so far (most of it is jroweboy's template)

[drludos]

My current plan is to make a CONTROLLER + ZAPPER game. My thought is that this could be played in single player (left hand controller, right hand zapper) or in co-op (P1 controller, P2 Zapper).

This is a great idea, I love it! Sounds like a cool game to play in co-op with your kids !

I don't have much free time either, but I've made some progress (a working score counter so far) and I'm eager to continue. I should be able to work further during this weekend! I plan to make a simple space shoot'em up game. I will be using CC65 with Neslib and Nesdoug, as that's what I'm used to from a previous project.