attempt at recreating the XEP80

[+hloberg]

I've read over most of the documentation on the XEP80 and concluded it 'might' be possible to recreate the device using simple things like a ESP32 or even a PC. Here is my idea to start with:

it looks like the device drivers for the XEP80 just output ASCII that could be read by a PC and displayed. I thought of hooking a PC RS232 to a modified cross over cable from the Atari Joystick port and read the data using a terminal program on a PC.  I'm using an old Toshiba laptop with a built in RS232, that I'm still waiting on a adapter for the drive to complete, that has XP.  if this works I plan on creating dedicated hardware. So, sound like it might work?

 

[tschak909]

Yes, it should be really easy to do.

-Thom

 

[zzip]

1 minute ago, hloberg said:

I've read over most of the documentation on the XEP80 and concluded it 'might' be possible to recreate the device using simple things like a ESP32 or even a PC. Here is my idea to start with:

it looks like the device drivers for the XEP80 just output ASCII that could be read by a PC and displayed. I thought of hooking a PC RS232 to a modified cross over cable from the Atari Joystick port and read the data using a terminal program on a PC.  I'm using an old Toshiba laptop with a built in RS232, that I'm still waiting on a adapter for the drive to complete, that has XP.  if this works I plan on creating dedicated hardware. So, sound like it might work?

 

Maybe a raspberry Pi would be good here instead of a PC, since those are smaller than the XEP80   The PIs GPIO ports would be good for this type of project too.

[tschak909]

The ESP32 is a very good fit for this (the 8266 would work great too), there are enough GPIO pins, you can flip them fast enough, and the device comes up ultra quickly (unexpanded 8266's come up in about 40-80ms, unexpanded ESP32s can come up in about 150-200ms).

 

-Thomn

[+hloberg]

I'm using a PC at 1st step since there are less unknowns with a PC. Next I do plan looking at a ESP32 or RaspPi so that it could be turned into a little module. Oh, I don't plan to emulate the print part or the graphics capability at 1st, just text. So I guess that makes it a XE_80. ? maybe with a little help I'll look into those other things later.

future, I was thinking with a little messing with the drivers color might be able to be added. just designate a character as a color change like on the C64. of course all theoretical at this point.

I'm starting this right after I get my SDrive going I'm building.

[zzip]

25 minutes ago, hloberg said:

I'm using a PC at 1st step since there are less unknowns with a PC. Next I do plan looking at a ESP32 or RaspPi so that it could be turned into a little module. Oh, I don't plan to emulate the print part or the graphics capability at 1st, just text. So I guess that makes it a XE_80. ? maybe with a little help I'll look into those other things later.

future, I was thinking with a little messing with the drivers color might be able to be added. just designate a character as a color change like on the C64. of course all theoretical at this point.

I'm starting this right after I get my SDrive going I'm building.

I did write a an ATASCII display program for PC with the complete character set at one point.   It could probably be adopted to 80 columns without much effort.  If I can find the source code, I'd donate it to the project if it helps.

[777ismyname]

@hlobergit was cool to hear about this during the meeting on Saturday. I haven't many skills that I could donate, but would be glad to donate some $ or materials that you may need.

[+hloberg]

13 hours ago, 777ismyname said:

@hlobergit was cool to hear about this during the meeting on Saturday. I haven't many skills that I could donate, but would be glad to donate some $ or materials that you may need.

I really appreciate the offer and kind words. this will take a while to create as I tend to be very methodical. Also, it probably won't cost much or that is my goal anyway. but what you can do is be a beta tester when it's ready. that would help a lot.

[+hloberg]

ugh, I finally got the adriuno & screen to make my S-drive max and the screen turned out to be the wrong kind. ordered a new one, be in a week. need s-drive to read the drivers software to the 600xl. more delay.

[777ismyname]

On 11/22/2020 at 7:23 PM, hloberg said:

ugh, I finally got the adriuno & screen to make my S-drive max and the screen turned out to be the wrong kind. ordered a new one, be in a week. need s-drive to read the drivers software to the 600xl. more delay.

...would be glad to help test things when the time comes. If you need something to move files about and would be interested, I could send you an SIO2PC. 

[+hloberg]

HD for the old Toshiba laptop with a serial port is being delivered today. Screen hat delivered next week to finish the S-Drive. when assembled I'll attach the PC serial to the Joyst of the Atari with a special cable I made and we'll see what we we'll see.

 

sorta related I just ordered Makeblock Arduino based robot kit for the kids at the non-profit I work with. A bunch want to learn programming. https://www.makeblock.com/mbot

 

[+hloberg]

got my old Dell XP laptop working that has a real serial port. I tested the port by attaching my TI-99/4a to the laptop using a program called CFHDX. the CFHDX program transfers files between the TI-99 and a PC (lot like an SIO2PC). (I'm going to have a complete walk through in my projects blog on the CFHDX later.)

What this does for the Atari XEP80 project? It makes sure the port works on the PC. this is a very old laptop.

On another note, I think, maybe, possibly the screen for my S-Drive is coming in the mail tomorrow. (I will build the S-Drive and also post the build project on my project blog.) I need the S-Drive as my drive for the project as I have no disk drive (and don't want one).

then creating and testing the Joyport2PC cable on the 600XL+. Should be able to test the cable by hooking to my laptop and running a port monitor.

of course, this is still theoretical.

[+hloberg]

built my S-Drive:

 

 

[+hloberg]

OK, started working on setting the laptop to communicate with the XEP80 software and discovered Windoz does not support 9bit. No way or anyway. Sigh. But that doesn't mean the PC comport won't. may use DOS on the PC and find a term emulator in DOS that supports 9bit.

[+hloberg]

found a way to trick it into thinking it's 9bits but it's rather complex and might require DOS and writing custom C code.  and I'm running out of time. gotta move on. will revisit this some time later.

[tschak909]

sigh. 9-bit? that makes absolutely no sense.

 

-Thom

[Mathy]

Hello Thom

 

19 hours ago, tschak909 said:

sigh. 9-bit? that makes absolutely no sense.

 

We're talking about the XEP80 here.  Nothing about the XEP80 makes sense.

 

Sincerely

 

Mathy

 

 

[tschak909]

1 hour ago, Mathy said:

Hello Thom

 

 

We're talking about the XEP80 here.  Nothing about the XEP80 makes sense.

 

Sincerely

 

Mathy

 

 

what part of it is 9 bits?

-Thom

[HiassofT]

On 12/5/2020 at 2:08 AM, tschak909 said:

what part of it is 9 bits?

The data - otherwise it wouldn't be fun to interface with standard serial chips and APIs ?

 

See eg the info from the (awesome) Altirra HW reference manual.

 

WARNING: please make sure you have a hard surface or wall nearby, you might feel a strong urge to bang your head against that after reading the details.

Spoiler

Communication protocol

Data is transferred to and from the XEP80 via a serial protocol at a baud rate of 15.625KHz. This is designed to
be close to the horizontal scan rate of 15.7KHz on the host computer. Communication from the host to the
XEP80 is by means of the joystick up line (bit 0 or 4 of PORTA/B) and communication from the XEP80 to the
host is via the joystick down line (bit 1 or 5 of PORTA/B).

 

The data format is one start bit, followed by nine data bits starting with the LSB, and ending with one stop bit.

Bytes sent with bit 8=0 are characters to print, while bytes sent with bit 8=1 are commands.

When sending data back to the host, the XEP80 actually uses two stop bits, giving the host one bit cell of time
between the bytes.

 

so long,

 

Hias

Edited December 6, 2020 by HiassofT

[tschak909]

Looks like the solution there is to use a soft-UART in the ESP32, and have it bang the bits manually.

-Thom

[phaeron]

It's still possible to use a UART if you can program it directly. The XEP80's UART doesn't support 9 data bits either -- it uses the parity support in 8-bit mode to send and receive the 9th bit.

 

[HiassofT]

16 hours ago, phaeron said:

It's still possible to use a UART if you can program it directly. The XEP80's UART doesn't support 9 data bits either -- it uses the parity support in 8-bit mode to send and receive the 9th bit.

Thanks a lot, this is very interesting info!

 

Using mark/space parity was also my first idea.

 

POSIX termios only supports even/odd parity, but eg linux has the CMSPAR extension to select mark/space parity as well and it's supported by quite a lot of drivers (8250, pl011, ftdi etc).

 

Sending arbitrary 9-bit data would be a huge PITA, sending with a fixed 9th bit (mark/space parity) is rather easy and receiving 9-bit data with parity-errors signalled in-band is doable with a bit of leg-work (setup with INPCK and PARMRK flags and post-process received data).

 

Not exactly sure how it's in OS/X or windows APIs, but eg using a Raspberry Pi looks feasible to me -  pl011 supports flexible baudrate configuration, and RPis come with HDMI and composite outputs which are helpful to get something displayed. Other ARM SBCs should work as well, OFC.

 

so long,

 

Hias

[phaeron]

12 hours ago, HiassofT said:

POSIX termios only supports even/odd parity, but eg linux has the CMSPAR extension to select mark/space parity as well and it's supported by quite a lot of drivers (8250, pl011, ftdi etc).

 

Sending arbitrary 9-bit data would be a huge PITA, sending with a fixed 9th bit (mark/space parity) is rather easy and receiving 9-bit data with parity-errors signalled in-band is doable with a bit of leg-work (setup with INPCK and PARMRK flags and post-process received data).

 

Not exactly sure how it's in OS/X or windows APIs, but eg using a Raspberry Pi looks feasible to me -  pl011 supports flexible baudrate configuration, and RPis come with HDMI and composite outputs which are helpful to get something displayed. Other ARM SBCs should work as well, OFC.

My understanding is that a 16C550 can support receiving 9-bit data in this matter as the RxFIFO also buffers errors bits, but transmitting is more difficult as the TxFIFO does not buffer parity mode. It would be necessary to flush the transmit FIFO on each mode switch, which is expensive but doable.

 

AFAIK Win32 does not support this mode of receive operation, as while it has support for in-band signaling, it can only replace the erroneous bytes instead of flagging them.

 

[HiassofT]

21 hours ago, phaeron said:

My understanding is that a 16C550 can support receiving 9-bit data in this matter as the RxFIFO also buffers errors bits, but transmitting is more difficult as the TxFIFO does not buffer parity mode. It would be necessary to flush the transmit FIFO on each mode switch, which is expensive but doable.

Yes, this should work fine.

 

9-bit mode seems to have been used in some older industrial applications and this trick was often used to get 9-bit mode working with UARTs.

 

The 16C950 even has support for a native 9-bit mode. When enabled the 9th bit is stored in the LSR parity bit when receiving, like on 16C550, and when transmitting the LSB of the scratch pad register holds bit 9 (this has to be written before the data register).

 

so long,

 

Hias

[+hloberg]

well I'm doing something a little simpler now, trying to see if I can hook up the joystick port to the serial port of a PC. But I'm getting conflicting info; one source, the Atari Hacker book, says you can hook the joystick port straight to serial port of the PC with just the Transmit & Receive lines of the serial port with a custom driver that redirects the R: device. (unfortunately it looks like the code has few errors, fairly simple ones too like labeling PORTB as PORTA so I'm doubting the usefulness).  BUT, I was also reading a post here on Atariage where a guy was saying you needed to invert the signal to get it to work??? (and unfortunately I can't find the post. It was an old post of a guy who was trying to do the same thing hooking the PC to the joystick port).

I was able to pull this off on my TI99 but it was hooking the TI99 NanoPEB serial port to the PC serial port then reading it with a terminal emulator. It enabled sending printouts to a file on the PC and custom 80+ column screens if I just sent the data to the RS232 device. Not exactly a XEP80 but a start.