POC Computer Version One

[BigDumbDinosaur]

I think some of you may be missing the point. I already have the parts needed to set up a SCSI subsystem. Why fool around with something else? As André pointed out, SCSI is very robust and works well with a lot of different hardware. As well as disks, I could attach a DVD or CD ROM, tape, etc. André got it to work with a wide disk, and that was without the benefit of an intelligent controller.

BTW, I had thought about doing SATA but when I found out I could get my hands on SCSI ASICs I set aside that idea for another time. My bus won't be a U320 interface or anything like it, but absolute performance isn't critical. Besides, this will give me the opportunity to fiddle with some more hardware.

Speaking of SATA, does anyone know of an SATA controller that might be adaptable to the 65xx bus?

[BigDumbDinosaur]

I started a new topic on my second-design POC.

[BigDumbDinosaur]

I'm still fiddling with POC V1 as I test some code concepts that will come in handy with the next version. In the process, I accidentally discovered that I can run the board at 12.5 MHz.

What happened was I had borrowed the unit's 20 MHz oscillator that generates the Ø2 clock for some other purpose. When I went to power up the unit I remembered that I had used the oscillator somewhere else. I thought I had grabbed the 20 MHz oscillator but it turned out I had gotten a 25 MHz one (the damned things all look alike unless under magnification). Since I had already plugged it in when I realized my mistake, I figured no harm in powering it up. The worst that could happen would be nothing.

Much to my amazement, the POC booted, went through the full RAM test and fell into the M/L monitor, just as it is supposed to do. After fooling around with it for a while, I concluded it was stable at the elevated clock rate. I really didn't think the unit would be able to run faster than 10 MHz, due to the 70 ns rating of the I/O hardware and EPROM, as well as the expected prop delays in the glue logic.

As you might expect, increasing the Ø2 clock rate by 50 percent had a noticeable effect on performance. A fill of RAM from $0100 to $CFFF (top of stack) was done in 290 ms, as compared to 440 ms with an 8 MHz clock. Hunting memory for a pattern took about 0.5 seconds to search the entire 52K usable address space.

Now I'm a bit excited about getting POC V2 built, since it should be able to run with a 20 MHz Ø2 clock, making it some 80 percent faster than my "overclocked" POC V1.

[kc5tja]

Yeah, but, where did you put the liquid cooling system and radiator block for it?

http://image.skycomp.com.au/products/gi ... hwiu02.jpg

This is cool news -- is this the first recorded incidence of running a discrete 65xx CPU at 25MHz?

[BigDumbDinosaur]

kc5tja wrote:

Yeah, but, where did you put the liquid cooling system and radiator block for it?

http://image.skycomp.com.au/products/gi ... hwiu02.jpg

The crazy things people will do to eke out a few more megahurts.

Quote:

This is cool news -- is this the first recorded incidence of running a discrete 65xx CPU at 25MHz?

You misread. The Ø2 clock is 12.5 MHz, as the oscillator output is run through a flop. Even if the '816 could be stable at 25 MHZ nothing else except the RAM would work at that speed. I'm hoping that with the use of a CPLD in POC V2 instead of 74ABT logic, I can max out the Ø2 clock at 20 MHz.

[ElEctric_EyE]

A few MHz increase seems nonlinear as far as speed doesn't it BDD? Even if it is linear, to see one's own code running so much faster is quite a reward to push further!

However, if you said you had reached higher speeds than my 6502 system, I would have to demand some sort of proof!

[BigDumbDinosaur]

ElEctric_EyE wrote:

A few MHz increase seems nonlinear as far as speed doesn't it BDD? Even if it is linear, to see one's own code running so much faster is quite a reward to push further!

And to think that it was accidental.

Quote:

However, if you said you had reached higher speeds than my 6502 system, I would have to demand some sort of proof!

POC V2 is going to shoot for 20 MHz. If it proves to be stable at that speed I may, like Donald Campbell, try bumping the clock just to see how fast it will go before it crashes.

[BigDumbDinosaur]

ElEctric_EyE wrote:

A few MHz increase seems nonlinear as far as speed doesn't it BDD? Even if it is linear, to see one's own code running so much faster is quite a reward to push further!

However, if you said you had reached higher speeds than my 6502 system, I would have to demand some sort of proof!

I've been monkeying with something else (non-computer), which uses a 30 MHz oscillator. Just for grins, I plugged the 30 MHz part into POC V1's clock generator socket, which produces an effective 15 MHz Ø2 clock. I really didn't expect anything at all to happen, as the resulting 67 ns cycle time is slightly under the ratings for the I/O hardware. However, the thing booted and seems to work okay. The IRQ-driven timekeeping is working as it should and terminal I/O appears to be normal. I guess both the Dallas watchdog and the NXP DUART are conservatively rated.

The increased clock rate over the 12.5 MHz Ø2 I've been running produces a small but perceptible performance improvement. As the time_t clock driven by the IRQ only has a resolution of 10 msec, I can't quantify the performance increase. But I can definitely see it. A fill of all RAM from $0100 to $CFFF happens too fast for a lag to be perceptible. Whooo-whee!

As soon as I have time to finalize the PCB layout for POC V2, I should be able to find out what 20 MHz operation feels like (except I/O—that will have to be wait-stated).

[BigDumbDinosaur]

[deleted]

[BigDumbDinosaur]

BigDumbDinosaur wrote:

I've been monkeying with something else (non-computer), which uses a 30 MHz oscillator. Just for grins, I plugged the 30 MHz part into POC V1's clock generator socket, which produces an effective 15 MHz Ø2 clock.

It's now February 16 and the POC V1 has been running on the 15 MHz Ø2 clock since I powered it on January 31. Everything is working fine, so I guess it could be called stable.

[fachat]

BigDumbDinosaur wrote:

I already have the parts needed to set up a SCSI subsystem. Why fool around with something else? As André pointed out, SCSI is very robust and works well with a lot of different hardware. As well as disks, I could attach a DVD or CD ROM, tape, etc. André got it to work with a wide disk, and that was without the benefit of an intelligent controller.

On a side note. In the meantime I found out that quite some USB devices (namely my USB memory stick, as well as a USB multi-card reader) actually fall into the category of "SCSI" devices as well. There is a whole USB class definition (class 8, subclass 6, protocol 0x50) for SCSI-over-USB devices. In this case USB is only used to transport the USB protocol over the wire. Haven't used it yet though, although I plan to.

André

Edit: my current state of affairs for the USB host driver: http://www.flickr.com/photos/afachat/5448843351/

[BigDumbDinosaur]

fachat wrote:

In the meantime I found out that quite some USB devices (namely my USB memory stick, as well as a USB multi-card reader) actually fall into the category of "SCSI" devices as well.

I can't say that surprises me. The SCSI protocol is very well engineered and extremely adaptable to a lot of different devices. I recall when high end scanners used SCSI. Also, at one time I had a printer with a SCSI interface. The interface went real fast, the printer real slow.

On another note, something I've been fiddling with is figuring out how to determine the approximate clock speed of a 65Cxx-based system strictly in software. To do so, a "calibration loop" is required that runs for a known number of clock cycles. If one can accurately measure the wall-clock time that elapses while the loop is looping, one can compute the speed of the MPU clock. Here's the calibration loop:

Code: Select all

;this code requires exactly 10,000,001 clocks
;to execute the loop bounded by L0000001
;
         *=$2000
         lda #$1f              ;MSB
         ldx #$04              ;LSB
         ldy #$6d
;
L0000001 dex
         bne L0000001
;
         dey
         bne L0000001
;
         nop
         dec a
         bne L0000001
;
         brk

Next step is to figure out how to accurately time this thing.

[BigDumbDinosaur]

As I mentioned in my POC V2 topic, I've concocted a way to add SCSI (specifically, single-ended SCSI-2) to my POC unit. POC V2 will include on-board SCSI, along with CPLD glue logic, but I though it best to do the SCSI development work within the realm of something that already functions and is stable. By adding SCSI to POC V1, I'm not faced with debugging a whole new design if something doesn't work right. Also, V1 has a fully functional M/L monitor and a Motorola S-record loader in ROM, so I can develop a driver on my UNIX box and then ship it to the POC unit for testing.

A while back, I acquired some 53C94 SCSI controllers, around which I've designed a plug-in host adapter. The 53C94 offloads all of the SCSI bus protocol steps from the host processor, greatly simplifying the circuit design, as well as the code required to drive the bus and talk to SCSI devices. The 53C94 requires little in the way of supporting silicon. The controller is capable of directly driving the SCSI bus, eliminating the need for line drivers, unless a high voltage differential bus is desired. A TTL or CMOS clock source running between 10 MHz and 25 MHz is required to generate the internal timing signals used by the 53C94's state machine. In theory, that clock could be derived from the Ø2 clock on the POC board. However, the configuration of several registers in the 53C94 is contingent on the clock rate, which I may change in the course of experimentation. I don't want to have to burn a new EPROM each time I fiddle with Ø2, so I'll use a separate clock generator (20 MHz, in this case) on the HA.

The 53C94 is capable of synchronous SCSI bus transfers at the rate of 10 MB/second. However, that mode of operation isn't practical with the 65C816 without a DMA controller. Synchronous operation increases throughput by not handshaking each byte on the bus, which implies that the host system must be able to read or write the bus at a rate greater than it can actually operate. As the 65C816 can't move data at SCSI-2's synchronous rate, an attempt to run in synchronous mode would likely result in data overrun during any of the data-in phases or an underrun in the target device during a data-out phase. Accordingly, I will run the bus asynchronously, which (in theory) can be done at very slow rates. For example, the Lt. Kernal subsystem for the C-128 ran at only 65 KB/second in FAST mode, a mere 2.6 percent of the base asynchronous rate supported by the SCSI-1 standard (2.5 MB/sec). My preliminary calculations suggest a maximum of 750KB/second with the '816 running at 20 MHz (not possible with POC V1). As loads and stores consume the bulk of the processing time, that rate will probably decrease almost in proportion to Ø2. Assuming this HA will function with the current Ø2 rate of 12.5 MHz, I might be able to achieve 450 KB/sec.

There is no expansion port on the POC, so I decided to use the Dallas watchdog timer's socket as a makeshift expansion port, as all but two of the signals required to control the 53C94 are already present. Several of the watchdog's socket positions are unused, so a simple patch to the POC board connects /IO-2 and RST (the missing signals) to the vacant pins. The host adapter itself mounts on three standoffs on the POC board and plugs into the watchdog's socket. The watchdog, in turn, plugs into a socket on the HA and (in theory) should be none the wiser about the change.

Owing to its intended use, the 53C94 will generate an interrupt each time the SCSI bus changes phase (the target device controls bus phases once arbitration and selection have occurred). Other events can also generate an IRQ, such as target device selection timeout. Most of the possible IRQ sources can't be disabled, which initially increases the difficulty of creating a basic driver. So I rigged up the host adapter so I can isolate the 53C94 IRQ output from the POC's IRQ circuit.

The finished driver will ultimately be a combination of foreground and interrupt-driven code. Each phase will have a code segment that fulfills whatever requirements are peculiar to that phase. There will also be segments to handle interrupts caused by events such as unexpected phase change, data transfer timeout, etc. In a general sense, the IRQ part will "dispatch" the main driver loop by changing the RTI address on the stack to point to the correct segment. This is where the 65C816's LDA n,S and STA n,S instructions will come in handy.

Anyhow, I've got the HA PCBs ordered and will post more as I progress.

SCSI-2 Host Adapter Schematic

SCSI-2 Host Adapter PCB Layout

NCR 53C94 SCSI Controller (PLCC84)

[ElEctric_EyE]

Can we still acquire these SCSI drives BDD? It would be a shame to put so much effort into writing code for a device that can't be used by anyone else...

[BigDumbDinosaur]

ElEctric_EyE wrote:

Can we still acquire these SCSI drives BDD? It would be a shame to put so much effort into writing code for a device that can't be used by anyone else...

To which SCSI drives are you referring? Narrow bus drives are no longer available (except used, maybe), but modern LVD drives can be readily adapted to the 8 bit bus. Also, all SCSI drives are all downward compatible with the older standards (going all the way back to SCSI-1 from 1986).