PBI R:Fi - Project Design/Build Log

[TangentAudio]

just for reference, I checked in the debugger of Altirra, and the atari OS does in fact perform the checksum on the d800-DFFF region before it does any PBI register initialization, so the OS expects your device to be off at reset. That said, it goes into self test mode if the checksum doesn't work, not a black screen....

 

Noted, thanks for chasing that down. Sounds like that's probably ruled out.

 

I have an LED that turns on when the device select is active (D1FF=80), and it's off when I power up the Atari, which means it won't be on the bus. I have a U1MB in this machine, so I do see the U1MB screen come up and show the countdown bar, then it goes into the OS boot. It's only at this point that my device goes active, and appears to crash with the device active.

Edited April 13, 2017 by TangentAudio

[Joey Z]

Other behavior I've witnessed even before I had the ROM set up in the FPGA had shown that things go sideways when I assert my PBI device select on a system booted with the XL OS. In other words:

• Boot XL OS + SpartaDOS X. POKE $D1FF $80 from the command line, and my device is selected but the system hangs. Could this be because SpartaDOS is using some RAM in the same range as the PBI device? Or some other type of conflict that the system doesn't appreciate given that the XL OS has PBI hooks? I've tried it with and without the U1MB/SIDE2 PBI device enabled, for what it's worth.
• Boot OmniMon XL, which is a ROM monitor OS that I believe is based on OS B despite having "XL" in the name - and should not contain PBI support. I believe this is borne out by the U1MB/SIDE2 PBI handlers now showing up when I use OmniMon XL. I do a Select-Reboot to get into the monitor, and A D1FF 80 to enable my device. Similar behavior - my device is selected (I have an LED to tell me this), but the system hangs immediately.

So far the only "stable" method I've had for testing my FPGA is:

• Boot OS B + SpartaDOS X. In this configuration I can POKE $D1FF $80 to my heart's content, and then PEEK, POKE or MDUMP regions of memory which map to my device and everything seems happy and functional. This is how I confirmed my ROM image appears to be in place, and it's how I've tested everything so far. However I have a feeling there's more than just the lack of PBI in OS B that's making this a 'working' configuration.

Reading back through the thread a bit, I'm guessing your FPGA is contending with the C000 region somehow. The XL/XE OS uses C000 for lots of stuff, including but not limited to IRQ handlers (which'll fire 'immediately' from the perspective of a human). OS B doesn't use C000 at all (it's unmapped memory in the 400/800).

 

Try out some test code maybe: disable interrupts, enable your FPGA, wait around a bit (in a loop, maybe 256x256 double loop with x and y to keep it simple) and then disable your FPGA, turn interrupts back on and return. Does it freeze? you're probably contending with the OS somewhere, better have a look back through the VHDL and make sure something weird isn't going on. Also, have a look at your board wiring and the FPGA pin assignments and double check all the address lines are going where you think they are. confusing a medium-level address line with a higher one might result in this, who knows. For this, change the address of D1FF to something else, so the OS doesn't crash at least and you can boot. Confirm that enabling via the new address still crashes the machine.

Edited April 13, 2017 by Joey Z

[TangentAudio]

For this, change the address of D1FF to something else, so the OS doesn't crash at least and you can boot. Confirm that enabling via the new address still crashes the machine.

 

That's a good and easy test to try. Since I'm no expert on the Atari memory map, is there a known safe address you can suggest to move the enable register?

[Joey Z]

 

That's a good and easy test to try. Since I'm no expert on the Atari memory map, is there a known safe address you can suggest to move the enable register?

For the moment, if you have all other PBI devices (including U1MB/SIDE PBI) off, you can use any other D1xx address, say, D1FE.

[HiassofT]

As a general hint (especially if you are facing odd issues): make sure you've set the slew rate / drive strengths of your FPGA outputs and bidirectional I/Os, especially the databus, to the slowest/lowest settings.

 

Atari's "bus" is a complete mess: long traces running across the whole board, connecting to tons of chips. So expect high capacitive load, odd reflections and all other goodness you can think of when driving these lines with steep edges

 

Check for ground-bounce on your FPGA (I've been caught by that before) and coupled-in noise on other signal traces.

 

Some time ago, when I noticed that even the lowest drive strength on Altera FPGAs was too much for an Atari system loaded with several internal upgrades, I thought about adding a good old 74LS245 transceiver for the databus. That for sure wouldn't output steep edges But, as usual, I didn't find the time to actually try and check that.

 

so long,

 

Hias

[TangentAudio]

Some time ago, when I noticed that even the lowest drive strength on Altera FPGAs was too much for an Atari system loaded with several internal upgrades, I thought about adding a good old 74LS245 transceiver for the databus. That for sure wouldn't output steep edges But, as usual, I didn't find the time to actually try and check that.

 

All good advice, thanks. I actually have 74LVC245's on all I/Os between the Atari and my FPGA because this FPGA is not 5V tolerant, so they're really the drivers that the Atari is seeing. No control over the drivers other than changing logic families really - and I'm not sure what other families have suitable 5V tolerance with 3.3V/2.5V supplies. The FPGA is controlling the direction and /OE signals of the data bus transceiver, while the address and control line transceivers are fixed direction.

 

Draft schematic attached, see page 3. The LVC245's are wired as shown, the LVC125 for the IRQ ID is not built yet, so you can ignore that. Also the FPGA pin mapping isn't done yet on this schematic so there's not much to see on page 2 except all the pins. Also this schematic doesn't show the recently added external PLL which is generating the (32*PHI2) clock. That is certainly a source of noise, I know 57.28MHz is being sprayed everywhere since I added that. I have to improve the terrible hand wiring that I did to add that.

 

My gut tells me this is more of a pure logic error than it is a 'black magic' type of problem, since I can successfully read out the ROM and read/write other registers in certain cases.

atari_pbi_draft3.pdf

Edited April 13, 2017 by TangentAudio

[Joey Z]

Draft schematic attached, see page 3. The LVC245's are wired as shown, the LVC125 for the IRQ ID is not built yet, so you can ignore that. Also the FPGA pin mapping isn't done yet on this schematic so there's not much to see on page 2 except all the pins. Also this schematic doesn't show the recently added external PLL which is generating the (32*PHI2) clock. That is certainly a source of noise, I know 57.28MHz is being sprayed everywhere since I added that. I have to improve the terrible hand wiring that I did to add that.

I'd try and avoid using any clocks that high speed if I were you. I just got done troubleshooting a machine running rapidus because rapidus has a 160MHz clock running the SDRAM. I needed to put capacitors on some lines to get it stable. It was definitely RFI issues. Not many people are running their atari's with the shields these days.

[_The Doctor__]

+1 shielding helps many levels..

[TangentAudio]

I'd try and avoid using any clocks that high speed if I were you. I just got done troubleshooting a machine running rapidus because rapidus has a 160MHz clock running the SDRAM. I needed to put capacitors on some lines to get it stable. It was definitely RFI issues. Not many people are running their atari's with the shields these days.

 

Indeed, I'd like to eliminate that high speed clock. As long as I can get PHI2 up above 5MHz with the external PLL I could use the PLL in the FPGA to generate the faster clock for internal use only. I was just not thrilled initially about the idea of cascading PLLs, and was worried about them both being reliably locked before the Atari came out of reset. Seeing how fast the external one locks, I think it'll be OK but I still need to test.

[Joey Z]

 

Indeed, I'd like to eliminate that high speed clock. As long as I can get PHI2 up above 5MHz with the external PLL I could use the PLL in the FPGA to generate the faster clock for internal use only. I was just not thrilled initially about the idea of cascading PLLs, and was worried about them both being reliably locked before the Atari came out of reset. Seeing how fast the external one locks, I think it'll be OK but I still need to test.

It's probably fine as long as you keep the traces as short as possible though, reasonably speaking. Use a ground fill in the area as well, that might help.

[+mytek]

4-Layer with Power Planes in the middle layers would really keep it quiet.

 

- Michael

[TangentAudio]

Reading back through the thread a bit, I'm guessing your FPGA is contending with the C000 region somehow. The XL/XE OS uses C000 for lots of stuff, including but not limited to IRQ handlers (which'll fire 'immediately' from the perspective of a human). OS B doesn't use C000 at all (it's unmapped memory in the 400/800).

 

Try out some test code maybe: disable interrupts, enable your FPGA, wait around a bit (in a loop, maybe 256x256 double loop with x and y to keep it simple) and then disable your FPGA, turn interrupts back on and return. Does it freeze? you're probably contending with the OS somewhere, better have a look back through the VHDL and make sure something weird isn't going on. Also, have a look at your board wiring and the FPGA pin assignments and double check all the address lines are going where you think they are. confusing a medium-level address line with a higher one might result in this, who knows. For this, change the address of D1FF to something else, so the OS doesn't crash at least and you can boot. Confirm that enabling via the new address still crashes the machine.

 

You win the Internet today. Awesome diagnosis just from looking at someone's random pile of stuff.

 

I found a different technique to test out your theory. I booted with OS B + SpartaDOS, and left my device deselected. I dumped all of C000-CFFF and it was all FF's as expected. Then I enabled my device and checked C000-CFFF again and guess what? Just like you suspected, my ROM was showing up at C800-CFFF. It was also showing up at D800-DFFF where it belongs.

 

So I poked around with a scope on the upper address lines, and sure enough - A12 was stuck low at the FPGA, but it was fine just after my transceiver/level shifter. Flipped the board over and double checked that wire and there it was - a nick in the wire wrap wire actually broke it, but left the insulation intact.

 

Fixed that, and chased another random dumb problem for an hour which turned out to be a small chunk of something conductive that wedged in between two of the pins on a TSOP package, and it was messing up my RW signal. Also made a bunch of cleanups in the VHDL code, though it's by no means done.

 

And now it boots up with the XL OS, and appears to go through my PBI init code which sequences a few of the LEDs! It doesn't do anything else yet, but that's progress!

 

Thanks again!

 

[_The Doctor__]

hmmm large chunk memory swaps.... I think ClausB originally did 32 K swaps on his memory upgrades and then changed it to 16 . would be cool to choose either method at will....

[TangentAudio]

So I poked around with a scope on the upper address lines, and sure enough - A12 was stuck low at the FPGA, but it was fine just after my transceiver/level shifter. Flipped the board over and double checked that wire and there it was - a nick in the wire wrap wire actually broke it, but left the insulation intact.

 

Actually it's more accurate to say it was floating at the FPGA, since it was not connected to anything. It wouldn't quite make sense if it was stuck low, since the FPGA would have always been seeing D000 addresses as C000 addresses and it never would have worked at all. So from the FPGA's perspective, A12 was actually stuck high. I did measure the pin as low (with induced transitions from adjacent pins riding on it) but who knows what a floating pin would do when touched with a scope probe. I don't think there are internal pullups enabled on that pin...

[Joey Z]

 

Actually it's more accurate to say it was floating at the FPGA, since it was not connected to anything. It wouldn't quite make sense if it was stuck low, since the FPGA would have always been seeing D000 addresses as C000 addresses and it never would have worked at all. So from the FPGA's perspective, A12 was actually stuck high. I did measure the pin as low (with induced transitions from adjacent pins riding on it) but who knows what a floating pin would do when touched with a scope probe. I don't think there are internal pullups enabled on that pin...

Yes, on a modern CMOS input it's completely understandable that even a 1Mohm scope probe (or more) might be enough to pull it low, but otherwise left floating, it could sit high.

[TangentAudio]

Found a little bit of spare time to update the draft schematic to keep it in sync with what I have built on the prototype. Now has the pin mapping from the bus to the FPGA, series termination on the FPGA side (per a dire Altera app note AN-447), the external PLL, and a few other cleanups.

 

Also this is a reminder to myself to get the Cypress PLL design file and JEDEC output from the CyClocksRT configuration program into GitHub. (currently sitting on an old laptop with no network)

 

 

atari_pbi_draft4.pdf

[TangentAudio]

This morning I did a little bit of hacking around with the cc65 cross compiler and wrote a quick and dirty HATABS dumper. This will display the contents of HATABS in a nice table format, and highlight any PBI devices that use the GENDEV handler at $E48F. It's so fast & convenient to write code in a Linux virtual machine, compile it, and have it available for instant loading on the real Atari hardware via RespeQt (also running in the VM).

 

This also serves as a test of a new S-Video capture card (Hauppauge Impact VCB-e, about $45 from Amazon). This allows me to directly record from the Atari Y/C monitor output, and with the video mods I've done on this 800XL, it looks pretty good!

 

[TangentAudio]

HATABS dumper attached.

 

hatabs.xex

[TangentAudio]

It's my busiest time of year at my day job, so my time availability will be quite limited for the next week and a half or so. However, I did sneak down to the lab for a bit tonight and inched things forward.

Tonight was proving out if I could actually use the CIO handler with a really simple test to open the device and write bytes from a dumb little BASIC program. I was having no success until I decided to give it a shot without the U1MB PBI driver loaded and all of a sudden it worked. Not sure what is going on there, but I'm guessing I'm not doing something properly to play nice along with other PBI devices. I know the OPEN vector is supposed to do some checks to make sure it's the right device and I'm not doing that yet, but I would have assumed that would make my device screw up the U1MB PBI drivers and not vice-versa.

 

Anyway it's nothing sophisticated, but it's still some progress.

 

 

[_The Doctor__]

I would not assume it's just what you are doing... you are at the point where collaboration might be necessary as PBI devices have not always behaved properly and co-existed on the bus as they should in the past.... u1m is not just a pbi device as I see it, but rather a hybrid of sorts

[Joey Z]

I would not assume it's just what you are doing... you are at the point where collaboration might be necessary as PBI devices have not always behaved properly and co-existed on the bus as they should in the past.... u1m is not just a pbi device as I see it, but rather a hybrid of sorts

U1MB has no problems with IDE2+ (or whatever it's called) so there are other PBI devices that work with it. That is to say, it can be made to work.

[TangentAudio]

 

"Utilizing the CIO handler table HATABS the OS figures out the generic PBI-device driver is to be used to perform that action. GENDEV then activates all registered PBI devices one by one and jumps to the open routine through the open vector contained in the data structure. The open routine should then check if it supports the given handler name (Z:) by checking the content of address IOCBCHIDZ ($20). If it does not, it has to clear the carry flag and to jump back via RTS, so the generic handler can try the next device. If the open routine finds it is the “right“ routine, all actions to open the channel should be done here and a RTS has to be performed with carry bit set, so the generic habdler knows the open action has been performed correctly.

The CIO return-code has to be put back in the Y register and should be 1 if the action was performed correctly. All other functions usually implemented by a device handler (open, close, get, put, status, special) work in the same way; if the function is performed correctly, the carry bit has to be set and the CIO return code is contained in register Y.

Several PBI devices can share the GENDEV driver as long as each firmware checks whether it is the one the OS wants to call." -- Roland Scholz, MyAtari Magazine Feature #7, August 2001

 

I'm not doing these checks yet - my open function just does RTS with carry set, which should tell the OS that my handler accepted the open request - it would blindly accept the open request for ANY PBI device. My device is currently configured to use PBI address $80 and my U1MB is configured for $40.

 

I originally had reason to believe the OS checked PBI devices in most significant to least significant bit order based on something I read somewhere, but if that was the case my device open routine should have been called first. If this is in fact not the case, it's possible the U1MB 'Z:' PBI open function was called first and it accepted the open request and then 'swallowed' the bytes I was trying to write out to my device during my LED test. It doesn't seem likely, but this could mean that Jon Halliday's driver was not doing that device name check and it was accepting 'open' requests for any PBI device regardless of device name. I would tend to blame my own stuff first, though, because Jon is a diligent programmer and has a lot more hours logged writing Atari code than I do.

 

I did have an instance yesterday where SpartaDOS reported that my real time clock had been reset (at boot), but I can't recall exactly what test I was doing around that time. Could it be possible that one of my attempts to write to my device instead actually wrote to Z: and screwed up the time/date? It could be entirely unrelated, but I just remembered that it happened, and maybe it's a clue. I suppose it's also possible my device was 'answering' for Z: on a read attempt.

Edited April 18, 2017 by TangentAudio

[flashjazzcat]

Excellent catch - I completely forgot to check the device name by the looks of it. Thanks so much for getting into the kind of territory necessary to pick this issue up.

 

Will fix in the next update, but in the meantime I'll send you a fixed version ASAP.

[TangentAudio]

No rush, I won't have any time to poke at this until late next week at the soonest. Glad it turned out to be fairly obvious at least!

 

Thanks again,

Steve

[dkerfoot]

Thanks for this thread. I know nothing at all about the PBI and only a little about CPLDs so I only understand a very small portion of the details, but I am very much enjoying following along on the saga!