CP/M-86 1.1 tinkering...

[Jared Falvo]

I'm running CP/M-86 1.1 on PCEm. And, try as I might, I cannot format a disk image any larger than 360K, even though the disk image may be larger (720K, in this case). I'm interested in trying to "modernize" (optimize for the 8086 processor (to start with), remove outdated reference like Punch Cards and such from the source code, and make it address (format) 720K and 1.44Mb disk images for use).

I'm currently running Tandy 1000SL/2 emulation in PCEm. Supposedly it supports 720K disks, but that doesn't seem to matter to CP/M-86 1.1. DSKMAINT refuses to format any higher than 360K. Is CP/M-86 1.1 or DSKMAINT the limiting factor here?

I have all three source code files (BIOS/CBIOS.A86, CCP.A86, and BDOS.A86) which comprise CPM.SYS, once assembled, PIP'd together, turned into a CMD file, and then renamed as CPM.SYS.

Really new to CP/M, here... but I love to delve into different things, just for the fun of it. At 50, I'm probably a bit long in the tooth to start learning 8086 assembly language and such, but I'm willing to give it a shot anyways. Anything to keep the ol' brain cells going... :-D

[dott.Piergiorgio]

well, I don't recommend 80x86 assembler for exercising wetware... better
68K, 65xx and 8080/z80

OTOH, there's what I call "the pokemon cross-assembler":

> http://john.ccac.rwth-aachen.de:8000/as/

there's many CPU architectures around...

Best regards from Italy,
dott. Piergiorgio.

[Randy McLaughlin]

It is the format program (dskmaint).


Randy

[Jared Falvo]

On Friday, July 26, 2019 at 1:40:28 AM UTC-7, Randy McLaughlin wrote:
> It is the format program (dskmaint).
>
>
> Randy

Anyone have the source code to dskmaint, then?

[Udo Munk]

Someone already build a CP/M-86 1.1 for 1.44MB floppy disks, you can find it here:

https://virtuallyfun.com/wordpress/2010/06/14/cpm86/

I run this under Virtualbox, might also work on PCem with a properly configured system.

[Randy McLaughlin]

Probably easier to just modify the drdos format utility:

https://sourceforge.net/projects/archiveos/files/d/drdos/d110721b.zip/download

Basically should be able to change calls to dos to calls to CP/M I haven't looked to see how hard it would be.

It should be a good place to modify formats for different drives both hard drives and diskettes.

Please note any format you create with this source would need to be supported by the BIOS to use.


Randy

[Udo Munk]

Or use cpmtools, diskdef is:

# CP/M 86 on 1.44MB floppies
diskdef cpm86-144feat
seclen 512
tracks 160
sectrk 18
blocksize 4096
maxdir 256
skew 1
boottrk 2
os 3
libdsk:format ibm1440
end

[Jared Falvo]

Ok, I'm having trouble making use of larger disk images, but... I want to modify CP/M-86 1.1 to natively format those sized disk images. I dont want to just "work around" the existing problem, I want to remove the problem. Even Freek's solution is a work-around, so far as I can tell...

And that's just the first of a few things I want to change.

[Randy McLaughlin]

I am not sure you understand how CP/M handles disk formats.

CP/M's BIOS has to know the format before it can be used. You must modify the CP/M BIOS to handle the format.

Once the CP/M BIOS is ready you then have a separate program to create the media (dskmaint or whatever formatting utility you want).

There are modified CP/M's that handle a variety of 3.5" media for CP/M 86v1.1. 1.44mb is a common format. People just formatted the disks from DOS.

To my knowledge the source for dskmaint is lost. There is a formatting program called fdformat (not to be confused with the Linux version) for DOS, it is written in turbo-pascal and may be a project that could be converted to CP/M.

For PC's low level disk utilities usually use ROM BIOS calls to do the work so it only needs relatively simple front ends to call the ROM. The programs can be written in high level languages.

But no matter how you format the disks the CP/M BIOS has to be modified to handle the desired format.


Randy

[Jared Falvo]

There is the BIOS (CMOS) of the computer and then the BIOS of CP/M-86 1.1. Does the BIOS of CP/M-86 1.1 (which is part of CPM.SYS) replace (or make unecessary) the BIOS (CMOS) of the computer? If, for example, in the Tandy 1000SL/2 emulation in PCEm, it supports 720K floppies. I assume that means it's ROM(s) know how to identify/support those drives. Do you then have to be able to call to that ROM(s)to identify/format a 720K disk image or can you simply duplicate that info inside of the BIOS of CPM.SYS? How would one best go about accomplishing that?

There is also an open source ROM called XTIDE. Does that support floppies higher than 360K? Where would I put it in PCEm (in the /ROMS directory)? Or is that outside the scope of this group?

[Randy McLaughlin]

Just like MSDOS CP/M uses the ROM BIOS extensively. My post denotes both as separate even though I never pointed out the CP/M BIOS requires the ROM BIOS.

I always thought limiting RAM to 640K (originally limited to 512K) was a huge mistake. Having 384K video RAM and ROM BIOS area was just plain stupid, they should have been bank swapped with 1mb 8088 space available to the user. Reminds me of Processor Tech's SOL-20, can we not ever learn from history?


Randy

[Jared Falvo]

The ROM BIOS, being the BIOS (CMOS) of the computer, correct? Like AMI, Phoenix, etc.) Because there is a ROM source code file for CP/M-86 (or some variant) that (I think) serves a similar purpose.

So, how exactly does this whole thing work? For example, on an XT. The BIOS (CMOS) boots the computer and then hands the rest of the booting to CP/M-86? But CP/M-86 has it's own BIOS apart from the computer's BIOS? There's also a Loader or something that I think is involved. So is the order:

XT BIOS (on motherboard; boots computer) -> CP/M-86 Loader (loads CPM.SYS; is it inside CPM.SYS or outside?) -> BIOS (inside CPM.SYS) -> BDOS (inside CPM.SYS) -> CCP (inside CPM.SYS)?

I know that if CPM.SYS is not the FIRST file you put on the disk image, it won't boot. Gives a "CPM.SYS not found" error message, even though the "Loading CPM.SYS..." message appears. So, that must be the Loader (which expects CPM.SYS to be the first file on the disk, and throws a hissy-fit if it isn't first in line... boo-hoo!), but it must be inside CPM.SYS, because the only file I copied over was CPM.SYS (first time, copied it after several other files (mistake!) and next time, made it the first file I copied over (correct!).

But everything I read said that CPM.SYS consisted of just THREE files (BIOS, BDOS, and CCP), so under what condition would you NOT need to have the Loader as part of CPM.SYS?

[Randy McLaughlin]

The ROM BIOS is not the CMOS.

The CMOS usually refers to the battery backed up clock that has a CMOS RAM that saves all the system settings in a PC-AT or higher. The system settings includes how many floppy drives and what type they are, How many hard drives and what type, memory timing etc. Each motherboard can use the CMOS RAM as they wish to store this information and there is no real standard to this date.

The original ROM BIOS's for the PC and the PC-XT had no CMOS their settings were by dip switches and had no battery backed up clock. Battery backed up Clocks could be added to these early machines but required addon software to support them.

The ROM BIOS like a Z80 based machine starts a boot process by reading the boot sector and jumping to the code it contains. The rest of the booting is up to the code in that sector which can read the rest of the boot either directly or through the ROM BIOS.

The ROM BIOS has lots of routines any OS can use. Console out has code built into the standard ROM for CGA or MDA display, for EGA, VGA, etc they have their own ROM BIOS's that hook into the main ROM BIOS so all calls to console output work seamlessly. The same can go for hard drive controllers, the original PC and PC-XT ROM BIOS has no hard drive code at all and their hard drive controllers are required to have their own ROM BIOS's that hook into the floppy routines in the original ROM BIOS.

As for the CPM.SYS it requires a loader period. The sys file format has code telling where and how CPM is loaded into RAM. The CP/M loader has a smaller version of the CP/M BIOS and BDOS to allow it to do this. The loader is separate for the simple reason that it can fit in the same reserved space allocated to the CP/M 2.2 (2 tracks of 26 128 byte sectors).

This boot track limitation is duplicated in many Digital Research OS's like CP/M 3, MP/M etc.

Dskmaint puts the loader onto the disks it formats but because of the forced limited size of the CP/M loader it is limited and needs the cpm.sys in the right spot.



Randy

[Jared Falvo]

Ok, so I don't get confused with terms, the ROM chip that is on the motherboard is called the ROM BIOS or CMOS? I call it CMOS, because I know that means it's the firmware on that ROM chip that has the menu screen and stuff for setting the time, and floppy disks, and Southbridge and RAM and video card, etc. So, when I say CMOS, that's what I'm referring to.

CP/M-86 also has a file called BIOS. How does CP/M-86's BIOS relate to the motherboard BIOS/CMOS/Firmware/whatever?

And, if you could get CP/M-86 to work "natively" with 720K/1.44Mb disks (not "work-arounds"), would you still need Loader to be on the disk or would you simply create a DSKMAINT program that did it for those size of disks?

[Randy McLaughlin]

CMOS does not refer to the ROM BIOS it refers to something modern ROM BIOS's use, namely a low power CMOS RAM that has a battery that keeps what is in ram from being lost when the computer is off. The CMOS RAM also contains a clock that keeps the current date and time.

The terms used are based on the original PC, PC-XT, and PC-AT. The PC and PC-XT had no CMOS that was added with the PC-AT. The PC and PC-XT used switches to setup the computer. When the PC-AT came out IBM did away with the switches and added the CMOS chip and battery.

Today the CMOS chip or equivalent is in all computers. Not only that but integration has made it so most computer support chips have been replaced by VLSI (very large scale integration) which means that the ROM BIOS, CMOS, DMA, RAM controller, and many more are physically in one chip but if you check the data sheets they are shown as separate devices.

So technically they could all be on the same chip but not necessarily. In any event they act separate. CP/M-86 assumes it is running on a PC or PC-XT and even had to be patched to run on a PC-AT.

Usually none of that matters but if you intend to tinker with CP/M it's best to know what is what and what it's called and why.

Unfortunately CP/M-86 has been treated as the red headed step child and a decent update is long past due.

I would recommend you look past v1.1 and look at CP/M-86 plus that adds quite a bit, basically the equivalent of CP/M 3 for the x86 world. It was not released in the US but it is available. Below is a link discussing it and showing how to implement it on an S-100 system:

http://www.s100computers.com/Software%20Folder/CPM86/CPM-86%20Software.htm



Randy

[Jared Falvo]

OK, so the ROM BIOS is the ROM (firmware) chip on the motherboard. It's the thing that initially boots the computer and then looks for a boot sector on a floppy or hard drive... right?

Ok, now on to the next topic... how does CP/M-86's "BIOS" relate to the computer's ROM BIOS? How are they similar/different? Does CP/M-86 ever "call" the ROM BIOS for anything or does everything CP/M-86 do, is done from the "BIOS" file within CPM.SYS and CP/M-86 basically ignores anything outside of itself (i.e. never makes any calls to the ROM BIOS for anything)?

At this stage, I just want to understand CP/M-86 1.1 and how/why it works the way it does. Of course, I have "future goals" (CP/M-68K, Z80, etc. are dead-end roads... but the 8088/86 was the first line of a road that continues to this day) in mind, but you can't cross a river, if you don't first learn how to swim. :-D

[Randy McLaughlin]

The CP/M BIOS calls/uses the ROM BIOS to do all I/O for CP/M. The CP/M BIOS does not interact directly with any hardware.

The CP/M BIOS translates all I/O to what the ROM BIOS needs. The CP/M BIOS also handles all the tables needed to tell the BDOS the structures of the disk media. The CP/M BIOS also blocks/deblocks the 512 byte sectors into/from 128 byte sectors.


Randy

[Jared Falvo]

Alrighty, then! :-D

Why do people choose to "patch" or "work around" CP/M-86's limitations, rather than resolve them at the source code level? Such as the AT and Y2K "patches", and Freek's 1.44Mb floppy driver? Why not just change the source code of the files in CPM.SYS (AT/Y2K issue) and write a new DSKMAINT program, since the original's source code is lost to history (to resolve the 1.44Mb floppy issue)?

BIOS, BDOS, and CCP (which comprise CPM.SYS; is the CP/M Loader also inside the CPM.SYS file or not? It was never mentioned as such, that I found) are all in A86 source code form, so fix them and you've fixed the issues, have you not? Then the patches become irrelevant.

[Randy McLaughlin]

Simple the patches pre date the availability of the sources.


Randy

[Jared Falvo]

On Saturday, July 27, 2019 at 12:06:31 AM UTC-7, Randy McLaughlin wrote:
> Simple the patches pre date the availability of the sources.
>
>
> Randy

Concise answer... but what about now? :-D And what of Freek's 1.44Mb floppy driver? Was that also created before the source code was made freely available?

[dxforth]

Who at the time could have predicted the 'IBM PC' would become and remain
the standard computer hardware model for the next 20+ years? Its success
likely held advancement back. Cf. Commodore trying (unsuccessfully) to
kill off the C64 in favour of the more advanced C128.

[Jared Falvo]

On Saturday, July 27, 2019 at 12:06:31 AM UTC-7, Randy McLaughlin wrote:
> Simple the patches pre date the availability of the sources.
>
>
> Randy

"This is the original BOOT ROM distributed with CP/M for the SBC 86/12 and 204 Controller. The listing is truncated on the right, but can be reproduced by assembling ROM.A86 from the distribution disk."

and

"This program resides in two 2716 EPROM's (2K each) at location 0FF000H on the SBC 86/12 CPU board. ROM 0 contains the even memory locations, and ROM 1 contains the odd addresses."

This comes from a file called ROM.A86 in a source code archive called c8611src.zip.

Is this the equivilant of the ROM BIOS in a regular PC? If so, then there might be a path of understanding in this, since it's the actual source code.

[Randy McLaughlin]

Great but doesn't apply that is a different version. That is for a multi bus system not a PC.

The PC CPM BIOS source exists now as a disassembly.


Randy

[Jared Falvo]

Sometimes its worth digging in a different place to understand something you don't currently understand. I'm trying to understand what the ROM BIOS is. And if ROM.A86 is it, then, regardless if it's for a PC or not, it stll runs on an 8086 based system.

So, I ask again: Is ROM.A86 the equivalent (similar to/same as) to the code (firmware) of a ROM BIOS in a PC?

And remember, it's still CP/M-86 (CP/M written for the 8086 processor). The computer hardware is just configured differently and, therefore CP/M-86 is coded to that particular platform.

As for "multibus", aren't there lots of different "busses" in a PC? Aren't ISA/PCI/AGP/PCIe slots technically "busses" (ways to interface with the computer)? Every route of communication between components and/or the user is techically a "bus", as I understand it. And the wiki article seems to confirm that.

https://en.wikipedia.org/wiki/Bus_(computing)

So, to say that the code I'm asking about is "for a multi bus system, not a PC" is really just a matter of symantics. It's firmware code, in ROM chips that boots the computer. Whether for a PC or a "mult bus system", it still performas the same initial function... it gets the system booted up after you hit the power button.

[s_dub...@yahoo.com]

On Sunday, July 28, 2019 at 12:20:35 AM UTC-5, Jared Falvo wrote:
> On Saturday, July 27, 2019 at 8:27:56 PM UTC-7, Randy McLaughlin wrote:
> > Great but doesn't apply that is a different version. That is for a multi bus system not a PC.
> >
> > The PC CPM BIOS source exists now as a disassembly.
> >
> >
> > Randy
>
> Sometimes its worth digging in a different place to understand something you don't currently understand. I'm trying to understand what the ROM BIOS is. And if ROM.A86 is it, then, regardless if it's for a PC or not, it stll runs on an 8086 based system.
>

I'd answer this way..
The RomBios comprises all the built-in functions such as int 10h (video console), int 16h (keyboard fns), int 13h (disk, storage fns), and more, covered by (search RBIL Ralph Brown's Interrupt List) the 'IBM Bios' (BIOS in Rom).

ROM.A86 pertains to a rom boot loader image to be burned into an eprom - in the pc world this is already incorporated into the RomBios. (search 'boot sector')

The cp/m-86 BIOS, or CBIOS, is the software interface portion that interfaces the cp/m-86 generic functions to the target hardware -- that is, the IBM RomBios, or device control ports directly. Search Gaby's site for 'Eagle' version of cp/m-86, as that strove to be IBM compatible, and was known to work
on pentium era laptops with early floppy drives that could read 720k, 3 1/2, floppies formatted as 360k/320k. CP/M-86 v1.1 for the IBM PC came on 5 1/4 single sided floppies with 8 sectors per track, 40 tracks, 512 byte sector size.

For example, cp/m storage algorithms deal with n sectors x m tracks. The int 13h floppy drive deals in terms of Cylinder, Heads, Sectors per track. Those
mapping functions to match the two up are placed into CBIOS.

The CBIOS was end user accessible, as the eagle sources show how to rebuild the
system with a modified CBIOS. The CCP & BDOS were provided as .h86 files, and the tools could deal with that. The CCP & BDOS are mostly independent modules,
but in practice are coupled by update patches, and are constrained by the fact that the CBIOS jump table begins at a fixed offset of 2500h. The Program Loader algorithms are in the BDOS and is the bulk of the BDOS, it is the 'heart' of the OS imho, they largely attempt to scale cp/m-80 to deal with segmentation and the like. The various boot sectors for cp/m-86 all do a final jump to LoadSegm:2500h where for the ibm is segment 0051h. The CBIOS function INIT: jump vector is there, and expected to be there for all software written, most likely.

The tools are as much a part of the Operating 'System', so changes can't break them unless alternatives are found.

Freek used MASM 5.11, iirc, for feat & feat2 development. These were implemented as overlays to the original system file. iirc, Lineo held clear rights to the dri stuff at the time, perhaps it was deemed safer to not permanently alter the object code. DRI issued patches geared toward use of their tools, such as DDT-86, to permanently alter the object code. The tools,
the OS, the .cmd header - program loader algorithm, these are all strongly coupled in design, so tinkerer beware.

> So, I ask again: Is ROM.A86 the equivalent (similar to/same as) to the code (firmware) of a ROM BIOS in a PC?

Same in goal of loading, and passing control to, the boot sector.
In the PC, and onward, this is Segment 0000h:7C00h Offset. -search 'boot sector' or 'booting'.

hth,

Steve

[Jared Falvo]

Ok, puzzle... I assembled all the .A86 files (BIOS, BDOS, and CCP) into their respective .H86 files. I PIP'd all three .H86 files into one CPM.H86 file. I then GENCMD'd CPM.H86 into CPM.CMD. Then created a 360K disk image (on drive B) in PCEm, then formatted that disk image in DSKMAINT. Then PIP'd CPM.CMD over to the B: drive (as the first file!) and then REN'd CPM.CMD as CPM.SYS. But upon booting that disk, it says "Loading CPM.SYS...." and just sits there forever. It doesn't say it can't find CPM.SYS, it just sits there, like it doesn't know what to do *with* CPM.SYS or something.

Since I only have other documentation (i.e. nobody else's advice/expertise) to follow, I used the example of:

GENCMD LOADER 8080 CODE[A400] <-- Changing the drive and filename appropriately.

Is it possible I used the wrong [A#]? The only other example I see is:

GENCMD CPMX 8080 CODE[A40] <-- Should I have used this [A#]?

[Jared Falvo]

Nope. That doesn't seem to have worked either... :-(

I seem to have built everything correctly, but I can't figure out whether or not the problem of the "Loading CP/M-86...." hang is because of something in the code of CPM.SYS (one of the .A86 files) or something done wrong with GENCMD.

[s_dub...@yahoo.com]

o [A51] The pc ivt (interrupt vector table) resides at segment 40h..50h.
o Can you define a diskette of 40 tracks * 8 spt? Use that first, a single sided diskette of 160k, as that is the original format.
o Check the option to gencmd (-m?) that removes the 80h bytes .cmd header record. Depending on the sector 1 system loader, it won't want the header, usually. CPM.SYS isn't expecting 9 spt. -And the last byte of the side is the 'sideness' of the diskette, -- Cyl 0, Head 0, Sector 8, byte 511 (0..511) is zero for a single sided diskette, or 1 for a double sided diskette.

Steve

[Jared Falvo]

I really wish that made any sense to me. Should I simply try formatting the disk as a 160K and see if my CPM.SYS works on it? Or should I try rebuilding the CPM.CMD by doing the gencmd (-m) thing you suggest? Which first? If neither works, what is the next thing I should try?

[Jared Falvo]

Ok, I tried reformatting the disk as a 160K and sticking my CPM.SYS on it. Still hung. I tried just GENCMD B:CPM.H86 8080 and THAT didn't work either. Still hung. Hmmph!

[s_dub...@yahoo.com]

Yeah, there is some background info you need to school up on.

The boot sector loader that you are using may be loading the cpm.sys at segment 40h. Do you have the source code for it? Where is it placing the cpm.sys image at? Is the cpm.sys image the correct one for the ibm pc?
For the IBM-PC/XT it must load to segment 51h.

Have you gotten your cp/m-86 from here?:

http://www.cpm.z80.de/binary.html

CP/M-86 for the PC 1.1: 375K The copyqm disk images, and the individual files from a 3 diskette set of CP/M-86 For The IBM Personal Computer [not XT][no AT-Patch] V1.1, [PC Only, no HD support].
...

According to https://en.wikipedia.org/wiki/PCem, "and CP/M-86 are also supported."

Have you tried seeking help here..

https://pcem-emulator.co.uk/phpBB3/viewtopic.php?f=2&t=3277&p=12517&hilit=cpm+86#p12517

Steve

[Jared Falvo]

The BDOS and CCP came from one source code file (they were the only two files in the archive I downloaded) and the BIOS came from another (which has everything, but it only has CPM.H86, and no BDOS/CCP source code files). That's probably why the CPM.SYS isn't loading. "Mix 'n' Match" doesn't exactly work too well, in this instance, eh?

You said that CPM.SYS for the PC/XT must load at segment 51h. But wouldn't that also be accomplished by setting GENCMD as GENCMD B:CPM.H86 8080 CODE[A51]? Or is something in the source code (.A86) files munging things up?

I can boot my working copy of CP/M-86 1.1 from a 160K or 360K disk image, no problem. I can boot it on a generic XT and even 286 emulation (using monochrome mode) in PCEm, no problem. But "my" CPM.SYS file won't boot at all... just hangs.

[Randy McLaughlin]

Do yourself a huge favor:

Start with a working system and learn it before building one of your own.

CP/M-86 is available as a working binary.

Start there and then modify it from a working environment.


Randy

[David Schultz]

On 7/30/19 1:49 PM, Jared Falvo wrote:
> The BDOS and CCP came from one source code file (they were the only two files in the archive I downloaded) and the BIOS came from another (which has everything, but it only has CPM.H86, and no BDOS/CCP source code files). That's probably why the CPM.SYS isn't loading. "Mix 'n' Match" doesn't exactly work too well, in this instance, eh?
>
> You said that CPM.SYS for the PC/XT must load at segment 51h. But wouldn't that also be accomplished by setting GENCMD as GENCMD B:CPM.H86 8080 CODE[A51]? Or is something in the source code (.A86) files munging things up?
>
> I can boot my working copy of CP/M-86 1.1 from a 160K or 360K disk image, no problem. I can boot it on a generic XT and even 286 emulation (using monochrome mode) in PCEm, no problem. But "my" CPM.SYS file won't boot at all... just hangs.
>

I have a lot of experience with CP/M-68K but none with CP/M-86 but in
many ways they are similar. Particularly in the boot process.

Debugging the loader can be tough. If you don't have a resident monitor
that can set breakpoints and single step then you are pretty much left
with using console I/O within your loader BIOS to drop hints. Little
things like printing out the requested track and sector numbers when
reading a sector.

--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)

[Jared Falvo]

How do you modify a working binary? Where is the source code for the exact same binary I am using? I can show/give you the working binary I am using. But how do you learn if there is no one to show, to guide, to teach? All the binary I have, allows me to do, is use it. I've learned some commands. I've formatted disks. Copied files. Even assembled existing source code and created a (non-working) CPM.SYS! Haven't yet run any outside applications (games and such), but... what else am I supposed to learn about this working binary I have? The rest is the inner workings... the source code... of CP/M-86.

It's not what CP/M-86 can do today (how many people even still use it regularly for what other OS's are used for? Can they, even?). It's what I see as potential... taking the past and bringing it to the future... "CP/M-86 2K Edition", if you will. People remember CP/M for what it WAS. Pure nostalgia, mostly. Not for what it IS or COULD be. But how many people would do a double-take if they saw CP/M-86 as never before? A familiar name doing things it never did before... and maybe even doing them BETTER! But each step towards a goal like that requires desire and focus. If no one cares, then nothing changes, and I've run into too many like that. The status quo is good enough for them.

The reason I want to learn what I can, is so I can carry the ball further than just mere words spoken to others. Talk is cheap and talking goes nowhere. But find a passionate individual who is willing to learn how to do, and the entire world can be changed!

[s_dub...@yahoo.com]

But there were machines other than the ibm pc that versions of cp/m-86 ran on.
There were s100 buss systems with 8086/8088 plug-in cpu cards for example.
There were all manner of configurations that a CBIOS was written for: dual 8in floppies, 5 1/4 in floppies, memory mapped video terminal or serial terminal. All those differences are reflected in the makeup of the CBIOS. Read the systems guide manual, probably on Gaby's site.

>
> You said that CPM.SYS for the PC/XT must load at segment 51h. But wouldn't that also be accomplished by setting GENCMD as GENCMD B:CPM.H86 8080 CODE[A51]? Or is something in the source code (.A86) files munging things up?
>

No, GENCMD uses the parameter in the creation of the prepended .CMD header record, which is the structure that carries info for the program loader in the BDOS to load and setup an executable file in some portion of TPA memory. CPM.SYS might not have the header, its loading is performed by the boot loader. It been 20 yrs, I don't recall if CPM.SYS has the header record, but that it is skipped over by boot loader, or it hasn't the record, which isn't a problem since the boot loader is designed for loading just CPM.SYS and is matched to that system.

> I can boot my working copy of CP/M-86 1.1 from a 160K or 360K disk image, no problem. I can boot it on a generic XT and even 286 emulation (using monochrome mode) in PCEm, no problem. But "my" CPM.SYS file won't boot at all... just hangs.

It is good news that you have a working system. I assume you have the normal complement of cmd files, including DDT-86.CMD or SID86.CMD..

You should realize that the point of departure in modification is the CBIOS, and that, that code resides, starting at offset 2500h, with the BIOS jump table. So, you can learn to merge a new CBIOS into CPM.SYS using DDT, instead of using an unknown CCP.H86, BDOS.H86, Vers 1.0 and v.1.1 are not compatible. Also, the CCP & BDOS are matched with a serial number, and those s/n's are checked for at runtime. This was a commercial product, not open source, in the day, so things were done.. only the CBIOS was 'open'.

You should learn to use DDT. Since it has a disassemble function, and you are working on an emulator where I imagine you can cut and paste screen output, you can get a disassembly of a block of code, and practice annotating what the code does.

You should come to know what your working boot sector is, and what it does.
A runtime copy of it is located at 0000h:7C00h aka 07C0h:0000h. It is 200h byes in length. It is a great exercise to start with. You need these skills..

This location is above cpm.sys and below DDT when DDT is running. Use DDT dump function to dump this region of 200h bytes as a hexadecimal dump and also the same region as a disassembly giving assembly instructions. Post both of them here and I can go over them with you. By comparing the hexadecimal dump and the disassembly of the same 200h byte block, the data area can be distinguished from the code. No hurry, learn what you need to, to do what I've asked for. You need these skills.

Steve

[Randy McLaughlin]

You start with a working system and you take the source you have and you compare the working binary with what your sources assemble to.

You learn how to assemble them to create the working binary (CPM.SYS).

Then you can start to do what you want to do.


Randy

[Jared Falvo]

Ok, the working system I have is an archive called "CPM-86 1.10 [IBM PC] (5.25-160k)". It's a 7Zip (.7z) file. It runs fine in PCEm v15, running a ROM called "GenXT", which I downloaded off the PCEm website, at the bottom of the download page. I still haven't figured out which folder it actually belongs in because the one I thought it would work in, didn't, so I just kept pasting the file into other folders til it popped up! But I know it's an XT folder (there are several)! :-D

I found two files (BDOS/CCP) in one archive (cpm86src) and the BIOS (and CBIOS) in another archive (c8611src). I could possibly build a working CPM.SYS file from the latter, but several parts of CPM.SYS are .H86 files, not .A86, so I can't learn anything from them, because they're already compiled! And you cannot diassemble Hex files without a lot of translation afterwards, to get working .A86 files again. For a non-programmer like myself, uh... let's not even bother with that, shall we? :-D

Like I said, trying to "mix and match" the pieces of two different archives is probably a fool's errand, but I was hoping, if it all worked, it would work. But, apparently, things can fit together seemingly "right" and still not function in the end. Dumb puzzle! Don't they know that if the pieces fit together, it doesn't matter if they're from two different pictures, it should still look like a single image? :-D

So, lesson learned... everthing "fits together" ok, but it's not the right picture (i.e. doesn't boot)! So, how do you get all the source code files to play/work nice together?

One thing I thought of is if you strip out all the "variables" (things that could be different between systems) and get down to a bare bones minimum that will just boot. Something so basic, you COULDN'T mess it up! But, question is, what would that be? Well, if you took out all the disk drive booting stuff and had it boot out of a RAMdisk...

I know that (maybe) sounds crazy, but hear me out...

The Loader ("Loading CP/M...") knows EXACTLY what it's doing. It's already ON the disk image (from the format process). The ROM BIOS has already loaded it. It's already running. What's happening is that it's putting CPM.SYS exactly where it needs to go, but my CPM.SYS is blond and hasn't got a clue WHERE it is, so it does nothing! It's sitting there at the end of that last period (with the blinking cursor) and just stares at the Loader and says... "Uhhhhh."

The Loader just sits back and laughs... "I did MY part... YOU figure out the rest!"

Ok, now back to the whole RAMdisk thing... there is a program on the CP/M-86 disk called Setup. And, in it, is a way to create... a RAMdisk! And you can "Update A: and Exit" (which permanantly alters something on the A: drive) The RAMdisk is created as part of CPM.SYS' journey to the A> prompt and knows how to do that by something Setup told it). But, what if it were created BEFORE CP/M started it's journey? If the Loader were to grab the RAMdisk code and execute it FIRST, then grab CPM.SYS and stick it at the begining memory location of the RAMdisk... But how do you do THAT?!?

Alter CPM.SYS to be the RAMdisk and have IT then grab, say CPM2.SYS (the actual CPM.SYS) and then stick it at the start of the RAMdisk's memory location.

Loader only cares about one thing... grab CPM.SYS from a specific disk location and stick it in a specific memory location. It doesn't care *what* CPM.SYS does, after that. It's job is done. CPM.SYS could be a game... a virus... a spreadsheet program... anything. We've ONLY created a defective CPM.SYS, so we know it's NOT Loader putting CPM.SYS in the wrong place. It CAN'T. So, the only logical conclusion, is that CPM.SYS doesn't know what to do (it thinks it's someplace it isn't) and thus nothing happens beyond that point.

I'm not sure how much RAM CPM.SYS actually takes up, but I imagine not a lot. So, with 640K (or 704K in my XT emulation), there should still be plenty of room with both a RAMdisk and "system memory".

So, if we reconstruct CPM.SYS to know where it is (the exact memory location Loader puts it), and to create a RAMdisk, and THEN either grab a second copy of itself (or simply duplicate itself) into RAMdisk position and continue from that point, then we have a disk-based (CPM.SYS file sitting as the first file on the disk), yet non-disk-based version of CP/M-86! At least the basic "kernel"(CPM.SYS). We make everything in CPM.SYS reference memory locations, not disks.

Ok, I've rambled on long enough... let me know if I'm either on track or totally off-base with all this and should be locked up in a padded cell, singing, "They're coming to take me away... ha, ha, hee, hee!" :-D

[Jared Falvo]

Goodness... you write an educational book of a reply and I'm scratching my head, going... "Whud he say?" :-D But I'm not sure you have the patience (or non-developer mindset) to break things down into (as I call it) "Fool's English" (explained in a way, even a fool could understand it).

It may be because I don't understand "Hexadecimal" (my math knowledge goes up to division and basic fractions... I forgot everything else -- you know, "use it or lose it" -- I done lost it loooooong ago), so talking about that kinda stuff just buzzes over my head like a drone!

But I try...

[Randy McLaughlin]

You should follow the KISS rule, Keep It Simple Stupid:

CP/M was never meant to be completely assembled from sources. It was always meant to use the H86 CCP/BDOS and only the BIOS (CBIOS) be assembled from source.

You need to find or create the H86 files that match the CCP/BDOS of your working CPM.SYS file then work from there.

You must aim for recreating the working CPM.SYS to be a matching file. Keep in mind uninitialized areas are undetermined and can be ignored.

Once you can create a working system from your BIOS (CBIOS) source you are ready to play.


Randy

[Udo Munk]

On Wednesday, July 31, 2019 at 5:43:33 PM UTC+2, Randy McLaughlin wrote:

> CP/M was never meant to be completely assembled from sources. It was always
> meant to use the H86 CCP/BDOS and only the BIOS (CBIOS) be assembled from source.

Yep, everyone is expected to enter the complete binary via a front panel ;-)
Many of the OEM's had a source license from DRI, of course the system was compiled/assembled
self.

[s_dub...@yahoo.com]

It's ok, the point is that at some time in the future it will make sense to you.

> But I'm not sure you have the patience (or non-developer mindset) to break things down into (as I call it) "Fool's English" (explained in a way, even a fool could understand it).
>

So I didn't know your skill level, your questions imply, possibly, a certain level, but we all start out with a zero skill level, and acquire knowledge as we need it. Being a fool isn't a problem, staying a fool is. If you can tell time with an analog clock, base 60:60:24, then you certainly have the skill to understand Binary, base 2, or hexadecimal, base 16.

> It may be because I don't understand "Hexadecimal" (my math knowledge goes up to division and basic fractions... I forgot everything else -- you know, "use it or lose it" -- I done lost it loooooong ago), so talking about that kinda stuff just buzzes over my head like a drone!
>

Well, at some point you will need those skills, you have wikipedia I presume.

> But I try...

A requirement, yes, but don't try foolishly, learn up.

Steve

[s_dub...@yahoo.com]

On Wednesday, July 31, 2019 at 3:59:01 AM UTC-5, Jared Falvo wrote:
> On Tuesday, July 30, 2019 at 9:55:04 PM UTC-7, Randy McLaughlin wrote:
> > You start with a working system and you take the source you have and you compare the working binary with what your sources assemble to.
> >
> > You learn how to assemble them to create the working binary (CPM.SYS).
> >
> > Then you can start to do what you want to do.
> >
> >
> > Randy
>
> Ok, the working system I have is an archive called "CPM-86 1.10 [IBM PC] (5.25-160k)". It's a 7Zip (.7z) file.

If you downloaded thru WinWorld it is the same as the one I provided to Gay's site.

See if you can use the Eagle version from/thru WinWorld, its pc compatible and provides the CCP & BDOS .H86 files, and its CBIOS, and how to build a new CBIOS version. -And, iirc, has the boot loader source.

Steve

<snipped>

[Jared Falvo]

If it was never intended to be assembled from sources, then how did CP/M-86 ever come into being? :-D Unless the sources were disassembled from the .H86 files and that's how we have them today. At least one copy/version of them.

But what good is recreating what I already have? Unless a lot of what I want to accomplish is doable from altering just CBIOS. But I don't get that sense. It's just one part of the whole and the whole is already mostly pre-defined in the .H86 files. Defined as part of the past... 80's design/technology. 160K and 360K drives. 640K memory limit. How do you "build a better mousetrap", by simply assembling the one that already exists? You simply have two of the same mousetrap.

And what are these "uninitialized areas" you speak of? If I don't know what to change in CBIOS, then how do I successfully change anything? Even if I were to assemble a perfectly working copy of a bootable CPM.SYS, the way you mention, how does that get me... anywhere? Doing something just to do it seems rather pointless. Unless, we're just making sure we CAN do it with the existing files. But... hasn't someone already proven that?

My hyper-analytical nature is beginning to show itself, I'm sure. I don't like to do something, just to do something. I want to know WHY I'm doing it and how it will progress my understanding. I want knowledge I will use, not just knowledge I will have. That's why I could never program code right in my programming class (I basically got a D in that class). Instead of writing a program that knew the answer to any questions asked, I was supposed to write a program that asked questions that the customer then answered. But as a computer tech (A+ Certified), *I'M* the one with the answers! I apply my knowledge to fix a problem, not ask questions to have the customer help me figure out how to fix a problem... otherwise the customer knows more than me!

So, in this situation, that's why I believe having the source code to everything helps me more (can add to my knowledge) than just putting together a working copy of what I already have, from one source file (CBIOS) and two .H86 files.

[Jared Falvo]

> If you downloaded thru WinWorld it is the same as the one I provided to Gay's site.
>
> See if you can use the Eagle version from/thru WinWorld, its pc compatible and provides the CCP & BDOS .H86 files, and its CBIOS, and how to build a new CBIOS version. -And, iirc, has the boot loader source.
>
> Steve

Ok, I downloaded it and running it on PCEm in the Generic Turbo XT 8088 BIOS emulation. First thing I noticed, is it has no "Loading CP/M...." and it never shows the number of drives or the amount of RAM, etc. It just prints the ROM BIOS info and then drops down to the A> prompt. Very uninformative... :-D

I see no CCP/BDOS .H86 files (unless they're named differently). I see other .A86 files but... now what am I supposed to do?

[David Schultz]

On 7/31/19 1:05 PM, Jared Falvo wrote:
> But what good is recreating what I already have?

That way you know that you have the parts and processes correct. Once
you have that, you have something to build on.

> Unless a lot of what I want to accomplish is doable from altering
> just CBIOS. But I don't get that sense. It's just one part of the
> whole and the whole is already mostly pre-defined in the .H86 files.
> Defined as part of the past... 80's design/technology. 160K and 360K
> drives. 640K memory limit. How do you "build a better mousetrap",
> by simply assembling the one that already exists? You simply have
> two of the same mousetrap.
>

Disk interface and the geometry definitions are part of the CBIOS. If
you don't alter those, you can't use different drives.

The CBIOS also contains the table that defines usable memory areas.

All described in the System Guide.

[s_dub...@yahoo.com]

Well, is there a CPM.H86? Then that is the CCP+BDOS combined. Are there .sub files describing how things are built?

>... now what am I supposed to do?

What did you imagine you would do?

You could learn enough to add functions to CBIOS INIT: to print out the device list gotten from INT 11h - get equipment status, and Get Memory Size (INT 12h).

Steve

[Jared Falvo]

How do I read .sub files? There's a WINSTALL.SUB file (on the A: drive), but I don't know how to read it.

I'm trying to understand how things work. But where is a manual or personal guidance for such? Giving a few step-by-step instructions (in "Fool's English") might go a long way.

[Randy McLaughlin]

Type it, or edit it. They are simple text files that contain CP/M command lines.

Randy

[David Schultz]

On 7/31/19 6:58 PM, Jared Falvo wrote:
> How do I read .sub files? There's a WINSTALL.SUB file (on the A: drive), but I don't know how to read it.
>

TYPE is the usual way.

[Randy McLaughlin]

Forgot to mention the files are run by typing 'submit "file name"'. The .sub can be omitted or not. Submit is the CP/M equivalent of DOS batch (.bat).


Randy

[s_dub...@yahoo.com]

Grab all the manuals under heading CP/M-86 from:
http://www.cpm.z80.de/drilib.html

How many disks came in the eagle version?

Steve

[Jared Falvo]

Two disk images.

[Jared Falvo]

On Wednesday, July 31, 2019 at 6:18:19 PM UTC-7, Randy McLaughlin wrote:
> Forgot to mention the files are run by typing 'submit "file name"'. The .sub can be omitted or not. Submit is the CP/M equivalent of DOS batch (.bat).
>
>
> Randy

When I type: TYPE Winstall.sub, I see:

CLDIR E:
CLDIR F:
SYS WCPM.SYS E:
WRTLDR WINBOOT.SYS E:

What do these lines do? I'm not about to execute a .BAT file (or the equiv. to, as you say) if I don't know what it's going to do. "What does THIS shiny red button do?", tends to cause things to self destruct. Just ask Ren & Stimpy. :-D

[Randy McLaughlin]

In this case W refers to Winchester aka hard drive.

None of the commands are base CP/M commands but obviously it erases 2 hard drives and makes the first hard drive bootable.


Randy

[Jared Falvo]

So, how do I use this version of CP/M-86? It's booting off of a floppy image, but where do I go from here? Is it meant to run off of a 286, so that a hard drive is possible or...? I could try to emulate a hard drive, but I don't know what type/size to set up. Not even sure if it will work on the XT emulation I have. Should I set up the 286 Emulation? I really don't see how this Eagle version helps me get any further along in my understanding...

[Randy McLaughlin]

You need to do what was recommended and read up on what CP/M is and how it works as is before reinventing it.

All of your questions are answered in the documentation.

While we can keep giving you advice you really need a basic level of knowledge first.

It is worth it learning CP/M it can give you insight into the birth of home owned computers. And try to keep in mind that so much was done with so little.

This post may sound pushy but I am just trying to help. Keep in mind that the documents are written for two different environments and neither is for the version you are using. One is the generic CP/M for any 808x and the DRI released IBM version preconfigured but it applies to your version anyway. It is all that I know of being available. I would have stayed with the DRI preconfigured until I was able to assemble it to be an exact copy of that CPM.SYS file.


Randy

[Jared Falvo]

On Thursday, August 1, 2019 at 7:36:19 PM UTC-7, Randy McLaughlin wrote:
> This post may sound pushy but I am just trying to help. Keep in mind that the documents are written for two different environments and neither is for the version you are using. One is the generic CP/M for any 808x and the DRI released IBM version preconfigured but it applies to your version anyway. It is all that I know of being available. I would have stayed with the DRI preconfigured until I was able to assemble it to be an exact copy of that CPM.SYS file.
>

Then I simply need to know where I can locate each version and then I need to know where the documentation for both versions are. Specific sites and filenames would be appreciated.

[Randy McLaughlin]

There is one official site even though it is still called the unofficial site:

http://www.cpm.z80.de

It originally was created without legal permission which is why it was named unofficial but it got permission for non-commercial distribution.


Randy

[Jared Falvo]

This is where I got my copy of CP/M-86 1.1 [PC]. I also downloaded the manual and am reading it now:

https://winworldpc.com/product/cp-m-86/1x

What's the diff. between 1.0 for [PC] and 1.10 [PC]? What's the difference between [PC-XT] and [PC]? Subtle? Significant? I just noticed the [PC-XT] version is on 360K disk(s) instead of 160K disk(s)... have I been using the wrong version, thinking [PC] was better than [PC-XT]?

[Randy McLaughlin]

As I remember 1.1 supported hard drives (XT). The difference is limited to just the IBM in the CBIOS and utilities like dskmaint. The generic CP/M-86 left all I/O up to whoever was integrating it.

Randy

[Jared Falvo]

On Friday, August 2, 2019 at 9:15:12 AM UTC-7, Randy McLaughlin wrote:
> As I remember 1.1 supported hard drives (XT). The difference is limited to just the IBM in the CBIOS and utilities like dskmaint. The generic CP/M-86 left all I/O up to whoever was integrating it.
>
> Randy

Are any of the versions I mentioned, the "generic" one? If not, where is this "generic" version?

[Randy McLaughlin]

I just checked the unofficial site link and sad to say they don't have a true generic version archived (I will get with Gaby to see about fixing that).

I would start with the CPM-86 for 1.44mb simply because it is a patched version that would be easier to run. The archive versions are all donated copies and needs to be researched what is what.

The above is for the non generic CP/M-86 but instead machine specific versions (IBM and others).

A different site has the closest to generic (has generic that includes Compupro CBIOS):

https://www.hartetechnologies.com/manuals/CompuPro/

The Compupro CBIOS source zip file is an archive that under the CPM 86 folder has then generic files under v1.1r\D2. These files include the CPM.H86 etc as needed.

The Compupro Archive contains many other OS's and even for CP/M 86 v1.1 has two versions but the two versions are just changes to the Compupro CBIOS and not a change in the CP/M-86 generic files.


Randy

[Jared Falvo]

On Friday, August 2, 2019 at 9:15:12 AM UTC-7, Randy McLaughlin wrote:
> As I remember 1.1 supported hard drives (XT). The difference is limited to just the IBM in the CBIOS and utilities like dskmaint. The generic CP/M-86 left all I/O up to whoever was integrating it.
>
> Randy

Ok, interesting discoveries:

1) The CP/M-86 1.0 manual has a LOT of detailed information I wasn't finding elsewhere...

2) CP/M-86 1.0 (PC) is the exact version the manual references. All Transient Utilites are the same (filenames match the manual).

3) CP/M-86 1.1 for PC-XT *is* the one that supports Hard Disks. However, I have to use the AMI 286 ROM, which has MFM Hard Disk support (I'm assuming IDE is not supported by CP/M-86, emulated or otherwise). I created a 10Mbyte Hard Disk image and then configured it in the 286 ROM BIOS (User Type 1). Ran HDMAINT and... BINGO! I have an 8Mbyte Hard Drive partition! Why 8Mbytes instead of 10Mbytes? CP/M-86 won't support it. Only Concurrent CP/M-86 will go higher, according to what HDMAINT tells me. Unless I misunderstood what it was saying and you could have a larger hard drive, but each partition can only be up to 8Mbytes each.

4) Using Monochrome (Hercules) allows me to use CP/M-86 on the AMI 286, whereas other modes (EGA by default) cram all the text to a single column on the left hand side, making it totally impossible to do anything or figure out what it's saying. In other words:

P
r
e
s
s

[
E
n
t
e
r
]

t
o

c
o
n
t
i
n
u
e
.
.
.

is kinda hard to see/use, isn't it? :-D

But I was under the impression that you couldn't use CP/M-86 on a 286 or higher, because of the "AT" incompatibility (which needed the "AT Patch" to function at all). Yet mine seems to be running fine so far, as long as I'm in Hercules (monochrome) graphics mode.

[s_dub...@yahoo.com]

If it runs, it is the 'right' version.
As the [PC] description says - no hard drive support. This means the CBIOS is simpler, which could be a good thing if the goal is to modify it.

The [PC/XT] has hard drive support, and it _may_ match up to the RomBios you've chosen to use in the emulator. Running HDMAINT to format the virtual hard drive would be something to try but see if you can find documentation on it. Perhaps the HELP command is available, and may have an terse entry about it.

First however, select each drive letter to see what happens, the possible range is A: thru P:.

You start off in A:

A: B:
B:
B: C:
Bdos err on: C:

(Ctrl-C)

The above tells..
A: is supported
B: is supported
C: is not supported.

C: was typically the first HD volume, but the RomBios image you've chosen to use may support 4 floppy drives: A:..D:, but that doesn't mean that the CBIOS knows about them. --this is probably above your knowledge base at this point.

Do the above, floppy drive login test, first. M: maybe recognized as a ram drive.

Steve

[Jared Falvo]

On Friday, August 2, 2019 at 11:27:26 AM UTC-7, Jared Falvo wrote:
> On Friday, August 2, 2019 at 9:15:12 AM UTC-7, Randy McLaughlin wrote:
> > As I remember 1.1 supported hard drives (XT). The difference is limited to just the IBM in the CBIOS and utilities like dskmaint. The generic CP/M-86 left all I/O up to whoever was integrating it.
> >
> > Randy
>
> Ok, interesting discoveries:
>

> But I was under the impression that you couldn't use CP/M-86 on a 286 or
> higher, because of the "AT" incompatibility (which needed the "AT Patch" to
> function at all). Yet mine seems to be running fine so far, as long as I'm
> in Hercules (monochrome) graphics mode.

Ok, weird...

CP/M-86 1.0 (PC) works with the AMI 286 ROM in monochrome. CP/M-86 1.1 (PC) won't work (crazy single column text ("Press any key to continue..." and error tone just repeats over and over, no matter what key you press)), even in monochrome. However, CP/M-86 1.1 for PC-XT also works in monochrome with the AMI 286 ROM.

Any idea... WHY?

[Randy McLaughlin]

As for the hard drive the it is handled by the ROM BIOS so CP/M cant tell the difference. It should work fine.

The vertical text could be either a bad disk image or not patched for the AT.

Just pick one that works preferably for an IBM.

As I remember dskmaint will show you if it sees a hard drive - IBM CP/M can not handle hard drives over 30mb (32 to be exact) so make sure the hard drive is emulating a tiny hard drive.

Not only does the drive have to be tiny the partition it makes can only be up to 8mb (all going by memory).


Randy

[Larry Kraemer]

Udo has the comtools diskdef posted and I have this as the libdsk diskdef:

# libdsk diskdef
#ORDER CYLINDERS
#
[cpm86-144feat]
description = FEA1 IBM PC, CP/M-86 - 1.44 MB - DSHD 3.5" - 96 TPI 512 x 18
sides = outback
cylinders = 160
heads = 2
secsize = 512
sectors = 18
secbase = 1
datarate = HD

Larry

[Jared Falvo]

Has anyone looked at bootOS? It reminded me of CP/M-86. Looks pretty simple, but figured the boot process it used might be advantageous...

[Jared Falvo]

On Tuesday, July 30, 2019 at 1:14:22 PM UTC-7, Randy McLaughlin wrote:
> Do yourself a huge favor:
>
> Start with a working system and learn it before building one of your own.
>
> CP/M-86 is available as a working binary.
>
> Start there and then modify it from a working environment.
>
>
> Randy

Ok, I am beyond confused... I just got all the .ROMs for every system/video card PCEm v15 supports and decided, just for the sake of craziness, to try and boot CP/M-86 1.1 (PC-XT) on the highest-end system... a Socket 7 processor motherboard, with a Pentium 75 (lowest end CPU the motherboard supports; the available processors go much higher).

Didn't boot, right? Nope! IT DID!

How is this even possible? This totally changes everything in my thinking! It doesn't need to be made to work on modern systems (*massively* modern, relative to what it's supposed to run on)... it already does! It simply needs to be made to work BETTER!

[Jared Falvo]

I have gathered all the source code and a complete development environment and a $100 challenge into a single .7z archive on my website:

https://luposian.webs.com/

Lets see who gets the money first!

[Jared Falvo]

Project temporarily suspended. After a lot of research, I came the realization, there really is no way to accomplish my goal. There is no real "upgrade path" from where CP/M-86 currently resides. It's basically stuck in the past with no simple way to modernize it. So a total reassessment of the situation is necessary. As well, the $100 challenge was likely far too small to even be considered, hence why no one in the few days my page was up, has even visited, so far as I can tell. I'll be back, when I've reorganized my project. Shouldn't be long. I've already got an idea in mind... and a much larger reward in consideration.

[drac...@gmail.com]

I dabble with CP/M-86 on occasion. Do I understand that you only want to make CP/M-86 use modern diskettes? I'm not running it now, but it works on old pentiums computers without problems because the old machine code is still recognized (the 8086/8088 egisters and addressing modes are mapped to subsets of the pentium registers. Some of the limitations may not exist in MP/M-86 or whatever it's called -- like the 8 MB hard drive limit.

I have been tracking this thread, but I've gotten bogged down in the details.

[Jared Falvo]

On Sunday, August 11, 2019 at 5:24:37 PM UTC-7, drac...@gmail.com wrote:
> I dabble with CP/M-86 on occasion. Do I understand that you only want to make CP/M-86 use modern diskettes? I'm not running it now, but it works on old pentiums computers without problems because the old machine code is still recognized (the 8086/8088 egisters and addressing modes are mapped to subsets of the pentium registers. Some of the limitations may not exist in MP/M-86 or whatever it's called -- like the 8 MB hard drive limit.
>
> I have been tracking this thread, but I've gotten bogged down in the details.

I've come to realize that CP/M-86 is "land locked" in the past, because ASM86 only codes for 8088/86 processors, so far as I know. I believe the only way to actually get "out of the past" is by porting CPM.SYS to another language. How difficult it will be (or expensive) to do so, is something I am researching now.

It's not just about using higher capacity floppy drives or using CP/M-86 on newer processors. It needs to go beyond its own inherant limitations. Not just by hacks/patches and "work-arounds", but natively. Give it a brand new lease on life. Yet no one has endeavored to do so. Why, I do not know. But I'm giving it a shot.

One thing I am trying to figure out... is the source code for GSX-86 available? I've found a couple things that say GSX-86 driver sources and GDOS1.1, but I'm not sure if that's actually GSX-86, the program that enables graphical output on screen and printers and such. Can anyone confirm?

[Udo Munk]

On Monday, August 12, 2019 at 7:26:42 AM UTC+2, Jared Falvo wrote:
> I've come to realize that CP/M-86 is "land locked" in the past, because ASM86
> only codes for 8088/86 processors, so far as I know. I believe the only way to
> actually get "out of the past" is by porting CPM.SYS to another language.
> How difficult it will be (or expensive) to do so, is something I am researching now.
>
> It's not just about using higher capacity floppy drives or using CP/M-86 on newer processors.
> It needs to go beyond its own inherant limitations. Not just by hacks/patches and
> "work-arounds", but natively. Give it a brand new lease on life. Yet no one has
> endeavored to do so. Why, I do not know. But I'm giving it a shot.

It looks like that you are not familiar with the work on CP/M-86 to move it to later
hardware. You can read about this here: https://en.wikipedia.org/wiki/DR-DOS

> One thing I am trying to figure out... is the source code for GSX-86 available?
> I've found a couple things that say GSX-86 driver sources and GDOS1.1, but
> I'm not sure if that's actually GSX-86, the program that enables graphical output
> on screen and printers and such. Can anyone confirm?

The GSX-86 sources probably are lost, but GEM, the descendant, also was developed further:
https://en.wikipedia.org/wiki/Graphics_Environment_Manager

[roger...@gmail.com]

> I've come to realize that CP/M-86 is "land locked" in the past,
> because ASM86 only codes for 8088/86 processors, so far
> as I know. I believe the only way to actually get "out of the past"
> is by porting CPM.SYS to another language.

have you looked at cp/m-68k? that's written
in C; with a bit of work, it can be made to
run on other platforms; I've run it on ARM
and VAX.
--
roger ivie
roger...@gmail.com

[Jared Falvo]

680x0 is a dead end road... 8086 leads to 80286->80486->Pentium->infinity and beyond... are there 4 core+ 680x0-based 64-bit processors? Not to my knowledge. The x86 roadmap goes on to this very day. ARM would be the most likely contender, but... where? From what codebase? I'd love to see CP/M running natively on a Raspberry Pi 3B, but... that much likely? Not to my knowledge.

[Jared Falvo]

CP/M is not DOS and DOS is not CP/M. DR-DOS was designed to compete with MS-DOS, which was (more or less) stolen from Gary Kildall by Tim Patterson, if I'm not mistaken in what I've read. GSX-86 is not GEM and GEM is not GSX-86. I don't want to touch things that are GPL'd (GEM is). You can't use/modify the code without being required to make it available to EVERYONE ELSE. I've got ideas in mind that are not GPL compatible. MIT/BSD licenses are "it" for me. CP/M is under such a type of license.

If I cannot accomplish what I am desiring to, the way I want to, then perhaps there is another route. But then... it isn't CP/M being adapted... it's another OS becoming CP/M... and is it CP/M then? Not really. That's the sore spot... remaining pure to the origins of the OS. HaikuOS is not REALLY BeOS. It looks like BeOS and functions like BeOS, but it is it's own creature that people enthuse over, because of their great love for BeOS in the beginning.

[David Schultz]

On 8/12/19 7:02 PM, Jared Falvo wrote:
> 680x0 is a dead end road... 8086 leads to 80286->80486->Pentium->infinity and beyond... are there 4 core+ 680x0-based 64-bit processors? Not to my knowledge. The x86 roadmap goes on to this very day. ARM would be the most likely contender, but... where? From what codebase? I'd love to see CP/M running natively on a Raspberry Pi 3B, but... that much likely? Not to my knowledge.
>

Completely missing the point that portable CP/M (used in CP/M-68K) is
portable to any architecture for which you have a C compiler.

--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)

[roger...@gmail.com]

On Monday, August 12, 2019 at 5:02:51 PM UTC-7, Jared Falvo wrote:
> On Monday, August 12, 2019 at 12:56:27 PM UTC-7, roge...@gmail.com wrote:
> >
> > have you looked at cp/m-68k? that's written
> > in C; with a bit of work, it can be made to
> > run on other platforms; I've run it on ARM
> > and VAX.
>

> 680x0 is a dead end road... ARM would be the most likely contender, but...
> where? From what codebase?

from the cp/m-68k codebase. cp/m-68k is written in c. it can be ported.
i have done it. twice. you'll also want to grab some of the utilities from the
cp/m-8000 codebase; some of the cp/m-68k utilities are written in pl/m.

it is, admittedly, lonely being the only user of cp/m-arm in the world.

http://cpm.z80.de/source.html and scroll down.

> I'd love to see CP/M running natively on a Raspberry Pi 3B, but...
> that much likely? Not to my knowledge.

certainly not with that attitude.
--
roger ivie
roger...@gmail.com

[roger...@gmail.com]

On Monday, August 12, 2019 at 5:16:14 PM UTC-7, Jared Falvo wrote:
> If I cannot accomplish what I am desiring to, the way I want to, then perhaps
> there is another route. But then... it isn't CP/M being adapted... it's another
> OS becoming CP/M... and is it CP/M then?

cp/m-68k running on arm is, in fact, cp/m. the bdos and ccp are digital resarch
code. there's a bit of glue in the bios and i had to provide my own program
loader (as well as a mechanism to hook it into the ccp). there were some
byte-swapping issues that i had to deal with, but i made few changes to the
digital research code. it is real cp/m.
--
roger ivie
roger...@gmail.com

[Udo Munk]

On Tuesday, August 13, 2019 at 2:16:14 AM UTC+2, Jared Falvo wrote:
> CP/M is not DOS and DOS is not CP/M. DR-DOS was designed to compete with MS-DOS,
> which was (more or less) stolen from Gary Kildall by Tim Patterson, if I'm not mistaken in
> what I've read.

There is a lack of common sense here.
Either DOS was stolen from CP/M, then this is CP/M just distributed under another name.
Or DOS is not CP/M because it wasn't stolen and it is something different.

Both OS's have the same API subset, so that it was possible to build applications without much
effort for both, technical details are hidden from the applications in the inner workings
of the operating systems, as usual.

You claimed that CP/M needs to be ported, but that already was done numerous times
in the past, by DRI them self and by others. Maybe you don't like what was done, but
that won't be any problem, because CP/M was written in higher level languages like
PL/M, Pascal and C. Of course the targets were 16bit micro- and mini-computer
system in usage when the work was done, but these can be ported to any architecture
of course. As an extreme use the 1975 CP/M sources and compile into 32 bit code
with an Intel 386 PL/M compiler, their modern 64bit CPU's still can run 32bit software.

Of course DRI used the CP/M-86 sources as base to build an improved system later called
DR-DOS. That was their decision to stay competitive, at least for a while. If you don't like
what they did, no problem, pick up early sources and build an OS for modern hardware
your self. Then show it to us, we well let you know if we would like it more than what
others did ;-)

> GSX-86 is not GEM and GEM is not GSX-86.

DRI started to build GEM by using the GSX sources, the functionality still is included but
with GEM enhanced of course. Since no GSX-86 sources exist you can start from the
available GEM sources with building whatever, that is the realistic option.

> I don't want to touch things that are GPL'd (GEM is). You can't use/modify the code
> without being required to make it available to EVERYONE ELSE. I've got ideas in mind
> that are not GPL compatible. MIT/BSD licenses are "it" for me. CP/M is under such
> a type of license.

Licensing is another issue, but one thing is clear, whatever sources you use to start
from, you'll have to accept the license under which the sources were made available.
As usual, write your own stuff to avoid any license dependencies.

> If I cannot accomplish what I am desiring to, the way I want to, then perhaps there
> is another route. But then... it isn't CP/M being adapted... it's another OS becoming
> CP/M... and is it CP/M then? Not really. That's the sore spot... remaining pure to the
> origins of the OS. HaikuOS is not REALLY BeOS. It looks like BeOS and functions like
> BeOS, but it is it's own creature that people enthuse over, because of their great love
> for BeOS in the beginning.

Good question. Lets say you take the 1975 CP/M source to build a 32bit OS. It is not very
likely that you'll build Torode's floppy disk controller as PCI card for modern systems.
More likely you'll rewrite all that for more modern hardware, and while you are at it,
you improve filesystem limitations also. We want large disks and not tiny floppy drives,
and what not else.
After you're done with that 60% of the original CP/M sources were massively changed.
Is this still CP/M then or is this something else??

[s_dub...@yahoo.com]

Well said. As Allison used to express: CP/M is CP/M-80 on an 8080. -And I'll add - everything else is a 'port'. CP/M-86 is definitely a port of CP/M-80 in that it started its life as 8080->8088 code translation with a large bulk of added coding to deal with segmentation and design requirements that that infers.

The allure of cp/m (imho) is that it is small enough to be comprehended. -And that there are enough sources around to mess with it.

Let's not forget the system tools as a subject. Things like GENCMD had to be coded as well, then abandoned as the code base shifted closer to pcDos, and its relocatable objects (.obj) schema. Let's remember the initial DRI/Intel .obj format was different and incompatible with the ms .obj format.

(for Jared)
'The tools' is a chicken and egg problem. You end up needing cross development stuff at the point where things in the architecture are changed so that the old tools fail. Like the need for _asm86.com_ to assemble for 8086 code on the 8080 before the porting to _asm86.cmd_, for a hardware example. Same issues in software architecture changes. So, what modifications can be made that won't cause that, or are you prepared to hack/modify old tools, or build new tools, and on what system (win or linux).

Steve

[Jared Falvo]

Hmm... my previous post disappeared. Did no one even see it? About how the source(s) to GSX-86 are probably NOT lost? And the file I uploaded and the link I posted? *sniff* *sniff* I smell fish... :-D A conspiracy is afoot!

[Jared Falvo]

On Tuesday, August 13, 2019 at 6:20:30 AM UTC-7, Udo Munk wrote:
>
> There is a lack of common sense here.
> Either DOS was stolen from CP/M, then this is CP/M just distributed under another name.
> Or DOS is not CP/M because it wasn't stolen and it is something different.

No, 86-DOS (QDOS) was supposedly stolen from CP/M code... but that doesn't make it CP/M under a different name. That's absurdity. If it were CP/M under a different name, it would have functioned EXACTLY the same and been released by Digital Research! Like GSX becoming GEM. But it didn't. That's how he got away with it. If I take GEM code, modify it, then call it JYM and don't allow people access to the source code (as I'm sure was the case with 86-DOS/QDOS)... have I not stolen GEM code for my own purpose? Same thing with the CP/M and 86-DOS (QDOS) scenario. But that's the past...

>
> > GSX-86 is not GEM and GEM is not GSX-86.
>
> DRI started to build GEM by using the GSX sources, the functionality still is included but

> with GEM enhanced of course. Since no GSX-86 sources exist...

As for the GSX-86 source code not existing... well, the files I have seem to paint a slightly different picture, as I posted earlier (and my post disappeared). So, there may yet be hope...

> Licensing is another issue, but one thing is clear, whatever sources you use to start
> from, you'll have to accept the license under which the sources were made available.

And I happen to like MIT/BSD-styled licenses just fine.

> Good question. Lets say you take the 1975 CP/M source to build a 32bit OS. It is not very
> likely that you'll build Torode's floppy disk controller as PCI card for modern systems.
> More likely you'll rewrite all that for more modern hardware, and while you are at it,
> you improve filesystem limitations also. We want large disks and not tiny floppy drives,
> and what not else.
> After you're done with that 60% of the original CP/M sources were massively changed.
> Is this still CP/M then or is this something else?

It would still be CP/M, because I choose to continue to call it that and keep aspects of CP/M continuing forward, yet improving upon it's early foundations. The license, as given by the CEO of Lineo, gives full, unlimited permission to change CP/M however one wishes, with really no directives otherwise (not even a 2 or 3-clause BSD type one). But, why would I use an antiquated OS, like CP/M-86 to base a better, differently named OS on? It's absurdity. A waste of effort.

It's the desire to respect the accomplishments of the past (and/or the person behind it) that causes someone to take an old, antiquated piece of history and deliberately improve upon it, from the ground up (thanks to available source code), so that it is no longer obsolete, but usable today!

It would be FAR easier to take something like MichalOS (32-bit version of MikeOS), change it to function like CP/M-86, change the name to something like "CP/M-32" and say, "There! I've done it!" But, in all honesty, it's still MichalOS, just functionally changed and name changed. It's not CP/M-86. It never was. It's a type of lying... saying something is something else that it really isn't. And I doubt people (especially hard core CP/M enthusiasts and afficionados) would want to use something that really ISN'T CP/M... it just acts like it. Would you?

But, to go the OTHER way... you don't get AWAY from the legacy of the past, you HONOR it! But the difficulty factor, in that direction, goes up enormously! But that's what makes it CP/M... because it always *WAS* CP/M, from the beginning!

Haiku is called Haiku because it cannot be legally called BeOS. If it could have been, it would have been (and I'm sure existing source code would have been used), I'm sure. They tried naming it "OpenBeOS" initially, but walked away from that for legal reasons, I believe. But they did the best they could to honor BeOS in making Haiku as much like BeOS as possible... down to binary compatibility! But after about 19 years, the improvements grew vastly beyond what BeOS ever was, to the point that hailing the past is actually a disservice to the present! No one really cares about BeOS anymore... it's too old to really be of any use to anyone now. Haiku IS the present "BeOS", as it were.

But, if you take CP/M-86 and "step it up" to NASM code (which allows it to be broken out of it's 16-bit ASM86 limitations), you can then take steps to improve upon aspects of CPM.SYS, while keeping others. If it were not for the inherant benefits of Assembly Language over C code, I think taking CP/M-68K and porting it to the 80386 might actually be a good choice. But I believe in Assembly Language enough to desire to stick with that. And I'm not even a programmer!

Start with CPM.SYS. Refine it. Modernize it. Make it the best it can be. Then go out from there. One "Transient Program" at a time. Then GSX-86... then a GUI (using GSX as the pure foundation)... then... the sky is the limit!

And someday, people could be using an OS that is still (honestly) called CP/M... yet spans a functonality range that rivals any OS made today. And I think that'd be really, REALLY cool!


It's not impossible. It just takes a little vision and desire and ability... and someone's money. :-D

"Never Give Up" by Luposian (me!)

Progress is progress, no matter how slow.
Remember the tortoise, wherever you go.

The rabbit was faster, we know by his pace.
But the tortoise was better, 'cause HE won the race!

[dott.Piergiorgio]

On 12/08/19 07:26, Jared Falvo wrote:

> One thing I am trying to figure out... is the source code for GSX-86 available? I've found a couple things that say GSX-86 driver sources and GDOS1.1, but I'm not sure if that's actually GSX-86, the program that enables graphical output on screen and printers and such. Can anyone confirm?

to be frank, after years of exposure to those ugly white/magenta/cyan
palette, personally I'm interested only on the hercules and CGA hi-res
monochrome, the "colour" CGA is something I don't want to do anymore

(still looking for a way of patching DOSBOX EGA/VGA/SVGA driver sources,
excising out the least desired backward compatibility)

sorry for the rant, and

Best regards from Italy,
dott. Piergiorgio.

[dott.Piergiorgio]

On 13/08/19 15:20, Udo Munk wrote:

> Good question. Lets say you take the 1975 CP/M source to build a 32bit OS. It is not very
> likely that you'll build Torode's floppy disk controller as PCI card for modern systems.
> More likely you'll rewrite all that for more modern hardware, and while you are at it,
> you improve filesystem limitations also. We want large disks and not tiny floppy drives,
> and what not else.
> After you're done with that 60% of the original CP/M sources were massively changed.
> Is this still CP/M then or is this something else??

Being a Naval historian, I must note that your reasoning was known in
ancient Greece, the Theseus's ship paradox...

[Randy McLaughlin]

The law is simple if you take someone else's code and modify it and end up with only one line of the original code then it is stolen. This is why when a company wants to copy something they use a double blind where one team precisely documents what it does and another team uses that definition to write the new code without ever seeing the original. Of course you don't need a double blind test if you never see the original source code, you can observe what it does and write your own to match.

This is why Apple lost against Microsoft in a look and feel lawsuit.


Randy

[Tom Lake]

MS might have won but Digital Research LOST the Apple look-and-feel lawsuit caused by their GEM interface. They got around it by changing the look slightly.

[Jared Falvo]

Thankfully, in an open-source environment, you're never "stealing" code, unless you don't abide by the licensing terms. :-D

[Udo Munk]

On Wednesday, August 14, 2019 at 8:47:56 AM UTC+2, dott.Piergiorgio wrote:

> Being a Naval historian, I must note that your reasoning was known in
> ancient Greece, the Theseus's ship paradox...

But they considered replacing of original parts like the planks with exactly the same new parts
and using the old parts for a new ship as paradox already.

Here we cut down the mast, take out the thwarts and replace that with a steam engine,
and then some. This still is a ship, but certainly not one anymore used by Theseus.

[Randy McLaughlin]

The old story of the man that still owns the axe his grandfather had. Its handle has been replaced 8 times and the head twice but it is his grandfathers axe.


Randy

[Tom Lake]

We used to debate about exactly when the ship was no longer Theseus' ship. Does replacing one plank make it not his ship? If not, how about two? Three? You get the idea.

[Randy McLaughlin]

In the case of a car if you replace the engine does it have to be re titled, no. You can replace every single piece of a car and it remains the same car, the title, ownership, and all legal rights remain. The same goes for hammers, axes, and software.

To have a new car, axe or software you must start as unique not something else first. That is not just a belief it is a legal standard.

In the case of say a car if you take two cars and swap parts to build one car you can use either title and the other title can either be lost or you can get enough parts to rebuild the remaining parts and have two titled cars. If you merge two pieces of software then both pieces rights remain in the new product.


Randy

[Tom Lake]

Yes but in the case of Theseus, he's long dead. If every plank, fastener and rope were to be replaced, then he had never even seen let alone touched any of them. His feet never touched the deck, his hands never touched the gunwale, tiller or wheel. If he were to come back, he'd know immediately that this wasn't his ship. The feel of the ship would be different. The smell, the sounds the ship makes would all be different. He might not be able to explain how he knew but he'd know in his gut that this was a different ship.

[dott.Piergiorgio]

no, I think you're mixing up things... M$ lost against apple, about
wsozz 1.0 UI and the result was wsozz 2.0 with not-so-slight changes to
the UI. and the cause wasn't on the source code (written for really
different hardware...) but on UI features ("look-and-feel")

on the "stolen" code, apply, for obvious reasons, to compiled
closed-source software, but this require disclosure in court of the
stolen lines of code.

on assembled "closed" source stealing by reverse engineering can be
proved because of the 1:1 of the correlation between source and binary
(abstracting from macros, of course)

this is why the legal framework of CP/M era was solid, and mutually
profitable: hardware vendors don't buy only the license, but also buyed
the right to adapt CP/M to their machines (hence the babel of disk
formats we known) and bundle the modified CP/M on their products. I
think was analogous to the OEM/VAR market model, or I'm wrong ?

[dott.Piergiorgio]

On 15/08/19 04:25, Randy McLaughlin wrote:
> In the case of a car if you replace the engine does it have to be re titled, no. You can replace every single piece of a car and it remains the same car, the title, ownership, and all legal rights remain. The same goes for hammers, axes, and software.

In Italy, car and engine are considered different, In Italy the
registered serials are two, framework (telaio) and engine and the
license plate is indeed linked to the framework, but the engine serial
is recorded on the car's license of circulation "libretto di
circolazione" and is mandatory recording the new engine serial if the
engine is changed.

[dott.Piergiorgio]

by this logic, applied to Lord Nelson and Rodgers, Hull, Bainbridge,
what matters should be the aftermost third: it's a reasoning whose can
be argued in philosophical circles, but definitively not in Naval
circles. I daresay, a preposition harmful to the philosopher if
argumented before sailors and Naval Officers.

[Jared Falvo]

On Wednesday, August 14, 2019 at 6:05:16 PM UTC-7, Randy McLaughlin wrote:
> The old story of the man that still owns the axe his grandfather had. Its handle has been replaced 8 times and the head twice but it is his grandfathers axe.
>
>
> Randy

In this case, had his grandfather never owned (or given him) the axe to begin with, there would be no axe to make this assessment with. But BECAUSE it was originally his grandfather's axe, replacing the handle and head makes no difference, because he owns it BECAUSE his grandfather owned it first. Now the mere existance of that very axe, itself, continues the lineage of it being his gransfather's axe. It's a legacy thing. It doesn't make sense from a tangible, physical angle, but that doesn't matter to some people. The emotional attachment is all that matters. "I own this item, BECAUSE my grandfather had it first."

[hper...@gmail.com]

What if I go to the axe graveyard, find the original discarded handle and head, and put the two together? Would that be his grandfather's axe or not? Two grandfather's axes?