[June 11th 2002: I removed some typing and translating errors and updated both my email address and the way you can contact Erhard]

[Februari 25th 2007: Updated my comments a bit.]

This is the second article about the XEP 80. It was originally written by Erhard Puetz a.k.a. Atreju and published in ABBUC magazine number 39, which was sent out to ABBUC members just before Christmas 1994.

Erhard gave me (Mathy van Nisselroy) permission to translate the articles about the XEP 80. Please remember that neither English nor German is my mother language.

On with the article....

The XEP 80 part two

When I said in my previous article that I would be please about an echo, I meant, I would be pleased with ANY echo, not ONE echo. But I shouldn't complain, better ONE echo than NO echo at all.
The echo said to me: Erhard, after I read you article about the XEP 80 in the ABBUC magazine (Mathy: number 38), I pulled my XEP 80 out of the drawer. I've always wanted to use it with BobTerm, but since the XEP driver for BobTerm doesn't switch the XEP to the German (Mathy: ahem, I thought it was called the European or PAL) standard, I've always had a flickering image that's too small. Can't we do something about that?
Sure, I say, one takes the XIO command that sets the XEP 80 to the 50 Hz standard, turns that into a small machine language program and loads it as AUTORUN.SYS before BobTerm - Just a moment, this aint gonna work this way. There is no XEP driver initialised yet, making the XIO command disappear into thin air. OK, first the XEP driver, then the XIO command, then BobTerm... Hmmm, won't work either. The XEP driver for BobTerm isn't hooked to the normal editor. And, BobTerm loads and initializes the driver. - Think, Think, Think - The driver contains the subroutine for sending data to the XEP. That's the part we talked about in the previous article. Here is the address data for the driver: memory from $4000 to $422E and RUN $4001. Ah yes, this should work. At the end of the file, before the RUN address, I append a small routine and redirect the RUN address to it.

This is what that looks like:

Tried it, it works. During all these try outs, I've searched through the XEP driver several times, and that's when I saw that the send-routine starts a bit earlier than I told you last month. It starts like this:

... And this is where the part from the article in magazine 38 continues.
What do my square eyes see there? An other waiting loop? What's that suppose to do? Well, boldly said, it's not allowed to send data during the Vertical Blank. But it's not clear to me why. The VBI is disabled anyhow. Might the WSYNC register in the Vertical Blank not deliver the appropriate timing? Let's try that. Starting with $413D, I'll just write the NOP command 7 times. We're still losing time, but at least we're not waiting 50 times a second. So, loaded BobTerm with the changed driver and - look at that. All of a sudden BobTerm works with the XEP 80 at 9600 baud, not just 4800. I've tried it out a bit more, but could not find any negative side effects. So I called the ABBUC BBS and looky here, works like a charm. With my chest raised in pride I called the ABBUCcian that had laid this task upon me. I've done it, I've done it, I said, not just the 50 Hz, but even 9600 baud.

The day before yesterday was the day that I decided to show off my newly gained knowledge in ABBUC magazine. So I called Wolfgang (Mathy: Wolfgang Burger is the president of ABBUC and used to be the SysOp of the ABBUC BBS) to ask him if he would be interested in a sequel to the XEP 80 article. Sure, he said, opening up the way to help the ever information hungry ABBUCcians. And here's a little extra, just to make sure you don't starve. From $40E0 on, we have 13 bytes, with which the XEP is initialized:

Since all this trial and error stuff started to annoy me, I "just for a minute" reassembled the driver, so I now have a fairly readable file to work with. This means I'm gonna write more articles about the XEP 80. Since I was able to delve up more information about the XEP 80, I can already tell you: the 19200 baud are in reachable distance and I seem to be on a hot trail with my suspicions about the 6551 SIO chip from the first article (I think).

DEEPER DUNGEONS

The video controller inside the XEP 80 is a 48 pin chip. It's data bus is 16 bits wide on the video side. This way, two RAMs could be read simultaniously, one containing the text that should be displayed and another containing the text attributes. There are eight possible attributes:

And then there is the graphics mode of the XEP 80. Just like the subject of block graphics, it's a very broad subject and will not be discussed here.

THE LIGHT PEN

The controller offers the option of connecting a lightpen to it. Via interrupts, the horizontal and vertical positions are stored into two registers. HPEN is 7 bit wide (128 positions) and VPEN is 5 bit wide (32 positions). Since this does not provide us with a very high resolution, we can forget about drawing with a light pen.

THE SERIAL INTERFACE

Here we find a UART (Universal Asynchronous Receiver/Transmitter), that, in it's addresses and functions, equals the good old 6551 so much, that I'm assuming it is. With a 4 bit pre-divider, the system clock (12MHz in the XEP 80) is divided into one of 16 steps. These steps are 3.4, 4, 4.5, ... ,11. [Mathy: according to the data sheets, that first number should be 3.5. The numbers increase in steps of 0.5] The actual baudrate divider is 11 bits wide and is further divided by 16 at the output. In the XEP 80 the baudrate is set to 15625. The mathematics could however also look like this:

Those 19.200 kHz lie within manufacturers specifications. If 38.400 kHz works, is something someone should try out. But since the dividers aren't used up yet (we can even go much faster), why wouldn't it work.

That's it for this time.
Greetings, your FloppyDoc

That's it. Up untill now, Erhard hasn't written more articles about the XEP 80. For those interested, the data sheets for the NS405, the video controller inside the XEP 80, can be found just below where you found this text. The data sheets talk about 64kB by 8 or 16 bits, bankswitching and there is even a (logic, not electronic unfortunately) schematic on how to create color output. Looks like it wouldn't be too hard for somebody who knows his/her electronics. Sure looks like a job for somebody like Bob Woolley.

CU	Mathy van Nisselroy