PBI R:Fi - Project Design/Build Log

[TangentAudio]

The PBI bus on my 800XL always held magical and mysterious powers... It seemed to be the key to unlocking unlimited potential of my Atari. In my earliest years with the XL (age 9-13 or so), I didn't really know much about what lay behind the port cover. As I got a little older, I learned about the products like the Multi I/O and the Black Box which could be plugged in, but these were always priced out of my reach.

 

As it would happen, I was destined to eventually follow a career path of software & electronics engineering, but my understanding of topics like parallel data buses would not come until I was a bit older yet, and had already moved on from the Atari to my first PC. Over the many years since then, I've gone on a few "nostalgia benders," digging up my old Atari gear and playing around with it for a while. Each time, I'd idly thought about maybe doing a PBI bus project, just to "check it off the list" so to speak. Well, this time I'm hoping to actually make it a reality, and I've started some work on a project that I think will blend the "old" (being the Atari) and the "new" (being some modern technologies I've been working with on other projects) in interesting ways.

 

I've debated whether I should labor away in the dark without sharing any info until I reach some arbitrary milestone, or share a progress log to get feedback, help and motivation from folks here. I've opted to try the latter.

 

So, I present the very first fledgling steps of my PBI bus to WiFi adapter for the 8-bit. I'm basing it on somewhat absurdly powerful but relatively inexpensive technology (an Espressif ESP-32 - a dual core processor standalone WiFi/Bluetooth module, and a small Altera MAX 10 FPGA). This is a massive pile of technology compared to the Atari, but I've been developing on the ESP32 for a few months on another project and am pretty familiar with it, and I've wanted an excuse to do a small FPGA project for a while now. I like the idea of combining these things.

 

My initial goal is to make a wifi coprocessor for the Atari, with the ESP32 doing most of the heavy lifting for dealing with TCP/IP connections. In the initial incarnation, I'd like to present it to the Atari as an R: compatible interface, so it can be used right out of the gate as a replacement for an 850 + Lantronix device, except hopefully much faster. This way it can be used with BBS and terminal software.

 

Longer term goals? Well, the sky's the limit really. The ESP32 has all kinds of interesting hardware support in it, and I've used much of it for another project. SD cards, audio, serial ports, I2C, Bluetooth, etc. There's a ton of potential to make it a PBI-based disk drive for example. Combined with the capabilities of the FPGA, it opens a lot of doors to doing interesting things. The daydreaming is great, but I'm trying to keep focused and meet a reasonable goal and then see where the project goes.

 

My rough architecture is that the ESP32 is going to communicate with state machines in the FPGA over a high speed SPI bus (it has no parallel buses). The FPGA will mediate between the slow Atari parallel bus and the high speed SPI bus. The FPGA I've chosen has a bunch of RAM and Flash ROM elements in it, so it can contain shift registers or dual ported RAM to aid this, and it can also contain the small amounts of PBI device handler code that need to be mapped in.

 

I'm breadboarding the first version because there are a few unknowns, and sometimes it's just easier to go old school and hand-wire stuff. I started this process last night, wiring up the address and data buses to the necessary level-shifting bus transceivers, because the Atari is a 5V system while the FPGA and the ESP32 are both 3.3V. I also have the FPGA eval board and the ESP32 development module positioned on the breadboard, but not yet connected.

 

Edited March 30, 2017 by TangentAudio

[Gunstar]

If you do this, what are the plans for a browser? Obviously TCP/IP is the most important first step, but that's on your board, there still needs to be some software for a browser on the Atari. Will you use Contiki or something totally new?

 

Contiki: https://news.slashdot.org/story/03/03/10/1211249/the-contiki-desktop-os-for-c64-nes-8-bit-atari

 

On the hardware side of things, there are a lot of PBI devices being developed these days, yours being unique, aside from the 1090XLR expansion project Dropcheck at BitsofthePast is working on. Maybe think about a version to go in a PCB slot in a 1090 expansion box?

 

Atari's original vision: http://www.atarimuseum.com/computers/8bits/xl/xlperipherals/1090xl.html

 

Dropcheck's 1090XLR site & forum: http://1090xlr.bitsofthepast.com

 

What ever you do, I'm all for it and wait expectantly.

Edited March 30, 2017 by Gunstar

[Starman]

That's pretty impressive! I just started looking at the mysterious PBI myself. My initial thought was "will this work with WPS2?", because I have hardware like the iBook with the Airport card in it that can't talk to WPA2 routers. If this could be a device that can be updated with newer components as time goes on, that would be amazing.

[TangentAudio]

A browser is not in my initial scope, but perhaps an Atari port of something like the old Lynx text browser is something to consider. https://en.wikipedia.org/wiki/Lynx_(web_browser)

 

I'm trying to aim low to start - just basic telnet-like capability via an R: interface so it works with terminals and BBS software. Then maybe getting into more advanced stuff like basic browsing, downloading, disk emulation, remote file/disk image access over the network, multiplayer games/chat, etc. I'm planning to make this a fully open project so hopefully if it gets some momentum I'll make some boards and maybe a couple people would like to make some software for it. Definitely putting the cart in front of the horse right now, though.

 

I did have some daydreams about a neat idea for doing a browser by offloading a lot of the heavy lifting work to the ESP32, and in conjunction with the FPGA having it present external display list and display memory to the ANTIC so that it can be directly rendered, without much 6502 intervention. I don't think I have quite the right signals out on the PBI to fully pull that off though, so I think it could only be done as an internal mod.

 

I've seen the 1090XLR project, and it's reasonable to consider adapting this to work in it, should both projects get any traction in the future. I'm much more worried about mine getting done than that one.

Edited March 30, 2017 by TangentAudio

[Starman]

My first thought - a way to connect to web sites that have games, and load them directly from there. Or, Dropbox. The point being - while SD cards are awesome, having a library-type system would be nice as well.

 

Once I get my SIO2PC I plan on archiving all my stuff. An iTunes-type home system would be a nice way to load things. I can understand why people go the SIO route, though - there's no PBI on the 800s.

[TangentAudio]

Yes, the ESP32 can do WPA2. My unrelated project on ESP32 is connecting to a WPA2 network and doing fully authenticated and encrypted communications with a web server over SSL/TLS, with certificate checks in both directions so the server can authenticate the node and the node can authenticate the server.

 

It's a really powerful little module for about $7, much better than the older and more widely known ESP8266. It's still not quite ready for Arduino hobbyist level prime time, but in the 3 months I've been developing on it, stability and documentation have both improved.

 

I initially considered just making a simple SIO peripheral for this project, but I decided it was a much more interesting challenge to do it on PBI.

[TangentAudio]

To give credit where it's due, the first idea I had for a PBI implementation was to use the same "bus racing" technique that electrotrains recently pioneered on the Atari8 with his UnoCart project. After a couple of evenings puzzling over that idea, I decided while it might be possible, it would be a royal pain in the neck with the particular way the ESP32 module maps its scant GPIO pins. My math showed it would probably work (it is a 600DMIPS equivalent processor after all), but it would mean having to dedicate one of the processor cores to doing nothing but keeping the bus fed. It also would not have been a beautiful, elegant single chip solution like his because I would have still needed the 5V/3.3V level converters and possibly some additional glue logic for partial address decodes. Also it would have chewed up every available I/O on the ESP32 module, meaning it would no longer be possible to use the other cool peripherals on the chip.

 

In the end I decided it would have been a cool hack, but it seemed like a better use of my time to shake the rust off of my VHDL skills and get familiar with a modern FPGA.

[+Stephen]

Awesome - I'll be following this with interest. Sorry for off topic - but what is that cart in your avatar?

 

OK - I googled. I was at least correct in thinking it was for 2600.

[w1k]

impresive

[TangentAudio]

Awesome - I'll be following this with interest. Sorry for off topic - but what is that cart in your avatar?

 

That's a RAM cart emulator that I designed for the VCS/2600 a million years ago (1999). It supported most of the typical bankswitching methods so many games worked, and it was loaded from a PC over a parallel port (it was the 90s and USB wasn't quite in vogue yet, nor were CF or SD cards). I wrote some Windows software to go with it that let you browse your ROM collection with cover art and descriptions, and it would kick off the downloader to push the ROM image to the cart when you wanted to play a game.

 

The one in the picture is the final version I did, but about a year before, one of my college buddies helped me build a hand-wired prototype that didn't support any bankswitching, which was the true genesis of the project.

 

I picked the name HappyCart for fond memories of the 1050 Happy drive chip that I always wanted, but never had as a kid. The "BSW2000" was a joke suffix for the improved version, since it did bankswitching, and anything with "2000" in the name made it futuristic.

 

 

Here's the original website, from the Wayback machine: https://web.archive.org/web/20040809222739/http://www.retrocomputing.org/index.html

 

And some newer but less detailed info on my stale personal site: http://www.tangentaudio.com/electronics/happycart/

Edited March 30, 2017 by TangentAudio

[Starman]

I just realized that Wifi printing would be good for this, too.

[Gandor]

Make something like the Flyer internet modem that is available for the C64

 

 

Sent from my iPhone using Tapatalk

[TangentAudio]

I just realized that Wifi printing would be good for this, too.

 

This crossed my mind too. I have a really old HP laser printer with a Jetdirect card, and I know you can just blast text to it on a TCP port and it will print it, using the internal fonts. I suspect modern printers will expect proprietary data from a customized print driver, but I guess it's worth a little research.

 

It's probably one of those things that won't be that hard to get to work for a very small subset of printers, so we'll have to determine how useful that really is.

[mellis]

 

This crossed my mind too. I have a really old HP laser printer with a Jetdirect card, and I know you can just blast text to it on a TCP port and it will print it, using the internal fonts. I suspect modern printers will expect proprietary data from a customized print driver, but I guess it's worth a little research.

 

It's probably one of those things that won't be that hard to get to work for a very small subset of printers, so we'll have to determine how useful that really is.

 

 

Thankfully, AirPrint (called ePrint by HP) standardizes wireless printing these days. Most modern printers support it, and it is the way by which mobile devices print.

[JoSch]

 

 

Thankfully, AirPrint (called ePrint by HP) standardizes wireless printing these days. Most modern printers support it, and it is the way by which mobile devices print.

Makes it only easier in that it sends only one printing format, but that's PDF, not the easiest format to handle, AFAIK.

Edited March 31, 2017 by JoSch

[mellis]

Makes it only easier in that it sends only one printing format, but that's PDF, not the easiest format to handle, AFAIK.

 

PDF is not too bad - it is a subset of PostScript, which is text-based page definition language. The Atari should be perfectly capable of generating useful output. It would be way more challenging if the Atari had to generate raster-based output for today's high resolution printers.

[TangentAudio]

There is a dual core 32-bit 240MHz processor in the ESP32 which can do some of the heavy lifting of generating a PDF wrapper for printing, that way it doesn't have to be done in a device handler on the Atari. Also means it can be written with reasonably sane development tools, and maybe even take advantage of an existing library. It's still a somewhat resource-constrained embedded environment, but still worlds more powerful than the Atari.

[JoSch]

 

PDF is not too bad - it is a subset of PostScript, which is text-based page definition language. The Atari should be perfectly capable of generating useful output. It would be way more challenging if the Atari had to generate raster-based output for today's high resolution printers.

Yeah, I know that and PostScript is even Turing complete. But I can't think of a program, that would generate PDF data on the Atari

I was thinking more on the line of using the ESP32 as a print converter, but it has not a lot memory and I don't know it, so I can't say anything about it's capabilities.

The raster operations like drawing a line should be anti-aliased, I would think. Bitmap would be a little bit harder

[Starman]

As I said in another thread, I used to write printer drivers for a living. While the guts of it is interesting, dealing with the ugly side like PPDs was living hell. I don't even think an Atari 8-bit could deal with things like that in a reasonable amount of time because of the parsing and logic involved on a 1.77 MHz system.

 

However, PDF can't be too hard. Saving to PDF would be a good way to handle things because printer drivers for every type of printer is just a big project and nobody would want to tackle it if they knew what was involved.

 

I thought about writing a PDF tool for the Atari, but I didn't know how practical it would be. You could use the Mac emulator now to print to a virtual Epson printer and then save that to PDF.

 

A few weeks ago I asked here if there was a way to save a printer dump somehow. Nobody responded. My idea is that the control codes you get from, say, an Epson driver can easily be converted. Write a standard wrapper around that and you have yourself a PDF creator for the Atari. The tricky part is getting it to work with apps like Print Shop since they have built-in "drivers", so how you re-route the data to PDF? Even if I create something like an F: port, apps need to know about it. I think Print Shop just blasts data out to P:. So while I don't envision a PDF creator for the A8 to be difficult, getting it to work with older software could be a serious challenge.

[TangentAudio]

My device should be able to insert a new P: handler, and grab any data that would have normally been sent to a standard SIO printer - assuming programs like The Print Shop were well-behaved and using the OS for printing and not directly pushing data out the SIO bus.

 

If the printer ports on the old MIO or Black Box devices worked in those programs, it should work with anything new. Unfortunately I never owned one back in the day so I have no idea if this was the case.

 

I'm not really sure of the value of using The Print Shop to print 8 foot long banners in PDF format, but who am I to stop anyone's fun?

[Starman]

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.

[TangentAudio]

I know there were also some software/devices which could do screen printing from the Atari, and worked in any graphics mode. Those are probably a bit outside the scope of a basic print driver, but maybe fun to explore if someone was really into it. I'm not that excited by printing, personally, but happy to try to make the facilities available if someone wants to explore it.

 

While we're daydreaming, that screen printing application actually made me think of another possibility: a remote desktop display, like VNC, RDP, TeamViewer, etc. Again, not sure it's 100% possible only being an external device on PBI, but it might be possible to capture what the ANTIC/GTIA are doing (display list & display memory), do some minimal compression on the data in the ESP32, and push it over a network to a remote client. The client could be constructed out of parts of an existing Atari 8-bit emulator - basically reconstruct the display data from the real Atari and feed it into a virtualized ANTIC/GTIA. Crazy idea that would take a lot of work and would have no practical purpose, but still kind of neat to think about.

[Brentarian]

http://www.retroprinter.com/epson-escp2-conversion-software-release/

 

This is part of a bigger project to capture printer data on a parallel port and convert Epson ESC/P2 to PDF and modern printers (on a Raspberry Pi), but they have code available for use under GPL. "As part of the project to create the best linux based ESC/P2 conversion software, we have decided to release the actual conversion routines which will be used by the Retro-Printer module under the GPL public license, as we feel that this conversion software could be useful in many different projects."

[Starman]

Interesting project. It's essentially what I was thinking of, but that project uses an outside source, I wanted to write an OS extension so that the A8 could create PDF natively. I'm still struggling with what to even do with the PDF if it's saved on the Atari - you still have to send it to a printer, and then you go down the rabbit hole of PPD files, etc. Maybe that's why nobody bothered with this before

[ricortes]

There is a dual core 32-bit 240MHz processor in the ESP32 which can do some of the heavy lifting of generating a PDF wrapper for printing, that way it doesn't have to be done in a device handler on the Atari. Also means it can be written with reasonably sane development tools, and maybe even take advantage of an existing library. It's still a somewhat resource-constrained embedded environment, but still worlds more powerful than the Atari.

Nice! I haven't bought the ESP32 yet but it has moved up my hit list with your announcement.

 

3x SPI capability => SD disk emulation, TFT touch screen, et al. Blue Tooth may let it hook into existing Atari stuff like Montezuma's server and be a viable alternative to replacing keyboards. I still haven't given up on stuff like the Arduino just because the micros available now are still ~50x as fast as our 6502's, but the 32 bit mircos are looking awfully inviting.

 

By all means go with what you envision. I would say though to make it as hardware independent as possible. For the low end ESP8266, it would be possible to make a dongle that would handle most of capability from internet to printing for a couple of bucks, maybe an internet file server.