24 Apr
2007
24 Apr
'07
11:02 a.m.
With all of this recent 8-bit and CP/M talk, it's prompted me to do a
little digging on what it would take to put together a CP/'M machine
on my own. I already have a couple of commercially-produced boxes.
This is about taking a Z-80, some RAM, some ROM and a storage unit and
making it run CP/M.
I've been reading the various threads, so I have a general idea of
what has to happen, but I'm still fuzzy on a few specifics, no doubt
due to my lack of deep experience with the Z-80.
The point of ROM vs RAM at $0000 has been gone over a few times. Do
"standard" CP/M machines use a shadow-ROM technique, or what, to
cold-start? We used to use a trick with the 68000 that would map ROM
at $000000, _and_ at some higher address, with the first few
instructions jumping to the higher ROM image, , and either an I/O pin
that toggled the address mapping for the lower ROM image, or just
watching for the first pulse from A23, such that the act of jumping up
to the higher ROM address itself would remove ROM from the bottom of
the memory map, revealing RAM.
How did CP/M systems handle 64K of RAM? Was there one primary way it
was done, or did every hardware vendor do it differently? I should
probably just confine my efforts to 48K of RAM and use the upper 16K
for a boot ROM, but if it's easy to support 64K of RAM, why not?
To confirm, the minimal I/O system is some flavor of serial interface
for console I/O (presumably piped to a display smart enough to handle
ANSI codes), and some form of block-addressable storage with a CP/M
filesystem, right? (I'm ignoring handy I/O like parallel printer
ports and 8255-type GPIO and the like, for the moment) Is it required
that the storage unit be writable? Is there a minimum size for the
display? That wouldn't matter for hanging a VT100-equivalent off of
the console port, but if I were to use some flavor of textual LCD, it
would very much matter. To find another way to ask, would the body of
extant CP/M apps freak out if you try to run them on a display that's
under 40 chars wide or under 24 chars tall? Do they expect 64 chars
wide or 80 chars wide? I don't think the OS itself actually cares how
wide or tall the display is, but perhaps some of the CUSPs, like DIR,
might.
Rather than taking a bare Z80, wiring on a Z8530, an SRAM or two and
an EPROM, I was contemplating beefing up my 1976 SDS Z-80 Starter Kit
to the point where it could run CP/M. I've written about it here
before, when I first got it, to remind those that don't know or don't
remember what it is, it has a ~2MHz Z80, 1K of 21L02 SRAM, room for
one more K, one 2716 with "ZBUG", two empty 2716 sockets (one attached
to an EPROM programming circuit), a keypad and 7-segment LEDs, a
largish wire-wrap area, and two S-100 slots. Presuming I wire the
SRAM, a larger-capacity EPROM, and some serial device into the
wire-wrap area, is there anything I should look for in an S-100 card
that would be interesting to install? A video card (rather than a
serial console), perhaps? I think I have one or two S-100 video
cards, but I was never clear on how one attaches a keyboard to that
rig - is there an ASCII keyboard port typically provided on an S-100
video card, or is that a separate peripheral?
Thanks for any and all answers to my noobish CP/M questions,
-ethan
24 Apr
24 Apr
12:35 p.m.
The point of ROM vs RAM at $0000 has been gone over a
few times. Do
"standard" CP/M machines use a shadow-ROM technique, or what, to
cold-start? We used to use a trick with the 68000 that would map ROM
at $000000, _and_ at some higher address, with the first few
instructions jumping to the higher ROM image, , and either an I/O pin
that toggled the address mapping for the lower ROM image, or just
watching for the first pulse from A23, such that the act of jumping up
to the higher ROM address itself would remove ROM from the bottom of
the memory map, revealing RAM.
There are many ways to accomplish getting RAM at 0, even though the CPU
has to boot from there.
Some systems force a JMP instruction onto the BUS during the first three
fetches, which transfers control to a ROM at a higher location.
An easy technique is to have the boot ROM appear in two places (0 and
somewhere else), and remove the select at 0 (replacing it with RAM)
after the first three fetches - the first instruction in the boot ROM
has to be a JMP to the actual boot ROM address (+3, otherwise you would
infinite loop on the startup JMP). One simple way to do this is to use
the select for the higher location to disable the zero one (which will
occur immediately after you JMP there).
The problem with either of those is that the ROM remains in the memory
map and takes up valuable RAM space.
I prefer to have the ROM copy itself to RAM, jump there, and then disable
the physical ROM via an I/O event - that way you are running from RAM, and
once booted, have a full 64k available to the OS (which must not reference
the boot ROM for I/O obviously).
How did CP/M systems handle 64K of RAM? Was there one
primary way it
was done, or did every hardware vendor do it differently? I should
probably just confine my efforts to 48K of RAM and use the upper 16K
for a boot ROM, but if it's easy to support 64K of RAM, why not?
CP/M covers a wide array of hardware - lots of different memory configurations,
although typically you must have ram at 0000 and it must extend contiguously
upward from there - the more the better. Many system has "holes" for memory
mapped I/O, video, disk (N* controller comes to mind). In general, as much as
you can arrange in a contiguous block from 0000 up is best.
To confirm, the minimal I/O system is some flavor of
serial interface
for console I/O (presumably piped to a display smart enough to handle
ANSI codes), and some form of block-addressable storage with a CP/M
filesystem, right? (I'm ignoring handy I/O like parallel printer
ports and 8255-type GPIO and the like, for the moment) Is it required
that the storage unit be writable? Is there a minimum size for the
display? That wouldn't matter for hanging a VT100-equivalent off of
the console port, but if I were to use some flavor of textual LCD, it
would very much matter. To find another way to ask, would the body of
extant CP/M apps freak out if you try to run them on a display that's
under 40 chars wide or under 24 chars tall? Do they expect 64 chars
wide or 80 chars wide? I don't think the OS itself actually cares how
wide or tall the display is, but perhaps some of the CUSPs, like DIR,
might.
CP/M itself is just a TTY interface - so it will run on just about any
format display - applications however are a different story, and as there
was no standard, there is no complete answer to your question. 80x24 as
probably as close to "standard" as you will get, and would give you the
maximum compatibility. You will also want a decent set of control codes
(cursor position, clear screen, clear to end of screen/line etc.). A TTY
that emulates some well known terminal from the era may make things
easier as many apps had prevonfigured setups for common TTYs.
Rather than taking a bare Z80, wiring on a Z8530, an
SRAM or two and
an EPROM, I was contemplating beefing up my 1976 SDS Z-80 Starter Kit
to the point where it could run CP/M. I've written about it here
before, when I first got it, to remind those that don't know or don't
remember what it is, it has a ~2MHz Z80, 1K of 21L02 SRAM, room for
one more K, one 2716 with "ZBUG", two empty 2716 sockets (one attached
to an EPROM programming circuit), a keypad and 7-segment LEDs, a
largish wire-wrap area, and two S-100 slots. Presuming I wire the
SRAM, a larger-capacity EPROM, and some serial device into the
wire-wrap area, is there anything I should look for in an S-100 card
that would be interesting to install? A video card (rather than a
serial console), perhaps? I think I have one or two S-100 video
cards, but I was never clear on how one attaches a keyboard to that
rig - is there an ASCII keyboard port typically provided on an S-100
video card, or is that a separate peripheral?
A video card will chew up valuable RAM, and many of them are only 16x64,
but it does let you do real-time screen updates, games etc.
Some video cards had a parallel keyboard port, many didn't - Usually it
was just an 8-bit parallel port with 7 data bits for the ASCII keycode,
and the 8th bit used for a key down/up indicator. You could also have a
serially interfaced keyboard.
The important thing to understand is that CP/M doesn't specify a display
or keyboard - pretty much any interface you might decide on can be made
to work under CP/M (within reason of course).
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
12:01 p.m.
On 4/24/07, Dave Dunfield <dave06a at dunfield.com> wrote:
I'm with you there.
The point of
ROM vs RAM at $0000 has been gone over a few times. Do
"standard" CP/M machines use a shadow-ROM technique, or what, to
cold-start?
There are many ways to accomplish getting RAM at 0, even though the CPU
has to boot from there. Some systems force a JMP instruction onto the BUS
during the first three
fetches, which transfers control to a ROM at a higher location.
That seems like it would take a bit of extra circuitry to do.
An easy technique is to have the boot ROM appear in
two places (0 and
somewhere else), and remove the select at 0 (replacing it with RAM)
after the first three fetches...
Hmm... that's a trick I haven't seen used in the 68000 world.
The problem with either of those is that the ROM
remains in the memory
map and takes up valuable RAM space.
Right. That much I get... so once CP/M is running, it's ordinary not
to refer to the boot ROMs? There's typically not a requirement to
keep some low-level BIOSy stuff in ROM?
That certainly takes care of how to handle 64K of RAM - just get rid
of the ROM from the memory map as soon as possible. With my other
experience with 8-bit micros, I didn't expect that this was a viable
techique. The systems I am familiar with pretty much require that you
keep the ROMs around - even with the C-64, which will let you bank out
ROMs and run from RAM, folks didn't tend to completely ditch the
Kernel ROM. Of course, Commodore machines don't have a "real"
operating system as such, and not even a DOS in the sense of an Apple
II or a TRS-80 - the routines in the ROM were commonly used by
applications like Zork that didn't care about BASIC, but they did care
that the ROMs had enough low-level I/O stuff to read and write disk
blocks, etc.
CP/M covers a wide array of hardware - lots of
different memory configurations,
although typically you must have ram at 0000 and it must extend contiguously
upward from there - the more the better.
Right. I know that there are *many* CP/M hardware configurations; I
am trying to get down the nub of as minimal a hardware design as
possible.
> To confirm, the minimal I/O system is some flavor
of serial interface
> for console I/O (presumably piped to a display smart enough to handle
> ANSI codes), and some form of block-addressable storage with a CP/M
> filesystem, right?
CP/M itself is just a TTY interface - so it will run
on just about any
format display - applications however are a different story, and as there
was no standard, there is no complete answer to your question. 80x24 as
probably as close to "standard" as you will get, and would give you the
maximum compatibility.
OK. That's not unexpected.
You will also want a decent set of control codes
(cursor position, clear screen, clear to end of screen/line etc.). A TTY
that emulates some well known terminal from the era may make things
easier as many apps had prevonfigured setups for common TTYs.
Sure. For the minimal system I have in mind, I'm planning on a VT100
or some modern machine running a terminal emulator (Kermit, et al.) to
handle screen formatting.
A video card will chew up valuable RAM, and many of
them are only 16x64,
but it does let you do real-time screen updates, games etc.
Ah... now we are onto something - games... are there many games for
CP/M that require a video card, or were most happy with whatever sort
of TTY-type device (ANSI codes or not) was out there?
Thanks for the clarification, Dave,
-ethan
12:35 p.m.
On 24 Apr 2007 at 12:01, Ethan Dicks wrote:
Right. That much I get... so once CP/M is running,
it's ordinary not
to refer to the boot ROMs? There's typically not a requirement to
keep some low-level BIOSy stuff in ROM?
Nope. CP/M installations are typically self-contained, though there
are a few systems that keep ROM around for I/O servicing. Since
you'll be writing your own boot code, you can do ROM mapping however
you'd like. A simple way is to keep your boot code and monitor at
0000 and have the boot routine from diskette simply unmap the ROM.
Note that the CBIOS code (which not only provides I/O, but also loads
the rest of the operating system is located in high memory and
doesn't require anything in low memory to get going.
One caution here. If you need interrupt service (say, if you're
interfacing a PC keyboard), do not give in to the temptation to use
the Z80 NMI line. NMI vectors to 0066H, which happens to be right in
the middle of FCB2. There are some very messy workarounds for this
for some systems, but the best thing to do is to avoid it. Use a
"regular" interrupt if you need one.
I think that the old Tarbell disk controller used a 82S23 bipolar ROM
to read one sector from disk. That's only 32 bytes, but it was
enough.
Cheers,
Chuck
3 p.m.
The problem
with either of those is that the ROM remains in the memory
map and takes up valuable RAM space.
Right. That much I get... so once CP/M is running, it's ordinary not
to refer to the boot ROMs? There's typically not a requirement to
keep some low-level BIOSy stuff in ROM? That certainly takes care of how to handle 64K of RAM
- just get rid
of the ROM from the memory map as soon as possible. With my other
experience with 8-bit micros, I didn't expect that this was a viable
techique. The systems I am familiar with pretty much require that you
keep the ROMs around - even with the C-64, which will let you bank out
ROMs and run from RAM, folks didn't tend to completely ditch the
Kernel ROM. Of course, Commodore machines don't have a "real"
operating system as such, and not even a DOS in the sense of an Apple
II or a TRS-80 - the routines in the ROM were commonly used by
applications like Zork that didn't care about BASIC, but they did care
that the ROMs had enough low-level I/O stuff to read and write disk
blocks, etc.
Again, think in terms of a box with a power supply and bus, and everything
else changable ... That was the environment CP/M was designed to address.
A C64 or any of a zillion other single-board computers have a much more
predefined environment, and often that environment is "software unfriendlty"
in order to make it cheaper - in such an environment, the ROM is much more
likely to be useful, and hence used by an OS or other system application.
Even so - It is not uncommon to completely eliminate the ROM and use OS
resident drivers once the OS starts up, as this saves space and allows for
a fuller RAM map.
A video card
will chew up valuable RAM, and many of them are only 16x64,
but it does let you do real-time screen updates, games etc.
Ah... now we are onto something - games... are there many games for
CP/M that require a video card, or were most happy with whatever sort
of TTY-type device (ANSI codes or not) was out there? 
26 Apr
26 Apr
10:10 a.m.
From: "Dave Dunfield" <dave06a at
dunfield.com>
No, in most (but not all) CP/M systems, the CP/M BIOS is not dependant on
the boot ROM.
Unlike a PC, where the ROM contains more-complicated-than-it-needs-to-be
general purpose code to control all kinds of hardware, a typical S-100 CP/M
boot rom contained just enough code to read one sector from a drive and
jump to it. This goes back to the days of wildly varying S-100 cards...
The guy who wrote the boot rom (the disk controller maker) only knew for
sure how to talk to one bit of hardware in your system (his disk
controller).
---snip---
Hi
As an example, my IMSAI has no ROM at all and I run CP/M. The disk
controller uses DMA to the IMSAI's RAM. On reset, the controller will
transfer the first sector into the 0000 address of the IMSAI. I have
code on the first sector that loads the rest of what is needed for CP/M
and it then jumps to that code.
The controller was made by a company called Digital Systems and
does have its own state engine run from ROMs in the controller.
Dwight
_________________________________________________________________
Need a break? Find your escape route with Live Search Maps.
http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&am…
The
problem with either of those is that the ROM remains in the memory
map and takes up valuable RAM space.
Right. That much I get... so once CP/M is running, it's ordinary not
to refer to the boot ROMs? There's typically not a requirement to
keep some low-level BIOSy stuff in ROM? 
24 Apr
24 Apr
3:36 p.m.
On Tue, 2007-04-24 at 12:01 -0400, Ethan Dicks wrote:
Video card manufacturers often produced games. Probably the most
common target video card was the VDM-1 card, as in the Sol-20 by
Processor Technology. I have one of those cards in my IMSAI. 16x64,
and takes up 1 K of memory. I've seen boots that involve a VDM-1, and
one 2708 (1K EPROM) that leaves 62K for RAM, and uses the VDM-1 memory
for stack during boot, IIRC. Ugly, but it works. VDM-1 cards require
S-100 bus, or massive hacking. That makes them, probably, outside the
parameters of the "quickest and cheapest" setup you've set.
Peace,
Warren E. Wolfe
wizard at voyager.net
Right. That much I get... so once CP/M is running,
it's ordinary not
to refer to the boot ROMs? There's typically not a requirement to
keep some low-level BIOSy stuff in ROM?
No, there is no requirement to keep ANY ROM available after boot.
It is preferable, in most cases, to have the entire address space made
up of RAM once the system is actually running, as opposed to booting.
Some cases involve copying the ROM contents to RAM during boot, and then
disabling ROM. Again, as has been implied, EVERYBODY chose their own
method -- some were better than others, naturally enough. As a matter
of fact, for those systems which implement ROM at 0000 for booting, the
ROM *MUST* be disabled for any even half-way normal CP/M system to run.
(See the previous discussions on CP/M for Radio Shack Models)
Right. I know that there are *many* CP/M hardware
configurations; I
am trying to get down the nub of as minimal a hardware design as
possible.
CPU, 64k RAM, disk(ette) controller, ROM able to be disabled (could
be on controller), serial port. Anything else is gravy.
Sure. For the minimal system I have in mind, I'm
planning on a VT100
or some modern machine running a terminal emulator (Kermit, et al.) to
handle screen formatting.
Perfect.
A video card
will chew up valuable RAM, and many of them are only 16x64,
but it does let you do real-time screen updates, games etc.
Ah... now we are onto something - games... are there many games for
CP/M that require a video card, or were most happy with whatever sort
of TTY-type device (ANSI codes or not) was out there?
5:10 p.m.
On 4/24/07, Warren Wolfe <wizard at voyager.net> wrote:
On Tue, 2007-04-24 at 12:01 -0400, Ethan Dicks wrote:
Fair enough. Any really interesting ones to recommend?
Ah... now we are onto something - games... are
there many games for
CP/M that require a video card, or were most happy with whatever sort
of TTY-type device (ANSI codes or not) was out there?
Video card manufacturers often produced games. Probably the most
common target video card was the VDM-1 card... VDM-1 cards require
S-100 bus, or massive hacking. That makes them, probably, outside the
parameters of the "quickest and cheapest" setup you've set.
My SDS Z80 Starter Kit already has two S100 slots built in, so the
only expense to outfit that one is a 100-pin backplane connector.
I'll keep it in mind as an upgrade for later.
Thanks,
-ethan
6259
days inactive
6261
days old
7 comments
5 participants
participants (5)
-
cclist＠sydex.com -
dave06a＠dunfield.com -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
wizard＠voyager.net