SpiceWare's Blog

I like the snow platform idea, to makes Frosty slower.

Would be well suited in a screen full of birds.

Yes, still a lot of good ideas left. Should be enough for another one.

That there are. If SF3 happens, it won't be for the 2015 Holiday Cart.

When I get back to work on 2600 code it'll be to hash out a bus-stuffing bankswitch format with batari and gang. After that I'll reboot Draconian to use it. If it works as expected, the bus stuffing version of the Slick Kernel will add HMOVE shifting to all objects (currently only works for player objects) plus the ability to color and resize the ball object. The HMOVE change will allow the diagonal ship shots to actually be diagonal, plus the ability to rotate the station shots as seen in the arcade game. The ball changes will allow that object to be used to draw shots, for less flicker on something critical for the player to see, while still being used to draw the parallax starfield.

 

I also plan to reboot Frantic to use it, the asymmetrical playfield will add additional wrinkles to bus-stuffing. We have a couple ideas on how to handle that:

• use STX PFx for the left side, STX PFx + $40 (TIA mirror address) for the right side
• support alternating datastreams - the first STX PFx uses one datastream while the second STX PFx uses another.

Should be a fun project!

I think you have to explain the STX PFx stuff a bit more. As far as I get it, that's load and store in one go, right?

 

Also, would that then be the maximum theoretically possible? Or can you imagine hardware which would use e.g. lda #PFx instead and save another cycle? Could the instruction pointer be manipulated by the DPC (or some even more elaborated hardware)? Or the RAM? Is it thinkable to manipulate the TIA directly?

The X register must be preloaded with $FF for this to work.

• 6507 requests a byte value for a specific address from the 4K cartridge address space
• the ARM chip, in charge of returning values from that 4K, uses the current bank and specified address to look up which byte value it needs to give the 6507
• The ARM puts that byte value on the data bus
• If the BUS_STUFFING mode is OFF, that's all the ARM does. However, if BUS_STUFFING is ON and the value was $86 (the byte value of a STX ZeroPage command) it has the following additional steps to take:
• When the 6507 requests the next byte value, the ARM retrieves it and puts it on the data bus
• The ARM checks to see if that byte value is one of the TIA registers that we're doing bus stuffing on
• if not, the ARM is done. If it's a TIA register, it has more work to do:
• The ARM figures out which datastream is associates with the TIA register
• The ARM retrieves the next value from that datastream
• At the same time the 6507 puts the value of the X register on the data bus, the ARM puts the datastream value on the databus
• Because of how the electronics work, the X register value of $FF from the 6507 gets Boolean Anded with the datastream value from the ARM. The ANDED value is stored in the TIA register.

Wasn't bus stuffing mentioned somewhere in reference to speech without the AtariVox? I have one but would love to have 2 player games with speech.

I don't know if it was, I do know speech can be done without it. It requires the AUDV0 register to be updated on every single scanline, same thing is done to generate 3 voice music in Pitfall 2 with the aid of its DPC chip. It can be done without hardware assist, as shown by Quadrun and Open Sesame back in the day or the hack Berzerk VE.

 

If you check the Frantic blog entries you'll find some that play back speech starting with the May 30, 2011 post.

Ok, I had seen that (for the record, I preferred the Berzerk sample). Maybe it was the thread on Wizard of Wor that mentioned bus stuffing. I'll have to see if I can search it out.

Nevermind. I found it in quite a few places, but not in reference to voice. It was in the WoW forum but I think it was you referencing what you referenced above. Maybe I was just hoping for 2 player WoW with voice. My son likes playing it with me.