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...