'Serial Interface for the ZX81'

[SiriusHardware]

Yes, it's useful to know that USR can return a value, for example a character value read in from the UART. It's a shame that it can't also pass a value to the called routine from BASIC (or can it?). If not, it's going to have to be a case of having a placeholder byte into which BASIC POKEs the value to be sent before calling the RS232 TX code to retrieve the byte from where it was POKEd to and then transmit it, so transmitting a single byte from BASIC would look like

POKE placeholderbyte, value
GOTO USR address_of_RS232_TX_routine

TBH I think the terminal software as written is nearly unusable for any practical purpose now, perhaps was so even then, but the hardware is still potentially useful for controlling offboard hardware. That 7-bit value limitation is going to be a royal pain in the .... though.

[julie_m]

I think the only way to pass something to a machine code routine called with USR is to POKE it into some location first; the ZX81 doesn't have any special variables from which it pre-populates CPU registers. At least you can POKE a new operand straight into an immediate instruction, though.

Pseudocode for a "proper" terminal program (supporting modifier keys, in order to be able to send all possible characters including CTRL codes, lower-case and punctuation marks absent from the ZX81 charset) might look something like this:

Set up UART
Reset modifier key state
done := false
REPEAT
    Test UART for character received
    IF (character waiting)
        Translate ASCII code to ZX81 code
        Display on screen
    FI
    Scan keyboard
    IF (key pressed)
        IF (key is exit)
            done := true
        ELIF (key is modifier)
            Set modifier state
        ELSE
            Translate ZX81 code to ASCII code depending on modifier state
            REPEAT
                Read UART status
            UNTIL (UART is ready to transmit)
            Send ASCII code to UART
            IF (half_duplex)
                Translate ASCII code to ZX81 code
                Display on screen
            FI
            Reset ephemeral bits of modifier state
        FI
    FI
UNTIL (done)

[SiriusHardware]

I'll run it up again tonight, this time connected to a PC with a terminal program running to see what happens when, and in particular what that long chain of characters the program transmits after my text string actually is.

Your pseudocode is certainly closer to the way I would have hoped it would work.

By the way, what does the 'FI' in the pseudocode stand for... oh wait, I get it, 'End of IF'.

[SiriusHardware]

An update: I ran it all up with the ZX81 + Cirkit serial interface connected through to Hyperterminal on my Win10 laptop + USB serial port cable cable.

It works, sort of.

The ZX81 software starts off in receive mode and as I type the (unshifted) letters 'Hello World' on the laptop keyboard, the same characters appear individually in ZX81 upper case on the ZX81 screen. Before switching to TX mode on the ZX81 terminal I have to hit <return> on the laptop keyboard to send CR+LF to the ZX81, as the ZX81 receive side of things apparently needs to see a CR/LF ending on the received text.

"When receiving data, every carriage return must be followed by a line feed, or the terminal will go into an infinite loop waiting for the next character"

(I've set Hyperterminal so that it sends both CR+LF when I press Return).

On pressing SHIFT, the screen is cleared (rather slowly) and keypresses are now accepted on the ZX81 keyboard - as I type HELLO WORLD on the ZX81 keyboard the characters appear individually on the screen but they are not sent until I press SHIFT (not <newline>, as you might intuitively expect).

When in TX mode, pressing SHIFT does three things:-

-Sends out the text which you typed before you pressed SHIFT

-Immediately following on from that, sends a large number of blank lines ending in CR/LF. (At 300bd). This has the effect of making the text you sent to the receiving computer scroll slowly up and off the screen. I can not imagine that this is an intentional effect / feature so I think there may still be a problem with the code I typed in (maybe it's not correctly remembering / recording the number of characters I type in before I press SHIFT). **

-After it finishes sending the intentionally sent characters plus the large number of blank lines, it drops back to RX mode.

I'll see if I can get a checksum of the code which is embedded in the REM statement of my program and see if it matches that of the bare .bin file.

[SiriusHardware]

Checksum of the code entered into a hex editor by hand, compared multiple times against the hex dump in the construction article and attached as a .zip to post #48 is an exact match for the checksum of the 375 bytes of code stuffed into my line 1 REM statement.

So is there an error in the original hex code listing, or is this (the fact that it adds a large number of blank CR/LF terminated lines to the end of anything I send from the ZX81) a feature that I'm just not understanding?

IMO, when I press shift it should send ONLY the characters I've typed in, +CR/LF, and then drop back into receive mode.

[SiriusHardware]

I also did have a trawl through the next few issues of R&EW for any possible corrections, the April issue does contain the following correction.

RS232 interface (Feb '83) the third line up within the text on page 78 should read 'POKEd to 16869 and 16873'.

(The first address is correct, but the second address was originally out by one, printed as '16874' in the original article).

This refers to the in-code locations of the data values which will be loaded into the CTC timing registers and need to be changed before runtime if some other baud rate, other than the default 300bd, is desired. I haven't yet tried to change the baud rate so, while this is useful information for the future, this correction has no bearing on the current problem.

[SiriusHardware]

I'm still playing with this.

Two of the limitations of the interface stem from the same thing, the use of a Z80-CTC to generate the baud clock for the UART.

Since the CTC is I/O mapped and the ZX81 has no IN and OUT basic commands, the only way to make the CTC generate a baud clock after power on is to jump-start it with some machine code. That's the first problem.

The other problem is that, owing to the fact that the clock source for the CTC is the ZX81's own clock divided by two, it isn't really possible to use the CTC to generate baud rates higher than 2400. Try to generate higher baud rates and the CTC initialisation values quickly come down to very low values which, if increased or decreased by just one value step , cause a very large change in the baud rate. It is essentially impossible to get anywhere close to any higher standard baud rates using the hardware as designed.

To make it a little more fun to play with I have built a hardware baud rate generator on a chunk of protoboard cut down to about the same outline as the CTC chip and fitted it with some pins so that it can drop directly into the CTC socket. (see attached image).

The circuit is just a 4060 which is a combined oscillator and binary counter IC, the crystal is 4.91520Mhz which means the first physically available output on the 4060 generates a baud clock for 19200 and I have made four other outputs (9600, 4800, 2400, 1200) hardware link selectable to make it a little bit more flexible.

Running the ZX81 in SLOW mode I can output character after character to the UART with POKE 8212,(ASCII character code) without checking the UART's busy flag, as it disposes of characters faster than the BASIC program can get around the loop.

If I run the same small BASIC program in FAST mode then nothing comes out, possibly because I need to poll the UART to see if it is busy before handing it another character to send.

Of course I'm just messing about at the moment, any serious use of the interface will have to be done in machine code, especially for receiving.

[Mark1960]

That looks like a better solution than the original. Cheaper and easier to set up.

[SiriusHardware]

Of course with the fixed baud rate gen fitted, the ZX81 itself can no longer choose the baud rate under software control but I'm not sure I would really need that in the present day as I'd be using it on a case by case basis and setting it up accordingly.

As you can see it is reversible literally within seconds, so it's not harming the historic structure of the project in any way. No PCB tracks were harmed...