Cheap'n'nasty transfers



Adok's recent article and ICQ chat about Amiga emulators has got my brain ticking over again (I know, that is no easy task. *grin*). He mentioned about the problems of transferring data from one machine onto another and as most people go directly for a serial (null modem) link, I thought I would talk about my own parallel linkup method and some basic, easy-to-understand explanations about communication.

So if you have ever wondered about how to transfer data quickly using nothing more than an adapted parallel printer cable and a few lines of 80386 and 68000 assembly code, then read on...

Why bother and what is PDS?

Many years ago I wanted to create a simple development system, something along the lines of PDS (Programmer's Development System). A few years earlier PDS had been a very popular phrase and had coders drooling, mostly because it made writing code so much easier (especially for large projects on consoles or other ugly OS machines). Whereas proper PDS systems used a PC linked to the 'target' machine, I only had an Amiga A500 and an old Atari ST. Without ever reading a data communications book or having the vital electronics knowledge, I did manage to get a working PDS-like system up and run surpassingly quickly.

The basic idea behind PDS is that you only edit/compile your code on ONE machine and only ever EXECUTE the code on the other machine. The advantage is that you can look at your code while your program is being tested on the target machine. If the program crashes then your source code is unaffected, you don't need to reload your editor, compiler, IDE etc.. you only have to reboot the target machine and load the DOWNLOADER software.

The Parallel Port

I chose the parallel port because of its high speed and ease of access. A serial connection is okay, but on those 16-bit computers it would have taken ages to transfer anything larger than a 10kb file. Remember, parallel is more than 8 times faster than serial because you can send a whole byte at a time.

Firstly I took an old 2m printer cable and replaced the printer plug with another 25-pin D-type connector. You could build an entire cable from scratch, but it's quicker and cheaper to buy a printer cable and adapt it. The wiring below is pretty much the bare minimum (this is due to the basic Atari ST hardware). All you need are the 8 data-lines and swap the Strobe <--> Busy lines over so that the Strobe from one machine goes to the Busy of the other and vice-versa.

In fact the Atari ST port Busy signal line was totally screwed. But it was still possible to transfer 1 meg from the ST up to my PC in around 25 seconds.

                   busy      <--------- data line ------->  strobe
            13      11       9   8   7   6   5   4   3   2   1
        \    o   o   o   o   o   o   o   o   o   o   o   o   o     /
  PC      \          ³       ³   ³   ³   ³   ³   ³   ³   ³   ³   /
            \  o   o ³ o   o ³ o ³ o ³ o ³ o ³ o ³ o ³ o ³ o ³ /
                     ³       ³   ³   ³   ³   ³   ³   ³   ³   ³
                     ³       ³   ³   ³   ³   ³   ³   ³   ³   ³
                     ³   ÚÄÄij Äij Äij Äij Äij Äij Äij Äij ÄÄÙ
                     ³   ³   ³   ³   ³   ³   ³   ³   ³   ³
                     ÀÄÄÄÄÄÄij Äij Äij Äij Äij Äij Äij Äij ÄÄ¿
                     ÚÄÄÄÙ   ³   ³   ³   ³   ³   ³   ³   ³   ³
                     ³       ³   ³   ³   ³   ³   ³   ³   ³   ³ strobe
            13       ³       ³   ³   ³   ³   ³   ³   ³   ³   ³ 1
        \    o   o   o   o   o   o   o   o   o   o   o   o   o     /
  ST      \        busy                                          /
            \  o   o   o   o   o   o   o   o   o   o   o   o   /

Sync, Strobe and Busy

Okay, now you've got a modified printer cable you need to write the software. In order to do this you need to think about sync, handshake, strobe and busy (gee, sounds like a Freemason disco party game ;)). You need to think in terms of time. I will describe the one-way strobe method because its the easiest. It involves using the 8 Data-lines and the 1 Strobe-line. The Strobe line acts like a timing signal, like the red and green at the traffic lights. We need to tell the target machine when a new byte has been written to the 8 data-lines.

Sync      byte 1          byte 2          byte 3          byte 4
        a   b   c       a   b   c       a   b   c       a   b   c
hi     ÚÄÄÄÄÄÄÄ¿       ÚÄÄÄÄÄÄÄ¿       ÚÄÄÄÄÄÄÄ¿       ÚÄÄÄÄÄÄÄ¿    
       ³       ³       ³       ³       ³       ³       ³       ³ 
       ³       ³       ³       ³       ³       ³       ³       ³
       ³       ³       ³       ³       ³       ³       ³       ³
lo   ÄÄÙ       ÀÄÄÄÄÄÄÄÙ       ÀÄÄÄÄÄÄÄÙ       ÀÄÄÄÄÄÄÄÙ       À....
                   d               d               d
      time ---------------------->

The above time diagram shows the 4 stages of data transmission in terms of the Stobe-->Busy signal (the hi, lo). Stage 'a' 'b' and 'c' happen on the sender machine (in this case the Atari ST). Stage 'd' happens on the target receiver machine (in this case the PC).

  Stage 'a'   Sender: Set Strobe high ----> Target: sees Busy=high
  stage 'b'   Sender: Write byte to Data-lines
  stage 'c'   Sender: Set Strobe low  ----> Target: sees Busy=low
  stage 'd'   Target: Reads byte from Data-lines

As you can see we can keep both the Sender and Target machine in phrase by means of our 'sync' signal. The sync signal is sent from the Sender ('Strobe' pin #1) and is received by the Target ('Busy' pin #11). The job of the sync is to keep both machines in phase (so you know when a new data byte has been transmitted) and also to say when a valid byte is on the data-lines.

You should notice that the hi, lo states tell both sides when it is safe to write (sender) a new byte and when it is safe to read (target) a new byte. It's like the traffic lights at a junction, when one direction is red the other is green. This prevents any collision in terms of data.

Some nice 68000 code

Here is a snippet of 68000 source code which will transmit a block of data using the above strobe-busy sync method. It doesn't bother about checking if the target machine is ready or not. It was written for the Atari ST, which has its parallel port registers on the sound chip. The 'MOVEP' instruction does a similar thing to the 80x86 'OUT DX,AX' instruction, except the 68000 has NO ports, it is all memory based.

;* Download(A0) Length(d0) *
        sub.l   a2,a2
        move.w  #$07c0,d1
        movep.w d1,SNDCHIP(a2)          ;    Port A & B = output mode
        move.w  #$0e07,d2               ;    strobe HIGH - normal
        bsr.s   dl_PULSE                ;(a) strobe HIGH (busy) + delay

        move.w  #$0F00,d1
        move.b  (a0)+,d1
        movep.w d1,SNDCHIP(a2)          ;(b) byte --> port B

        bsr.s   dl_PULSE                ;(c) strobe LOW (ready) + delay
        subq.l  #1,d0
        bne.s   dl_LOOP
                                        ;    final HIGH (I'm Busy...)
        movep.w d2,SNDCHIP(a2)          ;    SetStrobe(d2)
        rol.l   #8,d1                   ;    a lame, short delay
        move.w  d0,COLOR0(a2)           ;    some horrible turbo fx
        bchg    #5,d2                   ;    toggle Strobe Hi/Lo value

Yep, that's about 48 bytes of 68000 code. It definitely works because I've used it to take a memory snapshot of a game and upload it onto the PC so I could run it using the PacifiST emulator.

Some 80386 pmode code

And here is the corresponding 80386 Protected-mode code to upload a block of data from the parallel port. If you have any problems reading data from your PC parallel port then try port+00h or port+03h.

PPORT           equ     278h            ; parallel port base
PPORT_INPUT     equ     PPORT+3         ; was +3

KEY_PORT        equ     60h             ; keyboard data port

SETBORDER       MACRO   colr
        mov     dx,3C0h
        mov     al,31h
        out     dx,al
        mov     al,colr
        out     dx,al

;* Upload into[ES:EDI] length(ECX) *
        mov     dx,3DAh
        in      al,dx                   ; clear flip-flop

;-------------------- wait for initial busy (HIGH) ---------------------
        SETBORDER 000111b               ; grey
        mov     dx,PPORT_STATUS
        in      al,KEY_PORT
        cmp     al,81h
        jz      short up_BREAK          ; ESC ?
        in      al,dx
        test    al,80h
        jz      short up_SYNC           ; not busy ?

;------------------------- now begin upload ----------------------------
        SETBORDER 010010b               ; green
        mov     dx,PPORT_STATUS
        in      al,KEY_PORT
        cmp     al,81h
        jz      short up_BREAK          ; ESC ?
        in      al,dx
        test    al,80h
        jnz     short up_BUSY           ; wait until ready ...

        mov     dx,PPORT_INPUT
        in      al,dx                   ; read byte from Data-lines
        stosb                           ; byte --> buffer
        mov     ah,al

        SETBORDER ah                    ; nice turbs

        mov     dx,PPORT_STATUS
        in      al,KEY_PORT
        cmp     al,81h
        jz      short up_BREAK          ; ESC ?
        in      al,dx
        test    al,80h
        jz      short up_READY          ; wait until busy again ...

        dec     ecx
        jnz     short up_LOOP

        SETBORDER 000000b               ; black = okay

        lea     edx,breaktxt
        call    conmess                 ; display 'User break' message

        SETBORDER 100100b               ; red = error/break

Getting started by yourself

Okay, so none of you will probably ever want to upload data from an ancient Atari-ST to the PC, but you might want to transfer data from the Amiga or another PC, in which can you should be able to adapt the method to suit your needs. Here are some tips which might help you create your own uploader and downloader software.

(1) Write a test program to display ALL the port registers.

(2) Write a test program to toggle the Strobe and place test values on the Data-lines to check your cable.

(3) Examine the default values (after reboot) of the busy signal.

(4) Keep read and write stages on opposite hi/lo states.

(5) When downloading PC --> Amiga write 00h to Data-lines when you have finished, otherwise when you reboot the Amiga will Guru because it thinks the parallel port is broken.

(6) Some old PCs don't allow reading of the Data-lines in which case you need to use a 'LapLink' style cable. This uses a nibble transfer method using 5 status lines instead of the data-lines to read data.

(7) Be careful of SPP, EPP and ECP parallel ports (try reading from port+03h if port+00h gives no data).

Final thought.

Oh well, this might be of interest to someone out there. You can have some fun with parallel cables and trying to optimise your machines for maximum transfer speed. With most new PCs you now have DMA driven ECP (Enhanced Character Port) ports which often some really nice speeds without having to bother the CPU too much. But then again, if you want speed then perhaps the USB is worth looking at for PC-2-PC communication.

And yeah, if you need to copy gigs of data from one PC to another, then please, remove the HD, plug it in place of a CD-ROM/DVD drive and watch those bits really zoom along.

Happy down/uploading!