Juno First - Final Version (Atari 2600)

[Mayhem]

Before I transfer this latest build to my CC2 to play (and maybe attach the AtariVox to see if all works okay on a 7800) I tried it out in Stella 2.6 and spotted something. Not sure if this is Stella or the build, but the first time I get a high score, I enter my initials as I'm supposed to. Next time though I don't and the highscore table has wiped again (although the BEST score line down the bottom still retains my best score). Perhaps something isn't fully emulated yet...? Not sure. Just thought I'd mention it. Will check what happens later if possible with the real thing...

[mos6507]

I'm still having AtariVox issues. I got it to stop giving read errors again, but now it looks like the writes aren't taking or something because the scores don't stick. Every time the game ends my score just goes to the top and whatever was there disappears.

[cd-w]

Before I transfer this latest build to my CC2 to play (and maybe attach the AtariVox to see if all works okay on a 7800) I tried it out in Stella 2.6 and spotted something. Not sure if this is Stella or the build, but the first time I get a high score, I enter my initials as I'm supposed to. Next time though I don't and the highscore table has wiped again (although the BEST score line down the bottom still retains my best score). Perhaps something isn't fully emulated yet...? Not sure. Just thought I'd mention it. Will check what happens later if possible with the real thing...

 

Is the game definitely detecting the SaveKey (it should say "Found" at the bottom of the startup screen)? You need to reload the ROM after setting up the SaveKey in Stella, otherwise you will get the issues that you describe above. If this is not the problem, can you send me a copy of your eeprom file (should be called savekey_eeprom.dat or atarivox_eeprom.dat) and I will take a look.

 

Thanks,

Chris

[Mayhem]

Find the DAT file attached. What I've found is that the first score recorded is saved fine. All the rest are not. Whenever you reboot Stella you get the hiscore table back but it's only got the scores it saved in it, in other words all those "first attempts" after booting it up each time.

atarivox_eeprom.zip

[+Nathan Strum]

I'm getting the same thing in Stella 2.6. It will save your first score after reloading the ROM, but not subsequent ones in the same session. If you reload the ROM again, it will show all of the successfully saved scores, and let you save the first game you play. But after the second game, none of the scores show up, and it won't save. I have yet to try beta 6 on real hardware.

[+stephena]

I'm getting the same thing in Stella 2.6. It will save your first score after reloading the ROM, but not subsequent ones in the same session. If you reload the ROM again, it will show all of the successfully saved scores, and let you save the first game you play. But after the second game, none of the scores show up, and it won't save. I have yet to try beta 6 on real hardware.

Can you provide a quick HOWTO on how to replicate this? I don't see this behaviour in Stella, but at the same time it's very likely it could be an EEPROM emulation bug (as that functionality is very new).

 

EDIT: nevermind, I see what you're talking about now. I can save one score in Beta6, but if I get a higher score next time (within the same session), it cannot be saved. Also, in Beta5, this was fine; obtaining increasingly higher highscores allows one to save them (and they're loaded again each time). However, that same EEPROM data doesn't show any highscores when loaded in Beta6. But when reloading in Beta5, the scores are still there. So they haven't been erased; Beta6 just doesn't see them.

Edited May 18, 2008 by stephena

[cd-w]

EDIT: nevermind, I see what you're talking about now. I can save one score in Beta6, but if I get a higher score next time (within the same session), it cannot be saved. Also, in Beta5, this was fine; obtaining increasingly higher highscores allows one to save them (and they're loaded again each time). However, that same EEPROM data doesn't show any highscores when loaded in Beta6. But when reloading in Beta5, the scores are still there. So they haven't been erased; Beta6 just doesn't see them.

 

There seems to be a bug in my code here, rather than a bug in stella. Incidentally, the highscore table format has changed between Beta5 and Beta6, so you won't be able to see your old scores in the new version. It might be necessary to wipe the EEPROM (by holding right and fire during the titles) before it will work. I'm currently investigating to see if I can find the root cause of the problem ...

 

Chris

[cd-w]

I'm getting the same thing in Stella 2.6. It will save your first score after reloading the ROM, but not subsequent ones in the same session. If you reload the ROM again, it will show all of the successfully saved scores, and let you save the first game you play. But after the second game, none of the scores show up, and it won't save. I have yet to try beta 6 on real hardware.

 

Hmm - I think this may be a Stella problem after all. I tried it on real hardware and it seems to work fine. The problem is in the SaveKey detection code. I'm using the code shown below to detect if the SaveKey is connected. At the end of this code, the Carry flag should be clear if a SaveKey is present. It seems to work the first few times it is called, but after writing the high-scores it seems to fail for some unknown reason (I'm using the standard i2c.inc subroutines and macros).

 

Chris

 

 ; Check If Savekey Is Present (and Set Bank)
CheckSaveKey
; Check For Savekey
 jsr i2c_startwrite	   ; 286
 bcs NoCard			   ; 2/3
; Set Bank Address (Hi)
 lda #BANKHIGH			; 2
 jsr i2c_txbyte		   ; 270
; Set Bank Address (Lo)
 lda #BANKLOW			 ; 2
 jsr i2c_txbyte		   ; 270
NoCard
; Finish Writing
 jmp i2c_stopwrite		; 48

[+stephena]

I'm getting the same thing in Stella 2.6. It will save your first score after reloading the ROM, but not subsequent ones in the same session. If you reload the ROM again, it will show all of the successfully saved scores, and let you save the first game you play. But after the second game, none of the scores show up, and it won't save. I have yet to try beta 6 on real hardware.

 

Hmm - I think this may be a Stella problem after all. I tried it on real hardware and it seems to work fine. The problem is in the SaveKey detection code. I'm using the code shown below to detect if the SaveKey is connected. At the end of this code, the Carry flag should be clear if a SaveKey is present. It seems to work the first few times it is called, but after writing the high-scores it seems to fail for some unknown reason (I'm using the standard i2c.inc subroutines and macros).

Partially confirmed on my end. I enabled debugging info for EEPROM access, and it seems that the second access is causing a problem. In I2C access, SCL=1/SDA=1 followed by SCL=1/SDA=0 should indicate an I2C_START operation. However, in this case, it's responding with I2C_BUSY, causing the autodetection to fail.

 

I think this is a timing issue not related to your code. Hopefully I can figure this out and address it in the 2.6.1 release sometime next week. One final thing; are you making sure to wait at least 5ms between writes?

 

EDIT: OK, I've determined the problem and just committed code to fix it. Saving highscores now works fine in Beta6.

Edited May 19, 2008 by stephena

[+Nathan Strum]

Also noticed that with Stella 2.6, the music is skipping in the latest beta version (beta 6). It still seems fine in beta 5. (The music doesn't skip on real hardware.)

Edited May 19, 2008 by Nathan Strum

[+stephena]

Also noticed that with Stella 2.6, the music is skipping in the latest beta version (beta 6). It still seems fine in beta 5. (The music doesn't skip on real hardware.)

This is due to the increase in scanlines from 262 to 266. The current timing in Stella is pretty primitive, and it's something I'd like to fix soon. There are only two timing modes: 60 fps (NTSC) and 50 fps (PAL). What really should be happening is the timing to be calculated based on the number of scanlines. I'm pretty sure this is the issue since if you force Beta6 to run as PAL, the sound is fine. It's somewhat slower, of course, but there's enough 'time' to not miss any notes.

 

So please don't waste time looking for an issue with the ROM for this problem; it's definitely something I need to fix in Stella.

[cd-w]

I think this is a timing issue not related to your code. Hopefully I can figure this out and address it in the 2.6.1 release sometime next week. One final thing; are you making sure to wait at least 5ms between writes?

 

I didn't realise it was necessary to wait between writes (it isn't mentioned in the AVox guide) - how many cycles is 5ms?

 

EDIT: OK, I've determined the problem and just committed code to fix it. Saving highscores now works fine in Beta6.

 

Many thanks - it is very useful to be able to use Stella for AVox/SavekKey programming!

 

This is due to the increase in scanlines from 262 to 266. The current timing in Stella is pretty primitive, and it's something I'd like to fix soon. There are only two timing modes: 60 fps (NTSC) and 50 fps (PAL). What really should be happening is the timing to be calculated based on the number of scanlines. I'm pretty sure this is the issue since if you force Beta6 to run as PAL, the sound is fine. It's somewhat slower, of course, but there's enough 'time' to not miss any notes.

 

Yes, the sound issue happened when I changed the number of scanlines. It would be great if Stella could display the number of scanlines for each frame - this is the only reason why I still use z26.

 

Thanks,

Chris

[Thomas Jentzsch]

I didn't realise it was necessary to wait between writes (it isn't mentioned in the AVox guide) - how many cycles is 5ms?

I fell for the same problem. You have to wait 5ms after writing before starting reading. It's described in the I2C protocoll documentation.

 

~5200 cycles. Or you do just one read/write per frame.

[cd-w]

I fell for the same problem. You have to wait 5ms after writing before starting reading. It's described in the I2C protocol documentation. ~5200 cycles. Or you do just one read/write per frame.

 

Thanks, that is very useful to know. Does this include the "fake writes" that are used to set the starting address?

 

Chris

[+Nathan Strum]

Yes, the sound issue happened when I changed the number of scanlines. It would be great if Stella could display the number of scanlines for each frame - this is the only reason why I still use

Would this also be causing every other chunk of the Juno First logo to blink periodically (about once a second) on real hardware? I hadn't noticed this before. I'll try loading up beta 5 again and see if it does it there.

 

Edit: Nope - the beta 5 logo is solid. The blinking started in beta 6.

Edited May 19, 2008 by Nathan Strum

[cd-w]

Would this also be causing every other chunk of the Juno First logo to blink periodically (about once a second) on real hardware? I hadn't noticed this before. I'll try loading up beta 5 again and see if it does it there.

Edit: Nope - the beta 5 logo is solid. The blinking stared in beta 6.

 

I though there might be unexpected consequences moving to 266 scanlines! I can see two possible solutions:

 

1. Only the main game needs 266 scanlines, but I'm not sure if switching between 262 and 266 will cause screen rolls. I have attached a new version which uses 262 scanlines for the titles and 266 in-game. Let me know if this works OK?
   
2. The first 3 scanlines (the vertical sync region) are wasted. If I could use these lines, then I could bring the game back to 262 scanlines. However, I remember reading somewhere that doing work during this region can cause problems with some TVs. Has this ever been shown or is it just a theory?
   

 

Chris

Juno_First_BETA6b_NTSC.bin

Juno_First_BETA6b_PAL60.bin

[+stephena]

I didn't realise it was necessary to wait between writes (it isn't mentioned in the AVox guide) - how many cycles is 5ms?

Hmm, you're right; it isn't in the AVox documentation. As Thomas said, it's in the EEPROM specifications. Basically, when you 'write' to the device, what's really happening is the data is being cached internally in a 64-byte buffer. The writes don't occur immediately, and you're free to send data one byte after another with no restriction on timing (up to 64 bytes). When you're finished sending the data, you send a STOP signal. At this point, the STOP commits the internal buffer to the actual EEPROM. The specs say this can take up to 5 ms, in which time you cannot start another read or write operation. If you try, Stella will simply not respond, just as the real EEPROM would not.

Thanks, that is very useful to know. Does this include the "fake writes" that are used to set the starting address?

No, it only happens when committing from the internal buffer to EEPROM (ie, real writes).

Yes, the sound issue happened when I changed the number of scanlines. It would be great if Stella could display the number of scanlines for each frame - this is the only reason why I still use z26.

This is on my TODO list. Perhaps I can get it done for 2.6.1.

[Hornpipe2]

The first 3 scanlines (the vertical sync region) are wasted. If I could use these lines, then I could bring the game back to 262 scanlines. However, I remember reading somewhere that doing work during this region can cause problems with some TVs. Has this ever been shown or is it just a theory?

You can do work in that portion, but don't do anything that would touch the TIA.

 

EDIT:

You can do stuff during VSYNC if you want. Some games do. And why not? It's 3 scanlines of wasted time otherwise. I've put a horizontal positioning routine there before.

 

http://www.atariage.com/forums/index.php?s...t&p=1374673

Edited May 19, 2008 by Hornpipe2

[+SpiceWare]

[*]The first 3 scanlines (the vertical sync region) are wasted. If I could use these lines, then I could bring the game back to 262 scanlines. However, I remember reading somewhere that doing work during this region can cause problems with some TVs. Has this ever been shown or is it just a theory?

I've got a bit of stuff running in MM during the vertical sync. I think changes to video shouldn't be done, but anything else should be OK.

 

VerticalBlankGameCode
	lda #$82
	sta WSYNC
	sta VSYNC			; 3	start vertical sync, D1=1
	sta VBLANK		   ; 3  6 start vertical blank and dump paddles to ground
	lda #$2C			 ; 2  8 set timer for end of Vertical Blank
	sta TIM64T		   ; 4 12
	bit GameOptions
	bmi SetAIPSdemogame
	lda #<AIPS		   ; 2 14
	sta MaxMoveAmount	; 3 17
	lda #>AIPS		   ; 2 19
	sta MaxMoveAmount+1  ; 3 22
	lda GameOptions	  ; 3 25
	and #%00001100	   ; 2 27 get speed, 0-3
	lsr				  ; 2 29
	lsr				  ; 2 31
	clc				  ; 2 33
	adc FireBallsInPlay  ; 3 36
	ldx FireBallsInPlay  ; 3 39
	beq Times16		  ; 2 41 3 42   if no fireballs then don't subtract
	sec				  ; 2 43
	sbc #1			   ; 2 45
Times16
	asl				  ; 2 47
	asl				  ; 2 49
	asl				  ; 2 51
	asl				  ; 2 53
	clc				  ; 2 55
	adc MaxMoveAmount	; 3 58
	sta MaxMoveAmount	; 4 62
	bne .sync	
SetAIPSdemogame		
	lda #<AIDEMO		 ; 2 14
	sta MaxMoveAmount	; 3 17
	lda #>AIDEMO		 ; 2 19
	sta MaxMoveAmount+1  ; 3 22 
.sync
	sta WSYNC		; 1st line of vertical sync
lda DeadPlayers   ; 3
and #%00001111	; 2 5
eor #%00001111	; 2 7
and HumanPlayers  ; 3 10
bne AhumanStillLives
lda M0DirSpeed	   ; if all humans are dead then max speed
ora #%11100000	   ; on fireballs.  Due to M0/M1/Bl swapping
sta M0DirSpeed	   ; all fireballs will be maxed in 3 frames
AhumanStillLives
	lda #0
	sta PF0
	sta PF1
;		sta PF2
	sta WSYNC		; 2nd line of vertical sync
	RANDOM
	lda #WingColor
	sta DragonColor1
	lda #BodyColor
	sta DragonColor2
	lda #0
	inc Frame
	sta WSYNC		; 3rd line of vertical sync
	sta VSYNC		; stop vertical sync, D1=0

[+Nathan Strum]

Only the main game needs 266 scanlines, but I'm not sure if switching between 262 and 266 will cause screen rolls. I have attached a new version which uses 262 scanlines for the titles and 266 in-game. Let me know if this works OK?

Seems to have done the trick. The logo is blink-free again. There seems to be a slight hop when going from the title screen into the game, but it's not really noticeable.

[cd-w]

You can do stuff during VSYNC if you want. Some games do. And why not? It's 3 scanlines of wasted time otherwise. I've put a horizontal positioning routine there before.

http://www.atariage.com/forums/index.php?s...t&p=1374673

 

Thanks for the link - that is a very useful discussion.

 

I've got a bit of stuff running in MM during the vertical sync. I think changes to video shouldn't be done, but anything else should be OK.

 

I'm going to adopt this approach as the switch between 262/266 scanlines seems to be causing some problems. I notice that you are actually writing to PF0/1 in this code, so I guess not all video changes cause problems?

 

Chris

Edited May 20, 2008 by cd-w

[+SpiceWare]

missed that, so I guess not.

[cd-w]

Seems to have done the trick. The logo is blink-free again. There seems to be a slight hop when going from the title screen into the game, but it's not really noticeable.

 

Thanks to everyone for continuing to test this game. I have produced a new version (attached), which puts code in the vblank area to give a steady 262 scanlines. It is possible that this may cause problems with some TVs, so let me know if you have any issues. I've also added a "Get Ready!" message before the game begins, but I'm not sure if I like it yet so let me know what you think.

 

Chris

Juno_First_BETA6c_NTSC.bin

Juno_First_BETA6c_PAL60.bin

Edited May 20, 2008 by cd-w

[+Propane13]

I like the Get Ready message.

 

-John

[supercat]

I didn't realise it was necessary to wait between writes (it isn't mentioned in the AVox guide) - how many cycles is 5ms?

 

About 80 scan lines. Realistically, you should simply figure on one write per frame and not worry about the precise time. If you're drawing 192 lines, you'll spend 12.2ms drawing the display and 4.4ms in overscan and vblank combined. So if you draw the display between EEPROM operations, you'll have plenty of time even worst-case (e.g. if someone is using their AtariVox in the freezer); if you don't, unless you're using a much smaller than normal display window, it won't be possible to have enough wait without spanning the display draw.

 

Incidentally, I think Strat-O-Gems writes five bytes to the buffer in overscan and five bytes in vblank; it doesn't actually commit the write until everything is written.