Info for a dummy wanted
Ruud
Does something exist like ”Do it yourself CP/M hardware for Dummies”
and “Build your own CP/M BIOS (and whatever more is needed) for
Dummies”?
Please let me explain. Being a Commodore fan I’m well known with the
C128 and the CP/M cartridge for the C64. Less known, almost unknown,
there also exists a CP/M module for the CBM 8000 series. I know
because I have one. Unfortunately w/o software and worse, not working
due to a missing unknown part . But the how it works is clear: a Z80
system is connected to the CBM by means of a 6522 VIA and a Z80PIO.
Elektor did about the same for their 65xxx systems but using two
6821’s as interface. The CP/M module for the Acorn BBC contains a 6522
and a custom chip as interface (IIRC).
I have several ideas for creating a nice universal CP/M module for
more then one of my Commodores. First I have a spare Micro-Professor
laying around or I can use this unknown module I mentioned above.
Unfortunately these systems have 64 KB or less, thus need some
expansion to be able to handle CP/M 3.
The Elektor card has 256 KB onboard and should be able to handle CP/M
3. There is an EPROM onboard and I could disassemble it. But the
software for the 65xxx side is missing as well so I wonder if it
wouldn’t be faster to create a new ROM and software.
Of course I did some research on the hardware. One of the sources is
Digitals own CP/M 3.0 Programmers Guide. Here the banked system is
explained.
The 64 KB area is divided in two parts:
- the lower part that can be swapped
- the upper part that is always visible
The document doesn’t explain at what address the upper part starts. In
the Bondwell this is $8000, that is, if I interpreted the schematics
correctly.
The doc didn’t mention the ROM at all. I assume it first copies its
own contents to RAM and then switches to RAM. The schematics of the
Bondwell and the Elektor card support this theory.
I thought that for CP/M 2.2 I could do with a normal Z80 system, for
example the Micro-Professor plus some extra RAM. But after reading the
Guide I’m not sure anymore i.e. I think it needs a circuit to hide the
ROM as well. And then the fact that a program needs to start at $0100.
Can anybody shed some light on this, please?
The next part is the software. The only thing I’m sure of is that the
hardware developer has to provide the BIOS. But what about the BDOS? I
know it is the interface between the BIOS and the CCP and that it
gives the user/programmer a way to overrule the BIOS (if I’m
correctly). In that case should the hardware developer create and
maintain it?
I found this (and equivalent) info on Internet:
The BIOS begins with the following jumps to service routines:
JMP BOOT ;-3: Cold start routine
JMP WBOOT ; 0: Warm boot - reload command processor
JMP CONST ; 3: Console status
JMP CONIN ; 6: Console input
Etc. etc.
I assume that the WBOOT vector replaces the BOOT vector once the
content of the ROM is copied to RAM. Knowing for sure that a program
starts at $0100, I assume the first 256 bytes are reserved for the
vectors. The P.Guide also mentions RAM reserved for the “Buffers”
above the OS (page 1-2, 1-3 and 1-4). Page 1-6 shows a picture
mentioning BIOS, BDOS, Loader etc. filling the RAM. I haven’t figured
out yet what is what. I admit I haven’t read/studied the P.Guide that
good so far so if someone says “RTFM” I won’t blame him. But if
someone could shed some light on it, please!
Many thanks for your patience and help!
--
___
/ __|__
/ / |_/ Groetjes, Ruud Baltissen
\ \__|_\
\___| http://Ruud.C64.org
s_dub...@yahoo.com
Amstrad PCW256. I was never able to gather all the tools together,
and source code, to remake a cp/m 3 system file for it.
However it's memory map was like this:
- 256k -
Bank0 64k
Bank1 64k
Bank2 16k
Remainder 112k, RamDrive.
Bank0 was the 'Boot' bank, the memory in context when the system
loaded.
Bank1 was the 'TPA' bank, the memory in context when the TPA was
ready.
Bank2 was the memory mapped to the video controller.
The Memory Management Unit controlled the 256k in terms of 16k blocks,
so each 16k segment could be swapped into and out of context thru an
IO command to the controlling port. (I wish the resolution was 4k
blks)
The 'Common' block was the 16k block at C000h, it is common to Bank0
and Bank1. -Actually it was built at 'Boot' time in Bank0 and kept
into 'TPA' time. After 'TPA' time, the Bank0 'Common' block holds the
'Bankable' structures and data, and such.
The Video Memory was bit mapped, so you could do your own graphics by
swapping that 16k into the 'TPA' Bank, probably at 8000h, have your
code munge it, and swap it back. Sprite animations were done on the
PCW.
The CP/M 3 Bios was big, so a good portion of it was kept in Bank0,
especially all of the USERF functions. In fact, an USERF Call swapped
in Bank0 to run that code, then swapped back Bank1, your calling code,
before returning out of the Bios. The 'Common' Block (of the TPA)
really was common in that case to both banks.
The rest of the Ram for the RamDrive was also under the MMU control so
it could be accessed both by the regular file operations or directly
thu port control of the MMU, a 16k block could be swapped into the TPA
area, either at 4000h or 8000h. Or, 32k of the RamDrive memory could
be swapped in from 4000h..BFFFh providing your controlling code
resided outside this area.
Anyway, that's the way the PCW appeared to do it.
Your options are dictated by your hardware.
hth.
Steve
> The doc didn’t mention the ROM at all. I assume it first copies its
> own contents to RAM and then switches to RAM. The schematics of the
> Bondwell and the Elektor card support this theory.
>
> I thought that for CP/M 2.2 I could do with a normal Z80 system, for
> example the Micro-Professor plus some extra RAM. But after reading the
> Guide I’m not sure anymore i.e. I think it needs a circuit to hide the
> ROM as well. And then the fact that a program needs to start at $0100.
> Can anybody shed some light on this, please?
>
> The next part is the software. The only thing I’m sure of is that the
> hardware developer has to provide the BIOS. But what about the BDOS? I
> know it is the interface between the BIOS and the CCP and that it
> gives the user/programmer a way to overrule the BIOS (if I’m
> correctly). In that case should the hardware developer create and
> maintain it?
>
No, the BDOS should be supplied as a System Page Relocatable file. A
banked version or an unbanked version. These are generic. They embody
the file system algorithms mostly.
Mr Emmanuel Roche, France
Ho, boy! You have been silent for so many months/years, that I was
wondering if you had dropped CP/M in favor of your beloved C64...
> Does something exist like ”Do it yourself CP/M hardware for Dummies”
> and “Build your own CP/M BIOS (and whatever more is needed) for
> Dummies”?
Ouch! Hard(ware) questions! By "CP/M hardware for Dummies", I think
that you mean "building the minimum hardware able to run CP/M"? In
that case, I must point you to Andrew Lynch's N8VEM, which is
currently the standard. Before that, I would have said the "Ampro
Little Board" and the P112. As for "Build your own CP/M BIOS for
Dummies”, the answer is clear:
- "The Programmer's CP/M Handbook"
Andy Johnson-Laird
Osborne-McGraw Hill, 1983
(As I once explained, there are 2 versions of this book, the second
correcting, of course, some typos of the first printout. The files of
the book have been uploaded by Jack Rubin in 2007, after I mentioned
it several times. They can be found at the bottom of the Web page:
http://www.cpm.z80.de/source.html )
> Please let me explain. Being a Commodore fan I’m well known with the
> C128 and the CP/M cartridge for the C64. Less known, almost unknown,
> there also exists a CP/M module for the CBM 8000 series.
A Commodore CBM-8032? Come on, Ruud, who, except a crazy Commodore
fan, would like to run CP/M on such an old BASIC-in-ROM computer
(which uses GPIB for connecting its peripherals)? How many CP/M
computer do you know, that used GPIB for connecting its peripherals?
> I have several ideas for creating a nice universal CP/M module for
> more than one of my Commodores.
Haaaaa! Another hardware dream... I am waiting to read with interest
what will say Allison J. Parent, who starts all her sentences with "30
years ago, I made..."
Why would you want to create a "nice universal CP/M module" for your
collection of Commodore computers? Aren't you happy with them? A
computer is a computer is a computer. As long as it can do the 6
things that a computer can do, then it is useful. Else, it is a toy!
(I particularly liked your "First, I have a spare Micro-Professor..."
I once used one, and I clearly think that it is a toy. For me, the
most important part of a computer is its keyboard. That's why I do all
my retyping on an old 6-MHz computer: impossible to find one current
"IBM Clown" with a decent keyboard. Second is the screen, and how it
displays text. The Epson QX-10 is, visibly, obviously, the best screen
ever made. Third is the printer. I was happy with my Epson FX-80
printers (I never liked the "daisy-wheel" noise of my first printer, a
Qume Sprint 5), until I got one of the first laser printer ever sold
in France (Canon LBP-8 A1). Once I was used to 300DPI, I never went
back (except to print listings). The only think missing to my beloved
Epson QX-10 is an Internet connection. So, I got a "portable" just for
Internet.)
(I am cutting a big part of your message, because it is diving into
details that show that you only have experience with CP/M Plus.
Speaking of CP/M Plus, Digital Research once made a "piggyboard"
enabling Apple IIe computers to run under CP/M Plus. It was recently
mentioned. Apparently, many Americans were running CP/M software on
the Apple IIe. One little US company became millionaire selling one
"Microsoft Z-80 SoftCard" for the Apple IIe...)
> Many thanks for your patience and help!
Well, I am sorry to see you, another Old Timer, wanting to do useless
things. Of course, if you are an electronics engineer, it could be fun
to run CP/M Plus on a Commodore CMB-8032 but, except another Old Timer
like me, who remembers the CBM? And why port CP/M to a computer that
never ran under it, when any IBM Clown can run CP/M, either under MS-
DOS or in a "DOS Box" under Windows?
My advice: Drop this idea.
Your Friend, Emmanuel.
Jonathan Graham Harston
> systems but using two 6821's as interface. The CP/M module for the
> Acorn BBC contains a 6522 and a custom chip as interface (IIRC).
That's not a CP/M module. You can run CP/M on it, you can run any
Z80 code on it. It doesn't have a 6522 in it, just a Z80, 64K of
RAM, 4K of ROM and a Tube ULA (plus glue logic).
<http://mdfs.net/Software/Tube/Z80>
> The Elektor card has 256 KB onboard and should be able to handle
> CP/M 3. There is an EPROM onboard and I could disassemble it. But
> the software for the 65xxx side is missing as well so I wonder if
through magazine articles scanning, OCRing and archiving
co-processor projects, so I may have it in my pile.
> I thought that for CP/M 2.2 I could do with a normal Z80 system,
> for example the Micro-Professor plus some extra RAM. But after
systems have ROM at the bottom of memory, as that's where the CPU
starts on reset. For a Z80 system to be able to run CP/M the
startup RAM needs to be able to be removed from the memory map
after startup. The simplest way of doing this is to have ROM
visible everywhere on reset, make the first instruction JP &F003,
and when A15 goes high it disables the ROM-seen-everywhere logic.
> The next part is the software. The only thing I'm sure of is that
> the hardware developer has to provide the BIOS. But what about the
> BDOS? I know it is the interface between the BIOS and the CCP and
with CP/M. That's the whole point of CP/M. The software runs on
anything, you just change the BIOS to provide the system-specific
code needed for the specific hardware. http://mdfs.net/cpm/SmallSys
is a tiny tiny BIOS that provides everything the BDOS needs via a
simple IDE hard drive and 6850 serial I/O.
> JMP BOOT ;-3: Cold start routine
> JMP WBOOT ; 0: Warm boot - reload command processor
> JMP CONST ; 3: Console status
> JMP CONIN ; 6: Console input
> Etc. etc.
>
> I assume that the WBOOT vector replaces the BOOT vector once the
> content of the ROM is copied to RAM. Knowing for sure that a
to do a warm boot. If your BIOS starts at &F000, then &0000 will
contain JP &F003. Similarly, &0005 contains a jump to the BDOS for
making BDOS calls.
> program starts at $0100, I assume the first 256 bytes are reserved
> for the vectors. The P.Guide also mentions RAM reserved for the
0000 JP to BIOS warm boot
0005 JP to BDOS service
005C File Control Block
0080 Command line buffer
0100 Start of Transient Program Area (loaded programs)
> Many thanks for your patience and help!
J.G.Harston - j...@arcade.demon.co.uk - mdfs.net/User/JGH
Liberal Democrat Parliamentary Candidate for Sheffield Brightside
Ruud
> that I was wondering if you had dropped CP/M in favor of your beloved C64...
Nope, just lack of time :(
> I must point you to Andrew Lynch's N8VEM, which is currently the standard.
I even have thought about buying one. But a part of the fun is
building one yourself. I'll study the schematics.
> A Commodore CBM-8032? Come on, Ruud, who, except a crazy Commodore
> fan, would like to run CP/M on such an old BASIC-in-ROM computer
IIRC the N8VEM and P112 started as a PCB with only terminal connection
and no disk. And that is what I want the Commodore to be: just a
terminal with a disk. And if I can add an IDE-interface, it will
become just a terminal. And when using a C64 or C128, I will have one
with graphical capabilities. Hmmm, IIRC I know there was someone
promoting GSX (or something like that) for CP/M. He should be
interested :)
> How many CP/M computer do you know, that used GPIB for connecting
> its peripherals?
Philips 2000C :)
> Aren't you happy with them?
I am. But I also have been a Z80 fan thanks to the Micro-Professor
(which was not mine :( ). My second computer was a Sinclair ZX81, my
third the Aquarius. But the hardware configuration, documentation etc.
of the C64 was much better then that of those other computers.
> .... and I clearly think that it is a toy.
I know a factory that used the Commodore KIM-1 for controlling their
machine park in the early 80's. Those people were very happy with it.
If I would not have known the MP, I wouldn't have become a Z80 fan.
Not being a Z80 fan I wouldn't have taken interest in a DM5 that you
own now. So be happy that I met this "toy" :)
> ... most important part of a computer is its keyboard. ...
That's why I want to use the CBM :)
> wanting to do useless things.
I find climbing the Mount Everest useless as well. But probably some
people have fun in doing that. Ah, here we have the magic word: FUN.
Of course, if you are an electronics engineer, it could be fun
to run CP/M Plus on a Commodore CMB-8032 but, except another Old
Timer
like me, who remembers the CBM?
> And why port CP/M to a computer that never ran under it, when
> any IBM Clown can run CP/M, either under MS-DOS ...
CP/M 80 never ran on a PC as well. Etc. etc. etc.
I must admit that I'm a bit disappointed in you behaviour. Here you
have the opportunity to promote CP/M but the only thing you do with
these kind of statements is driving people away. I'm sorry to hear
that.
Ruud
> It doesn't have a 6522 in it, just a Z80, ....
You're right. It seems my memory isn't that good anymore after 50
years :)
> Won't it be in the original magazine article?
Elektor is Dutch and I have all articles as well (but in Dutch). I
even contacted the company (just 20 KM from my place) but they haven't
anything of the old stuff anymore :(
> You can (are expected to) use the standard BDOS and CCP supplied
> with CP/M. ... you just change the BIOS ...
Ah, happy lazy me !!!
> http://mdfs.net/cpm/SmallSys
Thank you !!!
> Depends what you mean by 'buffer'. Essentially:
The Programmers Guide mentions a Buffer on top of the OS. I was
wondering what that Buffer was. But I think I have a bit more RTFM to
do.
All...@localhost.net
wrote:
>Hallo allemaal,
>
>
>Does something exist like �Do it yourself CP/M hardware for Dummies�
>and �Build your own CP/M BIOS (and whatever more is needed) for
>Dummies�?
Depends on the level of information requiired.
I'd start with the various CP/M manuals by Digital research
themselves. Available on Gaby's site.
Another is "the programmers CP/M handbook" by Andy Johnson-Laird.
>
>Please let me explain. Being a Commodore fan I�m well known with the
>C128 and the CP/M cartridge for the C64. Less known, almost unknown,
>there also exists a CP/M module for the CBM 8000 series. I know
>because I have one. Unfortunately w/o software and worse, not working
>due to a missing unknown part ?. But the how it works is clear: a Z80
>system is connected to the CBM by means of a 6522 VIA and a Z80PIO.
>Elektor did about the same for their 65xxx systems but using two
>6821�s as interface. The CP/M module for the Acorn BBC contains a 6522
>and a custom chip as interface (IIRC).
Yes, I have both C64 and C128 and also a defunct C64 CP/M module.
>I have several ideas for creating a nice universal CP/M module for
>more then one of my Commodores. First I have a spare Micro-Professor
>laying around or I can use this unknown module I mentioned above.
>Unfortunately these systems have 64 KB or less, thus need some
>expansion to be able to handle CP/M 3.
>The Elektor card has 256 KB onboard and should be able to handle CP/M
>3. There is an EPROM onboard and I could disassemble it. But the
>software for the 65xxx side is missing as well so I wonder if it
>wouldn�t be faster to create a new ROM and software.
You can run CP/M 3 in 64k though you do loose some of the advanatges.
>
>Of course I did some research on the hardware. One of the sources is
>Digitals own CP/M 3.0 Programmers Guide. Here the banked system is
>explained.
>The 64 KB area is divided in two parts:
>- the lower part that can be swapped
>- the upper part that is always visible
>The document doesn�t explain at what address the upper part starts. In
>the Bondwell this is $8000, that is, if I interpreted the schematics
>correctly.
>
>The doc didn�t mention the ROM at all. I assume it first copies its
>own contents to RAM and then switches to RAM. The schematics of the
>Bondwell and the Elektor card support this theory.
This would be good.
>I thought that for CP/M 2.2 I could do with a normal Z80 system, for
>example the Micro-Professor plus some extra RAM. But after reading the
>Guide I�m not sure anymore i.e. I think it needs a circuit to hide the
>ROM as well. And then the fact that a program needs to start at $0100.
>Can anybody shed some light on this, please?
CP/M 2 or 3 requires ram from 000h through some higher address of not
less than 20K for CP/M2 and higher for CP/M 3. Generally if rom must
be resident it should be at the very highest address to keep ram
available.
>
>The next part is the software. The only thing I�m sure of is that the
>hardware developer has to provide the BIOS. But what about the BDOS? I
>know it is the interface between the BIOS and the CCP and that it
>gives the user/programmer a way to overrule the BIOS (if I�m
>correctly). In that case should the hardware developer create and
>maintain it?
The BDOS is the core (kernel) of CP/M and does not generally get
modified. The BIOS does raw IO and has a stadard interface, the BDOS
is the programmers API and the CCP is the "monitor/user interface".
The hardware maintainer does not generally "create nor maintain the"
BDOS It is a software module. It does have a specific address
relationship to the CCP and the BIOS.
>
>I found this (and equivalent) info on Internet:
>The BIOS begins with the following jumps to service routines:
> JMP BOOT ;-3: Cold start routine
> JMP WBOOT ; 0: Warm boot - reload command processor
> JMP CONST ; 3: Console status
> JMP CONIN ; 6: Console input
>Etc. etc.
>
>I assume that the WBOOT vector replaces the BOOT vector once the
>content of the ROM is copied to RAM. Knowing for sure that a program
It can but usually it does not. Coldboot ususally initializes
hardware and then drops into warmboot to bring all the software
componenets into the system ram.
>starts at $0100, I assume the first 256 bytes are reserved for the
The $100 address is for applications programs, the CCP, BDOS and BIOS
usually live in high ram.
>vectors. The P.Guide also mentions RAM reserved for the �Buffers�
>above the OS (page 1-2, 1-3 and 1-4). Page 1-6 shows a picture
>mentioning BIOS, BDOS, Loader etc. filling the RAM. I haven�t figured
>out yet what is what. I admit I haven�t read/studied the P.Guide that
>good so far so if someone says �RTFM� I won�t blame him. But if
>someone could shed some light on it, please!
DRI manuals are not so clear and require much study to get a complete
explanation. You will need to also read the Alteration guide and
features and facilities to get a more compllete picture. The
Programers CP/M Handbook is also very useful in explaining this.
Generally for CP/M memory after boot looks like:
$000 to $0ff page 0 is where all the system vectors and interrupt
handlers lie.
From $100 to $nnnn-(bdos and bios+ buffers) is the applications area
and is general use.
Above that is the CCP if a appliaction is not present then bdos then
BIOS with it's buffers and tables. Most applications will overlay the
CCP for more space but the BDOS and BIOS are retained for they
provide services like file IO and terminal IO.
The combined CCP and BDOS is $1600 bytes (5632 bytes) whith a
follwing and sized in the 2-4K range depending on programmers
hardware and requirements. The CCP and BDOS save for relocation
to execuition address are generally fixed code and the BIOS being the
custom and hardware specific code.
>Many thanks for your patience and help!
Likely you will have more questions. ;)
Allison
All...@localhost.net
<roch...@laposte.net> wrote:
>- "The Programmer's CP/M Handbook"
> Andy Johnson-Laird
> Osborne-McGraw Hill, 1983
This is a must have.
>(As I once explained, there are 2 versions of this book, the second
>correcting, of course, some typos of the first printout. The files of
>the book have been uploaded by Jack Rubin in 2007, after I mentioned
>it several times. They can be found at the bottom of the Web page:
>
>http://www.cpm.z80.de/source.html )
Gaby's site is an extermely valuable resource.
>A Commodore CBM-8032? Come on, Ruud, who, except a crazy Commodore
>fan, would like to run CP/M on such an old BASIC-in-ROM computer
>(which uses GPIB for connecting its peripherals)? How many CP/M
>computer do you know, that used GPIB for connecting its peripherals?
I just repaired a system for someone that used a CBM connected to
various instruments that compose a test system all programmed in
Nevada fortran using a CBM and CP/M. GPIB is a very widely used
instrumentation bus.
>> I have several ideas for creating a nice universal CP/M module for
>> more than one of my Commodores.
>
>Haaaaa! Another hardware dream... I am waiting to read with interest
>what will say Allison J. Parent, who starts all her sentences with "30
>years ago, I made..."
Well at least I've built it and can explain it. More recently as in
less than 3 weeks ago I did make up yet another z80 CP/M based
system. The end system will only need the BIOS and application
but all of them will be capable of running CP/M for development
reasons. If all goes as funded there will two dozen of them
interconnected for instrumentation use.
As they say far from dead.
Allison
Herbert Johnson
> Hallo allemaal,
>
> Does something exist like ”Do it yourself CP/M hardware for Dummies”
> and “Build your own CP/M BIOS (and whatever more is needed) for
> Dummies”?
Not quite. CP/M for 8080 (and Z80) was offered in the mid-1970's and
into the 1980's, well before the "dummies" books. So there are tens of
books - paper, printed books - about how to operate CP/M, program
under CP/M and to create BIOS's. SOme of them are specific to one
brand of
hardware, some are not. (I'll say where to get books shortly.)
Additionally, in comp.os.cpm, this same question is posted a few times
a year. The hardware changes, the goals change a little bit, but the
general form amounts to someone starting from zero or from some
specific pieces of hardware, to "generate" some kind of CP/M OS for
their needs.
Bottom line - I guarantee, there is no "dummies" CP/M book.
http://www.retrotechnology.com/dri/howto_cpm.html
I"ve outlined some of the issues and common questions on this Web
page. Some of those points come from prior discussions here. You can
find more of those discussions, by searching comp.os.cpm under
"Google" and "Google group" searches specific to comp.os.cpm, a Usenet
newsgroup. I mention books and how to get them, and links to some
useful Web sites. I do NOT describe what to do - other books, other
sites, do or did that long ago for CP/M, in various versions for 8080/
Z80 and 8086. (Or derivative OS's, but don't get distracted.)
> Please let me explain. Being a Commodore fan I’m well known with the
> C128 and the CP/M cartridge for the C64. Less known, almost unknown,
> there also exists a CP/M module for the CBM 8000 series. I know
> because I have one.
There are also Commodore discussion groups, in Usenet and as Google or
Yahoo! groups, and on their own Web pages. Have you searched those,
for more support for your CBM 8000 and the Z80 module? Did you really
exhaust those resources, is there no interest in discussion this
there? "CP/M Z80 module CBM 8000" in Google found some information,
for me.
> I have several ideas for creating a nice universal CP/M module for
> more then one of my Commodores. First I have a spare Micro-Professor
> laying around or I can use this unknown module I mentioned above.
> Unfortunately these systems have 64 KB or less, thus need some
> expansion to be able to handle CP/M 3.
CP/M 3.0 is somewhat based on CP/M 2.2, and 2.2 uses less memory and
is simpler. I suspect, if you have to work from scratch, it will be a
good first step to get CP/M 2.2 running and THEN get CP/M 3.0 running.
Also, there are Commodore simulators you can run on Windows and Linux,
you can do some development with those. My Web page describes a few of
these.
YOu want some "dummies" advice? Here it is - sometimes it's FASTER to
get the EASIER stuff working FIRST, work your way up, than to try to
do it "all" in one step.
> Of course I did some research on the hardware. One of the sources is
> Digitals own CP/M 3.0 Programmers Guide. Here the banked system is
> explained......
> The document doesn’t explain at what address the upper part starts. In
> the Bondwell this is $8000,...
>
> The doc didn’t mention the ROM at all...the schematics of the
> Bondwell and the Elektor card support this theory.
>
> I thought that for CP/M 2.2 I could do with a normal Z80 system, for
> example the Micro-Professor plus some extra RAM. But after reading the
> Guide I’m not sure anymore...
You've talked about a Bondwell, an Elector, and a MicroProfessor. It
can be confusing to work with a number of hardware platforms at once,
but that's your choice. It's hard for others to discuss multiple
platforms as well. And dont' expect docs from one platform or
implementation, to describe things the same way, or how other
platforms work. Sometimes that is useful, different points of view,
sometimes not. Look for general books about CP/M but expect them to be
general not hardware-specific. Unless these platforms are already
running CP/M in some version, I'm not sure they are helpful to you for
your stated purposes.
> The next part is the software. The only thing I’m sure of is that the
> hardware developer has to provide the BIOS. But what about the BDOS?
BIOS describes the hardware to the BDOS, it MUST be specific for your
hardware. (So must FORMAT programs.) BDOS is the operating system, you
don't change that. The CCP reads the command line and does DIR and
gets programs by name, you don't change that either. Get all that
straight right away or you'll be lost - period.
The value of CP/M is that most of the "stuff" in it, runs the same,
you don't have to write or rewrite it, all the books refer to the same
stuff (for the same CP/M version). Again, small steps may get you
there faster - consider running a CP/M emulator, or another CP/M
system, to get familiar with how CP/M works, how these features work.
Note, that contradicts my "advice" about too many platforms. Again,
this is not a "dummies" world, you will need to make judgments.
Good luck, do some more reading, consider some more work on CP/M stuff
already working or readily available, and work your way up. That's my
general advice. Specific information is in books, documents, Web
pages, source code listings. Specific questions can likely get
specific and quick answers.
Herb Johnson
retrotechnology.com
Mr Emmanuel Roche, France
> Nope, just lack of time :(
Then, this is one more reason for *NOT* trying to develop a "nice
universal CP/M module" for your collection of Commodore computers!
Every time I wrote an article or a program, I had nothing else to do
during a few days, started from scratch not knowing how or where it
would end: several times, I rewrote the article/program as it evolved.
I don't think that I would have been able to do it if I had a family,
like you. Me, programming is a nice way of using winter days/evenings,
or week-ends.
> But a part of the fun is building one yourself.
So, I was right: you are suffering from "hardware craze"...
> IIRC the N8VEM and P112 started as a PCB with only terminal connection
Remember, Ruud: the first BASIC/CP/M computers had no screen! There is
no "CLS" in MBASIC: its line editor commands are designed to give
orders to the "printwheel" of an ASR-33 Teletype! No screen! So,
technically, a Z-80 CPU alone is enough to provide another CPU to an
already existing computer: you can re-use its screen.
But I was telling you: I think that it is a bad idea. It was done for
the Apple IIe. If it has not been done/already been done for the
Commodore computers, then why waste your time/money just to run CP/M
on your beloved Commodore computers?
Either your Commodore computers can do the 6 things that a computer
can do, and are then useful, or they cannot. Then, it would be more
logical to develop the missing category of program (except that
Commodore is dead: so, you would be the only man on Earth using your
program... In any case, you will spend some time/money: is it
reasonable, 20 years after the death of Commodore, to develop one
program for use only on those old micros? Me, my BASIC program are
running under CP/M 2.2, CP/M-86, MS-DOS, and in a "DOS Box" under
Windows. I consider them portable.).
> Hmmm, IIRC I know there was someone promoting GSX
> (or something like that) for CP/M. He should be interested :)
Hahaha! Recently, someone (whose name I forgot: Sorry!) mentioned
"MetaWindow": I will do something this Winter. However, I will do a
"screen driver" for the IBM Clown, not for a 20-years old 8-bit
computer. During 15 years, I produced "business graphics" using DR
Graph on the Hewlett-Packard HP-7470A graphics plotter: nobody ever
asked me how I produced them, yet I was the only person in town still
using CP/M: They all thought that I had the latest IBM Clown hardware
and software in town, while I had the last 8-bit computer in town. But
my HP plotter managed 10,000x3,000 dots (and in colors!), while the
printers of the IBM Clowns of everybody else were managing less than
1/10th of that. Unfortunately, I never finished my laser printer
driver...
> CP/M 80 never ran on a PC as well. Etc. etc. etc.
CP/M-86 is as straight a port of CP/M 2.2 as possible. That's why I
never liked it, and searched "CP/M-86 Plus" that John Elliott found on
the Siemens Simatic PG685. I then built a custom "IBM Clown" just to
run it. I now have a 400-MHz CP/M Plus computer. I am happy. John
Elliott also made a VGA patch for the "Dr. Logo" interpreter: my Dr.
Logo full-screen 3D graphics now appear instantly on screen (the
problem is how to share graphics). After using CP/M Plus, BASIC and
Dr. Logo during 15 years on a 4-MHz system, I really appreciate the
increase in speed of a 400-MHz system. You cannot stop progress.
> I must admit that I'm a bit disappointed in you behaviour. Here you
> have the opportunity to promote CP/M but the only thing you do with
> these kind of statements is driving people away. I'm sorry to hear that.
Courage, Ruud! I am only counseling you not to waste your time/money
adding CP/M to your Commodore computers, especially if you only want
to use the Z-80 CPU at 4-MHz. A 400-MHz improvement would be better,
but then I doubt that your 20-years old Commodore computers would be
able to deal with it... If it was not done 20 years ago, why do it
now?
Your Friend, Emmanuel.
Herbert Johnson
> Hello Emmanuel,
>
> I must admit that I'm a bit disappointed in you behaviour. Here you
> have the opportunity to promote CP/M but the only thing you do with
> these kind of statements is driving people away. I'm sorry to hear
> that.
Read Roche's other posts, and responses to them, and you will confirm
your own conclusions. Ruud, good luck with your efforts, and in
following your own interests in CP/M. Hope my previous remarks and
references will be useful. If you find useful "how to" Web resources
or ancient CP/M books, let me know via my Web site.
Herb Johnson
retrotechnology.com
Jonathan Graham Harston
> Hallo Jonathan,
> > Won't it be in the original magazine article?
> Elektor is Dutch and I have all articles as well (but in Dutch). I
the articles are English versions of the Dutch magazine, might have
done an English version. Do you have an approximate date?The most perfect world is an imperfect world as the imperfections
give people a reason to strive to change it.
Mr Emmanuel Roche, France
Ok. This is my 3rd message in this thread, in answer to your message.
I hope that it will be the last one.
In short, you asked how to build a "piggyboard" adding CP/M capability
to a Commodore computer. I answered that I considered this a bad idea,
and a waste of time and money.
It so happen that, this morning, I finished studying a CP/M program
whose source code has been lost, and the company which wrote it closed
many years ago. Just to give you an idea, I have spent 3 weeks
studying this file, from the first byte to the last, with SID. I found
several things, like tables, and that 2 different subroutines were
using "inline" parameters. 3 weeks of work, and I have not yet started
my Good Old disassembler (which should find some more curious things)!
This to show you that doing serious work with CP/M can lead you to
spend quite a lot of time and/or money before getting any software/
hardware working. In this case, I decided that this program was so
valuable that it was well worth the effort (despite having already
disassembled more than 20 CP/M Programming Languages).
Now, I will try to answer some of your questions. I noticed that
Allison was thinking "CP/M 2.2" in her explanations, while you seem to
have only experience with CP/M Plus. (20 years ago, I disassembled the
BIOS of the Amstrad PCW-8256, as already mentioned several times.)
> (...) One of the sources is Digital Research's own "CP/M Plus
> Programmer's Guide". Here, the banked system is explained.
> The 64 KB area is divided in two parts:
> - the lower part that can be swapped
> - the upper part that is always visible
> The document doesn’t explain at what address the upper part starts.
Well, this is not very important. I even wrote a BASIC program which
was self-adapting to the CP/M Plus under which it was running, showing
the actual "Resident BDOS and BIOS" parts of a computer.
The fundamental idea of CP/M Plus is to divide both the BDOS and the
BIOS into 2 parts: the "resident" part (in the top of the TPA) and the
"banked" part (in another "bank of memory"). Those "banks" have
subdivisions: let us call them "blocks". (The PCW adds 2 banks of
memory, one for the screen, and one for the RAMdisk.) To run, at the
minimum the "resident" part enabling communication between banks must
be inside the "memory space" of the processor (usually a Z-80 CPU).
Some systems used 16KB block sizes, some 4KB, etc. As long as the
block containing the "resident" code is always present in the memory
space of the processor, CP/M Plus can run. We are talking about 1KB
(2KB at the maximum) of code for each the resident BDOS and BIOS, so
it is possible to disassemble it (20 years ago, there was absolutely
no information available, especially in France, where Amstrad France
was saying that the PCW was not a microcomputer, but an improved
typewriter... One day, I learned that Tilmann Reh, the German
electronics engineer, had disassembled the resident part. I asked him
a copy, and compared with mine. Mine was 2 times longer than him,
which had only spare remarks in German. Mine contained all the
information found in the "System Guide", so you did not need to open
the manual to understand it.
> (...)I think it needs a circuit to hide the ROM as well.
Well, it all depends where you want to put this ROM. Remember that
there are several banks of memory. Your ROM could be simply in another
bank of memory than the TPA: this way, there would be no conflict. The
ROM would have control of the computer at boot time, copy all its
stuff in various blocks of various banks, then transfer control to the
resident part in another bank. This way, no memory space would be
lost.
> The next part is the software. The only thing I’m sure of is that the
> hardware developer has to provide the BIOS. But what about the
> BDOS?
Normally, unless you are Locomotive Software and want LocoScript to be
the only program the user can use, you do not modify the BDOS. When I
disassembled it, 20 years ago, I also found the funny way it was
loaded inside memory...
> I assume that the WBOOT vector replaces the BOOT vector,
> once the content of the ROM is copied to RAM.
Well, "cold boot" and "warm boot" are 2 separate subroutines so,
technically, there is no need to replace one by the other. They can be
following each other. The famous "JUMP BIOS" in "Page Zero" of the TPA
points to "warm boot": you will notice that it is 3 bytes *after"
"cold boot". So, both are present in memory.
> (...) The P.Guide also mentions RAM reserved for the “Buffers”
> above the OS (page 1-2, 1-3 and 1-4).
Hahaha! This is something that I discovered, 20 years ago! The
"Resident BIOS" uses another 128-bytes "DMA Buffer" for its own
purposes when it transfers parameters from one block in a bank of
memory to another one (like from the TPA to the "banked BDOS"). If you
disassemble the 2 or 3KB of the "Resident" part of an Amstrad
PCW-8256, you will quickly notice this 128 bytes buffer. There is also
a mechanism for adapting the size of parameters copied to the "BDOS
Function Number" actually used, but let us keep this simple (else,
what would you discover?).
> Many thanks for your patience and help!
You are welcome! I am just trying to save you time and/or money.
If you are still using a Commodore CMB-8032, you could use COMAL. I
think that it was developed in Denmark. (Apparently, COMAL started on
Commodore computers.) (I am still searching for the MS-DOS version. I
know that a C=64 version existed.)
Your Friend, Emmanuel.
Peter Dassow
> Does something exist like ”Do it yourself CP/M hardware for Dummies”
> and “Build your own CP/M BIOS (and whatever more is needed) for
> Dummies”?
> Of course I did some research on the hardware. One of the sources is
> Digitals own CP/M 3.0 Programmers Guide.
> I thought that for CP/M 2.2 I could do with a normal Z80 system, for
> example the Micro-Professor plus some extra RAM. But after reading the
> Guide I’m not sure anymore i.e. I think it needs a circuit to hide the
> ROM as well. And then the fact that a program needs to start at $0100.
> Can anybody shed some light on this, please?
Hi Ruud,
nice to hear from you again. I guess it's a lot of easier to start with
CP/M 2.2, and do it for your CBM as an additional module in the same
manner Commodore did it for the C64. I mean, just try to relocate the
memory space for 4000h (or another reasonable address), so the zero page
of the 65xx and the start address location for CP/M will not be at the
same address.
A very good starting point for a (new) CP/M BIOS would be the original
CP/M Operating System Manual from DR for CP/M 2.2, Appendix A, "MDS-800
I/O drivers".
Also, you can take a look into the commented C64 CP/M BIOS sources at my
own page ( http://www.z80.eu/c64.html ).
Groetjes
Peter
Ruud
> Do you have an approximate date?
It was published in "Elektor Compting" in 1986. I searched my Duch
version for more details but I only found the year. EC was published
in NL and Germany but I haven't any idea if it was published in the UK
(or anywhere) as well.
I also looked for the PCB number but could not find it in "Print
sevice". I have to look on the card I have at home.
Ruud
> There are also Commodore discussion groups, in Usenet ....
I'm very well known with them. In fact, I consider myself a bit as the
hardware guru on CP/M for the C64 as I was the first one to re-
engineer the cartridge.
> Also, there are Commodore simulators you can run on Windows and Linux,
> you can do some development with those.
These emulate existing hardware, not new and thus unknown hardware :(
Regards, Ruud
Ruud
> I mean, just try to relocate the memory space for 4000h ....
I think you, and maybe others as well, think that I want to turn a
Commodore into a CP/M machine by adding a Z80 like the CP/M card for
the C64. No, the C= is only used as a terminal and will be connected
through a 6522 to a stand-alone CP/M system equiped with a PIO, 8255
or, in case of the Elektor card, a 6821. And that's why I call it
"universal". Equip a C64 with a 6522 (or better a 6526) and it can
work as terminal as well.
Take the Micro-Professor as example. It has a free PIO on board that
can do the communication with the C=. I only have to add extra RAM and
a circuit that hides the RAM after copying itself to RAM. That's it.
I take Herberts advice to start with CPM 2.2 first. Also means less
hardware to take care off :)
Regards, Ruud
James Moxham (Dr_Acula)
think
that you mean "building the minimum hardware able to run CP/M"? In
that case, I must point you to Andrew Lynch's N8VEM, which is
Thankyou Mr Roche for kindly mentioning the N8VEM. It isn't my board
but it is something I've contributed to. IMHO Andrew Lynch is a genius
as he cracked the problem of getting a hard drive onto a single
(battery backed) ram chip. The N8VEM is a very active group and it may
be worth considering joining the group. No hardware/software questions
are considered 'dumb'!
There is also an active CP/M group (perhaps even more crazy than the
N8VEM group) who are attempting to put CP/M into a Propeller chip.
This exists as a Z80CPM emulation written in propeller assembly and
currently runs at about the same speed as a real 4Mhz Z80. It really
does work and I have played Pacman on it, as well as useful programs
like Wordstar and Basic/C. The exciting thing about the propeller is
that it has a micro sd card that emulates multiple 8Mb hard drives
that are the same as the Altair SIMH drive images. There is a board
coming out very soon which may be the smallest and lowest power CP/M
machine around with a 1.3 inch square PCB with a few surface mount
chips on one side and a micro sd card on the other.
Hardware hacking is fun! Especially CP/M where everything is so
logical and also where there is a wealth of friendly support (like
this forum!)
How do you get started? Well, for the N8VEM you can start off with a
board and some chips and fire up the soldering iron and get a board
running http://smarthome.viviti.com/build Then you can start hacking
the CP/M bios. I've hacked it to add drivers for a 20x4 LCD display
and a standard PC keyboard for instance. Lots of eprom reprogramming
needed but very satisfying when you can print "Hello World" on a tiny
screen.
Another option might be to build a propeller emulation (which has less
chips and is about the same cost).
Or - get the Altair SIMH software working and hack the BIOS and
recompile it, which you can do on a PC with no hardware needed.
http://www.schorn.ch/cpm/intro.php
Or - use the hardware you have. Re "I have several ideas for creating
a nice universal CP/M module for
more then one of my Commodores." - Do you have some schematics? Maybe
we can a) get what you have working and b) try to work out a way of
modifying the hardware, eg by reprogramming eproms etc?
Jason King
conout (functions 1 & 2) that get console input and give console output.
ld c,1 ' conin
call 0005h
' first waiting input character is now in A.
ld c,2 ' conout
ld a,'A'
call 0005h
' character 'A' sent to output device.
If your cbm or xyz has a serial connection to your cp/m machine you can
support this interface.
Mr Emmanuel Roche, France
> If you are still using a Commodore CMB-8032, you could use
> COMAL. I think that it was developed in Denmark. (Apparently,
> COMAL started on Commodore computers.) (I am still searching
> for the MS-DOS version. I know that a C=64 version existed.)
- "Update On COMAL: A SuperBASIC"
Jim Butterfield
"COMPUTE!" magazine # 54, November 1984, p.102
COMAL is a computer language which was developed in Denmark as an
offshoot of BASIC. Some programmers prefer it and think of it as a
streamlined, extended, and systematized BASIC.
COMAL has been available for some time, mostly for Commodore 32K PET/
CBM machines. Previous versions have had some success despite a few
drawbacks and implementation problems. Now, new versions of COMAL are
being released, and the new packages look promising.
The New Generation
-----------------------------
COMAL has traditionally been available in the public domain (that
means free). It's a sound language: The loose ends of traditional
BASIC have been tightened into a much smoother system. The ease of use
for beginners has been maintained, and added features significantly
enhance the programming power. Yet this free, powerful language has
enjoyed only modest success.
The problem has been limited resources. Traditional COMAL would fit
only into a 32K PET/CBM; thus, only users with the biggest systems (of
that era) could use COMAL. Second, the COMAL interpreter took up a
good deal of memory, leaving room for only a small user program. To
offset this difficulty, a "split" COMAL was developed which used a
separate editor and interpreter; but this proved awkward to use.
Until recently, the best COMAL arrangement was obtained by using a CBM
8096 computer; with the extra 64K memory, there was plenty of room for
both the interpreter and the user's program. Alternatively, a ROM
board could be purchased to implement COMAL on a CBM 8032; this
allowed large programs to be written, but the board was costly—about
$400.
It looks like things are changing. New versions of COMAL are being
released that will make it an attractive language. A disk version for
the Commodore 64 is now in the public domain; a cartridge version is
soon to be made available for sale; and even the ROM board for the PET/
CBM 8032 is being redesigned to incorporate interesting new features.
Versions Of COMAL
-----------------------------
Disk-based COMAL for the Commodore 64 is named COMAL 0.14. It's free
in North America, but it's not public domain. The package prints a
copyright statement, but permits unrestricted distribution and
copying. COMAL 0.14 is available from clubs, user groups, and the
COMAL user group in Madison, Wisconsin. It's a good language
implementation, complete with graphics and a complete set of error
messages drawn from disk as needed.
COMAL 2.0 is a plug-in cartridge for the 64 which is expected to be
available from Commodore in 1985 for less than $100. It's
significantly more powerful than COMAL 0.14—it offers much more
program memory and includes extra features such as error trapping and
program chaining or overlaying.
The COMAL board has been redesigned for the 8032 computer. The price
of the revised board is expected to be similar to the previous version—
that is, around $400—but there are some new features. First, if you
don't want to use COMAL immediately, you can use BASIC, and the
computer becomes an 8096 with 64K extra memory supplied by the COMAL
board. Second, a video board can be added to the assembly to perform
high-resolution graphics, including turtle geometry. Third, the board
contains a time-of-day and date clock which is battery-powered and
keeps good time even when the unit is off. I installed a board and
checked the clock; before I reset it, it gave the correct time for
Copenhagen, where it was manufactured.
(...)
If languages interest you, this one is well worth a look. (...)
EOF
Ruud
> Do you have some schematics? Maybe we can a) get what you have
> working and b) try to work out a way of modifying the hardware
>, eg by reprogramming eproms etc?
Very kind offer! I have a PNG of the schematics of the MicroProfessor.
Even have the SCH if you have Eagle (www.cadsoft.de):
http://www.baltissen.org/images/mpf-1.png
I had a very quick look at the N8VEM but its schematics are not drawn
in the form what I'm used to so I need to study them a bit more.
If you have schematics laying around of the smallest system possible
that could be used with CP/M 3.0, I would be happy. IMHO it will
contain an EPROM, RAM (> 64 KB) a circuit to hide the ROM, a circuit
to swap the bottom part of the memory and some I/O to communicate with
the rest of the world.
Yesterday evening I got this idea: why not using my Bondwell? I can
connect it to my PC using a RS-232 cable. Now I can start hacking the
original ROM to use this RS-232 port for all action including loading
and saving software. One small problem: I never ever have programmed a
single byte for the Z80SIO. I know how to read data sheets but if
someone has a small program available that explains the minimum ins
and outs of programming this IC, I would be very gratefull!
Studying the schematics of the Bondwell, I noticed that it has a
printer port driven by 6821. (why not a PIO ???). I could replace it
with another 6821 where all I/O-pins have been bent up and connected
to a 25-pin male D-connector which on its turn can be connected to the
LPT port of a PC. More work but at least I understand all the ins and
outs of the 6821. But I only will use this option if the above doesn't
work.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
Ruud
> I had a very quick look at the N8VEM but its schematics are not drawn
> in the form what I'm used to so I need to study them a bit more.
Found other ones, even the Eagle files :) Very simple to understand
with one exception: why a seperate 74273 for en/disabling the ROM
while there are still 4 pins available at the other 273, used for
selcting the RAM?.
James Moxham (Dr_Acula)
Seperate 74273 because the original N8VEM used one latch for latching
the upper part of a 1mb eprom for an eprom 'disk'. I went for a 32k
eprom as it was much cheaper and quicker to program (and the chips
seem more robust - I zapped a few 1mb eproms). But to maintain code
compatability I left the latches in, even though a lot of pins are not
used. Theoretically one could save a chip.
Your design looks fairly standard.
Z80 SIO I think will be similar to the 16550. Roger Hanscom is the
expert on the Z80 SIO and I have seen his code somewhere. But anyway,
the 16550 has a number of physical ports but you only need to access
two - one port is a status and one is the data byte. So for output -
read the status port, if it is ok, then send the byte. For input, read
the status port, if no byte then loop, if there is a byte, read the
data byte. The actual physical address of your ports I think are set
by your IC9B.
Reading:
CONST: ; CONSOLE STATUS, RETURN 0FFH IF CHARACTER READY, 00H IF
NOT
IN A,(UART + $05) ; READ LINE STATUS REGISTER (UART5 = $68 + $05)
AND $01 ; TEST IF DATA IN RECEIVE BUFFER
; IS THERE A CHAR READY? 0=NO, 1=YES
JP Z,NOT_READY
LD A,$FF ; YES, PUT $FF IN A AND RETURN
NOT_READY:
; NO, LEAVE $00 IN A AND RETURN
RET
CONIN: ; CONSOLE CHARACTER INTO REGISTER A
CALL CONST ; IS A CHAR READY TO BE READ FROM UART?
CP $00 ;
JP Z,CONIN ; NO? TRY AGAIN
IN A,(UART) ; YES? READ THE CHAR FROM THE UART (UART0 = $68 + $00)
; REGISTER AND PASS BACK TO USER
RET
and writing
CONOUT1:
IN A,(UART + $05) ; READ LINE STATUS REGISTER
AND $20 ; TEST IF UART IS READY TO SEND
JP Z,CONOUT1 ; IF NOT REPEAT
LD A,C ; GET TO ACCUMULATOR
OUT (UART),A ; THEN WRITE THE CHAR TO UART (UART0 = $68 + $00)
RET
As an aside, should there be a current limiting resistor on the base
of Q10?
But - here is the problem. How do you hack the BIOS easily? It
involves tedious programming of eproms. Or an eprom emulator (which is
very expensive). I solved the problem by getting 20 eproms and an
erasor and erasing them 10 at a time and mindlessly making changes one
line at a time. I put a ZIF socket on the Z80 board and with about 1
minute per eprom program cycle it was possible to get things like a
keyboard driver working. But very tedious.
In the last few months I've been playing with the Propeller chip. The
bios changes end up in a file on an sd card, which is quicker to edit.
I am just double checking with someone via email, but I think we have
CPM 3 down to five chips. It is all very experimental but it may be
another option.
Rolf Harrmann
On Sat, 24 Oct 2009 06:12:36 -0700 (PDT), Ruud wrote:
>Yesterday evening I got this idea: why not using my Bondwell? I can
>connect it to my PC using a RS-232 cable. Now I can start hacking the
>original ROM to use this RS-232 port for all action including loading
>and saving software. One small problem: I never ever have programmed a
>single byte for the Z80SIO. I know how to read data sheets but if
>someone has a small program available that explains the minimum ins
>and outs of programming this IC, I would be very gratefull!
Demo-Code for a DART or SIO.
http://www.hd64180-z80180.de/assets/download2009/scream8.zip
ca. 208KB
The Program scream8.com sent and receives character to the DART or
SIO.
Please before you start the Program scream8.com a second Time must
start a new Character to the DART or SIO sent via Hyperterm.
The new Character are not a "." this is a Character for exit the
Program.
This is a N8VEM Zilog Peripheral Board with Dart or SIO.
http://www.hd64180-ecb.de/html/board6.html
Rolf
Ruud
> But - here is the problem. How do you hack the BIOS easily? It
> involves tedious programming of eproms.
Nope. At the moment I use the AT29C256 EEPROM, 27256 pin compatible,
for various Commodore projects. For example, in http://www.baltissen.org/newhtm/1541ide.htm
I replaced the original 27128 EPROM with a Textool ZIF socket. In
matter of seconds I have taken out the AT29C256, reprogrammed it and
put back in the socket again.
> Or an eprom emulator (which is very expensive).
I have built one myself as well. But has to be connected to the LPT
port which I only can program under DOS. My Universal programmer,
LabProg+ from Elnec, works under XP which enables me to check PDF's,
use my editor and assembler all at the same time. A bit more
conveniant IMHO.
>... and with about 1 minute per eprom program cycle ...
No erasing needed, never really checked it but I guess about 15
seconds. It is that I have these 29C256 around but otherwise I would
have used 29E010's or what ever FlashRAM/EEPROM with the help of a
socket converter. This is nothing more then a 32 pins (ZIF) socket
soldered on top of a 24/28 pins socket. The unused address lines are
wired to +5V and I only have to tell my programmer only to use the
upper xx KB of the 29xxxx.
As normal sockets have to thick pins, i.e. you run the risk to damage
the original socket where the (EP)ROM was seated, I use an obselete
EPROM. I smash the glass and carefully remove the inner wires. I check
it an Ohm meter and even use a car battery to "warm up" unseen left
over wires. In this way I end up with a very stable base for my
converter.
Ruud
> IN A,(UART + $05) ; READ LINE STATUS REGISTER (UART5 = $68 + $05)
Oops, almost forgot this: thank you for the code !!!
Steven Hirsch
> The original plan was to let the 6809 leverage the N8VEM system by
> making the Z80 in the SBC act as a "IO processor". The Z80 would be
> able to serve IO resources like the floppy drives, IDE hard drives,
> and video. If you are interested maybe we could reuse some or all of
> the 6809 host processor design for your CP/M board since it is very
> similar to what is already being done. Basically plug in a 6821 PIA/
> 8255 PPI into a Commodore and then the Z80 can communicate through the
> "bridge" and share resources.
>
> I think a CP/M CBIOS could be written to support such a concept much
> like a FLEX or CUBIX system would work for the N8VEM system. I hope
> this helps.
Andrew,
With the proper support for page mapping, that 6809 board should be capable of
running OS-9/Nitros-9 for the Tandy Color Computer. Obviously the graphics
video modes won't be available, but OS-9 was a Unix-y environment that
supported multiple users in terminal (text) mode.
NitrOS-9 is an opensource clone of OS-9 for which full sources are available.
Steve
mike7g
How about Symbos on an N8VEM? :-)
http://www.symbos.de/facts.htm
John Elliott
: The only experience I've had with a banked CP/M PLUS system is the
: Amstrad PCW256. I was never able to gather all the tools together,
: and source code, to remake a cp/m 3 system file for it.
The PCW implementation is a bit weird; it's almost as if CP/M Plus is
running as an application on top of a lower-level task-switching kernel. The
system file contains:
- a loader that copies all the bits below to the right place
- the aforementioned task-switching kernel
- drivers for the built-in screen, keyboard, etc.
- (in later versions) a loader for Field-Installable Drivers
- a driver for the built-in printer. This runs as three separate processes,
all of which have a higher priority than CP/M.
- the bitmap font for the screen
- CCP.COM
- CPM3.SYS
I'm sure the reason for this arrangement is code-sharing with other PCW
operating systems, like LocoScript and LocoLink. They all have the same
kernel (or a very similar one) but no BIOS, BDOS or CCP.
--
John Elliott
Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show
John Elliott
: Does something exist like ???Do it yourself CP/M hardware for Dummies???
: and ???Build your own CP/M BIOS (and whatever more is needed) for
: Dummies????
Not really. The Digital Research manuals (for CP/M 2.2, the System
Alteration Guide; for CP/M 3, the System Guide) are probably the nearest
you're going to come.
: Of course I did some research on the hardware. One of the sources is
: Digitals own CP/M 3.0 Programmers Guide. Here the banked system is
: explained.
: The 64 KB area is divided in two parts:
: - the lower part that can be swapped
: - the upper part that is always visible
: The document doesn???t explain at what address the upper part starts. In
: the Bondwell this is $8000, that is, if I interpreted the schematics
: correctly.
It's system-dependent. When you build CP/M 3, you have a file called
GENCPM.DAT which contains system parameters. One of them is COMBAS, the base
of common memory.
: The doc didn???t mention the ROM at all. I assume it first copies its
: own contents to RAM and then switches to RAM. The schematics of the
: Bondwell and the Elektor card support this theory.
What normally happens is that the boot ROM loads a bit of code (perhaps a
track, perhaps a single sector) from a floppy disc, and then switches itself
out, leaving 64k of RAM.
Depending on how helpful the boot ROM is, it either managed to load all of
CP/M, or it just brought in a first-stage loader and that has to read in the
rest. However it is, you need to end up with memory arranged like this for
CP/M 2:
+-------------+ FFFF
| BIOS |
+-------------+
| BDOS |
+-------------+
| CCP |
+-------------+
. .
. .
+-------------+ 0100
| Zero page |
+-------------+ 0000
like this for non-banked CP/M 3:
+-------------+ FFFF
| BIOS |
+-------------+
| BDOS |
+-------------+
. .
. .
+-------------+
| CCP |
+-------------+ 0100
| Zero page |
+-------------+ 0000
and like this for banked CP/M 3:
Bank 0 Bank 1
+-------------+ . . . . +-------------+ FFFF
|Resident BIOS| |Resident BIOS|
+-------------+ +-------------+
| BDOS | |Resident BDOS|
+-------------+ +-------------+
. . . .
. . . .
+-------------+ . . . . +- - - - - - -+ Base of common memory
| data buffers| . .
| | . .
| Banked BIOS | . .
| | +-------------+
| Banked BDOS | | CCP |
| | +-------------+ 0100
| Copy of CCP | | Zero page |
+-------------+ +-------------+ 0000
(Depending on how much memory you've got, there may be more banks. PCW
CP/M keeps its copy of the CCP in bank 2 rather than bank 0, for example).
: I thought that for CP/M 2.2 I could do with a normal Z80 system, for
: example the Micro-Professor plus some extra RAM. But after reading the
: Guide I???m not sure anymore i.e. I think it needs a circuit to hide the
: ROM as well. And then the fact that a program needs to start at $0100.
: Can anybody shed some light on this, please?
While CP/M is running, any ROM has to be at the top of memory (it is
treated as part of the BIOS). It needs RAM all the way from 0 to at least the
start of the BIOS. The same goes for memory-mapped I/O (eg, video RAM); that
all has to be above the BIOS, or switched in and out with memory paging.
: The next part is the software. The only thing I???m sure of is that the
: hardware developer has to provide the BIOS. But what about the BDOS? I
: know it is the interface between the BIOS and the CCP and that it
: gives the user/programmer a way to overrule the BIOS (if I???m
: correctly). In that case should the hardware developer create and
: maintain it?
You supply the BIOS. The BDOS and CCP shouldn't need any changes, except
to be relocated to the correct address. This is done with MOVCPM under
CP/M 2, and GENCPM under CP/M 3.
: I found this (and equivalent) info on Internet:
: The BIOS begins with the following jumps to service routines:
: JMP BOOT ;-3: Cold start routine
: JMP WBOOT ; 0: Warm boot - reload command processor
: JMP CONST ; 3: Console status
: JMP CONIN ; 6: Console input
: Etc. etc.
: I assume that the WBOOT vector replaces the BOOT vector once the
: content of the ROM is copied to RAM.
When CP/M is started for the first time, control is given to BOOT. BOOT
should do hardware initialisation (if any) and then, as a rule, fall through
to WBOOT.
WBOOT should do the following:
* Set up a jump at 0000h to WBOOT itself.
* Set up a jump at 0005h to the BDOS entry point (6 bytes after the start of
the BDOS). Under CP/M 2, this is fixed. Under CP/M 3, it's stored in the
last 2 bytes of the resident BDOS (xxFEh).
* Get the CCP into memory (for CP/M 2, just below the BDOS; for CP/M 3, at
0100h). This means either reloading it from disc, or copying it in from
another memory bank.
* Jump to the start of the CCP.
: The P.Guide also mentions RAM reserved for the ???Buffers???
: above the OS (page 1-2, 1-3 and 1-4). Page 1-6 shows a picture
: mentioning BIOS, BDOS, Loader etc. filling the RAM. I haven???t figured
: out yet what is what. I admit I haven???t read/studied the P.Guide that
: good so far so if someone says ???RTFM??? I won???t blame him. But if
: someone could shed some light on it, please!
In CP/M, each disc drive has certain data structures (the disc parameter
block, the allocation bitmap, etc.). These are provided by the BIOS, and so
it's the responsibility of the BIOS writer to allocate space for them.
In the memory diagram, you don't need to worry about the program loader;
that only applies in CP/M 3, and is put in place by the CCP as and when
required.
Steven Hirsch
> Hi! There is nothing stopping any builder from porting Nitros-9,
> Symbos, or any other operating system for the Z80, 8080, or 6809 to
> the N8VEM system. If a builder wants it they are free to do it. All
> it takes is someone interested and motivated to do the work.
Granted, but proper OS-9 support will require hardware features that I do not
believe are present. The kernel needs to individually map the lower 15 4k
chunks of the logical address range to arbitrary 4k chunks of physical memory.
In a Tandy CoCo, this is handled by a dedicated ASIC called a "GIME". OS-9
68k systems could (I think) do this through CPU capabilities.
How difficult would that be to implement in your hardware?
Steve
Ruud
> Not really. The Digital Research manuals ....
Many thanks for your reply!
Kind regards, Ruud
Axel Berger
>OS-9 68k systems could (I think) do this through CPU capabilities.
No, at least not as far as I'm aware.
All...@localhost.net
wrote:
>Hi! Yes, the GIME is a proprietary ASIC MMU that Tandy used on the
>CoCo3. I believe it would be quite difficult to implement it as I
>believe it would require reverse engineering the GIME with and
>replacing the on board 6809 host processor SRAM. It probably is not
>necessary to do that since there are versions of Nitros-9 the CoCo
>that do not require the GIME (level 1 Nitros-9, I believe) which
>probably could be adapted to work with the N8VEM 6809 host
>processor.
I believe the GIME was the Moto MMU + other chips merged in a FPGA
so there is little if any new tech there. I'd have to look up the
moto chip but it also added the video interface function that dual
ported ram.
>Porting the Nitros-9 OS would be a fairly substantial undertaking.
>The IO mezzanine board I am working on at the moment adds a 6840 PTM,
>6522 VIA, and 6551 ACIA. My plan is to use one of the unused ACIA
>lines (DTR) to allow bank switching on the 6809 host processor. It
>uses a 128K x 8 SRAM so the upper 64K is currently unused.
>
>I don't have any plans to incorporate GIME like MMU functionality into
>the IO mezzanine board although I suspect it is probably possible. I
>think it would involve disabling the on board 6809 host processor SRAM
>and replacing it with a GIME MMU with its own SRAM. Implementing an
>MMU would require quite a bit of circuitry I imagine and I don't see
A paging MMU is fairly simple and has been done for most CPUs. If
there is any caveat its matching MMU to the software allocation and
deallocation management. You can think of that as a driver but
without knowing OS9 or Nitros to any detail it may be burried code.
>the benefit of it. If another builder decided to port Nitros-9 all
>the pieces are there although additional hardware would be required
>for the higher levels (2 and 3). Probably the most feasible OS to
>port to the N8VEM 6809 host processor would be either FLEX or CUBIX.
In both cases the code is more available and at least CUBIX assumes
both no MMU and flat memory.
>This topic probably would be better moved to comp.sys.m6809 as it is
>only marginally related to CP/M. However, I still do believe that the
>6809 (or 6502) to 6821/8255 to Z80 bridge design used in the N8VEM
>6809 host processor would perform like the OP requested. The "host
>processor" approach was used quite successfully on the BBC Acorn and
>N8VEM systems. It could be applied in a general fashion to the CBM
>system since it uses a 6502 and 6821 PIA interface. I think it could
>provide a Z80 "host processor" for CP/M.
The general idea can be applied to any/many systems. It was done for
DEC systems like DECMate (ii and II), Pro(300, 350 and 380), and even
VAX. In all those cases the native system was NOT z80 but hosted a
complete Z80 platform that ran CP/M. The host system provided
terminal IO, printer interfaces, networking, and disk IO as needed.
IN all cases the interface was usually a series of parallel IO ports
and a protocal shared with the peripheral z80 and host system for
transfers (desitnation, data).
Allison
>
>Thanks and have a nice day!
>
>Andrew Lynch
Hans Bus
I may have the Elektuur lying around somewhere. If i remember coorrectly
only 1 or 2 issues were done of the "Elektuur Computing".
I have the one with the description of the CP/M "VarBios".
I will let you know as soon as I can.
regards,
Hans Bus
s_dub...@yahoo.com
> s_dubrov...@yahoo.com wrote:
>
> : The only experience I've had with a banked CP/M PLUS system is the
> : Amstrad PCW256. I was never able to gather all the tools together,
> : and source code, to remake a cp/m 3 system file for it.
>
> The PCW implementation is a bit weird; it's almost as if CP/M Plus is
> running as an application on top of a lower-level task-switching kernel. The
> system file contains:
>
> - a loader that copies all the bits below to the right place
> - the aforementioned task-switching kernel
> - drivers for the built-in screen, keyboard, etc.
> - (in later versions) a loader for Field-Installable Drivers
> - a driver for the built-in printer. This runs as three separate processes,
> all of which have a higher priority than CP/M.
> - the bitmap font for the screen
> - CCP.COM
> - CPM3.SYS
>
> I'm sure the reason for this arrangement is code-sharing with other PCW
> operating systems, like LocoScript and LocoLink. They all have the same
> kernel (or a very similar one) but no BIOS, BDOS or CCP.
>
32mhz clock signal for it. Also iirc, the ports which control 16k pg
selection are tied to it, as well as the memory chip address lines.
Do you know much more than that about it?
Steve
John Elliott
: That's interesting. The FPGA is a bit of a mytery, IIRC there is a
: 32mhz clock signal for it. Also iirc, the ports which control 16k pg
: selection are tied to it, as well as the memory chip address lines.
: Do you know much more than that about it?
Only what it says in the service manual -- which is, basically, that the
PCW is made up from a Z80, a gate array, a floppy controller, and the
microcontroller that drives the printer. The motherboard RAM all seems to
sit on the far side of the gate array, with separate address and data buses
(presumably so that the gate array can access memory to generate the video
display).