Flipper

Yes, actually, I guess I should have mentioned that. It will do AT or PS/2. No XT support, tho. Not that I think most people will care. And, I really doubt my code requires a Mega32. It SHOULD rebuild for any atmega with at least IRQ1. I barely use ANY SRAM at this point. You might have to change pin numbers if you use a chip with less than 32 I/Os

An update finally! Sorry about that, I intended to have this done a week ago. But between moving out for 3 days for a fumigation, spending an evening driving 2 hours each way to see Cats, family emergency, and other volunteer commitments....ya. Anyhow, the PS/2 keyboard now works. I actually had this going a week ago, just was waiting on some time to write the code to convert from PS/2 sequences to 7800 keycodes. I think I've found something I am happy with. The keyboard still types in all Caps, but you can use some punctuation now. I need to type out the full data tables (shift, control, shift+control) so that you can get all the keys on the 7800 keyboard. Key repeat is controlled by the 7800, just as it should be. The typematic stuff from the PS/2 keyboard is ignored. I still haven't implemented the keyboard status command, which ticks me off. It's pretty simple to do, so I'll do it in a couple of days here if work doesn't snow me under. I have to get serious there till the weekend. Anyway, if I can clean up this data table issue, and the keyboard status command, one of the three features of the original keyboard will be DONE. That would leave SIO, and casette. And I've still not gotten to test with original software/hardware. Anyhow, new code is up here: http://www.phin.com/atari7800

What I found adding a serial port to my commie 128 is... The setup timings are very exact on 6502. It is not possible on all chips to just set your address bus, data bus, chip select, read/write, and everything in any order. Normally, the CPU takes care of this as long as the whole system runs at the same clock rate. When the system runs at different clock rates, as the 7800 must do in 2600 or 7800 mode, things get tricky. It is quite possible that a 2mhz RIOT would fail if accessed at 1mhz, given the order and delay of setting up address, data, cs, rw. PHI2 is not the only signal that a 65xx part uses to latch signals. Either that, or they did not want to put yet another 2mhz part in the console to save on cost. Given the logic inside MARIA that they then needed to slow down the system each time, I somehow have trouble beleiving that. So, I'm going to guess it's a very annoying timing issue.

Full compatability is the only thing I would consider. Yes, at some point I need to have a real keyboard and or real software to test with. Having implemented more than one protocol 'by spec' at work, I know all to well the differences between specs and reality!

Note, I just rather found a problem in my design. Or, at least I think it's there. According to the spec, there is a breif (few microseconds) period as the port changes direction from keyboard->7800 to 7800->keyboard where both devices are trying to output on the data lines. This is basically a 'wired-or' condition which would try and pull huge amounts of power from the I/O ports on each chip. Adding some lowish resistors to the lines should help. The original keyboard use 470ohm resistors, and in addition to their use in the low pass filter, they will prevent the 'wired-or' case from burning excessive amounts of current. It hasn't caused me a problem during my testing, and I've REALLY electrically abused these chips with silly mistakes, so my guess is, they can take the overcurrent for the few microseconds it exists. But, the problem is still there. BTW, since A2600 asked, my TV is a Panasonic 34" hi-def Tau. The old style with no HDCP port, so if they ever turn on HD copy protection, I can't watch.

Well, last week a discussion got started on the relative difficulty of making a PS/2 to 7800 keyboard adapter, using a modern microcontroller to do it. Somehow, I got the impression that a challenge was put forth, and so I decided to do something about it, rather than just think about it as I have for several months. This necessitated finishing the EEPROM adapter that stacks onto the BIOS ROM socket, and installing Win98 on my machine so that my POS EEPROM programmer would work. It gets allergic to XP and shuts down half way through the write. Anyhow, I managed to get as far as getting the 7800 to sync with my Atmel microcontroller and then obtain 'keypresses' via the Atmel's RS232 port. Thus, I have my laptop hooked to the developer's board of the Atmel, feeding it characters that the 7800 polls just as it should from the 'real' keyboard. In the pictures you can see my EEPROM stack board with my keyboard test program loaded on it, the atmel plugged into joystick port 2 as the real keyboard would have been, a couple of pictures of the board to show where I plugged into it, and a screenshot of my laptop with a test message typed in, and a screenshot of the 7800's display of that same message. Although the communication between the laptop and the Atmel is RS232, the communication between the Atmel and the 7800 is PROBABLY the same as the original keyboard. All I have to go on, of course, is the programming spec that got scanned and posted around. So, it could be totally wrong. My next attempt is going to be to hook a PS/2 keyboard to it instead of the RS232. That would make it slightly more authentic feeling. After that, I see no reason why SIO shouldn't be doable. The 'brains' of the SIO system were all on the 7800 anyway. The microcontroller in the keyboard does little to nothing to process each command. Anyway, to prove I'm not full of it, pictures are at: http://www.phin.com/gallery/atari7800 And the source zips for both the 7800 code and the Atmel are at: http://www.phin.com/atari7800 The current code has many limitations, such as, no punctuation, capital letters only, no return key. These limitations are all very cosmetic. The actual act of passing triplets and bytes over the joystick port is working perfectly to spec as far as I can tell. Of course, without an actual keyboard or actual software, I can't be sure. Right now, one big thing that I can see is that I don't support the keyboard status command, that the real games would probably have used rather than transferring the full keypress byte each time. But again, that's all quite cosmetic. Sorting out my electrical issues was a problem. I'm NOT a hardware guy, I just do it when I have to so that I can write software.

I believe the problem was one particular IC that was not manufactured anymore. He needed the original code to program it onto a more modern IC I beleive. After meeting the rest of the guys from GCC last year he might have access to it now, although I don't know. Not sure it will ever happen though. It's a big undertaking. I have my fingers crossed just in case. Allan 840966[/snapback] Well, ya, that IC isn't available, but it shouldn't be THAT hard to recreate the code, even from scratch. Of course, I did a software generated video pong game from scratch with my Atmel board in a weekend. I'm just sort of slowly working my way to running my own code on the actual 7800 hardware. Not sure if I'll get around to trying such a thing any time soon.

Dunno. I seem to recall standing a foot away from one at a CGE and saying, "No, I could, but I shouldn't." And then going and blowing more money in the slot machines. Anyway. At one time, at least, they were obtainable. If someone would post the images of the carts, it would be really easy to make a PS/2 to 7800 keyboard adapter. The protocol is published on a couple of web sites, and is a pretty simple protocol involving 3 data lines and two clocks. An Atmel micro could easily handle the translation. I'd considered doing it, but of course lack cart images to test with. I have the atmels and everything. Of course, I should just do it and release some test code. The keyboard does have a cassette adapter (easy), and an SIO connector (annoying, given the proprietary connector). But all the programming sequences should work with all of them.

The console itself? They're about $60 to $100 on eBay. The keyboard add-on? No clue. If you find a supply, let me know, hmm?

Lemmings would be tricky due to the way the diggers worked. That really calls for bitmapped graphics instead of the sprites used by MARIA. 833651[/snapback] Mmm, it would require bitmapped graphics, but with 16k cart ram, the machine CAN actually do bitmapped graphics. 160x192, but technically bitmapped. With some fancy effort, you could probably put enough cartram to do 320x192. But, can you update a screen that large in the 2500 cycles you have available in the vertical blank? Given how slow the diggers worked, and the small # of pixels needed, I'll bet you could. Of course, you'd need a large rom and bankswitching to let you copy in the relatively huge bitmaps. Hmmm, too bad I suck at art and hardware.

That's probably not a bad idea to remove the RF modulator. It seems, at this point, that you have to disable the audio mixer anyway, which would negate the usefulness of RF. Note, I still suspect you can do it without disabling RF, but it will be slow going for me to check it out. Anyone know a GOOD analog electronics book? Not so much a complete one, but the sort that says, "This is a wire. It's made of a substance called metal. First of all, we'll try bending the wire! Wow! See how it bends?" That's about where I am with the analog side of the world. However, that would still only give you access to composite video. And void the warranty on your brand new 7800? You can tie to the MCOL/MLUM0-3 pins on the expansion port and get SVIDEO. That will give you better graphics. But, only in 7800 mode. The only way to get SVIDEO in 2600 and 7800 mode is to tie to the points mentioned in the other hacks.

Again, I ONLY have a breadboard version of this, and I never did understand analog electronics, so your mileage may SERIOUSLY vary... However, if you try and solder to those points, my guess is video should work. Give it a try and let us all know what happens! Rather than disconnecting the audio modulator, couldn't one just put a low pass filter to trim off everything above 5.8 or 5.9 MHz (where the modulated audio sits?) Rather than asking that, I suppose I should try it.

Well, don't ask me why it works, but I actually tried tying CVIDEO from the expansion port on my 7800 to a video in on my TV, and it was there. Barely, but it was there. Experimentally modifying the video driver circuit from an existing SVIDEO mod, I got a definately viewable picture. Take a look at it here: http://www.phin.com/gallery/expansionport It's still picking up interference from something. Gives me diagonal lines racing back and forth over the picture. Probably the result of trying to run composite video over a breadboard. But I'm not going to try SVIDEO tonight. Oh well. I cannot, however, find a usable audio signal on the expansion port. It OUGHT to be there, I just can't find a way to make my TV use it. Well, now that we know you CAN draw video off the expansion port, what can we do with it? [/url]

Oh, I agree. Being able to design "hardware" while still staying at the conceptual level rather than having to worry about "How much noise is on all these wires?" Or, "Why is it just sitting there letting out blue smoke." However, looking around the appropriate websites, it seems all the FPGAs are surface mount only. Or 1.8v. Or something else that doesn't work well for hooking an FPGA to a old console. Are there any docs on prototyping in the modern world, pretty much dominated by companies who roll PCBs for each try because it's the only way to make your design work?

Yes, I am aware that we have the code signing issue solved. But really...rather than sitting on our collective asses, we should have been writing games and working out EASY console mods.

And my point also was about the skill level required. In order to distribute homebrew code, the skill level needs to be VERY VERY low, so that the average classic gaming collector is willing to modify his console. Clipping two pins and possibly installing a switch is very easy, and something that most classic gaming people can do. Burning an EPROM is both expensive (if you do not already have a programmer), and above the skill level of most collectors. Building the needed inverter circuit is also above the skill level of most collectors. My point was, rather than spending 5/10 years saying "No point in writing homebrew games, as no one can run them.", we should have been looking for quick and simple mods to let people run homebrew games. The EPROM circuit, while far from complicated, is more than the average collector will want to build to run a homebrew game.

I think you both missed my point. It took me about 5 minutes to use my method. It would take me much longer to put in a new eprom. And I have no eprom programmer. Nor do I want to buy one. Hmmm. Who's method is more useful now?

Well, I tried for this years ago before the encryption program was discovered. And, not knowing much what I was doing, I rather failed. However, I got my new 7800 this week, and so I got to playing with it today. Cutting pins 10 and 12 of the 74LS174 that sits two chips away from the power connector bypasses the BIOS and runs 7800 games signed or unsigned. It does, however, also disable 2600 mode, as the BIOS switches into that. Now, of course, it makes little sense unless you want to get around the several second wait when testing your programs. Which is nice, sometimes. I'd recommend installing a DPDT switch, connection the holes for pins 10 and 12 to either +5V, or the original pins. The theory is this. All the outputs of the 174 start out at 0V. Pin 10 disables the A12, A14, and A15 lines of the cartridge port and enables the BIOS ROM at the high end of memory. Pin 12 disables the HALT line to the CPU, preventing the MARIA from taking control when it needs to. When the BIOS wants to read the key from the cartridge, it copies itself to RAM and fiddles with pin 10 to bring the cartridge into memory. It reads the signature and if it's valid, enables MARIA, disables TIA and locks out changes. If it is invalid, it disables MARIA, enables TIA, and locks out changes. According to the Atari docs, all cartridges must, upon startup, enable MARIA, disable TIA and lock out changes in case the BIOS ever changes. The configuration chip state is undefined at startup. Cutting pin 10 causes U4 and BIOS to see a 'no connect' state, which is defined in TTL as HIGH. This disables the BIOS as CS2 goes high, and stops gating the cartridge port. The cartridge gets control at startup, sets the config chip to 7800 mode and things run perfectly, no startup delay. Of course, programmers WILL break the rules. One on one basketball does NOT seem to set the config chip on startup, and this the TIA and MARIA try and run simultaneously. Galaga, Pole Position, and Centipede seem to do the right thing. Pin 12 goes high after two writes to the config register, enabling HALT and thus MARIA accesses to memory. As the cartridge will only ever perform one write to the config register, pin 12 must be cut as well to allow MARIA to function normally. So, it's not a perfect hack, but it would have allowed us to have been homebrewing a long time ago if someone with the schematics had ever found this. I think given the # of people that install mod chips in their NEW game consoles to play imports and that which they are not supposed to, plenty of people would have cut two pins to play homebrew games. We're all geeks anyway, those of us that would drag the old Atari out of storage.

Wasn't that a Compute's Gazette trick back in the day? They ran a short little basic program that would copy basic ROM to RAM, and then change a few of the keywords. It was kind of cool to be 'changing' rom. I wrote a few things under BASIC. It was a pretty good place to hide trainers for some of the early games, which often filled up all of memory, but forgot about the hidden RAM.

Mmm, true, in a sense.... But the 8086 had a cousin with an 8-bit address bus, the 8088. They could run each other's programs, however. Same with a 386. The DX has a 32 bit address bus, and the SX has a 16 bit address bus. But they both run in 32-bit protected mode. So, then by your definition, a 386 based PC may, or may not, be a 32 bit machine? Of course, they said the Jaguar was 64 bit, when it only had a 68000. They said, "The graphics fetch is 64 bits wide, so it's 64 bits when it needs to be.". By that method, a C-64 was a 12-bit machine. A graphics fetch can be 12 bits wide (color ram can be read simultaneously with system ram). Or a PC is 256 bit, as the graphics chip can often read data from ram 265 bits at a time. The whole bit count issue got way too muddled way too long ago to sort it out now.

Why DID all the 8-bit CPUs stop at 64k? 16 bit CPUs spent a few years going from 20-bit addresses on the 8086 and other small addressing schemes (68000 was limited to 8 meg or something IIRC), till they finally settled on 32 bit addressing. But 8 bit CPUs started at 16 bit addresses and stayed there. Why not put 32 bit addresses on an otherwise 8-bit CPU? Acutally more to the point, the AVR microcontrollers are very 8-bit ish, but they have chips bigger than 64k, and I don't beleive it's bankswitching.

The following URL shows the default memory map of the c64 with 38k free for basic. http://www.devili.iki.fi/Computers/Commodo...5/page_263.html The next page shows the basic and kernel ROMS flipped out. LORAM and HIRAM are just bits on the register at $0001, easily adjustable from any software program. http://www.devili.iki.fi/Computers/Commodo...5/page_264.html I'm not going to provide an explanation of every memory map the machine offered, but it was more than just using memory allocated for basic. Basic and Kernel are GONE in some of these modes.

Mmm, "poke 1,0" is a "modification" by an "experienced user"? Sorry, I just hate the myth that the bulk of the 64k was inaccessable, when most people have never gotten the programmer's reference guide and looked through the rather good explantion of the memory banking system, as it were. Clearing all the bits in the config register (yes, you're clearing more than that, but bear with me) banks out kernel ROM, basic ROM and I/O. If you type that, the computer will hang, as it goes 'dumb' so to speak. Now, it is true, that BASIC itself was usable in only two modes. 38K free for basic, or 30K free for basic with an 8k external rom. All other modes had to be written in Assembly/ML. However, this does NOT mean that you can't have some fun with that. The QLink (AOL's predecessor) software ran multiple machine language processes and one basic process, flipping out both roms and I/O as needed to run whatever process needed to go next. It even had RPC calls. Ow. But, yes, the average user would only ever use 38k for basic and the extra 4k for ML that come in the default mode. My preference was to stuff the hires screen (8k) under the kernel rom. The video chip mostly ignored ROM, and so it didn't care about the kernel being banked in from the point of view of the CPU. As long as you never (rarely) needed to read back from the hires screen, this freed up 8k of easily accessible memory , while eliminating the need to swap ROM in and out all the time.

Any item that shows up twice in a search list is not RARE. It amuses me when I go on eBay and search for Atari and it comes back with a screenfull of "Atari 2600! RARE! [email protected]@K!" Dude, if the SIMPLEST of searches returns more than 1 or 2 hits, the item is not, by any stretch, rare.

Well, I just used 'xmess' available from http://x.mame.net/ Now, the build process is a REAL pain. You have to edit a rather large makefile by hand, and must have the development tools from Apple (free, but a very large download) It's updated to 0.92, however, so if you're used to building your own software under Unix, it's a good alternative. Oh, you also need X11 for OS X. Comes with 10.3, or a free download from Apple.