PBI R:Fi - Project Design/Build Log

[TangentAudio]

Slowly poking away making a schematic to keep track of the design so it's not just captured in my head and on the hand-wired prototype. This will make it a quicker process to do a real PCB later on.

 

So far this just represents the 5V/3.3V level conversion/buffering between the PBI and my FPGA. I also have sketched out what I think is a flexible 0xD1FF circuit so that there will (hopefully) not be contention between this device and other internal devices that use the PBI bits for their own functions. This should allow up to four different devices (e.g. a network, printer, disk, and serial - all contained within this one PBI device) each with their own IRQ ID bit. Most importantly, ONLY the bit(s) that this device needs will be driven. I ran across some info somewhere on the forums that said certain devices make a bad assumption about driving the entire 8-bit data bus on a 0xD1FF read, causing contention if multiple PBI devices are in the machine and trying to drive the bus for address 0xD1FF.

 

It's going to take a big cup of coffee before I have the motivation to make the 144-pin FPGA part in the library editor, but I'll get there soon enough...

atari_pbi_5v-3v_draft1.pdf

Edited March 31, 2017 by TangentAudio

[TangentAudio]

With the benefit of a spring snow storm in New England, I had some more time to work on this over the weekend. Not much to show yet, but needless to say I got a lot of tedious work done:

• aligned schematic pinouts with my hand-wired prototype
• did more wiring of the level conversion circuits on the hand-wired prototype - now the entire PBI bus is connected on the Atari side
• adapted a spreadsheet with FPGA pinouts, created mapping to PBI bus functions
• created the FPGA component in my schematic tool
• created schematic hierarchy
• began design work on the FPGA logic and have the first signs of life of bus transactions in the simulation
• created a public GitHub repository for the project https://github.com/tangentaudio/atari_pbi

Still a ton of work to do before I'm even able to test out some basic bus transactions on real hardware, but it's progress anyway. It's been slow going because I'm learning a new schematic tool (KiCad - it's free and open source), and also learning a new programmable logic tool (Altera/Intel Quartus Prime Lite - also free but not open source).

 

atari_pbi_draft2.pdf

10m08sa_pins_draft2.pdf

[TangentAudio]

Also threw this together to give a "big picture" view of all of the pieces.

[TangentAudio]

I've been working on my bus decoder logic, and trying to square my understanding of 6502 bus cycles with reality, and also wrap my head around the quirks of the Atari XL PBI in particular... I keep turning up a lot of voodoo relating to PHI2 timing in particular, and have seen more than one mention of using a 74HC123 one-shot to help correct for this. Indeed, I even see an HCT123 on my SIDE2 cart, so there's obviously something to this. It's amazing such a slow bus (by today's standards) can be so finicky.

 

I've explored using a PLL in the FPGA as an alternative approach to a one-shot but so far that's led me down a dead end. I think the idea was sound, and indeed the FPGA I'm using does have PLL capability via the ALTPLL IP core (see https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_altpll.pdf).... I was thinking I could feed it the 1.79MHz (NTSC) clock from PHI2 and derive a phase-correlated, but multiplied and/or phase-corrected clock off it so that I tweak the PLL to alter my bus timing as needed... Or drive a counter off of a multiplied version of the clock to adjust my cycle timing arbitrarily using taps off the counter.

 

Unfortunately I have discovered that the ALTPLL core has a lower limit of 5MHz on the input clock. Anything lower and there's no guarantee that the PLL can lock on to the signal across all conditions, so they disallow it. Sure, I could tell the tools I have a 5MHz clock and only feed it 1.79MHz but there's a fair chance it won't work at all, and a greater chance it won't work across temperature and other corner case conditions in the FPGA. It would be bad design.

 

Anyway I'm still brainstorming... I have a 50MHz clock that is completely asynchronous to the PHI2 clock, and I think with some clever techniques I can do some similar cycle timing adjustments with it.... but as part of the brainstorming process I'm trying to collect info that's out there relating to 6502 bus timing and specifically the issues on the 8-bit Atari bus because of any quirks they may have introduced with cost-savings, etc.

 

I'll try to collect and post interesting links relating to 6502 and PBI bus timings in particular as I find them.. Here are some... Please share if you've got anything up your sleeve.

 

- A recent thread Starman started, a few folks chimed in on with some general PBI info and articles (includes 4-part Antic article that I made into a single PDF): http://atariage.com/forums/topic/263844-800xl-parallel-port-docsinfo/

- This old post by Matthias Reichl in 2006: https://groups.google.com/forum/#!topic/comp.sys.atari.8bit/JwWqzcyqQ3Y

- MEtalGuy66 rant: http://atariage.com/forums/topic/153113-pbi-connection-standard/

- This old AA thread with a few tidbits of good info: http://atariage.com/forums/topic/184127-how-to-make-new-pbi-devices/

- Old Candle thread: http://atariage.com/forums/topic/150226-xe-specific-pbi-implementation-info-required/

- This is a bit off topic and more about 65816 timing, but it has some good visual presentation: http://laughtonelectronics.com/Arcana/Visualizing%2065xx%20Timing/Visualizing%2065xx%20CPU%20Timing.html

Edited April 5, 2017 by TangentAudio

[_The Doctor__]

deleted

Edited April 5, 2017 by _The Doctor__

[TangentAudio]

Doctor, I believe you were asking if I could use 3*(PHI2) .. That would meet the minimum requirement for the PLL (3 * 1.79MHz = 5.37MHz), but I don't have 3*(PHI2) available anywhere, and generating a tripled clock is not easy.

 

I could generate 4*(PHI2) externally, and then feed that into the PLL. There are some hacks to clock double using digital logic and comparator chips, but they are imperfect, especially with regards to duty cycle of the resulting doubled clock.. and if I'm going to add extra components I might as well just use the HCT123 technique that people have settled on as being a stable approach. I'm not a huge fan of using an R-C circuit on a one-shot to control bus timing, but it clearly seems to work in the field.

[_The Doctor__]

Possibly, 4 am brain fart... that's why I deleted it before finalizing a post.. not sure why I didn't post 4 at 4 but hey no sleep can do that...... I don't like 'some' r-c circuits but it depends on the capacitors... I don't like canned caps (wet electrolyte) anymore... longevity, temperature, etc effect them... I tend to stick with ceramic, mlcc, tantalum, and pae caps.. the latter are durable accurate and stable... keep that in mind as you are of their characteristics... not much else to say

 

_T D__

[TangentAudio]

I did a quick and dirty test of using the asynchronous 50MHz clock that I have available, along with a simple counter and comparator in FPGA logic, to generate an early signal ("DONE") for latching writes (Atari->FPGA direction). This is somewhat functionally equivalent to the method of using the HC123 to generate a shorter '1' state for the PHI2 clock. Jitter is the main downside with this method. It's unavoidable because it's an asynchronous clock that will 'beat' against the 1.79MHz PHI2 clock. Because the 50MHz clock is so much faster than the PHI2 clock, however, the amount of jitter may not be a problem at all for the system.

 

This is by no means a thorough jitter analysis (which would quickly get me out of my depth), but it's a nice visualization of a dozen or so cycles of the state machine overlaid to show the jitter window.

 

 

Also here's an animation showing it as well.

 

[TangentAudio]

Actually testing on real hardware now! Took maybe 15 minutes to sort out a couple of issues before the XL would boot with my board plugged in (like /IRQ, /RDY, /MPD, and /EXTSEL all being held low because they weren't wired up yet.. oops!)... but once I sorted that out, I was able to start looking at my PHI2 clock shortening scheme for real.

 

 

 

Here's one cycle of PHI2 filling the screen (yellow trace) - triggering on falling edge of PHI2. The cyan trace is my shortened PHI2, generated with an asynchronous 50MHz clock. As predicted, it's jittery.

 

 

 

Here's the part of the signal we really care about, the "early" falling edge with the cursors on the jitter window. Measures out to 20ns, or exactly the period of the 50MHz clock. Makes sense.

 

 

 

 

Now the question is whether this jitter will be acceptable for latching writes from the Atari to the FPGA registers/RAM. My gut says most likely, but I need to do some more analysis. I think I could potentially use the PLL to help here - I can feed the 50MHz clock into it and double it to get 100MHz internally. That should halve the jitter.

 

 

[+mytek]

Nice workbench! And I really like your scope. But your real problem is that it's too neat, you need some more junk piled up like the way my bench usually is.

 

But seriously, it looks like you are making fast work with this project, and it's been very interesting following it thus far. Great stuff!

 

- Michael

[BillC]

Not only that, but I don't know anyone who has the old fanfold paper anymore. Print Shop is fun for goofy cards, though

 

I only use Print Shop as an example because of how complex the app was for its time, and how inflexible it is when it comes to printing to a port.

Staples (US and Canada) still sells fan-fold computer paper.

[_The Doctor__]

Was going to say I just picked up a case and it's the fancy 'laser' cut type... although I don't see what difference it makes, I still manage to tear the crap anyway!

[TangentAudio]

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 ...

 

[TangentAudio]

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.

Edited April 9, 2017 by TangentAudio

[HiassofT]

I've been working on my bus decoder logic, and trying to square my understanding of 6502 bus cycles with reality, and also wrap my head around the quirks of the Atari XL PBI in particular... I keep turning up a lot of voodoo relating to PHI2 timing in particular, and have seen more than one mention of using a 74HC123 one-shot to help correct for this. Indeed, I even see an HCT123 on my SIDE2 cart, so there's obviously something to this. It's amazing such a slow bus (by today's standards) can be so finicky.

Problem with the Atari bus timing is that the address lines change state before the falling edge of PHI2. Datalines seem to be not affected. You can esasily check this by hooking PHI2 and an address line up to your scope and trigger on the falling edge of PHI2.

 

Here's a screenshot from my problematic 130XE (digital lines are A0-A15, CH1 is PHI2 and CH2 is A4 - BTW ignore the improper decoded bus address 0000 at the right edge, that's a bug in my scope):

 

The same zoomed in

 

This means any modern logic with setup times below 10ns will pick up the address line changes - and/or trigger a hold time violation.

 

In my tests so far I only observed this on Antic accesses, so I'm inclined to say ANTIC might be the culprit here.

 

There are several ways you can work around this. With an FPGA and plenty of registers you could just register the address lines on the rising edge of PHI2 and use these when driving external chips and in the internal FPGA logic (to do state transitions at the end of PHI2).

 

Sampling PHI2 at a higher freqency is also an option, but then you'll have to cope with some delay since you need to run the signal through a 2 or 3 stage synchronizer to avoid metastability issues. Jitter should not be a problem though.

 

Another option would be latching the address lines during PHI2=high, but that is generally frowned upon when dealing with FPGAs - better use synchronous logic, use latches only when they are guaranteed to be glitch-free (which they are often not).

 

so long,

 

Hias

[TangentAudio]

Problem with the Atari bus timing is that the address lines change state before the falling edge of PHI2. Datalines seem to be not affected. You can esasily check this by hooking PHI2 and an address line up to your scope and trigger on the falling edge of PHI2.

 

...

so long,

 

Hias

 

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!

[TangentAudio]

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.

[HiassofT]

PHI2 is active all the time, so nothing to worry about in that respect.

 

One important thing to check though will be PLL lock time - your internal clock has to be stable before reset is deasserted.

 

Several years ago I checked PHI2 against reset and had one Atari in my collection where the clock wasn't stable for quite some time after reset went high - IIRC the frequency was quite off and the duty cycle was more like 20% instead of 50%.

 

Not sure though how common this is, could have been a one-off out-of-spec crystal/clock circuit - on another Atari I had oscillatin on the reset lo-hi transition which caused all sorts of trouble. 40+year old gear can develop interesting behaviour :-) Anyways, these are issues that need to be fixed by repairing the Ataris and I guess the majority of Ataris should be fine.

 

so long,

 

Hias

Edited April 9, 2017 by HiassofT

[TangentAudio]

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.

[TangentAudio]

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.

Edited April 11, 2017 by TangentAudio

[+Stephen]

All way over my head, but reading along with this is great fun.

[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.

 

 

[TangentAudio]

Unexpected progress tonight! I now have Flash ROM reads working in the $D800-E031 range. Just stuck some test data in there for now, but it's where the ROM vector table and handler routines will eventually go.

 

It didn't turn out to be as complex as I expected - the pieces fell into place in a couple hours. Still a bit more to do to expand the capabilities a bit but progress is good.

 

 

[TangentAudio]

A short video showing some basic tests of enabling/disabling PBI device, reading ROM, and writing to a register to light up some LEDs.

 

 

[w1k]

awesome.. i love this tech videos:)