[non] Persci drives and the Cromemco 16FDC - for Herb & Amardeep
Barry Watzman
Picking up on a an old topic ....
A number of us have from time to time wanted to use the Cromemco 16FDC
floppy disk controllers with non-Persci 8" drives.
There is a thread about this on Herb Johnson's web site (although I
can't find it, but I have it copied on my computer).
[actually, it is here:
http://www.retrotechnology.com/herbs_stuff/s_persci.html]
Part of that is a series of exchanges between Herb, myself and Amardeep
Chana from 2004.
At the end of this exchange, Herb wrote:
"Editor's note: Amardeep was able to complete his work and operate the
drives successfully. When I get the details I will put them up on my
site and put the link here. - Herb "
So, Herb (or Amardeep ....) .... was the final mods and techniques to
get a 16FDC to support non-Persci drives ever documented anywhere?
Another note, FWIW ...
Working on some 16FDCs in the past weeks, I have discovered that if I
try to boot using my Zenith Data Systems Z-100's external 8" drives (a
pair of Shugart SA-860's), it works if the 16FDC has RDOS (the firmware
ROM) version 2.52, but it fails if the 16FDC has version 2.01 (and I can
change the socketed ROM and prove that the firmware is the issue).
Anyone have any idea why? Is anyone able to burn some 2.52 ROMs for me
(it takes a 4k byte 2732; I can burn 2708's and 2716's but not 2732's).
Also, does anyone know what features and functions RDOS version 3.xx
added relative to version 2.52?
All...@localhost.net
The most common reasons would be:
- Wrong control signals for the drive (jumpers on drive or board).
- Wrong step rate (too fast, missed steps) and persi drives were very
fast.
- Wrong format expected (sides, sectors, bytes/sector)
I happen to have an Heath H207 (two HH height drives in a box) and
besides being heavy it's also rock solid reliable.
I do not use or have any 16FDC to look at as I have more than enough
DISK1As and my own smart floppy controllers.
>Also, does anyone know what features and functions RDOS version 3.xx
>added relative to version 2.52?
Never got to play with it though I'd heard it did have cpmV2
compatability and later CPMV3 compatability for basic applications.
Speculation only might it have been add ign CP/M 3 compatability
plus cleanup?
Allison
Herbert Johnson
> http://www.retrotechnology.com/herbs_stuff/s_persci.html]
>
>..... When I get the [final] details I will put them up on my
> site and put the link here. - Herb "
>
> So, Herb (or Amardeep ....) .... was the final mods and techniques to
> get a 16FDC to support non-Persci drives ever documented anywhere?
I don't think I got further information, that was five years ago. I
suggest you contact Amardeep directly and ask him, and let me know
accordingly. If I have a recent email addresss for him, I'll forward
the request.
> Working on some 16FDCs in the past weeks, I have discovered that if I
> try to boot using my Zenith Data Systems Z-100's external 8" drives (a
> pair of Shugart SA-860's), it works if the 16FDC has RDOS (the firmware
> ROM) version 2.52, but it fails if the 16FDC has version 2.01 (and I can
> change the socketed ROM and prove that the firmware is the issue).
The firmware may manifest the failure, but...what is the "failure"
exactly?
> Anyone have any idea why? Is anyone able to burn some 2.52 ROMs for me
> (it takes a 4k byte 2732; I can burn 2708's and 2716's but not 2732's).
>
> Also, does anyone know what features and functions RDOS version 3.xx
> added relative to version 2.52?
Dump and disassemble the ROMS and see. Or look for the sources or docs
...let's see what Herb Johnson has....
http://www.retrotechnology.com/herbs_stuff/d_crom.html
My Cromemco Web page says I have some RDOS manuals, including
"RDOS instruction manual, 1978, 30 pp."
"RDOS source code, ver. 2.01, with service notes, 100 pp."
"I have some RDOS ROM images at this links page" -
http://www.retrotechnology.com/herbs_stuff/proms.html
That page has "Cromemco RDOS proms for 16 FDC: RDOS252.HEX
RDOS312.HEX"
Those are Intel hex format files, which a PROM programmer will accept.
Also, PIP and LOAD will convert them to binaries, which could be
disassembled.
I charge for good photocopies of manuals I list on my site, contact me
for specifics. The RDOS files are already available on my Web site at
no charge. Other sites may have this or other information, documents.
herb johnson
retrotechnology.com
Barry Watzman
exactly?"
The firmware, after accessing the disk drive (or attempting to), says
"can't boot" (or "unable to boot" or something like that) and then you
get a new RDOS prompt (instead of CP/M).
Apparently it's not able to read the boot sector, because all it does is
read the boot sector and then transfer control to it.
Since I have the ROMs, I have the binaries. Disassemble them? I was
looking for an already existing answer. The time required to
disassemble them and then figure out the differences is greater than
what I am willing to put into this project at this time.
I ***SUSPECT*** that there is a drive issue that could be remedied with
a drive jumper change. But I'm not interested in making such changes.
Barry
Emil Sarlija
The original thread, although it didn't provide the answers, planted a
seed in showing me that it could be done. Using the 16FDC schematic, I
made a comparison between the 8" interface on it and the Shugart
standard and noticed the following differences:
(Note: use a monospaced font or this will look like utter crap)
SHUGART
/ 1 2 /TG43
| 3 4
| 5 6
| 7 8
| 9 10 /TWO SIDED
| 11 12 /DISK CHANGE
| 13 14 /SIDE SELECT
| 15 16 /IN USE
| 17 18 /HEAD LOAD
| 19 20 /INDEX
| 21 22 /READY
| 23 24
GROUND | 25 26 /DRIVE SELECT 1
| 27 28 /DRIVE SELECT 2
| 29 30 /DRIVE SELECT 3
| 31 32 /DRIVE SELECT 4
| 33 34 /DIRECTION
| 35 36 /STEP
| 37 38 /WRITE DATA
| 39 40 /WRITE GATE
| 41 42 /TRACK 00
| 43 44 /WRITE PROTECT
| 45 46 /READ DATA
| 47 48
\ 49 50
CROMEMCO 16FDC
/ 1 2 /SIDE SELECT
| 3 4 /DRIVE SELECT 4
| 5 6
| 7 8
| 9 10 /SEEK COMPLETE
| 11 12 /RESTORE
| 13 14 /EJECT
| 15 16
| 17 18 /DRIVE SELECT 3
| 19 20 /INDEX
| 21 22 /READY
| 23 24 /MOTOR ON
GROUND | 25 26 /DRIVE SELECT 1
| 27 28 /DRIVE SELECT 2
| 29 30
| 31 32
| 33 34 /DIRECTION
| 35 36 /STEP
| 37 38 /WRITE DATA
| 39 40 /WRITE GATE
| 41 42 /TRACK 00
| 43 44 /WRITE PROTECT
| 45 46 /READ DATA
| 47 48
\ 49 50
From this, I made the following cuts on the PCB using a Dremel to
disconnect the folowing pins on J3 - the 8" drive header:
Pin 2 - trace in between "16FDC" print and down arrow - component side
Pin 4 - trace in between via and "J3" print - component side
Pin 10 - trace between "IC 10" print and "R17" print - component side
Pin 12 - trace to the right of "CROMEMCO TM" print - component side
Pin 14 - trace in between the letters 'T' and 'R' in the "CABLE STRIPE"
print above J3 - component side
Pin 18 - trace to the right of J3 - solder side
Pin 24 - trace to the left of "C14" print - component side
I them made the following jumpers to the following J3 pins with
wire-wrap wire:
Pin 30 -> J2 Pin 14
Pin 32 -> J2 Pin 6
Pin 14 -> IC 8 Pin 14
Pin 18 -> IC 11 Pin 13
I have provided descriptions to assist in finding where the traces are
on the physical PCB. These modifications worked for me using Mitsubishi
M2896-63 8" drives. Your mileage may vary and I shall not be held
responsible for the release of magic smoke. ;-)
Herb, if you'd like to include the above info on your site to assist
anyone with the same problem, you're more than welcome to. Same goes for
anyone else. :-)
Have fun!
Emil
MikeS
I'm almost certain that the 16FDC with RDOS 2.52 supported the Tandon
TM848s that Cromemco used in the later System 3s and the Z-2 TopHats,
but I also seem to recall that the drives had some jumper wire mods
added. I doubt that anything prior to 2.50 would handle any 8" drives
other than the Perscis.
Are you sure that 2.52 is a 2732 equivalent? I'll have to check that
for myself one of these days. Sounds like you have one; why do you
need one burned?
3.xx ROMS were 8K and added support for booting from hard disks (as
well as some minor changes to the monitor commands); 3.08 would boot
the WDI IMI disks and 3.12 the STDC ST412 types.
mike
Barry Watzman
16FDCs here, of which:
-Some work, at least superficially, with my Shugart SA-860's
-Some work only if I change the RDOS ROM from 2.01 to 2.52
-Some have a working monitor but not a working FDC interface (no matter
what ROM is installed). Likely a data separator problem.
-Some are totally non-responsive
Some have 2.01 firmware, some 2.52 firmware and one has 3.07 firmware.
2.xx firmware is on 4k ROMs (eg 2732 or similar); the version 3 firmware
is on an 8k ROM (2764). I could use at least one more 2.52 ROM, but I
have no way of burning one.
I'm planning to offer some of them (probably the non-working ones) on
E-Bay. Perhaps as soon as this evening. I am also planning to offer an
S-100 chassis complete with a Cromemco ZPU, a 16FDC, memory and a
diskette that boots CP/M (e.g. a complete system, but no drives or
terminal).
The information in your post and in Emil's post is definitely helpful.
I wish that there was a repository somewhere of the different board
revision levels (most of mine are rev. E & F) and subsequent "wire mods"
to them. Almost no two boards that I have are the same.
MikeS
>
> - Show quoted text -
I think you'll find that the 2.52 ROMs and earlier are TI 2532
compatible and a 'normal' 2732 would require some mods; in fact you'll
probably notice that the original had pins 20 and 21 both tied
together for compatibility. Alternatively, if you can burn one you
could use a 2764 8K ROM for both 2.xx or 3.xx; the mods required for a
Rev E or F board to use the extra 4K are available on line, look for
App note 023-9125. BTW, 023-9124 outlines the changes from 2.52 to
3.08.
http://maben.homeip.net:8217/static/S100/cromemco/RDOS/index.html
A non-responsive console port was often caused by a ground loop
current burning out one or more of the chokes in series with the
RS-232 lines, which are easily replaced with a 100 (or 0) Ohm
resistor. The TMS5501 also occasionally failed.
Cromemco did publish application notes and tech bulletins detailing
the various board revisisons and mods, but unfortunately I haven't
seen any regarding the 16FDC (although I have some for the 64FDC and
Marcus also has them on line AFAIK).
I've never seen or heard of a version 3.07; if that's a correct number
I'd love to see a dump. Also just for historical reasons it'd be nice
to have a dump of that 2.01 before you get rid of it; I'm not aware of
any other copies.
Have fun!
MikeS
One of the selling points of the 16/64FDCs might be that having both
34 pin 5.25" and 50 pin 8" drive connectors effectively in parallel
makes it really convenient to connect a 5.25" or 3.5" HD drive as an
8" replacement; no cable adapters required, just a jumper to connect
the /READY signal.
Marcus has a couple of excellent writeups on his blog; see Mar. 30 and
Apr. 16 2009 or search 'Cromemco controller':
http://majzel.blogspot.com/search?q=cromemco+controller
mike
Barry Watzman
Quite a few of my boards have RDOS 2.01, and those are masked ROMs, so I
would have to think that they are fairly common.
On one of my boards, I did find that the RS-232 driver was the problem
(1488 or 1489).
There is a tech note about using an EPROM instead of the masked ROMs and
yes, a few minor mods are required. There is also a tech bulletin on
using a 3.08 ROM on the 16FDC boards, with lists of mods required
(different for 16FDC rev. E and rev F boards). None of those seem to
agree with the mods actually made to the board that has that EPROM. I
tested all of the 5501's, they were all good. I don't recall that there
were chokes, but I'll look at that.
Getting a dump of 2.01 will be difficult, since if the board has 2.01
... it won't work !! I need the 2.52 firmware to boot successfully. I
don't have an prom burner or any way of reading or burning a 4k prom of
any kind.
[There might be a way to capture the 2.01 prom; the terminal is a
toshiba laptop running DOS 6.22 and ProComm Plus. I can do a dump in
RDOS and I can probably capture the text in ProComm. I'll look at that.
It won't be pretty, and it won't be any format that you would like.]
MikeS
>
> - Show quoted text -
Ah well, sounds like I'm not telling you anything you didn't already
know.
And mea culpa, of course a 2764 won't fit as is; you'd need either a
68764/6 or an adapter to use 3.xx. I actually use 27128s with an
adapter and have both versions switch-selectable so I can boot from
either HD type.
A captured memory dump of those ROMs would be fine; there are probably
lots of 2.01s out there but I don't see any archived copies anywhere.
If you're really stuck I could probably spare an original 2.52 ROM.
mike
MikeS
Since you aroused my curiosity I've had a look at some of this stuff;
it looks like the 16FDC uses pin 2 for side select and pin 14 for
eject (no write current control AFAICS), while the 64FDC (and the
TM848) use pin 2 for RWC and pin 14 for side select.
On the TM848s used with the 16FDC that's definitely one of the mods;
the original pin2 trace is cut and pin 2 is rerouted elsewhere.
Maybe Cclist or the Cromemco UG forum would get you some better
answers?
mike
Herbert Johnson
soon include all your remarks on my "persci" Web page, which is linked
to my Cromemco Web page and (since Processor Technology was mentioned
at the time and commented upon) my Processor Technology Web page. This
will take a day, I gotta have dinner now.
http://www.retrotechnology.com/herbs_stuff/d_crom.html
http://www.retrotechnology.com/herbs_stuff/s_persci.html
http://www.retrotechnology.com/herbs_stuff/d_proc.html
Barry, if I recall, some RDOS versions allowed you to change the step
rate. I think the RDOS prompt changed from one semicolon to multiple
semicolons as the step rate was reduced. As I said earlier, I have a
paper version of early RDOS source from Cromemco; the Web archive site
mentioned by Mike S. probably has that document also.
Disassembly, as I suggested, is not a god-awful way to figure out code
like small monitors. Use an emulator to run Ward Christensen's
disassembler or some other one. For Pete's sake, don't dump a ROM in
binary, load in a simple hex converter and dump it in readable HEX.
Just take a byte, grab a four bit nybble, add something to make it an
ASCII number or letter, spit it out - not that much code, and it's a
nice "tool" to have around for just these occasions.
I'll be glad to host additional ROM images of RDOS, in Intel Hex
format, I already have two of them.
Herb Johnson
you know the drill
retrotechnology.com
Barry Watzman
track zero (e.g. no stepping is required ... AT ALL), and, subsequently
(and subject to how the code is written) RDOS isn't used for disk
access. Secondly, although not as fast as the Persci drives, the
Shugart SA-860's support buffered seek with a "seek complete" line
(although I think it's on a different pin than on the Persci drives).
Still, version 2.01 ROMs won't work with the SA-860's, while 2.52 will
(with NO mods to either the drives or controller, and this verified by
changing the roms on two different controllers).
MikeS
>
> - Show quoted text -
Well, it's not surprising. 2.01 is before my time but I wouldn't be
surprised if it even had some bugs; it sounds like the first version
of RDOS for the 16FDC (after the 4FDC). Of course in those days
Cromemco used Perscis exclusively AFAIK, and only in one system, and
we know how well the old saw about the nice thing about standards
being their variety applied to 8" drives of the day.
BTW, I have to thank you (Barry) and Emil:
When I started archiving my boxes of 8" disks and converting some to 5
1/4HD some years ago I only found 2 working drives out of 6; since I
had always found the 8" drives relatively unreliable I just wrote it
off as a cleaning and/or alignment issue and put the bad ones aside
for that 'rainy day' and used the working ones.
But this discussion reopened the subject, and although I knew there
were differences between the 16FDC and the 64FDC, since they both used
TM848s in my systems it never occurred to me that they were actually
incompatible at the interface level. Sure enough, I put in a 64FDC and
the 'dead' drives are working just fine; all I have to do is remember
that some of my TM848s are 16FDC compatible and some work with the
64FDC.
Years of working with Cromemcos and it took you guys to show me the
light ;-)
mike
glen herrmannsfeldt
< The step rate does not appear to have been an issue; the boot code is on
< track zero (e.g. no stepping is required ... AT ALL), and, subsequently
< (and subject to how the code is written) RDOS isn't used for disk
< access. Secondly, although not as fast as the Persci drives, the
< Shugart SA-860's support buffered seek with a "seek complete" line
< (although I think it's on a different pin than on the Persci drives).
How does it get to track zero? The drives I know require seek
pulses until the track zero line goes active.
The idea of buffered seek on a floppy drive is interesting.
It now seems common on hard disks, but not usual on floppy
drives. (It might be that the LS-120 drives do it, even with
ordinary floppy disks, though.)
-- glen
marcus bennett
http://maben.homeip.net:8217/static/S100/cromemco/cards/Card%20Revisions/index.html
is where the detail on Cromemco Card revisions live
http://maben.homeip.net:8217/static/S100/cromemco/cards/technical%20bulletins/index.html
for some misc technical bulletins
As I hope I commented in the Cromemco Google group (http://
groups.google.co.uk/group/cromemco ) I now have an almost totally
successfull mechanism for archiving 8" Cromemco Disks of any sort. In
essence it builds on the ability to install a 3.5" floppy on the 64FDC
that emulates a DSDD 8" diskette drive. Then placing another of these
3.5" drives into my IBMPC allows me with Dave Dunfield's imagedisk
( http://www.classiccmp.org/dunfield/img/) to make an image under
DOS.
Aside for reasons of authenticity then I'm moving all my 8" physical
disks to 3.5" media which (and I'm entirely serious) has some chance
of working in another 10 years of so.
Therefore if you look on a daily basis in the code directory
http://maben.homeip.net:8217/static/S100/cromemco/code/disks/index.html
you will see an increasing number of files with .IMD extension
magically appearing.
Finally, If anybody can burn and duplicate an RDOS 03.12 I'd be
interested. As Mike commented this level can boot to an MFM hard disk
drive connected to an STDC controller. At lower RDOS levels a direct
boot is not possible, in those cases you need to create a floppy with
a boot loader that either gives you a boot menu or is automatically
set to boot to a major:minor STDC device and partition. This is much
slower and quite annoying.
regards marcus
Barry Watzman
guess that even that could be an issue, but the SA-860's support
buffered seek, so even if the entire seek process isn't working (because
"seek complete" is on the wrong pin, for example), the system reset will
still get an SA-860 to track zero. This might not work with an older
technology drive, however.
Barry Watzman
the long term (e.g. decades) reliability of 8" media has been far better
than that of 3.5" media. Ok, the 3.5" media has the advantage of being
decades newer. But we are now at the point at which new computers don't
have 3.5" drives either, and at which almost no one is still using 3.5"
drives or media for much of anything.
Emil Sarlija
> In <h9qvhp$uu4$2...@news.eternal-september.org> Barry Watzman <Watzma...@neo.rr.com> writes:
>
>> FWIW, my experience (and I think that of a lot of others also) is that
>> the long term (e.g. decades) reliability of 8" media has been far better
>> than that of 3.5" media.
>
> And that of 5 1/4" media.
Being a computer collector, this is something I have noticed. I can
still read my CP/M disks from the late 70's, my Apple-II disks from the
early 80's, and my C64 disks from the mid 80's. Mind you, half my Amiga
disks, being DD 3.5" from the late 80's, are unreadable. I never quite
understood this. You'd think with the hard plastic shell that these
should still be good. Thinner media perhaps? Narrower track width?
Have fun!
Emil
Herb Johnson
>
> >> FWIW, my experience (and I think that of a lot of others also) is that
> >> the long term (e.g. decades) reliability of 8" media has been far better
> >> than that of 3.5" media.
> >> [...]
>
> > And that of 5 1/4" media.
>
> Being a computer collector, this is something I have noticed. I can
> still read my CP/M disks from the late 70's, my Apple-II disks from the
> early 80's, and my C64 disks from the mid 80's. Mind you, half my Amiga
> disks, being DD 3.5" from the late 80's, are unreadable. I never quite
> understood this. You'd think with the hard plastic shell that these
> should still be good. Thinner media perhaps? Narrower track width?
>
> Have fun!
> Emil
Simply put, what "determines" whether you can read old diskettes is
their age, storage environment, and original quality of manufacturing.
Additionally is the physical stress your floppy drive head puts on the
media, which vary by brand and model and condition of head. There is
much information about this on my Web site. If you want to change the
subject of this thread to "diskette media" or "failure", etc. start
another thread, but first look at prior threads (some recent) in
comp.os.cpm, maybe continue one of those threads.
But 8-inch diskettes can be as old as THIRTY YEARS (1970's); 5.25 inch
disks could be only a few years younger. That's enough time for the
physical qualities of the coating - binder material, lubricants,
presence of mold, thermal cycles - to be challenged. Also, there were
a lot of crappy diskettes produced, in all decades including this
decade. It all comes down to specifics and circumstances.
Herb Johnson
retrotechnology.com
All...@localhost.net
<Watzma...@neo.rr.com> wrote:
>FWIW, my experience (and I think that of a lot of others also) is that
>the long term (e.g. decades) reliability of 8" media has been far better
>than that of 3.5" media. Ok, the 3.5" media has the advantage of being
>decades newer. But we are now at the point at which new computers don't
>have 3.5" drives either, and at which almost no one is still using 3.5"
>drives or media for much of anything.
>
I concur. I have media for my pdp-11/23 from the 70s still at work.
I've had some bad media, usually specific brands and types but
in general I find 8" very reliable.
Now if the drives weren't so heavy, power hungry and a bit noisy that
would help! ;)
Allison
Barry Watzman
Processor Technology Helios disk unit (for those of you who don't know,
this thing is over 2 cubic feet in size and weighs about 60 pounds, due
to a cast metal chassis (all metal, probably bullet-proof), a linear
transformer power supply and the Persci drive).
Him: "JC, this thing is f'ing heavy; what the hell is it"
Me: It's a floppy disk drive
Him: A FLOPPY DISK DRIVE? ARE YOU KIDDING? AND WHAT ELSE?
Me: That's it; a floppy disk drive. well, and power supply.
Him: THAT's F'ING RIDICULOUS.
Me: Hey, they don't build them like they used to. You want to hear
something even more ridiculous?
Him: What?
Me: In 1977, it's price was $2,995.00
There are not enough sailors in the US Navy to contain what followed.
Amardeep S Chana
> Barry Watzman wrote:
>
>> http://www.retrotechnology.com/herbs_stuff/s_persci.html]
>>
>> ..... When I get the [final] details I will put them up on my
>> site and put the link here. - Herb "
>>
>> So, Herb (or Amardeep ....) .... was the final mods and techniques to
>> get a 16FDC to support non-Persci drives ever documented anywhere?
>
> I don't think I got further information, that was five years ago. I
> suggest you contact Amardeep directly and ask him, and let me know
> accordingly. If I have a recent email addresss for him, I'll forward
> the request.
>
I sent mod instructions with some pictures to Randy McLaughlin for
verification since he and I were already working on an RDOS recovery
project pooling all our ROMs and making images. That was going well
until he went offline.
Shortly thereafter an accident left the Xerox 820 I was using as a
terminal and my 16FDC non-functional. Between that and Randy's
disappearance the project faded away.
The 16FDC mod was a couple of trace cuts and wire jumpers. Nothing
difficult. I'll locate the information I sent him and post it here.
Amardeep
Barry Watzman
Amardeep S Chana
>>
>> I sent mod instructions with some pictures to Randy McLaughlin for
>> verification since he and I were already working on an RDOS recovery
>> project pooling all our ROMs and making images. That was going well
>> until he went offline.
Senility must be setting in. After an exhaustive search I've failed to
find any evidence that I actually finished the documentation and sent it
to anyone. Sorry for letting it lapse for so long. I have located the
board and will photograph the mods and write up some instructions.
Amardeep
Amardeep S Chana
> I have located the
> board and will photograph the mods and write up some instructions.
Okay, it is done. This documents three distinct modifications:
1. Support for /ReducedWriteCurrent and elimination of both sides
driving bus pin 12.
2. Support for dual sided drives.
3. Support for 8-inch drives on select 3 and select 4.
I would appreciate it if someone can verify the mods and post results.
The text file with pictures can be accessed here:
http://www.filedropper.com/16fdcmodsforshugart
or here:
http://rapidshare.com/files/343938940/16FDC_ModsForShugart.zip
Thanks,
Amardeep
Herbert Johnson
> Amardeep S Chana wrote:
> > I have located the
> > board and will photograph the mods and write up some instructions.
These results are now on my Web page, where I have an accumulation of
this discussion about the Cromemco 16FDC and Shugart 800 801 support:
http://www.retrotechnology.com/herbs_stuff/16fdc.html
I will host the ZIP file referenced, which is a text description of
the changes and some JPEGs of the changes to the board. I've asked
Amardeep for a schematic image of the changes as well.
Herb Johnson
retrotechnology.com
email me via my Web site, not "gmail.com"
Herbert R. Johnson, New Jersey USA
http://www.retrotechnology.com/ retro-technology home pages
-- S-100, CP/M history by "Dr. S-100"
-- other old tech in iron, glass, rock
domain mirror: retrotechnology.net
email: hjohnson AAT retrotechnology DOTT com