New SuperCharger game breaking on Uno and PlusCart

[Mr SQL]

On the Harmony Cart and the SuperCharger Arkanoid AidHead plays fine but on Uno and PlusCart the paddle becomes shaky and cannot be controlled properly.

 

(click in the bottom zone to start Arkanoid AirHead).

 

Any ideas?

KC_OS_RC5.bin

 

I also have a bonus version KC_OS_RC6.bin I am also releasing at the SillyVenture party which does not currently run on the Harmony for having an extra load, we are planning to expand the classic Harmony cart limit via a future BIOS update for better supercharger compatibility. Awesome if PlusCart and Uno can have better compatibility with whatever is breaking RC5 here, I think it may be an incorrect init taking place in Arkanoid AirHead that should be under supercharger control from the previous module since it is not load 0 and the BIOS init code should not get to run. 

 

Interestingly Akanoid AirHead on KC_OS_RC4 does not break on PlusCart but RC5 works on Harmony and the real SuperCharger so I think it should be supported for better SuperCharger compatibility like Harmony. If someone with an Encore cart can test RC6 please PM me for a release build, I suspect it will not have the control issues with Arkanoid Airhead.

 

[+Al_Nafuur]

UnoCart with @DirtyHairy's firmware or the unified build?

 

[Mr SQL]

20 minutes ago, Al_Nafuur said:

UnoCart with @DirtyHairy's firmware or the unified build?

 

I updated my UnoCart firmware from DirtyHairy's thread but am not sure how to tell which firmware version I am running.

 

Both my UnoCart and the current version of PlusCart have the same issue though, the paddle (controlled by the joystick) does not travel properly and breaks apart. 

 

I tried compiling Arkanoid AirHead as the main program with no other changes and then it run's fine so I think this bug is happening where the loading environment is somehow different or becomes corrupt; it should inherit about half of the zeropage RAM from the calling program with no other initialization besides what the SuperCharger does after the BIOS passes the security check for running any program other than main. Strangely, the program runs fine without showing this bug in the prior release in PlusCart exclusives.

 

[Mr SQL]

@DirtyHairy and @Al_Nafuur I think I found the source of this bug - when doing a multiload from the BIOS you must not initialize the regs, they should stay in whatever state they are currently in.

 

The SC BIOS is designed to preserve the current state of the zero page for multiloads, low RAM along with the registers.

 

Here are two files to show what is happening in the multiload BIOS call which should not happen, I had to add the init code to make it happen on the initial program load.  

 

The first program works fine, but the second one triggers the same bug where the paddle falls apart by initializing the registers - to fix this bug, do not init the regs for subsequent multiloads; consider the init performed by the BIOS stub for the IPL (initial program load) is correct and must be 1x only because Stella and more importantly the real SuperCharger hardware are not doing this second init routine for multiloads that PlusCart and UnoCart are doing. 

 

Line 31 shows the reg init that recreated the bug on IPL:

AkaniodAirhead2020_UnoCart_SuperCharger_multiload_bug_recreated.bin ArkanoidAirhead2020.bin

[DirtyHairy]

You can check out the BIOS stubs used by Stella here and by the Unocart and 6502.ts here. Neither preserves the register values, both overwrite 0x81 -- 0x9d with zeroes, and both use and overwrite a few bytes at the top of RIOT RAM. Both leave the registers in the same state, X = 0xff, Y = 0x00 and a random value in A (it's not actually random on the Unocart though). I am not sure about the supercharger BIOS, but iirc the Stella stub derives from code from Eckard Stolberg that was modelled after the original SC BIOS, and the Unocart and 6502.ts stub was written by me to match the Stella stub in behavior.

 

If your code behaves differently with both stubs, then I guess it either depends on 0xf0 -- 0xff or on the exact value in A (it is random in Stella and 6502.ts, but constant 0x9c on the Unocart).

Edited August 16, 2021 by DirtyHairy

[Mr SQL]

4 hours ago, DirtyHairy said:

You can check out the BIOS stubs used by Stella here and by the Unocart and 6502.ts here. Neither preserves the register values, both overwrite 0x81 -- 0x9d with zeroes, and both use and overwrite a few bytes at the top of RIOT RAM. Both leave the registers in the same state, X = 0xff, Y = 0x00 and a random value in A (it's not actually random on the Unocart though). I am not sure about the supercharger BIOS, but iirc the Stella stub derives from code from Eckard Stolberg that was modelled after the original SC BIOS, and the Unocart and 6502.ts stub was written by me to match the Stella stub in behavior.

 

If your code behaves differently with both stubs, then I guess it either depends on 0xf0 -- 0xff or on the exact value in A (it is random in Stella and 6502.ts, but constant 0x9c on the Unocart).

Thanks for those details.

 

The multiload version of Arkanoid2020 in KC OS RC5 runs the same code as the working standalone version of Arkanoid2020, and works via multiload in Stella and via Eckard's BIOS in Z26 and on the Harmony cart, but the paddle breaks apart on the UnoCart/PlusCart.

 

I am only initializing 1 to 128 (decimal) to reproduce the bug, not the other half of the zero page. 

 

This is an interesting bug, I am curious to see exactly which register is causing it to behave differently. I will try narrowing the range down further to see if I can pinpoint what register it is, maybe the cap is not discharging or something odd like that to set a register via hardware.

 

[Mr SQL]

5 hours ago, DirtyHairy said:

and a random value in A

Think I found the register, it's A - did you mean register A or the accumulator? Both appear to be involved:

 

" sta $000A" recreates this bug in Stella, however I did not detect what the value of a (the accumulator) is going into A (zero page register).

 

I think you must be initializing register A to whatever the accumulator value is for this bug to occur after a multiload?

Not all values trigger the bug so I think Reg A might still get set using a different accumulator value in Stella. 

[Mr SQL]

Made some more progress with this and found some new interesting bugs that can break the real hardware that work in emulation and via Uno/PlusCart and Harmony.

 

I was able to verify the SuperCharger does not leave CTRPLF (register $A) set to display a symmetrical playfield; it may be that the loader routine is leaving this register set to symmetric and should either run in asymmetric mode or reset the register to match the real hardware which appears to initialize the register for an asymmetric playfield even when doing a multiload and not initializing everything else.

 

Think it's a good idea to fix this bug on the bios stub or I could put a workaround in the manual for it if preferred.

 

I also found two new interesting bugs that work in emulation and via all other multicarts but not on the real SuperCharger. 

 

#1 Instead of being able to clear the board in the scrolling KC's the Atari would freeze with garbled display; removing a single superfluous load instruction allowed the rts at the end of the bank to be reached. Somehow we get a couple of extra magic bytes in emulation and via BIOS stub SC emulation (how?)

 

#2 The non-scrolling KC was able to play the demo and load the next program module on the SuperCharger, however both scrolling KC modules would not correctly load another module - the loading screen just kept resetting for them on the SuperCharger. I finally figured out I was calling the BIOS routine from bank 3 as expected (startup code in bank3) but bank3 was in the wrong spot to make the transfer - bank 3,2 instead of bank 1,3 continuity.  It still worked in emulation and via BIOS stub emulation on the flashcarts. 

 

Observations: 

Emulation can be very forgiving under certain circumstances or also be limiting when compared to the real hardware; I wonder how many "authentic" retro productions may actually fail to run on real hardware when the hardware is not readily available to test upon or emulated to approximate the missing retro components.