Re: DEC OSF/1 for i386?

[Guy Sotomayor via cctech]

I was at IBM when OSF (and subsequently OSF/1) was created and had a lot 
of discussions with OSF at that time.  At IBM I was working on the IBM 
Microkernel.  OSF/1 also used Mach (but a different source base) as the 
kernel.  The big effort was to keep the APIs and documentation 
"similar".  We had huge arguments about RPC and I think that's the area 
that we didn't converge which I think made the whole thing pointless 
since the IPC/RPC was one of the main points of Mach.  :-/


I don't know what DEC did in terms of their OSF/1 product, but I know at 
IBM we had 2 principle "ports" that we maintained (PPC & x86) as well as 
a few others (MIPS, StrongARM, 68K being the other ones as I recall) 
that we "kept alive".


TTFN - Guy

On 4/29/22 07:45, Dennis Grevenstein via cctech wrote:

Hi,

just recently I found this archive:

https://vetusware.com/download/OSF1%20Source%20Code%201.10/?id=11574

this is a package of source code for DEC OSF/1 V 1.0. I knew that this is
supposed to run on DECstations (with MIPS), in fact I have a DS3100
running it myself.
However, one thing really puzzled me: This archive apparently includes
support for i386. There is even a kernel build log from 1990.
Now that was news to me. I never realized that this worked on i386.
Can anybody here tell any stories about this?

regards,
Dennis


--
TTFN - Guy

Re: idea for a universal disk interface

[Guy Sotomayor via cctech]

I'm using Zynq SOMs (System on a module) that will plug into a "base 
board" (with hilrose connectors).  It is the base board that will have 
the "personality" of the emulator.  The baseboard will be fairly simple 
(level shifters, a small bit of logic and the drive interface 
transceivers).  So the base board is fairly simple (I think I have an 
early version in KiCAD...but it needs updating).


I'm trying to use as much as I can from the free libraries so I'm trying 
to keep stuff as simple as possible from a logic design perspective.  
Since I already have everything (in multiples) except for the base 
board, the cost to me is time at this point (which I don't have a lot of 
at the moment).


I also didn't want to get into doing any design with BGAs (at least 
where I need to worry about it) hence the decision to go with SOMs.  
With those, the SOM has the Zynq FPGA, flash, DRAM, etc (including the 
critical VRs and clocks).  All I need to provide is 3.3v.  ;-)


I should be able to dig up the docs.  Many are already on bitsavers.  
Let me know what you can't find on Bitsavers.


TTFN - Guy

On 4/20/22 11:22, shad via cctech wrote:

Guy,
I agree that accessing data in blockram (synchronous with fixed latency) is 
really easier than accessing it from RAM (asynchronous with variable latency).
Anyway I'm weighting the "cost" of additional complexity, which in change would 
allow to spare on Zynq cost.
In any case memory access is never sequential, but a sequence of bursts with 
shorter length (16 beats or less).
Considering this, the fact of starting or ending a sequential transfer is just 
a matter of generating addresses multiple of burst length. For this however you 
have to forget about Xilinx's free IP cores, and work directly with AXI3 bus of 
HP ports.

As I would have to invest a large amount of time and of money, it would be nice 
to have somebody interested in buying a working and assembled kit with moderate 
price gain, in way to repay part of the investment.
This however drives to bottom end FPGAs, with very limited amount of internal 
memory... whence the memory-spare design.

About documentation: you mentioned several documents about SMD/ESDI standards 
and related details.
Would you mind sharing this collection?

Many thanks.

Andrea


--
TTFN - Guy

Re: idea for a universal disk interface

[Guy Sotomayor via cctech]

I have proceeded as far as full block diagrams (still have to write all 
of the verilog) and basic SW architecture.  This is why I've had this 
discussion.  I've thought about this *a lot* and have gone through 
several iterations of what will or will not work given timing constraints.


I have all of the components for putting a prototype together but I just 
haven't had the time yet to write the verilog, the Linux device driver 
and the "personality board".  That is, there is still a lot to do.  ;-)


Some requirements that I've put on my design:

 * straight forward SW architecture
 * SW is *not* time critical (that is I didn't want SW in the critical
   path of keeping the data stream)
 * Must be able to emulate any SMD/ESDI drive
 * Must be able to match performance of the drive (or better)
 * Must be able to work with any controller (ESDI or SMD...depending
   upon interface)

With those in mind, that's how I came up with my design.

I found that the Zynq has sufficient Block RAM to contain a full 
cylinder of 512KB.  I'm keeping a full cylinder because that allows 
everything to be done in verilog except for seeks (see SW not being 
required to be in the critical path).  If I didn't do that, then SW 
would have to be involved in some aspects of head switch, etc and those 
can have tight (<< 100us) latencies and I just didn't want to try and 
get Linux to handle that.  Yes, I could use some form of RTOS (I'm 
actually in the middle of writing one...but that's still a ways away) 
but I don't see any that are really up to what I need/want to do for 
this project.


BTW, I'm basing my initial implementation on the Zynq 7020 which has 1GB 
of DRAM.  However, I'm also planning on a "bigger/better" one based upon 
the Zynq Ultrascale+ which has 4GB of DRAM so that I can support 
multiple/larger drives.


The amount required by Linux doesn't have to be large...I plan on having 
the KMD just allocate a really big buffer (e.g. sufficient for 
containing the entire drive image).  Linux will run happily in 
128MB-256MB since there won't be any GUI.  It could be significantly 
less if I were to strip out everything that isn't needed by the kernel 
and only have a basic shell for booting/debug.  My plan is to have the 
emulated drive data and the configuration file on the SD card...so 
there's no real user interaction necessary (and Linux would not be on 
the SD card but on the embedded flash on the Zynq module).


TTFN - Guy

On 4/17/22 10:28, shad via cctech wrote:

hello,
there's much discussion about the right  method to transfer data in and out.
Of course there are several methods, the right one must be carefully chosen 
after some review of all the disk interfaces that must be supported. The idea 
of having a copy of the whole disk in RAM is OK, assuming that a maximum size 
of around 512MB is required, as the RAM is also needed for the OS, and for Zynq 
maximum is 1GB.
About logic implementation, we know that the device must be able to work with 
one cylinder at a time. Given RAM bandwidth, this doesn't means that it must 
fit completely in blockram, also it can be produced at output while it is read, 
so delay time is really the time between first data request and actual read 
response. In between an elastic FIFO is required to adapt synchronous constant 
rate transfer of the disk to the burst transfer toward RAM.

Guy, you mentioned about development of a similar interface.
So you already produced some working hardware?

Andrea


--
TTFN - Guy

Re: idea for a universal disk interface

[Guy Sotomayor via cctech]

I think the issue is that you're thinking of somehow emulating the 
formatted data.  I'm working on just emulating the bit-stream as then 
it'll work with any controller and sector/track layout so I won't 
actually know what a sector really is (unless I do "hard sectoring" 
which some drives did support).


At a 15Mhz clock rate, 30 bytes is 1.us.  Not a lot of time. And 
frankly, that's defined by the controller and not the drive (though 
usually the drives specify some layout but that's only a 
recommendation).  Dealing with drive speed variations doesn't solve 
anything because it's actually done via the drive itself (e.g. the drive 
provides the clock to the controller so any variation is already 
accounted for).  The drive really cares about total bits (e.g. 
bits-per-inch) that the media supports.


If we assume 32KB track at 500MB/s DMA transfer rate, that takes 65us.  
But as I've said, the spec says that the time between a head select and 
read is 15us or so, you can see that you can't just transfer a track and 
still meet the minimum timings.  I will agree that you can probably take 
longer but I'm trying to have a design that can meet all of the minimum 
timings so I can emulate any drive/controller combination with at least 
the same performance as a real drive (and in many cases I can provide 
*much* higher performance).


By keeping a full cylinder in the FPGA Block RAM I can keep the head 
select time < 1us (it's basically just selecting the high order address 
bits going to the block RAM).


By keeping the entire disk image in DRAM, I can emulate any drive (that 
fits in the DRAM) with identical (or faster) performance. If I wanted to 
do something simpler (not much though) I could have a smaller DRAM (but 
since the Zynq modules I'm using have 1GB or 4GB of DRAM there isn't 
much motivation) but then any seek would be limited by access to the 
backing store.  Also remember, in the worst case you have to write the 
previous track out if it was written to so that will slow things down as 
well.  With the full image maintained in DRAM, any writes can be 
performed in a lazy manner in the background so that won't impact the 
performance of the emulated drive.


TTFN - Guy

On 4/16/22 14:32, Tom Gardner wrote:

-Original Message-
From: Guy Sotomayor [mailto:g...@shiresoft.com]
Sent: Friday, April 15, 2022 3:25 PM
To: t.gard...@computer.org; cctech@classiccmp.org
Subject: Re: idea for a universal disk interface

I'm looking at what the spec says.  ;-)  The read command delay from the head 
set command is 15us (so I was wrong) but still not a lot of time (that is after 
a head set, a read command must be at least 15us later).



-
And after the read command is given there is a gap, usually all zeros, at the 
end of which is a sync byte which is then followed by the first good data (or 
header) byte.  In SMD the gaps can be  20 or 30 bytes long so there is quite a 
bit of time until good data.

Tom



--
TTFN - Guy

Re: idea for a universal disk interface

[Guy Sotomayor via cctech]

I'm looking at what the spec says.  ;-)  The read command delay from the 
head set command is 15us (so I was wrong) but still not a lot of time 
(that is after a head set, a read command must be at least 15us later).


Since I'm not looking at formatted data rate (just handling the raw bit 
stream) it doesn't really matter what the formatted rate is...and the 
formatted data is different between different controllers, so I don't 
want to even try to do that on the fly (and they might do tricks where 
different tracks/cylinders have different formats.


If some one wants the "formatted" data, then I'd let them post process 
that off the captured data.


As I said, I'm trying to do this with fairly simple logic and low cost 
storage (as such this isn't going to particularly cheap).  I don't want 
to add another $100+ to the cost just to have a high performance drive 
when the HW is capable of doing a suitable job with a $10 SD card.


In reality an SD card (from a storage perspective) is way overkill.  
We're talking about emulating drives with capacities < 1GB and good 
quality SD cards contain 32GB for $10 or so.


TTFN - Guy

On 4/15/22 12:12, Tom Gardner wrote:


I haven't looked it up but I bet the head switch time is a lot longer 
than 1-2 usec - that's what the leading gap is for and the sync took 
most of the gap back in those days.


The issue is sustained data rate isn't it?  The ESMD raw data rate is 
24 Mb/s but the formatted data is something like 80% of that or maybe 
2.5 MB/sec.  A modern HDD in sequential mode can sustain a much higher 
rate, e.g. Seagate SAS 
 
at 520 MB/sec.  My understanding is that the sectors are slipped 
and/or cylinders are horizontal so that head switching doesn't lose 
any revolutions.  Maybe one would run into a problem at the cylinder 
seek moment so maybe one would have to keep each full emulated 
cylinder on the modern drive’s cylinder, but with Terabytes of data on 
a modern drive who cares about some wasted storage


Tom

-Original Message-
From: Guy Sotomayor [mailto:g...@shiresoft.com]
Sent: Friday, April 15, 2022 10:56 AM
To: t.gard...@computer.org; cctech@classiccmp.org
Subject: Re: idea for a universal disk interface

I ran the numbers for Zynq FPGAs.  First of all for ESDI and SMD the 
head switch time is 1-2us (basically the time it takes for the clocks 
to re-lock on the new data).


Two tracks isn't sufficient (which is the "other" track...you will be 
wrong).


So I decided to go and have a full cylinder (I'm allowing for up to 
32KB tracks and up to 16 heads) which is 512KB.  The Zynq DMA from HW 
block RAM to DRAM (at 500MB/s) is ~1ms.  Given that the previous 
cylinder could be dirty (e.g. has written data), the worst case seek 
time is ~2ms.  This allows me to emulate any seek latency curve(s) I want.


In my design, any dirty data is written back to storage in a lazy 
manner so the performance of the storage isn't really an issue.


I should note that the Zynq 7020 module has 1GB of DRAM on it, so 
there is no additional cost to just put the entire disk contents in 
DRAM and I'm using the attached SD Card interface for storage (so you 
can use a


$10 SD Card for storage).  Adding a high speed disk interface (e.g.

MD.2, PCIe, or other serially attached storage) would add additional 
cost in terms of having to create the interface as well as a 
reasonably fast drive and I don't see the advantage.


I'm planning on using a Zynq UltraScale+ module to allow for larger 
disks and multiple disk emulations (it has more block RAM and 4GB of 
DRAM on the module).


TTFN - Guy

On 4/14/22 23:34, Tom Gardner wrote:

> I suggest if we are talking about an emulator it really isn't 
necessary to have the entire disk in DRAM, two tracks of DRAM acting 
as a buffer with a modern HDD holding the emulated drive's data should 
be fast enough to keep any old iron controller operating without 
missing any revolutions.  The maximum unformatted track length of any 
old iron drive is well known and therefore one can allocate the number 
of blocks sufficient to store a full track and then write every track, 
gaps and all to the modern disk.  Given the data rate, track size and 
sequential seek times of a modern HDD one should be able to fill then 
next track buffer before the current track buffer is read into the 
controller.  If two track buffers and an HDD isn't fast enough then 
one could add a track buffer or two or go to SSD's.


>

> This was the approach IBM used in it's first RAMAC RAID where I think

> they had to buffer a whole cylinder but that was many generations ago

>

> Tom

>

> -Original Message-

> From: Guy Sotomayor [mailto:g...@shiresoft.com 
]


> Sent: Wednesday, April 13, 2022 10:02 AM

> To: cctech@classiccmp.org 

> Subject: Re: idea 

Re: idea for a universal disk interface

[Guy Sotomayor via cctech]

I ran the numbers for Zynq FPGAs.  First of all for ESDI and SMD the 
head switch time is 1-2us (basically the time it takes for the clocks to 
re-lock on the new data).


Two tracks isn't sufficient (which is the "other" track...you will be 
wrong).


So I decided to go and have a full cylinder (I'm allowing for up to 32KB 
tracks and up to 16 heads) which is 512KB.  The Zynq DMA from HW block 
RAM to DRAM (at 500MB/s) is ~1ms.  Given that the previous cylinder 
could be dirty (e.g. has written data), the worst case seek time is 
~2ms.  This allows me to emulate any seek latency curve(s) I want.


In my design, any dirty data is written back to storage in a lazy manner 
so the performance of the storage isn't really an issue.


I should note that the Zynq 7020 module has 1GB of DRAM on it, so there 
is no additional cost to just put the entire disk contents in DRAM and 
I'm using the attached SD Card interface for storage (so you can use a 
$10 SD Card for storage).  Adding a high speed disk interface (e.g. 
MD.2, PCIe, or other serially attached storage) would add additional 
cost in terms of having to create the interface as well as a reasonably 
fast drive and I don't see the advantage.


I'm planning on using a Zynq UltraScale+ module to allow for larger 
disks and multiple disk emulations (it has more block RAM and 4GB of 
DRAM on the module).


TTFN - Guy

On 4/14/22 23:34, Tom Gardner wrote:

I suggest if we are talking about an emulator it really isn't necessary to have 
the entire disk in DRAM, two tracks of DRAM acting as a buffer with a modern 
HDD holding the emulated drive's data should be fast enough to keep any old 
iron controller operating without missing any revolutions.  The maximum 
unformatted track length of any old iron drive is well known and therefore one 
can allocate the number of blocks sufficient to store a full track and then 
write every track, gaps and all to the modern disk.  Given the data rate, track 
size and sequential seek times of a modern HDD one should be able to fill then 
next track buffer before the current track buffer is read into the controller.  
If two track buffers and an HDD isn't fast enough then one could add a track 
buffer or two or go to SSD's.

This was the approach IBM used in it's first RAMAC RAID where I think they had 
to buffer a whole cylinder but that was many generations ago

Tom

-Original Message-
From: Guy Sotomayor [mailto:g...@shiresoft.com]
Sent: Wednesday, April 13, 2022 10:02 AM
To: cctech@classiccmp.org
Subject: Re: idea for a universal disk interface

I've had a similar project in the works for a while (mainly for ESDI and SMD).

I think the main issue you're going to face is that what you need to do for 
something like ESDI or SMD (or any of the bit serial interfaces) is going to be 
radically different than something like IDE or SCSI.  This is not just the 
interface signals but also what's needed in the FPGA as well as the embedded SW.

For example, for the ESDI and SMD interface in order to meet the head switch 
times (1-2 microseconds) requires that a full cylinder be cached in HW.  Once 
you do that and look at the timings to move a max cylinder between the HW cache 
(that will serialize/de-serialize the data over the
interface) and storage, you'll see that the only way to have any reasonable 
performance (e.g. not have seek times be > 40ms for *any*
seek) is to cache the entire drive image in DRAM and lazily write back dirty 
tracks.

I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq 7020 for single drive 
emulation and the Zynq Ultrascale+ for up to 4 drives).  In my case the HW, FPGA logic 
and SW will share significant portions but they will not be identical.  In my case there 
is no need for an external PC (just adds complexity) other than something to do basic 
configuration (e.g. drive parameters such as number of heads, number of cylinders, etc) 
which will actually be over USB/serial.  The actual persistent storage will be an SD card 
since all reading will be done at "boot time" and writes will be handled in a 
lazy manner (since the writes will first go to the DRAM based upon time or seek).

It may also be sufficient for configuration purposes to have a file
(text) on the SD card that defines the configuration so no external 
interactions would be necessary.  I'm still thinking about that one.  ;-)

TTFN - Guy

On 4/12/22 22:35, shad via cctech wrote:

Hello,
I'm a decent collector of big iron, aka mini computers, mainly DEC and DG.
I'm often facing common problems with storage devices, magnetic discs and tapes 
are a little prone to give headaches after years, and replacement drives/media 
in case of a severe failure are unobtainable.
In some cases, the ability to make a dump of the media, also without a running 
computer is very important.

Whence the idea: realize an universal device, with several input/output 
interfaces, which could be used both as storage emulator, to run a 

Re: idea for a universal disk interface

[Guy Sotomayor via cctech]

I've had a similar project in the works for a while (mainly for ESDI and 
SMD).


I think the main issue you're going to face is that what you need to do 
for something like ESDI or SMD (or any of the bit serial interfaces) is 
going to be radically different than something like IDE or SCSI.  This 
is not just the interface signals but also what's needed in the FPGA as 
well as the embedded SW.


For example, for the ESDI and SMD interface in order to meet the head 
switch times (1-2 microseconds) requires that a full cylinder be cached 
in HW.  Once you do that and look at the timings to move a max cylinder 
between the HW cache (that will serialize/de-serialize the data over the 
interface) and storage, you'll see that the only way to have any 
reasonable performance (e.g. not have seek times be > 40ms for *any* 
seek) is to cache the entire drive image in DRAM and lazily write back 
dirty tracks.


I've been looking at the Xylinx Zynq SoCs for this (mainly the Zynq 7020 
for single drive emulation and the Zynq Ultrascale+ for up to 4 
drives).  In my case the HW, FPGA logic and SW will share significant 
portions but they will not be identical.  In my case there is no need 
for an external PC (just adds complexity) other than something to do 
basic configuration (e.g. drive parameters such as number of heads, 
number of cylinders, etc) which will actually be over USB/serial.  The 
actual persistent storage will be an SD card since all reading will be 
done at "boot time" and writes will be handled in a lazy manner (since 
the writes will first go to the DRAM based upon time or seek).


It may also be sufficient for configuration purposes to have a file 
(text) on the SD card that defines the configuration so no external 
interactions would be necessary.  I'm still thinking about that one.  ;-)


TTFN - Guy

On 4/12/22 22:35, shad via cctech wrote:

Hello,
I'm a decent collector of big iron, aka mini computers, mainly DEC and DG.
I'm often facing common problems with storage devices, magnetic discs and tapes 
are a little prone to give headaches after years, and replacement drives/media 
in case of a severe failure are unobtainable.
In some cases, the ability to make a dump of the media, also without a running 
computer is very important.

Whence the idea: realize an universal device, with several input/output 
interfaces, which could be used both as storage emulator, to run a computer 
without real storage, and as controller emulator, to read/write a media without 
a running computer.
To reduce costs as much as possible, and to allow the better compatibility, the 
main board shall host enough electrical interfaces to support a large number of 
disc standard interfaces, ideally by exchanging only a personality adapter for 
each specific interface, i.e. connectors and few components.

There are several orders of problems:
- electrical signals, number and type (most disk employ 5V TTL or 3.3V TTL, 
some interfaces use differential mode for some faster signals?)
- logical implementation: several electrical signals are used for a specific 
interface. These must be handled with correct timings
- software implementation: the universal device shall be able to switch between 
interface modes and be controlled by a remote PC

I suppose the only way to obtain this is to employ an FPGA for logic 
implementation of the interface, and a microprocessor running Linux to handle 
software management, data interchange to external (via Ethernet). This means a 
Xilinx Zynq module for instance.
I know there are several ready devices based on cheaper microcontrollers, but 
I'm sure these can't support fast and tight timing required by hard disk 
interfaces (SMD-E runs at 24MHz).

The main board should include a large enough array of bidirectional 
transceivers, possibly with variable voltage, to support as much interfaces as 
possible, namely at least Shugart floppy, ST506 MFM/RLL, ESDI, SMD, IDE, SCSI1, 
DEC DSSI, DEC RX01/02, DG6030, and so on, to give a starting point.
The common factor determining what kind of disc interface can be support on 
hardware side is obviously the type of transceiver employed, for instance a 
SATA would require a differential serial channel, which could not be available.
But most old electronic is based on TTL/CMOS 5V logic, so a large variety of 
computer generations should be doable.

For the first phase, I would ask you to contribute with a list of interfaces 
which could be interesting to emulate, specially if these are similar to one 
from my list.
I please submitters to send me by email or by web link when possible, detailed 
documentation about the interface they propose, so I can check if it could be 
doable and what kind of electrical signals are needed.
Also detailed information about interfaced I listed is appreciated, as could 
give some detail I'm missing.

Thanks
Andrea


--
TTFN - Guy

Re: Fixing an RK8E ....

[Guy Sotomayor via cctech]

On Fri, 2020-06-19 at 12:24 -0700, Robert Armstrong via cctech wrote:
>   It appears that my RK8E has a problem - it fails the diskless
> control test
> with
> 
>   .R DHRKAE.DG
>   SR= 
> 
>   COMMAND REGISTER ERROR
>   PC:1160 GD: CM:0001 
>   DHRKAE  FAILED   PC:6726  AC:  MQ:  FL:
>   WAITING
> 
> Ok, maybe a bad bit in the command register so I'll check it
> out.  But then
> it dawns on me - how do you work on this thing?  It's three boards
> connected
> with "over the top" connectors - you can't use a module extender on
> it.
> Worse, the M7105 Major Registers board is the middle one of the
> stack!   Is
> there some secret to working on this thing?  Has anybody fixed
> one?  Any
> suggestions?
> 
>   I hadn't thought about it before, but the KK8E CPU would have the
> same
> problem.  Fingers crossed that one never dies...
> 

I seem to recall that there were some "special" (read unobtanium) over
the top connectors that permitted one of the boards in a board set to
be up on an extender.

TTFN - Guy