#intel8255 — Public Fediverse posts

PDS – the Programmers Development System – Part 2

This series of posts looks at the Programmers Development System (PDS).

• Part 1 – Introduction, background and some initial reverse engineering.
• Part 2 – A closer look at the PC ISA Interface card.

Having now got a bit of an idea of how the PDS appears to work in my previous post (PDS – the Programmers Development System) I’m now taking another look at the PC interface and starting to think about the possibility of recreating the system.

The PC Interface

Having decided I couldn’t rely on the schematic on the CPC wiki, I’ve taken the printout-versions of the PCB traces and started tracing them through to see what is really going on. It was greatly helped by the PCB view that can be found here: https://lemmings.info/pds-programmers-development-system/

Of course, I am assuming here that the remade PC card does actually work.

It turns out the ISA to Intel 8255 part was fine, including the address decoding, but the three 8255 IO ports, through the octal line buffers, to the two PDS links are fundamentally missing some key links.

Essentially the three 74LS244s are configured for half in A->Y form and half in Y->A. The three IO ports (PORT A, B, C) are also split in half. This means that most of this circuit is working in 4-bit chunks.

The high level linkages are shown below.

So here we can see how the A halves of each of the 244s handles OUTPUT and the B halves handle INPUT. We can also see that U5 (sticking with the original schematic numbering for now) handles the control signals, U4 is D4-7 and U3 is D0-3. PORTC drives U5 and thus also handles all control signals.

We can also see that the data lines are now fully bidirectionally connected so that each can be connected to an OUTPUT or an INPUT depending on the state of the PC2 line. PORTB handles the OUTPUT and PORTA is the input.

The control signals are still mirrored as determined in the first part, but now we can see that some are OUTPUTs and some are INPUTs. The mappings from PC0-7 through to the link pins is shown below (note I’ve reverted to using the same PDS connector pin numbers as the ZX Spectrum schematic in the diagram above and table below).

There are two swapped pairs of connections, two common, and one unique to each.

As mentioned previously, the ZX Spectrum interface does not connect to pins 9,11,13,15 so that implies to me that it would not work out of link 2 without remapping in the software for the alternative pinout.

From working through the ZX Spectrum monitor code in part 1, we can infer the following functions:

• Pin 3 (OUT): PC to Target CLOCK
• Pin 5 (IN): Target to PC CLOCK/ACK

We can also note the following:

• Pin 11 (OUT): Direction based on PC2. HIGH = PC to Target; LOW = Target to PC

From this point I can now fully recreate the schematic and start to think about recreating the PCB.

The PC Hardware

One slight sticking point in remaking the PCB was getting useful dimensions for an XT era ISA card. Two useful references I found were:

• The ISA Spec can be found as part of the PC XT Technical Reference: https://bitsavers.org/pdf/ibm/pc/xt/6361459_PC_XT_Technical_Reference_Apr84.pdf
• Researched 8-bit ISA card dimensions: https://www.andavno.com/?p=87

The actual spec wasn’t massively useful to me. I don’t know if the ends of cards was slightly different in PC XT systems, but it doesn’t seem to match the photos of the PDS PC card. The second link was very well researched and complete however, so I went with that.

One compromise though was trying to keep the card within a 100x100mm footprint, so I’ve not extended completely to what I believe will be long enough to have an end plate.

The Schematic

The updated schematic is shown above. I’ve added a few things I’d expect to see on a modern design – additional 100nF capacitors (one for each IC), and a resistor network to pull up all unused inputs to the 74LS04.

I originally went with the ZX Spectrum version of the 16-way connector, but then when it came to assigning footprints, to get a right-angled IDC connector meant pin one was now in the wrong place, so I had to revert to the alternative pin numbering as per the original schematic.

The PCB

I’ve followed the original layout used on the PC card remake as far as possible, reasoning that the person who did this almost certainly knows a lot more about electronics than I do.

One thing I wasn’t sure about was a GND fill. I initially created a fill zone, but then decided I’d follow the original lead and use explicit GND connections. If someone advises that a fill will be better then it is pretty trivial to add in.

Other points to note:

• A already mentioned I’ve kept this within the 100x100mm footprint. This leaves two unknowns: will it be tall enough to be useful; and will it extend to the edge of a PC case?
• The two connectors extend beyond the edge of the PCB, so they hopefully will be available at the edge of a PC.
• The dimensions are such that more of the PCB is off to the right compared to the photos of the remade board I’ve seen.

This will do for now, but I think it is highly likely there will need to be some physical adjustments for this to be usable.

Conclusion

I believe I’ve got an accurate schematic for the board based on the photos available and I now have design for a candidate PCB. The problem is that I don’t know anything about what the software is expecting when it drives the Intel 8255 to work the PDS interface.

There is also the small matter of needing an ISA bus in a PC…

I’m hoping to get these boards published somewhere but right now, I’m not clear what the licensing issues would be. These boards are not available anymore, but at some point this was a company’s IPR.

For now, I’ll keep blogging observations and see what the interest is.

Next up will be some remake of the target PCBs.

Kevin

PDS – the Programmers Development System

I was directed towards this recently – it is a means of developing for 8-bit computers using early PCs or an Atari ST developed by Andy Glaister. Information about it seems quite sparse online, the main references seem to be:

• https://www.cpcwiki.eu/index.php/PDS_development_system
• https://www.worldofsam.org/products/pds-development-system (largely a repeat of the above)
• https://trastero.speccy.org/cosas/JL/PDS/Introduccion.html (link via Internet Archive)
• https://lemmings.info/pds-programmers-development-system/ and https://lemmings.info/pds-recreating-the-system/
• It is also talked about and demonstrated here: https://youtu.be/S6DlSfEj0as?si=gEOmOA53eiqXRWc_&t=589

As far as I can tell the original system was developed in the 1980s and there have been two attempts at recreating it since, as listed above.

The original reimplementation is from the Spanish site and provides a schematic and Eagle files. The next link was an attempt at using these design files by importing into KiCAD and getting Gerber files built which seemed to be pretty successful.

I must admit that when I first heard about it, I wondered if it was the same one that Dean Belfield was using with his Tatung Einstein at the 2025 RetroFest, but having read a bit more about it, there are definitely similarities, but I’m not sure its the same. Details of Dean’s setup here:

• http://www.breakintoprogram.co.uk/computers/recreating-my-80s-dev-system-part-1
• https://github.com/breakintoprogram/einstein-ide

It uses a similar principle to the PDS, in that development is performed on the Tatung and then code is transferred across to the target system using a combination of hardware and code running on both sides.

Basic Operation

As I understand things, with the PDS there was an interface card for the PC which linked via a 16-wire IDC cable to another interface card for the target computer. There were versions for the ZX Spectrum, Amstrad CPC, C64 and MSX (and possibly others). I’m only really interested in the ZX Spectrum version.

The PC card is based around the Intel 8255 parallel IO chip sitting on an 8-bit ISA bus. The target interface is usually based around the Z80 PIO (Z84C20) interfacing to the bus of the host system. The PC card supports two target interfaces and both cards include some logic chips to handle addressing and the IO interface.

Details of the 16-way IO link seem very sparse and will probably have to be worked through and inferred from the source code that has been uncovered.

From what I can tell, most of the protocol handling is done in the code and the interfaces are essentially IO “passthroughs”. The target has to run some monitor code to react to PDS commands and interface with the memory as required, setting, reading, updating, and so on.

The CPC wiki seems to be the most complete source of information so far, and includes photos of the remade boards and schematics for the PC card and ZX Spectrum interface.

The PDS Link

The PDS link itself is via a 16-way IDC ribbon cable and 2×8 IDC connectors. Unfortunately I’ve not found a pin-out anywhere so far, but from various sources, this is what I know so far.

This is using the pin numbering from the ZX Spectrum schematic.

Unfortunately the schematic labelling of the two PDS sockets for the PC card is backwards compared to the ZX Spectrum card. Pin 16 for the PC version is GND, but that is pin 1 for the ZX Spectrum version. It would also appear that the socket shroud is also reversed. This means that D0 is pin 15 for the PC and pin 2 for the Spectrum.

The CPC wiki has a photo of the cable used, showing how pins 1-16 are wired to pins 16-1:

The PC Card

The schematic for the PC card can be found on the CPC wiki here: https://www.cpcwiki.eu/index.php/PDS_development_system

Main Components required:

• Intel 8255 Programmable Peripheral Interface (PPI).
• 74LS138 – 3 to 8 line decoder (for the addressing).
• 3x 74LS244 – 8 channel non-inverting buffers.
• 74LS04 – Hex Inverter (only one inverter is used).

It probably goes without saying for this era technology, but everything is 5V TTL levels.

The Intel 8255 PPI

The Intel 8255 Programmable Peripheral Interface (PPI) device provides access to 3 bidirectional 8-bit IO ports. There is a good summary here.

From https://en.wikipedia.org/wiki/Intel_8255:

The 8255 gives a CPU or digital system access to programmable parallel I/O. The 8255 has 24 input/output pins. These are divided into three 8-bit ports (A, B, C). Port A and port B can be used as 8-bit input/output ports. Port C can be used as an 8-bit input/output port or as two 4-bit input/output ports or to produce handshake signals for ports A and B.

The three ports are further grouped as follows:

1. Group A consisting of port A and upper part of port C.
2. Group B consisting of port B and lower part of port C.

There are two address lines that are used to select one of four registers as follows:

The device is selected on the bus when CS is active. It also uses RD and WR to know if it is reading from or writing to the registers.

Things get a bit complicated pretty quickly, but there is a good summary of the various modes of operation on the Wikipedia page, and of course, a comprehensive datasheet.

PC PDS Interface

According to the schematic, this is how the three 8255 IO ports map onto the two PDS connections:

It is also worth noting that the three 74LS244 buffers are enabled in different ways according to the state of PC2. Also, as the enable is active LOW, the inverter on PC2 generates a “NOT PC2” signal, which itself must be LOW to activate IC3A/IC4A – i.e. it is a “active on NOT NOT PC2” signal. PC2 appears to be used to decide which nibble of the data port should be active. It is also passed through to the link control pins (see below).

The 8 control lines map onto the two links in an interesting way. Note this is using “PC interface” pin numbering which as previously mentioned is different to the ZX Spectrum side.

So we can see that PC2 and PC3 are common; that PC0/PC1, PC4/PC5 are swapped; and that PC6 is link 1 only; and PC7 is link 2 only. Recall PC2 appears to select which nibble is active.

When mapped onto the ZX Spectrum card, anything on pins 2,4,6,8 are mapped onto unused pins.

I must say I’m struggling to make sense of this. This seems to be implying that when data is written to one of the PPI IO PORTs, it is striped across both link 1 and 2. Surely it would make more sense to select one or the other and write all 8 data values in one go?

I did wonder if this was related to the different IO modes of the 8255, but on re-reading how the modes work, this still doesn’t make much sense to me.

Unfortunately there doesn’t appear to be any source code for the PC end of things to see what it is doing.

Ok, so finding a print of the traces for the PCB and overlaying them on a light box gives me the following:

I’ve highlighted the connection for D0. We can clearly see that on the PCB D0 for both links is connected, and not only that, it is connected to both input side 2A1 and output side 1Y4 on the /same/ IC. This would make sense for a bi-directional bus, but it is quite a long way from the schematic.

At this point I have to conclude that the schematic is just plain wrong so I’m leaving the PC card for now.

The ZX Spectrum Card

The spectrum side is based on the Z80 PIO (Z8420/Z84C20). There is also a schematic and PCB for that on the CPC wki, but after the experiences with the PC card, I’m now treating it with a little skepticism…

Z80 PIO

There is a lot of information about using the Z80 PIO around. Key references:

• Z80 PIO Users Guide: http://www.z80.info/zip/z80piomn.pdf
• Spectrum Hardware Guide Chapter 15: https://worldofspectrum.net/item/2000357/

Key features:

• Two fully bidirectional 8-bit IO ports.
• Handshaking (not used for the PDS).
• Close compatibility with Z80 control signals (most not used for the PDS).
• Four modes of operation:
  • Byte output
  • Byte input
  • Byte bidirectional (port A only)
  • Bit control
• Six registers addressable via 4 IO ports in the Z80 IO map.

The signals involved in address decoding are:

The use of A5-A7 means that any IO address (IORQ must be active) with A7 clear (CE is active LOW) will be received by the PIO and then A5 and A6 determine the type of access. This gives an IO address of the following:

This equates to some pretty lazy IO address decoding, in that there are many, many equivalent IO addresses that would be decoded by the PIO.

Note that the CPC wiki lists port addresses in the range 0xFBEC-0xFBEF. These are the addresses used with the Amstrad CPC not the ZX Spectrum.

Looking at the provided source code for the ZX Spectrum, it appears to be using IO instructions (OUT, IN) using ports 31 ($1F), 63 ($3F), 95 ($5F), and 127 ($7F).

The schematic shows that /IORQ from the PIO is connected to /IORQ from the Z80 via a SPDT switch which allows selection between Z80 /IORQ and fixed pulled HIGH. This allows the PIO to be inhibited by stopping it responding to /IORQ.

The interrupt control lines for the PIO are not used. INT and IEO are not connected and IEI is pulled HIGH. The hand-shake signals (ARDY, ASTB, BRDY, BSTB) are not used either.

ZX Spectrum PDS Interface

The ZX Spectrum side of the PDS interface has the following:

• PIO PORT A – goes via the 74LS245 octal buffer to the 8 data lines of the PDS link.
• PIO PORT B – goes via the 74LS04 for certain control signals from the PDS link, and the direction control for the 74LS245.
  • Bit 0 – Pin 2 of the PDS interface
  • Bit 1-4 – not used
  • Bit 5 – Pin 7 of the PDS interface
  • Bit 6 – 245 direction control
  • Bit 7 – Pin 5 of the PDS interface

Note that half the PDS control signals are not used for the Spectrum interface. From the previous discussion we can interpret bits 2 and 7 to be the two clock/ack signals. Bit 5’s use is currently unknown. I’ll have to go to the code to see what is going on there.

ZX Spectrum PDS Monitor

I’ve not been able to find any source code for the PC side of things, some assembler has been issued for the target machines, which can be assembled into the run-time PDS monitor for that system.

The PDS Manual does have this to say:

“The software is designed to be machine independent, so the same protocols can be
used regardless of the target machines processor or make. All the communication is basically
the same, there are four major routines, SEND BYTE, GET BYTE and two direction
swapping routines.”

There are three versions of the monitor code for the ZX Spectrum:

• DL0 – the most minimal implementation, providing assembling and downloading only.
• DL1 – the long downloader, providing support for everything apart from the “analyze” command, which requires interrupts.
• DL2 – the full interrupt driven downloader.

The PDS manual contains some information about the ZX Spectrum downloader. Section 6.2 details the three versions of the code and then goes on to describe the available commands.

To get a feel for how the monitor functions, and some insights into how the hardware works, I’m looking at some extracts of DL0.

Code initialisation

START DI
      LD A,255
      OUT (127),A ; $7F=CB=$FF Mode 3
      OUT (63),A  ; $3F=DB=$FF PORT B=$FF (B0-7=HIGH)
      LD A,63
      OUT (127),A ; $7F=CB=$3F B6/B7=OUTPUT B0-B5=INPUT
      LD A,255
      OUT (95),A  ; $5F=CA=$FF Mode 3
      OUT (95),A  ; $5F=CA=$FF A0-A7=INPUT

CTRL = $FF means all bits of the control register are set. The Z8020 datasheet lists the control register as follows:

Where M1/M0 signify which of the four modes is to be used. In this case both PORTs are set to Mode 3, which allows for either IN or OUT on a per bit basis. I am guessing the writing of $FF to DB (PORT B DATA) happens to ensure that when then ports are configured as 2 OUT and 6 IN, the OUT lines are already HIGH, giving a known starting point.

Note: Setting B6 to HIGH means that the direction control for the 74LS245 will be LOW as it goes through an inverter. This sets the 74LS245 to work in the direction “B to A” which would correspond to when PORT A is set to all INPUTs later in the code.

GETBYTE

This is the lowest level function and it retrieves a single byte of data from over the PDS interface. This is used during the main protocol handling to both obtain commands over PDS and then receive data.

The essential function is as follows:

• Ensure PORT A setup for INPUT
• WAIT for a change in the PC->TARGET CLOCK
• Read the data from PORT A
• WRITE the TARGET->PC CLOCK/ACK
• Toggle the two CLOCK signals ready for next time
• Return

;On first entry D=64=b0100 0000
GETBYTE IN A,(63)  ;Read DB - control values
        XOR D      ;Toggle FLAGS
        RRCA       ;Pushes B0->Carry
        JC GETBYTE ;Wait for B0 to have changed
        IN A,(31)  ;Read data from DA
        LD E,A     ;And store in E
        LD A,D     ;Reload FLAGS
        OUT (63),A ;And write them out ie write B7
        XOR 129    ;Toggle B0+B7 (129, $81) for next time
        LD D,A     ;And store back in D
        RET

So I think the key features for this are:

• Control FLAGS are stored in the D register. Only B0, B6, B7 are significant. B0 is what we’re looking for on reception; B7 is what we will send in acknowledgement; B6 is the DIRection and is preset to INPUT for this.
• FLAGS are initialised to 64 i.e. B0=B7=0; B6=1.
• Every pass through the GETBYTE function toggles B0 and B7 between b0xxxxxx0 and b1xxxxxx1.
• Read data is stored in the E register.
• RRCA is used to take the read in control value and shift B0 into the carry flag so it can be checked with JC (JP C).
• Nothing else in the code works with the D register so it will always reflect the required status of the required PORT B CTRL word flags.

So this shows how the flags change through several passes of the function:

D=64               D=0100 0000 ($40)
CALL GETBYTE       D=1100 0001 ($C1)
CALL GETBYTE       D=0100 0000 ($40)
CALL GETBYTE       D=1100 0001 ($C1)

The PDS Manual describes the protocol as follows:

“Note that the protocol does not set the control lines directly, but toggles the lines to
communicate. All the protocols are designed so one computer can never get ahead of the
other, even if there is a big speed difference. There are no error checking protocols, as the
interfaces are very reliable, and error checking will slow down processes, and no real action
can be taken, even if an error was detected.”

Main Loop

The main loop essentially reads a byte from the interface and treats it as a control command. It will keep doing this until it finds a command it can process.

MAINLOOP CALL GETBYTE ;Get 'command byte'
         LD A,E
         CP 180	      ;Download code into aabb, len=ccdd
         JZ DLOAD
         CP 183       ;Select bank aa
         JZ SBANK
         CP 181       ;Execute code from aabb?
         JNZ MAINLOOP ;Not recognised - keep looping.

The comments are the original comments. There is a not a function for command 181, as this relies on “fall through”. It is the next function in the code.

The commands have values 180-187 as follows:

• 180: Download code
• 181: Jump to an address
• 182: Upload memory
• 183: Select bank
• 184: Send all registers to the main computer
• 185: Get registers from the main computer
• 186: Trace code buffer
• 187: Return analyze address

The various functions and message protocol layer are described in the PDS manual, so I won’t go into them in detail here, but by way of example, here is the description for 181:

The corresponding code is as follows:

;
; Function 181, Execute code from aabb
;
        CALL GETBYTE
        LD H,E  ;Get address of routine
        CALL GETBYTE
        LD L,E
        LD BC,MAINLOOP
        PUSH BC ;Put return address on stack and jump to routine
        JP (HL)

It is interesting to note that in the PDS manual, some commands appear to start with a padding byte (179). Apparently this is to ensure that all command messages are an even number of bytes long.

Any variable length commands (e.g. download) include an expected length field.

To retrieve data from the target, the protocol has the concept of “reverse ports”. After receiving upload command, ports are reversed to allow the sending of the appropriate amount of data before being reversed once again to restore the original direction ready for the next command.

Uploading is not supported in the simple D0 downloader. That requires the more complete D1 or D2 implementations. I’ve not gone into more detail here.

Conclusion

I’m going to leave this here for now. I think I’ve got a reasonable grasp of what is going on and I’d like to see if I can recreate the interfaces used at some point.

The ZX Spectrum one should be relatively straight forward. To do something with the PC end though is going to require a lot of work as I just don’t believe I can rely on that schematic.

I have to question though whether it would be worth it though. Given that an Intel 8255 is no longer available I’ll be using reclaimed parts and I also don’t have a PC with ISA anymore. I must admit I am wondering if an alternative PC end would be possible using a microcontroller to implement the PDS protocol and connect to the PC over USB (for example).

In fact, with something like a Raspberry Pi Pico, it would be quite possible to implement the entire target interface through to emulating the Z80 PIO on the ZX Spectrum board and potentially have a replacement system that is “USB direct to Spectrum”.

At this point of course, this is not really the PDS anymore and I’m sure there are already many modern alternatives to getting code running on a ZX Spectrum from a modern system, so that too might be a little pointless. And that is before we get into emulation.

But for its time, this is a really interesting system and it is a shame that information about it seems to have slowly disappeared.

I am still quite keen to recreate it though, so I might be on the look out for an old PC with ISA…

Oh, and as always, if you know about the PDS and are able to confirm or refute anything I’ve said here, do let me know in the comments!

Kevin

And in the second mystery AT box I find this!

#isa #retropc #oddhardware #singular #intel8255 #nec8255