>
>Subject: RE: Minimal CP-M SBC design
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Sun, 11 May 2008 10:24:57 -0700
> To: cctalk at classiccmp.org
>
>> Date: Sat, 10 May 2008 08:26:41 -0400
>> From: Allison
>
>
>> Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember
>> why you hate that.
>
>Or doing "ASM BIGFIL.ASM" or even just "ASM". I got into the habit
>of using M80/L80 as soon as I got my hands on a copy. DRI assemblers
>(even RMAC) weren't any great shucks.
>
>> But then I wa an early adptor of hard disk and from late '80 on
>> had at least a 5mb drive to avoid that. Is that less authentic?
>> By the end of 1981 I'd built a system with romdisk and ramdisk
>> and no floppy or har disk. Was that authentic?
>
>I think I failed to make my point well enough. Almost all the people
>who worked with CP/M initially did so in the context of floppy disks.
>Someone attempting to duplicate that experience would get a less-than-
>authentic experience without that aspect, in much the same way one
>would be deprived of the experience of big mainframe iron without the
>machine room noise level. Could you get a true experience of running
>OS/360 without a card reader? An authentic experience consists of
>all aspects of the experience, not just the convenient or pleasant
>ones. Without the whole, one gets a "dude ranch" picture.
For the latter without the card reader you couls substitute the tape
or even first floppy based job feeds.
As to CP/M if you want the pain oops wrong disk grab an old PC and
dont use hard disk with DOS. IT's somthing that one likes to
forget quickly.
Floppies and CP/M the major issues were lack of space, not enough drives
and some cases systems that could crunch (on power off or power fail)
media left in drive (data lost). Authentic yes, get as much done NO.
Every ones had to learn those fast and after that it was part fo the
psyche and largely forgotten save for lack of space and not enough dives.
>> What is authentic? To me if the platform has 8080, 8085,
>> Z80, Z180/64180, Z280, or NSC800 it's running on real iron. Of
>> course if you have a Z380 or eZ80 in native mode or a NEC V20
>> in 8080 mode those may count too.
>
>No, one gets extra bugs with a V20 that the 8080 never had.
;) but they are Authentic.
>> 1.4 really didn't even do a DISK bios, it was embedded in the bdos.
>> the bios for 1.4 was only terminal, punch reader and printer IO.
>> Yes, it ws a pain to interface any new disk to it.
>
>Not according to my archives. While it's true that the 1.4 BIOS
>lacked the configurability of 2.0/2.2 (i.e. there were no DPBs, etc.
>to define your own disk format), it contained the disk access code
>(e.g. SELDSK, SETTRK, etc.) If you'd like, I can send you a copy of
>the CBIOS that came with my Tarbell controller, complete with
>Processor Technology video board driver (which I didn't use). It's
>remarkable in one aspect--it allows for simulated 2-drive operation
>on one drive by prompting for the A: or B: floppy when required.
>
I have 1.4 for 8" and NS* Horizon (still running!) and their
respective manuals. Your right I forgot that NS* created a
second level bios strictly for the terminal, printer, punch, reader
part of the interface. That part if the ihterface is very lightly
doumented in my Alteration Guide.
>CP/M 1.4 had the right idea--it supported only one diskette format,
>so if you had more than 250K of storage, you were pretty much forced
>to accommodate this by simulating multiple floppy drives. (Wasn't
>there an early system that used an IMI "shoebox" drive for the Apple
>II that simulated about 50 floppies?) Where things got out of hand
>is when DRI said "Roll your own" with no guidance as to disk format
>standards.
>
>> It is in 2.0 (deblocking). However their explanation is thin and
>> some of the fine details have to be infered by really reading the
>> code. It was very mysterious when I did it for the first time back
>> in '80 when I was working with a early sample 765 DD FDC. It was
>> later that Andy Johnson-Laird wrote The Programmers CP/M Handbook
>> which covers the subject in much greater detail and has two BIOS
>> exammples that are very commented.
>
>It's been years since I've chatted with Andy. My acquaintance with
>him began after his book, however and I hadn't even realized that
>he'd done anything with CP/M.
>
I'd say he write "the book" that explains things from both the
bios/systems perspective and the applicatiosn programmers eye view.
It's the book I refer everyone too after the Alteration Guide has
confused, narrowed and limited their view of what can be done.
I've always maintained that CP/M was a UI and filesystem mostly
and there was little it prevents and mostly allowed anything.
It did a far job of hardware abstraction and mostly kept out
of the way.
Allison
>Cheers,
>Chuck
>> I guess there's nothing quite like the not invented here syndrome.
>
> Certainly some of that, but more in Appletalk v2 and than original
> Appletalk. To my mind the original appletalk was simple and elegant
> - a
> good fit for the system...
At a company I worked at we looked at Ethernet at the time, and it
simply was
way too pricey compared to AppleTalk at the time. Phone wire was
cheap,
and the office spaces we had were already wired up for two phone
jacks, so
it simply was a matter of isolating the punch down blocks for which
jacks to use.
(Luckily the folks who wired up the spaces put all the even numbered
jacks
on the same blocks, odds on the others... ) For the cost of one
ethernet card
(for the one machine we had that actually could take one) we wired up
two
offices, probably a couple hundred machines. (Mostly Mac's of course...
but ultimately a few Caymen Gator boxes to bridge to the small ethernet
segments that supported our Sun boxes...which had ethernet built in..)
It was chatty, protocol wise, but a very cost effective way to network
things
at the time...
I've actually got a NEW in the box Farallon PhoneNet (which was yet
another name for it..)
Star Controller sitting here. (I tried to sell it on EBay recently
but apparently nobody has any
of these networks that I can find. ) It's about to go into the
recycler pile...
(if someone is interested, drop me a line...)
Earl
> Date: Sat, 10 May 2008 21:07:12 -0700
> From: dwight elvey
> The metal blades will dull quickly on fiberglass boards. The cutting
> disk will work but tend to gum up.
You can do a lot of damage with a Dremel, the big problem being that
it's hand-held. This is one case where I might be tempted to use a
jeweler's frame saw and use as many blades (they're very cheap) as
needed to get the job done. Alternatively, a small carbide bit in a
table-mounted router would do the job in a jiffy.
Personally, I'd just find out if the IC was available in PLCC.
Cheers,
Chuck
> Date: Sat, 10 May 2008 20:50:33 -0400
> From: "Roy J. Tellason"
> Oh, and these aren't STD bus, which is 56 pins rather than 22/44. :-)
Yeah, I know. My wondering was that there was an abundant common
source of small-profile cards that might be adapted to an 8-bit bus
and wondering if they were still common at all.
Although there are fewer pins, I do remember mounting a small "sub-
bus" in my MITS 8800 using these as a "cheap" expansion for little
peripheral projects where an S-100 card was overkill. I basically
brought the 8 bits of data and 8 bits of address out with the I/O
port handshaking lines to a card. Most peripherals don't need access
to RAM I/O space anyway.
Does anyone recall what the original application of the 22/44 cards
was? I suspect industrial control or maybe telco switching.
Cheers,
Chuck
> Date: Sat, 10 May 2008 08:26:41 -0400
> From: Allison
> Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember
> why you hate that.
Or doing "ASM BIGFIL.ASM" or even just "ASM". I got into the habit
of using M80/L80 as soon as I got my hands on a copy. DRI assemblers
(even RMAC) weren't any great shucks.
> But then I wa an early adptor of hard disk and from late '80 on
> had at least a 5mb drive to avoid that. Is that less authentic?
> By the end of 1981 I'd built a system with romdisk and ramdisk
> and no floppy or har disk. Was that authentic?
I think I failed to make my point well enough. Almost all the people
who worked with CP/M initially did so in the context of floppy disks.
Someone attempting to duplicate that experience would get a less-than-
authentic experience without that aspect, in much the same way one
would be deprived of the experience of big mainframe iron without the
machine room noise level. Could you get a true experience of running
OS/360 without a card reader? An authentic experience consists of
all aspects of the experience, not just the convenient or pleasant
ones. Without the whole, one gets a "dude ranch" picture.
> What is authentic? To me if the platform has 8080, 8085,
> Z80, Z180/64180, Z280, or NSC800 it's running on real iron. Of
> course if you have a Z380 or eZ80 in native mode or a NEC V20
> in 8080 mode those may count too.
No, one gets extra bugs with a V20 that the 8080 never had.
> 1.4 really didn't even do a DISK bios, it was embedded in the bdos.
> the bios for 1.4 was only terminal, punch reader and printer IO.
> Yes, it ws a pain to interface any new disk to it.
Not according to my archives. While it's true that the 1.4 BIOS
lacked the configurability of 2.0/2.2 (i.e. there were no DPBs, etc.
to define your own disk format), it contained the disk access code
(e.g. SELDSK, SETTRK, etc.) If you'd like, I can send you a copy of
the CBIOS that came with my Tarbell controller, complete with
Processor Technology video board driver (which I didn't use). It's
remarkable in one aspect--it allows for simulated 2-drive operation
on one drive by prompting for the A: or B: floppy when required.
CP/M 1.4 had the right idea--it supported only one diskette format,
so if you had more than 250K of storage, you were pretty much forced
to accommodate this by simulating multiple floppy drives. (Wasn't
there an early system that used an IMI "shoebox" drive for the Apple
II that simulated about 50 floppies?) Where things got out of hand
is when DRI said "Roll your own" with no guidance as to disk format
standards.
> It is in 2.0 (deblocking). However their explanation is thin and
> some of the fine details have to be infered by really reading the
> code. It was very mysterious when I did it for the first time back
> in '80 when I was working with a early sample 765 DD FDC. It was
> later that Andy Johnson-Laird wrote The Programmers CP/M Handbook
> which covers the subject in much greater detail and has two BIOS
> exammples that are very commented.
It's been years since I've chatted with Andy. My acquaintance with
him began after his book, however and I hadn't even realized that
he'd done anything with CP/M.
Cheers,
Chuck
To all,
Found this while cleaning out some old S100 stuff.
A source listing for the 8080 Zapple Monitor from Computer Design Labs, Trenton, NJ
dated 1979 and 1980. Funny it is named the "Apple" monitor, I supposed maybe Apple
was not pursuing naming IP as it did later..
The listing is bound in a spiral type binding and I believe I purchased it sometime in
that time frame. I'm feeling a bit old now.... It is free (plus S&H) to the first to reply.
Dan, Butler, PA
RE: "1.4 really didn't even do a DISK bios, it was embedded in the bdos.
the bios for 1.4 was only terminal, punch reader and printer IO. Yes, it
was a pain to interface any new disk to it."
Allison, that is simply not true. The diskette format (DPH and DBP) was
imbedded in the BDOS, but the disk I/O was in the BIOS, more or less like
2.x.
>
>Subject: Re: RE: Minimal CP-M SBC design
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Fri, 09 May 2008 09:36:31 -0700
> To: cctalk at classiccmp.org
>
>> 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.
Cant argue with that but many are put off by that and discard
playing with Z180.
>> 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.
Ther are a lot of way s to stuff in code, the real trick is doing
with few parts as wirewrapping or other build strategies are labor
intensive and "kitting with a board" is cost sensitive.
>> 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?
Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember
why you hate that.
But then I wa an early adptor of hard disk and from late '80 on
had at least a 5mb drive to avoid that. Is that less authentic?
By the end of 1981 I'd built a system with romdisk and ramdisk
and no floppy or har disk. Was that authentic?
What is authentic? To me if the platform has 8080, 8085,
Z80, Z180/64180, Z280, or NSC800 it's running on real iron. Of
course if you have a Z380 or eZ80 in native mode or a NEC V20
in 8080 mode those may count too.
But what about 68000 or Z8000 runing CP/M they exist too? The
problem there being they are file system compatable but neither
can ran any of the vast library of CP/M 80 code base.
>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.
I'd argue that CP/M on an iPOD is not close to a useful experince.
For one without a keyboard the interaction is via GUI that could
never have existed back when on anything Z80. That falls into
cool hack catagory right up there with using a WRT54GL as a
wireless web server.
There are many emulators the classic ones and some really useful
ones too. I'd argue for playing with aps a SIM on PC is valid
enough. I'd also for hacking hardware a sim on PC is bogus. I
never figured out a way to simulate a board of random logic to
emulate a process control card adn plug that into a sim complete
with simulated stimulus. For me and I may be atypical I use both.
I use the PC with MyZ80 or Daveid Dunfields N*Horizon and of
course SIMH as software test platforms and even as portable
CP/M when I've forgotten to bring my PX-8. But I also use
those SIMs to build real platforms with 8085 or Z80. And there
is a different feel, real or perceived, to running on real iron
even if the iron is a 10mhz Z80 with 64k of ram and 512kb of ram
disk and 32mb of CF or my NS* Horizon built in '78 with a 32mb
hard disk, 5.25" floppy and 8" floppy.
>From a modern perspective, regardless of the hardware used be it
CF or a SA800 programming the BIOS is a mystery or stopper for
many as for all the people out there writing code few ever get
that close to the metal. That makes the real iron a challange.
>> 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.
>
1.4 really didn't even do a DISK bios, it was embedded in the bdos.
the bios for 1.4 was only terminal, punch reader and printer IO.
Yes, it ws a pain to interface any new disk to it.
It is in 2.0 (deblocking). However their explanation is thin and
some of the fine details have to be infered by really reading the
code. It was very mysterious when I did it for the first time back
in '80 when I was working with a early sample 765 DD FDC. It was
later that Andy Johnson-Laird wrote The Programmers CP/M Handbook
which covers the subject in much greater detail and has two BIOS
exammples that are very commented.
Allison
>Cheers,
>Chuck
Why not wait for the WiMax cards that are due out later this year? Allegedly they have a range of about 30 miles!
:)
Then most of us in the UK can interconnect our computers, hehe.
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
As I think most of you know, I have a fairly diverse collection of
classic computers (I suspect some others do too).
Quite often I need to transfer data between 2 machines. Maybe to
download a file from this PC, which I've in turn downloaded from a web
site, to run on one of the classics. Maybe to print out some listing from
a classic. Whatever.
My machines vary in size from the pocket computers up to machines that
it's not practical to move. They're scattered throughout a house. They
are, alas, not in a machine room. Most of the machines (and all the ones
I want to consider for this) have an RS232 port, either built-in or as an
option (which I have). Most of the machines run kermit. Or I can simply
print to the RS232 port on one machine and capture the incoming
characters on the other
So, I think the problem reduces to 'how to interconnect RS232 ports'. let
me add some constraints :
Must work over a distance longer than the RS232 spec allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
Prefereably no cables at all. One solution I've come up with is to use a
couple of line drivers and a long cable between them. A long cable that
my parents, or the cat, will get tangled up in :-(
No line-of-sight between the machines
Must work at 300 and 1200 baud. 110 and 9600 baud would be a bonus
I only need one pair of machines linked at a time. I don't need a
network. So if the solution involves a radio link, the fact that there's
only one channel available would not be a problem.
Must not make use of any flow control lines on the RS232 port, since some
of my machines don't support them.
Using classic, or at least repairable, hardwre is a bonus :-)
I said 'RS232'. I mean asynchronous serial, of course :-). If somebody
has a solution for TTL or 3.3V level serial ports, I can trivially
convert the signal levels
I've been looking at some of the license-exempt radio modules, but they
either are half-duplex or amke use of the flow control lines (typically
they buffer <n> bytes internally, then de-assert a flow control line
while they pack up that data and send it to the other end).
So far the best I've come up with is to link one machine to a palmtop
(HP95LX), then transfer the data to that, carry the palmtop to the other
machine and transdfer the data on. It's not ideal, but it does work.
Any other ideas?
-tony
