Flipper

I've got the links the to the 7800 side code that I wrote, as well as the Atmel code. As to schematics, something blew out my 7800. I don't know if it was bad static handling or if it was a bad cabling job, but it was REALLY hacky. Just some soldered wires between at Atmel dev board and the 6532 pins. If you're not a programmer and hardware guy, you're not going to be able to use what I got done before I fried my machine.

Sorry, my site moved.... Everything is back up at www.spinnyphin.com

They also don't have standard names. One opcode that I added to my repertoire back in the day was LDAX, but I've seen it called a couple of other names. It was pretty reliable across all addressing modes, and handled the basic ones I used. As you might guess, it loaded A and X in the same cycle. Much faster than LDA/TAX or any other pair. Another issue with undocumented opcodes is that they're only found on the NMOS process 6502s. They become a NOP on all CMOS chips, such as the 65C02 and 65816. Some software was incompatible with 65C02/65816 upgrades on the Apple II and C64 machines, because it used undocumented opcodes in it's protection or for performance. And some of them lock up the CPU. Watching for a program trying to jump to a $02 was a big clue that the protection had failed.

If you use the resistance in an RC timing circuit, as the 2600 does, the results will be inherently linear. Using a pot as a rheostat rather than a voltage divider will tend to make things a bit jittery no matter what you do, but the RC timing approach is pretty simple and cheap, and it's probably no worse from a jitter perspective than using a straight ADC. That being the solution I would have taken, not knowing any better than "it worked for Atari." Out of curiosity, WHY would using a pot as a rheostat be more jittery than when it's a voltage divider? I'd have thought that the same tolerances would be in place mechanically?

Thanx. Didn't happen that long ago, either.

It's possible yes but I have not done it myself yet. It would require some work and an amp for the video as from what I have read the output is very weak. Gracias, Sr. I'll take a look at the signal. What I'm thinking of feeding it into may be able to handle a weak signal okay. Take a look at My 7800 expansion port attempt. It's quite doable, however I found the following issues. 1. When taking composite video from CVIDEO, the FM audio signal is mixed in at 4.5MHz or whatever it is for NTSC. The filter required to trap this signal without affecting the phase of the color burst that I was able to find a schematic for was over 30 components (cheap, but lots of soldering). I'm guessing when I do digital electronics, and analog I have no background in. 2. When taking video from the digital port and using a standard 2600 S-Video out mod, you get wonderfully clean video, but in 7800 mode only. The digital video is tapped before the OR gates that combine the TIA and MARIA, not after, so you only get the MARIA signals. I had hoped that an analog guy on here would pick up my efforts and run with them, but nothing ever got done. I wish you more luck! BTW, I think I have the algorithm for doing genlock on the 7800. Use RDY (on the expansion port) to gracefully halt the 6502, use EXTMEN to disable and enable MARIA briefly (documented to reset all sync counters), and then release RDY. A LM1881 would do the sync separation, but I don't know when a good time to pull RDY low would be. Mixing the signals is easy, just wait for LUM0-3 to be all 0, and cut the input signal through.

Ok, so what is the 'point' of making any sort of game for a console that's been out of production for 20+ years, never sold well in the first place, and isn't that good in some respects? If I were to do it, and I've already got way too much on my plate, it would be to: * Play with my microcontroller stuff * Get some practical use out of my flash-modded 7800 * Learn PCB layout * Play with some 6502 code. * Make a 7800 draw pretty pictures The one-off costs wouldn't be too hideous. PCB would be the largest cost, and that can be shopped around pretty cheap. Just..time.

Yep...the microcontroller in the cartridge would make the directory listing and the ID3 tags available to the 7800, and accept the menu selections from the 7800.

Looking at some of the VS1001 designs, I could probably bang out a schematic, but the mechanics of getting a card edge connector entered into PCB layout software is beyond my experience. Getting the parts wouldn't be an inordinate difficulty either. Time, time, time.

In theory? Sure. Both the C64 and the 7800 are 6502 based machines. The 7800 has the advantage of having an audio input line on it's cartridge port, so you wouldn't need separate jacks for mono sound (obviously, you would if you want stereo). I've had the idea for some time of making a game and rather than incorporating a POKEY or SID or something hard to get, putting a standalone MP3 playback circuit and using an emulator to pre-render the sound on a PC. This would require having an idea for a game worthy of making into a cartridge, and teaming up with someone who could write music. The problem with the H/W MP3 codecs is that they can be tricky to get ahold of in small quantities. Finding them in 1,000 unit quantities for making iPod knockoffs, easy to do. Finding 20 to make a run of video game carts..not so easy. One source that seems obtainable is VLSI's VS1001. They do have ways to get small quantities! There are some projects out there that show the techniques for using this chip in an embedded environment.

Ok..true...you could have two entry points. One with some setup code to get the stack right, and then one for the interrupt routine. It's a little bit ow either way.

Sadly, it doesn't work. From a 6502 information site "Note that unlike RTS, RTI does NOT add one to the destination before placing it in the Program Counter (PC)". Thus, you'll end up returning to the wrong address. Also, RTS does NOT pull the processor flags, so you're stuck there too. One method which may be available to you is to use BRK, NOP. BRK is really a software interrupt, thus can be returned from via RTI. Note, when used as a software interrupt and you want to get control back to the main program, you must follow the BRK with a NOP. The pointer stored by BRK is off by one, and will skip the next byte of program code. Of course, since the BRK pointer is stored in ROM and shared with the IRQ pointer, this may get you no savings.

It's a simple 3 bit protocol, and requires maybe 100 bytes of code in the cartridge. However, to make it a full 'computer', yes, you're going to need extra ram. But just to include 'keyboard' support in a game, would take nothing at all. You could even do game saves to tape with little extra code, and no extra RAM.

You know I've been thinking about this, and you know what might actually be easier that a special keyboard, molded case, motherboard for keyboard and I/O port? A little converter box that would convert a standard keyboard with I/O ports on it. Not even a box, the case the use could add later, but just a board with a keyboard port and I/O ports. Maybe add extra ram... maybe. Know what's sad? I had this working...well over a year ago. http://www.phin.com/atari7800/ There was some brief interest, then I blew out something on my RIOT, and the port didn't work too well. However, that shouldn't have stopped anyone from replicating my results and extending on them. Oh well.

Well, I have thought about doing this, but the color signal has been mentioned as a possible issue. I suppose that could be. The theory is as follows, however. On the expansion port, there is a signal EXTMEN (External Maria Enable). It maps through a couple of gates to MEN on the Maria. Buried in one of the datasheets on the net, is a lttle side note that pulling MEN inactive results in two things: 1. 2600 memory mapping is engaged (we knew that one) 2. The sync counters are reset, starting a new frame. So, the theory really OUGHT to be as follows. After a VSYNC is detected (CSYNC is available on the expansion port), count off 260 (ish?) HSYNC pulses. An LM1881 can do the sync seperation for you. That's overkill, but it's cheap enough. At this point, pull RDY low, halting the 6502 gracefully. Using another LM1881 to break down the signal from the LD/DVD player, wait for VSYNC. When you see VSYNC, pull EXTMEN (high?) for 1 cycle, then release it and RDY. The CPU should start over. If the game is using a normal wait for VBLANK loop, it should now pick up with the next frame. Then, when LUM0-LUM3 are all 0, have a video switch select the LD/DVD player (maxim makes switches that should be plenty fast enough). Of course, as someone has suggested, the color signal may not be in phase enough. And there is some RF-design here, too, well beyound my level. On the other hand, many systems have offered genlock capabilities without implementing a full TBC. NTSC color is such crap I suspect you could commit many abuses. Now, that said, why an LD? You can make your own DVD's, and there should be no fudging with the color signal at 227.5. Either way. In order for your TV to decode the signal, the color burst must be pretty much 3.58MHz. The LENGTH of the video data on the line is irrelevant, as long as the sync is still pretty much 15KHz. The mixing and output would be done on the board attached to the expansion port, and the internal RF modulator would be ignored. There is, unfortunately, no way to disable the internal OR drivers used between TIA and MARIA to inject your own signal to the RF. But, yes, the only thing the expansion port is good for is video/audio out of the console. I've got a really crappy SVIDEO out plugged into the side of mine. Of course, it's protoboard stuff, and my protoboard soldering skills are really really scary, so the signal reflects EVERYWHERE, and luma is deplayed by about 2 pixels from chroma, so it's hard to look at. The computer keyboard plugs into the joystick port, needing nothing from the expansion port. What frustrates me about that is I was well on my way to implementing one with an Atmel when two things happened about a year ago: 1. A hardware design fault somewhere blew out my 6532. I have not yet checked it out in detail, but I suspect I blew out the output drivers. 2. Curt Vendel annouced that he was intending to make that device REAL SOON NOW. So, I backed off. The schematics are online. The programming docs are online. The communication protocol is simplicity itself. Any microcontroller you choose can easily handle it. I was using an Atmel AVR and had PS/2 to 7800 going just fine, and was typing on the screen. That constitutes approximately one weeks work. And you know, the puttering around after work work, sort of work.