[June 11th, 2002: I removed some typing and translating errors and updated my email address as well as the way you can reach Erhard]

[Februari 25th, 2007: I added the part of the text that seems to have gone missing when I transferred my site to my own domainname.]

Howdy Folks

The following article was translated by me, Mathy van Nisselroy, with permission of the original author, Erhard Puetz. This article previously appeared in ABBUC magazin number 38.

Please keep in mind, that I translated this from German to English, while Dutch is my mother language.

Yes, I hated the XEP 80 too, but I read the following article (I was VEEERRRYYY bored) and it seems this baby is quite capable and can be really fast, even with BobTerm.

The XEP 80

Ever since the 1993 ABBUC Annual meeting (Jahreshauptversammlung) I've been working with the XEP 80 and gained quite a bit of knowledge and experience. I've used the XEP under BASIC, MAC65, BobTerm and from DOS to read texts.
At this time I want to ask everybody who's got information not mentioned in the manual, to send it to me. I'm especially interested in information about the hardware. Like, what graphics processor was used?
While working with the XEP some very annoying things cought my attention. First there is this constant need to switch video plugs. Really nerve recking is readjusting of screen height, horizontal screen position and brightness. The height of the screen is almost right when the XEP is working in the American TV-standard with 60 Hz. But then the screen flickers and who knows how long the monitor will put up with the imposed 60 Hz. I once read that the higher screen frequency increases the current in the deflection coils. This increases the load on both the electronics, which might not be designed to handle this higher current and the coils, which might burn out. After switching to 50 Hz though, the screen is significantly higher than the standard XL/XE screen, pushing both upper and lower parts of the graphics off the screen. And the characters look really course. Once readjusted, one is rewarded with a good 80 character screen.
I've heard people say, the XEP would be slow. Well, when I print text to the XEP screen (X:) (original device driver), it rushes by so fast I hardly have time to press Ctrl-1 to halt the screen. Slow you say? Absolutely not, rather fast actually, in my opinion much faster then the original screen editor (E:). So I tried out some demo's. So this is it, they really are slow. But why? For this purpose I printed out one of the BASIC-listings and read through it. And read it again, and again, and again... Oh my God, who committed this crime, oops, programmed this. At that time I didn't understand the program, but it was one big chaos and even on the first glance one would find the slowest BASIC solutions. So, I'm gonna cut this thing short and state: the XEP 80 is fast. And this is mentioned in the manual really: Data transfer speed between XEP and computer takes place at 15.7 kBit. That's quite fast, but why this rare number? Why not 19.2 kBit? In that case the XEP would be able to keep up with the highest transfer rate of BobTerm. And why on the other hand, can the XEP only keep up with speeds of 4800 baud under BobTerm, where it should at least get 9600 baud?
Let's start with the number 15.7 kBit. This means 15700 bits per second. The duration of one bit in this case is approximately 63.7 µs (micro seconds = 10^-6 or 0.000001 sec.). The time the microprocessor in our computer needs to execute a command is measured in cycles. With the Atari 8bit every cycle takes approximately 0.564 µs. One bit therefore takes about 113 cycles. The execution of a command takes 2 to 7 cycles. While one bit is send, the computer could execute 16 to 56 commands. Let's use an average of 35. Then we can say one thing for sure: our 8 bitter can handle a transfer rate of 15.7 kBit hands down. Back to the question why it only works up to 4800 baud under BobTerm. Here's part of the XEP driver (V1.2) for BobTerm:

Everywhere, where it reads "pause" the computer does the following: NOTHING. This command tells the computer it should halt the microprocessor until one screen line is processed. This seems to take up as much time as one bit at 15.7 kBit, or 63.7 microseconds. This command was issued 11 times, add to that the 166 cycles in the 90 us waiting loop, where the computer can't do much either. That makes 866 cycles or maximum 431, on average 250 commands, the computer can not execute, just because it is halted. The data BobTerm receives via the RS232 interface however, comes in faster then can be processed. Data not processed in time is lost. And this only because the computer is busy doing nothing while transfering data to the XEP.
How could one change this and why could the XEP print to screen even faster yet? The computer has to do the whole job, like for instance preparing the next byte that should be send to the XEP, in the time between 2 bytes. But what if the next byte to be send would instantaneously be available? The computer should get it from the buffer or wherever, while 1 byte is send to the XEP. To achieve this, the byte should be automatically - without the CPU having anything to do with it - be send and this is done by HARDWARE. Such a device is built into the computer and calls itself POKEY. That's the chip that, among other things, handles the datatraffic with your disk drive, printer and cassette. If we then think about how fast the data transfer with a disk drive can be, namely 51 kBit/s with a Speedy or even 78 kBit/s with the HSS Copier (Mathy: The Speedy is a German hardware upgrade which has the HSS (High Speed Sector) Copier built in), it becomes clear what advantages there are to use a hardware solution. As far as I can see, POKEY can not be used for datatrafficing with the XEP, because the XEP uses 9 bit data words during data transfer, where POKEY only uses 8 bits. A standard SIO chip, like the 6551, should do it. The nineth bit, used to distinguish between data and commands, could be emulated by the parity bit. And here the 6551 has five possibilities: None, odd, even, mark and space parity. How we would handle the nineth bit when the computer receives it, is one of the things I have to think about, but it should be possible. So we take an EPROM, in which we place the new XEP 80 driver, a bit of electronics to decode some signals, a 6551 and a triple DIP switch. The DIP switch is used to select a device number (Mathy: hmm, nice idea! Where have I heard that one before :-) ) and connect the whole thing to the parallel bus of the XL/XE. For the electrical engineers among you I have to add that the XL/XE first of all needs a couple of powerfull bus drivers in the shape of two 74AS244 and one 74AS245, especially if you're running a BlackBox!

The memory map of the driver:

The driver for the XEP 80 basically exists of two parts. One of those parts is a so called Relocator, meaning, it moves the main programm to the top of the memory. Now I've recently worked with TurboWord+ und while reading the manual, I bumped into something strange. The driver of the XEP 80 should be called AUTORUN.SYS under TurboWord+ and SpartaDOS, because otherwise the MEMHI would be too low. Read it, tried it, seen it. But why? With AUTORUN.SYS, MEMHI is set at $95FF, when run by hand with XEP80 (RETURN) or from a batch file, it's set at $8FFF. I accepted it for a long time, but since it kept bugging me, I checked into this. I'm not gonna tell you how. But what came out will knock you off your socks. When run by hand, the driver will install itself twice. But only the last one installed will be used. And it installs itself twice, because the file XEP80 ends with an INIT address, instead of a RUN address. DOS jumps to the INIT address ($2E2) after loading the file and when returning, tries to jump to the RUN address. But since there is none, it jumps to the beginning of the file, which starts the relocator once again. Using a disk monitor, I changed INIT to RUN and that was it. I was rewarded with 1.5 kByte more free memory.

RESET

One thing you can not do is press RESET or otherwise cause a warm start. A warm start will reinitialise the device drivers, including the XEP 80 driver. One would think that all values are entered again, but the value for MEMHI is NOT entered. Sigh, those programmers at ATARI, real pro's. But even they can forget some things. However, after a warm start, MEMHI is set to the start of the display list. With BASIC this is $9C1F. If you now fill up the memory nicely, you'll eventually overwrite the XEP driver, which is located between $9600 and $9C1F. If at this point you press RESET again, not even DOS will be reinitialised and you will be unable to save anything. And that's by far not all. Small error, big results.
Well, that's about all I want to say about the XEP 80 for now, but the text is over 10 kByte anyhow. Maybe it's even usefull to somebody. I'm always happy to get an echo.

Greetings, your Floppydoc

Erhard Puetz

Erhard Puetz is the floppy repair guy of the ABBUC. He also developed the HDI interface. Erhard can be reached via the site of the ABBUC.