Discussion:
FreeCP/M
(too old to reply)
Ruud
2011-03-27 12:23:29 UTC
Permalink
Hallo allemaal,


Trying to create my own CP/M system and doing the needed research, I
more and more get the feeling that whenever it comes to creating the
needed system disk, the user first must have a working system to be
able to do so. Why? Because he needs files like BNKBDOS3.SPR and
RESBDOS.SPR. And then it needs GENCPM to create CPM3.SYS.

I want to be able to create CPM3.SYS using my own tools/assembler/
compiler, based on readable sources. This is what the FreeDOS guys do.
So my question: is there already a project that does the same for CP/
M?

If not, what about a FreeCP/M project? Goal: to produce sources and
executables which can replace the DR provided tools and still 100%
compatible.

And once having these, one can think about CP/M 4 etc......


Groetjes, Ruud Baltissen
PC Pete
2011-03-28 12:49:42 UTC
Permalink
Post by Ruud
I want to be able to create CPM3.SYS using my own tools/assembler/
compiler, based on readable sources. This is what the FreeDOS guys do.
So my question: is there already a project that does the same for CP/
M?
I don't think so, sorry.
Post by Ruud
If not, what about a FreeCP/M project? Goal: to produce sources and
executables which can replace the DR provided tools and still 100%
compatible.
Great idea, see below...
Post by Ruud
And once having these, one can think about CP/M 4 etc......
Ruud, that's a real can of worms you're opening there! Hence the lack of response...

I was going to post something similar about a month ago regarding CP/M 4 and the possibility of exactly what you suggest - separately buildable (cross-compilable) without
being bootstrapped by itself (after all, how did they get GENCPM to run without CP/M to run it on? :)

But I posted something in a related subject a day or two prior, and the responses were... well, read them yourself, do a search for "philosophy". I decided not to
irritate the denizens here any more, even though the folklore UGs weren't the right place, either!

I couldn't agree with you more - defining a hardware configuration guidelines, providing individually buildable components with OpenSource sources, fully Z80 source-code
compliant (and rebuildable for the few remaining 808x machines ;), and freely contributed to and supported. Clear instructions on how to patch or build or replace or add
modules (hardware dependencies). Simple installation. Small size. Able to handle >1M RAM, boot image ROMs, FLASH ROM, etc, etc, etc. A bit like linux started out, with
everyone who cared contributing bits of driver code, graphics, filesystem...

Nirvana, right?

I'm planning on doing something in that area as I build my next CP/M system in the next 2 months, so if there's anything I can do, let me know.

(And don't mention "philosophy" or the phrase "what if..." again! You'll wake them up and they'll get ya!)
-PCPete
Ruud
2011-03-28 16:44:44 UTC
Permalink
Hallo PCPete,
Post by PC Pete
Ruud, that's a real can of worms you're opening there! Hence the lack of response...
Jezus also started on his own, even got killed because of his ideas,
and nowadays more then a lot of people admire him. I only hope you
won't kill me :)
Whether you're right or wrong, express yourself. But when saying
nothing, you will loose anyway!
Post by PC Pete
Nirvana, right?
Most of the time Nivana doesn't come of its own. In that case you have
to create it yourself. So let's start now! :)
Post by PC Pete
so if there's anything I can do, let me know.
If you have time, please collect the information we need to build the
various files. For example, you'l find the documentation of the BIOS
in the CP/M 3 System guide. What about BDOS, CPMLDR etc.?

Anyway, I have found various source files from which I hope they can
serve as base for the project.


Groetjes, Ruud Baltissen
Dutch CP/M user
www.Baltissen.org
Post by PC Pete
(And don't mention "philosophy" or the phrase "what if..." again! You'll wake them up and they'll get ya!)
-PCPete
Tilmann Reh
2011-03-29 07:23:42 UTC
Permalink
Post by Ruud
If you have time, please collect the information we need to build the
various files. For example, you'l find the documentation of the BIOS
in the CP/M 3 System guide. What about BDOS, CPMLDR etc.?
Anyway, I have found various source files from which I hope they can
serve as base for the project.
The BDOS sources are publicly available (DRI originals, as well as
commented disassemblies).

The tools (like GENCPM) were written in PLM, the sources also are at
Gaby's site. Converters from PLM to C should be available (or re-write
the tools in any modern language).

So this surely is a /really/ laborious task - but not a problem due to
lack of information.

Tilmann
Floppy Software
2011-03-29 12:39:08 UTC
Permalink
Post by Ruud
And once having these, one can think about CP/M 4 etc......
Hi Ruud!

That's that I want: A new CP/M version built by the CP/M fans.

My humble knowledge in building CP/M it's not enough to do
the task, but I know that there are a lot of persons in this
newsgroup that can do it.

It's very important to preserve CP/M as is, and its history,
but (for me) it's very important to keep the CP/M flame alive
with new projects.
Ruud
2011-03-29 16:46:45 UTC
Permalink
Hallo Floppy Software,
Post by Floppy Software
Hi Ruud!
That's that I want: A new CP/M version built by the CP/M fans.
My humble knowledge in building CP/M it's not enough to do
the task, but I know that there are a lot of persons in this
newsgroup that can do it.
It's very important to preserve CP/M as is, and its history,
but (for me) it's very important to keep the CP/M flame alive
with new projects.
Thank you for your support and encouraging words!


Groetjes, Ruud Baltissen
www.Baltissen.org
dott.Piergiorgio
2011-03-29 18:00:47 UTC
Permalink
Post by Ruud
Hallo Floppy Software,
Post by Floppy Software
Hi Ruud!
That's that I want: A new CP/M version built by the CP/M fans.
My humble knowledge in building CP/M it's not enough to do
the task, but I know that there are a lot of persons in this
newsgroup that can do it.
It's very important to preserve CP/M as is, and its history,
but (for me) it's very important to keep the CP/M flame alive
with new projects.
Thank you for your support and encouraging words!
and I can suggest, as a good starting objective, a "CP/M ultralite",
that is, can run in a 16k TPA ?

And, related question, how is possible, with altz80, emulate at least
the smallest floppy size ? (I have figured that is the early shugart
SA-400, 35 tracks of 18 sectors of 128 bytes, 2304 bytes for sector, for
a total of 78 and 3/4 Kbytes (80,640 bytes) and someone has tried to
cram into it CP/M 1.4 or 1.3 ?

and, interesting thought, why don't experiment about a sort of
"bi-tasking" or "bi-threading" thru the Z-80's EXX ? (I know, will be
necessary some stack/CALL/RET alchemy for the instruction pointer
register...)

Best regards from Italy,
dott. Piergiorgio.
Holger Petersen
2011-03-29 19:41:11 UTC
Permalink
Post by dott.Piergiorgio
and I can suggest, as a good starting objective, a "CP/M ultralite",
that is, can run in a 16k TPA ?
CP/M 1.4 was supposed to do that. And, AFAIK, I did habe 8 KByte RAM
back in 1980 [*]...
Post by dott.Piergiorgio
a total of 78 and 3/4 Kbytes (80,640 bytes) and someone has tried to
cram into it CP/M 1.4 or 1.3 ?
And my Version of CP/M came on an 8 inch Disk as well as en 5.25inch one.
It was the SD-Sales Versafloppy (one).


Greetings, Holger

[*] the _used_ 8-inch drive was ~ 500$ and took most of my 'free luggage'
on the flight home from LA to HAM.
dott.Piergiorgio
2011-04-01 11:39:12 UTC
Permalink
Post by Holger Petersen
Post by dott.Piergiorgio
and I can suggest, as a good starting objective, a "CP/M ultralite",
that is, can run in a 16k TPA ?
CP/M 1.4 was supposed to do that. And, AFAIK, I did habe 8 KByte RAM
back in 1980 [*]...
From what I have figured, 1.4 was indeed supposed, in the sense that
runs in 16K, but the TPA was too small to be practical, and CP/M 1.3 was
the only CP/M whose the TPA was practical (considered the avg. size of
the transient programs of the age)

What I mean, is that I estimate that a Z80 rewrote of 1.x CP/M ought to
give an larger TPA
Post by Holger Petersen
Post by dott.Piergiorgio
a total of 78 and 3/4 Kbytes (80,640 bytes) and someone has tried to
cram into it CP/M 1.4 or 1.3 ?
And my Version of CP/M came on an 8 inch Disk as well as en 5.25inch one.
It was the SD-Sales Versafloppy (one).
I guess you refer to the model I, whose indeed use the SA-400, but you
remember having an heavy and bulky 8" drive, whose with SSSD IBM format
gives ~256k, enough for the practical use of late 70s/early software &
systems

one of my fun in hacking is putting constraints in objectives (like the
various 4k/8k/16k demo comps during the euro demoparties)

The smallest CP (not M) I found is the Tarbell cassette program at the
end of the manual of the cassette controller board, whose in 256 bytes
gives the core of a control program, loading, saving and executing. with
8080 instructions. The smallest monitor I glanced is 1K, but uses Z80
instruction (or at least, uses Z80 mnemonics..)

What I'm thinking and reasoning, is how useful can be a system with a
single or pair of first-generation SSSD 5¼ drive between 75 and 100k
formatted and a TPA of 16 or 32 KBytes ?

After reading that byte magazine archive of pdfs, I concluded that, in
Mr. Schorn's altz80 docs, the part about the default simulation being of
a "fairly loaded" 1977 Altair, is somewhat to be amended because seems
that in 1977 timeframe the default SIMH setting is definitively a "high
end" configuration.

if something is murky in my reply, please correct me and if needed,
please ask for clarification, I'm on the receiving end of a near-costant
stream of NMI from my father....

Best regards from Italy,
dott. Piergiorgio.
Holger Petersen
2011-04-01 13:02:24 UTC
Permalink
Post by dott.Piergiorgio
Post by Holger Petersen
And my Version of CP/M came on an 8 inch Disk as well as en 5.25inch one.
It was the SD-Sales Versafloppy (one).
^^^
Post by dott.Piergiorgio
I guess you refer to the model I, whose indeed use the SA-400, but you
^^^
Yes.
Post by dott.Piergiorgio
remember having an heavy and bulky 8" drive, whose with SSSD IBM format
gives ~256k, enough for the practical use of late 70s/early software &
systems
One could attach _either_ an 8 inch -or_ a 5.25" Drive onto the
Versafloppy-I; but not at the same time[*].

And both sort of disks were delivered with it. It might have been, that
some (unimportant :-) Data was missing on the 5.25 disk (perhaps E-Basic).

Nice weekend, Holger

[*] Not only that one ought to move one jumper, but the cables could not
be attached at the same time.
EX DE,HL
2011-03-29 21:54:15 UTC
Permalink
Post by Ruud
Hallo allemaal,
Trying to create my own CP/M system and doing the needed research, I
more and more get the feeling that whenever it comes to creating the
needed system disk, the user first must have a working system to be
able to do so. Why? Because he needs files like BNKBDOS3.SPR and
RESBDOS.SPR. And then it needs GENCPM to create CPM3.SYS.
Do you intend to create a new CP/M or an open source standard version?
It seems to me that if you create a new open source CP/M it would have to be
based around some standard disk system.
When CP/M was first conceived its purpose was to enable people to use the
new 'mini' 8 inch disk drives.

It is so much a part of the disk system that all of the various sections or
modules would have to take account of this.
I really love CP/M but who wants to use an 8 inch disk drive? (yes I do have
one and have used it)
But if another storage medium were chosen this probably would not suit
everyone. If the 'standard' 128-byte blocks are used for transfer of data
then the same deblocking arrangement would have to be used.

I have recently written some utility programs to use a micro-drive with CP/M
2.2 if you would like to look at them they are here.
http://www.interak.pwp.blueyonder.co.uk/micro_drive.htm

Alan
Jason King
2011-03-30 00:52:14 UTC
Permalink
This may sound like heresy, but if we're to do this, maybe we should do
cp/m 86. Lots of well-developed VMs (including free ones) and we can
use some existing toolchains (nasm, watcom or digital mars c etc) to
bootstrap a system.
Roger Ivie
2011-03-30 02:27:05 UTC
Permalink
Post by Jason King
This may sound like heresy, but if we're to do this, maybe we should do
cp/m 86. Lots of well-developed VMs (including free ones) and we can
use some existing toolchains (nasm, watcom or digital mars c etc) to
bootstrap a system.
Or you could use CP/M-68K. It's written in C and only needs a few tweaks
to go through gcc. I have an ARM version running on a Hawkboard. Not
talking to actual disk yet (just a RAMdisk image downloaded over
Ethernet).

Utilities are in PL/M though; I had to take ED, PIP, and STAT from
CP/M-Z8000.
--
roger ivie
***@ridgenet.net
Ruud
2011-03-30 11:36:24 UTC
Permalink
Hallo Jason,
Post by Jason King
This may sound like heresy, but if we're to do this, maybe we
should do cp/m 86.
CP/M-86 has one major flaw, please correct me if I'm wrong: it doesn't
run on a Z80 :)


Groetjes, Ruud Baltissen
www.Baltissen.org
Ruud
2011-03-30 11:33:46 UTC
Permalink
Hallo EX DE,HL ,
Post by EX DE,HL
Do you intend to create a new CP/M or an open source standard version?
An open source standard version.
Post by EX DE,HL
It seems to me that if you create a new open source CP/M it would have to be
based around some standard disk system.
To be honest: so far I only have been a user. I know I cannot put the
floppies of my Bondwell in my C128 and vica versa. I also know you
have 128 bytes sectors, 256 bytes sectors etc. but how you tell that
CP/M, I have no idea yet. So it is something I have to learn yet.
Post by EX DE,HL
http://www.interak.pwp.blueyonder.co.uk/micro_drive.htm
Very interesting!


Groetjes, Ruud Baltissen
www.Baltissen.org
Rolf Harrmann
2011-03-30 21:05:37 UTC
Permalink
Hello Ruud,
Post by Ruud
To be honest: so far I only have been a user. I know I cannot put the
floppies of my Bondwell in my C128 and vica versa. I also know you
have 128 bytes sectors, 256 bytes sectors etc. but how you tell that
CP/M, I have no idea yet. So it is something I have to learn yet.
the C128 can read and write Bondwell Floppies.

Look this link.

http://www.gaby.de/jugglinf.htm

(page is in German only)

Rolf
Gene Buckle
2011-03-31 15:11:32 UTC
Permalink
To: Rolf Harrmann
From Newsgroup: comp.os.cpm
Hello Ruud,
Post by Ruud
To be honest: so far I only have been a user. I know I cannot put the
floppies of my Bondwell in my C128 and vica versa. I also know you
have 128 bytes sectors, 256 bytes sectors etc. but how you tell that
CP/M, I have no idea yet. So it is something I have to learn yet.
the C128 can read and write Bondwell Floppies.
Look this link.
http://www.gaby.de/jugglinf.htm
There's a caveat to that - if your 1571 has a JiffyDOS ROM installed in it,
it won't be able to read MFM formatted disk because the JD code takes up the
space that the MFM code formerly occupied.

g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!

Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.
--- Synchronet 3.15a-Win32 NewsLink 1.91
The Retro Archive - telnet://bbs.retroarchive.org
Ruud
2011-03-31 18:08:05 UTC
Permalink
Hallo Rolf,
Post by Rolf Harrmann
the C128 can read and write Bondwell Floppies.
Yep, I completely forgot about the fact that the 1571 can handle MFM
floppies as well. It was one of the ways I exchanged data with my PC
but I used until 1990. After that I used a special cable: Userport <->
LPT.
But I needed a quick (and as it now seems, abit wrong) example to
support my statement.


Groetjes, Ruud Baltissen
www.Baltissen.org
PC Pete
2011-03-30 22:55:29 UTC
Permalink
It seems there is at least *some* interest in a modern respin of CP/M 2.x or 3.0...

Ruud is right, there's plenty of expertise here to put together a team to investigate and rebuild an open source release of CP/M on the Z80.

The questions then are :
1) who would like to participate?
2) who has time to participate in such a project?, and finally
3) who has the necessary skills (AND time, AND interest) to participate?

There are other questions, like hosting, forum software, use of a versioning (or at least a checkout/checkin) system, and so on that will need to be discussed.

For my part, I will gladly offer one of my domains for initial use in this project, and manage access and so on, if that would help. I have a couple of very quiet domains
that can be configured with good-quality forum software (PHPBB is already running on one domain), and while disk space may eventually become a limiting factor, I'm quite
willing to provide additional space if needed via some other mechanisms. The only catch is, initially it won't be called CP/M 4 or CP/M OS or whatever.com, but that can
be fairly easily changed at some later date via an alias or migration. Nothing is impossible!

The obvious alternative is Sourceforge or FreshMeat or something similar; I'm personally a bit "nervous" about such places for a number of administrative and political
reasons, and a lot of new projects do go there to die! My main concern though, is communication - the "forum" software on SF is a joke. So it would become a decision
based on access to all users vs the ability to use CVS or something similar to manage the project.

Having said ALL THAT (!), CVS or similar is NOT a prerequisite for such a project, at least IMHO.

So I guess the next step is to find a way to continue from here without hijacking the comp.os.cpm newsgroup! Then we can start to consider gathering existing
documentation, figuring out which Z80 target(s) to support, consider backwards-compatibility issues (like the deblocking thing, which is such a boatanchor), hardware
configuration support, graphics vs text-only, minimum/maximum memory size support, and possibly later on porting to other architectures. If the basic OS is written from
the ground up with proven value long-term industry-standard tools (Assembler -which one(s)?, C or C++, ANSI or not, etc), then porting should become a much more
manageable issue. With some clever thought in the modularity department (see, TurboDOS does have something to offer!), it should be possible to make this as flexible as
we wish.

I hope this small token is a starter for other folks.

Comments, suggestions, ideas, flames?
James Moxham (Dr_Acula)
2011-03-31 08:29:48 UTC
Permalink
I'm in too!

Re
Post by EX DE,HL
Do you intend to create a new CP/M or an open source standard version?
It seems to me that if you create a new open source CP/M it would have to be
based around some standard disk system.
When CP/M was first conceived its purpose was to enable people to use the
new 'mini' 8 inch disk drives.
Last year we had a number of people (I think more than 10) working on
the Propeller CP/M emulation. We went through a number of disk drive
formats, and in the end we settled on the Altair SIMH hard drive
format. Advantages:
1) Big enough for lots of files
2) Simpler and neater software than the floppy format
3) Able to easily copy multiple files from the SIMH to an SD card and
hence into CP/M
4) Smaller code space

We were using an SD card as the physical storage media, but anything
would work. We could have used flash ram or even eeprom.

Re
Post by EX DE,HL
consider backwards-compatibility issues (like the deblocking thing, which is such a boatanchor), >hardware
configuration support, graphics vs text-only, minimum/maximum memory size support, and possibly >later on porting to other architectures. If the basic OS is written from
the ground up with proven value long-term industry-standard tools (Assembler -which one(s)?, C or >C++, ANSI or not, etc), then porting should become a much more
manageable issue. With some clever thought in the modularity department (see, TurboDOS does have >something to offer!), it should be possible to make this as flexible as
we wish.
All very good questions. I suspect you have to go text only , but
maybe with VT100 command support? Max/Min memory - that is tricky. The
temptation will always be to add more and more. 10k max?? I suspect
that means the source has to be assembly. My personal preference is
Z80 mnemonics but only ever use 8080 op codes, so really it is 8080.

I very much like the modular approach. The N8VEM group may have some
things to offer here, eg a little bit of code you can drop in that
talks to a standard keyboard via an 8255.
Floppy Software
2011-03-31 12:25:39 UTC
Permalink
Post by James Moxham (Dr_Acula)
I suspect you have to go text only , but
maybe with VT100 command support?
I think it's needed some kind of standard terminal emulation in CP/M.

It would be more easy to build some programs (now, each program
need to write its own routines for all screen types it want to
support).
Floppy Software
2011-03-31 12:21:57 UTC
Permalink
Post by PC Pete
It seems there is at least *some* interest in a modern respin of CP/M 2.x or 3.0...
I am interested.

I think modularity is a great choice.

But... I don't know if we can do that with the source in the
Unofficial CP/M Website
due to license, and writting an Open CP/M from scratch... it's not CP/
M.

Anyway, I prefer C languaje instead of CP/M for the utilities.
Ruud
2011-03-31 19:56:01 UTC
Permalink
Hallo Floppy Software,
and writting an Open CP/M from scratch... it's not CP/M
If it walks like a duck, quacks like a duck and looks like a duck,
then IMHO it is a duck. A self written CP/M that does exact the same
job is CP/M as well in my point of view.


Groetjes, Ruud Baltissen
www.Baltissen.org
David Griffith
2011-03-31 23:14:17 UTC
Permalink
Post by Ruud
Hallo Floppy Software,
and writting an Open CP/M from scratch... it's not CP/M
If it walks like a duck, quacks like a duck and looks like a duck,
then IMHO it is a duck. A self written CP/M that does exact the same
job is CP/M as well in my point of view.
I'm wondering just how this differs from ZSDOS.
--
David Griffith
***@acm.org <--- Put my last name where it belongs
Ruud
2011-04-01 10:34:34 UTC
Permalink
Hallo David,
Post by David Griffith
I'm wondering just how this differs from ZSDOS.
Because I hadn't heard of it before. So thanks for the link.
Searching for ZSDOS I ran into other links so I lots to
investigate....


Groetjes, Ruud Baltissen
www.Baltissen.org
Nathanael
2011-04-01 14:53:06 UTC
Permalink
Post by David Griffith
Post by Ruud
Hallo Floppy Software,
and writting an Open CP/M from scratch... it's not CP/M
If it walks like a duck, quacks like a duck and looks like a duck,
then IMHO it is a duck. A self written CP/M that does exact the same
job is CP/M as well in my point of view.
I'm wondering just how this differs from ZSDOS.
[Coming out of lurk mode.]

Thanks for asking that. I was wondering myself. ZS/ZDDOS, ZCPR, Z-
System, ZPM -- wasn't all this done years ago? ZCPR3 is public domain,
and both ZSDOS and Z-System are now GPL'ed.

Doesn't sound like anyone (yet) has a clear idea of what the goals of
such a project would be. How would it differ from the above? Is it to
be backward- or forward-looking? If FreeCP/M is going to remain welded
to the 808x/Z80 platform, modern enhancements are out of the question.
If the intent is to write a modern CP/M, shouldn't there first be some
sort of discussion as to just what "CP/M" is?

And just to prove definitively that I have no understanding of the
topic... couldn't something akin to a modern IFS be implemented to
support most disk formats on-the-fly? I know Montezuma Micro CP/M on
my old Trash-80 could read and write literally dozens of different
formats.

As to hosting, I have unlimited space available, if anyone's
interested.

--Nathanael Culver
Post by David Griffith
--
David Griffith
pbetti
2011-04-01 16:09:29 UTC
Permalink
Post by Nathanael
Post by David Griffith
Post by Ruud
Hallo Floppy Software,
and writting an Open CP/M from scratch... it's not CP/M
If it walks like a duck, quacks like a duck and looks like a duck,
then IMHO it is a duck. A self written CP/M that does exact the same
job is CP/M as well in my point of view.
I'm wondering just how this differs from ZSDOS.
[Coming out of lurk mode.]
Thanks for asking that. I was wondering myself. ZS/ZDDOS, ZCPR, Z-
System, ZPM -- wasn't all this done years ago? ZCPR3 is public domain,
and both ZSDOS and Z-System are now GPL'ed.
Doesn't sound like anyone (yet) has a clear idea of what the goals of
such a project would be. How would it differ from the above? Is it to
be backward- or forward-looking? If FreeCP/M is going to remain welded
to the 808x/Z80 platform, modern enhancements are out of the question.
If the intent is to write a modern CP/M, shouldn't there first be some
sort of discussion as to just what "CP/M" is?
And just to prove definitively that I have no understanding of the
topic... couldn't something akin to a modern IFS be implemented to
support most disk formats on-the-fly? I know Montezuma Micro CP/M on
my old Trash-80 could read and write literally dozens of different
formats.
As to hosting, I have unlimited space available, if anyone's
interested.
--Nathanael Culver
Post by David Griffith
--
David Griffith
A simple rewrite in high level language is itself something totally
new.
The same can be said for differents filesystems (filesystems *not*
disk format)

Piergiorgio
PC Pete
2011-04-01 20:54:55 UTC
Permalink
Post by David Griffith
I'm wondering just how this differs from ZSDOS.
G'day David! Good question.

From my (most humble) perspective, ZSDOS and so on showed what could be done to the user interface/CCP without necessarily causing havoc to the underlying OS.

I know there were BIOS/BDOS/CCP replacements everywhere for a good while, many of which weren't much short of magic at the time.

But from my point of view, these all took off long after CP/M had been superseded by the various command-line replacements (DOS, etc). I know at the start of the 90s, I
had no access to any of those programs, despite working in a pretty flexible CP/M (for customer backwards compatibility and support) and Unix shop. So it seems that these
all did their best as emulator interfaces rather than as serious contenders for market share. (Again, my own opinion, and I know NZCPM and so on sold many thousands of
licences, etc).

These command-line-extension type of software never really took into account OS modularity, or at least not in the way we think of it these days. They certainly didn't
offer the level of integration that I would expect from a project like this - expansion and refinement of the BDOS and BIOS, first and foremost.

And finally, these were all products of their times: poorly-integrated "aliases" for drives and user areas, console-dependent editing, awkward invocation and
de-invocation to mention some of the things that seemed like a good idea at the time!

There are a lot (!) of questions to be resolved before this goes any further, so I hope your comment gives some other folks ideas about what (and what not) to look for in
a CCP replacement.

And yes, I know I'm radically oversimplifying much of this, I don't have the space (nor other people the bandwidth) here to discuss all the good and less good points of
all the competing products!

Great comment though - it sure made me think about some of the goals of the project in a new light!
-Pete
Floppy Software
2011-04-01 12:29:14 UTC
Permalink
Post by Ruud
Hallo Floppy Software,
and writting an Open CP/M from scratch... it's not CP/M
If it walks like a duck, quacks like a duck and looks like a duck,
then IMHO it is a duck. A self written CP/M that does exact the same
job is CP/M as well in my point of view.
No. It will be another thing, but not CP/M. It won't a CP/M
descendant.

We have BDOS replacements that aren't CP/M but its behaviour is
more or less the same (that's why they are known as replacements).

And I suspect that this is the reason because well known veterans in
this forum don't reply to this post: We are not talking about
"authentic"
and "real" with "pedigree" CP/M.
Ruud
2011-04-01 17:45:01 UTC
Permalink
Hallo Floppy Software,
Post by Floppy Software
Post by Ruud
If it walks like a duck, quacks like a duck and looks like a duck,
then IMHO it is a duck.
No. It will be another thing, but not CP/M. It won't a CP/M
descendant.
It looks like an IBM-PC, its screen shows the same output on the
screen and it works like a IBM-PC (and often more faster!). And they
were called IBM-compatibles.

So what I want to make is a "CP/M-compatible". And, if possible, I
want to call it FreeCP/M.
Post by Floppy Software
We have BDOS replacements that aren't CP/M but its behaviour is
more or less the same (that's why they are known as replacements).
Names, sources?

Forgive my lack of knowledge but due to lack of time I couldn't spend
that much time on CP/M as I wanted. Now I can but have to learn a lot.
Post by Floppy Software
And I suspect that this is the reason because well known veterans in
this forum don't reply to this post: We are not talking about
"authentic" and "real" with "pedigree" CP/M.
I have seen threads that were much shorter than this one is :)


Groetjes, Ruud Baltissen
www.Baltissen.org
Ruud
2011-03-31 19:47:11 UTC
Permalink
Hallo PCPete,
Post by PC Pete
Comments, suggestions, ideas, flames?
For the moment I'm only interested in those files (CPMLDR, BDOS/BIOS =
FDOS and/or whatever more is needed) which enable anyone to run the
standard CP/M 3 applications on their system.

Which disk systems should be supported? I haven't any idea, see my
previous message. But IMHO it should be possible by using macros to
choose the right disk(s) and then it is just a matter of assembling
and you have your boot files.
The right disk is not present? Experts among us should be able to tell
someone how define the correct parameters.

These files should be as small as possible IMHO (any reason why not?)
and therefore should be written in ASM. Which one? Z80 of course. Or
did you mean style? In that case the majority may decide; I just
adjust my own assembler :)


Next goal: CCP3.COM and all other system files. To be written in ????
I know CCP can be kicked out of the memory if needed. So being small
isn't a direct must so the extra size due to using a higher language
can be acceptable?

Which higher language? I myself prefer Pascal but I would go for C.
But with this condition: the compiler must become available as source
as well!

About hosting: how much space would be needed? And if it is too much
for one person, it could be shared: documentation here, tools there,
boot files over there, etc. etc.

Communication: does anyone know how to set up a forum? Or know one we
can use?

My comments and ideas so far....


Groetjes, Ruud Baltissen
www.Baltissen.org
Kenneth Scharf
2011-04-01 02:13:24 UTC
Permalink
Post by Ruud
Hallo PCPete,
Post by PC Pete
Comments, suggestions, ideas, flames?
For the moment I'm only interested in those files (CPMLDR, BDOS/BIOS =
FDOS and/or whatever more is needed) which enable anyone to run the
standard CP/M 3 applications on their system.
Which disk systems should be supported? I haven't any idea, see my
previous message. But IMHO it should be possible by using macros to
choose the right disk(s) and then it is just a matter of assembling
and you have your boot files.
The right disk is not present? Experts among us should be able to tell
someone how define the correct parameters.
These files should be as small as possible IMHO (any reason why not?)
and therefore should be written in ASM. Which one? Z80 of course. Or
did you mean style? In that case the majority may decide; I just
adjust my own assembler :)
Next goal: CCP3.COM and all other system files. To be written in ????
I know CCP can be kicked out of the memory if needed. So being small
isn't a direct must so the extra size due to using a higher language
can be acceptable?
Which higher language? I myself prefer Pascal but I would go for C.
But with this condition: the compiler must become available as source
as well!
About hosting: how much space would be needed? And if it is too much
for one person, it could be shared: documentation here, tools there,
boot files over there, etc. etc.
Communication: does anyone know how to set up a forum? Or know one we
can use?
My comments and ideas so far....
Groetjes, Ruud Baltissen
www.Baltissen.org
An open source C (and other language) complier already exists. And it
can compile itself so you can port it to other systems. The code
generator portion must be re-written for the new target but this has
been done many times already. Of course I'm talking about GCC, the Gnu
Complier Collection. Use the source Luke!
Ruud
2011-04-01 10:44:35 UTC
Permalink
Hallo Kenneth,
.... Of course I'm talking about GCC, the Gnu Complier Collection.
The idea is good but I have one doubt: what will be the size of the
COM file? Looking at my Free Pascal commandline compiler of 31 KB this
could be a very good idea, many thanks!


Groetjes, Ruud Baltissen
www.Baltissen.org
Floppy Software
2011-04-01 12:37:10 UTC
Permalink
Post by Ruud
Hallo PCPete,
Post by PC Pete
Comments, suggestions, ideas, flames?
For the moment I'm only interested in those files (CPMLDR, BDOS/BIOS =
FDOS and/or whatever more is needed) which enable anyone to run the
standard CP/M 3 applications on their system.
Which disk systems should be supported? I haven't any idea, see my
previous message. But IMHO it should be possible by using macros to
choose the right disk(s) and then it is just a matter of assembling
and you have your boot files.
The right disk is not present? Experts among us should be able to tell
someone how define the correct parameters.
These files should be as small as possible IMHO (any reason why not?)
and therefore should be written in ASM. Which one? Z80 of course. Or
did you mean style? In that case the majority may decide; I just
adjust my own assembler :)
Next goal: CCP3.COM and all other system files. To be written in ????
I know CCP can be kicked out of the memory if needed. So being small
isn't a direct must so the extra size due to using a higher language
can be acceptable?
Which higher language? I myself prefer Pascal but I would go for C.
But with this condition: the compiler must become available as source
as well!
About hosting: how much space would be needed? And if it is too much
for one person, it could be shared: documentation here, tools there,
boot files over there, etc. etc.
Communication: does anyone know how to set up a forum? Or know one we
can use?
My comments and ideas so far....
Groetjes, Ruud Baltissen
www.Baltissen.org
An open source C (and other language) complier already exists.  And it
can compile itself so you can port it to other systems.  The code
generator portion must be re-written for the new target but this has
been done many times already.  Of course I'm talking about GCC, the Gnu
Complier Collection.  
But Z80 open source C compilers are not so good... pity.
Floppy Software
2011-04-01 12:35:50 UTC
Permalink
Post by Ruud
Which higher language? I myself prefer Pascal but I would go for C.
But with this condition: the compiler must become available as source
as well!
I agree with you.

That's why I write my programs in MESCC (my own "near C" compiler
derived from Small C).

It's not standard C because it lacks some things, but I have
total control about compiler sources and I can clean bugs, and
add enhancements.

And it's optimized for size, not for speed, very important for 64K
TPA.
Ruud
2011-04-01 17:58:43 UTC
Permalink
Hallo Floppy Software,
Post by Floppy Software
It's not standard C because it lacks some things, but I have
total control about compiler sources and I can clean bugs, and
add enhancements.
And it's optimized for size, not for speed, very important for 64K
TPA.
It's a starter. But most important, are the sources free?

I wrote a Pascal compiler that can compile itself. And it only outputs
macros. Just tell my assembler for which CPU/computer the program is
meant and the result will be a binary. The only problem: creating the
macro definitions is a hell of a job :(


Groetjes, Ruud Baltissen
www.Baltissen.org
Bill Gunshannon
2011-04-01 18:16:24 UTC
Permalink
Post by Ruud
Hallo Floppy Software,
Post by Floppy Software
It's not standard C because it lacks some things, but I have
total control about compiler sources and I can clean bugs, and
add enhancements.
And it's optimized for size, not for speed, very important for 64K
TPA.
It's a starter. But most important, are the sources free?
I wrote a Pascal compiler that can compile itself. And it only outputs
macros. Just tell my assembler for which CPU/computer the program is
meant and the result will be a binary. The only problem: creating the
macro definitions is a hell of a job :(
As someone who has always been interested in compilers and in particular
Pascal, I have to ask.

Is it available? What CPU's do you have Macro's for? Want more? :-)

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Ruud
2011-04-01 20:58:10 UTC
Permalink
Hallo Bill,
Post by Bill Gunshannon
Is it available?
Yes, freeware. Just email me. Look at my site for the address.
Post by Bill Gunshannon
 What CPU's do you have Macro's for?
Only 6502 and the macros I have are meant for the C64.
Post by Bill Gunshannon
 Want more?  :-)
Always! (What else? :)


Groetjes, Ruud Baltissen
www.Baltissen.org
Floppy Software
2011-04-04 13:11:40 UTC
Permalink
Post by Ruud
Hallo Floppy Software,
Post by Floppy Software
It's not standard C because it lacks some things, but I have
total control about compiler sources and I can clean bugs, and
add enhancements.
And it's optimized for size, not for speed, very important for 64K
TPA.
It's a starter. But most important, are the sources free?
GPL:

http://floppysoftware.vacau.com/mescc.html
William
2011-04-01 11:43:00 UTC
Permalink
Post by PC Pete
It seems there is at least *some* interest in a modern respin of CP/M 2.x or 3.0...
Ruud is right, there's plenty of expertise here to put together a team to investigate and rebuild an open source release of CP/M on the Z80.
1) who would like to participate?
2) who has time to participate in such a project?, and finally
3) who has the necessary skills (AND time, AND interest) to participate?
There are other questions, like hosting, forum software, use of a versioning (or at least a checkout/checkin) system, and so on that will need to be discussed.
For my part, I will gladly offer one of my domains for initial use in this project, and manage access and so on, if that would help. I have a couple of very quiet domains
that can be configured with good-quality forum software (PHPBB is already running on one domain), and while disk space may eventually become a limiting factor, I'm quite
willing to provide additional space if needed via some other mechanisms. The only catch is, initially it won't be called CP/M 4 or CP/M OS or whatever.com, but that can
be fairly easily changed at some later date via an alias or migration. Nothing is impossible!
The obvious alternative is Sourceforge or FreshMeat or something similar; I'm personally a bit "nervous" about such places for a number of administrative and political
reasons, and a lot of new projects do go there to die! My main concern though, is communication - the "forum" software on SF is a joke. So it would become a decision
based on access to all users vs the ability to use CVS or something similar to manage the project.
Having said ALL THAT (!), CVS or similar is NOT a prerequisite for such a project, at least IMHO.
So I guess the next step is to find a way to continue from here without hijacking the comp.os.cpm newsgroup! Then we can start to consider gathering existing
documentation, figuring out which Z80 target(s) to support, consider backwards-compatibility issues (like the deblocking thing, which is such a boatanchor), hardware
configuration support, graphics vs text-only, minimum/maximum memory size support, and possibly later on porting to other architectures. If the basic OS is written from
the ground up with proven value long-term industry-standard tools (Assembler -which one(s)?, C or C++, ANSI or not, etc), then porting should become a much more
manageable issue. With some clever thought in the modularity department (see, TurboDOS does have something to offer!), it should be possible to make this as flexible as
we wish.
I hope this small token is a starter for other folks.
Comments, suggestions, ideas, flames?
Hello Pete

When I had some free time between contracts I tried to write a
portable version of CP/M written in C and compiled with SDCC (a Z80 C
compiler). I was very careful not to use local variables which the
the Z*0 cannot address efficiently so the result was actually about
the same size as hand written assembler - 4 K or so. The DRI C source
code compiles very inefficiently onto an 8 bit processor and should be
avoided IMHO.

I couldn't resist some improvements to the API.

Open, rename and set attributes may take ambiguous filenames!
If preceded by Open, Search Next will open the next file in the
user FCB
but any other intervening FCB I/O prevents this.
N.B. This would be illegal under CP/M
REN *.DOC *.TXT is legal

Conditional compilation was used to optionally configure the system
for combinations of CP/M 1.4, 2.2 or CDOS compatibility.

Alas the project was never finished but it could be resurrected.

Bill
pbetti
2011-04-01 12:10:32 UTC
Permalink
Post by William
Post by PC Pete
It seems there is at least *some* interest in a modern respin of CP/M 2.x or 3.0...
Ruud is right, there's plenty of expertise here to put together a team to investigate and rebuild an open source release of CP/M on the Z80.
1) who would like to participate?
2) who has time to participate in such a project?, and finally
3) who has the necessary skills (AND time, AND interest) to participate?
There are other questions, like hosting, forum software, use of a versioning (or at least a checkout/checkin) system, and so on that will need to be discussed.
For my part, I will gladly offer one of my domains for initial use in this project, and manage access and so on, if that would help. I have a couple of very quiet domains
that can be configured with good-quality forum software (PHPBB is already running on one domain), and while disk space may eventually become a limiting factor, I'm quite
willing to provide additional space if needed via some other mechanisms. The only catch is, initially it won't be called CP/M 4 or CP/M OS or whatever.com, but that can
be fairly easily changed at some later date via an alias or migration. Nothing is impossible!
The obvious alternative is Sourceforge or FreshMeat or something similar; I'm personally a bit "nervous" about such places for a number of administrative and political
reasons, and a lot of new projects do go there to die! My main concern though, is communication - the "forum" software on SF is a joke. So it would become a decision
based on access to all users vs the ability to use CVS or something similar to manage the project.
Having said ALL THAT (!), CVS or similar is NOT a prerequisite for such a project, at least IMHO.
So I guess the next step is to find a way to continue from here without hijacking the comp.os.cpm newsgroup! Then we can start to consider gathering existing
documentation, figuring out which Z80 target(s) to support, consider backwards-compatibility issues (like the deblocking thing, which is such a boatanchor), hardware
configuration support, graphics vs text-only, minimum/maximum memory size support, and possibly later on porting to other architectures. If the basic OS is written from
the ground up with proven value long-term industry-standard tools (Assembler -which one(s)?, C or C++, ANSI or not, etc), then porting should become a much more
manageable issue. With some clever thought in the modularity department (see, TurboDOS does have something to offer!), it should be possible to make this as flexible as
we wish.
I hope this small token is a starter for other folks.
Comments, suggestions, ideas, flames?
Hello Pete
When I had some free time between contracts I tried to write a
portable version of CP/M written in C and compiled with SDCC (a Z80 C
compiler).  I was very careful not to use local variables which the
the Z*0 cannot address efficiently so the result was actually about
the same size as hand written assembler - 4 K or so. The DRI C source
code compiles very inefficiently onto an 8 bit processor and should be
avoided IMHO.
I couldn't resist some improvements to the API.
 Open, rename and set attributes may take ambiguous filenames!
   If preceded by Open, Search Next will open the next file in the
user FCB
   but any other intervening FCB I/O prevents this.
   N.B. This would be illegal under CP/M
   REN *.DOC *.TXT is legal
Conditional compilation was used to optionally configure the system
for combinations of CP/M 1.4, 2.2 or CDOS compatibility.
Alas the project was never finished but it could be resurrected.
Bill
It would be certainly a good starting point.
The availability of re-implementation of CP/M in high level language
(what's better then C?) would open up a world of new possibilities
other than portability of the code and easy of maintenance and
development.
My personal desiderata after an initial startup of the code would be:
Scalability (in terms of memory: from 64K systems to banked ones)
Support for hierarchical filesystem (Z80 FAT16 implementation already
exists for MSX systems, just for an example)

However if this CP/M 4 effort will start count on me for
development :-)

Piergiorgio Betti
Steve Nickolas
2011-04-01 14:48:03 UTC
Permalink
Post by pbetti
The availability of re-implementation of CP/M in high level language
(what's better then C?) would open up a world of new possibilities
other than portability of the code and easy of maintenance and
development.
Scalability (in terms of memory: from 64K systems to banked ones)
Support for hierarchical filesystem (Z80 FAT16 implementation already
exists for MSX systems, just for an example)
However if this CP/M 4 effort will start count on me for
development :-)
Piergiorgio Betti
The CP/M-86 4.1 api seems to support directories though only on FAT
filesystems?

-uso.
pbetti
2011-04-01 16:06:02 UTC
Permalink
Post by Steve Nickolas
Post by pbetti
The availability of re-implementation of CP/M in high level language
(what's better then C?) would open up a world of new possibilities
other than portability of the code and easy of maintenance and
development.
Scalability (in terms of memory: from 64K systems to banked ones)
Support for hierarchical filesystem (Z80 FAT16 implementation already
exists for MSX systems, just for an example)
However if this CP/M 4 effort will start count on me for
development :-)
Piergiorgio Betti
The CP/M-86 4.1 api seems to support directories though only on FAT
filesystems?
-uso.
Yes it does. However assuming a development in C there are a *lot* of
free implementation of the FAT filesystem.

Piergiorgio
PC Pete
2011-04-01 21:15:49 UTC
Permalink
I think Nathanael is right : The old-timers have seen this idea lots of times before, and they know it will start well, but as one and another person loses interest, the
project will very slowly suffocate, and there will be Yet Another CP/M Re-Hash Repository going nowhere fast - until in 2 years' time, someone starts up another thread...
But that's OK. If we don't try, we'll never do anything.

There are a lot of responses that I'd like to acknowledge individually (thanks everyone for the interest in Ruud's idea!), but that would take me a day or more! So here's
my quick summary (and remember, I'm often wrong):
- Bill has some high-level source code that sounds as though it would be a terrific basis for something great!
* Bill, would you be willing to provide (privately) part of your sources so we could get a "feel" for the size and complexity of such a project? I don't mean ALL the
sources, but perhaps a module would be enough. Thoughts?

- We have not even begun to scratch the surface of what features and/or limitations will be inherent in such an OS project. Multitasking? Embeddable? 16/32/64/128/more
KB?
* Perhaps an offline discussion would help to pool ideas for everyone to consider?

- Ruud, I already have a working forum that I can modify to our needs, using fantastic free, industry-standard forum software, and it's as easy as pie to install by
anyone else who's willing to host this stage of the project.

Nathanael has offered space, so would you be happy to get PHPBB installed and configured Nathanael? Or would you prefer to see how much/what is involved first? I'm open
to suggestions, but this isn't my baby, I've just got the loudest keyboard at the moment!

- David's question/comment about ZSDOS and the derivatives/family is a good one.
* I guess it would help to think about what we could achieve in the user interface, what would be most useful for users, etc (history lists, etc), and then figure out
where that lies - in the BIOS, in the CCP, etc - and where it could be used - only banked systems with more than 96k RAM, etc, etc.

There's also the burning question of how backwards-compatible the project can be. One of the reasons I suggested modularity was not necessarily in terms of BUILDING the
OS (Assembling, compiling, and linking modules) but more in terms of EXTENDING the OS, such as with an RSX-type demand-load mechanism. I don't want to recompile my whole
OS just because I have an old Kaypro disk I want to read! Maybe if I was going to move to an embedded version, with severe restrictions on memory, or to an "open-ended"
version, where memory can be flat-accessed, not just banked or paged, then a recompile/build/link/whatever would be a good method of ensuring the best results.

We will definitely need to move out of the old "what mnemonics will we use" paradigm (which I'm part of, I know) and into the "what building tools will give us the
greatest flexibility while still being industry-STANDARD?" mode of thinking! Of course, I'd *like* to stay away from the point where we need 6 tools to build the various
modules, an assembler, a relocatable linker, a C compiler, a C++ compiler, J# scripts, batch files, etc, etc, etc. That alone should be a lot of fun!

Despite the deafening silence, I would like to think that this is a good time to start thinking about all this - who knows if Zilog will be alive and kicking in 2016? And
leveraging from the fantastic success of the N8VEM projects means there is an astonishingly flexible and yet standardised hardware platform that CAN be built on, but it
isn't a pre-requisite. I would reasonably expect some version of the project could be got running on my Little Big Board, or on my SBC V2, or on Andrew Lynch's fantastic
Home Computer (Z8S180) without *too* much recompiling. Granularity vs. manageability is another subject we have to hash out!

So far, so good - this is one of the liveliest "non-flame-based" discussions I've read in a while. I hope the momentum keeps increasing.
-PCPete
Roger Ivie
2011-04-02 02:31:03 UTC
Permalink
Post by PC Pete
But that's OK. If we don't try, we'll never do anything.
Maybe, but you've ignored the most important part of starting a serious
open-source project: selecting a mascot!

(yes, that was unwarranted snark; I denounce myself)
--
roger ivie
***@ridgenet.net
Mr Emmanuel Roche, France
2011-04-02 06:49:40 UTC
Permalink
Post by Roger Ivie
Maybe, but you've ignored the most important part of starting
a serious open-source project: selecting a mascot!
Since "PC Pete" is Australian, I propose, of course: "Boomerang"...

(Another famous Australian word, "Kangaroo", spring to mind. But the
problem is its meaning. According to legend, Lieutenant Cook and
naturalist Sir Joseph Banks were exploring the area when they happened
upon the animal. They asked a nearby local what the creatures were
called. The local responded "Kangaroo", meaning "I don't understand
you", which Cook took to be the name of the creature...)

Yours Sincerely,
Mr. Emmanuel Roche, France
Ruud
2011-04-02 13:25:38 UTC
Permalink
Hallo allemaal,


I have no objection against "Kangaroo". Linux has Tux, FreeDOS its
whale, Free Pascal its Cheeta, Ubuntu uses a range of animals,
so.... :)


Groetjes, Ruud Baltissen
www.Baltissen
dott.Piergiorgio
2011-04-02 13:42:45 UTC
Permalink
Post by Ruud
I have no objection against "Kangaroo". Linux has Tux, FreeDOS its
whale, Free Pascal its Cheeta, Ubuntu uses a range of animals,
so.... :)
why not "Dingo" ?

dingos are of the family of Canis, and this is also an self-ironic
reference to CP/M being a more or less forgotten OS (that is, an
underDOG ;) )

Best regards from Italy,
dott. Piergiorgio.

P.s. well, Italian Navalists perhaps can strongly disagree, because a
major incident in Naval historiography, but heck, I'm *actually* an
Italian scholar of Naval History....)
Mr Emmanuel Roche, France
2011-04-02 15:42:23 UTC
Permalink
Post by dott.Piergiorgio
why not "Dingo" ?
dingos are of the family of Canis, and this is also an
self-ironic reference to CP/M being a more or less
forgotten OS (that is, an underDOG ;) )
Hum... I see 2 objections:

1) As far as I know, dingos means wild dogs in the USA...

2) "Dingo" means "crazy" in French...

Another animal, the Kiwi, is, unfortunately, the symbol of New
Zealand:

http://en.wikipedia.org/wiki/Kiwi

The only one remaining(?) is the Platypus, which is, indeed, quite
strange (as would be a version of CP/M as described so far...):

http://en.wikipedia.org/wiki/Platypus

It has the big advantage of being endemic in the area where lives "PC
Pete"...

Yours Sincerely,
Mr. Emmanuel Roche, France
Roger Ivie
2011-04-02 17:04:18 UTC
Permalink
Post by Mr Emmanuel Roche, France
1) As far as I know, dingos means wild dogs in the USA...
I do not believe I have ever heard the word dingo uttered by someone
that wasn't talking about something Australian. Last time I checked, I
was not only an American but also actually in the USA.
Post by Mr Emmanuel Roche, France
The only one remaining(?) is the Platypus, which is, indeed, quite
Already taken by Darwin.

http://en.wikipedia.org/wiki/Darwin_%28operating_system%29
--
roger ivie
***@ridgenet.net
Mr Emmanuel Roche, France
2011-04-02 18:23:24 UTC
Permalink
Hello, Roger!
Post by Roger Ivie
I do not believe I have ever heard the word dingo uttered by
someone that wasn't talking about something Australian.
Last time I checked, I was not only an American but also
actually in the USA.
Argh! I checked: you are right. There is even a Wikipedia entry for
dingo:

http://en.wikipedia.org/wiki/Dingo

I should have made a search before typing. By the way, the first
sentence says: "The Australian Dingo or Warrigal is a free-roaming
wild dog unique to the continent of Australia"...

Warrigal! Never heard about it before! I made a search: this one seems
little used...

They also have a "Dingo (disambiguation)" page, listing (among other
things):

- Dingo, French name of Goofy.

Yours Sincerely,
Mr. Emmanuel Roche, France
dott.Piergiorgio
2011-04-02 20:00:52 UTC
Permalink
Post by Mr Emmanuel Roche, France
Argh! I checked: you are right. There is even a Wikipedia entry for
http://en.wikipedia.org/wiki/Dingo
I should have made a search before typing. By the way, the first
sentence says: "The Australian Dingo or Warrigal is a free-roaming
wild dog unique to the continent of Australia"...
Warrigal! Never heard about it before! I made a search: this one seems
little used...
They also have a "Dingo (disambiguation)" page, listing (among other
Warrigal... I *Really* like it.

So, perhaps we can eventually settle on this ? :)

Best regards from Italy,
dott. Piergiorgio.
Ruud
2011-04-02 20:18:52 UTC
Permalink
Hallo allemaal,
Post by dott.Piergiorgio
Warrigal... I *Really* like it.
I don't mind. And who is going to draw it?


Groetjes, Ruud Baltissen
www.Baltissen
Nathanael
2011-04-02 20:45:32 UTC
Permalink
Post by Roger Ivie
Post by Mr Emmanuel Roche, France
1) As far as I know, dingos means wild dogs in the USA...
I do not believe I have ever heard the word dingo uttered by someone
that wasn't talking about something Australian. Last time I checked, I
was not only an American but also actually in the USA.
Post by Mr Emmanuel Roche, France
The only one remaining(?) is the Platypus, which is, indeed, quite
Already taken by Darwin.
http://en.wikipedia.org/wiki/Darwin_%28operating_system%29
--
roger ivie
There's also the kukaberra and the Tasmanian devil...
Jeff Jonas
2011-04-06 05:45:25 UTC
Permalink
Post by Roger Ivie
Post by Mr Emmanuel Roche, France
The only one remaining(?) is the Platypus
Already taken by Darwin.
before Tux, there was the Linux Platypus
Jim Higgins
2011-04-02 23:19:14 UTC
Permalink
On Sat, 2 Apr 2011 08:42:23 -0700 (PDT), "Mr Emmanuel Roche, France"
Post by Mr Emmanuel Roche, France
Post by dott.Piergiorgio
why not "Dingo" ?
dingos are of the family of Canis, and this is also an
self-ironic reference to CP/M being a more or less
forgotten OS (that is, an underDOG ;) )
1) As far as I know, dingos means wild dogs in the USA...
No, it's *NOT* a general term used for wild dogs in the USA. In the
USA a "dingo" is an an Australian animal. We call wild dogs "wild
dogs" or "feral dogs."
Post by Mr Emmanuel Roche, France
2) "Dingo" means "crazy" in French...
Well that settles it. The dingo is the perfect choice of mascot for
such a project.
PC Pete
2011-04-06 22:26:40 UTC
Permalink
Post by Mr Emmanuel Roche, France
(Another famous Australian word, "Kangaroo", spring to mind. But the
problem is its meaning. According to legend, Lieutenant Cook and
naturalist Sir Joseph Banks were exploring the area when they happened
upon the animal. They asked a nearby local what the creatures were
called. The local responded "Kangaroo", meaning "I don't understand
you", which Cook took to be the name of the creature...)
Ah, thank you Emmanuel, where would we be without some way of disseminating urban (or in this case, maybe 'antipodean' :) legends? As you are fond of saying, perhaps a
quick stop by the Wikipedia page would have prevented an error from spreading... who knows? ;)

In fact, the word 'kangaroo' was the local indigenous word (Gugu Yimithr tribe at the time, from primary school memory!) for these bouncy critters. There are around 230
different words in the various indigenous sublanguages for the same thing. Ditto for our 'antipodean rabbit', the Bilby (finally taking over from the Easter Bunny), and
there are another 75 words for 'dingo', 200 for 'kookaburra' (one is laughing about a kilometre from me as I write this!), and so on.

Personally, I think the Platypus (family: ornithorhyncidae) would be an almost perfect symbol for what I guess Free CP/M could be - it's a bit of a 'mongrel', with great
ideas from many sources, it's limited in range, it's hard to find, but it's worthwhile finding!

I do like many of the other suggestions made here, and as always, I'm truly amazed at just how much people know about my little island continent! Whether it's true or not
is irrelevant - sometimes the truth is far less glamorous than the hype... As we all painfully know!

So, a show of hands (here or on the forum) for the platypus?
Nathanael
2011-04-02 20:43:11 UTC
Permalink
Post by PC Pete
Nathanael has offered space, so would you be happy to get PHPBB installed and configured Nathanael?
I've thrown up a site with, at the moment, a front page and some user
forums. If it looks acceptable to everyone, I'll go ahead and populate
the forums and we can move the discussion over there. The temporary
URL is http://www.accardi-by-the-sea.org/freecpm/

--Nathanael
PC Pete
2011-04-03 00:07:26 UTC
Permalink
Post by Nathanael
I've thrown up a site with, at the moment, a front page and some user
forums. If it looks acceptable to everyone, I'll go ahead and populate
the forums and we can move the discussion over there. The temporary
URL is http://www.accardi-by-the-sea.org/freecpm/
Hi Nathaniel,

I've just spent some time adding a couple of posts to the suggestion box, but unfortunately they disappeared after I browsed away from the forum to my user profile.

Happily, they still appear in my user profile page, so all is not lost!

I have to say, I'm really pleased you got the forum available so quickly! But I'm very uncomfortable with Joomla as forum software. It has a huge number of technical
problems, not least of which is performance. Once posts start appearing, performance drops through the floor. If you want to see what I mean, the SoftDeko forum uses a
variation of Joomla, and it takes up to 1 minute just to log in. Forums appear backwards if you're logged in, normal if you're not, and you can't change that behaviour.

It's also extremely difficult to backup and secure, which is a concern long-term if this project is going to get off the ground (and stay off the ground! heheh)

I would prefer to use something a bit more robust, such as PHPBB, but if anyone else has ideas, now would be the time to chime in! (The reason I keep harping on about
PHPBB is because nothing else comes close in terms of speed, flexibility, usability, and security - and it's free! I've used it for years for my own and my customers'
forums, and it almost never breaks, it's easy as pie to administer, and it's fast fast fast!) But that's just MHO, I'm sure other folks have far more experience!

Don't be disheartened, that's an excellent first pass, and if we can iron out all the bugs (one of my posts detailed my problems logging in to the site, and those
problems haven't gone away) I'm sure it will be a good start.

If I can do *anything* to help, please let me know, you have my registered email address now! I'll be happy to help out as best I can.

Cheers,
Pete
Henk Siewert
2011-04-03 10:37:54 UTC
Permalink
Hallo,

Nice, but a lot of things are not working, yet.

Henk Siewert
Post by PC Pete
Nathanael has offered space, so would you be happy to get PHPBB installed
and configured Nathanael?
I've thrown up a site with, at the moment, a front page and some user
forums. If it looks acceptable to everyone, I'll go ahead and populate
the forums and we can move the discussion over there. The temporary
URL is http://www.accardi-by-the-sea.org/freecpm/

--Nathanael
lynchaj
2011-04-04 11:20:37 UTC
Permalink
On Apr 1, 5:15 pm, PC Pete <***@audiography.com.au> wrote:
[snip]
Post by PC Pete
leveraging from the fantastic success of the N8VEM projects means there is an astonishingly flexible and yet standardised hardware platform that CAN be built on, but it
isn't a pre-requisite. I would reasonably expect some version of the project could be got running on my Little Big Board, or on my SBC V2, or on Andrew Lynch's fantastic
Home Computer (Z8S180) without *too* much recompiling. Granularity vs. manageability is another subject we have to hash out!
So far, so good - this is one of the liveliest "non-flame-based" discussions I've read in a while. I hope the momentum keeps increasing.
-PCPete
Hi! Thanks Pete. We are working on the N8VEM home computer prototype
at the moment. It is in initial build and test and there are 5 boards
in various states of construction. At least some are partially
working but we are not close a final board yet. I am thinking
probably another round of prototype boards before we go final with
it. It would serve as a good platform for a FreeCP/M however it is a
bit early since the project is still mostly internal N8VEM work and
not really "announced" yet other than discussion on the mailing list
and here.

Thanks and have a nice day!

Andrew Lynch
PC Pete
2011-04-05 03:08:37 UTC
Permalink
On Mon, 4 Apr 2011 04:20:37 -0700 (PDT), lynchaj <***@yahoo.com> wrote:
It would serve as a good platform for a FreeCP/M however it is a
Post by lynchaj
bit early since the project is still mostly internal N8VEM work and
not really "announced" yet other than discussion on the mailing list
and here.
Andrew, I'm really sorry if I've let the cat out of the bag here. I didn't intend to announce anything, I just got a bit carried away with my examples...

FWIW, most of my thinking on this project has been done using the SBC V2 as the starting point. It offers excellent features and flexibility, and once I've got mine
running, the first thing I'm doing is cracking open my old Willem programmer and trying a few things out in terms of development code!

I guess the HC isn't as prime a target right now (compared with the SBC), not only because of the early stage of development, but also because it uses a number of really
interesting ideas that could stretch the software side of things as well. So I'd like a really solid core codeset before I think of porting! But if we can make use of the
HC features to define new areas of interest in the core code, that would be most serendipitous!

Again, I wasn't intending to give anything away here WRT the HC build. I'll check with you next time before I post about new designs, just in case...
Regards,
Pete
James Moxham (Dr_Acula)
2011-04-06 00:08:38 UTC
Permalink
This is a fascinating topic.

I have built a number of N8VEM boards and rewritten quite large parts
of the operating system, eg to include a keyboard driver that works at
the bit banging level.

The problem I came up against is that the more you put into CP/M, the
more memory you take at the top of ram. CP/M allows you to do this but
it starts taking memory away from other programs. Wordstar has less
working memory. Basic programs have less working memory. So you reach
a point where anything more than 16k is too much.

What I did next is to take the knowledge of CP/M on the N8VEM board
and combine it with the emulations being done at the time by the
Propeller group. The Propeller can run CP/M and it can also run banked
versions of CP/M like MP/M. But the main feature of the propeller is
that it gets around the CP/M memory problem by offloading code into
propeller assembly.

So instead of writing a keyboard driver in Z80 (which you can do on
the propeller), you write it in propeller assembly, and then Z80 talks
to this with OUT and IN instructions to various ports. There are 256
ports available, and some of the port numbers in the propeller
emulation are the same as in the N8VEM. This enables programs like
XMODEM to be ported from the N8VEM to the propeller without any
changes to the code.

The big advantage to this turns out to be the disk drive code. The
original N8VEM used a ROM disk which didn't need much code space.
However, the hard drive code used a lot more space. Code to use an SD
card uses more code space again to do the SPI bit banging.

To me, it makes sense to keep the CP/M code to the more abstract level
of 'open a file', 'write n bytes to record x' 'close file', and to
offload the more bios type code to somewhere else.

On the propeller that code can be in propeller assembly, but where
would you put such code on a Z80 board?

I have been pondering this and maybe this isn't the best answer, but
what I am thinking is a banking system where the user has software
control and has control at a fine level, eg in 2k blocks. If you have
the ability to switch banks in and out of high memory and you can do
this in 2k blocks, then you don't need to be jumping around with bios
calls in low memory (which in themselves need custom code).

If you have a CP/M system that has an absolute maximum size of 10k,
and you count down from the top of memory then it occupies 64k to 54k.
Then have some banks that you can switch in and out from 52k to 54k.

Those banks can come from anywhere. They could come from ROM or EPROM
or from a SRAM chip.

The idea would be that you send an OUT instruction to a particular
address and that switches in a bank. Then run that code (it might be
the low level SPI driver for an SD card). Then return to CP/M and
maybe switch in a bank to talk to the keyboard.

I think this means that the CP/M part can be largely unchanged, and
all the new code (ie for things that did not exist when CP/M was
written, like PC keyboards and SD cards) - these drivers can be
written as separate modules. In fact, this code does already exist,
and would just have to be recoded so it would work in a 2k (or 4k)
block of code.

I'd be hoping that this would mean you could run CP/M 2, MP/M and a
new operating system on the same hardware.

Thinking about hardware, what I think this means is you don't want a
system that, say, switches the entire 16k of top ram in and out as a
bank. You need smaller blocks and the ability to switch both the size
of the block and the location of the block and control over where that
block came from.

I already have something very similar to this working on the propeller
with MP/M. It would be cool though to port it to a real Z80,
especially as the propeller emulation only runs at a Z80 speed of
about 2Mhz and I have some 10Mhz Z80 chips I'd like to use.

Thoughts would be most appreciated!
s***@yahoo.com
2011-04-06 03:05:58 UTC
Permalink
On Apr 5, 7:08 pm, "James Moxham (Dr_Acula)"
Post by James Moxham (Dr_Acula)
This is a fascinating topic.
I have built a number of N8VEM boards and rewritten quite large parts
of the operating system, eg to include a keyboard driver that works at
the bit banging level.
The problem I came up against is that the more you put into CP/M, the
more memory you take at the top of ram. CP/M allows you to do this but
it starts taking memory away from other programs. Wordstar has less
working memory. Basic programs have less working memory. So you reach
a point where anything more than 16k is too much.
Exactly so, I especially liked cp/m+ RSX's to add features to the bdos
calls, but each one that was added reduced the top of TPA by its size,
like you say.
Post by James Moxham (Dr_Acula)
What I did next is to take the knowledge of CP/M on the N8VEM board
and combine it with the emulations being done at the time by the
Propeller group. The Propeller can run CP/M and it can also run banked
versions of CP/M like MP/M. But the main feature of the propeller is
that it gets around the CP/M memory problem by offloading code into
propeller assembly.
So instead of writing a keyboard driver in Z80 (which you can do on
the propeller), you write it in propeller assembly, and then Z80 talks
to this with OUT and IN instructions to various ports. There are 256
ports available, and some of the port numbers in the propeller
emulation are the same as in the N8VEM. This enables programs like
XMODEM to be ported from the N8VEM to the propeller without any
changes to the code.
The big advantage to this turns out to be the disk drive code. The
original N8VEM used a ROM disk which didn't need much code space.
However, the hard drive code used a lot more space. Code to use an SD
card uses more code space again to do the SPI bit banging.
To me, it makes sense to keep the CP/M code to the more abstract level
of 'open a file', 'write n bytes to record x' 'close file', and to
offload the more bios type code to somewhere else.
On the propeller that code can be in propeller assembly, but where
would you put such code on a Z80 board?
I have been pondering this and maybe this isn't the best answer, but
what I am thinking is a banking system where the user has software
control and has control at a fine level, eg in 2k blocks. If you have
the ability to switch banks in and out of high memory and you can do
this in 2k blocks, then you don't need to be jumping around with bios
calls in low memory (which in themselves need custom code).
If you have a CP/M system that has an absolute maximum size of 10k,
and you count down from the top of memory then it occupies 64k to 54k.
Then have some banks that you can switch in and out from 52k to 54k.
Those banks can come from anywhere. They could come from ROM or EPROM
or from a SRAM chip.
The idea would be that you send an OUT instruction to a particular
address and that switches in a bank. Then run that code (it might be
the low level SPI driver for an SD card). Then return to CP/M and
maybe switch in a bank to talk to the keyboard.
I think this means that the CP/M part can be largely unchanged, and
all the new code (ie for things that did not exist when CP/M was
written, like PC keyboards and SD cards) - these drivers can be
written as separate modules. In fact, this code does already exist,
and would just have to be recoded so it would work in a 2k (or 4k)
block of code.
This could be USERF code in an alternate code bank..it would be great
if RSX's could reside in an alternate bank and accessed by a new
banked strategy.
Post by James Moxham (Dr_Acula)
I'd be hoping that this would mean you could run CP/M 2, MP/M and a
new operating system on the same hardware.
Thinking about hardware, what I think this means is you don't want a
system that, say, switches the entire 16k of top ram in and out as a
bank. You need smaller blocks and the ability to switch both the size
of the block and the location of the block and control over where that
block came from.
I already have something very similar to this working on the propeller
with MP/M. It would be cool though to port it to a real Z80,
especially as the propeller emulation only runs at a Z80 speed of
about 2Mhz and I have some 10Mhz Z80 chips I'd like to use.
Thoughts would be most appreciated!
The Amstrad PCW8256 was probably the last and greatest of the Z80
production machines, with its 256k as standard, but since it was sold
as a word processing machine, a minority knew of its CP/M Plus
underpining, or cared back then as the ibm xt was the rage.

The pcw was socketed to accept another 256k. However, because the
buss was exposed on the back to accept a socketed buss peripheral,
after market peripherals were a mini-business, and one could obtain an
addon for another 512k plus a hard drive controller. The official
addon provided a serial port plus a parallel port, to support an
external printer and a modem, for example.

The memory map was organized in three banks, It used a block size of
16k (you are right, that is abit coarse, your suggestion of 2 or 4 k
would be ideal) the top 16k of the three banks was the same 'common'
block, variables and code in it was persistent across bank switches
that way. Bank0 was in context at reset, Bank1 was the 'normal' TPA
bank, like cp/m-80. Bank2 had the video mapped addresses/data (2
Blocks). I forget the exact mechanism for the mapping but it involved
writing a value to a port like F0h, I think something like writing a
logical block number to an ordinal port number - F0..FFh performed the
mapping.

So of the 256k, 144k (9) blks for the system as..

Bank0 :: Blk0, Blk1, Blk2, Blk3 - boot bank, USERF, loader, ccp
'banked' code
Bank1 :: Blk4, Blk5, Blk6, Blk3 - appeared as typical cp/m-80
Bank2 :: Blk0, Blk7, Blk8, Blk3 - boot bank USERF, memory mapped
blocks to video.

The 112k remainder was for the ram drive, and could be used that way, /
or/, could be accessed through the 'block select' USERF function
extentions and mapped into a bank at a given block position. Mostly
used by game programs for video 'tricks'.

Populating the next 256k memory sockets was the best bang for the
buck/

This, and alot of other stuff, was managed thru a FPGA that held the
logic for bank select and block mapping, and contained video
controller logic for something akin to a hercules video adapter. It
supported 90 character lines by 32 rows, and block graphic characters
as well as pixel graphics. Pretty effective for its custom
wordprocessing software to run on. And it managed an extended the
address bus (iirc it added 2 for a 18 address lines, or maybe 3.)
IIRC, the clock for the FPGA was at 32mhz, although the z80 ran at
something less than 4mhz.

So something like what you described, some open hardware design with a
'free cpm+' to go with it, that would be something to think about.
Even such, as a 'official' paper design, would be useful. Remember
that the 'official' CP/M was designed on and for the intel development
system and that was the cp/m 'standard' to compare against.

-= my 2 cents worth =-

Steve
Ruud
2011-04-06 10:24:54 UTC
Permalink
Hallo James,
Post by James Moxham (Dr_Acula)
what I am thinking is a banking system where the user has software
control and has control at a fine level, eg in 2k blocks. If you have
the ability to switch banks in and out of high memory and you can do
this in 2k blocks, then you don't need to be jumping around with bios
calls in low memory (which in themselves need custom code).
The isea is good and it could be done with a MMU.


Groetjes, Ruud Baltissen
www.Baltissen
MikeS
2011-04-06 16:09:03 UTC
Permalink
On Apr 5, 8:08 pm, "James Moxham (Dr_Acula)"
Post by James Moxham (Dr_Acula)
Thinking about hardware, what I think this means is you don't want a
system that, say, switches the entire 16k of top ram in and out as a
bank. You need smaller blocks and the ability to switch both the size
of the block and the location of the block and control over where that
block came from.
I already have something very similar to this working on the propeller
with MP/M. It would be cool though to port it to a real Z80,
especially as the propeller emulation only runs at a Z80 speed of
about 2Mhz and I have some 10Mhz Z80 chips I'd like to use.
Thoughts would be most appreciated!
If we're only talking about a block that contains system-specific I/O
routines I don't understand why the size of the block matters?

Assuming you handle interrupts and leave a common area that
contains any parameters and the bank control logic, couldn't
you effectively switch out the entire rest of the space if you
wanted to, perform the I/O or whatever, and switch back?

The reason I ask is that there is some discussion about porting
CP/M to the Tandy M100 type tablet computers. These systems
have a 32K main ROM containing the OS and BASIC, and an
optional switchable ROM, both in the lower half of the memory
map; they use a few K at the upper end of the 32K RAM area for
working storage, and programs, working memory and a RAMdisk
occupy the space in between.

The plan is to leave the main ROM and its reserved upper RAM
area as is, replace the optional switchable 32K ROM with
RAM, locate a more or less standard CP/M just below the high
RAM used by the system, and just swap the entire low 32K
RAM with the original ROM (which would effectively be most
of CP/M's BIOS) to call its I/O and display routines as needed.

Anybody see a flaw in that plan?
Ruud
2011-04-06 18:05:35 UTC
Permalink
Hallo James,
Post by James Moxham (Dr_Acula)
I have built a number of N8VEM boards and rewritten quite large parts
of the operating system, eg to include a keyboard driver that works at
the bit banging level.
Can N8vem run CP/M 3? I know it has more then enough RAM to do so IMHO
but I found only references to CP/M 2.

Is your N8VEM capable of running it? If so, are your sources available
for the public? If not, may be for a personal view?

Many thanks!


Groetjes, Ruud Baltissen
www.Baltissen
lynchaj
2011-04-08 02:16:11 UTC
Permalink
On Apr 6, 2:05 pm, Ruud <***@gmail.com> wrote:
[snip]
Post by Ruud
Can N8vem run CP/M 3? I know it has more then enough RAM to do so IMHO
but I found only references to CP/M 2.
Is your N8VEM capable of running it? If so, are your sources available
for the public? If not, may be for a personal view?
Many thanks!
Groetjes, Ruud Baltissenwww.Baltissen
Hi! Yes the N8VEM SBC does run CP/M 3.0. The SBC V1 will run CP/M
3.0 however when it was redesigned into the SBC V2 additional bank
switching circuitry was added by the N8VEM builders to allow more
conventional 48K/16K rather than the 32K/32K scheme. There are files
and ROM images for CP/M 3.0 and active development.

http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=CP%2FM%203%20files

All the N8VEM sources hardware and software are public and free/open.
If you can't find it on the wiki then please join the mailing list and
ask. It may not be posted yet and will be on request. The yet
unannounced N8VEM home computer is based on the Z8S180 which supports
more fine grained MMU and will also run CP/M 3.0 eventually.

Thanks and have a nice day!

Andrew Lynch

PS, if you haven't checked out the N8VEM wiki lately you might want to
revisit it. Due to the selfless and heroic efforts of one of the
builders (Douglas) the wiki has been completely reorganized and
updated. The layout is quite logical and I am finding things much
easier now. It is quite a dramatic improvement! Thanks Douglas!
James Moxham (Dr_Acula)
2011-04-08 04:47:22 UTC
Permalink
Thanks Andrew - the N8VEM is moving ahead in leaps and bounds. I might
head over to the N8VEM forum with a few technical questions about
hardware.
PC Pete
2011-04-06 22:44:42 UTC
Permalink
Post by James Moxham (Dr_Acula)
Thoughts would be most appreciated!
James, your thoughts definitely parallel (and supercede) mine in this area. Rather than LDIRing code or swapping to/from dedicated areas on disk, it makes a lot of sense
to take advantage of whatever granularity we can reasonably achieve in hardware.

At the end of the day, switching in/out 32k at a time results in at least 64k of disconnected code (32k being swapped out, 32k being swapped in), and the application or
OS still has to ensure it's executing in the top 32k! Same for 16k (which is what I'm used to developing for, on the Little Big Board).

I really like Andrew Lynch's idea of having a fixed area always guaranteed to be available, possibly swappable itself, to give the most robust method of doing all this
juggling. I'd like to extend that idea, with a number of swappable segments or windows (sorry) that can be easily moved around to suit almost any combination of memory,
as well as being able to page out 60k at a time if needed (I'm thinking RTOS here, but maybe more limited than a full-on RTOS kernel).

The catch comes with the granularity - finer granularity means significantly more hardware to support it, especially if we don't want to 'throw away' data by switching in
a 2k "window" (sorry!) from a 32k SRAM bank and "losing" the other 30k! That means offset arithmetic in hardware, and as Ruud says, an MMU is probably the 'least worst'
approach.

One of my existing Z80 SBC designs has discrete 4k granularity control (using an LS688 12-bit address comparator and some glue logic), and that worked extremely well in
testing, but I didn't get any further in terms of OS or Monitor support due to other, unrelated, factors. :)

But I will be revisiting that code (if I can find what's left of it) later today. Like I said, 2k pages are on my notebook's 'what if' page...

I guess there will be a breakeven point in terms of how granular vs. how large the board has to be! But an FPGA would seem to be a pretty darn good MMU option... Just
thinking out loud...

Other thoughts anyone?

Cheers,
Pete
James Moxham (Dr_Acula)
2011-04-07 14:01:27 UTC
Permalink
Post by Ruud
Can N8vem run CP/M 3? I know it has more then enough RAM to do so IMHO
but I found only references to CP/M 2.
I am not sure about CP/M3. I don't think it can run MP/M.

I am running MP/M on the Propeller emulation and I have the source for
running 8 users at the same time. It is code taken from the SIMH and
modified and recompiled on the Propeller board under CP/M2.

@PCPete - we are thinking the same thing here! 2k or 4k - maybe it
does not matter so much. In general, I'd like to think you could free
up as much of the 64k as possible for the programs.

It would be great to think we could design a *better* little big
board. In general terms, if you had a number of digital I/O lines (one
or two 8255s?) you could do a lot. Run a keyboard. Talk to an SD card.
(I like SD cards, especially the low current consumption. On the N8VEM
discussion group are comments about big power supplies to run CP/M
boards. My CP/M boards run cold. Even the regulators run cold!)

I need to think about how you might do bank switching. Given a 512k
ram chip, you could run 8x64k for MP/M. Or run less users and use some
of that ram for BIOS. Or devote some of that ram to a ramdisk. And you
might want 2k granularity, but also the ability to do 16k and 32k for
backwards compatability.

Ideally any bank switching would be flexible enough to do all these
things. It might end up so complicated it would be FGPA, but maybe it
can be simplified? In a generic sense, I think the bank switching is n
control lines, 19 address inputs, and 19 address outputs. And needs to
do the eprom as well?

I suppose one initial question might be to ask - what is the maximum
one might want to allocate in high ram for the operating system? 10k?
More? Less?

I wonder if you simplified it and said that the top 16k is the
operating system. The bottom 48k is switched as a bank for MP/M and
the like.

The top 16k stays the same, but you can bring in 4k from elsewhere in
ram. So the OS fits in 12k and there is 4k you can use for drivers.
Take a 64k block and split it up in to 16 groups of 4k, and that ends
up being offset.

This is quite a fun little mental exercise!
Tilmann Reh
2011-04-07 15:06:30 UTC
Permalink
Post by James Moxham (Dr_Acula)
Post by Ruud
Can N8vem run CP/M 3? I know it has more then enough RAM to do so IMHO
but I found only references to CP/M 2.
I am not sure about CP/M3. I don't think it can run MP/M.
...
@PCPete - we are thinking the same thing here! 2k or 4k - maybe it
does not matter so much. In general, I'd like to think you could free
up as much of the 64k as possible for the programs.
I'm wondering why you think about reinventing the wheel...

I'd suggest to have a closer look at CP/M-3. All those details have long
been solved. My CP/M-3 implementation (running on a CPU280) provides
exactly 62k TPA; I don't think it could be larger while being a true CP/M.
Post by James Moxham (Dr_Acula)
Ideally any bank switching would be flexible enough to do all these
things. It might end up so complicated it would be FGPA, but maybe it
can be simplified? In a generic sense, I think the bank switching is n
control lines, 19 address inputs, and 19 address outputs.
Basically, you just need a small, fast SRAM to build a segmented MMU. In
early days, 74S189 was often used, today a small CPLD might do (maybe
resulting in a paged MMU only, but that would be OK here).
Or use a CPU with a built-in MMU (the Z180 has a paged one - rather
primitive, but sufficient for CP/M-3).
Post by James Moxham (Dr_Acula)
I suppose one initial question might be to ask - what is the maximum
one might want to allocate in high ram for the operating system? 10k?
More? Less?
For CP/M-3 and an efficient implementation: 2k is enough (see above).

Tilmann
PC Pete
2011-04-07 08:32:32 UTC
Permalink
Post by James Moxham (Dr_Acula)
I have been pondering this and maybe this isn't the best answer, but
what I am thinking is a banking system where the user has software
control and has control at a fine level, eg in 2k blocks. If you have
the ability to switch banks in and out of high memory and you can do
this in 2k blocks, then you don't need to be jumping around with bios
calls in low memory (which in themselves need custom code).
James, I've just finished logic testing 2 different granularity options that might work similarly to what you described.

I have a 2k bank switchable between 16 different banks (on a 32k RAM), using a 4-bit latch, a MUX, and an inverter. This allows a single 64K plus 32k, or a single 128k
RAM chip to be completely used for 2 separate 'swing-in' banks. One is at E000h, the other is at E800h, and both can be managed separately (from a 128k chip) or one at a
time (from a 64k/32k combo).

I've also just debugged a 60K bank arrangement, allowing for exactly 17 banks of 60K linearly addressed over a 1M RAM chip. This needs 2 MUXes, 4 inverters, a latch, a
couple of NORs, and can be extended to just about any size.

Both schemes allow for any ROM size, with a dedicated RAM area available even when the ROM is switched in (I never use all of a 32k ROM, even for my robot's lookup
tables!). It's even possible to use a 64k ROM, there's no fiddling around required. So far. :)

So I guess it's pretty trivial to support this kind of "swing-in" banking scheme, and if we think about it, the logical place to put the bank-switching routines is in the
BIOS! That way, we can trap bad attempts to swap before the system is ready, etc. THere still need to be flags and semaphores in place to manage the code and prevent
interrupts from breaking the execution, although if we used mode 2 interrupts, we already have an excellent fixed RAM space to put the IVECT table.

I haven't thought this completely through in terms of software protection needed, so that's where the difficulty (for me) lies.
-PCP
William
2011-04-03 18:29:12 UTC
Permalink
Post by PC Pete
It seems there is at least *some* interest in a modern respin of CP/M 2.x or 3.0...
Ruud is right, there's plenty of expertise here to put together a team to investigate and rebuild an open source release of CP/M on the Z80.
1) who would like to participate?
2) who has time to participate in such a project?, and finally
3) who has the necessary skills (AND time, AND interest) to participate?
There are other questions, like hosting, forum software, use of a versioning (or at least a checkout/checkin) system, and so on that will need to be discussed.
For my part, I will gladly offer one of my domains for initial use in this project, and manage access and so on, if that would help. I have a couple of very quiet domains
that can be configured with good-quality forum software (PHPBB is already running on one domain), and while disk space may eventually become a limiting factor, I'm quite
willing to provide additional space if needed via some other mechanisms. The only catch is, initially it won't be called CP/M 4 or CP/M OS or whatever.com, but that can
be fairly easily changed at some later date via an alias or migration. Nothing is impossible!
The obvious alternative is Sourceforge or FreshMeat or something similar; I'm personally a bit "nervous" about such places for a number of administrative and political
reasons, and a lot of new projects do go there to die! My main concern though, is communication - the "forum" software on SF is a joke. So it would become a decision
based on access to all users vs the ability to use CVS or something similar to manage the project.
Having said ALL THAT (!), CVS or similar is NOT a prerequisite for such a project, at least IMHO.
So I guess the next step is to find a way to continue from here without hijacking the comp.os.cpm newsgroup! Then we can start to consider gathering existing
documentation, figuring out which Z80 target(s) to support, consider backwards-compatibility issues (like the deblocking thing, which is such a boatanchor), hardware
configuration support, graphics vs text-only, minimum/maximum memory size support, and possibly later on porting to other architectures. If the basic OS is written from
the ground up with proven value long-term industry-standard tools (Assembler -which one(s)?, C or C++, ANSI or not, etc), then porting should become a much more
manageable issue. With some clever thought in the modularity department (see, TurboDOS does have something to offer!), it should be possible to make this as flexible as
we wish.
I hope this small token is a starter for other folks.
Comments, suggestions, ideas, flames?
My vote goes to an Open CP/M written in C, (so it might run on any
processor and is easier to understand), In order to make a useful
system even with only 16kb, the C code should avoid automatic
variables and when this is done the BDOS should fit in 4 to 5k or so.
DRI's C code should be avoided as it compiles very inefficiently to a
Z80 target. I've used SDCC.

Modularity can be achieved by making self relocating programs which
can extend or substitute CCP, BDOS, etc., The code is merged into a
PRL header so will work even on a "primitive" CP/M 1.x like system. A
single source file could contain conditional compilation to specify
CDOS, CP/M 1.x, CP/M 2.2 compatibility etc.

I have rather mixed feelings about implementing the CP/M file system.
Originally it was designed for IBM 8" floppies under CP/M 1.x and was
kludged to be more general under 2.2 and later. I think Paterson was
right to ignore it and opt for a FAT style system which is smaller and
faster (but uses more RAM), whilst offering the same FCB API. If I
had my way the BDOS wouldn't "know" anything about sectiores and
tracks at all. It would simply access the BIOS using a logical record
number. This would simplify the BDOS and put all the hardware
dependent stuff in the BIOS where it belongs! However given legacy
code uses the BIOS we have to use that interface I suppose. :)

I volunteer to help.

Bill
Ruud
2011-04-02 09:48:43 UTC
Permalink
Hallo allemaal,


I have been working with the sources of CPMLDR.COM which I found in
cpm3_src.zip so I could turn it into a Z80 file. Weird experience: it
was full of typos! In one case even a call to a subroutine I couldn't
find. But I managed to assemble it and although the result was much
shorter then then the original COM, a FC showed that quite a lot in
the start was the same. So now I'm going to polish both the Z80 file
(and 8080 if possible) to make the result exact to the COM file.


Groetjes, Ruud Baltissen
www.Baltissen
Ruud
2011-04-02 20:28:13 UTC
Permalink
Hallo allemaal,
Post by Ruud
I have been working with the sources of CPMLDR.COM which I found in
cpm3_src.zip so I could turn it into a Z80 file.
It becomes even weirder: in the disassembly of the COM file I found a
reference to the ZFDC board. It was found in the part the user has to
supply himself at the end of the source. So it seems that somebody,
IMHO John Monahan, used the sources to create his own CPMLDR.COM and
that's the one I found.


Groetjes, Ruud Baltissen
www.Baltissen
John Elliott
2011-04-02 22:49:05 UTC
Permalink
Ruud <***@gmail.com> wrote:
: It becomes even weirder: in the disassembly of the COM file I found a
: reference to the ZFDC board. It was found in the part the user has to
: supply himself at the end of the source. So it seems that somebody,
: IMHO John Monahan, used the sources to create his own CPMLDR.COM and
: that's the one I found.

That's standard procedure. From the CP/M 3 System Guide, section 1.8:

# Digital Research supplies a CP/M 3 loader file, CPMLDR, which you can link
# with your customized loader BIOS and use to load the CPM3.SYS file into
# memory. CPMLDR is a small, self-contained version of CP/M 3 that supports
# only console output and sequential file input. Consistent with CP/M 3
# organization, it contains two modules: an invariant CPMLDR BDOS, and a
# variant CPMLDR-BIOS, which is adapted to match the host microcomputer
# hardware environment. The CPMLDR BIOS module can perform cold start
# initialization of I/O ports and similar functions. CPMLDR can display a
# memory map of the CP/M 3 system at start-up. This is a GENCPM option.

So yes, any completely assembled and linked version of CPMLDR will contain
system-specific code.

Note also that CPMLDR isn't necessary. It was created for machines whose
boot ROM was designed to load CP/M 2 from a fixed area of the disc; CP/M 3,
being bigger, wouldn't fit into that space, but CPMLDR would. It's quite
possible to use other boot methods. Amstrad's versions, for example, would
have the boot sector load a single file of arbitrary size into memory, and
that file contained the BIOS, BDOS, CCP and various other bits and pieces.
The first chunk of code would copy everything to the right place in memory.
--
John Elliott

Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show
Ruud
2011-04-04 05:41:41 UTC
Permalink
Hallo allemaal,


I have one importatant question: who is going to lead the project?

I know I started the thread but I haven't almost any inside knowledge
of CP/M. I only can give it a start by dividing the project up into
subparts (and even that can/should be discussed):

1) Requirements - What are the minmal needs for a system to be capable
of running OpenCP/M, banked or not banked. Plus info for a newbee and
examples.

2) ROM - What is the minimal the ROM should contain.

3) BIOS

4) BDOS

5) SYSGEN - A program that combines the above (+ more ???) to CPM3.SYS
(or other name?). I myself would rather prefer sources of the above in
C or assemly + some directives then generate the file with an
assembler or compiler instead of a seperate program, just an idea.

6) CPMLDR - It should load the whole form disk.

Until here we should have something that must be able to load CCP.COM
and run all already existing CP/M programs. ANY different schedule/
idea is welcome!
One more important thing: you write the software, you write the
documantation!

From here on we can think of developing open source tools like
assemblers, compilers, editors etc.

Please shoot :)


Groetjes, Ruud Baltissen
www.Baltissen.org
Steve Nickolas
2011-04-04 06:09:43 UTC
Permalink
Post by Ruud
5) SYSGEN - A program that combines the above (+ more ???) to CPM3.SYS
(or other name?). I myself would rather prefer sources of the above in
C or assemly + some directives then generate the file with an
assembler or compiler instead of a seperate program, just an idea.
On MS-DOS and descendents, the BIOS, BDOS and CCP are separate files
(io.sys, msdos.sys, command.com in the case of the MS dialect). I'm
kind-of used to this arrangement, but generally I've seen CP/M systems
include them all in either one file, or hidden sectors.

-uso.
pbetti
2011-04-04 07:58:25 UTC
Permalink
Post by Ruud
Hallo allemaal,
I have one importatant question: who is going to lead the project?
I know I started the thread but I haven't almost any inside knowledge
of CP/M. I only can give it a start by dividing the project up into
1) Requirements - What are the minmal needs for a system to be capable
of running OpenCP/M, banked or not banked. Plus info for a newbee and
examples.
2) ROM - What is the minimal the ROM should contain.
3) BIOS
4) BDOS
5) SYSGEN - A program that combines the above (+ more ???) to CPM3.SYS
(or other name?). I myself would rather prefer sources of the above in
C or assemly + some directives then generate the file with an
assembler or compiler instead of a seperate program, just an idea.
6) CPMLDR - It should load the whole form disk.
Until here we should have something that must be able to load CCP.COM
and run all already existing CP/M programs. ANY different schedule/
idea is welcome!
One more important thing: you write the software, you write the
documantation!
From here on we can think of developing open source tools like
assemblers, compilers, editors etc.
Please shoot :)
Groetjes, Ruud Baltissenwww.Baltissen.org
Not all opensource projects have one single project leader. We can
also consider a board that coordinates development effort.
What is mandatory is to define the rules for source/pacth submission
and acceptance (Nothing complex, just a guide).
Also a repository server (svn?) is needed. I can setup one very
quickly if you agreed.

Piergiorgio
PC Pete
2011-04-04 09:10:18 UTC
Permalink
Guys, if you haven't already done so, please head over to Nathanael's forum (http://www.accardi-by-the-sea.org/freecpm/) to see what we've started to do there and see if
that feels comfortable for you to continue the discussion...

None of it is set in stone, of course, these are just talking points - but we seem to be duplicating our efforts here and there!

I have no issue whichever way we decide to thrash this out, but the less bandwidth we consume here, the happier everyone else will be. We can still report back as
milestones are reached, etc, etc.

Sorry if I sound like your Mum!!!! (and while I'm happy to help everyone else out in EVERY way, I DON'T want to be the project manager!) I think Piergiorgio is right -
for now, a committee is probably going to get ideas sorted and thrashed out quickest, with everyone getting a chance to have their say. No-one (NO-ONE!) is unimportant.
The "stupidest idea" could be the best we ever have! :)

Cheers,
PC Pete
Ruud
2011-04-04 15:34:31 UTC
Permalink
Hallo PCPete,
Post by PC Pete
please head over to Nathanael's forum (http://www.accardi-by-the-sea.org/freecpm/)
I just did :)


Groetjes, Ruud Baltissen
www.Baltissen.org
dott.Piergiorgio
2011-04-04 13:19:18 UTC
Permalink
Post by Ruud
I know I started the thread but I haven't almost any inside knowledge
of CP/M. I only can give it a start by dividing the project up into
1) Requirements - What are the minmal needs for a system to be capable
of running OpenCP/M, banked or not banked. Plus info for a newbee and
examples.
well, for major improvement a Z80 is needed, because the more compact
code gives a larger TPA. (but see below)
Post by Ruud
2) ROM - What is the minimal the ROM should contain.
On this, what about a minimal ROM whose handle the bankswitch to the
bank containing the BDOS/BIOS and return from it ? this can be done in
~1K and hardware-wise should need only the check of some more address
lines ? this theorically will give a banked CP/M or MP/M with 63K TPA
for bank (save the system bank holding the BIOS and BDOS, of course)

[snip]
Post by Ruud
Until here we should have something that must be able to load CCP.COM
and run all already existing CP/M programs. ANY different schedule/
idea is welcome!
See above.
Post by Ruud
One more important thing: you write the software, you write the
documantation!
well, this is the major issue, coding and having care of commenting are
generally incompatible ;)
Post by Ruud
From here on we can think of developing open source tools like
assemblers, compilers, editors etc.
well, on tools, I guess there are umpteen X-assemblers for Z-80 and at
least one (pasmo6) capable of handling 8080 mnemonics.

on native assemblers, I think is feasible, on native compilers, I
suspect is definitively a rather difficult thing to do on a Z80 but at
least I estimate that is feasible to code a fortran or algol compiler.
both language are really well defined.

Editors is perhaps the least issue, if we avoid the ancient Emacs-Vi
war, because seems that there is more microemacs variants and versions
than stars in the sky....
Post by Ruud
Please shoot :)
ranging salvo fired, waiting for spotting results ;)

(remember, I'm mainly a Naval historian...)

Best regards from Italy,
dott. Piergiorgio.
Greegor
2011-04-06 03:40:00 UTC
Permalink
What kind of modern technology enhancements
would be in or out?

Not targeted for multimedia, right?
No MP/3, no complex sound
No DVD video handling
No browser, just CP/M term programs talking to RS232

IDE storage?
SATA storage?
USB 2.0 (3?) to talk to devices
USB to pose as a device on a PC? (trickier)
( useful to use PC as a terminal )

Is this intended to run the old CP/M public domain
libraries without code modification?

Is it oriented around home control or
process control applications?

Haven't most home control things gone
fairly high tech, not much direct wired
anymore, right?

Haven't vid CAMERAS become a pretty
big part of the home control field?
Not a match for this project.

But could cheap web cam be used
to do still photos?

I guess what I'm thinking is that
if you try to make this all things
to all people, projects like that tend
to do none well.

What would the main advantages of such
a reincarnation really be?

What would the great strengths of such
a project really be?

Programming ease for old Z-80 coders
who haven't updated to the latest PC's?
I did some Z-80 interfacing in ASM 32 years
ago but did not keep up with bit twiddling
all of the processors since then.

Using Propeller/FPGA or whatever to
do intelligent disk I/O, memory swapping,
I/O handling and greatly simplifying
the use of somewhat standard CP/M
might be acceptable to more of the
older CP/M carmudgeons/purists.

Some of the cheap Chinese MP/3 players
run on glorified fast Z-80 clones with
USB, SDRAM I/O and LCD I/O and
some can even do video with color
LCD screens. The same chips are used
in some flash drives, and some consumer
still cameras.

Nobody seems to be interested in making
a super cheap Z-80 computer to run CP/M
based on one of those Chinese super Z-80's.

I suppose there's no money in it but wouldn't
that revive the old CP/M software world?

http://groups.google.com/group/comp.os.cpm/msg/e8937295dc7e4011
Floppy Software
2011-04-06 12:11:36 UTC
Permalink
Post by Greegor
What kind of modern technology enhancements
would be in or out?
Hi!

Enhancements?

That's what I like to see in CP/M 4:

- stdin / stdout redirection supported at CCP level (not CCP
replacements).

- SUBMIT with IF, GOTO, etc. (not external programs).

- Password protection out forever. It's very poor. I think that size
code can
be used for more interesting and useful things.

- Loadable / unloadable device drivers as: opendev("epson.dev") that
can
be in TPA or banked.

- Environment variables internally supported as: getenv("tempdrive").

- User areas with name internally supported by BDOS (and CCP of
course). As open("mydata/today.txt"). This can be done adding
extended BDOS functions and preserving the older ones.

Regards.
Bruce Morgen
2011-04-06 17:05:26 UTC
Permalink
Post by Floppy Software
Post by Greegor
What kind of modern technology enhancements
would be in or out?
Hi!
Enhancements?
- stdin / stdout redirection supported at CCP level (not CCP
replacements).
- SUBMIT with IF, GOTO, etc. (not external programs).
- Password protection out forever. It's very poor. I think that size
code can
be used for more interesting and useful things.
- Loadable / unloadable device drivers as: opendev("epson.dev") that
can
be in TPA or banked.
- Environment variables internally supported as: getenv("tempdrive").
- User areas with name internally supported by BDOS (and CCP of
course). As open("mydata/today.txt"). This can be done adding
extended BDOS functions and preserving the older ones.
Much of this stuff was
accomplished (albeit in
significantly compromised
ways dictated by CP/M 2.2
compatibility constraints)
by the ZCPR34/ZSDOS
combination, which has
been available for many
years. There's even an
auto-installing version
called NZCOM for CP/M 2.2
and one for CP/M 3 called
Z3PLUS (which doesn't
involve BDOS replacement)
-- all of them freebies
at this point afaik. The
source code for ZCPR 3.4
and ZSDOS comprise master
classes in compact Z80
assembler coding, and if
nothing else could serve
as a starting point for a
project untethered from
the limitations of extant
DRI products.
Floppy Software
2011-04-07 12:24:12 UTC
Permalink
Post by Bruce Morgen
Post by Floppy Software
Post by Greegor
What kind of modern technology enhancements
would be in or out?
Hi!
Enhancements?
- stdin / stdout redirection supported at CCP level (not CCP
replacements).
- SUBMIT with IF, GOTO, etc. (not external programs).
- Password protection out forever. It's very poor. I think that size
code can
 be used for more interesting and useful things.
- Loadable / unloadable device drivers as: opendev("epson.dev") that
can
 be in TPA or banked.
- Environment variables internally supported as: getenv("tempdrive").
- User areas with name internally supported by BDOS (and CCP of
course). As open("mydata/today.txt"). This can be done adding
extended BDOS functions and preserving the older ones.
Much of this stuff was
accomplished (albeit in
significantly compromised
ways dictated by CP/M 2.2
compatibility constraints)
by the ZCPR34/ZSDOS
combination, which has
been available for many
years.  There's even an
auto-installing version
called NZCOM for CP/M 2.2
and one for CP/M 3 called
Z3PLUS (which doesn't
involve BDOS replacement)
-- all of them freebies
at this point afaik.  The
source code for ZCPR 3.4
and ZSDOS comprise master
classes in compact Z80
assembler coding, and if
nothing else could serve
as a starting point for a
project untethered from
the limitations of extant
DRI products.- Ocultar texto de la cita -
- Mostrar texto de la cita -
Hi Bruce,

Yes, I know but... that's not CP/M.

I was talking about modifying BDOS and CCP and adding
that things.

ZCPR, etc. are external adds.
James Moxham (Dr_Acula)
2011-04-07 14:03:43 UTC
Permalink
I've also just debugged a 60K bank arrangement, allowing for exactly 17 banks of 60K linearly >addressed over a 1M RAM chip. This needs 2 MUXes, 4 inverters, a latch, a
couple of NORs, and can be extended to just about any size.
That sounds interesting. Have you got a link to a schematic by any
chance?
PC Pete
2011-04-07 21:30:37 UTC
Permalink
Post by James Moxham (Dr_Acula)
That sounds interesting. Have you got a link to a schematic by any
chance?
On my notepad and in Altium Explorer 6.0, yes... Let me work something up that's postable (and *verifiable* !!)
PC Pete
2011-04-08 23:58:03 UTC
Permalink
Post by PC Pete
Post by James Moxham (Dr_Acula)
That sounds interesting. Have you got a link to a schematic by any
chance?
On my notepad and in Altium Explorer 6.0, yes... Let me work something up that's postable (and *verifiable* !!)
I found a showstopper with the 60k swapping hardware. It's been a *long* time since I bought SRAM, and it's not easy to find 1Mx8 (i.e. 8megabit) SRAM configurations. The
alternative is to stack 4 megabit SRAMS (i.e. 2 x 512kx8), or under-utilise a 2Mx8 SRAM.

I'm working on a way to combine the best of both worlds - 2k switchable from up to 16 locations, and 60k switchable from up to 32 locations. It's overkill, but I like
overkill.

My first iteration will use a single 512kx8, plus a 32kx8 - it's WAY cheaper than a high-capacity chip, and does the exact same thing, only takes a little more space.

I'll try to get a basic schematic up somewhere asap. Sorry about the running around, things have changed in the memory world quite a bit... I can buy a 32k x 8 12nS SRAM
for 80% less than I used to be able to buy a 2k x 8 300nS SRAM!
Bruce Morgen
2011-04-07 15:44:17 UTC
Permalink
Post by Floppy Software
Post by Bruce Morgen
Post by Floppy Software
Post by Greegor
What kind of modern technology enhancements
would be in or out?
Hi!
Enhancements?
- stdin / stdout redirection supported at CCP level (not CCP
replacements).
- SUBMIT with IF, GOTO, etc. (not external programs).
- Password protection out forever. It's very poor. I think that size
code can
 be used for more interesting and useful things.
- Loadable / unloadable device drivers as: opendev("epson.dev") that
can
 be in TPA or banked.
- Environment variables internally supported as: getenv("tempdrive").
- User areas with name internally supported by BDOS (and CCP of
course). As open("mydata/today.txt"). This can be done adding
extended BDOS functions and preserving the older ones.
Much of this stuff was
accomplished (albeit in
significantly compromised
ways dictated by CP/M 2.2
compatibility constraints)
by the ZCPR34/ZSDOS
combination, which has
been available for many
years.  There's even an
auto-installing version
called NZCOM for CP/M 2.2
and one for CP/M 3 called
Z3PLUS (which doesn't
involve BDOS replacement)
-- all of them freebies
at this point afaik.  The
source code for ZCPR 3.4
and ZSDOS comprise master
classes in compact Z80
assembler coding, and if
nothing else could serve
as a starting point for a
project untethered from
the limitations of extant
DRI products.- Ocultar texto de la cita -
- Mostrar texto de la cita -
Hi Bruce,
Yes, I know but... that's not CP/M.
I was talking about modifying BDOS and CCP and adding
that things.
ZCPR, etc. are external adds.
ZCPR is a full CCP replacement,
ZSDOS is a full BDOS replacement
-- a system running both has no
DRI code whatsoever, unless you
want to count its BIOS as such
because it's written to CP/M 2.2
specs. I don't see how they are
"external adds," but perhaps I'm
missing something.
PC Pete
2011-04-07 21:43:02 UTC
Permalink
Post by Bruce Morgen
Much of this stuff was
accomplished (albeit in
significantly compromised
ways dictated by CP/M 2.2
compatibility constraints)
by the ZCPR34/ZSDOS
combination, which has
been available for many
years. There's even an
auto-installing version
called NZCOM for CP/M 2.2
and one for CP/M 3 called
Z3PLUS (which doesn't
involve BDOS replacement)
-- all of them freebies
at this point afaik. The
source code for ZCPR 3.4
and ZSDOS comprise master
classes in compact Z80
assembler coding, and if
nothing else could serve
as a starting point for a
project untethered from
the limitations of extant
DRI products.
That's one of the burning issues - how compatible do we stay? So far, it looks like 100% backwards compatible (same as ZSDOS/ZCPR/NZCOM), but with * significant*
improvements and extensions - little and big. For example, I loved the ability to name user areas and drives - but this behaviour was very poorly (inconsistently)
implemented, precisely because of the extreme need to fit in the old "shoebox".

And the arbitrary 128 byte/8Mb per drive (that's megabytes, not mibibytes... don't get me started), well, that was a show-stopping limitation for many potential users
even before CP/M 3 hit the streets - and CP/M 3, for all its improvements, didn't do a thing to improve the disk system!

Bill's sample code already allows AFNs in findfirst and findnext, allowing AFN renaming using the same BIOS calls, but which don't affect legacy code. That's probably the
closest to what I would envisage such an OS replacement would allow.

In other words, better use of existing resources, plus far more flexibility in terms of non-legacy code. Not an easy job, I know, but if we don't at least look at
reinventing the wheel, we're going to be stuck with someone else's version of the wheel! And many of us don't like the way we cripple our "cars" so the old "wheel" will
still fit... (OK, not a good analogy...)

And don't forget, some of us are learning via this process, which would seem to be a fairly good thing, given that otherwise we're limited to "endless, sublime
recapitulation" instead of seeing what's possible. (With apologies to Umberto Eco!)
-PCPete
Bruce Morgen
2011-04-07 21:56:32 UTC
Permalink
Post by PC Pete
Post by Bruce Morgen
Much of this stuff was
accomplished (albeit in
significantly compromised
ways dictated by CP/M 2.2
compatibility constraints)
by the ZCPR34/ZSDOS
combination, which has
been available for many
years. There's even an
auto-installing version
called NZCOM for CP/M 2.2
and one for CP/M 3 called
Z3PLUS (which doesn't
involve BDOS replacement)
-- all of them freebies
at this point afaik. The
source code for ZCPR 3.4
and ZSDOS comprise master
classes in compact Z80
assembler coding, and if
nothing else could serve
as a starting point for a
project untethered from
the limitations of extant
DRI products.
That's one of the burning issues - how compatible do we stay? So far, it looks like 100% backwards compatible (same as ZSDOS/ZCPR/NZCOM), but with * significant*
improvements and extensions - little and big. For example, I loved the ability to name user areas and drives - but this behaviour was very poorly (inconsistently)
implemented, precisely because of the extreme need to fit in the old "shoebox".
And the arbitrary 128 byte/8Mb per drive (that's megabytes, not mibibytes... don't get me started), well, that was a show-stopping limitation for many potential users
even before CP/M 3 hit the streets - and CP/M 3, for all its improvements, didn't do a thing to improve the disk system!
Bill's sample code already allows AFNs in findfirst and findnext, allowing AFN renaming using the same BIOS calls, but which don't affect legacy code. That's probably the
closest to what I would envisage such an OS replacement would allow.
In other words, better use of existing resources, plus far more flexibility in terms of non-legacy code. Not an easy job, I know, but if we don't at least look at
reinventing the wheel, we're going to be stuck with someone else's version of the wheel! And many of us don't like the way we cripple our "cars" so the old "wheel" will
still fit... (OK, not a good analogy...)
And don't forget, some of us are learning via this process, which would seem to be a fairly good thing, given that otherwise we're limited to "endless, sublime
recapitulation" instead of seeing what's possible. (With apologies to Umberto Eco!)
Well, Pete, I don't have a
pony in this derby, having
written my last line of Z80
assembler a couple of
decades ago, but you might
want to touch base with my
old friend Hal Bower, who's
done some pretty extensive
work on adapting ZCPR/ZSDOS
to more capable modern
hardware and freeing it up
from crippling vestigial
limitations. Reinventing
the wheel is all fine and
good, but such an effort is
best done after thoroughly
familiarizing oneself with
prior art of similar ilk.
James Moxham (Dr_Acula)
2011-04-07 23:47:11 UTC
Permalink
@Tilmann For CP/M-3 and an efficient implementation: 2k is enough (see
above).

That sounds absolutely fascinating. Do you have a link to a schematic?

I don't know much about CP/M 3. Can it run CP/M 2 programs?

I do know about MP/M though. With MP/M, you need to be able to run CP/
M 2 in order to rebuild the images. How does that work in CP/M 3 - do
you also need an earlier version?

In an ideal world, any hardware would be able to run all these
versions of CP/M. So, in order of increasing complexity:

1) You would have some sort of eprom booter that maybe takes over the
lower 32k of memory and then switches over to ram when it is finished.
2) For CP/M 2 all the bank switching is off and there is just a 64k
flat memory space, and the rest of the ram chip is unused.
3) Then you could have some commands (? an out instruction) to switch
in a bank in CP/M 2. That might give CP/M 2 the ability to access the
rest of the ram chip and run a custom ram drive.
4) Then you could have banking in the standard MP/M way - ideally so
that the SIMH MP/M code runs with little or no modification.
5) Then think about customising MP/M so it hands over blocks of code
that are stored elsewhere in ram. Shrink the core OS code.
6) And then the Rolls Royce version, running Tilmann's code that only
takes 2k!

A thought. Say you have the ability to pull in a block of 2k of
assembly code. This would always end up in the same part of memory
(for example, E000). In terms of coding, would you put an ORG at the
beginning of your code and write some code up to 2k. It seems to me to
be simpler than trying to write code that can be 'relocatable' with
only relative jumps etc?
Steve Nickolas
2011-04-08 01:12:13 UTC
Permalink
Post by James Moxham (Dr_Acula)
I don't know much about CP/M 3. Can it run CP/M 2 programs?
Yes.

-uso.
Peter Dassow
2011-04-08 21:00:10 UTC
Permalink
Post by James Moxham (Dr_Acula)
@Tilmann For CP/M-3 and an efficient implementation: 2k is enough (see
above).
That sounds absolutely fascinating. Do you have a link to a schematic?
I don't know much about CP/M 3. Can it run CP/M 2 programs?
It is backward compatible.
The most significant difference between 2.2 and 3.0 is bank switching
and file system features (of MP/M II).
Because of additional memory with bank switching, buffering tracks and
directory is much faster.
Also you don't need to use Ctrl-C for each floppy disk change, and there
is in- and output redirection possible.

My personal opinion about this thread:
There is no need to reinvent a "new CP/M 2.2" or even a CP/M Plus for
Z80. Think about ZSDOS, the Z-System, ZCPR3, ZCPM3 and ZCCP.
Also, there were very good BDOS implementations already, see Tilmans
comment.
And last but not least, it will be talked a lot about it, but just
discussing things is one thing, implementing something is a different thing.

Regards
Peter
PC Pete
2011-04-09 00:04:51 UTC
Permalink
Post by Peter Dassow
Post by James Moxham (Dr_Acula)
@Tilmann For CP/M-3 and an efficient implementation: 2k is enough (see
above).
That sounds absolutely fascinating. Do you have a link to a schematic?
I don't know much about CP/M 3. Can it run CP/M 2 programs?
It is backward compatible.
The most significant difference between 2.2 and 3.0 is bank switching
and file system features (of MP/M II).
Because of additional memory with bank switching, buffering tracks and
directory is much faster.
Also you don't need to use Ctrl-C for each floppy disk change, and there
is in- and output redirection possible.
There is no need to reinvent a "new CP/M 2.2" or even a CP/M Plus for
Z80. Think about ZSDOS, the Z-System, ZCPR3, ZCPM3 and ZCCP.
Also, there were very good BDOS implementations already, see Tilmans
comment.
And last but not least, it will be talked a lot about it, but just
discussing things is one thing, implementing something is a different thing.
Yes, there's nothing new under the sun these days, Peter!

So far, there's quite a bit of talk, but there's also been quite a bit of action too.

THis is good - it means people are genuinely interested in looking at improving what was (in it's day) a great little OS, and they're prepared (with their wallets) to
find out what it takes to do this, without necessarily being restrained by all the baggage that came with CP/M (like 128-byte sectors, directory limits, 8080-only
opcodes, etc, etc). Whether anything comes from this or not is in one way irrelevant - I'm learning heaps of new things, I'm back into my hardware design again, and I've
met some wonderful people. What's not to like? :)

What I find fascinating is trying to understand how something like CP/M 3, with it's revolutionary support of "512Mb drives" with "32Mb filesize" limits, would work with
32k or 48k paging schemes. It seems (to me) that CP/M 3 was only the first step in that direction. If DOS and personal UNIX (Xenix, SCO, etc) hadn't come along just then
with a focus on the 16-bit goal, CP/M might have developed into...????
James Moxham (Dr_Acula)
2011-04-09 04:43:37 UTC
Permalink
Post by PC Pete
I'm working on a way to combine the best of both worlds - 2k switchable from up to 16 locations, and 60k switchable
from up to 32 locations. It's overkill, but I like overkill.
That sounds interesting.

Back when we were first getting the N8VEM working the only way to
debug CP/M was to program a 32k eprom. I spent over a week on that - a
ZIF socket, a Willem programmer and 20 eproms that cycled endlessly
between the programmer and the eprom erasor. While it was fun to see
an OS come to life (and probably good for the soul), I do wonder if
there are better ways to do things.

I'm thinking of leveraging what already works. Say you have CP/M 2,
and it is working and you can write code and compile it on the board.
And/or you have xmodem so you can do downloads with one keypress (we
have both of these things).

Pick a location in high memory, maybe just under CP/M. Write your 2k
test program and load it to that location. Then you can move that code
into other parts of the ram using bank switching. And you can debug it
from your favourite language, eg Basic or C, by issuing a call to the
high memory location. If it works then it returns to your high level
language and you go on to the next step. But if it crashes, just
reboot CP/M and try different code. Easier than programming an eprom.
And the code would be more modular too.

I'd be interested to see what sort of schematic you come up with.
Peter Greuter
2011-04-09 12:41:53 UTC
Permalink
Post by Peter Dassow
There is no need to reinvent a "new CP/M 2.2" or even a CP/M Plus for
Z80. Think about ZSDOS, the Z-System, ZCPR3, ZCPM3 and ZCCP.
Also, there were very good BDOS implementations already, see Tilmans
comment.
And last but not least, it will be talked a lot about it, but just
discussing things is one thing, implementing something is a different thing.
Regards
Peter
+1

IMHO, an operating system is just a tool needed by application
programs, to access and to control the hardware of a computer.

The Question is :
are there any people who will write new application programs for the
New CP/M++++ ?
And : Who needs a newer and better CCP ?

And :
The old applications will not take advantage of the new CP/M++++
(except may be for bigger TPA size ?).

Who will adapt old tools (assemblers, languages etc ) to use the new
features (date, wildcards etc )?

Who will adapt old word processors used by old users ? Which documents
can you process with a TPA size of 62 kbytes ?

I think there will be also a big problem for testing the new version
on a multitude of hardware configurations. RAM bank-switching needs
new hardware. The only way : standardize on one modern CP/M hardware,
will leave out 90% of the current users and developpers.

Kind regards from sunny Paris (France).
--
Peter Greuter
SOPEGE MICPER: microcomputers since 1976
http://www.sopege.fr/histoire.html
PC Pete
2011-04-08 23:51:34 UTC
Permalink
Post by James Moxham (Dr_Acula)
@Tilmann For CP/M-3 and an efficient implementation: 2k is enough (see
above).
That sounds absolutely fascinating. Do you have a link to a schematic?
I don't know much about CP/M 3. Can it run CP/M 2 programs?
I do know about MP/M though. With MP/M, you need to be able to run CP/
M 2 in order to rebuild the images. How does that work in CP/M 3 - do
you also need an earlier version?
In an ideal world, any hardware would be able to run all these
1) You would have some sort of eprom booter that maybe takes over the
lower 32k of memory and then switches over to ram when it is finished.
2) For CP/M 2 all the bank switching is off and there is just a 64k
flat memory space, and the rest of the ram chip is unused.
3) Then you could have some commands (? an out instruction) to switch
in a bank in CP/M 2. That might give CP/M 2 the ability to access the
rest of the ram chip and run a custom ram drive.
4) Then you could have banking in the standard MP/M way - ideally so
that the SIMH MP/M code runs with little or no modification.
5) Then think about customising MP/M so it hands over blocks of code
that are stored elsewhere in ram. Shrink the core OS code.
6) And then the Rolls Royce version, running Tilmann's code that only
takes 2k!
James, that's pretty much all CP/M machines in a nutshell! (Except for non-banked systems of course).

I guess the catch is in initialising all those pages with the "right" code. That could take hundreds of milliseconds. :) This will add to the perceived boot up time, but
wouldn't (I don't think) be really noticeable with ROM-based loaders and RAM-based disks.
Post by James Moxham (Dr_Acula)
A thought. Say you have the ability to pull in a block of 2k of
assembly code. This would always end up in the same part of memory
(for example, E000). In terms of coding, would you put an ORG at the
beginning of your code and write some code up to 2k. It seems to me to
be simpler than trying to write code that can be 'relocatable' with
only relative jumps etc?
You can achieve this a couple of ways, depending on your assembler/linker.

For code that's always executed at a different location to where it's stored (e.g. in the ROM space), I use .phase and .dephase, these 'reset' the location counter in the
assembler to generate the right locations pointed to, but it won't work until that block of code is LDIR'd into the right place. Easy-peasy, and you don't need relative
addressing. There are other (and quite possibly better) ways, but this always works for me out-of-the-box!
-Pete
Loading...