TangentAudio

After I figure out that stability issue with my shortened PHI2, the next step is to build the state machine and logic in the FPGA to talk to the Altera internal User Flash module (ALTUFM). This will hold the PBI handler code, and whatever else we dream up later on. I think there is 48KB of Flash in this version of the FPGA, so there's plenty of room. I think it should be possible to override system ROMs from this device, for example. The ALTUFM works a little differently than a traditional memory device. It needs to be fed with a clock (the 57.28MHz clock in this case), and it's going to require a small state machine to drive it, which will start running at the rising edge of PHI2. Basically you have to issue a read request for a particular address, and then four clocks later you can get the result of the read. The flash only performs 32-bit reads, so I'll need some extra logic to select the correct byte of the 32-bit word based on address lines A1 and A0 once the read is done.

I wonder if there was a version adapted for the XL OS, because I had an 800XL at the time and it worked fine.

Got the PLL chips in today and after a minor battle with the programmer, got it to successfully program a chip to produce a PHI2 * 32 (57.28MHz), and a reconstructed PHI2 (1.79MHz for me here in NTSC-land). Soldered it down to a prototyping board, wired it up, and it seems to be working as expected! Signal integrity and noise are, to put it mildly, pretty awful... but that is par for the course with a hand-wired board. I can make a couple of easy improvements that should help a bit, but it won't be that great slinging a 57MHz signal around until I make a proper PCB. Here are the resulting clocks, along with the "early" PHI2 scheme, same as before - but now with no jitter because the clocks are in sync. Yellow is the original PHI2 from the Atari PBI (through a level conversion transceiver). Cyan is the 57.28MHz (PHI2 * 32) that is my 'fast' clock for the FPGA. Purple is the "early PHI2" signal I'm generating with simple counter/compare logic in the FPGA. Dark blue is the reconstructed PHI2, which is actually what I'm using in the FPGA for PHI2 currently. Note that it does have a slight phase shift, but it doesn't seem to matter so far. I also checked out PLL clock stability as /RESET is released, and it looks great! I tested over dozens of bootups and the PLL clocks are always dead locked before it comes out of /RESET. Purple is /RESET, Yellow is PHI2, dark blue is PHI2-reconstructed, and cyan is 57.28MHz. I think that my overly simple scheme for generating the "early PHI2" appears to have a metastability issue, or there's something else going on that I need to chase down. It seems to be a bit worse with certain counter/comparator values that control the delay of the generated falling edge. On occasional boots, I see this (look for the 'ghost' edges on the purple signal). Anyway, this is good progress. I'm sure it looks like it's miles away from the overall goal of the project but slogging through this stuff is important.

One 2hr session on a yellowed Taiwan 800XL, using nothing but the "40 volume" peroxide paste. Still not 100% back to white, but much improved. I might give it one more session to see if it improves any.

That $180 one looks terrible. Missing two keycaps, too. I made a lowball offer on the one that's being sold "as-is" with a 1050 for $270. Came back with a $250 counter-offer. No thanks.

No wonder I can't find one on Ebay for anything even remotely reasonable. I'd be happy with just one good one in my collection!

It's a great intro to the art of disassembly. It's not a fully automatic process - you have to do a lot of work to help guide it (e.g. identifying text segments, etc.)

Peter Dell (JAC!) has a great series on using DIS6502, if you haven't seen it.

I believe the menu title was configurable, because I had other disks with different titles. Also whichever item you select shrinks to smaller text when you select the item.

Here's a cleaned up copy of that loader, if anyone is curious to do forensics work. I believe this is actually the very first disk I received as a 'gift' from a relative when I first got my 1050 drive. He had a friend who had a Happy modded 1050 and he used to make pocket money selling disk copies for $5 each. Beats mowing lawns, I guess? Somewhere I have a printed list of all of the games he had available - I need to try to find that. The 'clean up' entailed deleting a few files that were not on the disk originally - I must have used it in a pinch to save some stuff later on, when I was out of floppies. Destroy_Mastlamp_Rally_CESdemo - Fixed.atr

Does anyone recognize this one? This is the loader I was most familiar with around 1985. Most "disks of ill repute" that made their way to me (that weren't flat out Happy copies of protected bootable disks) had this loader. This was in the greater Boston Massachusetts area, if there is any regionality correlation. This loader uses DOS2.x compatible file structures.

I managed to hunt down a now-discontinued device programmer for the Cypress PLL chips on Ebay. These things originally sold for over $450 plus $150 per adapter for each device you want to program. Managed to scoop it up for pennies on the dollar. The PLL chips are still active parts, but strangely Cypress does not currently have a programmer they offer for them. But I had to contend with the fact that this programmer is old enough to still use a parallel port for interface to the PC. I was hoping I would live the rest of my life without ever having to babysit a Windows XP install ever again, but unfortunately this was not the case. I dug out an ancient 14 year old laptop that I had in storage and put a fresh XP install on it, fired up the Cypress software and it seems to talk to the programmer. My batch of PLL chips should be here today, so hopefully tonight I'll see how this theory of generating a multiplied PHI2 clock pans out.

A bit of a tangent... We had some nice sunny weather this weekend so I decided to try out retr0brite on that Taiwan 800XL that I originally picked up as a parts donor. This was a single treatment for about 2hrs, using the popular "40 volume creme developer" peroxide paste. I think it could maybe stand one more treatment, but it did get a lot of the yellowing/brown out. This will be for a spare 800XL so it doesn't need to be pristine, but it's good that it will look a little nicer.

One thing that has me concerned about using a PLL on PHI2 is that I thought I may have seen some cases where PHI2 was stopped when I was looking at the full bus with my logic analyzer yesterday. I didn't explore it because I was debugging something else, but it made me wonder... Is PHI2 constant or does it actually stop when ANTIC takes over the bus? If it stops and starts that might spell doom for my plan to drive a PLL off of PHI2.

You can buy XE motherboards from MyAtari on Ebay, but you may be able to find another entire computer for a similar price from somewhere else.

Great info, thank you Hias! This helps fill in some gaps in my understanding, and seeing your scope traces helps a lot. There is much talk of this problem over the years, but not much concise information on the nature of it. I am going to need a high speed clock internally for a couple different purposes (e.g. the on-chip Flash IP core), and it would be nice if that clock was synchronous with PHI2, so that's why I'm now exploring using a Cypress PLL chip (CY22150). My plan is to create a 32-48x PHI2 clock so I can build a state machine that has 32-48 time slices during a full PHI2 clock period. For things like the Flash IP, I'll need to start a flash fetch once I know what address the Atari is trying to read. Several (fast) clocks later, the data will become available from the flash as a 32-bit word. I'll then need to pick the correct byte out of that word based on ADDR[1:0], hold it, and output it on the data bus until the bus read cycle is done. Such a clock should also be very helpful in dealing with the PHI2/ADDR stability issue, I would think. This project is as much about building my VHDL / FPGA skills as it is about making a cool device for the Atari, so I'm sure my design can be improved and I still have much to learn, especially with regards to best design practices and thorny issues like metastability. I've done a handful of CPLD designs over the last 20 years, but they have been simpler and didn't have to deal with as much fussy bus timing. The biggest design I did was a 512 macrocell CPLD to interface a PCMCIA wireless card to an 8051 microcontroller. Come to think of it, that is a pretty similar project conceptually - WiFi on a device never meant to have it!

Making real progress today! After last night's push to get the entire bus wired up to the FPGA, this morning I was able to attack talking to some test registers in the FPGA from the Atari, and there are signs of intelligent life! I'm able to read and write expected values from registers. Most of these are just test patterns that I'm outputting in the FPGA code, but it shows the bus transactions are working. I also hooked up a register latch to the test LEDs on the FPGA dev board and I can control them via writes to a $D100 address. Had to haul out the USB logic analyzer, since the 16 channels on my MSO scope wouldn't cut it for looking at the entire bus (24 signals + a bunch of control lines and clocks), but I'm glad I did - it made short work of finding the last few issues gumming up the works. Thankfully I did not have to haul out the circa 1988 Tektronix beast of a logic analyzer, though maybe that would get me more style points for using period-correct equipment. I still have some things to learn with respect to what's going on with the Atari side and how the PBI code in the OS behaves. ,My FPGA is not yet at the point of being a true PBI device - there is no ROM yet for the handler or expected table for example. But my device looks for its bit to be set in the $D1FF register and only then will it put itself on the bus for the ranges $D100-D1FE (registers), $D600-D7FF (RAM), and $D800-D81C (ROM) . When I enable my device with a write to $D1FF, I get a system lockup when I'm testing on the XL OS. Interestingly I can get unobstructed testing when I use either the OS B or OmniMon XL system ROMs - but I'm pretty sure neither of those have PBI hooks, so that may make sense. I also did some experimenting with writing to the PBI device shadow registers ($0247 and $0248), expecting to see them reflected as writes out to $D1FF but didn't see that. Not having looked into the OS code yet, I'm guessing perhaps it won't do that if the OS didn't properly detect the PBI device at bootup? Maybe one of the PBI gurus can educate me. Anyway, I think I'll need to have my handler code (or at least the short lookup table) in place for this to play right with the XL OS, even for basic testing. I'm working on bringing in the Altera On-Chip Flash module into my VHDL code. There are some hoops to jump through because it's a 32-bit wide Flash device, so I've gotta deal with word-to-byte conversions/addressing and some other details ... but I think it will be possible to make it work.

This is all of the 3.3V-level-shifted version of the Atari bus now connected to the FPGA... I also set some other wheels in motion relating to more explorations of more ways of dealing with the PHI2 clock. I found an external PLL chip from Cypress that can run down to 1MHz, and can produce any multiple of the PHI2 clock that I want. I had to hunt down and buy a discontinued device programmer on ebay, and I'll have to sort out if I can even get that running... But it was an avenue I wanted to explore for my own education anyway, so ...

I'll confess, I hate that stuff and always take it off! But I think I'll leave it on this.

Received the new XL from Ebay today. Near mint condition, no yellowing, and still has the protective clear plastic on the cartridge doors and the function keys. It's indeed a Chelco - all the same style plastics (with Chelco stamps), ground wires going from the cart doors and keyboard to the main board, etc. Revision A1 board, compared to A2 on mine - so the A1/A2 switchover was some time in the ~5-6 weeks between these two units being made. It was sold "as-is/for parts/not working" (which is kind of ridiculous given I paid $90 for it), and indeed it was not functional when it showed up. I couldn't leave well enough alone and I spent a couple hours tearing into it. Pulled all the chips and hit the sockets with CAIG De-Oxit D5, that didn't fix it. Tested all the chips in another board and they were good. Replaced Q8/Q9 in the clock circuit, no dice. The soldering on this board was a mess - maybe an early unit out of Chelco before they got their act together. So I started touching up lots of dodgy looking solder joints, and then touched up a bunch of vias. Finally hit a via up next to the BASIC ROM and that brought it back. Must have been a broken connection either in the via or on one of the traces nearby. Anyhow, getting it running wasn't the point, but I guess now I have another socketed XL board to add to the fleet.

Best I can figure is that it's reference to a proverb or a fairy tale, maybe about deciding between two equally good things? Hard to get the exact meaning since this is also translated. We need one of our Polish friends to educate us, I think. Otherwise it's going to end up like that Star Trek episode... https://en.wikipedia.org/wiki/Darmok

"Well, interesting, donkey in a manger was given" I think something may have been lost (or gained) in translation.

Very exciting! That's great progress for a first (OK, second) boot of a new board! My instinct with the symptoms you describe is something related to a chip select being slightly wrong.

I didn't state it well, but I was largely taking issue with gilsaluki missing the point of this whole exercise. The damage was already done to my machine, back when I was just a dumb teenager and didn't know any better. I was fortunate to hold on to the pieces, even if they sat on a shelf and gathered dust for much of that time. I was fortunate that it didn't take much work to revive the motherboard, even if the mechanical pieces were beyond repair. I was probably a bit harsh in not considering the Atari computers art. I'm an engineer, and I can certainly appreciate parts of engineering as art. But even if it is considered art, my point stands that it's not exactly priceless rare art - at least not yet. There were some 2 million of them sold over the years, and many of them still exist. When you can still pick them up for $30 used (even if people are trying to fetch 10 times that), it's a sign that they're still out there in numbers. I'm happy that I've got my XL functional again, and that it will soon be restored to near mint condition aesthetically. I'm also enjoying the fact that this was the exact machine that started my life at the intersection of computers and electronics, and that I'm paying respect to that by actually using it as the development machine for my PBI-WiFi interface project ( over here http://atariage.com/forums/topic/263880-pbi-rfi-project-designbuild-log/)... Video upgrades and U1MB fit right in with the theme. I'd love to hear more about those applications of the Atari in various industries. I ran across a thread about a system meant to pull down program guide data from satellite for TV Guide, but I haven't heard of too many other specific cases. I'm an embedded systems developer in the audio/video broadcast industry by day, so these kinds of applications are right up my alley.

And by the way - good news on this front. I found a near-mint 800XL that I believe is a Chelco. See my other thread about the restoration of this XL: http://atariage.com/forums/topic/263472-mini-saga-restoring-my-childhood-800xl/?p=3734295