Hi,
I just wanted to provide a bit of a progress report on the SMD/ESDI
emulator project.
Now that I'm retired I have a bit more time to actually work on it.
Previously I was just doing a bunch of research and writing notes on the
design. I now have a solid design and I'm starting with the implementation.
I'm going to list some of the design goals and then sketch out a few of
the major issues and how they're being addressed.
Goals:
* Emulate any drive geometry
* Emulate a drive's performance characteristics
* Work across different interface types
* Fully built emulator cost below $500
Major Issues:
* SMD/ESDI have head switch times < 10 microseconds (basically the
time it takes for the read amplifiers to settle on a "real" drive).
Solving this issue drives the majority of the design
* Address marks on a "real" drive are implemented by writing a DC
signal on the track and the read circuitry detects that and
generates the address mark signal
When looking at the specifications for SMD and ESDI disks there aren't
really a lot of difference in how the drive behaves. The interfaces
differ in detail but in reality the differences are pretty minor. So
the current design should allow for 95+% code sharing between SMD and
ESDI emulators.
To solve the head switch performance, it is necessary to have an entire
cylinder in some sort of RAM. This allows for very fast head switch
times (e.g. the selected head just addresses a particular portion of the
RAM). However, this means that loading a cylinder (which in some cases
could be as much as 1MB) could take considerable time. It will take
even longer if some of the tracks in the cylinder are "dirty" due to
them having being written to prior to the seek.
Since I want the emulator to be able to faithfully emulate drives in all
respects, the limiting factor is the cylinder-to-cylinder seek time
(e.g. moving from one cylinder to another cylinder that is adjacent).
This is typically in the 4-8ms range. So doing the math, one must move
1MB in 4ms (that turns out to be ~250MB/sec of bandwidth...using 32-bit
transfers, this means over 60M transfers/sec).
The above implies that the cylinder RAM and where the storage holding
the cylinders of the image must be capable of at least 60M transfers/sec
between them. This is going to involve a complex FPGA that is able to
have large internal RAMs and a direct connection to some sort of DRAM to
hold the full image. I've chosen to use a SOM (System-On-Module)
version of the Xilinx Zynq 7020. This has dual 32-bit ARM cores (plus a
whole bunch of peripherals), 32-bit DDR3 memory interface, plus a fairly
large FPGA with enough block RAM to contain the maximum cylinder. The
calculations I've done should allow a new cylinder to be loaded from
DRAM into the cylinder RAM in 4-8ms (I think with a few tricks I can
keep it in the lower range).
I've looked a quite a few Zynq SOMs (and have acquired quite a few for
evaluation purposes). I finally found one that's ~$200 (most of the
others are in the $400-$1000+ range). This SOM brings out most of the
Zynq's I/Os (94 I/Os) in addition to having ethernet, USB, serial, SD
card, etc. as well as 1GB of 32-bit DDR3 DRAM. It also runs Linux which
means that developing the SW is fairly straight forward.
The next issue was how to emulate address marks. The emulated drive
will have a bit clock which is necessary for clocking out the data when
reading (or out when writing). The bit clock is always running (just
like a "real" drive when spinning). That will drive a counter (which
represents which bit is under the emulated "head"), that counter (along
with the head number) will be used to address the block RAM. The
counter is always running, so as to emulate the spinning disk. The
address marks are emulated by having a series of comparators (one for
each possible sector). They compare the bit counter with the value
associated with the comparator, if there's a match then that signals an
address mark. It's bit more complicated because writing address marks
(in the case of soft-sectors) has to be dealt with.
The emulator is composed of 4 major components:
1. Emulator application plus some utilities
I'm currently writing all of this code...since I'd been a SW
engineer for 50+ years, this is all "production" quality code and is
extremely well documented...still a ways to go.
2. Linux device driver which provides the interface between the
emulator application and the emulator HW
I haven't started on the driver yet but it should be fairly straight
forward as it really only provides an interface to the emulator HW
to the emulator application
3. Emulator HW RTL
I haven't started on this other than to do some basic blocks of
what's here. It mainly is the cylinder RAM, serdes (I *may* be able
to finesse this by having 32-bits on the AXI bus and 1 bit on the
interface side...a nice feature of the block RAM), address mark
logic, bit counter and some command decode/handling (it'll handle
the seek command all in the RTL...everything else will be handled by
the application.
4. Interface board
This should be a fairly simple board. It's a carrier for the SOM,
3.3v-to-5v level shifters, interface circuits for SMD or ESDI (they
use different interface ICs) and the interface to the cable.
I'm starting with SMD just to make the board layout easier (I can just
use 0.1" headers for interface cabling). I also have an SMD disk
exerciser that will make it easier to make sure it's working properly.
The idea is that once I have an SMD working reasonably well, I'll start
on ESDI.
Interacting with the emulator application can be any of the following:
* config file: indicates various emulator startup options including
which image (if any) to "mount" initially
* command line: same as the config file
* emulator utilities: these are mainly allow for changing which image
is mounted, changing write protect status, querying state of
emulator, etc. The utilities can be used locally by logging into to
Linux running on the Zynq 7020 or by using "host" versions if the
emulator is connected to a network via ethernet.
One of the key utilities is creating an "empty" (that is all tracks
contain all 0's) image. The image format has been finalized. It allows
for almost any geometry of disk (up to 32 heads and up to 65536
cylinders). The main restriction is the 1GB of DRAM on the Zynq 7020
SOM. I expect in reality that the largest drive that can be emulated
will be ~600-700MB due to DRAM.
I plan on providing some standardized "templates" (e.g. they'll describe
actual drive geometries and seek performance tables) so creating new
images won't be too onerous.
I'll be putting all of the source, RTL and board files on github under a
BSD license once I get further along.
--
TTFN - Guy
I picked up a keyboard for a Wyse terminal at a flea market the other
day. When I tried some of the keys, they couldn't be depressed.
I thought, at first, some dirt or debris had gotten stuck there, but on
closer look I saw something black below the keys that seemed to be
stuck. I pulled a key cap off and found a U shaped piece of black
plastic that was put there on purpose to prevent you from depressing the
key.
The question came to mind; "What sort of application would be so crude
that you would have to prevent the user from depressing certain keys?"
One of the keys was a Break key, which sort of made sense to me, because
it would halt a PDP-11 if that was the host machine.
This was the first time I had ever seen this kind of thing, was this
common long ago?
LINK:
https://www.kennettclassic.com/surplus-sale-starts-3-19/
If you can make it to Kennett Square, PA USA between now and April 19th
2024, stop in and browse our inventory of surplus vintage computing items.
The link above contains answers to questions. If you want to be added to
the mailing list, visit kennettclassic.com and submit a contact form.
Thanks
Bill Degnan
Hi all!
I'm working on a little side project to see why one can't put a better
CPU chip into a Sun 386i. Basically with a real 386 in the socket the
system will at least start to flash the LEDs on the back, but with a
Cyrix chip the LEDs are frozen on.
I can remove the frame buffer, memory cards, even the Timekeeper chip
and I still see this behavior. Running with no CPU or no PROM chip makes
the system flash no lights, pointing to the problem being code in the PROM.
Now, 386 CPUs don't have the CPUID register, but they do have a little
feature where upon reset EDX contains a "3" to show the CPU "type". On a
Cyrix chip it contains a "4".
My guess is the ROM code has at the beginning a check of EDX and if <>3
go to a halt. I'd like to dump the code, find that check, and either
replace the 3 with a 4, or replace the first HALT with a NOOP.
The PROM is an Intel D27010 which is an Intel 128k*8 chip. Unfortunately
I'm not finding much in terms of either datasheets or PROM programmers.
Does anyone know how to/have the tools to dump and reprogram this? I'll
bet the old archives that talk about the "Blue Lightning 386" working
for boot were due to the chip being made under license of Intel thus
being allowed to have that "3" in there.
But since I also have a TI 386/486 chip with 8k of L1 cache, a 486 core
instruction set, faster multiplier, and clock doubling by default I
think it might wind up being.... faster.
C
Does anyone have interest in vintage diskette duplication / duplication
machines? Would this make for an interesting VCF exhibit? Does/did anyone
use these commercially?
Bill
Just a ping out there to see if anyone's sitting on installation media for
CommonPoint (the last gasp of Taligent). Seems appropriate to try to coerce it
to run on an Apple Network Server. Let me know on or off list as appropriate.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- "I'd love to go out with you, but I need to clean my toilet brush." --------
Over the years, I have gradually built up a functional PDP-11/23+
system, which of course I now have no need for ;) So I'd be interested
in selling it as I slowly downsize. You'd need to pick it up in south
central Missouri as shipping would be impractical and expensive.
Specifics: 11/23+ with 4MB RAM, selectable boot ROMs, two RL02 drives,
floppy interface (set to 3.5" TEAC drive), 16-line serial ports,
corporate cabinet with DEC power controller. Software including RT-11SJ,
XM, TSX-Plus. Also have a VT-220 for the console which I may sell
separately or with the system.
Please email me *off-list* with offers, request for pics, etc.
thanks
Charles
I look back fondly on the IBM PC-XT of 41 years ago. It was very pricy here
in the Great North but it allowed for a much more advanced computing
environment. What one could do with a 10MB hard disk! Granted it was far
more popular in the business world than the consumer one. However, it made
possible much greater developments that hobbyists and experimenters latched
onto.
Happy computing!
Murray 😊
Hello classic computing fans! The new website for VCF Midwest is up at
https://vcfmw.org. Who knows the design inspiration without asking a
(Commodore) friend?? Apologies if it doesn't render well on your device.
I don't have your device!
Room booking for the show will open this afternoon (Friday 3/8). It will
be announced via the mailing list and a refresh of this web page (at the
"HOTEL" link.)
Lots more rooms this time, and we're starting with an empty block. But
it's still best to book early if you want to stay at the show hotel!
See you in September...
-jt
