Rasberry Pi as XEP80?

[+hloberg]

well, you guys have lost me already.

But from what I read the XEP80 was slow using the Joyst ports and even adding the RasPI wouldn't speed that up.

Also using the SIO wouldn't work since a disk request would freeze or blank the screen (which is probably why Atari didn't use the SIO with the XEP80 in the 1st place).

[danwinslow]

well, you guys have lost me already.

But from what I read the XEP80 was slow using the Joyst ports and even adding the RasPI wouldn't speed that up.

Also using the SIO wouldn't work since a disk request would freeze or blank the screen (which is probably why Atari didn't use the SIO with the XEP80 in the 1st place).

It wouldn't blank it, but it might freeze/slow it down, but it does that already, so you wouldn't notice in all probability.

[ricortes]

 

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.

As much as I recall<not much ) terminal screens pretty much had to exchange/refresh data for the entire screen each time when something BIG was done if there wasn't a good knowledge of the capability of the terminal/console. Some of the other programs like WordStar operated similarly in the CPM/DOS environments. That is, if you did something like <ctrl>Y to delete a line, the whole screen would clear and be redrawn with what the editor thought was current.

 

All the editor programs <IIRC> had built in help screens with useful information like ^Y = delete line.

 

In the Linux environment you can specify what terminal you have so it could go to the lowest common denominator like AD3, VT100, ???. You don't know know or care about what the Atari thinks because all of that matters is what the Linux box thinks and on a Pi, you would have that plugged into your composite monitor.

 

I think Kermit on the Atari was specifically designed to mostly work with UNIX, never spent more then a time or two using it.

 

I'm not saying it isn't nice. Shell account with access to all those neat utilities like telnet, Pico, Pine, C compiler, internet gateway, ogles of fast storage, giga hz of processing power. Problem for me is I start thinking 'Gee, I'd like to use that nice USB keyboard' and next thing you know, you are using the Pi natively.

[danwinslow]

Well, sure, but I think the OP was actually looking for something a little more than just a remote connection to a Linux box. With the XEP, you'd still be making the text available to programs...as a remote connection the text only lives on the PI. He wants to use it as a 'virtual screen', so it would have to be mapped to do what the atari expects in all cases, and there isn't a TTY terminal mapping that matches that. So you'd have to have something in between to interpret the atari behaviors. You'd also need something on the atari side buffering characters, which S: or E: will do, but you need ti intercept and suppress the regular atari screen output too, which a normal serial connection will not do.

 

So, I would write a PI side client that would act like a custom SIO device, kind of like the SIO2PC stuff does but a lot simpler. It would bring up a screen designed to look like an atari 80 col display (blue background FTW), and it would listen for keystrokes and screen write outputs coming along the SIO connection. Then, on the Atari side, I would steal the vectors from S: and E: and redirect them through my own handler to send the info to the PI device, and then pass the data back to the S: and E: device to process 'normally'. I'd have the screen display turned off on the atari most likely.

Edited March 15, 2016 by danwinslow

[ricortes]

Best eventually IMHO would be + genlocked Pi video. Since Michael is here, we could ask. I was at SLCC when he presented his Atari genlock. Same XEP 80 over serial line but with the ability to display on a single monitor w/o using a monitor switch or switching cables.

[pirx]

or when you have pi already, attach video digitiser to it and overlay xep video on captured 8-bit screen.

too bad delays would make it unplayable.

[phaeron]

well, you guys have lost me already.

But from what I read the XEP80 was slow using the Joyst ports and even adding the RasPI wouldn't speed that up.

Also using the SIO wouldn't work since a disk request would freeze or blank the screen (which is probably why Atari didn't use the SIO with the XEP80 in the 1st place).

 

As you may have gathered from the conversation up to this point, it's the joystick interface that's slow, not the XEP80 itself. The XEP80 itself is actually pretty fast as it contains an 8048 derivative running at 12MHz. Its text mode is implemented using a display list and it scrolls simply by swapping row addresses.

 

However, if you were really bent on making a new device that used the joystick ports, a nibble-wide clocked interface like the Corvus Interface would still be much faster and easier to use than the asynchronous bit-at-a-time XEP interface.

 

or when you have pi already, attach video digitiser to it and overlay xep video on captured 8-bit screen.

too bad delays would make it unplayable.

 

Note that the XEP80's video signal is way out of spec, to the point that some TVs can't even lock onto it. I had to hack the timing chain parameters to stop it from rolling on my LCD TV.

[+hloberg]

Maybe the XEP80 wasn't such a great device after all.

[+Stephen]

Maybe the XEP80 wasn't such a great device after all.

Steaming pile of shit comes to mind when I think of it.

[+hloberg]

Steaming pile of shit comes to mind when I think of it.

LOL. so much for that a great idea. Also sounds like trying to redo it wouldn't be much better.

[fujidude]

LOL. so much for that a great idea. Also sounds like trying to redo it wouldn't be much better.

 

Agreed. But as long as it comes to re-doing, I would have to say the way VBXE does it is far superior and they way it really ought to be done. I would like to see VBXE adopted as the defacto A8 80 column solution by (what's still left of) those still creating software for the A8.

 

When reading through the VBXE info, it seems it even supports colored text. How awesome would it be to see a terminal program that took advantage of that?

Edited March 18, 2016 by fujidude

[flashjazzcat]

When reading through the VBXE info, it seems it even supports colored text. How awesome would it be to see a terminal program that took advantage of that?

 

Something like this?

[fujidude]

 

Something like this?

 

Uhm yes, like that. Wow. I even had a posting in that thread. I totally forgot about that. Looks like it's been about a year since the last beta was published though? I was probably waiting for the 1st release and then forgot about it.

Edited March 18, 2016 by fujidude

[Fox-1 / mnx]

Steaming pile of shit comes to mind when I think of it.

Really?

 

The thing was far from perfect but was easy to connect (using the mostly unused 2nd joystick port), provided a centronics printer interface (only XE-style solution by Atari), it's not limited for Atari 8-bit usage only (however I'm not aware if someone ever tried to use it with other hardware) and it gave you a second monitor output, all at an affordable price. Also, without any hardware hack, you can connect 2 of those (up to 4 in case of 400/800) for another extra monitor output and printer port and with some slight patching of the drivers all features are usable.

 

The rolling screen problem that some may have wasn't much of an issue back then since monitors were analog.

 

To improve it's speed, one can put a PIA in a cartridge and connect the XEP80 to it. With the direct, unfiltered, connection to the port of the PIA I'm pretty sure it can go faster. Existing drivers can be used when patching a single address.

 

So... no, I don't think the thing is actually that bad as it is, but yes, it could be better, like when connected to cartridge bus in stead of a joystick port, but this would increase the costs of production.

[gozar]

Really?

 

The thing was far from perfect but was easy to connect (using the mostly unused 2nd joystick port), provided a centronics printer interface (only XE-style solution by Atari), it's not limited for Atari 8-bit usage only (however I'm not aware if someone ever tried to use it with other hardware) and it gave you a second monitor output, all at an affordable price. Also, without any hardware hack, you can connect 2 of those (up to 4 in case of 400/800) for another extra monitor output and printer port and with some slight patching of the drivers all features are usable.

 

The rolling screen problem that some may have wasn't much of an issue back then since monitors were analog.

 

This was the biggest issue with it. I finally found an old monochrome monitor that actually let me use my XEP-80.

 

But at the time it came out, they should have hung it on the PBI/ECI and left the 800 users in the cold. In all actuality, the non-release of the 1090XL expansion chassis probably hurt the viability of the 8-bits.

[ClausB]

 

The XEP80 itself is actually pretty fast as it contains an 8048 derivative running at 12MHz. Its text mode is implemented using a display list and it scrolls simply by swapping row addresses.

 

Well, the 8048's instruction cycle is 15(!) clocks long, so that's only about 0.6 MIPS.

 

Really? Its display chip supports display lists? ACE80 uses the same scrolling trick with ANTIC's display list.

Edited March 19, 2016 by ClausB

[flashjazzcat]

I think many display drivers use the same scrolling trick - certainly TLW's display diver, and RC_GR8.SYS AFAIK.

[Fox-1 / mnx]

 

This was the biggest issue with it. I finally found an old monochrome monitor that actually let me use my XEP-80.

 

But at the time it came out, they should have hung it on the PBI/ECI and left the 800 users in the cold. In all actuality, the non-release of the 1090XL expansion chassis probably hurt the viability of the 8-bits.

Maybe the rolling-issue was less of an issue in 50Hz "PAL" countries? Dunno...

 

The XEP doesn't need PBI. The cartridge slot will do fine so no need to exclude the 400/800 and many 65XE's. If they'd use a SDX/RT8 style cart you could even mix it with other cartridges on non 800's. As an extra bonus, a cartridge with a PIA can be re-used for a lot of other things too.

 

[fujidude]

I used an XEP80 on a monochrome, amber colored Magnavox monitor. It worked great, but I remember I had to fiddle with the adjustment of the monitor quite a bit to get it where it needed to be for my XEP80.

[ClausB]

So, how exactly does XEP80's hardware support display lists?

Edited March 20, 2016 by ClausB

[flashjazzcat]

So, how exactly does XEP80's hardware support display lists?

 

Looking at Phearon's hardware manual on page 110, he says the NS405 processor contains 64 bytes of internal memory, and of these locations, $20-$38 contain "the high byte of the starting address for each display row".

 

 

The row pointers are only reinitialized by power-on or a master reset ($C2) command; afterward they are swapped around as needed during scroll and insert/delete operations

 

Presumably the pointers tell the hardware from where to fetch the line data, and moving the addresses up or down one place effectively scrolls the screen by one line.

[ClausB]

Ah. Thanks, Jon.

[phaeron]

The display list isn't a direct hardware feature, but the NS405 is designed to run text mode in with an interrupt per line, where the firmware reloads the display address at the end of each line. The XEP80 firmware loads the high byte from the table in internal memory and the low byte from the horizontal scroll position. During scroll and insert/delete operations, the firmware swaps row pointers to shift lines. In addition, two of the framebuffer address bits are wired to control character set selection, so it is possible to mix ATASCII, international ATASCII, internal characters, and block graphics on different rows by using undocumented commands to change the row table.

[ClausB]

Thanks for the details. Sounds like a capable device, aside from the interface.

 

I did several 8048 projects, both professionally and personally, in the 80s and 90s so I have a soft spot for that old micro. It was the Arduino of its day.

[gozar]

Maybe the rolling-issue was less of an issue in 50Hz "PAL" countries? Dunno...

 

The XEP doesn't need PBI. The cartridge slot will do fine so no need to exclude the 400/800 and many 65XE's. If they'd use a SDX/RT8 style cart you could even mix it with other cartridges on non 800's. As an extra bonus, a cartridge with a PIA can be re-used for a lot of other things too.

 

Maybe Atari could have had a PBI adapter with a PIA to use with the XEP80? Then it would have been faster on the PBI/ECI machines but still useable in the others. (After they fixed the bin-standard video...)

 

 

Sent from my iPhone using Tapatalk