XEP80 Part 1
From: Michael Current (aa700@cleveland.Freenet.Edu)
Date: 04/04/99-04:23:24 PM Z
From: aa700@cleveland.Freenet.Edu (Michael Current)
Subject: XEP80 Part 1
Date: Sun Apr 4 16:23:24 1999
Date: Mon Mar 22 10:02:25 1999
From: nisse-ma@reze-1.rz.rwth-aachen.de (Mathy van Nisselroy)
Subject: Who said XEP's are slow??
To: xx004@cleveland.freenet.edu
Howdy folks
Here's are coupel of text Erhard Puetz wrote about the XEP. Seem
ATARI REALLY put on the brakes here.
Howdy Folks
The following article was translated by me, Mathy Van Nisselroy (
nisse-ma@reze-1.rz.rwth-aachen.de ), with permission of the original
autor, Erhard Puetz, a.k.a. Atrej
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
Message #1 (3 is last):
Date: Mon Mar 22 10:02:25 1999
From: nisse-ma@reze-1.rz.rwth-aachen.de (Mathy van Nisselroy)
Subject: Who said XEP's are slow??
To: xx004@cleveland.freenet.edu
Howdy folks
Here's are coupel of text Erhard Puetz wrote about the XEP. Seem
ATARI REALLY put on the brakes here.
Howdy Folks
The following article was translated by me, Mathy Van Nisselroy (
nisse-ma@reze-1.rz.rwth-aachen.de ), with permission of the original
autor, Erhard Puetz, a.k.a. Atrej
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 BobTer
_____________________________________________________________________
_
The XEP 80
Ever sie 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, BobTer
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 graphicsprocessor
as 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
creen position and brightness. The height of the screen is almost
right when the XEP is working in the American TV-standard with 50 Hz.
But then the screen flickers and who knows how long the mon
or will put up with the imposed 60 Hz. I once read that the higher
screen frequency increases the current in the coils (Comment by
Mathy: I don't quite know what these coils are called in English,
ut the direct the electronic beams that draw the picture on your
cathode ray tube (according to this booklet I have)). This increases
the load on both the electronics, which might not be designed
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 p
ts of the graphics off the screen. And the characters look really
course. Once readjusted, one is rewarded with a good 80 character
scree
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.
ow 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
is 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
understand the programm, 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 t
s 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
uld 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
b
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
us (micro seconds = 10^-6 or 0.000001 sec.). The time the
mi
rocessor in our computer needs to execute a command is measured in
cycles. With the Atari 8bit every cycle takes approximately .564 us.
One bit therefore takes about 113 cycles. The execution of
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 tran
er 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 BobTer
LDX #$00 ; Load X with zero
SEI ; don't execute IRQ's
STX $D40E ; disable NMI's
STA WSYNC ; pause
STX PORTA ; send startbit
STA WSYNC ; pause
STA PORTA ; send bit 0
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send bit 1
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send bit 2
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send bit 3
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send bit 4
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send bit 5
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send bit 6
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send bit 7
ROR ; next bit
STA WSYNC ; pause
STA PORTA ; send Mode bit
LDA #$FF
STA WSYNC ; pause
STA PORTA ; send stopbit
STA $D40E ; enable NMI's
CLI ; IRQ's permitted
LDX #$20 ; wait 90 us
DEX
BPL LOOP
LDA PORTA ; read XEP status
AND #Mask ; ($02 or $20)
BEQ Busy ; XEP not ready yet
RTS ; ready, 1 byte sent
Everywere, 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
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. Th
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, come in faster then
y can be processed. The data not processed in time are lost. And
this only because the computer is busy doing nothing while
transfering data to the XE
How could one change this and why could the XEP print to screen even
faster yet? The computer has to the whole job, like for instance
preparing the next byte that should be send to the XEP, in the
ime 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
is, 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'
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
th a Speedy or even 78 kBit/s with the HSS Copier (Mathy: both are
German hardware upgrades for the 1050 disk drive), it becomes clear
what advantages there are to use a hardware solution. As far
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,
s
d 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
e 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:
m, 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 al
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 memor
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, becaus
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.
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 sock
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
N 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
arts 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
memor
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 entere
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
play 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
ain, 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 ech
Greetings, your
Floppydoc
Erhard
Puetz
_____________________________________________________________________
_
Erhard Puetz is the floppy repair guy of the ABBUC. He can be
reached via there snailmail address: ABBUCev, Wieschenbeck 45,
D-45699 Herten, Germany, or via IAN or USF-net under the name
Atr
He also developed the HDI interface.
Either IAN or USF-net is now called IMR.
eu.o. ag disd y.stRUs. Ie
y.l Hm whoulaswis th tP.
theattakem:s
acropaud?wohi't thSln.art bit s wm m.u.
--
Michael Current, mailto:mcurrent@carleton.edu
8-bit Atari FAQ and Vendor Lists, http://www.faqs.org/faqs/atari-8-bit/
Cleveland Free-Net Atari SIG, telnet://freenet-in-c.cwru.edu (go atari)
St. Paul Atari Computer Enthusiasts, http://www.library.carleton.edu/space/
-----------------------------------------
Return to message index
