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.

I've been doing some experiments over the past couple of days to try and get my head around the NTSC artifacting on the 7800. I understand the cause, but not how to use it. That said...it only works when I'm using composite/RF out, not S-Video. Again, that makes sense as S-Video was created to eliminate NTSC artifacting. However, as more and more people mod their consoles for S-Video out, should we stop using the artifacting, and instead assume it will not occur? It does seem like an either-or choice. If you ignore the artifacts and write colors as you please in 320 modes, users on unmodded consoles will find the screen smudged beyond all recognition. If you use artifacting, and a user plays it on an S-Video console, the screen will look messed as well. My particular experiment was with 320D mode, hoping to make something like an Apple II graphics mode. If I recall from those years, on the Apple you only had Green or Purple pixels (or Red and Blue), but if you put a green pixel next to a purple pixel, you ended up with a white pixel because the color decoder in the monitor would screw up. That doesn't seem to work on the 7800, or at least not with my fancy HD TV (yeah, it's got RF in). I get some color that looks mostly like the SECOND color I draw. As in, if I draw green, purple, green, purple, green, purple, I get a solid purple bar.

Are you sure? The offical docs say there is an uncertainty in the amount of time a DMA startup will take. It takes 5-9 video cycles to halt the CPU. That doesn't sound like the CPU will stop in the middle of an instruction.... The lineram within the maria is double buffered, and that in addition to the amount of time the video chip holds HALT low for should be plenty to aleviate the need to halt the CPU in the middle of an instruction. Of course, I've never seen a datasheet for a 6502C, and thus don't have any way to prove what goes on at that level. At any rate, since the MARIA is read only, it probably doesn't matter.

That's what I used for Tubes, and there were just enough Maria cycles left to do a pair of 16 pixel sprites, plus a bit more for score and stuff. The real problem is that you have almost no CPU time left. That includes vertical blank handlers, which will only get a few cycles per HSYNC. The Maria is literally The Thing That Ate The CPU when you try to do a nice looking background in a 320 mode. Yeah, that was my great disappointment as I started looking into the 7800. Is there a reason why they didn't sit on the phase 1 clock like commie's VIC chip? My guess would be, though I don't find anything truly confirming or denying this, that it loads DL and DLL entries at faster than CPU clock. That would explain why they NEED to sit in RAM. On the other hand, ROM seems to be accessed at the 1.79MHz, so why didn't they just sit on the silent side of the clock? I don't THINK it's ROM speed, as the Ultimax used the VIC chip to grab chars from ROM, and did on the sly.

Well, I would have picked colors that were basically NTSC compatible. Apple used RED/BLUE or GREEN/PURPLE. Those always came through true enough. On the commie, I always liked blue/yellow as a nice pairing. As to forcing it to start a new DLL...hmm. Since the DLL includes VBI, then forcing it to start over again wouldn't do what you want. Which brings to mind...would not the 2600 and 7800 be possibly the only game consoles able to close caption their games? Tho, it would be pointless, I think. What would you print? "Strange explosions..." WSYNC exists in MARIA space. You could just do WSYNC/colors/logic/WSYNC/colors/logic. While that is icky compared to writing a more traditional program, 2600 programmers are often stuck with that, or keeping all game logic in the VBI.

I just reread the description and finally figured out what it means. Really not very clear at all. Basically, it would seem to be pretty much like artifact color, except with a little more control over the exact color hues than one would get with artifacting alone. I would expect that artifacting would tend to dominate the colors produced (e.g. if having even pixels black and odd pixels white would generate a particular hue, having even pixels be a dark color and odd pixels a light color will generate a similar hue; using different colors can change the hue somewhat, but only in very limited fashion. What I'd like to see more would be a practical way to alterate color sets on alternating scan lines. Unfortunately, I don't know any way to do that without typing up the CPU during the display scan. Is there one? Mmm, I don't know that I would say artifacting would dominate...it is like almost any console/computer's 320 mode on a standard TV. You are changing colors faster than color clock, and if you ask the decoder in the TV for too much, you will get an artifact. On the other hand, if your colors are close, it works OK most of the time. On the commie there was a nice little grid of which colors could be next to which colors with minimal/slight/severe artifacting. Most of them were classed as minimal. And as to changing colors? On the high color sections of the screen, do one DLL entry per line. You have a limit of 256 or 512 bytes in the DLL, so you can't do a whole screen this way. But this way you just pick which pallettes you use. If you need a whole screenful of line by line color changes...hmm....dunno.

Running the calculation on doing background tiles recently, and reading what others have to say, you're pretty much not going to do background tiles in 320B. You technically can, of course, but you'll have nothing else on the screen. Not exactly a 'background' when there is no 'foreground'. However, there are ways to make a useful background tile mode. 320A: It works. Set for 2 byte tiles, 16 lines high in your DLL. This gives you 21 (with smooth scrolling) 16 pixel by 16 pixel tiles. The math: 12 (for DL) + 21 * (9 (for gfx data) + 3 (for charmap lookup)) = 264 out of 405 cycles. Plenty to do your own sprites on top. Problem is...monochrome. The whole line must be the same color. You might be able to live with that, tho. 320C: Unsuitable for same reasons as 320B. Already uses two bytes per 8 pixel tile, requires blitting 40 tiles/line. 320D: Sitting out there is a icky, nasty, horrible 'certain colors in certain columns' mode. That uses one byte per 8 pixel tile. That can be set for 2 byte mode just as the 320A trick. Same performance, 264 out of 405 cycles. And, I was looking at it last night, and I realized that it is not that fundamentally different from the Apple II's graphics, and everyone learned how to deal with that. Odd columns handled one color set, and even columns had another color set. Thus, it should be possible to at least get a background going, and fill in any issues with sprites on top. Unfortunately, I am not nearly enough of an artist to know how to make a tileset that would use 320D mode effectively.

Impressive! BTW, how are you testing your code in the flash? It looks like you've got a 100% surface mount design, and I can't see any way to remove the flash to a programmer without soldering and desoldering. Also, any consideration to bringing the HALT line into the memory bank controller? That would allow the programmer to have the video chip see different memory than the CPU. I'm sure someone could come up with some use for that!

Does anyone have the mechanical specs for a card edge connector, namely the somewhat wierd one that the 7800 uses? I've not seen any PCB layout software that offers good support for card edge connectors at all, and I'm pretty sure you'd have to roll your own for the 7800's notched connector.

Ya, I didn't even think of that. Unless you could predict when the keyboard would send data and do your processing. I guess that's exactly why the official keyboard has a clock in each direction. Any time one side or the other gets busy, it just stops responding to the clock, and the protocol automatically halts.

Actually, that WOULD work if you can poll the joyport fast enough to read 10-16kbps. I'm mostly doing my project as a learning exercise, and because I love bit-banging funky protocols. And some FSK demod for the casette would be fun too. Of course, to be able to offer board layouts and code and everything, maybe even a kit, that would be great too. But, here's what you would do to wire an AT or PS/2 keyboard directly to a joyport. Use an open collector inverter. It's a 74xx part, just don't remember the number. Wire two inputs to D0 and D1 on the joyport. Wire the outputs to D2 and D3, as well as keyboard clock and data. Connect power and ground. Now, to send data to the keyboard, send it INVERTED on pins D0 and D1. To read it, read it NON-INVERTED on pins D2 and D3. People who have done fast loaders on the C64 will know EXACTLY what I am talking about here. When the DMA starts on the 7800, write a 1 to the clock inverter. This will pull DOWN the clock line and stop the keyboard from transmitting data. Write a 0 at the conclusion of DMA to allow the keyboard to send bytes again. The keyboard generates clock, thus if you cannot keep up with 16kbps, some keyboards will be iffy, and some will work.