More FPGA progress...

[ehenciak]

Hi all,

 

I had acouple of small threads going on in the programming group, but it's starting to look like this is becomming more of a reality as opposed to another vaporware Atari-in-an-FPGA project. Here are some frames of GI Joe and Cosmic Ark running in my VHDL simulator...these games like to exploit TIA

 

 

I have the design about 95% synchronous now. I need to tweak a couple of things in the playfield circuit and I should be able to kick back and play Pitfall for a few hours on an Altera Cyclone FPGA. I still have to add the audio, but, trust me, that will be nothing after what I've been slamming my head off the wall over the past two months ! TIA doesn't lend itself well to pure synchronous design, but I think I have it nailed down.

 

For those that don't know what an FPGA is, think of it as a black box that can implement virtually any digital circuit depending on the circuit's size. In the case of the Atari 2600, it's a means of performing virtually perfect hardware emulation of the system on a relatively small device. For examples of other people putting older games on these devices, please check out www.fpgaarcade.com .

 

At any rate, I have a few ideas to circulate regarding this project. Keep in mind that I will release the source code in a few months...to not do that would be borderline criminal seeing that one needs the schematics, an emulator like z26 for code tracing, and (soon) Kevin Horton's bankswitching document to even have a shot at doing this properly. Here are the ideas :

 

1> Atari 2600 / 7800 in a cartridge. Basically, all one needs is controllers, a power supply from Radio Shack (or one from your own collection if you're like me), composite video cables, and a computer with a USB connection for uploading games. It'll use MMC cards much like Cuttle Cart so that one can store all the games they want. I plan on doing Maria for 7800 HW emulation once the 2600 is done. Actually, now that I have gotten as far as I have with TIA, a friend is laying out boards for this right now....I'm making this more for myself if anything. The price will be less than $100 (that's the high end...seeing how cheap I am, I am fighting tooth and nail to make it significantly lower) and $5 of each sale (regardless of final price) will be donated to some kidney foundation in the name of Jay Miner (the designer of TIA for the 2600...he also played a role in developing a heart defibrillator that gave my girlfriend's dad four more years of life...seeing that I am an ASIC designer as well, I have a special place in my heart for this guy anymore after tearing TIA apart).

 

I have to make this thing for some reason....I've wanted something like this since I was a kid. For what it's worth, if it's OK with MikeJ @ fpgaarcade.com, you'll be able to play Bally Astrocade and VIC-20 stuff on this as well. It's also going to support PAL for all our European friends ! FPGAs have been around for a while, but they're finally getting cheap enough to make affordable homebrew hardware projects.

 

2> I'd like to toss out an idea about making a "Super TIA". What this will be is an "upgrade" for existing Atari 2600 owners. This will plug into the socket where TIA currently sits. This "Super TIA" by default will do away with the modulator circuit and allow one to output composite video (you will not be able to use the old switchbox/modulator anymore). So, at a minimum, "Super TIA" is basically a replacement for TIA that supports composite video output.

 

Now, I know many out there are probably thinking "great, yet another Atari 2600 composite hack". Well, yes, and, well, no. "Super TIA" could potentially add new features for homebrew authors. After digging thru the inner workings of TIA for two months, I can see why people go bonkers developing games. Here are some ideas I have :

 

A> Expand player / missile objects from two to four. This would allow more objects on the screen at one time.

B> HARDWARE ASSISTANCE FOR READING PADDLES (Kaboom 2 anyone ?).

C> Provide homebrew authors with additional RAM for games...this means that authors can use existing EPROMs and PCBs for games.

D> Add some registers for multi-colored sprites.

E> Add some default sprites so that authors have room for other goodies in games (i.e. default characters for scores, etc.)

 

Those are only a few ideas and details would need to be hashed out. I already have a target device in mind for this if people are interested. I could possibly make these upgrades relatively inexpensive as well. I'd also add this to my system-in-a-cart, but it'd also be available as a stand-alone device for those that already own a Cuttle Cart or Krokodile Kart (I'm more in this for expanding the Atari gaming community...I do other stuff to make ends meet ).

 

Anyone have any comments, suggestions, insults, etc. on these ideas? I'll make another post when I have it running on real hardware....it should be any day now (depends on school and work).

 

Ed

[+Mitch]

 

Mitch

[Albert]

Wow, thanks for the detailed update, great to hear of the progress you're making!

 

..Al

[Thomas Jentzsch]

Here are some ideas I have :

 

   A> Expand player / missile objects from two to four.  This would allow more objects on the screen at one time.

   B> HARDWARE ASSISTANCE FOR READING PADDLES (Kaboom 2 anyone ?).

   C> Provide homebrew authors with additional RAM for games...this means that authors can use existing EPROMs and PCBs for games.

   D> Add some registers for multi-colored sprites.

   E> Add some default sprites so that authors have room for other goodies in games (i.e. default characters for scores, etc.)

Though I really your project of an FPGA Atari, I am probably to conservative to ever use any enhancements (where is the challenge then? ).

Anyway, a few more ideas from me:

- horizontal positioning by writing a new value into a register (maybe delayed to the next scanline or HMOVE)

- more options for NUSIZx (e.g three sprites, but still only one missile, more size/number/spacing combinations)

- independent colors for all objects (sprites/missiles, PF/ball)

- two sets of registers for PFx

- maybe some new opcodes and adressing modes, e.g. add, sub, bra, cpx/y adr,y/x, asr (preserving sign!), neg, jmp (adr,x)...

- disable HMOVE blanks

 

And last not least: I want a PAL version!

[Tom]

more audio channels (3 or 4). this would allow you to have games with cool ingame music and sound effects.

 

extensions you make to the 2600 hardware probably should be somehow "protected", so that old games don't accidentally trigger them...

 

thomas: he plans to support PAL

[Eckhard Stolberg]

Hello Ed,

 

looking at your Cosmic Ark screenshot, it seems that you are not doing the starfield effect quite right (z26 doesn't either). On a real VCS the extra clocks from the HMOVE, that are happening during the visible part of the screen, somehow interfere with the output logic for the movable objects. This might be because the clock line for HMOVE is used for different things during the visible part of the screen.

 

If you cause the starfield effect for a one pixel wide missile (like Cosmic Ark does), then you need to look at the scanlines where the missile would be drawn over the first pixel of a playfield block. In the scanline after that the missile will not display, while in the scanline after that the missile will be two pixels wide.

 

If you cause the starfield effect for a player graphics and it's first pixel displays over the first pixel of a playfield block, then the player will only move 16 pixels in the next scanline. It will move 18 pixels in the scanline after that though. Therefore I think it's not the object's position that is affected, but the output logic for the object.

 

I don't know what is going on there exactly, so if you find out by studying the TIA schematics how the object display logic works and how it could be affected by extra HMOVE clock pulses, please let me know, so that we can fix z26 too.

 

 

Thanks,

Eckhard Stolberg

[Mindfield]

more audio channels (3 or 4). this would allow you to have games with cool ingame music and sound effects.

 

Simply adding POKEY into the FPGA would accomplish that -- something that would occur naturally when adding 7800 support anyway.

[jeepnut24]

Well if you have a 2600 in a cart, Id like to take that and make a smaller 2600 handheld.

 

Great work btw.

[jsoper]

How about an encoder circuit to directly drive a GBA SP lcd matrix?

Just kidding, great work.

[vdub_bobby]

"Super TIA" could potentially add new features for homebrew authors.  After digging thru the inner workings of TIA for two months, I can see why people go bonkers developing games.  Here are some ideas I have :

 

   A> Expand player / missile objects from two to four.  This would allow more objects on the screen at one time.

   B> HARDWARE ASSISTANCE FOR READING PADDLES (Kaboom 2 anyone ?).

   C> Provide homebrew authors with additional RAM for games...this means that authors can use existing EPROMs and PCBs for games.

   D> Add some registers for multi-colored sprites.

   E> Add some default sprites so that authors have room for other goodies in games (i.e. default characters for scores, etc.)

 

- horizontal positioning by writing a new value into a register (maybe delayed to the next scanline or HMOVE)

- more options for NUSIZx (e.g three sprites, but still only one missile, more size/number/spacing combinations)

- independent colors for all objects (sprites/missiles, PF/ball)

- two sets of registers for PFx

- maybe some new opcodes and adressing modes, e.g. add, sub, bra, cpx/y adr,y/x, asr (preserving sign!), neg, jmp (adr,x)...

- disable HMOVE blanks

More sprites, independent colors for all objects, two sets of PF registers, disable HMOVE blanks would be top of my list. Paddle help and more sound channels also. Default sprites (character sets, etc.) not so much.

Other possibilities:

Being able to read the TIA registers (not just write)

Positioning register (i.e., 'lda #120 sta POSP0' to put player 0 at 120th pixel)

If you are adding additional RAM, maybe reserve 200-byte strips for sprites (like the 8bit computers do)?

 

Of course, all this is just turning a 2600 into an A8, so what's the point?

Fun to dream, though.

[+Mitch]

Hello Ed,

 

looking at your Cosmic Ark screenshot, it seems that you are not doing the starfield effect quite right (z26 doesn't either). On a real VCS the extra clocks from the HMOVE, that are happening during the visible part of the screen, somehow interfere with the output logic for the movable objects. This might be because the clock line for HMOVE is used for different things during the visible part of the screen.

 

If you cause the starfield effect for a one pixel wide missile (like Cosmic Ark does), then you need to look at the scanlines where the missile would be drawn over the first pixel of a playfield block. In the scanline after that the missile will not display, while in the scanline after that the missile will be two pixels wide.

 

If you cause the starfield effect for a player graphics and it's first pixel displays over the first pixel of a playfield block, then the player will only move 16 pixels in the next scanline. It will move 18 pixels in the scanline after that though. Therefore I think it's not the object's position that is affected, but the output logic for the object.

 

I don't know what is going on there exactly, so if you find out by studying the TIA schematics how the object display logic works and how it could be affected by extra HMOVE clock pulses, please let me know, so that we can fix z26 too.    

 

 

Thanks,

Eckhard Stolberg

 

Eckhard, have you seen this page? It talks about the Cosmic Ark HMOVE problem, it's rather above me so I don't know if that's exactly what you are looking for.

 

Mitch

[ehenciak]

looking at your Cosmic Ark screenshot, it seems that you are not doing the starfield effect quite right (z26 doesn't either). On a real VCS the extra clocks from the HMOVE, that are happening during the visible part of the screen, somehow interfere with the output logic for the movable objects. This might be because the clock line for HMOVE is used for different things during the visible part of the screen.    

 

Oh you are so picky ... and so right ! I should have put a mention of this in my first post but forgot in my haste.

 

I am currently advancing the counters for both the players and the missiles (and the ball for that matter) on the XOR of what I call motion clock and "horizontal motion". This is not entirely correct to do this since it is not how this happens for real. A simple XOR would be nice, but it looks like gate delays come into play allowing for more clock edges when motion enable overlaps the normal hblank_n interval. Looking at the schematics, motion clock only has one gate delay to worry about (the NOR gate which drives motion clock in all the objects). However, the actual motion signal doesn't go low until several gate delays later. Therefore, I suspect that this little time period where motclk is low and the motion enable signal is asserted is enough to advance the counter.

 

I am very sorry if I am not conveying my thoughts properly (I am sick as a dog today). I will explain this in a more detailed document once I figure it out (complete with pretty pictures and timing diagrams).

 

I am currently using a "close enough for television" hack to achieve something similar. I am building "simulation only" models of each circuit and I do see a mismatch between "real" and "synthesis" in the case of Cosmic Ark, so I will definately return to this as soon as I get it synthesized.

 

Finally, please note that this "hack" only comes into play during games which use the "starfield" bug in TIA. I don't have a special block of code called "starfield hack"....the screenshot merely shows what my logic will do when it's invoked !

 

Ed

 

PS It took about 5 minutes to render 60 frames of Cosmic Ark so that I could produce a screenshot with the complete Ark !

 

PPS I showed GI Joe since it seems to use everything but the ball and abuses hmotion. What other games abuse TIA in attract mode?

[RG Dev Rel]

In reference to the original post, the 2600-On-A-Chip project has not diseappeared. It is now owned by RetroGames and has been finished for quite some time.

 

The company has moved to other products. The production part is lagging behind but this is out of our control right now.

 

There is support for all modes but supercharger games; This includes cartridges with RAM, etc. Paddle support is included, there is a full menu system and the storage space is flash-able.

 

Here is a link to the prototype's first demo:

http://www.protectedfromreality.com/BennuA...ari2600Demo.avi

The quality is low, but it was simply to show the prototype running.

 

As we design IP, we do not have control over the rest of the production process. At this point in the process, we can not promise anything related to production (release date, etc), but we can answer over features, provide more screenshots, etc

[ZylonBane]

Of course, all this is just turning a 2600 into an A8, so what's the point?  

My thoughts exactly. Once you start extending the platform, you lose the entire point of the exercise. Anyone who wants a more powerful console to hack on has several real ones to choose from already, and even if this caught on it would just fragment an already-small fan base.

[mos6507]

more audio channels (3 or 4). this would allow you to have games with cool ingame music and sound effects.

 

Simply adding POKEY into the FPGA would accomplish that -- something that would occur naturally when adding 7800 support anyway.

 

How feasible would it be to access a POKEY chip from a 2600 game?

 

Where would it map into the address space? And could you do this all by grafting it to a TIA chip replacement?

 

I do like the idea of a drop-in TIA replacement so that 2600+ games could be played on legacy systems.

[Mindfield]

How feasible would it be to access a POKEY chip from a 2600 game?

 

Where would it map into the address space?  And could you do this all by grafting it to a TIA chip replacement?

 

I do like the idea of a drop-in TIA replacement so that 2600+ games could be played on legacy systems.

 

I don't know about grafting it into TIA, but if Pitfall II can access its own custom sound chip via the cart port then I see no reason why you couldn't do the same to a POKEY.

[mos6507]

I don't know about grafting it into TIA, but if Pitfall II can access its own custom sound chip via the cart port then I see no reason why you couldn't do the same to a POKEY.

 

There is no audio line on the cart port on the 2600. They added this with the 7800. The Pitfall chip requires the game to read from a memory address to pick up the current audio values to feed to the 2600 audio hardware on every single scanline, almost like a digital audio playback.

 

I don't think you could interface POKEY this way. You'd have to do some kind of analog to digital conversion in the chip and then do a realtime handoff of the audio values to feed to the TIA sound which the kernel would have to keep picking up on each scanline.

 

You'd really want to directly wire POKEY to the 2600 motherboard in such a way that the hardware registers show up in the 2600 memory map, which would be tricky.

[Mindfield]

There is no audio line on the cart port on the 2600.  They added this with the 7800.  The Pitfall chip requires the game to read from a memory address to pick up the current audio values to feed to the 2600 audio hardware on every single scanline, almost like a digital audio playback.

 

I understand the concept (data streaming), but how is TIA involved in relaying the sound signals of a chip capable of doing more than TIA itself can reproduce? It can't be converting the analog signals to digital (basically digitizing the audio output from the cart) and feeding the digital signal to TIA every scan line. That would produce playback at ~14KHz (assuming 8-bit values), which would sound pretty low-fi. It would also eat a lot of machine cycles. It seems to me that the audio chip in the Pitfall II cartridge would somehow have to pass the audio off to the 2600 in some other way that doesn't necessarily utilize TIA's audio capabilities.

 

Not that I'm disbelieving you -- I'm no engineer by any means and have only a passing familiarity with hardware concepts, I'm just trying to work out how it'd work.

[Bruce Tomlin]

I understand the concept (data streaming), but how is TIA involved in relaying the sound signals of a chip capable of doing more than TIA itself can reproduce?  It can't be converting the analog signals to digital (basically digitizing the audio output from the cart) and feeding the digital signal to TIA every scan line.  That would produce playback at ~14KHz (assuming 8-bit values), which would sound pretty low-fi.

The TIA has an "all-ones" mode, and Pitfall just sets the sound channel volume. That gives you 4 bits at 15KHz.

 

It would also eat a lot of machine cycles.  It seems to me that the audio chip in the Pitfall II cartridge would somehow have to pass the audio off to the 2600 in some other way that doesn't necessarily utilize TIA's audio capabilities.

Without having looked at the Pitfall II code, I'm guessing that the custom chip has a 4-bit value ready to be copied directly to AudV0 by doing a LDA/STA immediately after STA WSync. This wouldn't take up too much in the way of machine cycles.

 

It's the general case of trying to produce two sine waves of arbitrary frequency that really takes up serious CPU cycles. My red/blue box cart takes up over 2/3 of every scan line with inline code just to update the audio. In fact, this was the main reason that I added a macro feature to my 6502 assembler years ago.

[ZylonBane]

Sooo.... technically... Pitfall II is the first console game to play streaming digital audio!

[Mindfield]

Sooo.... technically... Pitfall II is the first console game to play streaming digital audio!

 

If you grant that it's really just digitized chip-generated sound, and that it's played back at approximately 1/6th CD quality, then yes, I suppose it is. :-)

[mos6507]

[ That would produce playback at ~14KHz (assuming 8-bit values), which would sound pretty low-fi. .

 

It sounds higher fi than the regular TIA sound, that's for sure. Remember that it isn't doing human voices or acoustic instruments or anything. It's pure synthetic tones. So if there is some aliasing/distortion in the sound, it's okay.

[Bryan]

The nice thing about Pitfall II is that the music is all square-wave which tends to hide the artifacts of the sample resolution.

 

-Bry

[+FujiSkunk]

I understand the concept (data streaming), but how is TIA involved in relaying the sound signals of a chip capable of doing more than TIA itself can reproduce?  It can't be converting the analog signals to digital (basically digitizing the audio output from the cart) and feeding the digital signal to TIA every scan line.  That would produce playback at ~14KHz (assuming 8-bit values), which would sound pretty low-fi.

The TIA has an "all-ones" mode, and Pitfall just sets the sound channel volume. That gives you 4 bits at 15KHz.

 

For comparison's sake, your typical telephone connection has audio quality that translates to an 8kHz sampling rate with 8 bit samples. That means the music in Pitfall II has about twice the frequency range, but also more noise, than it would if you were to take the "pure" audio and send it over a phone line. That sounds about right to me (pardon the pun).

 

Sooo.... technically... Pitfall II is the first console game to play streaming digital audio!

 

Maybe, but there are a handful of speech synthesis programs for various 8-bit home computers that use the same or similar tricks, and they probably have Pitfall II beat by a year or two. You raise a good point, though. Remember, kids, digital doesn't necessarily mean high quality, no matter what the cable guy is trying to sell you.

[Bryan]

Maybe, but there are a handful of speech synthesis programs for various 8-bit home computers that use the same or similar tricks, and they probably have Pitfall II beat by a year or two.

 

Speech synthesizers for old computers used one of 2 methods:

 

1. An IC was used, and its audio output was directly amplified.

 

2. Software was used to generate speech waveforms, which were then played through the computer's audio hardware.

 

This is different from what Pitfall II is doing. The sound chip is creating 4-bit wave data on the fly that is read by the game and stuffed into a volume register in the 2600. This is a combination of methods 1 & 2, and I think it's pretty unusual (but necessary on the 2600).

 

-Bry