POC Computer Version One

[BigDumbDinosaur]

enso wrote:

Congratulations. That's a success for 1.1!

Well, mostly it means that the hardware is not misbehaving. There's no "real" operating system at this point, just the BIOS ROM firmware and the M/L monitor. Up-time counts are generated in the interrupt service routine, with jiffy IRQs being triggered by the watchdog timer at 10 msec intervals. I do have a job that starts at eight hour intervals and does some SCSI I/O, that job being triggered by a interrupt-driven alarm. All I/O is also interrupt-driven, so at least I know the IRQ handler is working okay.

Practically speaking, POC V1 has fulfilled its purpose, which was to develop and debug the BIOS and M/L monitor, as well as develop a SCSI I/O subsystem. POC V2, when built, will be the focus of operating system development, as this unit will have sufficient hardware resources to support preemptive multitasking, especially since I made a recent acquisition.

[BigDumbDinosaur]

BigDumbDinosaur wrote:

enso wrote:

Congratulations. That's a success for 1.1!

Well, mostly it means that the hardware is not misbehaving. There's no "real" operating system at this point, just the BIOS ROM firmware and the M/L monitor. Up-time counts are generated in the interrupt service routine, with jiffy IRQs being triggered by the watchdog timer at 10 msec intervals. I do have a job that starts at eight hour intervals and does some SCSI I/O, that job being triggered by a interrupt-driven alarm. All I/O is also interrupt-driven, so at least I know the IRQ handler is working okay.

Practically speaking, POC V1 has fulfilled its purpose, which was to develop and debug the BIOS and M/L monitor, as well as develop a SCSI I/O subsystem. POC V2, when built, will be the focus of operating system development, as this unit will have sufficient hardware resources to support preemptive multitasking, especially since I made a recent acquisition.

Aww! An extended power failure resulted in me having to shut down every nonessential piece of computer hardware in my office to preserve the battery in the UPS and keep the mail server on line. POC V1.1 had run for nearly 80 uninterrupted days without a hitch. Oh well!

[BigDumbDinosaur]

Unfortunately, my health woes have slowed me down again and the planned break from homebrew computing that I was going to take so I could get some work done on my large-scale model locomotive won't happen until I get better (again). So I have turned my attention back to POC.

Something I have been thinking about is how to implement disconnect/reconnect (aka reselection) in the SCSI driver. Reselection is an optional step in a SCSI transaction that accounts for the fact the target device is very slow from the perception of the microprocessor (even an ultra-320 SCSI disk is, in some ways, a snail compared to the 65C816 running at 20 MHz). If reselection is implemented, a SCSI transaction that will result in the MPU having to wait for the target to complete a command can be temporarily suspended so the MPU can attend to other work while the SCSI device is busy. For example, if it is necessary to read a block of data from the tape drive the tape has to be positioned to the right location before any data transfer can occur. It's patent that winding the tape takes time, time that the MPU could use to get something else done.

If during the SCSI protocol steps where the tape drive is selected the drive is told that the host machine supports reselection, the tape drive will disconnect from the SCSI bus while it is winding the tape, an event that will cause a "disconnect" IRQ in the host, signalling to the MPU that it can divert its attention to another task. During this time, the SCSI bus will be quiescent and an entirely different SCSI transaction with a different device could be started (which is a not-uncommon occurrence in a busy operating system). Later on, when the tape drive has positioned the tape and read the desired data block into its buffer, it will check the bus for activity and if the bus is quiescent, reselect the host and identify itself so the suspended transaction can be resumed.

Reselection can also work with a hard drive, as relative to the MPU's perception, considerable time will pass when the heads have to be moved from one cylinder to another. Also, some latency is likely waiting for the desired data block to spin around to the heads after they reach the correct cylinder. It only amounts to a few milliseconds. However, an '816 running at 20 MHz could execute tens of thousands of instructions during that time. So one can see that reselection could improve system throughput when SCSI I/O is in progress.

Although there are a number of SCSI commands that can be time-consuming, the two where reselection would be most likely to occur are read and write operations. Implied is the need for the SCSI driver to maintain state information related to each pending transaction so it knows where to resume when reselection occurs. Since the eight bit "narrow" bus can support up to seven devices (the eighth device is the host adapter) potentially seven sets of state information would have to be stored somewhere. The data tables into which this information would be stored would be organized by SCSI ID so the correct driver state can be re-established following reselection.

It should be noted that disconnect/reconnect is of no value unless the operating environment supports concurrent task execution (aka preemptive multitasking). Hence adding reselection to the SCSI driver in the POC's BIOS would be pointless. If the BIOS retains control following reset (because no operating system can be loaded) then the machine will be idling in the M/L monitor's input subroutine waiting input, and that's all that will be happening (other than jiffy IRQ servicing).

On the other hand, in a multitasking kernel the SCSI driver would have to include extra features that would save the driver transaction state for later when the target reconnects, as well as arrange for the kernel to perform a context switch and execute the next task that is ready to run. Later on when reselection occurs, the SCSI IRQ handler would have arrange for context to change back to the SCSI driver, which would then resume where it left off.

As this is more than a little complicated it will take some planning, and probably some flowcharting to assure that all possible conditions are accounted for in the code. A precursor to actually developing a driver that supports reselection is developing code to simulate a multitasking kernel on POC so the testing environment mimics a real operating system. I can see that the assembler (and possibly the reset button) will be getting a good workout as I put this together.

[BigDumbDinosaur]

Following the restart on November 26, 2012 due to extended power failure, POC V1.1 has been running continuously and just passed 100 days of uptime without a reset. This extended run period demonstrates that the system is stable. That's more than I can say for my Windows PC.

[BigDumbDinosaur]

A goal of the POC design has been to eliminate having to use a dumb terminal as the POC's console and arrange for the console hardware to be part of the design, requiring only a keyboard and monitor. In the past I had looked at several ways of doing so but set them aside for various reasons, mostly due to missing features (e.g., a hardware-generated cursor).

I've decided that I should be able to adapt one of these to POC and in fact, can patch it to the old POC V1.0 unit for basic testing by wiring it into the MAX-238's socket, effectively disconnecting the console port from the circuit and making the MicroVGA adapter the console (the MAX-238 on POC V1.1 is an SOIC device, so adaptation would be more difficult). All that would be required to complete the change would be a PS/2 style keyboard and a VGA monitor with an analog input, items that I already have here. The MicroVGA hardware interface is a TTL-level TIA-232 arrangment, using either XON/XOFF or hardware handshaking (the latter being the better arrangement). Hence I can wire it to channel-A of the 2692 DUART and drive it at 115.2 Kbps for best performance. There is a built-in setup utility to configure the device outside of a working system.

From a programming perspective, the MicroVGA more-or-less looks like an MS-DOS console running the ANSI.SYS device driver (Hey, Garth! Remember that?), which means it understands attribute changes and other elements of the DOS text screen. Several character sets are available, which means box graphics can also be printed, along with some of those funny-looking DOS characters. The unit defaults to DOS code page 437, which anyone in Canada, the UK or the USA will immediately recognize. The ANSI color change sequences are supported as well, allowing for a 16-color display (certainly more than adequate for a console), as well as cursor control, region clearing, etc. The only signficant control feature that is missing is support for the ASCII <BEL> character, as there is no audio built in.

All-in-all, the MicroVGA seems to be a flexible display unit that ought to work. We'll soon know.

[ElEctric_EyE]

That's pretty good resolution, but it seems geared towards text only. 115Kbps is more than adequate for a terminal.

[BigDumbDinosaur]

ElEctric_EyE wrote:

That's pretty good resolution, but it seems geared towards text only.

It's meant to be a console I/O device, so there isn't any need for a graphics mode.

[clockpulse]

BigDumbDinosaur wrote:

All-in-all, the MicroVGA seems to be a flexible display unit that ought to work. We'll soon know.

It does look good, it will be interesting to hear how it works out.

[BigDumbDinosaur]

clockpulse wrote:

BigDumbDinosaur wrote:

All-in-all, the MicroVGA seems to be a flexible display unit that ought to work. We'll soon know.

It does look good, it will be interesting to hear how it works out.

I've been notified that the MicroVGA has shipped, so I hope to see it soon. When it arrives and I've verified that it's functional I'll start working out the interface details, which will mostly be a little blue wire here and there. I'll have to generate a new terminal driver table for the BIOS, since the present BIOS is set up to drive a WYSE 60. The MicroVGA uses ANSI-ECMA escape sequences (with which I'm familiar) vs. WYSE's vendor-unique and widely imitated sequences. Also, the MicroVGA has a little less functionality than the 60, but that shouldn't be an impediment to getting everything to work. If it proves out then I will revise POC V2's design to integrate the MicroVGA into the hardware and rework the PCB layout so the MicroVGA PCB can be adapted.

[BigDumbDinosaur]

BigDumbDinosaur wrote:

I've been notified that the MicroVGA has shipped, so I hope to see it soon.

I did receive it a while ago but have not had time to fool with it. I hope to get to it soon.

[BigDumbDinosaur]

POC V1.1 continues to sit on my desk, executing WAIs and such and being a good boy. Current uptime is more than 130 days. Sure wish Microsoft Windows was this stable.

POC V1.1 embodies just about all of the circuitry of POC V1.0, including hardware patches applied to fix the address bus woes mentioned many pages back. I devised an improved address bus qualification circuit and a different method of generating separate /RD and /WD signals from the MPU's RWB output, /RD and /WD being required by the I/O silicon. There are also circuits to expose more I/O addresses for SCSI operation (three of them).

Attached are some pictures of what the unit currently looks like:

The above is POC V1.1 minus the SCSI host adapter. Its physical layout is almost identical to V1.0, except for the use of an SOIC package for the MAX-238 transceiver (left end of unit) and repositioning of the NMI and RESET inputs to the right end of the board. The TO-92 packages to the immediate right of the 65C816 are Dallas (Maxim) 1813 reset generators. One is attached to /RESET and the other to /NMI, the latter available so when I commit a bone-headed coding goof and make the MPU start chasing its tail I can recover control (most of the time). The DS-1813 is perfect as a slow push button debouncer. I can use almost anything to short out the NMI jumper block—usually a paper clip—and not get multiple NMIs. Ditto for the RESET block.

The above picture is POC V1.1 with the DMA-capable SCSI host adapter installed. When I figured out how to use the 'C94's DMA channel, I had to rework the host adapter circuit so DMA status could appear on the data bus when the 65C816 read that part of the I/O block. The chip at the bottom of the host adapter PCB is a 74ABT541 bus driver whose sole purpose is to bring D7 high when the MPU queries the 'C94 and the latter says it is ready for a DMA transaction (the "ready" status is easily tested with a BIT instruction). I used the 74ABT541 because I happened to have one in the "slightly used" parts bin. This is clearly a gross waste of silicon, but the circuit works quite well—a transfer of 64 blocks (32 KB) from disk occurs at the rate of about 500KB per second. Even single block transfers are very fast: the activity LED on the disk barely flashes during the transfer, it's that quick.

The above picture is a side-view of the unit, which shows how the host adapter makes its connections to the mainboard. You can also see a patch on the underside of the mainboard, which I'll explain below. This is an example of taking the MPU's buses off-board, which increases loading and thus restricts the maximum Ø2 clock rate to 10 MHz (there are no bus drivers). With the host adapter unplugged and the Dallas watchdog moved to the "expansion port" socket on the mainboard, the unit is rock-solid at 12.5 MHz and mostly-operable at 15 MHz.

The above picture is of the patch I made to enable SCSI quasi-DMA operation. Less than a week after I had reworked POC V1.0 into V1.1, I experienced a "eureka" moment and figured out how to use the 'C94's DMA channel by making the MPU pretend to be a DMA controller. There were two steps involving hardware to get this to work: a redesign of the host adapter so a DMA status output from the 'C94 (DMAREQ, which goes high when the device is ready for a DMA transaction) could be checked by the MPU, and extending another I/O output from the 74AC138 decoder to the host adapter to control the bus driver that provides that signal to the data bus. Unfortunately, I had already had PCBs made, had populated the first one and had determined that everything was working as it should. So even after building V1.1, I *still* had to apply blue wire to rig up the DMA polling circuit.

The next step is to figure out how to hook up my newly-acquired SeCons µVGA console device and switch over from a dumb terminal (a WYSE 60, which is nearly 20 years old) to a standard PS/2 keyboard and video monitor (I have an older Viewsonic 17 inch model that is gathering dust in the computer graveyard). The hardware hookup is not particularly difficult, as the µVGA module is small and uses TTL-level TIA-232 for communication at speeds up to 1.25 Mbps (really!). Data going to the screen is written to the module's RxD input and data coming from the keyboard is read off the module's TxD output. There are also handshaking lines, which are probably going to be required to achieve error-free performance at high transfer rates.

As part of this experiment, I will be using a 26C92 DUART in place of the 2692A, as the former can support a maximum speed of 230.4 Kbps (the 2692A maxes out at 115.2 Kbps). Also, the 26C92 has a deeper set of FIFOs, so interrupt servicing won't be as critical as it might otherwise seem. Now, running the interface at 230.4 Kbps may be somewhat ambitious, as CBAT at that speed means that the '816 will theoretically get hammered with about 46,000 IRQs per second. However, I can't type quite that fast, so the input side won't be suffering much. Some cycle counting suggests that assuming a full transmit buffer, the unit could reach at least 18,000-20,000 bytes per second on the output side. I'm guessing that the µVGA module can't sustain that transfer rate and will invoke flow control to avoid a buffer overrun. The 26C92 does flow control in hardware, and as experience in driving the much slower WYSE 60 has shown, is very trustworthy. I'm not really expecting much trouble with getting the hardware interface to the µVGA module (famous last words).

[BigDumbDinosaur]

BigDumbDinosaur wrote:

clockpulse wrote:

BigDumbDinosaur wrote:

All-in-all, the MicroVGA seems to be a flexible display unit that ought to work. We'll soon know.

It does look good, it will be interesting to hear how it works out.

I've been notified that the MicroVGA has shipped, so I hope to see it soon...

I finally had some time to try out this thing. Attached are some pictures I took of the display and the module itself.

SECONS µVGA Module

SECONS µVGA Module Setup Screen

SECONS µVGA Module Code Page 437 Character Set

SECONS µVGA Module Color Set

As you can see, it does generate a display, at least with an older (c. 2006) Viewsonic 17 inch video monitor. It would not sync the display with the Viewsonic 22 inch 16x9 LED monitor on our test bench, a monitor that is only about a year old—the display kept flickering. I didn't bother to try it with the 24 inch Viewsonic monitor on my desk, figuring it would have the same problem.

The display is reasonably sharp on the 17 inch monitor, which reports that the vertical sync frequency is 60.07 Hz and the resolution is 800x600. The keyboard functions okay, with the exception that I can't turn on NUMLOCK. There is no mention of any software command that can turn on NUMLOCK, so I don't know at this time if the numeric keypad will emit numerals.

If you carefully examine the first picture, you will note that the mini-DIN keyboard jack is too close to the DB-15 VGA jack, causing the keyboard and monitor plugs to interfere with each other. Didn't these guys check for this when they laid out the PCB? I sent them some E-mail asking them to contact me about this interference matter, as well as the other items I mentioned.

Next step will be to adapt it to POC V1.

[Klaus2m5]

BigDumbDinosaur wrote:

If you carefully examine the first picture, you will note that the mini-DIN keyboard jack is too close to the DB-15 VGA jack, causing the keyboard and monitor plugs to interfere with each other. Didn't these guys check for this when they laid out the PCB? I sent them some E-mail asking them to contact me about this interference matter, as well as the other items I mentioned.

Most native PS2 keyboard plugs would fit as they don't have such a wide handle. All have a handle but usually it extends only to give it a square like footprint in one direction not extending the footprint of the edges. On the other hand immagine a USB/PS2 adaptor from one of these convertible keyboards. They would never fit.

[BigDumbDinosaur]

Klaus2m5 wrote:

Most native PS2 keyboard plugs would fit as they don't have such a wide handle. All have a handle but usually it extends only to give it a square like footprint in one direction not extending the footprint of the edges. On the other hand immagine a USB/PS2 adaptor from one of these convertible keyboards. They would never fit.

We exclusively use Key Tronic keyboards around here with our servers and workstations, due to their ruggedness and generally good tactile feel. The Key Tronic PS/2 connector size complies with the ATX mechanical standard, as does the connector on a Logitech keyboard that I also have. The latter has the same sized connector as the Key Tronic—and of course, the same interference problem.

The PS/2 receptacle is jammed right up against the VGA receptacle, as is the TV out receptacle. I think the majority of keyboard connectors would interfere. SECONS was obviously trying to shrink the µVGA as much as possible (it's really small), but got carried away. It won't stop me from testing it but I would not use this product in anything that we would ever sell (we do machine control design, in which something like the µVGA could be useful).

[clockpulse]

BigDumbDinosaur wrote:

It would not sync the display with the Viewsonic 22 inch 16x9 LED monitor on our test bench, a monitor that is only about a year old—the display kept flickering. I didn't bother to try it with the 24 inch Viewsonic monitor on my desk, figuring it would have the same problem.

Images look good. Maybe something is going on with the horizontal sync.