jaholmes

I was just talking about the amount of command data streaming by, not the size of the buffers needed. However, a mutable 12x12 byte array--assuming you want full color pixels--is already beyond the capability of the Atari 2600 hardware. 96x192, as just a random pick, would be nearly 20kb. I'm not sure what trickery could be used to work around the need for some (relatively) fat buffers in that case--at least in the MCU address space. The command buffers obviously needn't be anywhere near that large.

Cool! That makes plenty of sense. How do the buffer sizes correlate with the cartridge address space, do you think? I guess they wouldn't need to be very large, as they could be filled extremely quickly by your IRQ handler from a single, logical staging area in the MCU's RAM. Perhaps their size is chosen to keep your FPGA cheap. I'm imagining a situation where a C++ developer wants to think of the screen as having a frame buffer associated with it, and wants to just start plotting pixels all over the place without regard for the beam. Obviously, if you wanted to support such a thing, then we're talking 10's of kbs worth of commands and multiple buffer swaps and refills, which a lazy C++ dev might want hidden from him/herself.

Yeah, I was thinking the former, although the logger solution might be better. But if you bring out the results of two completely independent tests--one for a known address, another for known data at that address--as two pins, I think you'd get a good picture of the relative timing. Of course, your known data might appear at other addresses, but if your scope is triggering on the address, that shouldn't matter.

Hmm. That's a very attractive thought. If you do end up scoping this out, I'd love to see what the actual timing works out to be!

Nah, leave it on. Adds character. On the latching, I'm just wondering about these things: As implemented, I believe you have a transparent latch, so as soon as the address matches SWCHA's %0001010000000, your LEDs start to reflect whatever is on the data bus. Which, at that point, is probably nothing you want to see. From a look at the 6532's timing diagrams, the address could easily become valid 300-400ns before the data bus stabilizes, so you could be seeing ~400ns worth of garbage. Or maybe just nothing. Since the LEDs in the video look stable, I'd tend to guess it's the latter. A scope would obviously tell. Instead, you could do an opaque latch only when the address transitions away from %0001010000000, but you would need to guarantee the validity of the data at that point, which from the timing diagrams, is a tad troublesome. The 6502 appears to stipulate a minimum 10ns "hold time" on the data bus before the address bus goes invalid, however the state of the data bus after the address bus goes invalid doesn't have many guarantees attached to it. At that point, one begins to wonder about the propagation delays in your 74LS245s, which have no documented minimum, but can go as high as 12ns. Stick a fast one on the address bus and a slow one on the data bus, and you're probably in trouble. It's a pity that Phi2 isn't brought out to the cartridge. That would be awesome. Without it, it seems like a worthy endeavor to reduce the propagation delay of your logic level translation circuitry as much as possible. 10's of ns might bring about interesting or "impossible" data.

Very cool! (Separately, you may have to share the story of the tag and ink on your TV screen, and why you haven't removed them. ) One thing that springs to mind, though you've probably thought of it: The final versions of your "stuff" and "snoop" operations are going to require some calibrated delays. There may be a very nontrivial gap, for instance, between the appearance of a valid address and the reasonable assumption of valid data--easily a half-cycle or more. While you're reflecting the data lines to LEDs, this is pretty irrelevant, but when you're trying to latch a value for future use, it'll be harder. But perhaps not all that much harder, assuming the FPGA is clocked like 10x+ the rate of the 6502.

If you just need TIAs, RIOTs, and whatnot, you can still buy them new (old stock) from a number of places, e.g.: http://www.myatari.com/atari26.txt http://www.best-electronics-ca.com/2600_Tech_Tips.htm At $12 US for a TIA, you probably wouldn't want to blow up too many of them, but a couple of mistakes wouldn't break the bank.

Cool! Looks like you're wasting no time. I trust you'll share screenshots of your "extra chatty" Donkey Kong if it works out? Should any of your 2600's ICs donate their smoke to science, may they at least be of the socketed sort!

And just for kicks--for those situations where C++ just doesn't feel 'retro' enough, and yet you still want a somewhat casual development experience--you could drop a 6502 core into your FPGA. Clocked at 32+MHz, you're sure to win the beam race, even with the sloppiest of coding. You could name the cartridge simply "Overclocked", and the label artwork could be a photo of a heatsink/fan assembly.

I'd probably chicken out and use these (or similar): http://www.nxp.com/products/logic/level_shifters_translators/74LVC4245APW.html But for a prototype... Where's an FPGA with 5V I/O when you need one?!

Makes sense. (Seems a little scary, I don't mind admitting!) I just found this very informative thread on the subject.

This sounds like a neat project with a lot of potential. I guess I'm still wondering what it actually means to "stuff the bus", though. Except in situations where a ROM would normally drive the data bus, you wouldn't be driving any busses, and so you're really just emulating a ROM. Presumably you'd have some set of well-written template kernels--chunks of 6502 machine code with all the operands missing--which would be populated in realtime by the FPGA based on some "operand memory", which would be the analog of the TIA from the standpoint of the ARM code. Or am I off in the weeds? Actually, thinking about this some more, you'd obviously need to be a bit more than a ROM emulator in order to deal with input, for instance. I guess, since the FPGA would know when it had just handed the CPU an instruction to read from the RIOT's address space, it could snoop the result from the data bus directly when it saw the address go by. There'd be no need to preserve the resulting register state in the 6502; the next instruction could safely blast over it. Hmmm... the possibilities...

Hi, ResolaQQ - That's very cool! I think people tend to disparage new emulators in situations where mature ones already exist, but emulators are fabulous computer science projects, and taking the time to produce one is something worthy of admiration. Back when the NES emulator scene was exploding in the late 90's, I accepted the challenge and wrote my own NES emulator--of course, with no shortage of prior art to benefit from! It really expanded my appreciation for these machines as well as for the game developers. I never released my emulator, named Syntendo, because the sound emulation never reached a state I could be proud of, and the sound of those old games was a big part of my own enjoyment. Ironically, the name Syntendo was shortly thereafter taken by somebody else for a project that emulated nothing but the NES's sound chip. (Guess we just need to glue the two halves together!) I hope you'll keep working on and enjoying your emulator project! Take care, Aaron

Ah, that makes sense. I suppose WSYNC was a bad example! How about setting the stack pointer to the address of some TIA registers and executing a BRK. +1 Electrically, it's difficult to see how the CPU address and data lines could be manipulated in this way. Is this perhaps talking about manipulating the TIA's internal address and data lines?

Sheet #2 of the TIA schematic shows that all of the data and address lines coming in are latched at the start of a write cycle, so changing the address in the middle wouldn't have any effect as far as I can tell. Also, unfortunately, the address and data lines drive both high and low, precluding any obvious attempts and bus-mastering from the cartridge. Hmmm. There might be some interesting read-modify-write exploits. Does 'INC WSYNC' cause you to wait for two HBlanks? I would think that it would. Not that such a thing would be all that useful, but maybe there are useful ones...

Gah! Thanks for pointing that out. Batari's post started out with a bit of a speculative tone, which caused me not to read all the way to the bottom. I see now the error of my ways.

Just to be clear, and per the "please ignore" in my previous post, I've confirmed through examination of photos and diagrams in the Field Service Manual that the "inductor and capacitor over C201 and R206" in the Manual is not referring to the inductor Albert is referring to. So definitely don't perform this Atari-suggested modification expecting it to resolve the Stay Frosty 2 issue. I don't think it's related. But it is interesting anyway. I still look forward to knowing the Ultimate Answer to the Stay Frosty 2 issue.

Perfect! The shot with the joystick ports is exactly what I was looking for. Thanks!! I wish it were that. Sadly, it's just laziness.

Yes, that was the best one I could find also, and curses! The part I need to see (around the controller ports) is precisely what's obscured in this particular photo. D'oh!

Google and Bing image searches haven't been as productive as I'd expected. I was hoping to avoid tearing apart my heavy sixer just to answer a few basic questions about component layout, but most of the photos I'm finding of the motherboards just aren't all that great. Anybody know where I might find a few really nice motherboard photos? Of a six-switch unit! Doesn't have to be a "heavy"; any sixer will do. Thanks, Aaron

(EDIT: Please ignore this post; I found this picture which clearly shows the location of the FSM mod below to be different from the location of the mod Albert discusses earlier. The FSM mod location lies between the 6507 and 6532.) Actually... (Sorry for the double post!) ...is the sixer mod being discussed here the same one discussed in Field Service Manual? In section 3-2 of the FSM, I see the following: If so, then I guess it's worth mentioning that Atari's solution was to remove, not bridge, the inductor. Although it would be great if somebody with a board in front of them could confirm that this is the same inductor. Anybody?

Hey there, 7800. A quick forum search turned up atari2atari. And here's a relavant post/thread. I'm sure there are more than a couple of others who do this stuff, though. Hope that helps!

Here's an interesting thread. Check out the first post, too, however the post I'm linking to is another instance of a Sears Tele-Games light sixer with what appears to be "heavy" guts. The board is tan, unlike your green one, but is otherwise very similar. (It has the additional capacitor and resistor, the finned heatsink on the regulator, etc.--characteristics the first post in the thread associates with heaviness. ) Very interesting stuff! It's hard to know what to make of it all. I don't think it's quite as cut-and-dried as the first post suggests, as others in the thread describe sending in light systems for service and getting heavy boardsets back, or sending in heavy systems for service and getting a light cases back. I guess the most important thing would be: Have fun with it! One of my best friends growing up had a Tele-Games sixer. Lots of fond memories...

Oh boy... *strains to remember*... I seem to recall Astroblast was one. IIRC, it would frequently hang or start up in a unresponsive state. There were a couple of others that consistently misbehaved. Whether these were software compatibility issues or physical issues with the cartridges--or something else--I can't know for sure at this point.

The Coleco Gemini! Ok-ok-ok, the Atari 2600. But, when I was five years old, I got a Gemini for Christmas, not a 2600. The Gemini was plenty good, except when I'd borrow a 2600 cartridge from a friend and discover that it didn't work. That was rare, though. I do have an actual 2600 system now, but it's a recent eBay purchase. I don't really have a next-favorite Atari system, unless you count the Atari 800 (My uncle had one, and when I'd visit him, that's what I'd play).