10

The NEC PC-8201 had three serial interface ports on the back, "RS-232," "SIO1" and "SIO2." These were all driven by a single IM6402 USART, switched between each physical port via bits 7 and 6 of IO port $90. Details are given in §3.1.8 (p. 3-10) of the NEC PC-8201 Service Manual (PDF).

This allowed a user to plug in multiple devices simultaneously and very quickly switch between them, quickly enough that a user might feel all devices were working at the same time, though of course actually only one device would be accessed at any particular instant. It saved on cost, took up fewer of the 256 I/O ports, and also saved considerable board space on a small machine (the IM6402 was a 40-pin chip).

What other 8-bit microcomputer systems used this technique, where a single controller (such as a UART) that cannot control more than one device at a time would be switched between different devices? (The devices may be on-board or external devices, and, if external, the switching logic may be onboard or in a separate "port expander" unit.) Ideal answers will include the user's view of how the ports were used, an explanation of why the designers implemented the system this way, it, a techincal description of the multiplexing scheme, and references.

Note that I'm not asking about external multi-device bus systems such as Atari SIO, but only systems that appeared to the user to have separate external ports where the devices did not share the external port with other devices connected at the same time. (Or, for internal muliplexing, where the device itself was not "aware" that was sharing a controller with other devices.)

8
  • 2
    I have my doubts that this was a robust setup worthy of copying. If your system has bounded i/o requirements, maybe. For example, 3 printers, almost always just listening. But if you had three 56k modems all trying to talk to you at once, they may not be able to buffer, waiting for the computer to get around to listening to them.
    – RichF
    Mar 7, 2020 at 5:13
  • 1
    @RichF Well, for a start there were no systems using 56K or even 24.4K modems during the 8-bit era; these weren't invented until the '90s. Nor do I think many users used multiple modems at the same time. The scheme described above is certainly more limited than, say, Atari SIO, but also requires less intelligence from devices (e.g., you can use a standard modem rather than one with an intelligent, buffering interface) and apparently was felt workable enough by NEC that they implemented it. If no other systems did, that would provide some information on the scheme's workability.
    – cjs
    Mar 7, 2020 at 6:14
  • 1
    I'm not sure if an analogue output counts for you, but the first version of the Tandy Radio Shack CoCo had one single DAC which was used for: Audio output, cassette output and the joystick input. Mar 8, 2020 at 17:06
  • 1
    @MartinRosenau That does count, and a post on the details of this would be a valuable answer.
    – cjs
    Mar 8, 2020 at 23:33
  • 1
    Oh, I thought of another potential answer. Any thoughts on: any machine with a WD177x and multiple disk drives? The WD doesn't have any native support for multiple drives, it's always external logic that switches between them, and clearly a disk drive is a serial input. But on the other hand, there's only a very limited sense in which the machine is making it look like it's running the multiple drives 'simultaneously'.
    – Tommy
    Mar 9, 2020 at 15:11

10 Answers 10

11

The Sinclair QL also had two RS232C ports which used an unusual combination of a ASIC (ZX8302) and Intel 8049 to provide two physical ports (with non standard connectors) but could not be used independently. The two ports were nominally for printer and modem use, but during development the built in modem of the QL was dropped, but the case retained the physical connectors.

“The one really bad bit of cost-cutting I did was trying to squeeze two serial ports out of one,” David Karlin concedes. “That was not a sensible thing to do, and we should have just said it had one serial port. It was only one serial port, so the two we claimed had to be multiplexed and that was seriously not a good idea" http://www.theregister.co.uk/AMP/2014/01/12/archaeologic_sinclair_ql/

https://web.archive.org/web/20060504000555/http://www.staff.uni-mainz.de/roklein/ql/Hardware

http://www.dilwyn.me.uk/gen/serial/serial.html

1
  • And it was in fact not a very robust serial port implementation. The two ports can only run on a common baud rate and started to suffer data loss at baud rates at or above 9600.
    – tofro
    Nov 1, 2021 at 22:13
4

The NES with its multitap accessory is a potential answer, if you'll accept some logic in the accessory.

NES controllers use a 1-bit serial protocol. The host strobes to begin a transfer, causing the joypad to load its current state into a shift register, and the host then clocks in 8 bits, each representing one of the 8 inputs. It's actually the CPU that does this, reading a single bit at a time, at whatever cadence that particular game's routine produces.

The official multitap, the Four Score, permits four controllers to be connected. The programmer now strobes, just as they always did, but the multitap has a little extra logic. Having supplied the strobe to all connected joypads, when reading it'll:

  • direct the first eight clocks to the first joypad;
  • the second eight to the third joypad;
  • use the third eight to provide the 8-bit value 0x10;
  • supply the fourth eight to the second joypad;
  • the fifth eight to the fourth joypad; and
  • finally, clock out the 8-bit value 0x20.

So it's providing four serial inputs to one serial controller, with physical port selection occurring in a fixed round robin.

2
  • Yes, logic in a separate "port expander" of some sort (in this case, the multitap accessory) is perfectly fine. (Obviously when multiplexing there needs to be some logic somewhere outside the controller being multiplexed to direct its I/O to different lines.) Great answer; thanks.
    – cjs
    Mar 9, 2020 at 2:36
  • I guess I've failed at 'microcomputer' though. Unless a slight stretch via Famicom BASIC works.
    – Tommy
    Mar 9, 2020 at 15:08
4

A second bite of the cherry: amongst others, the WD177x family are popular floppy controllers that were used in or with a variety of 8-bit machines including the MSX, the Acorn Electron and later models of the BBC Micro, the Oric and the TRS-80.

They are serial controllers because floppy drives provide a single data line, which the controller monitors for both timing and data in order to reassemble full bytes.

The controllers themselves have a single data input and no further selection logic, implying a single drive. However all of the machines I listed above support multiple drives. They do so through external electronics that selects which drive† is currently visible to the floppy controller.

They're therefore an example of a single serial port multipliexed to multiple physical connections.

† in practice, some of them technically allow multiple drives to be selected at once, but they'll just literally be wired together producing whatever electrical conditions result and inhibiting the controller's ability to read anything. So doing so is not desired behaviour.

3

The Commodore 64 used a single CIA for both the keyboard and joystick (or paddles).

This made reading both the keyboard and the joystick at the same time a bit of challenge, see this answer for details (complete with schematics).

As for an explanation of "why", I guess the answer is always "to save parts and make it cheaper".

2
  • Hm. Not quite what I was thinking of, since in the C64 the joysticks and keyboard are always connected simultaneously, rather than the CIA being switched between them, but it brings up a good point. (It's also ironic that you have to point me to my own answer to remind me of this. :-))
    – cjs
    Mar 7, 2020 at 8:54
  • I tried hard not to add a smiley - this being a serious Q&A site and all.
    – dirkt
    Mar 7, 2020 at 12:22
3

The Sinclair ZX81 had a single Uncommitted Logic Array (ULA) chip that controlled both the screen and the cassette port. Consequently, accessing the cassette (loading or saving) would cause stripes to appear on the screen.

It also controlled the keyboard, causing the screen to flicker at each keypress, but the keyboard was built-in and so it doesn't count as an external port for the purpose of this question.

1
  • Actually, multiplexing amongst internal devices should count, I think; I will tweak my question. Perhaps you can expand this answer a little to explain how the multiplexing in the ZX81 worked, and provide a link or two to detailed documentation?
    – cjs
    Mar 9, 2020 at 7:38
3

In the Commodore 16/116/Plus-4, the Cassette connector and the serial (floppy and printer) port are both implemented via the CPU's single built-in I/O port which can be accessed by code at addresses $0000/$0001 (the same port that is used for the bank switching logic in the C64). Most lines of the two interfaces use separate bits of that one 8-bit port, but one line is physically shared - Cassette Write Data Out and Serial Clock In.

Additionally, in the Plus/4 only, User Port data bit 2 is shared with the Cassette Sense line (which is used to determine if any key - though software cannot tell which one - on the tape recorder is currently pressed down).

In addition, there is the usual sharing of lines between the keyboard and joystick that, as far as I know, all Commodore 8-bit systems use.

2

The TRS CoCo might match your criteria:

It used one single D/A converter that was used for tape output, sound output and A/D conversion of joysticks (which is done by comparing the analogue value to the D/A value).

The four joystick potentiometers were multiplexed using an analogue multiplexer.

So you could only use one of tape output, sound output or input from one of the four joystick channels at the same time.

3
  • I'd like to have a closer look at how they did this, particularly how they did the multiplexing. Do you have any pointers to documentation on this? Even just a link to a schematic and an approximate grid reference for the circuit would be a great start.
    – cjs
    Nov 2, 2021 at 4:32
  • @cjs In the reference manual you'll find the schematics of the CoCo. On page 66 (73 of the PDF), top right, you find the D/A converter. One page later, bottom right, you find the joystick input. Nov 2, 2021 at 5:50
  • That's good info. I think it should be edited in to your answer rather than being banished to a comment.
    – cjs
    Nov 3, 2021 at 10:42
1

I think the canonical example from the 16-bit era is the two ports on the Macintosh provided by a single Zilog 8530 and able to be used for serial, printer, modem, and AppleTalk networking based on user configuration. Of course this was influenced by the modem and printer port on the 8-bit Apple //c, but those ports relied on 2 independent 6551 UARTs.

In order to actually answer the question, which stipulated a single controller chip on an 8-bit microcomputer system, I'd point out the Apple IIgs as a possible answer. It shared the single Zilog "Serial Communications Controller" ("SCC") architecture with the Classic Macintosh, while also being compatible with the two independent serial ports approach of the earlier Apple //c. The two ports on the Apple IIgs support AppleTalk, printers, modems, and other serial connections, in much the same manner as the Mac when used under GS/OS. When used in ProDOS 8, the two ports mimic the behavior of the Apple //c ports. It's quite flexible and a real testament to the power of Zilog's SCC compared to vanilla UART controllers.

From the Zilog Users' Manual:

  • Two independent full-duplex channels
  • Synchronous/Isosynchronous data rates up to 5 Mbits/sec
  • Asynchronous
  • Byte-oriented synchronous
  • SDLC/HDLC
  • Receiver FIFO

8530 block diagram

Since the SCC manages all the multiplexing internally, it is exceptionally easy to implement from a hardware standpoint. Naturally, the software has to fill in the gap of managing the added complexity of two channels and multiple operating modes. This software control was done quite well on the IIgs.

3
  • 1
    Can you describe the 8530 in a bit more detail? In particular, was the 8530 a single UART that was multiplexed amongst multiple physical serial ports, or was it two or more UARTs in the same package?
    – cjs
    Mar 8, 2020 at 2:15
  • My question was not about a single controller chip but a single controller. (Were it the former, any microcontroller or system synthesized on a single FPGA would qualitfy for all its I/O.) From your diagram above, and the product brief that says the 8030/8530 has "Two Independent, 0 to 4.1 Mbit/Second, FullDuplex Channels," this seems to be two separate UARTS on a single chip, not a single UART switched between two physical ports. (I will try to further clarify my question to make this clear.)
    – cjs
    Mar 8, 2020 at 23:42
  • @cjs Yeah. Of course, Zilog did call the 8530 an "SCC" for Serial Communications "Controller". So, I figured, who am I to argue with Zilog?
    – Brian H
    Mar 9, 2020 at 14:29
1

The Amstrad CPC range multiplexes 2 joysticks onto a single Atari style 9 pin port by the simple expedient of having two common lines, one for each joystick. This allows each joystick to register 7 inputs, being 4 directions and up to 3 buttons.

Typically, the first joystick would include circuitry for an additional socket, into which a second joystick could be chained. The AY chip in the computer can switch between the two common lines to read which lines are pulled to 0V in each joystick.

0

The Commodore SID chip has two paddle inputs; the C64 can support four paddles by multiplexing between the paddle ports on the first joyport and those on the second. See https://archive.org/details/C64-C64C_Service_Manual_1992-03_Commodore/page/n15/mode/1up for more information [link courtesy cjs].

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .