EricBall

Packrat Video Games (although I don't know if they still have 'em): http://www.packratvg.com/pictures/sk2.jpg

Yes, it would be possible to use external components to virtually add pins, but that would drive up the project cost due to needing a custom PCB. My current plan is to use the Teensy++ 2.0 as a semi drop-in replacement for the 6805. Both are 40 pin DIPs and most of the pins match up so I can just solder on some headers. And I'm hoping some simple wire can bridge the few mismatches. From a firmware perspective, I'm looking at using code done by Soarer - which is very easy to customize. There's also Hasu's popular TMK firmware. It's very powerful & customizable, but requires you to recompile it to make changes. Of course I wasn't able to find the nut driver at Home Depot or Princess Auto. However, it appears it is a common tool in the RC world. Unfortunately, my local hobby shop is out of stock at the moment.

More research & thinking: First, Atmel makes AVRs with built-in USB controllers - so the result is much more "according to spec" than those where the AVR had to bit-bang out the USB. Unfortunately, the common ATMega32U4 only has 26 I/O while I'd need 27 (16+8 row/column matrix + 3 LEDs). The AT90USB1286 based Teensy++ has 46 I/O, but costs $24+shipping. And one of the objectives of this project is a keeping the project (tools & material) costs low. I've also been thinking about how I'm going to connect to the keyboard internals. Although I haven't opened it yet, my understanding is there are several ribbon cables connecting the keyboard matrix and LEDs to the 6805. My first idea was to desolder the cable connectors from the PCB and then somehow connect those to the AVR breakout board. But the I had another idea - why not remove the 6805 and connect the breakout board there.

Update: I've found some keyboard hacker hangouts - in particular http://deskthority.net/ and http://geekhack.org/ One advantage of using something like the Teensy (AVR based) versus the MSP430 is there's other people also working on it. So there will be improvements over time. And while it might be possible to get something like the Sprintek controller cheaply, then there's the cost of the PCB & USB port. But the first thing I need is a 5.5mm / 7/32" nut driver to open the case. (Or I can use a Bic Pen: http://i.imgur.com/7fjQCXA.jpg )

While working at IBM (1993-2008) I acquired several classic Model M keyboards. Unfortunately, they have PS/2 connectors which isn't supported even by many current desktops. I have bought one of the "blue cube" adapters so I can use one at work, but I'm thinking I'd rather "roll my own" - open up the keyboard and replace the 6805 based controller with something that will output USB. This has been done before by others, so I'm not breaking new ground. I even have a keyboard which is missing the SDL cable - so is ripe for modification. The question is what microcontroller to use. The popular hobbyist solution appears to be either the ATMega16 or 32. However, I also found a TI whitepaper which uses the MSP430. The advantage of the MSP430 is it should be more "according to spec" versus something which works "well enough".

Hrmm.. I'm not sure I should be trusting my memory on this... Let me look into it. (It may have been a CYA, like doing a SEI on a 2600 game.) Ok, I've reviewed the 7800 BIOS disassembly on http://www.atarihq.com/danb/files/7800bios.asm and while the BIOS locks INPTCTRL before changing to 2600 mode LF831: LDA #$FD STA COLUPF JMP(LFFFC) ; And use the reset vector on the cart to start it doesn't for the 7800 mode. LF7B9: LDX #$16 ; finally, back to something important STX INPTCTRL ; switch out bios and use reset vector TXS ; on cart to start the game. SED JMP(LFFFC) So it's necessary to store #$x7 to $0000-$001F before trying to update any TIA registers.

You probably want to note it is set & locked by the 7800 BIOS so cannot be changed by the game program (2600 or 7800).

INPTCTRL is a write-only register mapped to $0000-$001F implemented by an external circuit (U11 on http://atariage.com/7800/archives/schematics_ntsc/Schematic_7800_NTSC_Low.html ) It is normally set (and locked) by the 7800 BIOS, so it's invisible to the program.

And I will be very very upset with the guys who sold me the iMac (local outfit - better than Apple pricing & authorized service center). However, I think the iMac will still have a better GPU than the next Mini - which is probably worth something.

Back in late September when Apple announced the Haswell iMacs I thought it wouldn't be long before Apple would announce a Haswell update for the Mac Mini. But in spite of much forum speculation and rumor no update has occurred. I'm done waiting, so I will probably buy an iMac in the near future. Which is funny, because when the Haswell iMacs were announced that was what I was going to do. But then a coworker pointed out the wisdom of keeping the screen & CPU separate (so the screen could be used with a different CPU) and the waiting began. Last night I discussed our options with my CFO: 1. Continue waiting. However, there's no guarantee a new Mac Mini will be forthcoming in the near future. There's also the risk Apple will make unacceptable changes (e.g. SSD only - not good for my video editing plans). And I'm already kicking myself for how long I've already waited. 2. Get the current Mac Mini & 27" display. 3. Get the 27" iMac - which not only has a better CPU & GPU than the current Mac Mini but costs a little less (depending upon configuration). We concluded the better CPU / GPU is worth more to us than a separate display. And while a separate display could be used with a different CPU, we don't upgrade that often. Now I'm just trying to convince myself that I really should go big and get the i7 & 780M instead of the cheapest 27".

Maybe... are you referring to the graphics data used by a normal direct sprite, or the list of LSBs which are added to CHARBASE to obtain the graphics data (indirect sprite). It's that list of LSBs which are in question (RAM vs ROM).

It's not the CHARBASE which is in question, but the character list pointed to by the display list entry.

A display list describes the sprites on a number of lines (typically 8 or 16). The pointer in the display list entry points to the last line of the sprite, with each previous line being on the next page in ROM. So if the sprite moves down a line, the pointer is adjusted to bottom line + 256. Then an entry in the next display list with a pointer = bottom line - 256 * (number of lines in zone - 1). "Holey DMA" is so you don't have to waste ROM space for the lines above and below the sprite. Building (or updating) the display lists is a non-trivial thing to do efficiently. Just like the kernal of a 2600 game, there is value in ensuring all data structures in a 7800 game are arranged to make building display lists as efficiently as possible.

Some of the Zelda games have a fishing minigame http://zeldawiki.org/Fishing you can also fish in Minecraft.

Although it probably won't make a whit of difference, you can push it to the following - verified as same as INT([0-185]/5.0): #define DIV_BY_5 0x19999A #define DIV_BY_5_SHIFT 23

Indirect mode (aka character or tile mode) is specified by a 5 byte display list entry containing a 16 bit address pointer to the character / tile map in RAM (required?), the number of characters / tiles to display (i.e. bytes to fetch from the pointer) along with the horizontal position, the palette and the write mode flag. Each character / tile byte is used as the LSB for the address of the graphics data (which may be in ROM or RAM); the MSB coming from the CHARBASE register. Either 1 or 2 bytes of graphics data may be fetched per character / tile. As per the second link, MARIA has a different set of timings for graphics data (ROM) versus non-graphics data (RAM) accesses. I don't know whether MARIA changes timings based upon what kind of data is being fetched or the address (like it does to the 6502 for RIOT/TIA accesses). In addition, the cycle count list shows character maps taking 3 cycles - the same as a graphics byte. So it might be possible to put the character map in ROM; but as Rybags noted that's only useful for static data. (Hmmm... for SpaceWar! 7800, I had planned on including a tile based star field in ROM, I can't remember whether I ever tested it.) I wouldn't be surprised if the character maps could be in ROM since that's how you'd likely do a tiled background.

Transparency is always 160 res. MARIA only has two buffers of 160 x 5 bits of RAM to work with. (One buffer is updated by the display list while the other is being displayed.) The 320 modes are just a trick of the output stage.

Hi Bob, I haven't tested this, but according to the spec MARIA uses the 2 LSBs to determine whether each 5 bit pixel should be written to line RAM. But since the 320 modes split each 5 bit pixel into two display pixels, transparency is a little less intuitive - particularly with 320B. 320B WM=1,RM=1,RM0=0 3 colors from 2 palettes + background & transparent, 2 bits / pixel D7 D6 D3 D2 0 0 0 0 BG + BG / transparent 0 0 0 1 BG + C1 / transparent 0 1 0 0 BG + C2 0 1 0 1 BG + C3 0 0 1 0 C1 + BG / transparent 0 0 1 1 C1 + C1 / transparent 0 1 1 0 C1 + C2 0 1 1 1 C1 + C3 1 0 0 0 C2 + BG 1 0 0 1 C2 + C1 1 1 0 0 C2 + C2 1 1 0 1 C2 + C3 1 0 1 0 C3 + BG 1 0 1 1 C3 + C1 1 1 1 0 C3 + C2 1 1 1 1 C3 + C3 So with 320B you can only use C1 adjacent to C2 and C3 or it is transparent. However, it's also possible to use the background color as an additional color adjacent to C2 or C3. However, the bigger problem with 320 modes is color artifacts.

https://sites.google.com/site/atari7800wiki/graphics-programming/display-lists https://sites.google.com/site/atari7800wiki/graphics-programming/vertical-motion http://www.atarimuseum.com/ahs_archives/archives/pdf/videogames/7800/gcc1702b_maria_specs.pdf The display list is a sequence of display list entries which are either 4 or 5 bytes long, depending upon the 2nd byte. The end of the list is indicated by an entry where the 2nd byte is zero. (i.e. the display list end entry is 2 bytes).

See my post #14 which shows each of the color codings. 320B gives 3 color + background|transparent per sprite from 2 palettes (P0 and P4) or 7 colors (including background) per line. The spec says there are at least 7 "fast" CPU cycles between the end of DMA on one line before the start of DMA on the next line. How many cycles the DLI gets before DMA starts depends on how many sprites/bytes were in the last display list, but if we assume there's enough cycles to do the IRQ and STA WSYNC before the end of the line, then you can easily change 1 color (i.e. background) before the line starts. And if you can restrict yourself to using 1 palette in that zone then there's plenty of time to change more colors.

Yeah, the Zelda "auto-jump" takes some getting used to, but once you stop trying to jump it removes the typical "platform challenge" annoyances (e.g. the sections in Half-Life where you have to make a series of accurate jumps or you end up falling to your doom).

Palettes are specified on a per sprite / tile list basis (and it doesn't "cost" anything). So with 160A you have 8 palettes of 3 colors to chose from. It is possible to change the colors in mid-screen, but there's limited CPU time to do so (min 7 fast CPU cycles per line). I suspect Froggie changes the background color from blue (water) to black (road) so it doesn't need to have a tiled background (which is very expensive in MARIA time).

http://www.hackersdelight.org/divcMore.pdf might have something of use

You can also do division as a "shift and subtract", which will reduce the number of loops to the number of shifts. However, the 6502 doesn't have the instruction set which will make this method efficient.

The following tables map the graphics data bits to color indicies for the various modes (except 320D, which is 1bpp like 320A but the palette bits change the colors of the left & right sub-pixels - very strange). Note: the tables are in pixel color order rather than bit order to make it easier to understand. 160A WM=0,RM1=0 3 colors from 8 palettes + transparent / background, 2 bits / pixel D7 D6 0 0 BG / transparent 0 1 C1 1 0 C2 1 1 C3 160B WM=1,RM1=0 12 colors from 2 palettes + transparent / background, 4 bits / pixel D7 D6 D3 D2 0 0 0 0 BG / transparent 0 1 0 0 c1 1 0 0 0 c2 1 1 0 0 c3 0 0 0 1 BG / transparent 0 1 0 1 c5 1 0 0 1 c6 1 1 0 1 c7 0 0 1 0 BG / transparent 0 1 1 0 c9 1 0 1 0 c10 1 1 1 0 c11 0 0 1 1 BG / transparent 0 1 1 1 c13 1 0 1 1 c14 1 1 1 1 c15 320A WM=0,RM1=1,RM0=1 1 color from 8 palettes + background & transparent, 1 bits / pixel D7 D6 0 0 BG + BG / transparent 0 1 BG + C2 1 0 C2 + BG 1 1 C2 + C2 320B WM=1,RM=1,RM0=0 3 colors from 2 palettes + background & transparent, 2 bits / pixel D7 D6 D3 D2 0 0 0 0 BG + BG / transparent 0 0 0 1 BG + C1 / transparent 0 1 0 0 BG + C2 0 1 0 1 BG + C3 0 0 1 0 C1 + BG / transparent 0 0 1 1 C1 + C1 / transparent 0 1 1 0 C1 + C2 0 1 1 1 C1 + C3 1 0 0 0 C2 + BG 1 0 0 1 C2 + C1 1 1 0 0 C2 + C2 1 1 0 1 C2 + C3 1 0 1 0 C3 + BG 1 0 1 1 C3 + C1 1 1 1 0 C3 + C2 1 1 1 1 C3 + C3 320C WM=1,RM1=1,RM0=1 4 colors from 2 palettes + background & transparent, 2 bits / pixel D7 D6 D3 D2 0 0 0 0 BG + BG / transparent 0 0 0 1 BG + BG / transparent 0 0 1 0 BG + BG / transparent 0 0 1 1 BG + BG / transparent 0 1 0 0 BG + c2 0 1 0 1 BG + c6 0 1 1 0 BG + c10 0 1 1 1 BG + c14 1 0 0 0 c2 + BG 1 0 0 1 c6 + BG 1 0 1 0 c10 + BG 1 0 1 1 c14 + BG 1 1 0 0 c2 + c2 1 1 0 1 c6 + c6 1 1 1 0 c10 + c10 1 1 1 1 c14 + c14 This also shows why Kangaroo Mode (transparency) has an odd impact on 320B. For all the other modes transparent pixels go to background when KM=1, but with 320B this isn't the case.