Bringing up CP/M on a new computer
Lee Hart
computers have all ran a BIOS that somebody else wrote. This has always
produced limitations. The author was invariably in a hurry, or lacked
knowledge, or just wasn't all that competent. The result is that there
are always bugs, or limitations, or problems. And, they can be VERY
difficult to fix, as the author is unknown and the source code is
unavailable.
I like the Heathkit H8 and H89 computers' implementation of CP/M. They
distributed commented source code. They included a program, MAKEBIOS,
that allowed you to select the hardware you actually had installed on
your computer, and then automatically assembled a BIOS to suit. They
also included CONFIGUR, a program to reconfigure an existing BIOS for
things like number and type of disk drives, serial port formats, etc. It
supports many disk formats, so I can exchange disks with a lot of
different machines. Finally, it is pretty robust and bug-free; it don't
crash, or hang if there are disk errors, etc.
I also have an IMSAI S-100 system. It is a much nicer computer
hardware-wise (8 MHz Z80, more memory, more I/O, front panel, easily
expandable, etc.). But frankly, the H89 gets all the use because of that
excellent BIOS.
So here are the questions:
1. Can I bring up the Heath BIOS on the IMSAI? Any advice on the
approach
you would take? What software is needed?
2. Can I keep the structure of the Heath BIOS, to allow interchangeable
modules to support different hardware, so any "idiot" can select and
install them?
If possible, I'd like to make this BIOS public domain, so *anyone* could
use it to bring up CP/M on whatever odd collection of boards they have
in their S-100, or other CP/M-capable computer.
What do the experts think?
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
Bruce Jones
respects, but a few obstacles must be overcome:
- For the most part serial and parallel I/O should be easy as it is all 8
bit with simple status checks
- The difficult part will be DISK I/O!!!
a) floppy disk I/O - the command set for the FDD chip must be known, and the
port address of the chip must be known
b) hard drive I/O - same as for the floppy I/O
There were few floppy controllers on the market when IMSAI was built, but
the I/O locations could vary.
There were lots of hard drive controllers since many types of hard drives
were connected to CP/M systems.
Unless you can provide disk I/O routines for every FDC and HDC that will be
used it is hard to see how a universal BIOS can be released. BTW a few
authors of BIOS did have conditional assembly to cover a small range of
controller cards and popular I/O boards.
SCSI provided a partial solution, and I implemented it in BIOS and XIOS code
from 1980 to 1993. What you get is a common command set and a simple 8 bit
interface. A problem today is that most if not all SCSI drives are 16 bit.
To use them a small I/O circuit would have to be made ( unless there is and
extended SCSI command to switch the I/O to 8 bit ?! ).
=============================
If you want, you can email me the present IMSAI BIOS that causes you some
trouble and I will examine it for bugs, make changes as needed and let you
know. Price? $0.00 as I am curious about how a BIOS can be buggy. Be sure to
give me a list of bugs you notice with the IMSAI BIOS, since it is nice to
have a starting point for the bug search.
Also if you can email me the Heathkit source ( zipped ) I will add it to my
museum of BIOS code.
==============================
From 1979 to 1993 I wrote BIOS and XIOS code to support a large number of
hardware configurations, so I believe I can assist you in getting a bug free
BIOS.
Regards
Bruce
Tim Shoppa
> 1. Can I bring up the Heath BIOS on the IMSAI?
Not really. The most important part is the disk driver, and if
this is different at all, then CP/M isn't going to even be loaded.
> Any advice on the approach
> you would take?
Having the Heath up and running next to the IMSAI will prove
valuable, because you'll be able to do your assemblies there,
write them to floppy, move the floppy to the IMSAI, and test.
If you can move the IMSAI's disk controller to the Heath for testing
your disk I/O primitives, that's even better.
> What software is needed?
None is *needed*. If you look at the _CP/M Customization Guide_ that
came with your copy of CP/M, you'll see they walk you through,
step by step, in installing CP/M on a computer using nothing but
a pad of paper for hand-assembly and the front-panel for toggling
in your code. Almost as fun as constructing a primitive mnemonic
memory circuit using stone knives and bear skins!
If you have a computer that can run an editor and ASM for
assemblies, you're in a land of luxury :-).
Tim.
dwight_...@my-deja.com
leea...@earthlink.net wrote:
---snip---
> It
> supports many disk formats, so I can exchange disks with a lot of
> different machines. Finally, it is pretty robust and bug-free; it
don't
> crash, or hang if there are disk errors, etc.
> > 1. Can I bring up the Heath BIOS on the IMSAI? Any advice on the
> approach
> you would take? What software is needed?
Hi
It isn't the format of the disk that is the issue, it is
a completely different controller that is the issue.
>
> 2. Can I keep the structure of the Heath BIOS, to allow
interchangeable
> modules to support different hardware, so any "idiot" can select
and
> install them?
Again, you have to write for a piece of hardware that
doesn't exist on the Heath Kit.
>
> If possible, I'd like to make this BIOS public domain, so *anyone*
could
> use it to bring up CP/M on whatever odd collection of boards they have
> in their S-100, or other CP/M-capable computer.
Anyone can write the low level bios and give it away.
CP/M is in general designed to have different levels
of interface. The concept of installing CP/M on a machine
is to write the various I/O drivers and then put them
together with the main CP/M core.
The actual core CP/M will be the same, coming from a H89
or an IMSAI, for the same version. Some of the disk utilities,
like FORMAT will usually need to be written for the specific
controller and disk type.
I think what your missing is that CP/M, as it is can be
connected to any odd collection of boards. It was specifically
designed that way. There are a few, more or less, standard
interfaces, such as the 177x, etc. but there many TTL controllers
out there as well.
I have done an implementation on a IMSAI. I wrote low level
drivers for the serial and the floppy drive. The rest was
already in CP/M so I'm not sure what it is that you would be
adding to this?
In order to put CP/M on a machine, you need to use the CP/M
manual, an assembler and a pile of data books. I'm not sure
that your changing this to anything different.
Dwight
Sent via Deja.com http://www.deja.com/
Before you buy.
bill_h
> 1. Can I bring up the Heath BIOS on the IMSAI? Any advice on the
> approach
> you would take? What software is needed?
> What do the experts think?
Expert I wouldn't claim. Never_the_less .....
BIOS is a piece of the specific hardware design. It's purpose is
to present a more or less 'standard' interface to other software,
be it an operating system (some sort of Unix, CP/M, other DOS's,
etc) OR simply a language (Pascal, Basic, etc) without a separate
operating system (ie stand-alone). BIOS is software, usually made
a little 'firmer' by writing it into some sort of programmable ROM.
Some programmable ROM's have little quartz windows, to let UV light
in, allowing erasure. Sometimes, the identical chip was mounted in
a solid plastic case, allowing only one time use. Then there are
the EEPROMS, programmable/erasable, without windows. Flash is EEPROM.
A designer could put some BIOS into 'firmware', just enough to get
the machine started, by including some sort of loading routine, then
continue loading his BIOS from somewhere else - over a network, from
a tape or disk, from some other 'firm', or possibly 'less firm' battery
backed-up memory. Lots of places to put the balance of a BIOS beyond
whatever is needed to get the thing started.
Some BIOSes have additional features, beyond simply providing a
'standard' interface, and/or getting a machine started up.
Heath was famous for this. But they were neither the first, nor the only
company to do this. It's pretty normal to call these firmware devices
MONITORS, because using them, without any other softwares or operating
systems, one could observe, change, and produce I/O from the machine.
In fact, a well thought out and designed monitor blows away the sort
of primitive things you can do from a 'front panel' - so once ROM
MONITORS started showing up, front panels were no longer necessary or
even useful. A good ROM monitor will let you single-step through code,
and display mnemonics instead of hex opcodes. And don't bother telling
me you learned all 117 or whatever. Been There, Done That. I'll take
a ROM monitor every time. Oops, okay, some Heaths were OCTAL. Talk
about perverse!
Again, assuming well thought out, you might have an 'interrupt' button
that allowed any running program to be tossed to monitor supervision,
so you could poke around in it. And programmable breakpoints. For
example.
Okay, so monitors are wonderful. And, to most users at the time, Heath
monitors were addicting beyond belief. As in, any other machine seemed
almost moronic in comparision to what you could do with your swiss army
knife of computers. There was no software, nor programming tricks, you
couldn't completely dismantle with a Heath.
Now, the Imsai is a nifty looking machine, no doubt about it. I still
own a couple. But like the Imsai, and most other S-100 boxes, is just
another box, albeit probably the second S-100 'system', and the first
successful one, because it was reliable enough for actual money making
business use. But inside virtually every S-100 box would be one or more
cards not made by the box manufacturer. Many times, the entire box would
be, at some point, completely gutted, and somebody else's cards
installed.
It was very common to go from 2/2.5mhz 8080 systems to 4/6mhz Z-80's
this way. And, to improve or add on a disk system in the process.
But writing a BIOS that includes a monitor, something along the lines
of those written for the various Heath machines? Why? The Heath used
specific I/O and memory addresses, call them ''Heath standards''. The
Imsai not only used different ones, but given that you might only be
dealing with an Imsai BOX, with heaven only knows whose INTERNALS, it
would seem pointless to even try to define an 'Imsai standard'.
Just for reference, my 'stock' CP/M system favorite is a Bigboard II.
Using just the monitor, I can read every soft-sectored disk, at least
enough to figure out what it is. Including it's format scheme. To me
the Heath's were boat anchor sized swiss army knives. The BB II fits
in something a lot smaller and lighter. In addition, it includes an
EPROM programmer and extra BIOS sockets, for unbelievable versatility.
Bill
Tucson, AZ
Steve
>
> For years I have relied on "somebody else" to do my work for me. My CP/M
> computers have all ran a BIOS that somebody else wrote. This has always
> produced limitations. The author was invariably in a hurry, or lacked
> knowledge, or just wasn't all that competent. The result is that there
> are always bugs, or limitations, or problems. And, they can be VERY
> difficult to fix, as the author is unknown and the source code is
> unavailable.
>
> I like the Heathkit H8 and H89 computers' implementation of CP/M. They
> distributed commented source code. They included a program, MAKEBIOS,
> that allowed you to select the hardware you actually had installed on
> your computer, and then automatically assembled a BIOS to suit. They
> also included CONFIGUR, a program to reconfigure an existing BIOS for
> supports many disk formats, so I can exchange disks with a lot of
> different machines. Finally, it is pretty robust and bug-free; it don't
> crash, or hang if there are disk errors, etc.
>
> hardware-wise (8 MHz Z80, more memory, more I/O, front panel, easily
> expandable, etc.). But frankly, the H89 gets all the use because of that
> excellent BIOS.
>
> So here are the questions:
>
> approach
> you would take? What software is needed?
>
> modules to support different hardware, so any "idiot" can select and
> install them?
>
> use it to bring up CP/M on whatever odd collection of boards they have
> in their S-100, or other CP/M-capable computer.
>
> Lee A. Hart Ring the bells that still can ring
> 814 8th Ave. N. Forget your perfect offering
> Sartell, MN 56377 USA There is a crack in everything
> leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
*IF* you put EVERYTHING at the same locations in I/O space that it is on
the machine you are emulating, then there is no reason you cannot run
it. A concern might be that somebody needed to use a BIOS timing loop
that might need tweaking. But I even doubt that. You will have to use
the same FD controller and the same sort of video, but if that's a
terminal that can emulate the other machine then you have it!
-Steve
Lee Hart
>> Can I bring up the Heath BIOS on the IMSAI?
>> Any advice on the approach you would take?
Tim Shoppa replied:
> Not really. The most important part is the disk driver, and if
> this is different at all, then CP/M isn't going to even be loaded.
These discussions are always difficult to get started, because we don't
know what each other already know. There isn't enough time or bandwidth
to state all the assumptions, and list the things you already know.
I know that the BIOS is the specific piece of code in a CP/M system that
is hardware-dependent. It *has* to be changed to suit the actual
hardware. Thus a BIOS from one machine won't work on another.
In most cases, computer users don't have the source code for their BIOS.
Even if they did, it is a tricky process to write, modify, test, and
re-install an improved version. Yet this is precisely what must be done
if you want to add or change the hardware.
The Heath computers were an exception. They supplied BIOS source code,
and made it unusually easy to change it. So my goal is to rewrite the
Heath BIOS to support the specific hardware in my IMSAI. And, to do it
in such a way that others could do the same thing with their favorite
collection of hardware.
> the _CP/M Customization Guide_ walks you through, step by step,
> installing CP/M on a computer using nothing but a pad of paper
> for hand-assembly and the front-panel for toggling in your code.
This is method #1: It was the *only* way in the dark ages. Very
difficult and tedious, it requires a lot of ingenuity and intuition on
the part of the programmer to succeed. I hope there are better ways
today!
> Having the Heath up and running next to the IMSAI will prove
> valuable, because you'll be able to do your assemblies there,
> write them to floppy, move the floppy to the IMSAI, and test.
This is method #2: Get a working CP/M computer (for example, my Heath
H89). Use it to develop software for the new computer (for example, my
IMSAI). Kluge up some way to get the new BIOS into the new computer.
Test and debug it in the new computer.
> If you can move the IMSAI's disk controller to the Heath for testing
> your disk I/O primitives, that's even better.
One thing that makes my quest hopeful is that both the Heath and IMSAI
use the same disk controller chip; Western Digital 1797. The disk
routines might be usable by changing their I/O port addresses and
control register bit assignments.
> If you have a computer that can run an editor and ASM for
> assemblies, you're in a land of luxury :-)
This might be method #3: Use a modern, powerful computer (PC clone?) to
develop the BIOS software, which you somehow get into the new computer.
Bruce Jones wrote:
> For the most part serial and parallel I/O should be easy as it is all 8
> bit with simple status checks
Yes. I would expect to have conditional assembly, equates, INCLUDE
files, or some other mechanism so the user could say, "I have an 8250
UART at I/O port 48h; include a driver for it."
The Heath BIOS already supports the 8250, 8251, and 8255 for its
optional printer drivers, at configurable I/O addresses.
> - The difficult part will be DISK I/O!!!
Absolutely! Besides knowing what floppy disk controller IC is used,
there are matters of whether it is I/O or memory-mapped, polled,
interrupt, or DMA, etc.
The Heath BIOS provides some guidance, because it supports 3 different
controller methods (hard-sector with TTL controller, soft-sector with
WD1797, and SASI), and multiple controller boards for each method (there
were at least 4 different controller boards for the H89 using the WD1797
(Heath, LLL, Magnolia, and CDR).
> Unless you can provide disk I/O routines for every FDC and HDC that will be
> used it is hard to see how a universal BIOS can be released.
I cannot hope to make a universal BIOS by myself. All I can do is set up
the structure, and publish it. Then YOU can write the module to support
your particular disk controller or other hardware. It should be easier
than writing an entire BIOS, and your module could be made available to
others as well. Over time, with many people helping, we could "fill in
the blanks" so BIOS modules could be found for most common harware.
> SCSI provided a partial solution, and I implemented it in BIOS and XIOS code
> from 1980 to 1993. What you get is a common command set and a simple 8 bit
> interface. A problem today is that most if not all SCSI drives are 16 bit.
> To use them a small I/O circuit would have to be made ( unless there is and
> extended SCSI command to switch the I/O to 8 bit ?! ).
CP/M is dead if new hardware can't be added easily. Physically adding
the hardware is easy (hard drives, huge RAM disks), but the software is
a serious barrier. An organized BIOS structure should pave the way to
make it much easier to extend CP/M.
> If you want, you can email me the present IMSAI BIOS that causes you some
> trouble and I will examine it for bugs, make changes as needed and let you
> know. Price? $0.00 as I am curious about how a BIOS can be buggy. Be sure to
> give me a list of bugs you notice with the IMSAI BIOS, since it is nice to
> have a starting point for the bug search.
Thanks for the offer; I'll send you what I've got.
I consider it a "bug in the BIOS" if the computer does something drastic
(hangs, crashes, writes garbage to a disk, etc.) when the user does
something only a little bit stupid. For example, attempting to read an
unformatted disk should not hang the system (on a clear disk you can
seek forever :-)
Bill H replied:
> BIOS is a piece of the specific hardware design...
(clipped to save bandwidth)
An excellent overview of what the BIOS does, and ways to implement it.
Assuming you have a BIOS program written, it needs to somehow get into
memory. That's where the fun begins; how to do this most effectively
(especially when developing and testing a new BIOS). Here are some
approaches I can see:
Approach 1: Toggle it in with the IMSAI's front panel. This was done in
the "good old days" when we had little or no ROM. Drawback; very
tedious. We can do FAR better nowdays.
Approach 2: BIOS in ROM. Most CP/M systems put most or all of their BIOS
in ROM. Being nonvolatile, it's right there when you turn on the power.
But it is difficult to change. Good in a mass production environment,
awkward for BIOS testing and development. There are ROM emulators,
hardware that look like a ROM to the IMSAI but can be downloaded from
another computer on which you write, assemble your BIOS. Drawback;
requires a special piece of hardware.
Approach 3: Monitor in ROM. Put a little program in ROM that can read
and write to memory, accept downloads via a serial port, and begin
execution at an address. The BIOS can be written and assembled on
another working computer, and downloaded as a HEX file. If the monitor
is sophisticated enough, it will provide a good working environment for
debugging. This is the approach Heath used, and so far it looks like the
best one to use.
Approach 4: Are there any others?
Bruce Jones
I used it for one project in the late 1970's.
It was based on an note that came with a BIOS writer's support document.
You have two BIOS images running at the same time, both have a modification
to them so that drive A selection puts the BIOS #1 jump vector in place,
while a drive B selection puts the jump vector in place for BIOS #2.
It worked if you had two known working BIOS sources, and really all it
allowed was copying files across different media ( say different skew, and
DIR track offset, or floppy to new SCSI ).
Modem7 worked as well if you had a good baud rate ( but I remember having to
modify Modem7 source because the default version only buffered 256 directory
entries. Not good when I started installing HDs with 1024 dir entries.).
I quickly learned to adapt my floppy BIOS to any hard drive controller, or
even a co-resident floppy controller ( dif. port map ) so I dropped using
it.
Anyway that is the jist of it.
Another piece of CP/M history.
Fred J. Scipione
"Lee Hart" <leea...@earthlink.net> wrote in message
news:398280...@earthlink.net...
> Thanks to all for the well-seasoned advice and comments! I asked:
> >> Can I bring up the Heath BIOS on the IMSAI?
> >> What software is needed?
> >> Any advice on the approach you would take?
You may be interested in something I have mentioned in this news-group
before:
There is a site on the web at vectorboard.com. In its download link, in the
"Miscelaneous"
area there is a (sub) directory for a Z80 based microcomputer called the
"CONKEY".
It contains, among other things, (several revisions of) a custom BIOS whoes
source
code has been segmented into a somewhat modular fashion. E.G.: the code for
de-blocking hardware segments larger than 128 bytes is separate from the
code for
tracking diskette swaps for a "phantom" drive, and both are separate from
the code
which runs the disk drive controler chip, ...
Most options and hardware constants are set explicitly in one of 2 "include"
files which
can be edited in accordance with the instructions in the accompanying
comments.
Adding options to support a video board console instead of serial port, or a
different disk
drive controler should be very feasible.
The only potential copyright claimant, Columbia Data Products, has
disclaimed all
interest in CP/M and Z80 hardware.
John W. Linville
Steve Kostecke
Fred J. Scipione wrote:
>There is a site on the web at vectorboard.com. In its download link,
>in the "Miscelaneous" area there is a (sub) directory for a Z80 based
>microcomputer called the "CONKEY". It contains, among other things,
>(several revisions of) a custom BIOS whoes source code has been
>segmented into a somewhat modular fashion.
Can you provide a current URL for this site? vectorboard.com does
not seem to exist.
Thanks,
--
____
||k || Steve Kostecke <st...@kostecke.net>
||__||
|/__\| Public Key at gopher://kostecke.net or `finger st...@kostecke.net`
Fred J. Scipione
I just found them here:
http://vectorbd.vectorbd.com/Welcome.html
The files section is normally off line from 5 PM to 11PM
Eastern time each day. If there are other problems, the
sysops should be notified by e-mail. If that still doesn't
help, I can attach my copy of the version 3.0 archive onto
replies to personal e-mail request.
"Steve Kostecke" <st...@kostecke.net> wrote in message
news:slrn8ob4th...@stasis.kostecke.net...
Ernest
20 system that wants to use CP/M, and I've been thinking about giving it a
try.
This system is a single board z80 machine, and since there is absolutely
zero information on the internet for this machine, or a source for the OS,
my only real choice is to try to set up CP/M for it.
I know that I'll be showing my ignorance here but what would be the best way
to probe the machine to figure out the I/O addressing? Is this something
that you just make a guess at, or are there basically just a few possible
choices (address ranges) that I could systematically try until I find one
that works?
Are the I/O address' randomly chosen by the manufacturer or are they usually
defined by the choice of chip, and if that 's the case, would I be able to
copy that information from a similar board OS (if I could find one.) I would
guess that there's a small number of controller chip manufacturers, so it
might be possible to find a similar style of board, and the OS.
The other question is the keyboard? This system has a very non-standard
keyboard. Is the keyboard layout translated by the keyboard controller chip,
or does the OS need to be modified for this too? I warned you about my
ignorance.
Or, is there anyone out there that might be willing and able to build the
CP/M OS for this machine for a reasonable price? What would a reasonable
price even be??
Ernest
Steve wrote in message <398263...@armory.com>...
>Lee Hart wrote:
>>
>> For years I have relied on "somebody else" to do my work for me. My CP/M
>> computers have all ran a BIOS that somebody else wrote. This has always
>> produced limitations. The author was invariably in a hurry, or lacked
>> knowledge, or just wasn't all that competent. The result is that there
>> are always bugs, or limitations, or problems. And, they can be VERY
>> difficult to fix, as the author is unknown and the source code is
>> unavailable.
>>
>> I like the Heathkit H8 and H89 computers' implementation of CP/M. They
>> distributed commented source code. They included a program, MAKEBIOS,
>> that allowed you to select the hardware you actually had installed on
>> your computer, and then automatically assembled a BIOS to suit. They
>> also included CONFIGUR, a program to reconfigure an existing BIOS for
>> things like number and type of disk drives, serial port formats, etc. It
>> supports many disk formats, so I can exchange disks with a lot of
>> different machines. Finally, it is pretty robust and bug-free; it don't
>> crash, or hang if there are disk errors, etc.
>>
>> I also have an IMSAI S-100 system. It is a much nicer computer
>> hardware-wise (8 MHz Z80, more memory, more I/O, front panel, easily
>> expandable, etc.). But frankly, the H89 gets all the use because of that
>> excellent BIOS.
>>
>> So here are the questions:
>>
>> 1. Can I bring up the Heath BIOS on the IMSAI? Any advice on the
>> approach
>> you would take? What software is needed?
>>
>> 2. Can I keep the structure of the Heath BIOS, to allow interchangeable
>> modules to support different hardware, so any "idiot" can select and
>> install them?
>>
>> If possible, I'd like to make this BIOS public domain, so *anyone* could
>> use it to bring up CP/M on whatever odd collection of boards they have
>> in their S-100, or other CP/M-capable computer.
>>
>> What do the experts think?
>> --
>> Lee A. Hart Ring the bells that still can ring
>> 814 8th Ave. N. Forget your perfect offering
>> Sartell, MN 56377 USA There is a crack in everything
>> leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
Steve
>
> I've never "built" a BIOS for a system but I have this pesky Olympia Olytext
> 20 system that wants to use CP/M, and I've been thinking about giving it a
> try.
>
> This system is a single board z80 machine, and since there is absolutely
> zero information on the internet for this machine, or a source for the OS,
> my only real choice is to try to set up CP/M for it.
>
> I know that I'll be showing my ignorance here but what would be the best way
> to probe the machine to figure out the I/O addressing?
The hardware makes it obvious. If you know TTL logic and bus theory,
which is dead easy, then you just follow the address lines and ask the
musical question: What bus lines have to be active to turn THIS on?
>Is this something
> that you just make a guess at, or are there basically just a few possible
> choices (address ranges) that I could systematically try until I find one
> that works?
--------------
That would take too long unless you write a self-modifying driver with a
success determination routine and turn it loose iterating, sort of a
plug-n-play in software!!! ;-) On some computers the equipment list is
determined this way!
> Are the I/O address' randomly chosen by the manufacturer or are they usually
> defined by the choice of chip,
---------------------
The chip determines how many contiguous addresses must be used, and
after that they usually built the bus so as to minimize cost by making
the port decoding dead-assed easy, by putting the base addresses
(starting address of that device's ports) of I/O devices right on major
numeric boundaries.
> and if that 's the case, would I be able to
> copy that information from a similar board OS (if I could find one.) I would
> guess that there's a small number of controller chip manufacturers, so it
> might be possible to find a similar style of board, and the OS.
----------------
Yes, there are certain classic routines for 8085/Z80's using various
chips, and you simply have to relocate them properly.
> The other question is the keyboard? This system has a very non-standard
> keyboard. Is the keyboard layout translated by the keyboard controller chip,
> or does the OS need to be modified for this too? I warned you about my
> ignorance.
----------------
I dunno, I have never seen one. Work it out, do more searching and
asking for it, and meanwhile determine the I/O map and architecture for
yourself, it's great experience!
> Or, is there anyone out there that might be willing and able to build the
> CP/M OS for this machine for a reasonable price? What would a reasonable
> price even be??
>
> Ernest
----------------
Aw, it's not that hard, dontcha wanna be able to say you wrote your own
BIOS?? You really do NOT want to pay somebody for a one-off BIOS!! The
barebones BIOS for CP/M is already written, you sort of fill in the
blanks!
Steve
Lee Hart
> I have this pesky Olympia Olytext 20 system that wants to use CP/M...
> a single board z80 machine... absolutely zero information...
> what would be the best way to probe the machine to figure out the I/O
> addressing?
Well, you have to start with what you know. It is possible to start from
ground zero, but this is a tough way to go. The more "toys" you have in
your toolbox, the better. Every little fact and detail that you can find
out will help, too.
For the sake of illustration, let's assume you have ZERO trustworthy
information about the machine.
1. Take a look at the chips on the board.
- Can you find the CPU? Is it an 8080, 8085, Z80, etc?
- How much RAM does it have? At least 16k bytes?
- Is there a standard-pinout ROM or EPROM? (2708, 2716, 2732, 2758,
2764, 27128, 27256, etc.)
- Can you find a disk controller? What chip is it?
- Are there any serial ports? (8250, 8251, SIO, etc.)
- Are there any parallel ports? (8255, PIO, etc.)
- Is there a video controller? (on-board video logic; 6845 etc.)
If it has the above, it could run CP/M. If there is no on-board video or
keyboard port, you can still run CP/M via an external terminal connected
to one of the serial ports.
2. Pull the EPROM, and put it in an EPROM programmer.
- Read, and save the EPROM's contents in a file on disk.
- Use a disassembler suitable for the board's CPU chip to disassemble
the code in the EPROM.
- Look through the code to discover the memory and I/O maps.
Even if you aren't proficient with the instruction set for the
particular CPU, certain IN and OUT instructions are a dead giveaway that
there is I/O at those addresses. Memory MOV instructions are more
subtle, but wherever you find instructions that, for example, set the
stack pointer, you can be SURE they point to RAM.
3. Trace out the circuit.
- Get data sheets for the I/O and memory chips found.
- Concentrate on tracing these chip's "chip select" pins circuitry.
Depending on the board, this might be very easy, or very difficult. They
generally don't decode every address line to produce a memory or I/O
chip select; just the minimal number so that no two chips share the same
address. For example, they might have a 74LS138 1-of-8 decoder. Its 8
outputs each select one I/O chip. One of them has 8 internal registers,
so address lines A0, A1, and A2 go straight to the chip. The designer
therefore connected A3, A4, and A5 to the 3 address-decode inputs to the
74LS138. Then the 74LS138's "0" output is active for any I/O addres from
00-07h, its "1" output for 08-0Fh, "2" for 10-17h, etc. Each I/O chip
has 8 addresses whether it needs it or not.
4. Hardware gadgets
- Everything but CPUs and dynamic RAMs can work at zero clock speed.
- Thus, you can remove the CPU chip, and substitute DIP switches to
pull the address, data, and control lines to known states. So...
- Build an adpater that plugs into the CPU socket, with a pull-up
resistor to +5v and a DIP switch to ground on each address, data,
and control line.
- Now you can select an address, activate the control lines to
request
a memory or I/O read, and use a voltmeter, logic probe, etc, to see
which chip is actually being selected.
This is a poor-man's logic analyzer. It will absolutely confirm that you
have found the addresses. Note: Don't select dynamic RAMs except very
briefly. First, they won't work anyway, and second, some older dynamic
RAMs will get hot if left selected continuously.
5. Find or write a ROM "monitor" program for the addresses you've found.
- Write this program into an EPROM of the same type as the one you
pulled from the board.
- Stick it in, and see if it works.
- If so, now you can examine and change memory and I/O address to
learn and confirm how they work.
Now you are well on your way to being able to do something useful with
the board, like bring up CP/M. If the board has a serial port, I would
program the monitor to use it to talk to an external terminal (or PC)
rather than any on-board keyboard or display. Fewer things to go wrong!
> Are the I/O address' randomly chosen by the manufacturer?
Yes (or so it seems :-) Actually, they are usually chosen based on what
made the hardware design easiest.
> The other question is the keyboard? This system has a very non-standard
> keyboard. Is the keyboard layout translated by the keyboard controller chip,
> or does the OS need to be modified for this too?
Anything is possible. Each key undoubtedly produces a code that the
micro can read. It would be nice if it is ASCII, but anything can be
translated.
Now the fun begins!