Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Rewriting CP/M
1,561 views
Skip to first unread message
billc...@iscmns.org
Jan 12, 2018, 2:29:18 PM1/12/18
to
Last month I reported some progress on my attempt to rewrite CCP+BDOS compatible with CDOS and CPM 1. But as usual one gets carried away so the system is always in a state of almost working!!
My objective was always to write something small and comprehensible, and to overcome the design errors of the past. But don't get me started on listing all the weird design decisions of DR!!. Suffice it to say, that I am currently attempting to update the file system to CPM 2.2 compatibility and I am happy to say that bigger disks and files (>512 kB) seem to work. However I need to update to allow extent folding. Ugh!
Sequential reading and writing is complicated under CPM and is even worse with extent folding (where a single directory entry / FCB specifies multiple logical extents of 16 kB each). So as I was musing on the problem I thought why not implement a FAT8 file system with up to 256 clusters in a 256 byte FAT? The FAT itself could be contained in 256 bytes of the directory which would require less space because directory entries would only be 16 bytes long (no disk map required). On opening a file the FCB would be filled with a map of 16 cluster numbers just like CPM does but these would be fished from the FAT, not the directory. Obviously opening files would be faster and less disk space would be wasted.
What about RAM usage? Well CPM already uses a 128 byte directory buffer and further RAM for allocation bit map and checksum arrays. The FAT8 system described could reuse the same buffer for the FAT with no need for bit maps. The need for checksum arrays used to detect media changes, can be eliminated by logging off all removable drives when the CCP reads in a command. With the caching of 16 clusters in the FCB plus half the FAT remaining in the buffer, on a single drive system you probably wouldn't need (m)any further FAT accesses until the next file is opened. But for simplicity and speed it might be better to allocate a 256 byte buffer for both directory and FAT. Even so, this would hardly exceed the RAM requirements of CPM 2 BDOS.
Sequential I/O would faster without the need to make multiple scans of the directory every time a new extent is opened. And if the CPM 2 BIOS supports physical sectors > 128 bytes (usually the case) then it could be that the directory plus FAT are already cached in RAM.
Let's consider the smallest system with a 1 kB directory size. It could hold a respectable 48 entries and have space for the FAT too! And unlike CP/M we don't need entries for extra extents! And a 2 kB directory size would support 112 entries, 4 kB - 240 entries, 16 kB - 1008 entries. In every case, the FAT8 system significantly improves upon CPM.
I dare say some might prefer DOS FAT12 format. That's understandable but in the third millennium we might prefer software over hardware compatibility. Does anyone still use old FAT12 media?
It would be nice if anyone would like to participate in the design (or implementation) of this. In any case I shall proceed with Tiny CPM but I dare say I shall drop CDOS compatibility. I think that few actually need CDOS at all even if we appreciate it. And those few, can probably run their favourite CDOS programs using my MYCDOS. But there is nothing to stop CPM returning CDOS values in registers which CPM does not define. So very high compatibility can be achieved.
Cheers, Bill
My objective was always to write something small and comprehensible, and to overcome the design errors of the past. But don't get me started on listing all the weird design decisions of DR!!. Suffice it to say, that I am currently attempting to update the file system to CPM 2.2 compatibility and I am happy to say that bigger disks and files (>512 kB) seem to work. However I need to update to allow extent folding. Ugh!
Sequential reading and writing is complicated under CPM and is even worse with extent folding (where a single directory entry / FCB specifies multiple logical extents of 16 kB each). So as I was musing on the problem I thought why not implement a FAT8 file system with up to 256 clusters in a 256 byte FAT? The FAT itself could be contained in 256 bytes of the directory which would require less space because directory entries would only be 16 bytes long (no disk map required). On opening a file the FCB would be filled with a map of 16 cluster numbers just like CPM does but these would be fished from the FAT, not the directory. Obviously opening files would be faster and less disk space would be wasted.
What about RAM usage? Well CPM already uses a 128 byte directory buffer and further RAM for allocation bit map and checksum arrays. The FAT8 system described could reuse the same buffer for the FAT with no need for bit maps. The need for checksum arrays used to detect media changes, can be eliminated by logging off all removable drives when the CCP reads in a command. With the caching of 16 clusters in the FCB plus half the FAT remaining in the buffer, on a single drive system you probably wouldn't need (m)any further FAT accesses until the next file is opened. But for simplicity and speed it might be better to allocate a 256 byte buffer for both directory and FAT. Even so, this would hardly exceed the RAM requirements of CPM 2 BDOS.
Sequential I/O would faster without the need to make multiple scans of the directory every time a new extent is opened. And if the CPM 2 BIOS supports physical sectors > 128 bytes (usually the case) then it could be that the directory plus FAT are already cached in RAM.
Let's consider the smallest system with a 1 kB directory size. It could hold a respectable 48 entries and have space for the FAT too! And unlike CP/M we don't need entries for extra extents! And a 2 kB directory size would support 112 entries, 4 kB - 240 entries, 16 kB - 1008 entries. In every case, the FAT8 system significantly improves upon CPM.
I dare say some might prefer DOS FAT12 format. That's understandable but in the third millennium we might prefer software over hardware compatibility. Does anyone still use old FAT12 media?
It would be nice if anyone would like to participate in the design (or implementation) of this. In any case I shall proceed with Tiny CPM but I dare say I shall drop CDOS compatibility. I think that few actually need CDOS at all even if we appreciate it. And those few, can probably run their favourite CDOS programs using my MYCDOS. But there is nothing to stop CPM returning CDOS values in registers which CPM does not define. So very high compatibility can be achieved.
Cheers, Bill
rwd...@gmail.com
Jan 13, 2018, 6:09:00 AM1/13/18
to
Could Fat8 and your new system support some sort of sub-directory?
CPM-80 v3 User numbers is too global, one needs to be able to work on a subset of each drive,e.g subdirectories, unrelated to other drives, even if it is tied in to the concept of user number.
I recollect, but may be mistaken, that the user number applies across all drives.
Cheers
Richard
CPM-80 v3 User numbers is too global, one needs to be able to work on a subset of each drive,e.g subdirectories, unrelated to other drives, even if it is tied in to the concept of user number.
I recollect, but may be mistaken, that the user number applies across all drives.
Cheers
Richard
Udo Munk
Jan 13, 2018, 7:56:02 AM1/13/18
to
In the 80th we already had a CP/M 2 add-on with directories. Problem is you need to
rebuild applications against the new filesystem interface, else it is not of much
use. That was possible only if sources were available of course, the binary only
software won't know anything about the directories.
rebuild applications against the new filesystem interface, else it is not of much
use. That was possible only if sources were available of course, the binary only
software won't know anything about the directories.
roger...@gmail.com
Jan 13, 2018, 6:57:12 PM1/13/18
to
RT-11 takes an interesting approach with the LD: device driver,
which implements what is called logical disk subsetting. You can
mount a file on an LD: device and use it as a disk. Change
directories by dismounting that file and mounting a different
one. Software needs no modification to work with logical disk
subsets.
Of course, it's easier for RT-11 because the filesystem is contiguous;
when you mount a file, all LD: has to do is figure out where the file
begins and how big it is. Accessing a block in the LD: device is
simply a matter of adding the offset of the start of the file to
the block numbers passed in. A CP/M equivalent would have to be
able to figure out how to access each cluster in the subset.
--
roger ivie
roger...@gmail.com
which implements what is called logical disk subsetting. You can
mount a file on an LD: device and use it as a disk. Change
directories by dismounting that file and mounting a different
one. Software needs no modification to work with logical disk
subsets.
Of course, it's easier for RT-11 because the filesystem is contiguous;
when you mount a file, all LD: has to do is figure out where the file
begins and how big it is. Accessing a block in the LD: device is
simply a matter of adding the offset of the start of the file to
the block numbers passed in. A CP/M equivalent would have to be
able to figure out how to access each cluster in the subset.
--
roger ivie
roger...@gmail.com
gr...@sydneysmith.com
Jan 13, 2018, 10:29:13 PM1/13/18
to
Something to keep in mind is that some configurations of CP/M (or maybe just CDOS) have more than 256 blocks / clusters on a disk. This was with larger disk sizes and not-the-usual settings in the BIOS for EXM and related values.
Greg, from http://www.sydneysmith.com
Greg, from http://www.sydneysmith.com
billc...@iscmns.org
Jan 14, 2018, 1:19:59 PM1/14/18
to
On Sunday, 14 January 2018 04:29:13 UTC+1, gr...@sydneysmith.com wrote:
> Something to keep in mind is that some configurations of CP/M (or maybe just CDOS) have more than 256 blocks / clusters on a disk. This was with larger disk sizes and not-the-usual settings in the BIOS for EXM and related values.
>
> Greg, from http://www.sydneysmith.com
Yes the BIOS could be configured to use more than 256 blocks for higher capacity but you can alternatively allocate longer blocks. The largest block size is 16 kB and 256 of them would cover 8 Mb. Of course larger blocks may lead to wasted disk space but that's hardly a problem these days! And a benefit is faster disk access with up to 256 kB of disk addressable by 16 disk blocks in disk map of the directory entry / FCB.
> Something to keep in mind is that some configurations of CP/M (or maybe just CDOS) have more than 256 blocks / clusters on a disk. This was with larger disk sizes and not-the-usual settings in the BIOS for EXM and related values.
>
> Greg, from http://www.sydneysmith.com
gr...@sydneysmith.com
Jan 14, 2018, 4:21:38 PM1/14/18
to
Hi Bill,
All perfectly valid. It looks like you've thought the trade-offs through. I do agree there is an elegance to the simplicity of putting all of the extent map allocations in a single place.
I always disliked the messiness of FAT12 and having to shift 4 bits left or right sometimes. FAT8, whilst having some limits, is consistent with the idea of a tiny CP/M with better design decisions those that applied when CP/M was created.
CDOS compatibility goes because CDOS embeds BDOS within it, and changing how BDOS positions things on the disk would require rewriting CDOS too. CDOS programs could still be supported if you support the extra CDOS calls, which is what I think you had in mind for "nothing to stop CPM returning CDOS values in registers which CPM does not define".
Assuming that you are using disk image files for the disks, you will need tools to get files on and off the disk images, which would no longer be in standard CP/M format. I'd be willing to write a variation of cpmfs (http://www.sydneysmith.com/wordpress/cpmfs/) that would support the different disk image format. It should be compilable for both Win or nix.
I'm guessing the plan is the first 256 bytes (2 sectors) of the first directory block will be the FAT and everything after that is a normal FCB. Or 256 bytes then short (10H) FCBs as the mapping info has already been given.
To throw in another spanner, just so it has been considered, YAZE talks about mapping directly to the host file system. I haven't checked whether I misread that or it's actually true. The spanner is this: if you're going to fake standard CP/M extents by plugging values into the extent map, have you considered just using the filename and extension in the FCB and plugging in 00, 01, etc to access the host files directly? You could also add a CP/M call that changes the directory that CP/M looks in, to give you a "cd" command in CP/M and unlimited disk space. You also wouldn't need to get files into or out of disk images - the same files would exist inside CP/M and on the host. You'd probably need a "boot.dat" and a "sysarea.dat" but the directory could be faked from the currently selected host directory.
All the best,
greg from http://www.sydneysmith.com
Udo Munk
Jan 14, 2018, 5:07:26 PM1/14/18
to
On Sunday, January 14, 2018 at 10:21:38 PM UTC+1, gr...@sydneysmith.com wrote:
> To throw in another spanner, just so it has been considered, YAZE talks about mapping
> directly to the host file system. I haven't checked whether I misread that or it's actually true.
> The spanner is this: if you're going to fake standard CP/M extents by plugging values into
...
> To throw in another spanner, just so it has been considered, YAZE talks about mapping
> directly to the host file system. I haven't checked whether I misread that or it's actually true.
> The spanner is this: if you're going to fake standard CP/M extents by plugging values into
...
For this you might want to check out RunCPM:
https://github.com/MockbaTheBorg/RunCPM
It is pretty good doing this.
billc...@iscmns.org
Jan 15, 2018, 6:47:14 AM1/15/18
to
As for directories, CP/M requires a single directory which is scanned during login to construct the bit allocation table. But there is no special reason why the directory should not be an ordinary file and consequently dynamically extendable. The same goes for the bootstrap files. (Under MSDOS the first 512 byte sector has a bootstrap to load the system files which means that the OS is not restricted to the first tracks. It also means that for non system disks, the first tracks can be used for files. And you don't need hard wired disk tables in the BIOS. Altogether a far better solution.
In my Tiny CP/M I read the DPB from the label entry which must be the first directory entry. Consequently I can recognize non standard disks without any CP/M 2+ support. The label can be constructed in test mode, from an extra internal CCP command, "LABEL". (It would not be possible to load LABEL.COM from the file system because the file system parameters might not yet be known).
I think Garry Kildall did a brilliant job bootstrapping a high quality OS with very limited resources. Although we can improve upon his design today, we do so with the benefit of hindsight, experience and powerful computers. :)
hper...@gmail.com
Jan 15, 2018, 8:50:05 AM1/15/18
to
On Friday, January 12, 2018 at 8:29:18 PM UTC+1, billc...@iscmns.org wrote:
> ...
> ...
> Sequential reading and writing is complicated under CPM and is even worse with extent folding (where a single directory entry / FCB specifies multiple logical extents of 16 kB each). So as I was musing on the problem I thought why not implement a FAT8 file system with up to 256 clusters in a 256 byte FAT? The FAT itself could be contained in 256 bytes of the directory which would require less space because directory entries would only be 16 bytes long (no disk map required). On opening a file the FCB would be filled with a map of 16 cluster numbers just like CPM does but these would be fished from the FAT, not the directory. Obviously opening files would be faster and less disk space would be wasted.
> ...
> I dare say some might prefer DOS FAT12 format. That's understandable but in the third millennium we might prefer software over hardware compatibility. Does anyone still use old FAT12 media?
Isn't that what MSX-DOS does? FAT filesystem + directories (V2 and up) + pretty good CP/M compatibility...
Udo Munk
Jan 15, 2018, 8:56:09 AM1/15/18
to
On Monday, January 15, 2018 at 12:47:14 PM UTC+1, billc...@iscmns.org wrote:
> I think Garry Kildall did a brilliant job bootstrapping a high quality
> OS with very limited resources. Although we can improve upon his design
> today, we do so with the benefit of hindsight, experience and powerful
> computers. :)
That has been done numerous times since 1979, when CP/M realy took of with
> I think Garry Kildall did a brilliant job bootstrapping a high quality
> OS with very limited resources. Although we can improve upon his design
> today, we do so with the benefit of hindsight, experience and powerful
> computers. :)
the 2.x releases. I don't want to discourage you, but I doubt you could try
anything that hasn't been tried already several times, even CP/M 2 with
directories.
Udo Munk
Jan 15, 2018, 10:09:08 AM1/15/18
to
> I think Garry Kildall did a brilliant job bootstrapping a high quality
> OS with very limited resources. Although we can improve upon his design
> today, we do so with the benefit of hindsight, experience and powerful
> computers. :)
BTW, Gary Kildall had unlimited resources. He had direct access to Intel
> OS with very limited resources. Although we can improve upon his design
> today, we do so with the benefit of hindsight, experience and powerful
> computers. :)
technology, even before the microprocessor chips were released, and he
wrote cross-assemblers, compilers and emulations for the not yet released
chips. For that he used mainframe and minicomputer systems, later DRI of
course had their own DEC VAX for cross development.
The brilliant thing was to envision computers for everyone at home. Small
and simple computers with very limited resources, but for that without the
size of a fridge. And these computers needed an OS suitable, because
none of the mainframe and minicomputer OS's could be downsized enough
and still beeing usefull.
gr...@sydneysmith.com
Jan 15, 2018, 4:55:52 PM1/15/18
to
Hi Bill,
It sounds like Tiny CP/M is a lot more than just an idea or it is at least a fairly detailled idea. I'd be interested in having a play with it when it's done.
Whilst many things have already been done, often the new is a spin on something that already existed or a combination of existing ideas. I'm not a history expert so I may have the timing wrong, but even Gary K's BIOS idea could be seen as a variation on a common trailer hitch allowing multiple vehicle types to tow multiple trailor types.
In my experience, a lot of ideas, combinations of ideas or newer implementations of existing ideas; don't pan out. That's the "999 ways to not make a light bulb before finding one that worked" story. The world in the year 3000 is likely to be very different to what we see today. There is plenty left to invent. Will it be due to advances in retro-computing? Probably not - they're opposite directions. But it might. Udo's right in not wanting to discourage you. If Tiny CP/M ends up in the 999 it'll be a lot of work for very little; but it's still your variation on something and, in the very least, it might provide insight for "the next big thing".
The link that Udo provided to RunCPM is a brilliant example. There is a lot of cleverness in what that does:
- a BIOS in 200H (mostly empty space)
- running CP/M (BDOS) in the simulator's address space, by the look of it, instead of in CP/M RAM; and
- some tricks with IO (perhaps at a high address gives monitor commands and lower addresses give normal IO?)
Fascinating.
It'd be a pity if it never got done because it had already been done. The author's take on it is inspiring.
Many projects aren't brilliant. Often they turn up nice, well-thought-out or clever bits. Perhaps they're more of the same. I'm sure I'm guity of some pointless projects; but even I ended up with at least one fairly popular one (unrelated to CP/M and simulators).
Again, I'd love to have a play with Tiny CP/M when it's done.
greg from http://www.sydneysmith.com
It sounds like Tiny CP/M is a lot more than just an idea or it is at least a fairly detailled idea. I'd be interested in having a play with it when it's done.
Whilst many things have already been done, often the new is a spin on something that already existed or a combination of existing ideas. I'm not a history expert so I may have the timing wrong, but even Gary K's BIOS idea could be seen as a variation on a common trailer hitch allowing multiple vehicle types to tow multiple trailor types.
In my experience, a lot of ideas, combinations of ideas or newer implementations of existing ideas; don't pan out. That's the "999 ways to not make a light bulb before finding one that worked" story. The world in the year 3000 is likely to be very different to what we see today. There is plenty left to invent. Will it be due to advances in retro-computing? Probably not - they're opposite directions. But it might. Udo's right in not wanting to discourage you. If Tiny CP/M ends up in the 999 it'll be a lot of work for very little; but it's still your variation on something and, in the very least, it might provide insight for "the next big thing".
The link that Udo provided to RunCPM is a brilliant example. There is a lot of cleverness in what that does:
- a BIOS in 200H (mostly empty space)
- running CP/M (BDOS) in the simulator's address space, by the look of it, instead of in CP/M RAM; and
- some tricks with IO (perhaps at a high address gives monitor commands and lower addresses give normal IO?)
Fascinating.
It'd be a pity if it never got done because it had already been done. The author's take on it is inspiring.
Many projects aren't brilliant. Often they turn up nice, well-thought-out or clever bits. Perhaps they're more of the same. I'm sure I'm guity of some pointless projects; but even I ended up with at least one fairly popular one (unrelated to CP/M and simulators).
Again, I'd love to have a play with Tiny CP/M when it's done.
greg from http://www.sydneysmith.com
Udo Munk
Jan 15, 2018, 5:54:40 PM1/15/18
to
On Monday, January 15, 2018 at 10:55:52 PM UTC+1, gr...@sydneysmith.com wrote:
> Udo's right in not wanting to discourage you.
Coming here asking about implementing things that have been done to no extend
> Udo's right in not wanting to discourage you.
is the wrong attitude. If you want to do something then just do and put the result
online. In worst case no one is interested because enough variations already exist.
There is only one reason why you would do it anyway, and that is learning for your
self. And for that you don't have to ask here if you should do it or not.
For example I don't care much how popular z80pack is in the retro scene or whatever.
I do this stuff because I can and because I like it. If others find it useful for whatever,
great, if not I don't care because at least I'm entertaining my self, by exploiting modern
systems for building such things.
An emulated 8bit microprocessor definitely will not be the next great thing either,
Gary Kildall already wrote an 8080 emulation more than 40 years ago, followed
by numerous others. Useless stuff, but that won't discourage us to do it anyway :)
Floppy Software
Jan 16, 2018, 2:23:37 AM1/16/18
to
"Fascinating.
It'd be a pity if it never got done because it had already been done. The author's take on it is inspiring."
Just read the source and search a bit.
I totally agree in that is a very well done CP/M emulator, but without the Z80 emulation part it will be nothing.
billc...@iscmns.org
Jan 16, 2018, 3:55:09 AM1/16/18
to
hper...@gmail.com
Jan 16, 2018, 4:24:25 AM1/16/18
to
On Monday, January 15, 2018 at 11:54:40 PM UTC+1, Udo Munk wrote:
> Coming here asking about implementing things that have been done to no extend
> is the wrong attitude.
Hmmm.... this is comp.os.cpm! I would say is actually the right place to ask, discuss, criticize or simply talk about anything CP/M-related, and whether it is a new project or not...
> Coming here asking about implementing things that have been done to no extend
> is the wrong attitude.
Udo Munk
Jan 16, 2018, 5:22:01 AM1/16/18
to
On Tuesday, January 16, 2018 at 10:24:25 AM UTC+1, hper...@gmail.com wrote:
> Hmmm.... this is comp.os.cpm! I would say is actually the right place
> to ask, discuss, criticize or simply talk about anything CP/M-related,
> and whether it is a new project or not...
Sure, but CP/M has been re-written so often, these things have been discussed
> Hmmm.... this is comp.os.cpm! I would say is actually the right place
> to ask, discuss, criticize or simply talk about anything CP/M-related,
> and whether it is a new project or not...
and tried and done so many times already...
pbetti
Jan 16, 2018, 5:27:33 AM1/16/18
to
dott.Piergiorgio
Jan 17, 2018, 5:53:19 AM1/17/18
to
Intel lies in an rather intelligent marketing. not only the substantial
access to that part-time worker, Kildall on the design and
pre-production chips, but also the huge discount to that start-up, the
MITS.... together they realised the "computer for (not-so) everyone at
home" prior of the 1977 introduction of the full "computer for everyone"
(the PET/Apple II/TRS-80)
(the "not-so" is because S-100 machines was more for hackers/hobbyists
than general users)
Best regards from Italy,
dott. Piergiorgio.
billc...@iscmns.org
Jan 17, 2018, 12:54:47 PM1/17/18
to
> but CP/M has been re-written so often, these things have been discussed
> and tried and done so many times already...
Unfortunately most of these rewrites were made without specifications - probably by reverse engineering DRI code. Looking at the dubious quality of DRI source I'm not sure if access would have been very helpful! :) Let me give an example of pointless coding which was blindly copied by DRI themselves in CP/M 1 & 2 BDOSes:-
> and tried and done so many times already...
CALL SEARCH(FNM);
IF DCNT = 255 THEN DO;
IF READING THEN RETURN;
CALL MAKE;
END;
ELSE CALL OPEN;
This extract is taken from the 1.4 BDOS (in OPEN$REEL) but similar code exists in at least 4 other versions. My guess is that even DRI didn't really understand what their own code was trying to do. A moment's thought shows that the directory SEARCH is superfluous it would be sufficient simply to try and OPEN (the extent) and MAKE it (if writing) should OPEN fail.
What was never tried as far as I know was any serious attempt at writing an efficient, that is to say fast and compact operating system. This is the objective of Tiny CP/M and as far as size is concerned the following table compares it to the competition:-
CCP BDOS BIOS BDOS+BIOS BDOS+CCP
PCPM 0800 1100 0D00 1E00 1900
ZSDOS / Z80DOS 0800 0E00 0D00 1B00 1600
NOVADOS / QPM 0800 0E00 0D00 1B00 1600
CP/M 2.2 0800 0E00 0D00 1B00 1600
NZCOM 0800 0E00 2500 3300 1600
Banked CP/M 3 0600 1200 1800
CP/M 1.4 0800 0D00 0300 1000 1500
CP/M 1.3 0900 0D00 0300 1100 1600
TINY CDOS (Z80) 0400 0800 0300 0B00 0C00
TINY CP/M (8080) 0500 0700 0300 0A00 0C00
The BIOS sizes above may be misleading as they may not be minimal. I took the values from AltairZ80 disks. The "Tiny" BDOS sizes include the directory buffer and allocation bit maps like CP/M 1 which other systems place in the BIOS.
Floppy Software
Jan 17, 2018, 1:27:29 PM1/17/18
to
Oh, maybe you're right, maybe not, but take into account that Gary Kildall had not any CP/M to look at when he wrote... CP/M.
IMHO it's easier to write something from / than something real.
But writing something from scratch it's not so easy sometimes.
IMHO it's easier to write something from / than something real.
But writing something from scratch it's not so easy sometimes.
Udo Munk
Jan 17, 2018, 3:06:58 PM1/17/18
to
On Wednesday, January 17, 2018 at 11:53:19 AM UTC+1, dott.Piergiorgio wrote:
> Beware, 1974/5 Intel isn't Intel of today. The actual merit of early
> Intel lies in an rather intelligent marketing. not only the substantial
With the 8080 Intel became a leading manufacturer of microprocessors
> Beware, 1974/5 Intel isn't Intel of today. The actual merit of early
> Intel lies in an rather intelligent marketing. not only the substantial
and support chips, which they still are. Nothing has changed, just the
size of the company is much bigger of course.
The marketing idea that no one needs a computer at home and refusing
CP/M was not a good idea. They got into financial troubles and this
likely was one of the reasons for that. Must have been pretty bad, because
if I right now look here at the major german electronic outlets, 60% of the
small barbone systems are from Intel. These are not for the consumer
Joe Sixpack, you have to add components your self to make a working
system from the barebone. They learned something it seems.
> access to that part-time worker, Kildall on the design and
> pre-production chips, but also the huge discount to that start-up, the
> MITS.... together they realised the "computer for (not-so) everyone at
> home" prior of the 1977 introduction of the full "computer for everyone"
> (the PET/Apple II/TRS-80)
>
> (the "not-so" is because S-100 machines was more for hackers/hobbyists
> than general users)
hacker, much to expensive. These were used as development systems,
automation systems, office systems etc. etc.
Fortunately the systems had a flexible design, so that hackers also were
able to get affordable parts, one after another, and build a working system
over the time. I build several ECB bus systems this way, stretching the costs
for a complete system over many month, simply because I was not able
to walk into the local Computerland and buy a complete system more expensive
than a car.
Udo Munk
Jan 17, 2018, 3:23:12 PM1/17/18
to
On Wednesday, January 17, 2018 at 6:54:47 PM UTC+1, billc...@iscmns.org wrote:
> What was never tried as far as I know was any serious attempt at writing an efficient, that
> is to say fast and compact operating system. This is the objective of Tiny CP/M and as far
> as size is concerned the following table compares it to the competition:-
It is called CP/M 3. It is possible to build a system that needs 2KB in common for the
> What was never tried as far as I know was any serious attempt at writing an efficient, that
> is to say fast and compact operating system. This is the objective of Tiny CP/M and as far
> as size is concerned the following table compares it to the competition:-
OS, leaving 62KB for the TPA. Of course requires appropriate hardware like interbank
DMA, so that you can avoid all and any buffers in common, and really moving everything
not absolutely necessary into the bank 0 OS segment. And with enough buffers and a good
BIOS it is very fast, difficult to beat.
Didn't really help because it doesn't matter if you have 50 or 60KB TPA, because the
next class of software requires much more. Overlays helped for a while, but it was
time consuming to modify large software for 16/32 bit CPU's, so that it will run with
overlays on a 8080/Z80. We also build systems with paging MMU's, so the Z80
has 4MB virtual memory mapped as 16 pages a 4KB into the address space, but
the mapping had to be done with software, no page miss traps available, segment
tables not in hardware, must be implemented with software etc etc.
hper...@gmail.com
Jan 18, 2018, 5:16:02 AM1/18/18
to
On Wednesday, January 17, 2018 at 9:23:12 PM UTC+1, Udo Munk wrote:
> On Wednesday, January 17, 2018 at 6:54:47 PM UTC+1, billc...@iscmns.org wrote:
>
> > What was never tried as far as I know was any serious attempt at writing an efficient, that
> > is to say fast and compact operating system. This is the objective of Tiny CP/M and as far
> > as size is concerned the following table compares it to the competition:-
>
> It is called CP/M 3.
CP/M 3 was certainly neither compact nor efficient. It required more complex
> On Wednesday, January 17, 2018 at 6:54:47 PM UTC+1, billc...@iscmns.org wrote:
>
> > What was never tried as far as I know was any serious attempt at writing an efficient, that
> > is to say fast and compact operating system. This is the objective of Tiny CP/M and as far
> > as size is concerned the following table compares it to the competition:-
>
> It is called CP/M 3.
hardware - a machine with at least bank switching or else it would simply
consume too much RAM, leaving less than CP/M 2 did for the applications to run.
The BIOS was also more complex and more difficult to write. CP/M 3 even required
a stripped version of the OS to boot (an OS to load an OS!), so one had to
write two BIOSes... And so on. And it was buggy.
Floppy Software
Jan 18, 2018, 5:50:11 AM1/18/18
to
CP/M 3 runs very nice in my old Amstrad PCW.
billc...@iscmns.org
Jan 18, 2018, 11:49:43 AM1/18/18
to
On Wednesday, 17 January 2018 21:23:12 UTC+1, Udo Munk wrote:
> On Wednesday, January 17, 2018 at 6:54:47 PM UTC+1, billc...@iscmns.org wrote:
>
> What was never tried as far as I know was any serious attempt at writing an efficient, that is to say fast and compact operating system. This is the objective of Tiny CP/M
>
> On Wednesday, January 17, 2018 at 6:54:47 PM UTC+1, billc...@iscmns.org wrote:
>
> What was never tried as far as I know was any serious attempt at writing an efficient, that is to say fast and compact operating system. This is the objective of Tiny CP/M
>
> It is called CP/M 3.
I can't help chuckling at this comment! I am perfectly aware of the dimensions of Banked CP/M. Indeed, I quoted the precise figures in my table. You will note that Tiny CP/M gives a (much) bigger TPA due to the fact that CP/M 3 also requires a bloated BIOS. As for speed, just to reload the CCP, CP/M 3 required 3 or 4 times more disk accesses than previous versions of CP/M. It was never very popular.
> We also build systems with paging MMU's, so the Z80
> has 4MB virtual memory mapped as 16 pages a 4KB into the address space, but
> the mapping had to be done with software, no page miss traps available,
> segment tables not in hardware, must be implemented with software etc etc.
VM paging was quite common on many mini computers in the 80s. However it did not require any extra OS support. Given the speed limitations, I'm not sure if paging on floppies would be very efficient, but if that's the only way to get a vital piece of sophisticated software to run, why not?
> has 4MB virtual memory mapped as 16 pages a 4KB into the address space, but
> the mapping had to be done with software, no page miss traps available,
> segment tables not in hardware, must be implemented with software etc etc.
The vast majority of us had to make do with generic software which required a TPA in which to run. The bigger, the better. That there may have been buffers in some other memory bank or in the BIOS really didn't make any big difference. Having said that, the major effect extra RAM available on say the IBM PC was that developers used high level languages instead of assembler. No surprise that typical applications suddenly became 10 times as big and ten time as slow. It was the beauty, simplicity and efficiency of CP/M which explains why it is so admired 40 years later.
If I were transported back in time to the 70s, it would not be CP/M I would redesign, but the horrible micro-controllers of that era. None of them were designed according to logical criteria (like being suitable for high level languages) mainly because electronic engineers then had very little understanding of software. For them, micro-controllers were just generic devices to substitute other electronics. It took Kildall to show the world that sophisticated systems could be implemented even on lowly micro-controllers!
But in the 80s, a simple but brilliant 8 bit (stack based) instruction set was designed by C.A.R. Hoare and other academics. The team designed the Transputer which evolved into the ST20. If a similar micro had been designed 10 years earlier, it would have taken the industry by storm. The code density is about double that of the Z80!
I still have an 8086 manual dating from 1978. By that time even Intel had learnt that CPUs should be designed according to benchmarks and the 8086 and later 80186 show clear signs of being influenced by high level language considerations. And there was an even greater influence by sales who wanted a design compatible with the primitive 8080 / Z80. So we got stuck with (far too many) 8 bit registers, segmentation, non orthogonal architecture.
Udo Munk
Jan 18, 2018, 4:55:41 PM1/18/18
to
On Thursday, January 18, 2018 at 5:49:43 PM UTC+1, billc...@iscmns.org wrote:
> I can't help chuckling at this comment! I am perfectly aware of the dimensions of
> Banked CP/M. Indeed, I quoted the precise figures in my table. You will note that
> Tiny CP/M gives a (much) bigger TPA due to the fact that CP/M 3 also requires a bloated BIOS.
> As for speed, just to reload the CCP, CP/M 3 required 3 or 4 times more disk accesses than
> previous versions of CP/M. It was never very popular.
Then you have never seen a CP/M 3 system that takes all the advantages they put into the thing.
> I can't help chuckling at this comment! I am perfectly aware of the dimensions of
> Banked CP/M. Indeed, I quoted the precise figures in my table. You will note that
> Tiny CP/M gives a (much) bigger TPA due to the fact that CP/M 3 also requires a bloated BIOS.
> As for speed, just to reload the CCP, CP/M 3 required 3 or 4 times more disk accesses than
> previous versions of CP/M. It was never very popular.
A CP/M with a 60KB TPA was quit common, but if you have memory with interbank DMA
you can get a TPA of 62KB and the OS needs a whooping 2KB. You won't be able to get this
far with a CPM 1/2 rewrite.
The BIOS can be bloated to any extend, because most of it can be in the OS segment outside
of the common memory, won't reduce the TPA any bit.
For directory access CP/M 3 needs zero disk access, if you can provide enough directory buffers,
and that is possible with hard disks, not only some lame floppy disks. For the later one you need
of course a working media change implementation, so that the directory is read ONE time after
a media change.
And you can place the CCP in a memory segment, no more disk access for warm boot at all.
Of course that won't be possible with very basic hardware, but in 1983 hardware was available
to take full advantage of the system.
dxf...@gmail.com
Jan 18, 2018, 5:34:40 PM1/18/18
to
hobbyist I was never much interested in CP/M 3's
special features. More annoying it broke many
programs written for 2.2 particularly those
involving bios disk calls.
Udo Munk
Jan 18, 2018, 5:56:48 PM1/18/18
to
On Thursday, January 18, 2018 at 11:34:40 PM UTC+1, dxf...@gmail.com wrote:
> The Bondwell 14 did that. This said, as a
> hobbyist I was never much interested in CP/M 3's
> special features. More annoying it broke many
> programs written for 2.2 particularly those
> involving bios disk calls.
That was no CP/M software, that was hobby stuff written without reading
> The Bondwell 14 did that. This said, as a
> hobbyist I was never much interested in CP/M 3's
> special features. More annoying it broke many
> programs written for 2.2 particularly those
> involving bios disk calls.
or just ignoring the manuals. DRI clearly wrote don't use BIOS calls in applications,
always use the BDOS, because if not software won't be compatible. Most commercial
software vendors made sure that their software would run on any CP/M or MP/M.
Nothing wrong with exploiting systems as much as one can, but then complaining
that it won't work with later OS releases anymore is a no go ;-) Fix the broken stuff.
dxf...@gmail.com
Jan 18, 2018, 6:07:55 PM1/18/18
to
was *DRI* that made BIOS calls non-portable.
Udo Munk
Jan 18, 2018, 6:17:38 PM1/18/18
to
On Friday, January 19, 2018 at 12:07:55 AM UTC+1, dxf...@gmail.com wrote:
> Not everything could be done with BDOS and it
> was *DRI* that made BIOS calls non-portable.
They clearly said that BIOS calls are not portable, your own fault
> Not everything could be done with BDOS and it
> was *DRI* that made BIOS calls non-portable.
ignoring it. Their fault was that they needed to long for providing
better BDOS's that allowed to do everything.
hper...@gmail.com
Jan 19, 2018, 5:32:52 AM1/19/18
to
On Thursday, January 18, 2018 at 11:56:48 PM UTC+1, Udo Munk wrote:
> On Thursday, January 18, 2018 at 11:34:40 PM UTC+1, dxf...@gmail.com wrote:
>
> > The Bondwell 14 did that. This said, as a
> > hobbyist I was never much interested in CP/M 3's
> > special features. More annoying it broke many
> > programs written for 2.2 particularly those
> > involving bios disk calls.
>
> That was no CP/M software, that was hobby stuff written without reading
> or just ignoring the manuals.
STAT from CP/M 2.2 does not work or does not show correct results, for example, at least not in a banked system. And that is CP/M software, and certainly not hobbyist. The DRI's ISX ISIS emulator can't be made to work either. Etc.
> On Thursday, January 18, 2018 at 11:34:40 PM UTC+1, dxf...@gmail.com wrote:
>
> > The Bondwell 14 did that. This said, as a
> > hobbyist I was never much interested in CP/M 3's
> > special features. More annoying it broke many
> > programs written for 2.2 particularly those
> > involving bios disk calls.
>
> That was no CP/M software, that was hobby stuff written without reading
> or just ignoring the manuals.
CP/M 2.2 did not provide access to everything via its BDOS interface, so programmers had no other choice than to use BIOS calls, in particular for full access to the directory or to the disk as a whole. Imagine writing an 'undelete file' utility using only BDOS calls, or doing a disk surface scan searching for bad blocks.
Direct BIOS calls were also used to perform console I/O to improve performance (e.g. by WordStar, and probably also by WordMaster), especially since the CP/M 2.2 BDOS had a 'quirk' which made e.g. Ctrl/S to become ignored if another character was typed before it during console output.
CP/M 3 removed support for the IOBYTE as well, and changed BDOS functions 7 and 8 to something else, breaking again compatibility. Since device names changed, programs that supported the old style looked awkward (e.g. MS tools).
CP/M 3 tried to bring new functionality without breaking 'too much' compatibility with the old version, and it did indeed very good job. But the incompatibilities hindered its popularity, added to the fact that it was more expensive, required a faster and more expensive machine with much more memory in order to have a decent performance, and that at the end it actually did not make much difference for the common user.
hper...@gmail.com
Jan 19, 2018, 5:43:35 AM1/19/18
to
The problem with CP/M 3 is that in *banked* systems the BIOS jump table was no longer directly accessible. Instead, they added a new function (50) to make direct BIOS calls (clearly they were *not* discouraging the user from calling BIOS functions, they just changed the access method, making it incompatible).
billc...@iscmns.org
Jan 19, 2018, 10:00:30 AM1/19/18
to
Of course it's great if, the CCP can be cached into some RAM bank. But a simpler and faster alternative, one possible with Tiny CP/M, is to put the entire BIOS+BDOS+CCP into ROM. I did a LINK of the system this morning and it totals less than 3 kB of code. So we could imagine for example Tiny CP/M running on a single EZ80 chip today using internal RAM (16 kB) for TPA and a 252 kB fast ROM disk. You wouldn't necessarily need external EPROM / RAM etc.
John Elliott
Jan 19, 2018, 4:08:03 PM1/19/18
to
hper...@gmail.com wrote:
> CP/M 3 even required
> a stripped version of the OS to boot (an OS to load an OS!), so one had to
> write two BIOSes... And so on. And it was buggy.
On this point: It doesn't *require* CPMLDR (there are machines, like the
> CP/M 3 even required
> a stripped version of the OS to boot (an OS to load an OS!), so one had to
> write two BIOSes... And so on. And it was buggy.
Amstrad PCW, that boot just fine without it). Where you need CPMLDR is if
your system's boot ROM is hardcoded to load something the size of CP/M 2.
--
John Elliott
Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show
hper...@gmail.com
Jan 20, 2018, 7:00:15 AM1/20/18
to
On Friday, January 19, 2018 at 10:08:03 PM UTC+1, John Elliott wrote:
> On this point: It doesn't *require* CPMLDR (there are machines, like the
> Amstrad PCW, that boot just fine without it). Where you need CPMLDR is if
> your system's boot ROM is hardcoded to load something the size of CP/M 2.
No, not precisely. Most (all?) machines simply loaded the first sector of the first track into memory and executed it. After all, they were supposed to be able to load OSes other than CP/M.
> On this point: It doesn't *require* CPMLDR (there are machines, like the
> Amstrad PCW, that boot just fine without it). Where you need CPMLDR is if
> your system's boot ROM is hardcoded to load something the size of CP/M 2.
CPMLDR was necessary because the CP/M 3 system image was generally so large that it would no longer fit into the standard 1 or 2 system tracks of the CP/M diskette. Yes, you could modify the disk format to have e.g. 3 boot tracks instead, but that would break compatibility with your existing disks if you were upgrading from 2.2, not to mention reducing the available disk space.
And even then, DRI did not gave you another option. Sure, you could always come up with some other ways of loading CPM3.SYS (after all, the file format is documented) but you were on your own. I don't know the Amstrad, but that's probably what they did (custom boot loader + system image on the boot tracks of the floppy).
dott.Piergiorgio
Jan 20, 2018, 11:15:54 AM1/20/18
to
in late 70s-early 80s was different, the majority of PC/hobbyist
computer was imported from US (in the days of "super-dollar"..) at more
than double the US prices. but even with the doubling of the prices, the
price allows the development of EU automation systems and custom
systems. whose in countries (Italy and Germany) where the small and
mid-scale industries are the majority, was what matters. (I don't hide
that I'm monitoring carefully the high-end 3d Printers/low-end CNC
machines market, where german precision is still well-valued here)
not into delving into political-economical matters, but I find that the
actual free market is the EU one, not the US one, because here the small
industries are more or less healthy.
Udo Munk
Jan 22, 2018, 1:58:33 PM1/22/18
to
On Friday, January 19, 2018 at 11:32:52 AM UTC+1, hper...@gmail.com wrote:
> STAT from CP/M 2.2 does not work or does not show correct results, for example,
> at least not in a banked system. And that is CP/M software, and certainly not hobbyist
>. The DRI's ISX ISIS emulator can't be made to work either. Etc.
Of course won't system tools from one OS not run on another, they need to
> STAT from CP/M 2.2 does not work or does not show correct results, for example,
> at least not in a banked system. And that is CP/M software, and certainly not hobbyist
>. The DRI's ISX ISIS emulator can't be made to work either. Etc.
be rewritten of course. Tried to complain to Apple that an old VAX UNIX ps
command won't work os OSX? Guess not, one won't even bother trying such
things anyway.
The ISX emulation would be difficult to make working under CP/M 3, a complete
rewrite probably is necessary, which no one bothered to do.
> CP/M 2.2 did not provide access to everything via its BDOS interface, so programmers
> had no other choice than to use BIOS calls, in particular for full access to the directory
> or to the disk as a whole. Imagine writing an 'undelete file' utility using only BDOS calls,
> or doing a disk surface scan searching for bad blocks.
some OS code, not using it's application interface. Nothing wrong doing so, but expecting
that such stuff would work after a major release OS update is very questionable.
> Direct BIOS calls were also used to perform console I/O to improve performance
> (e.g. by WordStar, and probably also by WordMaster), especially since the CP/M 2.2
> BDOS had a 'quirk' which made e.g. Ctrl/S to become ignored if another character
> was typed before it during console output.
the few programmer editors that run everywhere, from the ancient IMSAI CP/M 1.3 to
the latest CP/M 3, MP/M and every rewrite of the OS's I tried. Even runs under Cromix,
I like WM better than Cromemcos screen editor.
Udo Munk
Jan 22, 2018, 2:06:57 PM1/22/18
to
On Friday, January 19, 2018 at 11:43:35 AM UTC+1, hper...@gmail.com wrote:
> Can't remember that they ever said that. On the contrary, the BIOS calls were
> standardized and well documented, and they presented a consistent interface
> to the BDOS and applications *independently* of the hardware. That's being
> portable, IMHO.
The only published application interface is the BDOS 5 call. The BIOS is an interface
> Can't remember that they ever said that. On the contrary, the BIOS calls were
> standardized and well documented, and they presented a consistent interface
> to the BDOS and applications *independently* of the hardware. That's being
> portable, IMHO.
for the BDOS, exactly, not an interface for applications.
> The problem with CP/M 3 is that in *banked* systems the BIOS jump table was no longer
> directly accessible. Instead, they added a new function (50) to make direct BIOS calls
> (clearly they were *not* discouraging the user from calling BIOS functions, they just
> changed the access method, making it incompatible).
the BIOS jump vector still is reachable from applications, parts of the BIOS routines
are moved into the OS segment.
The other way around, with CP/M 3 they provided a portable BIOS interface without
the need to jump to some address and make assumptions what the code there might
do.
Udo Munk
Jan 22, 2018, 2:20:37 PM1/22/18
to
On Friday, January 19, 2018 at 4:00:30 PM UTC+1, billc...@iscmns.org wrote:
> Udo by throwing enough sophisticated hardware and software at a problem of
> course you can improve its performance. But the point is that Tiny CP/M can
> provide high performance on generic hardware (e.g. the Intel MDS available in
> the 70s). And yes the CP/M 3 could use banked hardware in 1983, but the
> IBM PC had been announced in 1981 so really the OS was too little too late.
> Yes I know that the IBM PC was slower and its floppies were lower capacity...
No one was throwing hardware at a problem, hardware was slowly (compared to
> Udo by throwing enough sophisticated hardware and software at a problem of
> course you can improve its performance. But the point is that Tiny CP/M can
> provide high performance on generic hardware (e.g. the Intel MDS available in
> the 70s). And yes the CP/M 3 could use banked hardware in 1983, but the
> IBM PC had been announced in 1981 so really the OS was too little too late.
> Yes I know that the IBM PC was slower and its floppies were lower capacity...
nowadays) improving from 1974 to 1983. This improved hardware required new
OS's that can make use of it, CP/M 1/2 won't do anymore.
For the very early systems like Altair, IMSAI, MDS etc. Tiny CP/M really might
be interesting though.
With regards to the IBM PC, both PC/MS-DOS and CP/M-86 were a total disappointment
to me. Both looked like a CP/M 2 clone just for the 8088/86 CPU and haven't had all
the nice improvements from CP/M 3 and MP/M. And that besides the poorly
engineered PC was very slow compared to the Z80 systems available.
> Of course it's great if, the CCP can be cached into some RAM bank. But a simpler and faster
> alternative, one possible with Tiny CP/M, is to put the entire BIOS+BDOS+CCP into ROM.
> I did a LINK of the system this morning and it totals less than 3 kB of code. So we could
> imagine for example Tiny CP/M running on a single EZ80 chip today using internal RAM
> (16 kB) for TPA and a 252 kB fast ROM disk. You wouldn't necessarily need external
> EPROM / RAM etc.
Net Client for diskless systems, they provided CP/M romable versions for handhelds
like from Tandy and who knows what.
Udo Munk
Jan 22, 2018, 2:29:33 PM1/22/18
to
On Thursday, January 18, 2018 at 11:16:02 AM UTC+1, hper...@gmail.com wrote:
> The BIOS was also more complex and more difficult to write. CP/M 3 even required
> a stripped version of the OS to boot (an OS to load an OS!), so one had to
> write two BIOSes... And so on. And it was buggy.
If you want to load any OS from a filesystem and not from some reserved boot tracks,
> The BIOS was also more complex and more difficult to write. CP/M 3 even required
> a stripped version of the OS to boot (an OS to load an OS!), so one had to
> write two BIOSes... And so on. And it was buggy.
you need a stripped OS for this, that understands the filesystem and the load format
of the kernel binary. Pretty cool that one could do this in 1983 already with microcomputers,
usually the technic was used for minis and mainframes at that time. Nowadays it is used
everywhere of course.
A CP/M 3 implementation likely was done on a system already running CP/M 2, that was
a no brained to copy and paste a tested and working BIOS for the loader. A hue advantage
for system implementors, because you got the thing up and running in a short time.
Of course you can use your own boot code, no one forces you to use cpmldr from DRI.
Oh, OS code is buggy, really. With regards to CP/M 3 all the bugs were fixed and nowadays
you have the bug fixed sources available as open source, running on lots of virtual machines.
If it still contains bugs go fix 'em?
Udo Munk
Jan 22, 2018, 2:42:56 PM1/22/18
to
On Saturday, January 20, 2018 at 1:00:15 PM UTC+1, hper...@gmail.com wrote:
> CPMLDR was necessary because the CP/M 3 system image was generally so large
> that it would no longer fit into the standard 1 or 2 system tracks of the CP/M diskette.
> Yes, you could modify the disk format to have e.g. 3 boot tracks instead, but that would
> break compatibility with your existing disks if you were upgrading from 2.2, not to mention
> reducing the available disk space.
Nope. First no one was running 8" SD disk drives anymore in 1983. We kept systems
> CPMLDR was necessary because the CP/M 3 system image was generally so large
> that it would no longer fit into the standard 1 or 2 system tracks of the CP/M diskette.
> Yes, you could modify the disk format to have e.g. 3 boot tracks instead, but that would
> break compatibility with your existing disks if you were upgrading from 2.2, not to mention
> reducing the available disk space.
with one drive for software exchange, but certainly not for booting any OS. The DS/DD
drives provided enough space to keep large OS's on two tracks.
Then of course it is much more comfortable if the OS kernel just is a file on a filesystem.
For loading this you need a boot loader that understands the filesystem, so it is
a stripped down OS. And of course CP/M 3 MP/M and the like are segmented binaries,
you need to properly load the segments where they belong to.
billc...@iscmns.org
Jan 23, 2018, 4:51:05 AM1/23/18
to
On Monday, 22 January 2018 20:20:37 UTC+1, Udo Munk wrote:
> On Friday, January 19, 2018 at 4:00:30 PM UTC+1, billc...@iscmns.org wrote:
> No one was throwing hardware at a problem, hardware was slowly (compared to
> nowadays) improving from 1974 to 1983. This improved hardware required new
> OS's that can make use of it, CP/M 1/2 won't do anymore.
I disagree. Banked hardware had to be designed for CP/M 3. Non banked CP/M 3 on generic systems was a non starter.
> On Friday, January 19, 2018 at 4:00:30 PM UTC+1, billc...@iscmns.org wrote:
> No one was throwing hardware at a problem, hardware was slowly (compared to
> nowadays) improving from 1974 to 1983. This improved hardware required new
> OS's that can make use of it, CP/M 1/2 won't do anymore.
>
> For the very early systems like Altair, IMSAI, MDS etc. Tiny CP/M really might
> be interesting though.
And not only. As I have pointed out, Tiny CP/M beats most banked CP/M 3 systems in terms of TPA size. Though of course Z80MU can offer even larger TPA.
> For the very early systems like Altair, IMSAI, MDS etc. Tiny CP/M really might
> be interesting though.
>
> With regards to the IBM PC, both PC/MS-DOS and CP/M-86 were a total disappointment
> to me.
I agree 100%.
> With regards to the IBM PC, both PC/MS-DOS and CP/M-86 were a total disappointment
> to me.
>
So we could
> > imagine for example Tiny CP/M running on a single EZ80 chip today using internal RAM
> > (16 kB) for TPA and a 252 kB fast ROM disk. You wouldn't necessarily need external
> > EPROM / RAM etc.
>
> All done numerous times.
I think you may be mistaken. All the CP/M designs on the EZ80 I have seen use external RAM and other chips.
So we could
> > imagine for example Tiny CP/M running on a single EZ80 chip today using internal RAM
> > (16 kB) for TPA and a 252 kB fast ROM disk. You wouldn't necessarily need external
> > EPROM / RAM etc.
>
> All done numerous times.
>DRI had a romable version of Personal CP/M-80,
Indeed but if you look at the statistics I cited you'll see that PCP/M appears to have a memory foot print (in ROM) of over 8 kB compared to Tiny CP/M's < 3 Kb!
hper...@gmail.com
Jan 23, 2018, 7:35:16 AM1/23/18
to
On Monday, January 22, 2018 at 7:58:33 PM UTC+1, Udo Munk wrote:
> > CP/M 2.2 did not provide access to everything via its BDOS interface, so programmers
> > had no other choice than to use BIOS calls, in particular for full access to the directory
> > or to the disk as a whole. Imagine writing an 'undelete file' utility using only BDOS calls,
> > or doing a disk surface scan searching for bad blocks.
>
> Sure, but that won't change the fact that you are jumping right into the middle of
> some OS code, not using it's application interface.
No. BIOS is not the "middle of some OS code". It was a standard (for CP/M), published (by DRI) interface. As were the methods to access it!
> > CP/M 2.2 did not provide access to everything via its BDOS interface, so programmers
> > had no other choice than to use BIOS calls, in particular for full access to the directory
> > or to the disk as a whole. Imagine writing an 'undelete file' utility using only BDOS calls,
> > or doing a disk surface scan searching for bad blocks.
>
> Sure, but that won't change the fact that you are jumping right into the middle of
> some OS code, not using it's application interface.
> Nothing wrong doing so, but expecting that such stuff would work after a major release OS update is very questionable.
The problem is, it was *supossed* to be fully compatible. But it wasn't, not even at BDOS level.
hper...@gmail.com
Jan 23, 2018, 8:00:28 AM1/23/18
to
On Monday, January 22, 2018 at 8:29:33 PM UTC+1, Udo Munk wrote:
> Oh, OS code is buggy, really. With regards to CP/M 3 all the bugs were fixed and nowadays
> you have the bug fixed sources available as open source, running on lots of virtual machines.
> If it still contains bugs go fix 'em?
I actually said it *was* buggy, at least when the first version (3.0) was released. And that gave it some bad reputation. In addition to compatibility problems, in certain cases the system would freeze without apparent reason and even some GENCPM options would cause disk data corruption (IIRC it was the double-bit alloc map) and I was bitten by that. Media change detection was also unreliable.
> Oh, OS code is buggy, really. With regards to CP/M 3 all the bugs were fixed and nowadays
> you have the bug fixed sources available as open source, running on lots of virtual machines.
> If it still contains bugs go fix 'em?
And there were things like the SAVE command that worked backwards: if you forgot to call it before executing a program, then you had no way to recover your work if the program exited unexpectedly.
It was discouraging; I never had such experience with the 2.2 version. Most bugs were fixed I believe in 3.1 except IIRC the double-bit thing, which DRI recommended not to use. I have it running on my P112 and seems fine, but since then I never trusted it 100% again.
IMHO, the 2.2 version was the best in terms of quality, efficiency and reliability.
hper...@gmail.com
Jan 23, 2018, 9:48:37 AM1/23/18
to
On Monday, January 22, 2018 at 8:29:33 PM UTC+1, Udo Munk wrote:
> If you want to load any OS from a filesystem and not from some reserved boot tracks,
> you need a stripped OS for this, that understands the filesystem and the load format
> of the kernel binary.
Not necessarily, and as a matter of fact most (if not all) OSes of the time used a different method. There are better ways, e.g. look what Linux LILO did, or how UZI180 boots from a floppy using a loader that fits on boot block 0.
> If you want to load any OS from a filesystem and not from some reserved boot tracks,
> you need a stripped OS for this, that understands the filesystem and the load format
> of the kernel binary.
The discussion here was about efficiency. The CP/M 3 method was more of a quick-n-dirty solution than anything else, and certainly not efficient in terms of disk access, memory used and CPU time.
John Elliott
Jan 23, 2018, 3:08:03 PM1/23/18
to
hper...@gmail.com wrote:
> And even then, DRI did not gave you another option. Sure, you could always
> come up with some other ways of loading CPM3.SYS (after all, the file
> format is documented) but you were on your own. I don't know the Amstrad,
> but that's probably what they did (custom boot loader + system image on
> the boot tracks of the floppy).
The Amstrad has a 512-byte bootloader in the first sector of the floppy,
> And even then, DRI did not gave you another option. Sure, you could always
> come up with some other ways of loading CPM3.SYS (after all, the file
> format is documented) but you were on your own. I don't know the Amstrad,
> but that's probably what they did (custom boot loader + system image on
> the boot tracks of the floppy).
that understands enough of the CP/M filesystem to load the boot file
(JxxCPM3.EMS) into RAM starting at 0. That file contains the data from
CPM3.SYS and CCP.COM, together with a loader that relocates everything to
the correct place in memory.
Udo Munk
Jan 23, 2018, 3:39:14 PM1/23/18
to
On Tuesday, January 23, 2018 at 10:51:05 AM UTC+1, billc...@iscmns.org wrote:
> On Monday, 22 January 2018 20:20:37 UTC+1, Udo Munk wrote:
> > No one was throwing hardware at a problem, hardware was slowly (compared to
> > nowadays) improving from 1974 to 1983. This improved hardware required new
> > OS's that can make use of it, CP/M 1/2 won't do anymore.
> I disagree. Banked hardware had to be designed for CP/M 3. Non banked CP/M 3 on generic
> systems was a non starter.
Nope, way before CP/M 3 existed banked hardware was in use. Even IMSAI already
> On Monday, 22 January 2018 20:20:37 UTC+1, Udo Munk wrote:
> > No one was throwing hardware at a problem, hardware was slowly (compared to
> > nowadays) improving from 1974 to 1983. This improved hardware required new
> > OS's that can make use of it, CP/M 1/2 won't do anymore.
> I disagree. Banked hardware had to be designed for CP/M 3. Non banked CP/M 3 on generic
> systems was a non starter.
started with this in the 70th. This kind of banked memory came from minicomputers.
And before CP/M 3 became available all one could do with CP/M 2 was using a RAM
disk to speed up compilers and such. CP/M 3 just made the banked memory useful,
with enough disk buffers compilers ran much faster, because disk reads were reduced,
and that without the need to configure the RAM disk and copy software onto it at
boot time.
Udo Munk
Jan 23, 2018, 3:54:39 PM1/23/18
to
On Tuesday, January 23, 2018 at 1:35:16 PM UTC+1, hper...@gmail.com wrote:
> No. BIOS is not the "middle of some OS code". It was a standard (for CP/M), published (by DRI)
> interface. As were the methods to access it!
Sigh. See, also CP/M already was a layered software stack, you'll even find pictures of it.
> No. BIOS is not the "middle of some OS code". It was a standard (for CP/M), published (by DRI)
> interface. As were the methods to access it!
In such a layer the outermost layer communicates with the next inner layer, which then
communicates to the next inner layer and so on. Very basic OS stuff. If you jump from
the outermost layer into some more inwards, over jumping the layers in between, you
are just jumping into the middle of some OS code.
The well documented BIOS was intended for system programmers for porting the OS to
new hardware, is was not intended for abusing it by jumping right into the middle of some
code. Doing this also didn't work with many of the CP/M rewrites and of course not
with MP/M, Cromix, etc. etc.
> I guess we could apply the same reasoning to the BDOS as well. Why any application should
> be expected to work after a major OS update?
specific software layer.
> The problem is, it was *supossed* to be fully compatible. But it wasn't, not even at BDOS level.
like. Just runs, most stuff not running was amateur software written with this attitude that
one can jump into the middle of some OS code and don't have to use the API.
Udo Munk
Jan 23, 2018, 4:09:07 PM1/23/18
to
On Tuesday, January 23, 2018 at 2:00:28 PM UTC+1, hper...@gmail.com wrote:
> I actually said it *was* buggy, at least when the first version (3.0) was released.
> And that gave it some bad reputation. In addition to compatibility problems, in
> certain cases the system would freeze without apparent reason and even some
> GENCPM options would cause disk data corruption (IIRC it was the double-bit alloc
> map) and I was bitten by that. Media change detection was also unreliable.
This is not correct. At that time I was working with some guys from a company which
> I actually said it *was* buggy, at least when the first version (3.0) was released.
> And that gave it some bad reputation. In addition to compatibility problems, in
> certain cases the system would freeze without apparent reason and even some
> GENCPM options would cause disk data corruption (IIRC it was the double-bit alloc
> map) and I was bitten by that. Media change detection was also unreliable.
was a DRI source licensee. They gave me CP/M 3.0 for trying it out with the clear
directions not usable for production because too many bugs, and 3.1 would become
available in 2-3 month. 3.0 was beta test software for system builders, that was not
intended for end users. There also was no bad reputation at all because it was known
that 3.0 is not the final but a test release.
Media change detection was working reliable if implemented correctly. This was difficult
and dependent on whatever a disk drive/controller combination was able to signal.
There probably were quite some not reliable working implementations, mine was
working.
> I have it running on my P112 and seems fine, but since then I never trusted it 100% again.
be trusted.
Udo Munk
Jan 23, 2018, 4:22:36 PM1/23/18
to
On Tuesday, January 23, 2018 at 3:48:37 PM UTC+1, hper...@gmail.com wrote:
> Not necessarily, and as a matter of fact most (if not all) OSes of the time used a different method.
> There are better ways, e.g. look what Linux LILO did, or how UZI180 boots from a floppy using a loader
> that fits on boot block 0.
LILO is very limited, that is why almost no one uses it, most installations use grub.
> Not necessarily, and as a matter of fact most (if not all) OSes of the time used a different method.
> There are better ways, e.g. look what Linux LILO did, or how UZI180 boots from a floppy using a loader
> that fits on boot block 0.
No idea what UZI does, for FUZIX Alan kept it simple for now, the OS kernel
is dumped on reserved space on disks, the old and easy way, inflexible of course.
If the kernel grows in size you can't dump it onto an existing disk that also includes
a filesystem anymore. With the kernel as a file in the filesystem you can keep more
then one kernel with any size of course.
hper...@gmail.com
Jan 25, 2018, 4:12:15 AM1/25/18
to
On Tuesday, January 23, 2018 at 10:09:07 PM UTC+1, Udo Munk wrote:
> On Tuesday, January 23, 2018 at 2:00:28 PM UTC+1, hper...@gmail.com wrote:
>
> > I actually said it *was* buggy, at least when the first version (3.0) was released.
> > And that gave it some bad reputation. In addition to compatibility problems, in
> > certain cases the system would freeze without apparent reason and even some
> > GENCPM options would cause disk data corruption (IIRC it was the double-bit alloc
> > map) and I was bitten by that. Media change detection was also unreliable.
>
> This is not correct. At that time I was working with some guys from a company which
> was a DRI source licensee. They gave me CP/M 3.0 for trying it out with the clear
> directions not usable for production because too many bugs
Maybe in Germany it was different. When we got the 3.0 version (end of 1983?) there was no mention whatsoever about bugs or that it was a beta version. I remember that at the time CP/M 3 got some bad press, so we obviously were not the only ones. Patches arrived as late as in 1984; but by that time we had already ditched it in favor of MP/M-II, which was more suitable for our needs and worked rock solid. Also, we were switching to PCs.
> On Tuesday, January 23, 2018 at 2:00:28 PM UTC+1, hper...@gmail.com wrote:
>
> > I actually said it *was* buggy, at least when the first version (3.0) was released.
> > And that gave it some bad reputation. In addition to compatibility problems, in
> > certain cases the system would freeze without apparent reason and even some
> > GENCPM options would cause disk data corruption (IIRC it was the double-bit alloc
> > map) and I was bitten by that. Media change detection was also unreliable.
>
> This is not correct. At that time I was working with some guys from a company which
> was a DRI source licensee. They gave me CP/M 3.0 for trying it out with the clear
> directions not usable for production because too many bugs
One major disappointment with CP/M 3 was that, regardless of the fact that it was basically designed for machines with more than 64K of memory, it did not provide any functions for the applications to use the extra memory - it just provided a little bit more TPA, that's it. Things like RSXs were loaded on the application bank, thus reducing the available TPA. Extra memory was used just for buffers and more buffers which, with the introduction of the faster hard disks, were kind of superfluous anyway.
> Media change detection was working reliable if implemented correctly. This was difficult
> and dependent on whatever a disk drive/controller combination was able to signal.
hper...@gmail.com
Jan 25, 2018, 4:42:23 AM1/25/18
to
On Tuesday, January 23, 2018 at 9:54:39 PM UTC+1, Udo Munk wrote:
> Sigh. See, also CP/M already was a layered software stack, you'll even find pictures of it.
> In such a layer the outermost layer communicates with the next inner layer, which then
> communicates to the next inner layer and so on. Very basic OS stuff. If you jump from
> the outermost layer into some more inwards, over jumping the layers in between, you
> are just jumping into the middle of some OS code.
Sorry, but that's only your point of view, and fortunately not shared by many good programmers. The fact that an OS is layered does not mean that you must use exclusively the outer layer. If a service is not provided by the outermost layer of the OS, then you go to an inner layer, and so on. That's the ways things were done then, and even today.
> Sigh. See, also CP/M already was a layered software stack, you'll even find pictures of it.
> In such a layer the outermost layer communicates with the next inner layer, which then
> communicates to the next inner layer and so on. Very basic OS stuff. If you jump from
> the outermost layer into some more inwards, over jumping the layers in between, you
> are just jumping into the middle of some OS code.
> Try it sometime with software like office applications, language compilers, databases and the
> like. Just runs, most stuff not running was amateur software written with this attitude that
> one can jump into the middle of some OS code and don't have to use the API.
bruce.m...@gmail.com
Nov 14, 2019, 11:39:21 AM11/14/19
to
On Tuesday, January 23, 2018 at 5:51:05 PM UTC+8, billc...@iscmns.org wrote:
> And not only. As I have pointed out, Tiny CP/M beats most banked CP/M 3 systems in terms of TPA size. Though of course Z80MU can offer even larger TPA.
> And not only. As I have pointed out, Tiny CP/M beats most banked CP/M 3 systems in terms of TPA size. Though of course Z80MU can offer even larger TPA.
> > > So we could
> > > imagine for example Tiny CP/M running on a single EZ80 chip today using internal RAM
> > > (16 kB) for TPA and a 252 kB fast ROM disk. You wouldn't necessarily need external
> > > EPROM / RAM etc.
> >
> > All done numerous times.
> I think you may be mistaken. All the CP/M designs on the EZ80 I have seen use external RAM and other chips.
If an ez80 was put on an expansion board for David Murray's CX16 project ([cf. https://www.c64-wiki.com/wiki/Commander_X16 ]), I should like external RAM, even if just used as a RAM disk, but even though the C128 CP/M was CP/M 3.1, a non-banking CP/M would be fine for a lot of the uses of the resources of an ez80, including all of the support for accessing modern serial-interface (SPI and I2C) chips.
> > > imagine for example Tiny CP/M running on a single EZ80 chip today using internal RAM
> > > (16 kB) for TPA and a 252 kB fast ROM disk. You wouldn't necessarily need external
> > > EPROM / RAM etc.
> >
> > All done numerous times.
> I think you may be mistaken. All the CP/M designs on the EZ80 I have seen use external RAM and other chips.
Also, would Tiny CPM be able to put a CPM of some sort in a RC2014 Micro, or is it's memory map not compatible? ([cf. https://rc2014.co.uk/modules/rc2014-micro/ ])
I also would be cursiou
Bill Collis
Jun 28, 2020, 11:03:46 AM6/28/20
to
> Also, would Tiny CPM be able to put a CPM of some sort in a RC2014 Micro, or is it's memory map not compatible? ([cf. https://rc2014.co.uk/modules/rc2014-micro/ ])
>
1) 8080 Tiny CP/M
2) Z80 Tiny CP/M
3) Z80 Tiny CDOS (Cromemco like)
All these are CP/M 1 compatible but add some extra CP/M 2 features 2 so they work with BIOS's made for either (e.g. deblocking support). Curiously the CDOS version is the same size as CP/M! The extra CDOS functionality comes at no cost.
I have configured the system build (of CCP, BDOS, BIOS) to make a ROM version which would easily fit in 4k bytes, but this is not tested yet. The normal RAM based version is a bit smaller because initialization code can be overwritten and reused. (DRI did not do this).
This is the memory map displayed on a Cold Boot:-
BIOS FC00 to FE9B for ALTAIR 8800 and CP/M 1
CDOS F406 to FBF0 CP/M version 2.1 CDOS 2.35
CCP EF00 to F3FB
Stack F01C and TPA (overlapping CCP)
There are probably a few bugs so I'd appreciate any testing. I could possibly supply a self relocating version which automatically copies itself over your CCP and BDOS without any configuration.
My next sub-project will be to allow loading of compressed .COM programs. The CCP would expand the code in the TPA resulting in faster loading and more disk space. Maybe I have too many memories of frustration at not being able to fit all my files onto an old floppy. But I imagine this issue remains with ROM / RAM disks too.
Enrico Lazzerini
Sep 18, 2020, 12:49:36 PM9/18/20
to
I apologize if I go a little off topic in which case please cancel this my post.
Beautiful this post! I am not as skilled as all you are. I can barely understand the topic which is very interesting because it goes beyond thinking about the characteristics of the various platforms and instead highlighting the problems to enter into their merits.
What you highlight is so obvious to me:
I have a Xerox 820-1 board with firmware on ROM 2732 which is copied to the startup in RAM at address F000H. It had a 1771 FDC which I replaced with a SWP card with FD8876. It charges its special CP / M to allow for the double density that FDC 1771 did not allow. The SWP software loads its CBIOS into memory, then replaces the firmware in RAM at F000H with its own reading from the zero track (26x128bytes) and then switches the FDC to Double Density mode (16x512bytes) and loads the CCP and BDOS. Finally finish by configuring the rest of the disk in 9x1024bytes.
To create the right software, it was essential to leave the standard 26x128 zero track while track 1 had to increase the density and length of sectors to contain it. Furthermore, the way to increase the disk capacity had been solved by the card and by the SWP software (75trksx9sectx1024bytes) but the problem of access to disk change remained and it is essential to perform a crtl + c in case of disk change on drive B, while it is good that the SWP CP / M software remains on the A disk.
Then I have a board clone of the original Ferguson Bigboard to which only the FDC 1797 was added instead of the 1771. The firmware resides in two 2716 eproms and at the time of startup a part, containing the commands available at the ROM level, remains mapped and accessible via a switch while the other is located at address F800H. The disk access routines use 4 memory locations in which they store the disk type (faces, densities, type 5"/8"), the last track, the last sector of the track. All they are used to decode the disc type. By default the drive is seen as IBM3740 (SSSD 26x128bytes) and it is possible to load the CP / M of a Ferguson Big board with FD1771 with modified CBIOS addresses (they pointed to F000H) pointing to the firmware entry points at F800H. The machine, whose CP / M has been lost, had special DISKCONF.com command that allowed to map up to 4 drive units each characterized by using 4 memory locations in which they store the disk type (Faces, densities, 5/8 ") , the last track, the last sector of the track. The setting mechanism of the FDC 1797 uses two bits of the system PIO to drive the DDEN and the MINI of the FDC 1797 and 9229B (external data separator).
In this second board I was trying to find a way to create a new dual density CP / M system disk and not being an assembler programmer I found myself in trouble.
Would you like to give me some solution that allows me to take into account the observations you made in this post?
Thank you
Beautiful this post! I am not as skilled as all you are. I can barely understand the topic which is very interesting because it goes beyond thinking about the characteristics of the various platforms and instead highlighting the problems to enter into their merits.
What you highlight is so obvious to me:
I have a Xerox 820-1 board with firmware on ROM 2732 which is copied to the startup in RAM at address F000H. It had a 1771 FDC which I replaced with a SWP card with FD8876. It charges its special CP / M to allow for the double density that FDC 1771 did not allow. The SWP software loads its CBIOS into memory, then replaces the firmware in RAM at F000H with its own reading from the zero track (26x128bytes) and then switches the FDC to Double Density mode (16x512bytes) and loads the CCP and BDOS. Finally finish by configuring the rest of the disk in 9x1024bytes.
To create the right software, it was essential to leave the standard 26x128 zero track while track 1 had to increase the density and length of sectors to contain it. Furthermore, the way to increase the disk capacity had been solved by the card and by the SWP software (75trksx9sectx1024bytes) but the problem of access to disk change remained and it is essential to perform a crtl + c in case of disk change on drive B, while it is good that the SWP CP / M software remains on the A disk.
Then I have a board clone of the original Ferguson Bigboard to which only the FDC 1797 was added instead of the 1771. The firmware resides in two 2716 eproms and at the time of startup a part, containing the commands available at the ROM level, remains mapped and accessible via a switch while the other is located at address F800H. The disk access routines use 4 memory locations in which they store the disk type (faces, densities, type 5"/8"), the last track, the last sector of the track. All they are used to decode the disc type. By default the drive is seen as IBM3740 (SSSD 26x128bytes) and it is possible to load the CP / M of a Ferguson Big board with FD1771 with modified CBIOS addresses (they pointed to F000H) pointing to the firmware entry points at F800H. The machine, whose CP / M has been lost, had special DISKCONF.com command that allowed to map up to 4 drive units each characterized by using 4 memory locations in which they store the disk type (Faces, densities, 5/8 ") , the last track, the last sector of the track. The setting mechanism of the FDC 1797 uses two bits of the system PIO to drive the DDEN and the MINI of the FDC 1797 and 9229B (external data separator).
In this second board I was trying to find a way to create a new dual density CP / M system disk and not being an assembler programmer I found myself in trouble.
Would you like to give me some solution that allows me to take into account the observations you made in this post?
Thank you
wutzi...@gmail.com
Sep 18, 2020, 8:09:41 PM9/18/20
to
Hi Bill C,
Is your Tiny CP/M available to use? I have a few eZ80 designs that I would like to try it on.
I have eZ80F91 based hardware, 128KB ram, MicroSD and CompactFlash storage and use the ZDSII tools.
Thank you
Is your Tiny CP/M available to use? I have a few eZ80 designs that I would like to try it on.
I have eZ80F91 based hardware, 128KB ram, MicroSD and CompactFlash storage and use the ZDSII tools.
Thank you
Bill Collis
Sep 19, 2020, 1:29:12 PM9/19/20
to
A major drawback is that the file system is based on CP/M 1 so it will only accept disks with 255 blocks and no more than 8 drives. This means that it will work with tiny BIOSes (maybe 512 bytes?). However it will work with CP/M 2 BIOS too. I assume the console device is NOT a CP/M 2 compatible.
Do you have source code for your BIOS?
I'm quite busy until the end of the month on another project but I will answer any questions.
Bill Collis
Sep 19, 2020, 1:39:03 PM9/19/20
to
Regarding disk changes, Tiny CPM automatically logs out all disks when a new command is typed in at the CCP level. So you will not require CTRL-C. It also logs a disk in during any directory access with one directory scan rather than two. I don't understand why DRI never did this.
Enrico Lazzerini
Sep 19, 2020, 3:50:58 PM9/19/20
to
The hardware problems identified above should be isolated in the BIOS. Do you have a BIOS listing in the documentation for your hardware? Is your BIOS in the EPROM 2716?
While I have the BIOS source listings of the Ferguson Bigboard1 on eprom 2732 with FDC 1771, I do not have the BIOS sources of the other Ferguson Bigboard1 board in 2x2716 eprom with FDC1797. However, I read the two 2716 eproms and tried my best to disassemble the content which is largely identical to the source BIOS of the card with FDC1771.
In any case, I have the description of the functionality of each entry point of the bios of both boards.
Greg Holdren
Sep 19, 2020, 7:12:10 PM9/19/20
to
Bill,
Where can Tiny CP/M be downloaded from? I did a quick search but failed to find anything.
Thanks,
Greg
Bill Collis
Sep 20, 2020, 2:27:04 AM9/20/20
to
On Sunday, 20 September 2020 at 01:12:10 UTC+2, greg.h...@gmail.com wrote:
> Bill,
>
> Where can Tiny CP/M be downloaded from? I did a quick search but failed to find anything.
>
> Thanks,
> Greg
I have not published it. I can give you sources and build scripts for running it on AltairSimh next month. Write to me personally.
> Bill,
>
> Where can Tiny CP/M be downloaded from? I did a quick search but failed to find anything.
>
> Thanks,
> Greg
0 new messages