High score causes EEPROM failure in Self Test.

[bakerhillpins]

0.86 PE

If a player collects a Tesseract and gets a high score it gets displayed next to their initials in the HS Table. If you then go into Self Test the EEPROM will be marked bad and the High Score table will be reset.

I'll try to get a pic of the error # from the ST screen.

A normal HS (without the Tesseract icon) doesn't have this issue.

[bakerhillpins]

Here's the error code:

[jessaskey]

aight!! I found this bug... it wasn't where I thought it would be but I did find an issue.

[bakerhillpins]

FYI.. played a bunch just now and filled up the HS table with my scores. When I went into ST I saw the same EEPROM error code and of course all scores were cleared. Just in case the bug you fixed only occurs with the Tesseract icon.

[jessaskey]

Okay, the bug I fixed was just for the Tesseracts... so I will walk through the code for a general score save... I guess that the issue must be that the checksum of the data is not correct so it is being cleared. The only time that the checksum is checked is..

1. Self Test - Only looks at bad flags and displays them, no further action is taken... however as soon as you turn off ST, then you get the 'Game Boot' below where actions will be taken on a bad CSUM.
2. Game Boot - If CSUM is wrong here, it will do the 'default' action for that bad data block (high scores = reset to defaults, warps = reset to classics, statistics = reset to zero, etc)

[jessaskey]

Lets see if this works in 0.87 for your hardware as Im no longer able to duplicate it in MAME now.

[bakerhillpins]

This is getting weird.. I played and obtained the 1st Tesseract and obtained a high score by getting to and dying on level 11. I entered my initials. I then continued the game to Level 10 but let myself get killed off at the space battle. Here's the HS table:

When I went into Self Test it reported the following error:

When I exited Self Test the High Scores remained where I expected them to have been cleared. Now when I go into Self test the EEPROM is reported to be good. Stays that way even though I go into/out of ST now.

[bakerhillpins]

I've not seen this in a LONG time.

[jessaskey]

Okay, I will mark it is as closed in this release. I was pretty sure it was fixed but wasn't 100% sure.

[jessaskey]

I think this one is back based upon a text from @bakerhillpins yesterday where the same thing happened with an Extra life causing the EEROM error... back to investigation.

[bakerhillpins]

Sorry for the delay in updates here.

I reported #225, where we figured the next status change would result in the data being updated to decimal display. I then played a game where I got an extra life and a tesseract which should have updated the stats. When I went to view them I now saw this EEPROM error:

Since that time I've played games where I updated more stats and the screen now reports this error:

[jessaskey]

Ongoing saga comment on this one... you had texted me with the process of randomizing the warps and them not saving, PLUS causing an EEROM error. I thought that this was something I could definitely duplicate in MAME to try and solve this puzzle. BUT, unfortunately in MAME, everything seems to work... I can randomize warps... exit self test... go back into self test... no EEROM errors AND warps are saved.

Im thinking that you really might have a bad EEROM at this point... What do you think? Do you have another EEROM that you can swap with a different game to test this out?

[bakerhillpins]

I'll put in my OEM ROMs and see what they say but I'm not so sure it's bad. I wonder if my old data has been retained. I'll look around to see if I have another EEPROM that I can use or I'll try to order one. I didn't have any EEPROM issues until 2 things happened, you updated the stats display so that it wouldn't display HEX, and I played a game where I got an extra life AND I visited the 1st secret level. Both of which are supposed to update the stats.

Can you explain to me what each bit means in the error display above?

I may also go back to the set of ROMs with the HEX display error and see what happens.

Should we add a way to clear/reset the EEPROM?

[jessaskey]

Yes the bits above signify a failed checksum..... when all checksums are good... the 8 bytes are all 0... but if one of the 8 checksums are bad, then a 1 is shown for that position.

Here is the listing file for all the EEROM data sections.. the bits for the display are 'backwards' just like the input/output bits screen that we talked about.... D7 is leftmost and D0 is rightmost. Your last picture is saying that the XLives+Warps/GameStats/MazeStats and OptionSwitch data checksums are ALL bad... which is a lot... something had to have gone severely wrong to cause that. the EEROM is address $6000-$67FF and those 4 flags mean that the data between $6000-$610D (4 segments) had bad checksums.

Upon looking at this code... it needs some cleanup... the original code that Owen wrote only had two segments (High Scores and Initials)... I used the same concept but took it out to 8 segments. It is pushed to it's limit for sure, literally.

0990   97D0             ;******************************************************
0991   97D0                     .sbttl "EEROM Applications"
0992   97D0             ;******************************************************
0993   97D0             ;* If bit is set, that section is either read or      
0994   97D0             ;* written depending of request byte in                   
0995   97D0             ;*      Bit 0 = 00000001 = High Scores   
0996   97D0             ;*      Bit 1 = 00000010 = Initials                         
0997   97D0             ;*      Bit 2 = 00000100 = XLives+Warps Stats
0998   97D0             ;*      Bit 3 = 00001000 = Game Stats 
0999   97D0             ;*      Bit 4 = 00010000 = Maze Stats               
1000   97D0             ;*      Bit 5 = 00100000 = Option Switches 
1001   97D0             ;*      Bit 6 = 01000000 = Defined Warp Data  
1002   97D0             ;*      Bit 7 = 10000000 = Tesseract Data 
1003   97D0             ;******************************************************
1004   97D0             eflg_scores     = $01 
1005   97D0             eflg_initials   = $02  
1006   97D0             eflg_xwarp      = $04
1007   97D0             eflg_game       = $08  
1008   97D0             eflg_maze       = $10   
1009   97D0             eflg_option     = $20   
1010   97D0             eflg_warpco     = $40     
1011   97D0             eflg_tesser     = $80            
1012   97D0             ;******************************************************
1013   97D0             ; teax is the table for length of data chunk
1014   97D0             ;******************************************************       
1015   97D0 0C          teax    .db cksumhs-hscore          ;Scores
1016   97D1 09                  .db cksumit-initl           ;Initials  
1017   97D2 10                  .db cksumxw-extlie          ;XLives+Warps
1018   97D3 10                  .db cksumgs-game1           ;Game Stats
1019   97D4 C8                  .db cksummz-mzstats         ;Maze Stats
1020   97D5 02                  .db cksumop-options         ;Options 
1021   97D6 0E                  .db cksumwc-warpcodes       ;Warp Codes 
1022   97D7 03                  .db cksumts-tessers         ;Tesseracts
1023   97D8             
1024   97D8             ;RAM Buffer Location for the EEROM data tranfer
1025   97D8 07 07       teasrl  .dw hscore                  ;Scores
1026   97DA FD 06               .dw initl                   ;Initials
1027   97DC 03 06               .dw extlie                  ;XLives+Warps
1028   97DE 14 06               .dw game1                   ;Game Stats
1029   97E0 25 06               .dw mzstats                 ;Maze Stats
1030   97E2 00 06               .dw options                 ;Options 
1031   97E4 EE 06               .dw warpcodes               ;Warp Codes 
1032   97E6 14 07               .dw tessers                 ;Tesseracts
1033   97E8                     
1034   97E8             ;EEROM Locations for the data transfer
1035   97E8 27 61       teadel  .dw hscore-starts+eerom     ;Scores
1036   97EA 1D 61               .dw initl-starts+eerom      ;Initials
1037   97EC 23 60               .dw extlie-starts+eerom     ;XLives+Warps
1038   97EE 34 60               .dw game1-starts+eerom      ;Game Stats
1039   97F0 45 60               .dw mzstats-starts+eerom    ;Maze Stats
1040   97F2 20 60               .dw options-starts+eerom    ;Option 
1041   97F4 0E 61               .dw warpcodes-starts+eerom  ;Warp Codes
1042   97F6 34 61               .dw tessers-starts+eerom    ;Tesseracts
1043   97F8             
1044   97F8             ;teasrh  = teasrl+1

[MajorHavoc]

That’s a new one. Is it possible the NVRAM is failing? I’d also look at the size of the high score and see if it is writing over other data because it got too large?  I don’t think I ever checked for a score that could be too big. Sent from my iPhoneOn Jan 12, 2023, at 8:46 PM, Jess Askey @.***> wrote:

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[bakerhillpins]

So it is possible that the NVRAM is, or has failed and I plan to be looking into that later today. However, this was working until we updated the code and now it's not so that seems a bit suspicious. I might take the time to try and locate another set of ROM chips so I can burn back to a build where I knew all of this worked as another test.

[bakerhillpins]

I went back to the 1.01beta build you emailed to us on Dec 29th and it doesn't have any issues with the EEPROM. So it's something that's changed since that build.

[jessaskey]

And... just to clarify Bryan... with that last set of build ROM's I sent you... did you end up burning the 4 Alpha ROM's AND the Gamma ROM? That change on Dec 29th might have required a new Gamma ROM to be burned as well. BUT, Im tracking down something strange looking in the EEROM code that I 'fixed' around that time... Im pretty sure what I did fix was a bug but Im seeing if it had side effects.. as you say here, it clearly did.

[bakerhillpins]

So the last build I got from you fixed the Demo Mode problem:

• where it didn't work, it always started on level 1 no matter what level you chose.

I only burned the 4 Alpha ROMs to apply that "fix". All other updates have been all 8 ROMs. Well one update was 9 ROMs because one of those builds had the Max sound issue fixed in it.

[jessaskey]

Owen... by the final code you were doing things pretty good... each score was 4 bytes (8-digits) which supports a score up to 99,999,999. While I think if Jerky was actually challenged to get a score that high, I bet he could do it BUT it would take like 24 hours of constant playing :-) If a player got that high, their score would simply flip over to 0 again and they wouldn't get anything in the high score table for their accomplishment tho.

[jessaskey]

Can you try the last set of v1.01 ROM's I sent AND replace the gamma ROM too really quick? The reason Im asking for this is that I started trimming out Alpha->Gamma commands from RPM that were not being used and so Im worried that somehow I took one out which shifted the byte values for all the commands above that by -1 and now your Alpha might be sending commands to Gamma which are not doing the correct task at all. That might have accounted for some of the weird stuff you were seeing in Self Test with the sound codes etc.

Also, on the Warp Reset... you are correct that the Reactor Hum sound notes that the warps were saved to Gamma. If you can consistently generate EEROM errors simply by resetting the warps (or randomizing them), then that is a good use case for us to focus on for this because that is a very simple situation being that you are in self test and we know there isn't some other random set of Alpha -> Gamma commands happening in gameplay that are confusing things.

On the Self Test for randomizing the warps, there are only 4 commands set to the Gamma from that screen... 1) Get LETA value, 2) Get Switch Values (Fire/Shield) 3) Randomize Warps. 4) Sound command for Reactor Sound

The Randomize Warps command doesn't send any data to Gamma it just tells Gamma to do it and the randomization is all done on the Gamma side... The Gamma just randomizes into RAM, marks to EEROM segment for warp codes to 'write' and then returns a 'success' value to Alpha which then sends the reactor hum sound command.... After the Gamma sends that 'success' command to Alpha which finishes the NMI routine, then it resumes the Gamma 'main loop', where it tends to tasks... in the main loop it looks to see if there are any EEROM 'commands' (Read EEROM to RAM or Write RAM to EEROM), if so, it looks at which segment is supposed to be read or written and does it then. If our command to 'randomize warps' it would see that the warp code segment was flagged as having a command and the 'write flag' for that segment would be set... it would then be actionable to that state and copy 7 warps, 2 bytes each + 1 csum = 15 bytes from RAM to EEROM. It would clear the segment and write flag for that segment (which finishes the process).

[bakerhillpins]

Just so I'm clear on what to do. You want me to burn and replace 9S using the files you sent for the Demo Mode fix? (kinda unfortunate that we discussed that via text message eh?)

The reason I ask is because the 9S files in both of those builds have the same image (I used a binary diff tool)

[jessaskey]

If they diff the same, then you are right, no need to reburn. I just want to make sure we are running the same code (me=MAME, you=PCB) just because that is obviously where we need to start. :-) Im going to burn the current ROM's and put them into my board here next so I can see if I can dup your behavior on my hardware, that will give us a 3 way test rather than a he said/she said situation. :-)

[jessaskey]

These are current build of v1.01 (pre-release) mhavocpe_en_adpcm_101.zip

[bakerhillpins]

When I diff 9S with the build that isn't having problems (Dec 29th) it IS different!

[jessaskey]

Let me burn ROM's here and see what I can find... between hardware and MAME... I will send another ROMset this weekend that should have this fixed as long as I can dup on my end.

[jessaskey]

Okay, a little update here... there are/were a number of issues going on.

1. Maze stat - Even tho I had to remove the screen from the Self Test that showed these stats (Owen, this screen was even in your code originally but skipped in the self test screens) the code was still all in place that at each maze end the Alpha was sending stats (deaths in space, deaths landing, deaths before touching reactor, deaths after touching reactor) to the Gamma to save in EEROM. I had high hopes of bringing this back but the concept of putting 28 levels with 4 data points onto a single screen with numbers in columns prooved to be a horrible flicking nightmare on real hardware (looked fine in MAME of course). Depending on if I get time eventually, it would be nice to actually just draw a line graph of these for each level because a) that would be cool looking b) it would be much easier on the Vector Generator to draw a line over a bunch of numbers . Either way, I took out the code that actually even sends this data to the Gamma because it was unfortunately the wrong size (only had 24 levels allocated and should have had 28 levels). I could have just re-sized this data array but the side effect would be that all the data above it in the EEROM would have been corrupted on game boot because they would have shifted up in physical address locations and the CSUMs would not have matched anymore. That data would have included scores, initials and medals... so anyone upgrading from v1.00 to v1.01 would have lost all their scores in EEROM and an 8-bit processor with only 16K of program memory is not the place you want to start doing version specific patches on memory. SO, long story short, I took this code OUT... there are now only 7 EEROM 'segments'... so that graphic I have above on the EEROM flags is now obsolete, I will make another and post here.
2. The original EEROM code for Erasing segments was broken... there was seemingly a function to allow the native EEROM routine to 'erase' segments and calculate a correct CSUM, but it didn't work. After going back and looking at Owen's original code, I saw that instead of using this function, that Owen actually just 'corrupted' segment memory in order to have it reset to zeros upon next boot. In the end, I fixed the EEROM code so that it now supports READ, WRITE and ERASE properly of multiple segments in a single command (a command can have multiple segments specified at a time... like erase game stats AND erase warp stats).

With all that, I have only tested this in MAME over the weekend.. Here is what I verified..

1. 'Reset Stats' in Gamma test screen works properly. They ARE reset properly immediately, not on next restart, but an unfortunate side effect of the way that the Alpha Self Test routine gathers the EEROM flags (only once upon entry into Self Test) means that the Gamma screen doesnt update the EEROM error flags unless you leave and re-enter Self Test. In a perfect world, if you had a corrupt set of flags on the EEROM (lets say the game stats and warp stats for example)... and you sent the command to 'Reset Stats'... you would hope that would send (the program now beeps properly again too when this is done) the command and then immediately reload the EEROM flags and show that they are clean.. but that doesn't happen. I'm going to make a new issue for that one after I type this out.
2. Getting a high score indeed works and saves along with initials and tessers. Gamma Test command of 'Reset Scores' works properly.
3. Changing of game settings (now stored in EEROM too), works and does not create a bad checksum. Settings are read back properly from EEROM.