Interest in PBI serial device?

[Joey Z]

I've always been a little surprised by the lack of a plentiful, proper, serial interface for the 8 bit atari's. We have the 850 and the ICD P:R:, but those are practically a 'hack' to get serial I/O based on my understanding of them. They don't allow I/O to SIO attached peripherals when they're on. Then there's the RVerter which has similar problems to the 850 and P:R: with sharing the SIO bus. There's the MIO and the blackbox, but they aren't readily available and tend to be expensive because of their relative rarity. Also, they do a lot more than just RS232, and you pay for that, making them an expensive RS232 solution if that's all you really want.

 

Anyway, I've always thought about the possibility of a PBI device (or ECI, I suppose) that has a modern UART with a FIFO on it which is fully PBI compliant (firmware/handler ROM which automatically sets up the R: device). If I were going to build this device, which I'll probably do even if it's just for myself, is there anybody interested in buying it? I'm open to design suggestions as well if I end up selling it.

 

There could certainly be multiple versions for ECI and PBI, maybe even a version to plug into the PBI header on an incognito if there's interest. I'd do my best to find a suitable case to put it in, which would be optional if the buyer wanted a reduced cost version. There would be optional socketing as well (for further cost reduction) if I were going the route of thru-hole parts. There would likely be two full RS 232 ports since dual UARTs are pretty common devices and I don't think they sell too many single UARTs, but this could change.

[gozar]

Would it have a pass thru so I could still use my IDE+?

[Joey Z]

Yes, pass-thru would definitely be included since it's likely these wouldn't be the only device on the PBI/ECI bus. PBI ID would also be selectable so that conflicts with other devices could be avoided.

Edited January 15, 2015 by Joey Z

[Kyle22]

An add-on for the Incognito PBI would be awesome. How about this:

 

Plugs in the next card slot, has pass-through PBI connector, has 1 or 2 serial, and 1 parallel port on it. All devices should be selectable using a program that runs under SDX.

 

Cables would be ribbon going out under the 800's top cover.

 

Example:

 

C:\UTIL>iface S1+ P- (which would turn Serial port 1 ON, and the Parallel port OFF).

 

 

Just an idea... I would buy one if it existed

[Joey Z]

An add-on for the Incognito PBI would be awesome. How about this:

 

Plugs in the next card slot, has pass-through PBI connector, has 1 or 2 serial, and 1 parallel port on it. All devices should be selectable using a program that runs under SDX.

 

Cables would be ribbon going out under the 800's top cover.

 

Example:

 

C:\UTIL>iface S1+ P- (which would turn Serial port 1 ON, and the Parallel port OFF).

 

 

Just an idea... I would buy one if it existed

I suppose that's a possibility too. I hadn't thought about using the next empty slot as a mounting spot. And if demand warrants it, I see no reason I can't add a paralell port on as well (which could be optional to reduce the price)

[TXG/MNX]

I am interested, a serial chip with FIFO sounds great I assume this device should handle more then 19.200 then.

 

Printing is less interesting but the whole concept sounds great.

[+Larry]

The major purpose of this would be to run a dial-up modem faster?

 

-Larry

[Alfred]

Honestly a PBI serial device strikes me as a waste of time. Modems are virtually useless these days. A PBI ethernet interface would be far more useful in this day and age.

[danwinslow]

Honestly a PBI serial device strikes me as a waste of time. Modems are virtually useless these days. A PBI ethernet interface would be far more useful in this day and age.

 

I agree. I'm sure the dragoncart design or something like it could be adapted.

[Tillek]

... and so it begins....

[+bob1200xl]

There was a series of articles in ANTIC magazine about the PBI. The example they used was a fast serial interface. Everything you need is in there.

 

Bob

[danwinslow]

As a software developer, personally, what I would like is a general purpose breakout connector, such that I could attach the Digital IO pins from any other small device ( ie., SBC, Raspberry PI, etc. ) and be able to put stuff on and get stuff off of the PBI. That way we could all experiment and develop lots of different things. Want a high speed serial IO device? Great, hook up a Raspberry. Want ethernet? Fine, hook up a small SBC with wireless ethernet, etc.

 

I may be way off base hardware wise and what I'm saying isn't possible, but it would sure be cool if it were.

[Joey Z]

I am interested, a serial chip with FIFO sounds great I assume this device should handle more then 19.200 then.

 

Printing is less interesting but the whole concept sounds great.

Yes, no reason not to support speeds greater than 19200 with a FIFO. Printing would be an optional part to the whole design, easily removed in the end product by not populating a few footprints if you don't need/want it. (save a couple bucks too).

 

The major purpose of this would be to run a dial-up modem faster?

 

-Larry

I was thinking more along the lines of a lantronix box, a linux or windows (or OSX, since OSX is just another variant of *nix really) PC running a shell account or TCP to serial software, etc.

 

Honestly a PBI serial device strikes me as a waste of time. Modems are virtually useless these days. A PBI ethernet interface would be far more useful in this day and age.

I partially agree with this and I do see your point. However, an ethernet device for the PBI would be a significantly larger task to design it and write software for than this project would be. I'm new to the whole 'building and selling hardware' thing and I'd like to get my feet wet with something I see as doable first. The complex hardware comes later.

 

 

I agree. I'm sure the dragoncart design or something like it could be adapted.

I personally don't like the dragoncart design. I don't like the idea that applications have to be specifically developed for it. I'd rather have a device that emulated R: in addition to allowing direct hardware access if it were needed by a specific application. I also don't think R: emulation would be very usable with the ethernet chip that the dragon cart designers opted to use. I know why they chose to use that chip, there was already a C64 project using the same chip which meant software could be ported to the a8 platform to use the device. However, in more modern times, there are more capable ethernet chipsets to use which support TCP/IP on chip rather than needing it to be implemented in software on the host machine. With the dragon cart, the TCP/IP stack has to be implemented in software on the atari. This makes supporting older applications which use the R: device difficult due to memory constraints. Something like ice-T (as an example) assumes control of the atari's resources and uses the R: device. There's simply no place to put a TCP/IP stack after such an application is loaded.

 

There was a series of articles in ANTIC magazine about the PBI. The example they used was a fast serial interface. Everything you need is in there.

 

Bob

I'll have to take a look, but I should be fine as far as hardware design goes. I've been working with digital electronics since I was about 10, and I've read multiple college textbooks on microcomputer design.

 

As a software developer, personally, what I would like is a general purpose breakout connector, such that I could attach the Digital IO pins from any other small device ( ie., SBC, Raspberry PI, etc. ) and be able to put stuff on and get stuff off of the PBI. That way we could all experiment and develop lots of different things. Want a high speed serial IO device? Great, hook up a Raspberry. Want ethernet? Fine, hook up a small SBC with wireless ethernet, etc.

 

I may be way off base hardware wise and what I'm saying isn't possible, but it would sure be cool if it were.

The issue with this is deciding on a common interface that can be used with different SBC's. The best way to do it could be very dependent on which SBC you want to use.

[gozar]

http://www.atarimagazines.com/v3n9/Parallel_Bus.html

http://www.atarimagazines.com/v3n10/parallelbus.html

http://www.atarimagazines.com/v3n11/parallel_bus.html

http://www.atarimagazines.com/v3n12/toolbox.html

 

:-)

[danwinslow]

There's simply no place to put a TCP/IP stack after such an application is loaded.

 

The issue with this is deciding on a common interface that can be used with different SBC's. The best way to do it could be very dependent on which SBC you want to use.

 

Well, I am putting the stack in extended memory. Seems to work fine. See the telnet I wrote as an example. Restricting things to the R: interface is fine, as long as it's something that naturally lends itself to that protocol. Quite a few of the IP protocols don't really fit very well across a serial device. I tried the route that everybody seems to recommend, which is to have an SBC or other 'smart' device run the stack. Communicating with a device like that over SIO and trying to do polling really isn't feasible given the incredible (comparatively) overhead of a SIO poll. Though everyone seems to think that's the obvious way to go, exactly no-one has done so. At least the Dragoncart exists, and works well. It needs programming though to take advantage of. If your goal is to not require programming, then yes, R: is probably about the best you can do. Incidentally, the dragoncart stack does expose an I: device that I am hoping to make as easy to use as r: is, as in you can use basic OPEN commands and so forth. But enough about that, as that's not really what this thread is about.

 

I agree that there would be the need for a common interface. Although SBC's differ, the digital IO pins are usually standard, are they not? I was thinking that just exposing the basic control lines with a suitable 3v-5v conversion layer would be a start, although I am probably oversimplifying things. I just really like the idea of being able to rig up stuff and create custom protocols. If I had a really fast way to interrogate an SBC for ethernet packets, then I sure would use it.

[guus.assmann]

Hello,

 

Some time ago I've made a design of a cartridge with a 6551 Uart.

This device is still available and I do have a couple.

The cartridge has been build (once) and tested. It works, but there's no software.

You may use it.

It's a handy point to start I would say.

 

BR/

Guus Assmann

UART.zip

[gozar]

 

Well, I am putting the stack in extended memory. Seems to work fine. See the telnet I wrote as an example. Restricting things to the R: interface is fine, as long as it's something that naturally lends itself to that protocol. Quite a few of the IP protocols don't really fit very well across a serial device. I tried the route that everybody seems to recommend, which is to have an SBC or other 'smart' device run the stack. Communicating with a device like that over SIO and trying to do polling really isn't feasible given the incredible (comparatively) overhead of a SIO poll. Though everyone seems to think that's the obvious way to go, exactly no-one has done so. At least the Dragoncart exists, and works well. It needs programming though to take advantage of. If your goal is to not require programming, then yes, R: is probably about the best you can do. Incidentally, the dragoncart stack does expose an I: device that I am hoping to make as easy to use as r: is, as in you can use basic OPEN commands and so forth. But enough about that, as that's not really what this thread is about.

 

I agree that there would be the need for a common interface. Although SBC's differ, the digital IO pins are usually standard, are they not? I was thinking that just exposing the basic control lines with a suitable 3v-5v conversion layer would be a start, although I am probably oversimplifying things. I just really like the idea of being able to rig up stuff and create custom protocols. If I had a really fast way to interrogate an SBC for ethernet packets, then I sure would use it.

 

I found the AX11015, which looks like you can communicate with it over serial, and it will take care of all of the TCP/IP stuff for you. Once Joey_z finishes this PBI board just hang it off of one of the serial ports. Or buy a Lantronix box. :-)

Edited January 15, 2015 by gozar

[danwinslow]

 

I found the AX11015, which looks like you can communicate with it over serial, and it will take care of all of the TCP/IP stuff for you. Once Joey_z finishes this PBI board just hang it off of one of the serial ports. Or buy a Lantronix box. :-)

 

Yes, I've found any number of things like that, and tried a few. As I mentioned, the IP protocols I am interested in do not work well over serial. Lantronix is fine for faking out telnet connections, but anything over serial won't cut it for me. If I had a fast PBI direct connection to an SBC, it'd be different.

[Joey Z]

if I were going to do any type of ethernet board, it'd definitely be PBI. There'd be an R: handler for the sole purpose of maintaining telnet support for terminal emulators and similar programs. Otherwise, I'd use some sort of I: or N: handler to allow direct TCP/IP socket interface, as well as a few protocols on top of TCP/IP possibly (as well as direct hardware programming being a possibility for those who want to mess with it)

[Joey Z]

So I've looked a little at some wiznet chips. They look easier to interface than I originally thought. If I were to make a PBI ethernet interface, would that deter people from buying a serial interface? I imagine MOST people would no longer need the serial interface if there were ethernet available.

 

Anyway, if that's the case (and I believe it will be) I'm only bothering to build one.

 

EDIT: and if people still want it, I'd be happy to make a board which includes UART and parallel interface.

Edited January 16, 2015 by Joey Z

[kogden]

I'd be interested in a high-speed serial interface with PBI pass-through. Not just for net access but playing with weird serial hardware and embedded gadgets.

 

I'd be interested in a PBI ethernet interface too but I'm not so sure a full TCP/IP stack would be too useful on stock machines. Expanded machines maybe. I'd be game just to play around with writing a simple non-routable LAN protocol.

[ricortes]

I just have trouble getting excited about serial. I don't mean that it isn't worthy of doing, just that even if one was available I don't have a lot of applications that are dying for high speed buffered serial communications.

 

At least a couple of guys have done it. This is a good example

http://www.steckschwein.de/schematics/

 

You have to look at the main board schematic where he uses a 74LS00 to generate the separate R and W lines for the chip. I've seen it done by Fachact<sp?> where he uses a different scheme with a 74LS00. They also use an inverted interrupt so you need another chip to handle that.

 

I always get in a ground loop when it gets to that stage of working. I mean specifically as soon as you get to the generation of all things Intel signal wise, it just seems like a better bang to go with one of those 'we are the world' chips that have built in IDE, Printer, dual 16550 compatible serial, floppy disk drive, and something that does the dishes and darns your socks.

 

At one time I saw one of the TI chips like that at Fry's for $20 or $25 but I never pulled the trigger on it. I imagine they are even cheaper now. After my recent floppy mischief with CPM/DOS, I think I have an aversion to anything rotating or terminal.

[bbking67]

I've always been a little surprised by the lack of a plentiful, proper, serial interface for the 8 bit atari's. We have the 850 and the ICD P:R:, but those are practically a 'hack' to get serial I/O based on my understanding of them. They don't allow I/O to SIO attached peripherals when they're on. Then there's the RVerter which has similar problems to the 850 and P:R: with sharing the SIO bus. There's the MIO and the blackbox, but they aren't readily available and tend to be expensive because of their relative rarity. Also, they do a lot more than just RS232, and you pay for that, making them an expensive RS232 solution if that's all you really want.

 

Anyway, I've always thought about the possibility of a PBI device (or ECI, I suppose) that has a modern UART with a FIFO on it which is fully PBI compliant (firmware/handler ROM which automatically sets up the R: device). If I were going to build this device, which I'll probably do even if it's just for myself, is there anybody interested in buying it? I'm open to design suggestions as well if I end up selling it.

 

There could certainly be multiple versions for ECI and PBI, maybe even a version to plug into the PBI header on an incognito if there's interest. I'd do my best to find a suitable case to put it in, which would be optional if the buyer wanted a reduced cost version. There would be optional socketing as well (for further cost reduction) if I were going the route of thru-hole parts. There would likely be two full RS 232 ports since dual UARTs are pretty common devices and I don't think they sell too many single UARTs, but this could change.

 

The P:R: Connection is an SIO device... I guess you mean Multi I/O. I always thought the Multi I/O was a pretty competent Serial interface for the Atari. Maybe only bested by the BlackBox? I never owned a BlackBox, but it seemed at least on par with the MIO...

[Joey Z]

 

The P:R: Connection is an SIO device... I guess you mean Multi I/O. I always thought the Multi I/O was a pretty competent Serial interface for the Atari. Maybe only bested by the BlackBox? I never owned a BlackBox, but it seemed at least on par with the MIO...

yes, I mentioned both the P:R: and the MIO. problem with the MIO is finding one, SCSI, and price.

 

EDIT: not that there's anything wrong with SCSI as an interface, but drives are rarer for it I think. certainly not as plentiful as IDE drives and CF.

Edited January 18, 2015 by Joey Z

[bbking67]

yes, I mentioned both the P:R: and the MIO. problem with the MIO is finding one, SCSI, and price.

 

EDIT: not that there's anything wrong with SCSI as an interface, but drives are rarer for it I think. certainly not as plentiful as IDE drives and CF.

 

Yes, SCSI drives that are compatible can be challenging to find in working condition (I have a few and several have bearing issues characterized by loud grinding noises). Some folks seem to be adapting SCSI to IDE, but the adapters are expensive.

 

The other problem with the Multi I/O is the reliability of the SIPP memory... it just doesn't hold up and it's also hard to come by.