PBI interface to raspberry pi or Arduino

[E474]

Hi,

 

   I was just wondering how easy it would be to design an interface that connected the PBI interface to either a raspberry pi (maybe via a HAT to the GPIO pins), or to an Arduino (somehow). I'm not a hardware hacker, I don't know if you could directly work with a 1.79 MHz bus from either of these systems, but would it be possible with some additional circuitry? From what I have read, the PBI exposes all the address and data lines, plus some additional signals, but I also remember that some addresses in $DXXX had special meaning, or acted as buffer memory. 

 

  I was wondering about this because both Rpi and Arduinos are readily available, but interfacing them to the PBI could also result in some interesting/fast devices. Not sure if this had been talked about before, or is practical, but am curious if other people think it is practical/have an approach on how to do it?

[Rybags]

You need 5V IO and sufficient IO lines, plus a decent amount of speed - you'd need to be able to capture a register write on any 6502 cycle and also have to respond to register reads and provide the correct information.

PBI doesn't particularly assist with address decode which can be annoying, e.g. you need to monitor a bunch of address lines over and above what you'd expect (though ECI provides a D1XX line).

Depending on what features you'd want to provide it might be easier to just use the cartridge port - it provides the D5XX signal though not audio in line the PBI.

[Xuel]

Back in 2012, I interfaced PBI to a Beaglebone to provide a 140MB memory expansion via bank-switching. See github and my blog.

 

The Beaglebone has a dedicated co-processor called the PRUSS which can be used to bit-bang the PBI bus. With an Rpi, you'd probably have to write a bare-metal OS which polls the GPIO pins in a tight loop if you want a full-speed interface. Arduino is already pretty much bare-metal so might be a little easier. Another limitation with both Rpi and Arduino is insufficient GPIO pins.

[Rybags]

Thinking some more - you could do external decoding to save on IO pins but like Xuel says, you're likely going to need that bare-metal OS so that you don't miss anything.

[ricortes]

To what end? A simple interface like is done for 8 bit data could be done similar to the SPI. The protocols are usually pretty simple like first write is command and subsequent bytes specify parameters followed by data. i.e. first write say $0 is write memory, next two bytes are start location, next two bytes are number of bytes, data. 

 

It would have some speed advantage, just that what would be the purpose? We already have fast I/O parallel devices, you are limited to what you can display on an Atari screen to ~8k bytes. It's possible to do something like a quick 80 column screen, just that a lot of people that need 80 columns just switch to a Intel platform cross compiler/assembler. 

[Sugarland]

Using a pi or Arduino as a hard drive(s) SpartaDos X (alternative to SIDE2) would be very nice...?  Expanded on top of that could be added RS232/parallel, etc etc..

 

[Faicuai]

The IDEAL, upgrade-of-upgrades, or the upgrade-to-end-all-upgrades is a PBI-compatible PC-on-board that will run Altirra (and the necessary Windows 10/DirectX supporting framework), with built-in digital video, audio, storage and networking (Bluetooth and WiFi).  Running PAL/NTSC software? Emulating VBXE? 80 Columns? True digital video with max. chrominance resolution? True digital sounds? Stereo pokeys? You name it, all in there, without sweating a single drop...

 

Ideally, this solution should be able to communicate (via PBI) with the local Atari HOST to use its keyboard, Joysticks/Paddles, cartridge ports and SIO inputs). But for all that, it seems to me that, without supporting BUS-MASTERING on that special expansion board, I am not sure how far it could really go... even for lesser / simpler upgrades, like a 100-200 Mhz. 6502-compatible CPU that will handle almost ANYTHING, will eventually require proper bus-mastering capabilities on PBI.

 

Not sure if this has been already done, but IIRC, the 1090 Expansion box already included provisions for bus-mastering...

[_The Doctor__]

whats the point of that? a win10 pc emu rig with a card that provides all the Atari ports on it and perhaps an Atari Keryboard? bah!

Edited September 10, 2019 by _The Doctor__

[Faicuai]

Just now, _The Doctor__ said:

whats the point of that? a win10 pc emu with a card that provides all the Atari ports on it and perhaps an Atari Keryboard? bah!

Runs on your Atari host... and then it can run Apple II, BBC, ZX, Commodore, PC and ANYTHING else you want... and with dual-screen output (the Atari host video-signal is still active, besides the PC-on-Card system...)

 

That is THE monster retro-computing upgrade, which will solve a ton of issues and simplify the lives of almost everybody else, including developers...

[ivop]

Check the UNO Cart. It uses an ARM CPU at ~180MHz (IIRC) and it's capable of "running the bus". You could just as easily connect it to the PBI bus. And at the same price you can now probably get a faster CPU.

Edited September 10, 2019 by ivop

[E474]

Hi,

 

   I was more wondering about something like a raspberry pi hat, so you could have a PCB with a PBI connector on it, and also it connects to the raspberry pi GPIO pins. I hadn't really thought about what you would need to do to monitor the PBI lines, I think the slowest RPi is running at 700 MHz, but it's also running an OS like Linux at the same time, so I have no idea how you would code something that really needed to be so real-time. 

 

   Having said all that, a PCB that allowed you to share a certain amount of memory (and maybe some signals mapped to hardware registers) would be quite interesting, and might simplify the programming a bit (I think this is what the BeagleBone expansion does). 

 

   Would it be possible to have a pcb that has something like 1K, 4K or 16K shared between a pi and an Atari, or maybe provide bank selectable ram that could also be accessed from a pi?

 

   I should point out I haven't used any of the PBI expansions, just SIO devices like sio2bsd or sdrive-Max, but what I think would be interesting is just having a simple way to interface to readily available hardware like the RPi or Arduino. Unfortunately, I'm not a hardware hacker, so can't figure out what is practical, or useful.

[Mathy]

Hello guys

 

Freetz, the guy from the ABBUC Software contest, has entered a SIO2Arduino interface into the ABBUC hardware contest.  It comes with a SIO cable on one end and the PCB on the other end plugs strait into an Arduino (not sure which one, but it's not the Nano).

 

Sincerely

 

Mathy

[+DrVenkman]

In general, this sort of thing is similar to the Pi1541 project - a bare-metal OS kernal running on an RPi3 or 3+ that provides cycle-accurate emulation of a 1541 or 1581 disk drive for a C64, allowing the machine to read and write to disk images (including copy-protected disks). The code for the project is up on Github - not directly usable, of course, but it might give a motivated and skilled coder the kind of insight necessary to program a bare-metal Atari PBI device if he or she wanted to.

 

https://github.com/pi1541/Pi1541

[E474]

Hi,

 

   Thanks for the pointer to the Uno Cart project, I had heard of it, but hadn't looked at it in any detail. The links are: https://atariage.com/forums/topic/257488-racing-the-atari-bus-with-a-stm32f4-microcontroller/#comments and https://github.com/robinhedwards/UnoCart

 

  It looks like you could use a similar setup for making a PBI/ECI connector, the STM32F has 140 I/O ports, so there should be enough capacity to monitor all 16 address lines, data, extra signals, etc. Presumably you could also Read/Write data to a Raspberry Pi/Arduino using GPIO pins, or perhaps some other method of interfacing/sharing data.

 

  I appreciate there are quite a few SIO based interfaces (which is great), but I was more interested in how practical a PBI/ECI setup would be, given that you would be loading data via the address bus, so it should be as fast as possible(?). Also, I think you could provide support for several different device handlers, e.g. D:, R:, B: and maybe even K: or others too, so you would have a lot more functionality than file storage.

[ricortes]

21 hours ago, Faicuai said:

The IDEAL, upgrade-of-upgrades, or the upgrade-to-end-all-upgrades is a PBI-compatible PC-on-board that will run Altirra (and the necessary Windows 10/DirectX supporting framework), with built-in digital video, audio, storage and networking (Bluetooth and WiFi).  Running PAL/NTSC software? Emulating VBXE? 80 Columns? True digital video with max. chrominance resolution? True digital sounds? Stereo pokeys? You name it, all in there, without sweating a single drop...

This.

Not that I agree with that particular set of goals, just that it narrows down what can be done with what is available. I don't think it could be approached by an Arduino and an RPi would have some latency problems due to its multi tasking environment.

 

Electrotrains did an excellent fpga in a cart. You start to run into acceptance problems with costs when you go this route of course. I *THINK* they were about $95 with all options. Don't get me wrong, adding a RPi to something like this would be good for Bluetooth, HDMI, WiFi, et al, just that the RPi with SD card and interface will add another $50-$100 to the $95 price tag. When stuff starts approaching $200, I usually opt out.

 

[Faicuai]

9 hours ago, ricortes said:

(...) When stuff starts approaching $200, I usually opt out.

 

And therein lies the problem, precisely:

 

Because we don't reach the $200 with the expansion that does ALL that is needed, we end up buying $60, $50, $80, $20, $40... $nn worth of fragmented, incohesive expansions that do not end up doing what we really wish, and end up costing more than the $200.

 

We just don't have the right vision, as buyers. That's all.

[E474]

Hi,

 

   I think for price and flexibility my best bet is ordering one of the STM32F4 discovery boards - I've seen various boards, such as https://www.aliexpress.com/item/33013274704.html - does anyone know if this board would be able to handle the 5v (TTL?) on the 8-bit bus?

 

    Also, I think it's possible for a PBI device to provide both ROM and RAM in the same address space, the SysCheck 2 card does this, so it should be possible (I guess), but I don't think the cartridge connector exposes all 16 bits of the address bus, so you couldn't do this with a cartridge plug in (unless there is a way to do this?).

 

   I was wondering how difficult it would be to offload floating point code to the ARM chip, presumably you replace the 8-bit FP package with code executed on the ARM processor, if you could modify the OS code, which I think you can with the softOS from @flashjazzcat.

 

   The other thing you could do would be a blitter, and maybe a sprite manager, so the ARM is updating 8-bit video memory (which would be in the cartridge address space), but Antic is displaying it on screen. You would just need an API accessible in 6502 assembler, or cc65, etc., and some way of handling those calls from the ARM chip. You would have all the standard Antic functionality (display lists, pmg, etc.), but the ARM chip would be handling softsprites and rendering graphics to the screen memory, so you should, in theory, be able to generate graphics that would be too complex for a standard 8-bit to produce, e.g. something like full screen WayOut, etc.

 

   I know the Ultimate Cart uses a FPGA, but for my purposes, the STM32 might provide more functionality.

   

[flashjazzcat]

48 minutes ago, E474 said:

I was wondering how difficult it would be to offload floating point code to the ARM chip, presumably you replace the 8-bit FP package with code executed on the ARM processor, if you could modify the OS code, which I think you can with the softOS from @flashjazzcat

Note that the soft-OS used on the UNO cart is a slightly augmented version of Altirra OS by @phaeron.

[+Stephen]

Not to poo-poo on any ideas, but one thing that always strikes me as funny about these threads.  We've had VBXE for over a decade now, and there's maybe 3 pieces of software that use it.  Many people feel it is "not atari" at that point.  We have Veronika and there's one piece of software for it (phaeron's BASIC).  It just seems odd to me that with so many unsupported mods out there, people keep trying to come up with more mods, but nobody seems willing to use what is out there.

[_The Doctor__]

From what I gather, in order to thread that needle... people expect the pokey antic, gtia, and personality of the Atari to shine through, also they furthermore expect the upgrade to be built on a super-set of of the OS and opcodes et al that they consider somewhat the DNA of their beloved machines...

 

some of the upgrades tick these boxes... but most folks interestingly get that feeling they are still using an Atari when putting their hands on an Amiga... even if they don't know who was behind that machine... the architecture is the ghost in the machine... it is really the DNA and that is why they can't put a finger on it but rather get the impression it's an upgraded Atari, that it's all so familiar.

 

with those 2 things bearing in mind, you still have the issue of price... 'power without the price per 'se ' ... at what point do I just buy an Amiga? *(though the Amiga fell prey to the bad capacitor era) if you buy one that hasn't been re-capped, don't turn it on until you do!

 

I think what might hit it big would be a kit, an all in wonder, that checks more of those boxes and bridges the gap... still lets you revert to plain old Atari 800 line goodness or passes that through... add workbench of sorts and/or gui flourishes but keep the ability to go full CP... that's quite a tall order...

 

*on another side note compatibility is a big deal... it has to be unified... this is why so many embrace upgrades such as the incognito... it adds so much and takes so little...

some of the upgrades have come so very close... it would take quite a push to get quantities of such wonderments out there...

 

Don't know why I felt compelled to write this response but I did it anyway...

Edited September 12, 2019 by _The Doctor__

[ivop]

2 hours ago, Stephen said:

Not to poo-poo on any ideas, but one thing that always strikes me as funny about these threads.  We've had VBXE for over a decade now, and there's maybe 3 pieces of software that use it.  Many people feel it is "not atari" at that point.  We have Veronika and there's one piece of software for it (phaeron's BASIC).  It just seems odd to me that with so many unsupported mods out there, people keep trying to come up with more mods, but nobody seems willing to use what is out there.

True, but I guess an 80 column PBI solution that costs ~$40-$60 dollars would have way more users than VBXE I think.

 

3 hours ago, E474 said:

I think for price and flexibility my best bet is ordering one of the STM32F4 discovery boards

I have one for a while now, but have not really played with it yet. I wasn't thinking about Yet Another Unused Expansion, but put it in place of Sally. I'm fairly sure it could run the MOS 6502 state machine plus the /HALT line. IMHO that would be awesome

[Xuel]

1 hour ago, E474 said:

   I think for price and flexibility my best bet is ordering one of the STM32F4 discovery boards - I've seen various boards, such as https://www.aliexpress.com/item/33013274704.html - does anyone know if this board would be able to handle the 5v (TTL?) on the 8-bit bus?

This datasheet says the microcontroller itself has 138 5V-tolerant GPIOs. They're probably brought directly out to the connectors on the discovery board, so I guess they should be OK. You'd want to operate them in open-drain mode since there's no 5V supply for the chip to drive onto the GPIO pins.

 

It also says the max toggle rate on GPIOs is 48Mhz which is well beyond what would be needed to talk to the 1.79Mhz PBI bus. But 48Mhz is probably only achievable if all of the IPC (instructions per clock) of the microcontroller are dedicated to writing to the memory-mapped GPIO registers. You'll have to factor in additional instructions to achieve any meaningful functionality. For comparison, the PRUSS on the Beaglebone has a constant, exactly 1 IPC at 200Mhz, with no pipelining, so it's very good for real-time applications like this.

[E474]

Hi,

 

   Perhaps I am going about this the wrong way. If I connect up the PBI pins used by the cartridge edge connector to the discovery board, I have a Uno Cart. 

 

  If I connect up the other pins, I can supply the OS ROMS, and also RAM under the OS from the discovery board.

 

   Does anyone have a source for cheap PBI connectors, ideally something like AliExpress, I just want to make a simple (ribbon?) cable or Dupont cable type setup that would connect the PBI interface to pins on the discovery board?

 

   I've had a quick look, and 50 pin edge connectors seem to be non-standard, but they can't be impossible to source.

 

   I'm sure there is a device along the lines of an Sdrive-Max, that can be connected to the PBI/ECI, and that can be upgraded via firmware to provide new functionality to the 8-bit. 

  

[flashjazzcat]

The problem with the MCU (bus racing) approach is asserting signals on the Atari side while the ARM CPU is doing something other than watching the bus. Simply maintaining an emulated IDE status register with bit 7 set while performing IO on the SD card proved impossible (for me) on the UNO cart, at least without resorting to a multitasking kernel or complex interrupts. Managing a PBI device may present even more difficulties. I'd be very interested to hear of any solutions, however.

[E474]

Hi,

 

   I think you might be better off using an interrupt, you only need a single (specific)  port to trigger an interrupt, as address and data are going to be supplied synchronously on the PBI (I guess). Unfortunately,  you have to synthesise the address and data values by combining 16 port values for the address, and 8 for the data, which I'm not sure you can do elegantly/quickly in ARM assembler. If you use an interrupt, you aren't tying up the ARM cpu with polling, so you can do other tasks. I'm sure that there must be some techniques used by emulators that would help out, but I don't know what they are. 

 

  Probably this is a bit more complicated in practice than in theory.