> Date: Sat, 10 May 2008 12:29:24 -0400
> From: Dave McGuire
> I dunno Chuck...the only reason more CP/M systems weren't ROM-
> resident back in the day was due to convention, not technical
> restrictions. I (personally) don't think there's anything
> non-"period" about ROM-ing CP/M.
It's not the ROM-ing of CP/M that disturbs me, but rather the
"disklessness" of the thing. Wasn't the whole idea of CP/M
originally to give you something to manage files on your floppy
drives? I mean, that's what the bulk of the code in CP/M is for--
heaven knows, the support for other I/O is nothing to write home
about.
If one wants to enjoy a "vintage" experience, what sense is there in
being diskless? At any rate, even something as simple as a WD1770-
type controller added to the design would give that capability with a
minimum of support "glue".
Alternatively, one could stay diskless and add a sound-effects module
to emulate the "chunk" and "grrr" of a head-load and seek--and the
"thunk-click" of a drive door being opened and a floppy inserted.
I still don't have the hang of this "vintage" thing yet, probably
because I'm vintage myself. Please forgive my density...
Cheers,
Chuck
-----REPLY-----
Hi Chuck,
I hear what you are saying and agree there is something just very
disconcerting about diskless CP/M computers. However, CP/M in the CBIOS is
really just about block devices and the OS really could care less whether
you attach a 8" SSSD floppy, a CF drive or a ROM. It is all the same to the
BDOS.
My goal here is to *eventually* allow expansion to include IDE and floppy
drives. As a matter of fact, the CBIOS does support IDE hard disks already
but requires the interface IO card and the ECB backplane to attach it to the
SBC. I have an IDE hard disk with CP/M format and some programs on it.
My goal with the SBC using ROM/RAM drives was to allow something minimal to
operate as a SBC and have some functionality with the option to expand to as
desired. I am trying for a modular, low cost approach with easy to build
increments.
Assuming I get this SBC respun and into manufacturing my next project is to
redo my ECB backplane as a PCB. After that will be the disk IO board and
bus debuggers which are also made from prototype boards.
My Test Prototype home brew computer was built entirely with prototype
boards and point to point wiring. It supported IDE drives and even had a
NEC765 FDC circuit built in. I wrote some software but never got around to
test the FDC part since the machine started experiencing reliability
problems which I think trace back to poor grounding and power distribution
issues. The new PCB SBC version seems much more solid than the prototype
did.
The SBC is something which works but gives only limited functionality. If
that is enough, people can stop there. If they want more they can plug it
into the ECB backplane and add peripheral cards. So far only two peripheral
cards exist; the disk IO card and the bus debugger. Hopefully more in the
future. I have some ideas kicking around in my head but am concentrating on
the SBC for now.
Thanks and have a nice weekend!
Andrew Lynch
> Date: Thu, 08 May 2008 07:50:46 -0400
> From: Allison
> I can make the boot process easier as you can plop the rom in
> mappable space. The usual arguement is can you get a Z180
> in a package most people are willing to deal with (64pin dip)?
I wouldn't want to deal with the DIP as it's a "skinny" DIP with
0.050 pin spacing, unlike, say, the 68K. While it probably makes
little difference on a PCB, it requires an adapter if you're
prototyping--and sockets are hard to find. It's easier to use the 68
pin PLCC to keep the spacing--smaller footprint too.
> The latter is the shadow rom many have refered to. I usualy do that.
> And make the rom BIG so not only can I map it in when I want but also
> access part of it (ROMDRIVE).
I believe the Amstrad Joyce uses the printer controller to force the
necessary boot code onto the Z80 bus. (Tony?) At least I've never
seen a boot ROM on a Joyce PCB.
> There is no requriement to boot the system from "disk"
> and making that change can make bring up simpler.
But that's where the "authentic" aspect fails me. Why run a
"vintage" CP/M system without the experience a disk drive gives you?
You'll be deprived of the "BDOS Err on B:" messages. What fun is
that?
One might as well run an emulation program on a PeeCee. I wouldn't
be at all surpised to find that someone's done it for the iPod Touch--
there already exists a NEC 9801 emulator for that platform.
> Deblocking is not too mysterious. The real missing bit in the
> Alteraion guide is how the BDOS telegraphs the need to preread
> and when to skip it.
Page 14, section 12 entitled "Sector Blocking and Deblocking" in the
Alteration Guide covers it pretty well. I remember being relieved to
find the information after I struggled with 1.4 not having any such
mechanism. I don't think it was in 2.0 either, but I can check if
anyone's curious.
Cheers,
Chuck
The drives used in the original IMSAI disk system were Calcomp 140's (this
was with the 2-board IFM/FIB disk controller set). In later versions that
supported double density (with the later DIO/PDS 2-board disk controller
set), these were changed to identical looking (but electrically different)
Calcomp 142's. I have the original Calcomp OEM and service manuals here
.... and I have them both in hard copy and as scanned PDF files (someone
really lucked out .....).
[The drives used by DEC were made for them by Calcomp and had the same
faceplate, but I am not sure if they were the same drives or not ... I don't
think that they were, but I'm not sure of that.]
In the early chassis, Imsai used a Calcomp "PLO" phase locked loop data
separator board for each drive (e.g. two of them ... it was a PC board about
4" x 6"). In later chassis, they figured out how to use one single PLO
board for both drives. In still later implementations, the PLO was
eliminated entirely and data separation was done in the disk controller back
in the computer (this did not happen until the DIO/PDS controller replaced
the IFM/FIB controller).
Also, there was a "short" chassis (early) and a "long" chassis (late).
Originally, the chassis had terrible cooling, and a cooling mod kit was
developed that consisted of some die-cut cardboard vents and baffles as well
as an added fan. The short chassis was too short to house the fan, so when
the cooling mod was retrofitted, the fan went on the OUTSIDE back of the
case. The later "long" chassis was 2" deeper and had the fan on the inside.
In addition to the original Calcomp manuals, I also have an original IMSAI
manual on the disk SYSTEM (the original IFM/FIB controller version, not the
later DIO/PDS controller version). Unfortunately, I have never scanned that
to PDF (it's a bound manual ... I'd have to destroy it).
Note that in the original 2-board disk controller, the IFM board went
through a lot of revisions, and versions earlier than Rev. 6 were junk. The
IFM board is a complete 8080 compute system with it's own 8080 CPU, RAM
(2111's, I think) and ROM (two 2708's, I think). I have source code for the
IFM firmware, I believe. This board did DMA into the "main" 8080 system
memory. It was, for the time, a very elegant design. Unfortunately, it was
slow, it REQUIRED the full original CP/M interleave of 6 to work.
It was (and therefore is) possible to replace the IFM/FIB controller with a
single density Tarbell controller (Western Digital 1771), I did this in a
few systems. The result was a MUCH better disk system. In this mod, the
PLO board(s) were removed entirely, raw unseparated clock and data were fed
back to the [Tarbell single density] controller and the system was 6x faster
(could work with no interleave at all), more reliable, lower power and one
board instead of two. To do this you put a dip plug into the socket on the
Calcomp drives where the PLO had plugged in, that was the only change to the
disk box, which connected to the main IMSAI (or other computer) with a
25-conductor flat ribbon cable (DB-25 at both ends). Then you needed a
custom cable from a DB-25 socket on the back of the IMSAI to the Tarbell
controller, and custom wiring of the Tarbell controller, which was not much
more than a "disk controller prototype board" to begin with. I MAY still
have my notes on the Tarbell jumpering for that configuration. The may, in
fact, be in the PDF file I created of the Tarbell single density manual that
was posted on Howard Harte's site.
Looking for a few SMC COM81C17 UARTS,
to repair some vintage computer equipment.
This is a 20-pin UART.
I don't believe anyone ever made a pin-compatible substitute.
Direct replacement only; not interested in any type of kludge. ;-)
Shoot me an e-mail if you have some, along with a price.
Thanks for your time. . . .
T
-----Original Message-----
From: cctalk-bounces at classiccmp.org
[mailto:cctalk-bounces at classiccmp.org] On Behalf Of Jeff Jonas
Sent: Thursday, May 08, 2008 9:49 PM
To: cctech
Subject: any STD bus users or developers?
I'm getting the itch to get back to Z80 stuff.
Has anyone used the STD bus, or have any parts?
I have a few card cages and cards
but never enough I/O cards!
In the least, I was planning on using the STD bus
just for expansion cards to a single board computer.
-- Jeffrey Jonas
-----REPLY-----
Hi Jeff,
Have you considered STE or ECB bus rather than the STD bus?
STD is a fine bus no doubt but as it uses edge connectors, building
prototype boards is more difficult I think.
STE and ECB bus use a plain DIN 41612 connectors and can be attached to a
plain PCB or prototype board.
There are still companies supporting the STE bus (ARCOM and others) and
some of the parts are still available.
I have found that the selection of the PCB form and bus interface is one
of the most difficult selections and factors involved in building
homebrew computers.
PCBs with edge connectors really drive the costs up because specialized
prototype boards are required or if you manufacture the PCBs using edge
connectors and gold fingers are extra.
Thanks!
Andrew Lynch
Hi Tony,
thanks for responding! Would you feel comfortable to copy the
distribution tape or create a TAR hard disk backup? It would be
a great help.
I'm working on emulating a Zeus system based on the East German
P8000 towers. It would be very interesting to find out how similar
this system actually is to your system. As a background - the East
Germans could not get their hands on a Zeus system directly due to
US export control laws. However, they seem to 've got it anyway -
and so their own Z80, Z8000 ICs as well. Did they actually copy
the system from somewhere and reverse engineered it or did they
write it from scratch no match exactly the original.
Those tapes/disk would be great for reference.
Cheers,
Matt
Tony Duell ard at p850ug1.demon.co.uk wrote:
>
>No real info, alas...
>
>Zeus was supposedly an acronym for Zilog Enhanced Unix System , or
>something similar
>
>I ahve a Zilog S8000 Model 30 (the large-ish tower machine built in
>slices with an SMD hard disk and QIC tape drive). I should have the
>(inary) distriution tape for that somewhere, and I hope the hard disk is
>still readable (I've not used it for some time, it was fine last time I
>used it, and I locked the heads afterwards...). But no source code, or
>even full shcemaitcs (YET!).
>
>-tony
Date: Thu, 8 May 2008 17:32:28 -0400 (EDT)
From: der Mouse
> I think there must be - below some minimum power, pretty much anything
> must go in most bands; otherwise, things like spark plugs in car
> engines would be illegal because they splatter a little power all
> across the RF spectrum. (Not much power, but pretty much clear across
> the band.)
Do you mean that you folks outside of the US were spared Ron Popiel
and "Mr. Microphone"?! Surely you had his "pocket fisherman"... "It
makes the perfect Christmas gift!"
Yes, the US does permit unlicensed very low power transmission on the
radio broadcast bands. I don't recall if there is a specific power
mentioned or simply a propogation distance. Right now, I'm listening
to the Beeb World Service on a radio in the bedroom, thanks to a low-
power FM transmitter attached to the server downstairs.
I don't know if there's a similar provision in UK law, but it might
be worth investigating...
Cheers,
Chuck
