Jump to content
IGNORED

Bus Stuffing Demos


SpiceWare

Recommended Posts

I was able to test this on a 7800, Jr., and light sixer today. 7800 and light sixer worked fine, but the Jr. did not. I tried repeating Crispy's experiment on the Jr. but D0 is always low. I'm guessing this is different than what the others reported. In this case the CPU seems to have got into a halted state. Instead of jail bars garbage is rendered similar to what you'd see if you pull out the cartridge while it's running.

 

Important note about that Jr. is that the harmony menu doesn't display right and A12 always goes low for a portion of every clock cycle. In general this specific console seems to have lots of problems with the harmony. Normal games all work just fine though.

 

I also tested on a CRT and a LCD TV. The LCD TV looks like this.

 

post-40226-0-49517300-1485986959_thumb.jpg

 

 

  • Like 1
Link to comment
Share on other sites

I followed SpiceWare's suggestion and cleaned my Harmony, and the results were slightly better than my first try, but about half the bits are still always high, with the same chaotic flickering in places. Running the parrot test actually showed some appreciable brightness gradients, mostly in the columns that had the "dark areas" I reported earlier.

  • Like 1
Link to comment
Share on other sites

I was able to collect some data using the test program that SpiceWare supplied and found that bus stuffing breaks when the Harmony is driving a logic low on a data pin, and the resulting voltage at the pin is higher than 1.39 V. This happens when the resistance between the harmony cartridge and the data bus is greater than 39 ohms. When the resistance is less than 1 ohm there is a comfortable margin of 0.47 V, at least on my four switch console. I realize that a sample size of one really doesn't provide enough data points to support a conclusion, but having a margin of nearly 0.5 V leads me to believe that bus stuffing will work on most 2600 consoles.

Noting that it takes only 39 ohms of resistance between the harmony cartridge and the data bus to break bus stuffing, it's important to have the contacts perfectly clean on both the Harmony cartridge and on the 2600 cartridge connector. I've seen oxidation on connector contacts introduce 50 ohms or more of resistance.
It's also possible, as Kosmic Stardust and ZackAttack pointed out, that some TIA chips and/or CPUs may have odd timing issues that prevent bus stuffing from working. However from what I'm seeing on the scope, the timing margins are good, and bus stuffing should work fine in most cases.
Edited by Crispy
  • Like 3
Link to comment
Share on other sites

 

Noting that it takes only 39 ohms of resistance between the harmony cartridge and the data bus to break bus stuffing, it's important to have the contacts perfectly clean on both the Harmony cartridge and on the 2600 cartridge connector. I've seen oxidation on connector contacts introduce 50 ohms or more of resistance.

Do you happen to know a good, halfway-convenient way to clean the connector? Cartridges are easy, but I've never actually done the connector.

Link to comment
Share on other sites

Do you happen to know a good, halfway-convenient way to clean the connector? Cartridges are easy, but I've never actually done the connector.

 

Isopropyl alcohol and a cotton swab - flatten out the end of the swab with a pair of pliers. You may have to remove some cotton.

Edited by Nathan Strum
  • Like 1
Link to comment
Share on other sites

Isopropyl alcohol and a cotton swab - flatten out the end of the swab with a pair of pliers. You may have to remove some cotton.

When I last cleaned my harmony I'd also cut an old credit card sized rewards card in half, wrapped it in a paper napkin, soaked it in alcohol, then insert/removed it a few times. It cleaned it a bit:

post-3056-0-54395500-1486152016_thumb.jpg

 

 

Just tried this method and it cleaned it quite a bit more:

post-3056-0-86963100-1486151722_thumb.jpg post-3056-0-76435400-1486151726_thumb.jpg post-3056-0-68726100-1486151731_thumb.jpg

  • Like 2
Link to comment
Share on other sites

Bummer :(

At this point I'm leaning towards a new bankswitch format that uses Fast Fetchers like DPC+ while utilizing what we've learned while working on BUS:

  • DPC+ Fast Fetchers
  • BUS Datastreams (much more flexible as all 16 support integer and fractional increments)
  • BUS 2K driver size (more ROM and RAM available for the game)
  • DPC+ Music
  • BUS packed audio sample playback from ROM
  • Like 1
Link to comment
Share on other sites

Maybe, not sure how widespread the problem is. We have 2 problem systems (3 if we include 7800s) so far out of rather small sample size. Think I'll post something in the main 2600 forum to get more feedback on this.

 

It might be good to use the test program I proposed earlier so we'll know which failures are timing issues and which are resistance/electrical issues. I'd be happy to help implement that if needed.

Link to comment
Share on other sites

 

It might be good to use the test program I proposed earlier so we'll know which failures are timing issues and which are resistance/electrical issues. I'd be happy to help implement that if needed.

 

 

That would be helpful. While I understood what you posted I'm not familiar with ARM assembly, nor the hardware side of things, to be able to implement it.

Link to comment
Share on other sites

This made me realize cleaning cart slots in even new hardware is really important.

I would wash, refurbish, clean classic hardware when I buy it, but I had not realized how tarnished my (new compared to 70s-80s carts) Harmony Encore was!

Probably part of the reason games were failing on a 2600 Heavy Sixer, and no problems with the same 2600 game on a 7800.

There's still the 7-8 year difference in manufacture.

I have a 1977 TIA chip that blinks playfield pixels in my own DPC+ bB game. That is age and a TIA variation I'd guess.

 

I was just about to post "My better of 2 7800s had a 1-pixel gap after the 2nd or 3rd sprite in the Bus Stuff Demo, 20160302.bin"

But I cleaned the Harmony Encore and testing just now,and both 7800s and Harmony orig & Harmony Encore have no problems!

The 7800's are colder than last night when I ran that demo after a few games of" Pacman 8K V7_test" & "Fat Albert".

  • Like 1
Link to comment
Share on other sites

When I last cleaned my harmony I'd also cut an old credit card sized rewards card in half, wrapped it in a paper napkin, soaked it in alcohol, then insert/removed it a few times. It cleaned it a bit:

attachicon.gifIMG_8359.jpg

 

 

I have done this with expired shopper's cards and coffee filters. Spraying contact cleaner into the cartridge bay and vigorously inserting and removing a game cart also help.

Link to comment
Share on other sites

At this point I'm leaning towards a new bankswitch format that uses Fast Fetchers like DPC+ while utilizing what we've learned while working on BUS:

  • DPC+ Fast Fetchers
  • BUS Datastreams (much more flexible as all 16 support integer and fractional increments)
  • BUS 2K driver size (more ROM and RAM available for the game)
  • DPC+ Music
  • BUS packed audio sample playback from ROM

 

I had a thought about how to improve on bus stuffing using a simple and cheap hardware mod. It will allow the Harmony to act as a DMA controller without the bus contention that bus stuffing causes. It also has the added benefit of allowing the Harmony to write a TIA or RIOT register in a single CPU cycle.

 

The idea is to put a tri-state buffer between the CPU address bus and the main board address bus so that after a write to WSYNC, when the READY line goes low, the CPU address lines will be disconnected from the main board address bus. At the same time, the R/_W line will be forced low, and at this point the Harmony is free to control the address and data buses. Since the R/_W line is now in the write state, a register will be written every CPU cycle. For any cycle that doesn't require a register write, the Harmony can set the address to some non-existent register. There is no data bus contention during DMA because when the READY line goes low after the write to WSYNC, the internal CPU data bus drivers are disconnected since the CPU is now in the state of fetching the next instruction.

 

The hardware mod is very simple. It will be a small circuit board with a 28 pin socket and a few discrete logic chips. You install it by unplugging the 6507 CPU from its socket, plugging the small board into the CPU socket on the main board, and then plugging the 6507 CPU in the socket on the small board. Unfortunately, installation would only be this simple on six switch and four switch consoles. Installation on the Jr. would require soldering since the CPU is soldered to the main board on those machines.

 

Software interfacing is very straightforward as well. The small board will have a register that will be used to enable or disable DMA. When you want to use DMA you first write a 1 into the DMA enable register. Once DMA is enabled, you can write to WSYNC to activate DMA. It will remain active until the beginning of the next scan line when the READY line goes high, at which point the CPU is given back control of the address bus and R/_W line. Disabling DMA is done by writing a 0 to the register on the small board. Doing this will cause the hardware to behave as if the mod isn't even there.

 

I realize that this is not a "pure" solution since it involves a hardware mod, but I would like to make a couple of arguments in favor of its validity. First, this is a cheap and easy hardware mod that was feasible back in the early 1980s when the 2600 was popular. It uses parts that were cheap and readily available back then. Yes, it is only one half of the solution. The other half is the Harmony cartridge, which didn't exist in the heyday of the 2600. However, knowing what David Crane did with the DPC chip, it would have been possible to make an inexpensive DMA controller chip for Atari 2600 cartridges back then.

 

And finally, games that set hardware requirements are nothing new. Using the Amiga as a example, when the Fat Agnus chip became available, a lot of games hit the market that required the 1 Meg Agnus. If you had and A500 or A2000 that had the 512K Agnus, then you had to upgrade your hardware with the Fat Agnus in order to play those games.

 

Comments? Suggestions?

Edited by Crispy
Link to comment
Share on other sites

 

I had a thought about how to improve on bus stuffing using a simple and cheap hardware mod. It will allow the Harmony to act as a DMA controller without the bus contention that bus stuffing causes. It also has the added benefit of allowing the Harmony to write a TIA or RIOT register in a single CPU cycle.

 

The idea is to put a tri-state buffer between the CPU address bus and the main board address bus so that after a write to WSYNC, when the READY line goes low, the CPU address lines will be disconnected from the main board address bus. At the same time, the R/_W line will be forced low, and at this point the Harmony is free to control the address and data buses. Since the R/_W line is now in the write state, a register will be written every CPU cycle. For any cycle that doesn't require a register write, the Harmony can set the address to some non-existent register. There is no data bus contention during DMA because when the READY line goes low after the write to WSYNC, the internal CPU data bus drivers are disconnected since the CPU is now in the state of fetching the next instruction.

 

The hardware mod is very simple. It will be a small circuit board with a 28 pin socket and a few discrete logic chips. You install it by unplugging the 6507 CPU from its socket, plugging the small board into the CPU socket on the main board, and then plugging the 6507 CPU in the socket on the small board. Unfortunately, installation would only be this simple on six switch and four switch consoles. Installation on the Jr. would require soldering since the CPU is soldered to the main board on those machines.

 

Software interfacing is very straightforward as well. The small board will have a register that will be used to enable or disable DMA. When you want to use DMA you first write a 1 into the DMA enable register. Once DMA is enabled, you can write to WSYNC to activate DMA. It will remain active until the beginning of the next scan line when the READY line goes high, at which point the CPU is given back control of the address bus and R/_W line. Disabling DMA is done by writing a 0 to the register on the small board. Doing this will cause the hardware to behave as if the mod isn't even there.

 

I realize that this is not a "pure" solution since it involves a hardware mod, but I would like to make a couple of arguments in favor of its validity. First, this is a cheap and easy hardware mod that was feasible back in the early 1980s when the 2600 was popular. It uses parts that were cheap and readily available back then. Yes, it is only one half of the solution. The other half is the Harmony cartridge, which didn't exist in the heyday of the 2600. However, knowing what David Crane did with the DPC chip, it would have been possible to make an inexpensive DMA controller chip for Atari 2600 cartridges back then.

 

And finally, games that set hardware requirements are nothing new. Using the Amiga as a example, when the Fat Agnus chip became available, a lot of games hit the market that required the 1 Meg Agnus. If you had and A500 or A2000 that had the 512K Agnus, then you had to upgrade your hardware with the Fat Agnus in order to play those games.

 

Comments? Suggestions?

That sounds like a cool idea, but has the potential to fracture the user base or break compatibility with existing games. Also one could argue if a game does not run on stock hardware, it ca be argued it is no longer a VCS game. This isn't like computers where parts are user upgradeable, several hardware configurations exist from lowest to highest, and some games require a higher configuration than others.

 

Still if such a kit were released, I would likely buy one for testing purposes, assuming the mod were completely reversible.

Link to comment
Share on other sites

It also has the added benefit of allowing the Harmony to write a TIA or RIOT register in a single CPU cycle.

My concern would be that once you are able to update the TIA every pixel, it will lose everything that makes programming the VCS special. Instead of having to manipulate the limited resources at just the right time, you'll have a 160x192 128 color bitmap. Programming that would be no different than any other system with a frame buffer.

 

Of course, there's also the obvious drawback that the console must be modified. At that point why not just have an HDMI port on the cartridge?

 

I don't see any reason not to make it though. If someone doesn't want to use it, they don't have to. This is just a hobby after all.

  • Like 1
Link to comment
Share on other sites

My concern would be that once you are able to update the TIA every pixel, it will lose everything that makes programming the VCS special. Instead of having to manipulate the limited resources at just the right time, you'll have a 160x192 128 color bitmap. Programming that would be no different than any other system with a frame buffer.

 

Of course, there's also the obvious drawback that the console must be modified. At that point why not just have an HDMI port on the cartridge?

 

I don't see any reason not to make it though. If someone doesn't want to use it, they don't have to. This is just a hobby after all.

I don't think so. Essentially it's creating a totally unique platform with it's own aesthetics.

 

You're basically limited to a single background and playfield color per line, unless I'm missing something. So it inherits somewhat of a monochrome aesthetic sort of like a Game Boy, with optional colored overlay like the old monochrome arcade games. The "Cicada" demo screen was a good example of what is actually achievable. The screenshots kind of had a Vectrex / Game Boy vibe to them.

 

But the issue is kind of mute or relegated to Harmony apps unless we get a display engine that works across all hardware models including Juniors and 7800s. Or a disclaimer that the game cart may not work on specific models of hardware.

 

Cicada would be an instant purchase for me even it the game is in monochrome. Also I picked a wonderful time for my Harmony cart to turn up missing. It's in the house; I just cannot find it. :dunce:

 

Anyhow these bus stuffing demos sound like awesome sauce... :grin:

Link to comment
Share on other sites

We all have our lines somewhere. Some limit themselves to 2 or 4K, others to what was possible to put inside the cartridge "back in the day". For me, the cartridge must work in a stock Atari. Actually, my line extends a little into hardware modification to the VCS as I'm willing to support the stereo mod - it enhances the game if you've done the mod, but it's not required to play the game.

 

Chris figured out the 128 pixel display using DPC+, so a monochrome Cicada would be possible without bus stuffing. I think that was limited to 128x100 (same pixels are repeated over 2 scanlines), though could be made 128x200 with a convoluted layout of the bitmap in memory that might be detrimental to an action game. That's why the new bankswitch scheme would support the newer, more flexible datastreams.

 

I haven't posted the survey yet as I've pinged Al to get feedback on whether or not he's willing to sell a game that might not work on all 2600s.

  • Like 2
Link to comment
Share on other sites

We all have our lines somewhere. Some limit themselves to 2 or 4K, others to what was possible to put inside the cartridge "back in the day". For me, the cartridge must work in a stock Atari. Actually, my line extends a little into hardware modification to the VCS as I'm willing to support the stereo mod - it enhances the game if you've done the mod, but it's not required to play the game.

 

I agree with this sentiment- the stereo mod isn't required so it still plays on a stock Atari. Since the Jr. was readily available, I would also consider it a stock 2600 and would think releases should work with that system. The 2/4K guys I think of as purists, but I don't think they would begrudge a 16K game release either- it's just not what they might choose to do themselves. Just my two cents.

  • Like 1
Link to comment
Share on other sites

I agree with this sentiment- the stereo mod isn't required so it still plays on a stock Atari. Since the Jr. was readily available, I would also consider it a stock 2600 and would think releases should work with that system. The 2/4K guys I think of as purists, but I don't think they would begrudge a 16K game release either- it's just not what they might choose to do themselves. Just my two cents.

I agree, also with the Jr. But IMO that shouldn't stop BusStuffing.

 

Maybe there is a way to overcome the problem by software, which just cannot be seen right now? Or maybe the Jr. consoles can be fixed with a mod like some 7800 had to be fixed for certain Atari 2600 games? Also, the Cosmic Ark trick doesn't work right on many Jrs, still this is accepted as an incompatibility of the hardware, not the software.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...