Paul's HappyBird - a new game for Atari 2600

[+bsteux]

On 5/18/2023 at 10:45 PM, Al_Nafuur said:

Your score has been transmitted, but it has not been sent with the correct game-id. There are more entries in the database that are affected. It should be easy to correct, but @bsteux we need to fix the error in ROM to prevent this from happening again. I'll investigate further and send you a direct message.

 

 

I have fixed your score and uploaded the screenshot.

 

By the way, players can now upload their screenshots themselves:

 

Here is the source code that sends the high score... Looks simple... Is it possible to check from the program that the comm is OK ? Is my ROM the only one in troubles ?

 

plusrom_send_score	SUBROUTINE
;{
; *WriteToBuffer = game_mode;
	LDA game_mode          	; 3
	STA WriteToBuffer      	; 3
; i = score_high;
	LDA score_high         	; 3
	STA i                  	; 3
; dec_to_bcd();
	JSR dec_to_bcd         	; 6
; *WriteToBuffer = j;
	LDA j                  	; 3
	STA WriteToBuffer      	; 3
; i = score_low;
	LDA score_low          	; 3
	STA i                  	; 3
; dec_to_bcd();
	JSR dec_to_bcd         	; 6
; *WriteToBuffer = j;
	LDA j                  	; 3
	STA WriteToBuffer      	; 3
; *WriteSendBuffer = 60;
	LDA #60                	; 2
	STA WriteSendBuffer    	; 3
	RTS

 

[+bsteux]

On 5/16/2023 at 4:27 AM, ZeroPage Homebrew said:

ZeroPage Homebrew is playing Paul's HappyBird on tomorrow's ZPH stream LIVE on Twitch, hope you can join us!

 

Tue May 16, 2023 | LIVE @ 6PM PT | 9PM ET | 1AM GMT+1Day

WATCH LIVE: https://www.twitch.tv/zeropagehomebrew/
WATCH LATER: https://youtube.com/zeropagehomebrew/

 

Games:

• Frazzled (2023 WIP | 2600) by David Marli @DaveM
• Paul's HappyBird (2023 | 2600) by Bruno Steux @bsteux
• C.H.E.A.T. (2023 WIP | 2600) by Vince Weaver @deater78
• Kovi Kovi (2023 WIP | 2600) by Mashdy Games / Marco Johannes @MarcoJ

(WATCH AT 1080P60 FOR BEST QUALITY)

 

 

Thank you very much for your video, which was particularly appreciated by Paul, my 9 year-old son. Sorry I couldn't see it in direct (I live in France). AtariVox retransmlssion + a high-score in direct live! Wow! Great show.

[+Al_Nafuur]

 

1 hour ago, bsteux said:

Is my ROM the only one in troubles ?

Currently yes. We had a few issues like this before with other ROMs, but they all have been solved.

 

What is happening is that somehow the "WriteToBuffer" is been touched (shortly) after the transmission has been initialized with the write to "WriteSendBuffer". When this happens the internal write pointer of the PlusCart is still pointing to the last byte in the buffer to send (in our case here the game-id) and this byte gets overwritten before it is sent.

 

There a few ways the "WriteToBuffer" can be touched without it being obvious in the code. The case that occurs most often is a "RTS" directly before the "WriteToBuffer" hotspot. The 6507 is doing readahead after an command (usually for the param) rts has no param so the readahead is ignored by the cpu, but for the cartridge it looks like a real access to the address.

I had a look at the ROM and there is no code or data directly before the hotspot, so this seems not to be the case with your ROM.

 

Another way are direct reads/writes to the hotpot, but here too I didn't find any in the ROM.

 

A third way I can imagine is a indexed read/write which is landing at the hotspot, these are more difficult to find in the ROM. They should be easier to find with stella traps. A special case with indexed reads/writes is when they are crossing a page, then the address in the initial page is touched too.. 

 

 

[+bsteux]

14 minutes ago, Al_Nafuur said:

 

Currently yes. We had a few issues like this before with other ROMs, but they all have been solved.

 

What is happening is that somehow the "WriteToBuffer" is been touched (shortly) after the transmission has been initialized with the write to "WriteSendBuffer". When this happens the internal write pointer of the PlusCart is still pointing to the last byte in the buffer to send (in our case here the game-id) and this byte gets overwritten before it is sent.

 

There a few ways the "WriteToBuffer" can be touched without it being obvious in the code. The case that occurs most often is a "RTS" directly before the "WriteToBuffer" hotspot. The 6507 is doing readahead after an command (usually for the param) rts has no param so the readahead is ignored by the cpu, but for the cartridge it looks like a real access to the address.

I had a look at the ROM and there is no code or data directly before the hotspot, so this seems not to be the case with your ROM.

 

Another way are direct reads/writes to the hotpot, but here too I didn't find any in the ROM.

 

A third way I can imagine is a indexed read/write which is landing at the hotspot, these are more difficult to find in the ROM. They should be easier to find with stella traps. A special case with indexed reads/writes is when they are crossing a page, then the address in the initial page is touched too.. 

 

 

In order to avoid these side effects, wouldn't it make sense to wait a little (a few hundred milliseconds should be enough no ?), or better to wait for a feedback from CartPlus (just a flag that would tell that's ok) ? It's very likely that there are many page crossings in my code. As it's written in C, It uses a lot of use of (),Y indexing with page crossing, and the tables located are at the end of each bank (especially the rainbow table... which could be involved in our case). I'll try to have a look in order to find where this happens...

[+Al_Nafuur]

10 minutes ago, bsteux said:

In order to avoid these side effects, wouldn't it make sense to wait a little (a few hundred milliseconds should be enough no ?), or better to wait for a feedback from CartPlus (just a flag that would tell that's ok) ? It's very likely that there are many page crossings in my code.

Unintentional read/writes to hotspots should generally be avoided.

 

In case of the PlusROM functions the access to the WriteToBuffer hotspot after the current request has been done will write arbitrary data to the buffer, which will add unwanted data to the next request. So if we only delay these accesses to the hotspot it will just move the problem to the next request.

 

 

10 minutes ago, bsteux said:

As it's written in C, It uses a lot of use of (),Y indexing with page crossing, and the tables located are at the end of each bank (especially the rainbow table... which could be involved in our case). I'll try to have a look in order to find where this happens...

since the PlusROM hotspots are at the end of the last page, I am not sure how the page crossing has to look like to "ghost" trigger the hotspots. Maybe we should look for real access by indexed reads with traps first..

 

 

 

[+ZeroPage Homebrew]

4 hours ago, bsteux said:

Thank you very much for your video, which was particularly appreciated by Paul, my 9 year-old son. Sorry I couldn't see it in direct (I live in France). AtariVox retransmlssion + a high-score in direct live! Wow! Great show.

 

You're so welcome Bruno, so glad your son enjoyed the show too! The graphics in your game are incredible and it's an extremely rare occurrence where there are three colours on the same line for the character you're controlling, amazing!

 

- James

[+bsteux]

16 hours ago, Al_Nafuur said:

Unintentional read/writes to hotspots should generally be avoided.

 

In case of the PlusROM functions the access to the WriteToBuffer hotspot after the current request has been done will write arbitrary data to the buffer, which will add unwanted data to the next request. So if we only delay these accesses to the hotspot it will just move the problem to the next request.

 

 

since the PlusROM hotspots are at the end of the last page, I am not sure how the page crossing has to look like to "ghost" trigger the hotspots. Maybe we should look for real access by indexed reads with traps first..

 

 

 

Yes, you're right. I can't see how a page crossing could "ghost" trigger the hotspot at the end of the ROM. It's likely a real (),Y which goes too far into the rainbow table, because it's next to the hotspot I think... What I wonder is why I don't see any glitch or anything else unexpected... As soon as I have a little time ahead, I'll make this search with traps and a thorough examination of the source code to sort out the issue...

[+bsteux]

Hi,

I think I've found the issue with PlusROM high scores. Gameover function was possibly called 3 times instead of only once, sending PlusROM data 3 times, and likely overwriting previous buffers, causing incorrect behaviour.

I've replaced :

    if ((*CXP0FB & 0x80) != 0) gameover();
    if ((*CXP1FB & 0x80) != 0) gameover();
    if ((*CXBLPF & 0x80) != 0) gameover();

with

    if ((*CXP0FB & 0x80) != 0) gameover();
    else if ((*CXP1FB & 0x80) != 0) gameover();
    else if ((*CXBLPF & 0x80) != 0) gameover();

Should be better now. I've attached PAL and NTSC corrected binaries (now v1.07 FINAL version).

Still no ghost in the machine this time...

Sorry for all the people who could be the highscore but were not registered. Official high score today in Pro mode is 111 by Zeropage Homebrew (in direct live!) ! Time to beat it.

happybird-v1.07-NTSC-PLUSROM.bin happybird-v1.07-PAL-PLUSROM.bin

[+bsteux]

Hi,

Here is a "technical" update of Paul's Happybird. @Albert asked me to change the savekey address to $1480 due to an issue with savekey address allocations, so here is an updated version. Note that this version was compiled with cc2600 v0.4, which produces a slightly better optimized code - nothing to be noticed by the player...

Regards.

happybird-v1.08-PAL-PLUSROM.bin happybird-v1.08-NTSC-PLUSROM.bin