XL/XE compatible Atari 800?

[+Stephen]

Maybe you can sell special joystick port caps for those of us who can't resist...

 

Or an LED board that shows the $D301 status via 8 LEDs. Or in HEX via 2 7 segment LEDs. That would kick ass.

 

Stephen Anderson

[+warerat]

Well, I'm finally at the stage where I'm actually laying out a PCB (and naturally the autorouter is having problems). Going to spin off a proto or two to make sure it works with the new CPLD, and then it's ready for production. These hobby projects sure do take a long time, but it's been fun and totally worth it (at least to me).

 

Looks like to make the whole assembly priced reasonably will probably require a run of at least 25 boards. I've got enough new 128K static rams and OTP ROMs to cover a run, but I'm going to need to find a reliable, affordable source for the DIP 512K SRAM. So to make this work in your 800 you're going to have to be competent enough to completely disassemble your 800 to the motherboard, solder 20 wires and a resistor to get the necessary signals on the wiring harness. But once you do it, you don't need to remove the cable harness to run your stock OS-B boards. I'll put it to you this way-- if you can handle a 320K XE mod, this is cake compared to that. It's conceivable that one could fabricate little PCBs for the ICs with connectors to make it solderless. You'd need five of 'em, one for ANTIC, GTIA, PIA, the 74LS42 decoder and the 74LS32 between the cart slots and the personality slot.

 

Don't want to commit to a price as it depends on the cost of the PCB, but I'm aiming for <$40-$50 US for a populated board. While I have no reason to think it wouldn't work on a PAL machine, I'd like to work with someone once I get a proto board with a PAL 800 to verify.

 

To summarize: Full 100% XE compatibility, four memory expansion modes (if populated with both static rams, otherwise it's just a 128K 130XE), full ANTIC enhance, built-in BASIC C, PBI-logic enabled. You lose ports 3/4 and any 800 hardware/software compatibility while harness is plugged into personality board. Can return to stock by plugging in old boards (with cases removed because they wont fit with a 20-conductor ribbon cable in the card cage). And no HELP key.

[+Stephen]

Awesome! Put me down for a 512KB board.

 

Stephen Anderson

[+remowilliams]

Sounds great! I'm down for one, possibly two.

[Shawn Jefferson]

That sounds great, I think I might have to bring the old 800 down from the top shelf once these boards get produced, especially if they aren't going to be too pricey.

[mimo]

put me down for one 512k board.

Maybe another if it can be adapted to a PAL 400.

 

Is the 32-in-1 os provision still included?

Edited March 12, 2008 by mimo

[BoatofCar]

Would anyone be interested in doing all the grunt work and selling the new boards already inside an 800? I have no electronics skill at all, but would still love to be able to have an 800 that could handle all A8 software.

[+bf2k+]

I'll get one too.

[dragos]

I'll definitely take one!!!!! w00t, finally!!!!

[ClausB]

Check out my recent post "64K Atari 800" to see how my 800 was XL-compatible (sort of).

 

EDITED - Sorry, had to remove the claim that this was before the Atari XL. My notes were not dated but I deduced that I did the upgrade in 1983, after I had seen a 600XL. My apologies.

Edited March 14, 2008 by ClausB

[+warerat]

Check out my recent post "64K Atari 800" to see how my 800 was XL-compatible (sort of) before there was an XL.

 

Hi Claus,

 

I'm humbled to know I followed in your footsteps and didn't even know it. Your approach using EXSEL- to switch in RAM is innovative. Also goes to show the hardware designers for the 800 had definite plans for expandibility on their mind. Just wish they would have added a few more signals to the personality slot module.

 

My upgrade evolved like this: http://www.atariage.com/forums/index.php?showtopic=84836. To get the XL compatibility I initially started with the OS board and left the three 16K RAM slots untouched. I removed the three mask ROMs and did some re-wiring in their place to get the standard 16K XL OS ROM (with a slight patch because the 800 doesn't have a hardware system reset and the XL OS doesn't test to see if system reset was pressed). Then I used half of a 32K SRAM for the missing 16K (14K) RAM under ROM. From there, I brought in bit 0 from the PIA on the unused pin on the slot to provide software switching. At that point I had a 98% software compatible 800XL with no switchable self-test or BASIC.

 

(I'm answering your question in your 64K Atari 800 post) Then I implemented the 16K bank-switch method. I had a few static RAMs still laying around, so I wired in 32K for the main RAM in slot 2, freeing up slot 3. I essentially brought all of PIA port B into slot 2 and added the logic to switch RAM off at $5000-$57FF for the selftest and $A000-$BFFF for BASIC. I had to run these two selects back to the OS board to allow the ROM to turn on when selected with bits 1 and 7 (by this point I added the built-in BASIC in the ROM on the OS board). Then it was just a matter of putting some logic in place with PIA bit 4 to select which 16K bank appeared from $4000-$7FFF and the rest (bits 2, 3, 5, 6) went directly to the high address bits on the 512K static RAM. I had a jumper to select connecting bit 1 to the 512K so I could switch between a 320K or 576K mode (but lose switchable BASIC in 576K mode). So essentially at that point I had successfully implemented the entire XL memory map and it was 100% compatible, but it required a modified OS board, a modified slot 2 board, and you still kept your slot 1 RAM for the first 16K.

 

I then evolved the design so that everything would just go on one card (less is more!) to not need all the extra boards and implement the last few remaining things missing from the upgrade-- PBI signals and ANTIC compatibility. I implemented the entire 130XE memory space in a single 128K SRAM and only use the 512K SRAM when anything above 128K is required. So I jammed all remaining the decoding logic and flip-flops into a large CPLD. The final design replaces all four original 800 cards with a single board that plugs into the personality module containing only four ICs and provides four distinct extended memory mappers.

[ClausB]

The final design replaces all four original 800 cards with a single board that plugs into the personality module containing only four ICs and provides four distinct extended memory mappers.

Wow, very nice. I'll be studying your work some more. Amazing how far RAM technology has come. Also, programmable logic really cleans up circuit design.

 

1st Q: How did you get the full address bus (or enough RAM select signals to reconstruct A13 & A14) to the personality slot?

Edited March 15, 2008 by ClausB

[re-atari]

Or an LED board that shows the $D301 status via 8 LEDs. Or in HEX via 2 7 segment LEDs. That would kick ass.

 

Stephen Anderson

I remember seeing an 800XL at a club meet back in 1987 that had precisely the mod that you decribe. It consisted of a 7-segment LED display that showed in HEX the bank that was being used at that particular moment. I spoke briefly with the developer, and he told me it was a homebrew mod. IIRC he said to have used a CD4538. I thought it cool to try and build one myself, but didn't get a chance to look at the internals. Never saw him or this particular XL again either.

 

re-atari

[retrobits]

I would purchase (or prepay) for one 512kB board. Thanks a ton for your work on this -- it truly is incredible.

[+warerat]

The final design replaces all four original 800 cards with a single board that plugs into the personality module containing only four ICs and provides four distinct extended memory mappers.

Wow, very nice. I'll be studying your work some more. Amazing how far RAM technology has come. Also, programmable logic really cleans up circuit design.

 

1st Q: How did you get the full address bus (or enough RAM select signals to reconstruct A13 & A14) to the personality slot?

 

I brought in the missing two address lines from elsewhere (actually off ANTIC). I went through this same exercise trying to utilize all the signals provided on the personality slot. Unfortunately, there isn't a practical way to derive A13/A14 from the select signals present. You'd be able to determine the proper states only under certain conditions, but not all of them that would actually make it work. Essentially the CPLD has A8-A15 tied to it to generate all the I/O and memory selects. The on-board 'LS42 decoder is only used to decode the cart slots and even then I have an additional enable going to it to insure its timing is correct w.r.t. the combinatorial delays in the CPLD RAM/ROM selection logic (as there are several layers).

[ClausB]

I brought in the missing two address lines from elsewhere (actually off ANTIC).

Did you use motherboard jumpers to unused slot pins, or flying wires from board to board?

 

Did you consider intercepting the Port B writes within the GAL instead of wiring to the joystick ports?

[doctorclu]

I would purchase (or prepay) for one 512kB board. Thanks a ton for your work on this -- it truly is incredible.

 

Usually good in the retro gaming scene not to prepay. As we learned with the Catbox on the Jaguar scene.

 

I know Warerat is a good guy to do business with from my own experience so best to wait till he's ready... that way no product rushed because money changed hands. I know I feel a burden when I receive money to get product out. It weighs on you. If the product is not ready, it would be even more so.

 

Trust me when I say to stay tuned, the wait will be worth it.

 

(Speaking as someone who has one of the proto XE mod boards for the 800).

[+warerat]

I brought in the missing two address lines from elsewhere (actually off ANTIC).

Did you use motherboard jumpers to unused slot pins, or flying wires from board to board?

 

Did you consider intercepting the Port B writes within the GAL instead of wiring to the joystick ports?

 

I have a 20-pin header that goes to a ribbon cable I snake through the holes in the back of the card cage and hit a few points on the CPU board. I could make a tiny jumper board that plugs into one of the memory slots for three of the signals, but I wanted to leave them free for possible plug-in PBI devices, as I provide a PBI header on the OS board to provide the XE ECI signals.

 

Ironically, in the next rev of the design I already intercept read/writes to $D301 to an internal tri-state 8-bit register that connects to the data bus (I have it coded, but I haven't committed to silicon). Only thing is, to implement it in the current design, I'd use the last two remaining I/Os on the CPLD to connect A0 and A1 for the PIA intercept. I was wanting to leave the two-pins as spares, but I could use them. From that point, I'm only four pins shy of a hybrid jumper-selectable 800 OS-B/XE board, but I'd have to outgrow my CPLD (again!) to get more pins-- and from there I might as well implement full Axlon modes. I'm using a 64-pin Xilinx XC9572XL, and out of those, 52 are usable for I/O. The advantage would be you'd only have to solder 12 points instead of 20. I'll think it over, as there's still room to squeeze that in.

Edited March 17, 2008 by warerat

[Gunstar]

I'm sure all would agree, the easier installation is, the better, BUT, I'd rather have a board that requires more soldering points if it means leaving the other slots open for other upgrades. I mean, if you have to take the 800 apart and solder 12 points anyway, another 8 solder points really doesn't make a big difference. Another 5 minutes of soldering at most.

Edited March 18, 2008 by Gunstar

[ClausB]

I'm using a 64-pin Xilinx XC9572XL, and out of those, 52 are usable for I/O. The advantage would be you'd only have to solder 12 points instead of 20.

Gunstar has a good point. Once you dive in, you're already wet, so keep swimming.

 

You must have access to some nice PLD development tools. My last professional PLD was a GAL22V10 with PALASM! Now I do some Xilinx FPGA programming in LabView, but that's a far cry from VHDL. What language are you using?

[+warerat]

I'm using a 64-pin Xilinx XC9572XL, and out of those, 52 are usable for I/O. The advantage would be you'd only have to solder 12 points instead of 20.

Gunstar has a good point. Once you dive in, you're already wet, so keep swimming.

 

You must have access to some nice PLD development tools. My last professional PLD was a GAL22V10 with PALASM! Now I do some Xilinx FPGA programming in LabView, but that's a far cry from VHDL. What language are you using?

 

Nothing fancy... I use regular-vanilla VHDL-- I program the device through JTAG plugged into my parallel port. I did the original "proof-of-concept" using a pair of GAL16V8's using Atmel's WinCUPL compiler. Not the greatest, but it worked. I'm not fond of ModelSim for simulation, so if there's any Mentor Graphics people on here, I won't apologize. I use Aldec's Active-HDL to run the sims instead-- that is a *nice* piece of software for VHDL simulation.

 

Now I remember why I did Port B direct: Not sure if the Xilinx BUFE primatives (for the internal tri-state buffer) are true hi-Z on my particular device family. The documentation on it implies when the buffer is disabled the outputs go high, which the databus wouldn't like. Going to have to verify that. Maybe it's hi-Z with a weak pull-up, but I'll have to try it in-circuit to be sure.

Edited March 18, 2008 by warerat

[ClausB]

My upgrade evolved like this: http://www.atariage.com/forums/index.php?showtopic=84836. To get the XL compatibility I initially started with the OS board and left the three 16K RAM slots untouched. I removed the three mask ROMs and did some re-wiring in their place to get the standard 16K XL OS ROM (with a slight patch because the 800 doesn't have a hardware system reset and the XL OS doesn't test to see if system reset was pressed). Then I used half of a 32K SRAM for the missing 16K (14K) RAM under ROM. From there, I brought in bit 0 from the PIA on the unused pin on the slot to provide software switching. At that point I had a 98% software compatible 800XL with no switchable self-test or BASIC.

I've looked at your older posts and I really like the idea of putting SRAM and EPROM into the mostly pin-compatible OS ROM sockets - rather elegant.

 

Once you eliminated DRAM, did you consider trying to recover the ANTIC refresh cycles and let the CPU use them for an 8% speedup? I guess it would be too hard to isolate ANTIC's address bus during refresh - probably not worth it for only 8%.

 

With fast SRAM, could you put in a faster CPU (65816?) that runs at maybe 4 or 8 times 1.79 MHz but slows down when accessing the Atari I/O? Forgive me if this has all been covered before - I'm trying to catch up on 2 decades of progress.

 

Oh, and what ever happened with the CompactFlash interface? That would be cool.

Edited March 20, 2008 by ClausB

[+warerat]

Once you eliminated DRAM, did you consider trying to recover the ANTIC refresh cycles and let the CPU use them for an 8% speedup? I guess it would be too hard to isolate ANTIC's address bus during refresh - probably not worth it for only 8%.

 

I was thinking doing exactly that for a simple DMA controller that could be used to move data in memory during the refresh cycle (and use the faster 3.58MHz clock). It is totally possible to disconnect ANTIC from the buses during the refresh without any dynamic memory. But here's the problem: ANTIC asserts HALT during the refresh cycle, so the CPU is froze anyway (see attached timing diagrams). HALT is asserted right before the middle of the previous bus cycle and is latched at the falling edge of PHI2 in the CPU. So an independent device could, in theory, use the refresh cycle to drive the address and databus for about 560-570ns with ANTIC floating.

 

Dilemma here is how to cleanly mask HALT from the 6502 during the refresh cycle. Then you could truly steal the time back from ANTIC and give it back to the CPU.

[ClausB]

Once you eliminated DRAM, did you consider trying to recover the ANTIC refresh cycles and let the CPU use them for an 8% speedup? I guess it would be too hard to isolate ANTIC's address bus during refresh - probably not worth it for only 8%.

 

I was thinking doing exactly that for a simple DMA controller that could be used to move data in memory during the refresh cycle (and use the faster 3.58MHz clock). It is totally possible to disconnect ANTIC from the buses during the refresh without any dynamic memory. But here's the problem: ANTIC asserts HALT during the refresh cycle, so the CPU is froze anyway (see attached timing diagrams). HALT is asserted right before the middle of the previous bus cycle and is latched at the falling edge of PHI2 in the CPU. So an independent device could, in theory, use the refresh cycle to drive the address and databus for about 560-570ns with ANTIC floating.

 

Dilemma here is how to cleanly mask HALT from the 6502 during the refresh cycle. Then you could truly steal the time back from ANTIC and give it back to the CPU.

I see.

 

An aside: Your logic traces show AN0-2, the ANTIC to CTIA mini bus. Have you decoded their meanings? I tried once, without a scope, by lifting one pin at a time and seeing how the display bit batterns changed, but it got too messy.

[dmlloyd]

Once you eliminated DRAM, did you consider trying to recover the ANTIC refresh cycles and let the CPU use them for an 8% speedup? I guess it would be too hard to isolate ANTIC's address bus during refresh - probably not worth it for only 8%.

 

I was thinking doing exactly that for a simple DMA controller that could be used to move data in memory during the refresh cycle (and use the faster 3.58MHz clock). It is totally possible to disconnect ANTIC from the buses during the refresh without any dynamic memory. But here's the problem: ANTIC asserts HALT during the refresh cycle, so the CPU is froze anyway (see attached timing diagrams). HALT is asserted right before the middle of the previous bus cycle and is latched at the falling edge of PHI2 in the CPU. So an independent device could, in theory, use the refresh cycle to drive the address and databus for about 560-570ns with ANTIC floating.

 

Dilemma here is how to cleanly mask HALT from the 6502 during the refresh cycle. Then you could truly steal the time back from ANTIC and give it back to the CPU.

 

Well even if you buffer all the bus signals and figure out some clever scheme to isolate those particular cycles, you'd still have the problem that accessing the ANTIC during the refresh cycle won't work, so you'd have to have additional logic to halt the CPU if it's trying to access an ANTIC register during the refresh cycle... an awful pain in the butt for a measly 8%.

 

Scope output is interesting though, I always thought /HALT was asserted while /REF was asserted.