Hacking An Atari Lynx

Update 13.0214:
My niece gave me a bunch of old PC boards, one being a ISA bus sound card. And - it had a 74LS245 on it, although not a DIP package. Well, that works for me - I wired it in to the design (instead of a 540) and only to /CE0. I will wire both /CE0 and /CE1 when I find a 74LS08. Well, I may be able to wiring in both using diodes, but I need to do some research.

 The 74LS245 hot glued to the interface board and

blue wires attached to the 'B' side of the chip.

  The 74LS245 fully wired into the design.

Success! This is T-Tris, running on the new setup.

So, with the 74LS245 incorporated, I don't have to do a bunch of weird 'bus switching' code in the PIC. It simplifies the code dramatically, which is needed. Next is to incorporate either the USB for reading game images from a thumb drive, or an SD Card slot. OR figure out how to increase the storage capacity of the PIC some other way (right now it's 32K bytes minus 256 bytes for code and 64 bytes for a header).

Games running so far:
1) Pong1K
2) Karri's PONG
3) Centipede
4) T-Tris

I still haven't managed to get the BLL loader working. BUT - I _can_ load either pure cart images, 'LYNX' header images (for emulators) and 'BS93' images (again, for emulators).

Update 13.0131:
New ROM Emulator schematics, V1.01 (5 pages). Now I need to find the parts - how am I going to find a 74LS540 and a 74LS08 around here? Time to scrounge at the local repair shops.

Update 13.0131:
I need to add a tri-state buffer to the data lines, that is enabled when either CE0/ or CE1/ go low. Right now the PIC drives the data lines continuously and this messes with the buttons - and who knows what else. There is a tristate (TRISD) for the data port (PORTD), but I can't switch it around fast enough to present the data to the Lynx. GRRRR. I have a timeout method for tri-stating the data port, but I'm unsure if I am messing up anything else in the system before it tri-states. GRRRRR. Oh well, what's a 20pin part amongst friends?

Update 13.0130:
Two things: a new Game Cartridge document and a schematic for a cartridge that will allow you to emulate whatever ROM you want, plus read ROM images from a USB thumb drive.

Note: The previous versions of the Game Cartridge document have been removed as they were flawed and presented incorrect information. There's enough bad information out there, I don't want to add to the confusion.



Also note: the ROM emulator hardware is not fully tested yet, not has all of the software been written. That will come in the future.

Here's the ROM emulator schematic V1.00 (5 pages):

And here's the new Game Cartridge document - V1.02 (10 pages):

 

 

Previous updates and the original post below the break.

Merry Christmas! Maligayang Pasko!!!

From the crew at Dysfunctional Technologies.
No, I'm not telling which one is me.

BREAK OUT (PIC12F1840)

Since PONG was such a snap (heh) - why not do BREAK OUT for the PIC12F1840? Same hardware as the PONG game (you will have to turn the paddle sideways for left to right, instead of up to down). A lot of the infrastructure for the PONG game remains - just change the position / orientation of the paddle, change the graphics, and change the game play. Yeah, that's _all_ that needs to be done. Sure.

I've just started this today - I have the title screen changed and the paddle orientation complete. Working on the game play now. Nothing worth releasing the software yet. If you want to see what is basically in the guts of this game, go take a look at the PONG post HERE and check out the source code links.

UPDATE 12.1226:
The title screen, field, paddle and ball are done. Scoring and life counting is done. Wall collision and paddle collision detects are implemented. Loss of a life if you miss the ball is implemented. Video timings are (mostly) at spec. All I need to do now is put in the bricks!

UPDATE 12.1226:
I'm going to take the opportunity to try a new timing scheme I have been thinking about. Instead of timing the video lines throughout the code, I am going to let a TIMER0 interrupt service routine generate the video signals (except for actual data). This should be interesting.

UPDATE 12.1226:
It's possible to use the timer0 interrupt to time the video signals -  for the most part I am getting a clean signal with no jitters - but some of the tweaking is AWFUL. I think what I actually have is a hybrid between using the ISR and the manual timing. More work to be done!

UPDATE 12.1227:
Using the timer0 interrupt has been fully implemented. Everything is working as before, but now all of the nasty 'Timing Fudge' (usually a bunch of NOPs) has been removed from the code. I can change the graphics now without having to go through and tweak each of the individual lines. This is _really_ nice. And the screen is rock solid.

Chinese Meteor Lights (8 Pin Micro, 18 LEDs)

UPDATE 12.1222:
 As an experiment, I wired up their 8-pin part to a ICSP header and connected it to a PICKIT2. Well, it's not a 12F629 - in fact, the PICKIT2 reads back an ID of '0', which I think means the device isn't responding back properly. Anyone out there know what Microchip device has an ID of '0', if any?

So it's not a Microchip PIC - probably. It could be some other micro, or a specialty part as I said before. BUT, the important thing is that a PIC12F629 _can_ work in the design. And that gives me 20 individual LEDs on an 8-pin PIC with no additional hardware. And that makes me _really_ happy. Just think of the upgraded 'Iron Man Chest Arc Reactor' I can build now!

-----
Okay, I revisited the Chinese Meteor Lights with 18 LEDs that has an 8 pin device controlling the LEDs. At first it was thought that the device was an 8-pin micro of some sort, maybe a PIC12F629. After removing their part and replacing it with a PIC12F629 and trying some programming - I deemed that the original part was not a standard 8-pin micro and probably some type of specialty part, a-la the UCS1212.

Well, a blog reader informed that yes, indeed, you should be able to do this design with an 8-pin PIC12F629. You just need to tristate the GPIO pins to the LEDs you do not want lit.

After years of working as a validation engineer on new silicon, I am not hesitant to go back and rerun tests if questions are posed. No ego here. Thank God for that. Sometimes you are right - sometimes you are wrong. And sometimes, when you are wrong, it means the situation is actually better.

So - it turns out that I did the tests I ran before _did_ tristate the unwanted GPIOs, but I was still seeing multiple LEDs being lit - albeit that only the target LED was fully bright, and the rest were semi-bright, looking quite like leakage of some sort.

It turns out that I did my testing with the PICKIT2 still connected to the design. The PICKIT2 allows you to program the PIC12F629 while assembled in the design. Nice. But the PICKIT2 connects to GPIO0, 1, & 3 and can mess things up - which I found out when I disconnected the PICKIT2 and the meteor light started behaving as expected / desired.

So - yes, it is some sort of 8-pin micro. Yes, you can replicate the design using a PIC12F629. So - have at it!

Here's a new schematic (V2.00):

Here's source code for the test program:

Meteor_Lights.ASM (V1.02): http://pastebin.com/3dVrGELs
Common.INC (V1.04): http://pastebin.com/rKDCCKZS

Videos and pictures after the break.

First Game Of Video Ping Pong (1969)

Documented! And now the video is on YouTube.

Sheesh. Some guys made careers of this stuff. I'm doing it in my retirement.