Bus Stuffing Demos

[+Karl G]

The issues with the BUS demos came up in the @ZeroPage Homebrew interview with @SpiceWare. I mentioned that I have one of the problematic Juniors that have issues with the BUS demos, and I would be willing to lend out my system if it might help with diagnosis.  I was told that @batari was looking into BUS issues, and might be interested in talking me up on this? Anyway, I just wanted to put that out there.  ? 

[+batari]

Yes, many BUS issues may have been resolved, and what is really needed now is to write a new driver and get that out there for testing to see how effective it will be in practice. It will take some effort because the driver may require a short burn-in period on problematic consoles while the driver determines the best way to deal with them. Basically, it tries to figure out which bits will stuff and which won't. It can deal with up to two bits that fail by using 6507 store instructions instead on those bits.

 

The burn-in period will probably consist of an encapsulated graphic image on the title screen made up of sprites, missiles and/or the ball, and enclosed by the playfield, where the console tests how the console responds to various stuffing attempts, and checks the integrity of the image by checking collisions. Most consoles will work immediately, though some will take a few seconds to find a good solution. Or, if your console fails completely then that will be apparent too.

[Omegamatrix]

Great!

 

I vote for this burn-in screen to be an image of a bus, being stuffed by various Atari characters boarding.

[Keatah]

..with the BUS driver waving out the window saying the test has passed.

 

Preposterous!!

[+batari]

7 hours ago, Omegamatrix said:

Great!

 

I vote for this burn-in screen to be an image of a bus, being stuffed by various Atari characters boarding.

Funny, but something like that could work if you don't mind a possibly glitchy image until it gets figured out.

 

My initial idea was to use a sprite with a logo for BUS, with one player as the object and one in the background behind the player. All collision registers are cleared before the graphic and on a working console, no collisions should be set afterward. Maybe with an audio cue and color change when testing passes.

 

This could be done in multiple lines. Basically, it would try stuffing all bits low first. The sprite should be at least 8 lines high, and the background sprite would be something like this:

 

 .byte %10000000

 .byte %01000000

 .byte %00100000

 .byte %00010000

 .byte %00001000

 .byte %00000100

 .byte %00000010

 .byte %00000001

 

The "main" sprite can be anything, as long as bits above are clear. Then, bus stuff the sprite for 8 lines and record collisions on each line. If any bits fail to stuff, collisions will be set and the failing bits can be recorded.

 

For the main color, pick a high luminance, and a low luminance for the background sprite, but brighter than the background.

 

The current BUS driver can stuff low or high on any bit. If stuffing low fails after a time, then you can try stuffing high. It would work like the above but with inverted graphics (could be transparent by swapping background and player colors.) Then, see if any of the low bits will work by stuffing high.

 

The BUS driver can deal with up to two bits that fail to stuff so that alone should "pass" most consoles pretty quickly.

 

To keep the driver simple, I will probably leave it up to the programmer to determine what bits to stuff low, what to stuff high, and what bits failed to stuff high or low. The bits failing to stuff, if any, would be specified in a mask register passed to the BUS driver so it can handle these bits in a different way. This way we can write the driver soon and let programmers sort out the best methods for stuffing detection later.

 

Once the BUS driver is written, y'all can create these bit detection screens Shouldn't be too long...

[ZackAttack]

On 8/14/2020 at 11:25 PM, Karl G said:

I mentioned that I have one of the problematic Juniors that have issues with the BUS demos, and I would be willing to lend out my system if it might help with diagnosis.

Have you ever tried out this other bus stuffing implementation demo on that problematic junior?

[Thomas Jentzsch]

On 1/21/2017 at 1:16 AM, SpiceWare said:

Another update to the 128 pixel demo.

As far as I can tell, none of these demos work with Stella. Any idea what is wrong?

[+SpiceWare]

9 minutes ago, Thomas Jentzsch said:

As far as I can tell, none of these demos work with Stella. Any idea what is wrong?

 

Yes, it's in the initial post:

On 10/19/2016 at 7:19 PM, SpiceWare said:

CURRENT VERSIONS OF THE DEMOS:

• 2016-12-31 reply #60 - 18 colors per scanline¹
• 2017-01-01 reply #64 - 128 Chronocolour demo¹
• 2017-01-20 reply #79 - 128 pixel demo¹
• 2017-06-16 reply #185 - RPG Demo²
• 2016-11-02 reply #49 - Draconian reboot¹

Some demos were original posted in other topics.

NOTE: At this time these demos only work on real hardware via a Harmony Cartridge.

¹ demos prior to June 6, 2017 run under Stella 5.0.0-pre6 or pre7.

² demos from June 6 on need Stella 5.0.0-pre8 or newer.

 

So RPG works in the current Stella, but none of the others as they were created when the BUS driver was still in flux. Updating the older demos to use the latest BUS driver is on my To Do list; though I have no idea when that'll happen, probably when I start working on the BUS forum in the Harmony/Melody club.

 

 

 

 

[Thomas Jentzsch]

Thanks!

[+MarcoJ]

This development is incredible. Being able to use all 6 horizontal sprites with colour is amazing. The RPG demo is jaw dropping. I have been trying to push the limits of the 8 character coloured tile engine I used in Pitkat but I realise now it's not possible, and I think even with CDFJ it's not possible. Bus stuffing is the only way. This will bring out a whole new generation of games. Very cool work!

[+SpiceWare]

Stella 6.7 was just released and contains some updates I've done for the BUS Stuffing support.  I've found 4 versions of the BUS driver that I've named BUS0 thru BUS3.  Most of the older demos now work, though some don't as BUS was undergoing numerous revisions back then. Additionally the audio routines only work correctly for the BUS3 version of the driver.

 

 

 

 

The debugger will tell you which version of the BUS driver is being used:

 

 

 

 

 

[+MarcoJ]

On 10/20/2016 at 10:19 AM, SpiceWare said:

^1,2 most demos now work using Stella 6.7 or newer.

thanks for getting this working again. Good to go through and review the demos again. I wanted to see how the 128 kernel worked, and was able to see the kernel source in action in Stella. It's good that there's a way to draw 128 pixels horizontally, would be great for wireframe rendering.