Strange sprite multiplexing issue on ROM 400/800 OS-A

[8bit-Dude]

Hi Guyz,

 

Filippo has been testing the latest version of 8bit-Slicks for the 400/800, and found a bug that only affects the OS-A ROM version.

The DLI multiplexed sprites appear multiple times instead of the way they appear on other ROM versions. Please refer to screenshots below.

 

Is there something particular with the way that ROM version handles sprite addressing?

Here is my DLI: https://github.com/8bit-Dude/8bit-Unity/blob/main/unity/targets/atari/DLI.s

Here is my VBI: https://github.com/8bit-Dude/8bit-Unity/blob/main/unity/targets/atari/VBI.s

And sprite copy code: https://github.com/8bit-Dude/8bit-Unity/blob/main/unity/targets/atari/blitSprites.s

 

(My sprite multiplexing code is loosely based on the guide from https://playermissile.com/dli_tutorial/)

slicks-demo-atari48k.atr

[Rybags]

PM graphics aren't used by the OS so shouldn't be directly affected in different ways.

 

But, and this occurs with OS-B also - the interrupt handlers don't do a CLD early in the VBlank handler but with the XL it does which can lead to problems with programs that use ADC/SBC during VBlank or an IRQ (DLIs in all cases never have a CLD)

 

Other than that all I could think of is some sort of timing issue but it'd likely be VBlank related and generally you have some variance in timing regardless of OS version.

 

Does your sprite move routine get called during VBlank?

I'd suggest - regardless of what you're doing, always do a CLD at the start of your VBlank code.

 

Aside from this, all I can think of is some sort of memory conflict but I don't think OS-A uses any locations that OS-B doesn't.

 

Late thought - ensure you're using an OS that's relevant to the region settings - the common A variant OS will often just be for PAL 800s - though that said, they should be just about identical except for keyboard timing and probably the cassette bitrate tables.

Edited January 9, 2022 by Rybags

[_The Doctor__]

The other thing to consider is what type of cpu card is in his 800, the OS and cpu card might have some bearing on things... sure sounds odd so it might be good for him to verify all the particulars right on down to GTI and ANTIC chips...

[8bit-Dude]

9 minutes ago, _The Doctor__ said:

The other thing to consider is what type of cpu card is in his 800, the OS and cpu card might have some bearing on things... sure sounds odd so it might be good for him to verify all the particulars right on down to GTI and ANTIC chips...

Thanks for the feedback. The bug can be easily replicated in Altirra by setting PAL 800 with OS-A ROM. So not sure there is something specific to hardware... 

[8bit-Dude]

Thanks for several suggestions Rybag. I will try them out tomorrow when i get back home (particularly CLD). 

[Rybags]

I'll have to try and get a copy of Rev A.  Rev B doesn't do CLD so I doubt it's that.  It might just come down to timing or there might be a memory usage difference.

[phaeron]

This issue is due to a change between OS-A and OS-B in the implementation of the SETVBV routine for changing interrupt vectors. In OS-A, it resets NMIEN and turns off your DLIs. OS-B has a rewritten SETVBV routine that avoids doing this. The fix is to reset NMIEN after calling SETVBV or anything else that might indirectly call SETVBV (DOS/SIO).

 

 

[8bit-Dude]

2 hours ago, phaeron said:

This issue is due to a change between OS-A and OS-B in the implementation of the SETVBV routine for changing interrupt vectors. In OS-A, it resets NMIEN and turns off your DLIs. OS-B has a rewritten SETVBV routine that avoids doing this. The fix is to reset NMIEN after calling SETVBV or anything else that might indirectly call SETVBV (DOS/SIO).

 

 

Thanks for a very insightful reply Phaeron.

My program is compiled with cc65 and relies on xBios for loading and file handling. 

Could the problem come cc65 or xBios calls to setvbv? 

[Rybags]

The way I see it, you have 2 main choices for a fix:

 

- don't use SETVBV, use your own code to do it.

- set NMIEN to $C0 after any change of DLI or VBlank vector.

 

Whether it's CC65 or XBios calling SETVBV - really it doesn't matter.

Edited January 9, 2022 by Rybags

[8bit-Dude]

Sweet!!! I added NMIEN reset after all calls to SETVBV, and it fixed the problem!

It is amazing to have received support so quickly from you guys, I would have had no chance figuring this out alone.

Thanks a million times!!!

[snicklin]

On 1/9/2022 at 12:14 PM, 8bit-Dude said:

Hi Guyz,

 

Filippo has been testing the latest version of 8bit-Slicks ...

slicks-demo-atari48k.atr 179.64 kB · 5 downloads

This is a great game that you've got here. The turning mechanism is more realistic than in Grand Prix Simulator.

 

I had a go a decade ago at something similar and didn't get the turning mechanism right... I had so many layers of logic for the movement (which used a lot of CPU time) that I ended up getting confused under all of it and eventually with the pressure of paid-work gave up. That isn't my game in the screenshot, but it is linked. Hit fire on the title screen. If you touch a key it will crash.

 

 

[8bit-Dude]

Thanks for the feedback Snicklin!

 

The graphics look very good in the screenshot above, but when I click the link it just takes me to another thread (can't see any ATR).

 

Edit: I managed to download the ATR. I see what you mean, the car moves in a straight line!

 

In 8bit-Slicks, I used 2 angles: 1 for the angle of sprite, and 1 for the direction of travel. I then have a LERP function that progressively brings the angle of second close to the first (so there is a kind of lag allowing "drift").

Edited January 10, 2022 by 8bit-Dude

[8bit-Dude]

Here are the disks of fixed version for 48K (400/800) and 64K (XL/XE) Atari 8bit!

This is the shareware version of the game, and it is compatible with 3 networking devices (see here for full version).

 

I have also included a modified version of Altirra 4.0 that includes the 8bit-Hub for networked play (a Joy Port 2 accessory).
(Configure System > Peripherals > Devices > Add > 8bit-Hub)

slicks-demo-atari48k.atr slicks-demo-atari64k.atr

Altirra-4.00-Hub-2022-01-10.zip

Edited January 10, 2022 by 8bit-Dude
There was a problem with Altirra link

[+Philsan]

Steve, you reminded me I was excited by your game WIP:

https://atariage.com/forums/topic/148210-graphics-mode-12-overlay-code-required/?do=findComment&comment=2156101

 

Eleven years has passed and now I am the "Filippo" who tests 8bit-Slicks.

[snicklin]

On 1/10/2022 at 10:25 PM, 8bit-Dude said:

Thanks for the feedback Snicklin!

 

The graphics look very good in the screenshot above, but when I click the link it just takes me to another thread (can't see any ATR).

 

Edit: I managed to download the ATR. I see what you mean, the car moves in a straight line!

 

In 8bit-Slicks, I used 2 angles: 1 for the angle of sprite, and 1 for the direction of travel. I then have a LERP function that progressively brings the angle of second close to the first (so there is a kind of lag allowing "drift").

Ahh, there is a version there where it turns, though it tends to slide a bit at times.

 

I reckon that if I pulled out all the logic and started again, I might be able to succeed. I am not sure where the source code is though.

 

On 1/11/2022 at 2:59 AM, Philsan said:

Steve, you reminded me I was excited by your game WIP:

https://atariage.com/forums/topic/148210-graphics-mode-12-overlay-code-required/?do=findComment&comment=2156101

 

Eleven years has passed and now I am the "Filippo" who tests 8bit-Slicks.

Nice to hear you liked it. And I am glad that you are on a project that has a very high chance of success!