Game Genie Game mini-jam

[TakuikaNinja]

However, when I went to test it in FCEUX, (using it as the GG image), it boots to a grey screen, and there's no time left to debug that. What's another emu that emulates the Game Genie?

puNES has a GG ROM mode, but it requires a headered .nes file instead of a raw PRG dump. It seems to override the mapper number with its own internal one.

Edit: NintendulatorNRS also supports the GG as a passthrough device using a supplied GG.BIN file. I'm not sure if it does any hash checks, though.

[jroweboy]

I used the llvm-mos sdk. Only thing I ran into trouble with, is putting C code in RAM, it seems like in other compilers I just tag it as 'data' segment and it would work, I still couldn't get it happen with this setup though (using __attribute__((section)). Didn't spend a lot of time on that, as I ran out of time.

I tried your entry out today and it seemed pretty awesome! Great work on what you have so far!

To answer your question, in llvm-mos, it should work like you would expect it to. If you mark a function as

Code: Select all

section(".data")

then the compiler will (in ca65 terms) set the LOAD address to the current code segment, and set the RUN address to the CIRAM segment. From there, on startup, there is a C routine that runs called `__copy_data` which performs the memcpy from the ROM address to the RAM address for all .data segments (ie: data that should be in R/W RAM)

So in short, all you *should* need to do is add

Code: Select all

__attribute__((section(".data")))

to the function, but there may be complicating factors.

For instance if your function got inlined, then maybe it won't show up? Try marking it with

Code: Select all

__attribute__((noinline))

just in case. And then you can also make the function

Code: Select all

extern "C"

so that the name doesn't get mangled (making it easier to find in the symbol maps)

[Punch]

Fixed a ton of stuff on my Chip8 interpreter... there's still some bugs regarding incorrect sprite XORing for some reason, but everything else works properly, including correct PPU initialization which is reason enough to post a corrected ROM.

I will be correcting the remaining bug and expanding on the missing opcodes, functionality etc. in a separate thread, to keep with the spirit of the jam's deadline

[Fiskbit]

I've hacked Galactor to write the new scroll position at the correct time, so it should work on hardware. drludos will probably want to do his own fix at some point, but this gets the job done for people wanting to play it before then.

[drludos]

I've hacked Galactor to write the new scroll position at the correct time, so it should work on hardware. drludos will probably want to do his own fix at some point, but this gets the job done for people wanting to play it before then.

Woaw, thanks a lot for narrowing down the issue, and for fixing it too!

I had noticed that there was a "glitchy" line when the sprite 0 hit was detected and the screen was split and vertically scrolled, but I didn't know how to fix this. I tried moving the call to the the "sprite 0 hit" function call around and also moving the "sprite 0" positon from left to right of screen without success.
So I'm very grateful for your help and expertise, as I wouldn't never been able to fix it on my own!

May I ask you more details on how you fixed the issue so I can fix it in the game source code? (i.e. what assembly code did you change?)

The game was coded in C using NesLib and NesDoug (v1.3 - 2022), and I used NesDoug's xy_split() function to do this effect. I guess the issue is related to how I (mis)used this function in my game, but here is its assembly code from the library if it can be helpful:

Code: Select all

;void __fastcall__ xy_split(unsigned int x, unsigned int y);
_xy_split:
	;Nametable number << 2 (that is: $00, $04, $08, or $0C) to $2006
	;Y to $2005
	;X to $2005
	;Low byte of nametable address to $2006, which is ((Y & $F8) << 2) | (X >> 3)

	sta <TEMP+2 ;y low
	stx <TEMP+3
	jsr popax
	sta <TEMP ;x low
	stx <TEMP+1
	
;push to stack in reverse order	
	lda <TEMP+2 ;low y
	and #$f8
	asl a
	asl a
	sta <TEMP+4
	lda <TEMP ;low x
	lsr a
	lsr a
	lsr a
	ora <TEMP+4
	pha
	
	lda <TEMP ;low x
	pha
	
	lda <TEMP+2 ;low y
	pha

	lda <TEMP+3 ;y high
	and #$01
	asl a
	sta <TEMP+4
	lda <TEMP+1 ;x high
	and #$01
	ora <TEMP+4
	asl a
	asl a
	pha

@3:

	bit PPU_STATUS
	bvs @3

@4:

	bit PPU_STATUS
	bvc @4

	pla
	sta $2006
	pla
	sta $2005
	pla
	sta $2005
	pla
	sta $2006
	rts	

And here is what I do in my own code to call it and do the screen split (simplified for more readibility, full source is available alongside the game ROM, but I wrote down all the code performed right after the VBLANK up to the call to the screen split function):

Code: Select all

	//Wait for Vblank
	ppu_wait_nmi();
	
	//Read First controller current state
	pad0=pad_poll(0);
	
	//If we are currently in the gameplay state
	if( STATE == 1 ){
			
		//If the GAME IS NOT PAUSED
		if( game_paused == 0 ){
		
			//==== SPLIT SCROLLING ====
				
			//Update starfield position using its current speed
			if( ticks_fast ){ --scrollingPos; }
			
			//Make it loop 0-239 to avoid "hicups", as it's only 30*8=240 pixels tall
			if( scrollingPos > 239 ){ scrollingPos = 239; }	
				
			//Wait for Sprite 0 Hit to trigger a split scrolling : we start with the GUI (X scroll = 0), then we wrap to the second nametable (starfield, X = 256) and make it scroll endlessly in Y
			xy_split(256, scrollingPos);

[Denine]

Hi,
When I first heard of Game genie jam I was quite excited. At first, I planned a puzzle type game but unfortunately on start day of the jam my life suffered problems on several fronts.
Only on 30th, I was able to work a bit on the game. I changed genre of the game to infinite runner. I submitted that ROM before deadline to keep within the rules. Today I was able to polish it a bit, enough to be worthy of uploading here.
The game is very rough and I dont think I'll have the time to improve it any further.
Thanks to SuperNatetendo for all the art.

[Fiskbit]

I've hacked Galactor to write the new scroll position at the correct time, so it should work on hardware. drludos will probably want to do his own fix at some point, but this gets the job done for people wanting to play it before then.

May I ask you more details on how you fixed the issue so I can fix it in the game source code? (i.e. what assembly code did you change?)

The key thing is that the 3rd and 4th writes of the $2006/$2005/$2005/$2006 sequence need to land during the OAM fetch region in hblank so that they do not conflict with any nametable fetches or, most importantly, the automatic increments of the PPU's internal v register (this v increment collision is what causes your problem). This is easily done by just adding a delay (a do-nothing loop) before these writes, and using Mesen's event viewer to calculate how long the delay should be and fine-tune it.

Unfortunately, I couldn't find any free space in the ROM at a glance that I could use to insert the delay loop, so I instead optimized the function starting at the first of the two "ora <TEMP+4" instructions in the code you posted.

Code: Select all

; This now stashes in Y.
CA4F    ORA $22
CA51    TAY

CA52    LDA $21
CA54    AND #$01
CA56    ASL A
CA57    STA $22
CA59    LDA $1F
CA5B    AND #$01
CA5D    ORA $22
CA5F    ASL A
CA60    ASL A
; We don't use A until this value is needed, so I just let 
; the value persist in A until then.

CA61    BIT PpuStatus_2002
CA64    BVS $CA61

CA66    BIT PpuStatus_2002
CA69    BVC $CA66

; This is the new delay loop.
CA6B    LDX #$24
CA6D    DEX
CA6E    BNE $CA6D

; The important thing here is that the 3rd and 4th writes
; land roughly in the first 64 dots of hblank. The 3rd write
; updates fine x, which you don't want during the visible
; portion of the scanline, and the 4th copies the PPU's t
; register to its v register, which must not take effect before
; dot 257 or so. The timing of the first two writes doesn't matter
; much; they just need to be anytime after dot 257 of the
; *previous* scanline, so there is a lot of leeway.
CA70    STA PpuAddr_2006
CA73    LDA $20
CA75    STA PpuScroll_2005
CA78    LDA $1E
CA7A    STA PpuScroll_2005
CA7D    STY PpuAddr_2006
CA80    RTS

[drludos]

Wonderful! Thanks a lot for the commented explanation and source code to the fix, I'll try to implement it in the game source code then .

I'm also pinging @dougeff as this issue is actually present in NesDoug library. Now that you've discovered it, I've retried NesDoug's XY split example, and it also displays the same issue. And the code you fixed is indeed part of the library.

[drludos]

Ok, i've added your fix to the game, and shared the updated ROM and source code online:
https://drludos.itch.io/galactor/devlog ... -starfield

I managed to free some bytes in the source code and added the delay loop as instructed. Of course Fiskbit you're credited for this incredible work, and I'm thanking you again for going the extra mile to bugfix my game and explain me how you did it! I've learned a lot about the NES during this Jam . (and I still have a lot to learn!)

Also, as the fix was made on the NesDoug's library XY screen split function, I'm attaching here the bugfixed library file in case anyone else is doing a XY split game in C with NesDoug.

[Fiskbit]

The exact timing for the fix is going to depend on when your sprite 0 hit happens. Yours is at the start of the scanline, so you need a long delay. The delay needs to be shortened by 1 cycle for every 3 dots, though there's some leeway so that exact timing isn't critical. If the hit is at the right edge, you don't want any delay at all.

Happy to have helped out. You made a very impressive entry and it'd be a shame to have it not work on hardware.

[lidnariq]

Here's an archive containing all of the entries! Thanks to sylvie.

GameGenieJam-All Entries together.zip

I'd also like to ask people to give their feedback on the jam. What worked, what didn't work, what we should definitely do the same for future jams, what we should try to do differently.

Was two weeks' advance notice good? Was two weeks long good? Should either be adjusted? What did you specifically like / dislike?

[tepples]

I was just bummed that I had to miss the Game Boy jam, the SNES jam, and this jam, because all happened to occur while I was busy with crunch time on Haunted: Halloween '87, which we just finished this weekend.

[Punch]

I'd also like to ask people to give their feedback on the jam. What worked, what didn't work, what we should definitely do the same for future jams, what we should try to do differently.

Was two weeks' advance notice good? Was two weeks long good? Should either be adjusted? What did you specifically like / dislike?

It was great! IMO we need more heavily constrained compos/jams. Fun to work with, easier to get motivated, experiment and to finish something cool. A short deadline gives it a sense of urgency too.

Though I only found out about the jam on the start date, a @everyone on discord if we were supposed to know about it in advance would have been appreciated

[drludos]

I'd also like to ask people to give their feedback on the jam. What worked, what didn't work, what we should definitely do the same for future jams, what we should try to do differently.

Was two weeks' advance notice good? Was two weeks long good? Should either be adjusted? What did you specifically like / dislike?

I really enjoyed this Jam, the theme / constraints was unique and very fun to work on. Thanks again a lot for running such a cool event!

Regarding feedback, I think the overall formula worked great as shown by the many entries.

I do have a couple of suggestion (but this is just my opinion / personal feedback)

- Regarding duration, 2 weeks / 14-15 days is great. But I would slightly alter the starting and ending date to include 3 weekends. I know that personally, it's during the weekend that I can find the most "free time" to work on hobby projects. So if the jam was starting say a Friday, and end 17 days after on a Monday that would be greater as I'll get an extra "weekend" to work on the game.

- Regarding communication, I think that maybe we should try to spread the word larger to have more participants. I personnaly heard about it on the Reddit r/retrogamedev sub. I've been a member of NesDev forums for years, but I only come from time to time, so I may have missed it if it wasn't mentioned on this reddit sub that I read more often.

- Entries exposure. I don't know if this is dumb idea or not, but maybe we could have more players aware of the entries if the Jam was run on itch.io? There are a lot of NES games released on this site, so many NES players / homebrew enthusiats come here already, but may not go on NesDev forums as they are not developers but players. I said that as I published my game on itch.io, like I do for all my projects. According to itch.io stats, of the ~60 people that downloaded my game (thanks!), about half of them seems to have found it by browsing Itch.io catalog (thanks to the tags "nes-rom" and "nes").
Even if this jam is also hosted/published on Itch.io, it doesn't prevent you from accepting entries from the NesDev forum, in case some developers don't to want to set up an account of this site. I mean we shouldn't make itch.io mandatory, but only an "extra channel" to give entries more exposure to players.

[Memblers]

Thanks for the tips with llvm-mos, I'll have to try that again soon.

Worth noting if anyone uses my demo ROM, the sound mode init address entered ends up getting ignored and it's forced to $8000/$8003, intended to test with Capcom games. Since that was hacked in the last hours of the deadline, then couldn't be tested anyways. I'll update that part when I can get it properly tested.

So far my little app doesn't work on any emulators. puNES does run the ROM (after typing the name into the cfg file), but it acts like won't enter game mode. The JSR $8000 part just ends up back at my program's menu. It looks like I'm doing all the stuff to enter game mode, and patching the NMI vector, but I've not tested it on hardware yet, either.

NintendulatorNRS has the memory size fixed to 4kB, it's maybe easy to change that in the source, but I can't build it without lots of errors, I can't get into the right build environment. It looks like it was using Win 7.1 SDK, and this turns out to be weirdly difficult to install on Windows 10. Ugh.

The $FFF0, $FFF1, $FFF0 sequence happens about 8 frames in, which is the top of main(). In the original GG, IIRC this happens much sooner after power-on (though it shouldn't matter for emulation). Then there's a delay after that, I assume it's there so you can't skip through the menu super fast because presumably the ASIC isn't ready immediately. The actual handover to game mode starts at $0100, after pressing A on the sound mode screen, if anyone wants offer a second opinion.

Maybe some of these emulators are going by the ROM CRC and I'm not noticing. There is only one GG ROM revision known.