Rasberry Pi as XEP80?

[+hloberg]

Got this thought experiment that might work? Maybe. What if you used a RasPi in the place of a XEP80?

First, hook the RasPI to the Atari from the joyst port to the USB. of course that would require some sort of parallel to USB interface which is beyond me. But say IF it could be done...

Second, the RasPi could be programmed to send the info through it's HDMI to a current LCD TV with glorious simulated 80 column text.

might be able to use the XEP80 drivers.

of course the first part with the interface is (insert magic here).

I'm not a hardware guy but the software sounds doable.

Any thoughts?

 

[Tickled_Pink]

You can pretty much use the Pi for anything. Certainly sounds feasible. The Pi is certainly fast enough. It could be used for pretty much any interfacing jobs..

 

I think an Arduino would probably do it. It's cheaper and smaller, although you'd have to buy or build the HDMI output circuit. Whatever's in the XEP80 is going to be slower than modern hardware, so an XEP80 emulator with Arduino or Pi should be a doddle.

[JoSch]

I wouldn't go the USB route. Just get a breakout board and a case that allows for the cable.

Even the first RPI should have enough power to handle the IO necessary for that.

[gozar]

I think it would be better to hang it on the SIO port, and then add the capability to use it as an external graphics/audio card instead of just an 80 column card. The hardware is relatively easy, plug the SIO into the UART on the Pi. The software is where the issue lies. Drivers need to be written for the 8-bit and then server software for the Pi (or other single-board computer). Feed the audio of the Pi into the SIO, and then you could "play" mp3s or have other sound effects in games.

 

Using the $9 CHIP would give you the option of wifi and bluetooth. :-)

[JoSch]

I think it would be better to hang it on the SIO port, and then add the capability to use it as an external graphics/audio card instead of just an 80 column card. The hardware is relatively easy, plug the SIO into the UART on the Pi. The software is where the issue lies. Drivers need to be written for the 8-bit and then server software for the Pi (or other single-board computer). Feed the audio of the Pi into the SIO, and then you could "play" mp3s or have other sound effects in games.

 

Using the $9 CHIP would give you the option of wifi and bluetooth. :-)

Yes, but that wouldn't be compatible with the XEP80 drivers.

[gozar]

Yes, but that wouldn't be compatible with the XEP80 drivers.

 

 

The XEP drivers only affect the E: device (maybe the S: device). What apps are written specifically for the XEP-80 (and not just 80 columns)?

[pirx]

i am totally in favour of making a pi companion - it could also replace sio2pc and stuff and be attached via both sio and joystick port for compatibility with xep80

[ricortes]

For a hobby project a neat hack. As far as something I would use, probably not. Some of the neat features like the Pi provides composite out mean you wouldn't need two monitors. Eventually you run into the esoteric conflicts like how much is Atari and how much is Pi. We have had the capability of using the PC in a similar manner for literally decades and it hasn't gathered much of a following. The only thing the Pi supplies over what we have had prior to its introduction is small size.

[+hloberg]

A RasPi is about $40 and add another $20 for interface parts for $60. the original XEP80 was $80, that be about $160 in today's dollars.

Purposing a RasPi for just a XEP80 would actually be economical. Don't forget it was also a printer port.

 

I had also thought about using the APE or SIO2PC module for the same thing. Redirect the E: to the SIO then display the output in a window on the PC. Down side, the APE software would have to be disabled when the 80 column software on the PC was n use. Since I use the same monitor for the PC and the 800XL should work.

Even simpler, the APE software has a virtual RS232. If I could loop it back to another V-RS232 I could use a terminal program for the output. But the E: would have to be diverted to the R: on the Atari. writing software, that I can handle.

[phaeron]

The original Atari XEP80 driver supports both S: and E:. However, S: is mostly for bitmap mode, which is not very useful because of how slow and crippled it is, and the weird squarish aspect ratio. The SpartaDOS X driver only hooks E:.

 

If you're going to emulate the XEP80, be aware that it uses a 9 data bit protocol, not 8. The XEP80 handles this with a standard UART by monitoring the parity error status on each byte during receive and changing parity mode on each byte during transmit. That may be tricky to do with a standard serial interface. That having been said, I wouldn't recommend emulating the XEP80 at all, for the following reasons.

 

Let's start with the hardware protocol. The joystick based protocol is a big pain in the butt on the Atari side because it eats tons of CPU time in order to bang out one bit per scanline. In the transmit direction, this burns 10 scanlines per byte. In the receive direction, this practically requires display DMA to be turned off to lock onto the bit timing. The joystick port also seems not to be very good for higher speed operation. I've been able to run the XEP80 driver at 31.5Kbaud transmit speed for about a 20% increase in throughput, but could not get 63Kbaud operation stable. That's significantly below speeds that are normally attained on the SIO bus, which also is much easier to drive with standard interrupt-driven operation. Ditch the weird 9-bit protocol for a standard 8 data bit protocol and use a standard SIO2PC connection, and it's easier on both ends.

 

Even if the hardware protocol weren't an issue, let's go to the software protocol. First issue, the XEP80 deviates a lot from standard E: behavior. The biggest issue is that instead of using a logical line bitmap like the Display Handler does, it stores EOLs in the framebuffer to mark lines. This leads to lots of bugs like "move right" actually changing the contents of the screen and returning spaces at the end of a line. This is frustrating in BASIC because your source lines tend to accumulate lots of spaces at the end that you can't see and have to remove later on. Then we get to the more advanced features like bitmap graphics and hardware scrolling. These are a pain to use for one silly reason, which is that you can't get any control values into the XEP80 without actually printing them on screen. For instance, in order to move the cursor in graphics mode you need to write two address bytes before issuing the set cursor position command, but those two bytes will actually get written into the framebuffer. The workaround involves abusing the text mode positioning commands to temporarily move the cursor off screen before printing the control bytes. It's hard to do anything fast when it takes six bytes to plot a pixel.

 

[Rybags]

IMO... start from scratch. Make something that hangs off the PBI port.

Potentially it could become a poor man's IDE +2 and VBXE.

[Fox-1 / mnx]

I had also thought about using the APE or SIO2PC module for the same thing. Redirect the E: to the SIO then display the output in a window on the PC.

It's already there. In AspeQt that is, not sure about APE. Open the printer-output window on PC and redirect E: to P: on Atari.

[JoSch]

 

 

The XEP drivers only affect the E: device (maybe the S: device). What apps are written specifically for the XEP-80 (and not just 80 columns)?

E.g., there was a version of AtariWriter, that used the XEP80.

[+Stephen]

IIRC, there was also a version of BobTerm which used the XEP80, but I think it could work with both monitors at once.

[danwinslow]

I think SIO or PBI is the way to go here. SIO would be slow for graphics, but fast enough for text, and much easier to implement than PBI. You'd have you write your own hack for E: and S: intercepts, but that would probably be easier than a PBI interface. Implement your own little interface commands to the PI side to send each char with the appropriate command context. Then the PI side would interpret the chars and commands. In fact, what you'd need on the PI side would be basically a telnet program that reads from the serial port and interprets characters based on the Atari 'terminal' type. I bet there's a telnet core somewhere you could modify. So, hack the E: and S: drivers appropriately to intercept each char, send it to the SIO connection, and stand up a serial program/modified telnet on the PI side. You have to add code such that the PI side responds to basic SIO commands, but that's very easy.

 

With PBI, you could in fact implement your PI as a kind of external video card, which would be very cool but probably much harder to do. I have no idea what would be required electrically to hook the PBI up.

Edited March 14, 2016 by danwinslow

[JoSch]

IIRC, there was also a version of BobTerm which used the XEP80, but I think it could work with both monitors at once.

Which means, it didn't used the Atari XEP80 driver, because that would disable the normal display.

[gozar]

Maybe a PBI interface could just be a serial port hanging on the PBI connecting to the Pi. Sort of like the Apple II Pi, http://schmenk.is-a-geek.com/wordpress/?p=167

[+Stephen]

Which means, it didn't used the Atari XEP80 driver, because that would disable the normal display.

Oh - ok. I never had one back in the day. I only recently got one just to add to my collection. I tried it once, and promptly put it back in the box.

[+Larry]

For a hobby project a neat hack. As far as something I would use, probably not. Some of the neat features like the Pi provides composite out mean you wouldn't need two monitors. Eventually you run into the esoteric conflicts like how much is Atari and how much is Pi. We have had the capability of using the PC in a similar manner for literally decades and it hasn't gathered much of a following. The only thing the Pi supplies over what we have had prior to its introduction is small size.

 

Hi Rick-

Don't follow what you are saying about the PC? You mean we have had the capability to get 80-columns using the PC without an XEP80 (how)? Or maybe you mean using the XEP80 with a PC capture device? (That doesn't really work well in my experience, due to the infamous overscan of the XEP80.)

-Larry

[Fox-1 / mnx]

IIRC, there was also a version of BobTerm which used the XEP80, but I think it could work with both monitors at once.

Bobterm uses an external *.BTM (Bobterm module) to use the XEP as terminal screen. The menu just stays on the normal screen.

[phaeron]

The XEP80 can be used in dual display mode (ANTIC + XEP80) but doesn't work very well. The problem is that receive timing is marginal with the badlines from the ANTIC display. This is why the stock XEP80 driver breaks with BASIC XE, which turns ANTIC DMA on at startup. BobTerm works around this by switching the XEP80 to burst mode, but that makes it hard to emulate E: since no cursor updates are sent.

[+hloberg]

It just occurred to me that using the SIO port for video would potentially have timing issues during drive access.

[Fox-1 / mnx]

It just occurred to me that using the SIO port for video would potentially have timing issues during drive access.

That's not different for the XEP80. During serial disk operations, especially at high speed, there's not much time left to do other serious things.

[ricortes]

 

Hi Rick-

Don't follow what you are saying about the PC? You mean we have had the capability to get 80-columns using the PC without an XEP80 (how)? Or maybe you mean using the XEP80 with a PC capture device? (That doesn't really work well in my experience, due to the infamous overscan of the XEP80.)

-Larry

Just simple stuff like redirecting the console on the IBM to the serial port. Ditto for the Atari in that you can redirect the I/O to the R: Handler. I suppose you could just use a BBS on one or the other computers to have access to editing functions.

 

Back when I ran a BBS I took small advantage of that last technique but seldom in real time. I'd edit/asm on the IBM and transfer to the Atari rather then use a sneaker net with a disk converter like MyUtil. hehe, even used Pico with the Atari via my UNIX shell account. That would have been circa 1990 I guess. It just doesn't feel right to me. I'd guess I could have done the same thing with an advanced editor like VI, but never got that into the UNIX environment. Since the Pi runs Linux I'm sure you could just set the Atari up as a console and null into the Pi to Pico or VI.

[danwinslow]

Just simple stuff like redirecting the console on the IBM to the serial port. Ditto for the Atari in that you can redirect the I/O to the R: Handler. I suppose you could just use a BBS on one or the other computers to have access to editing functions.

 

Back when I ran a BBS I took small advantage of that last technique but seldom in real time. I'd edit/asm on the IBM and transfer to the Atari rather then use a sneaker net with a disk converter like MyUtil. hehe, even used Pico with the Atari via my UNIX shell account. That would have been circa 1990 I guess. It just doesn't feel right to me. I'd guess I could have done the same thing with an advanced editor like VI, but never got that into the UNIX environment. Since the Pi runs Linux I'm sure you could just set the Atari up as a console and null into the Pi to Pico or VI.

 

Yes, its really all about where the PI thinks it's getting key strokes from. I don't know about straight into VI or Pico, for two reasons:

1. There will need to be some kind of SIO response from the PI for it to participate as a SIO device. Of course, you could go straight serial through an R: driver, but then you'd need the linux serial TTY set up, which isn't hard to do.

2. Vi or Pico will be expecting a certain key mapping and set of commands. Somebody in between would need to map the atari keys and the atari program output ( such as print a character at position x,y ) to commands that would effect the same result on the screen.