Well, based on CP/M documentation (V2.2) the BIOS is responsible for defining the disk organization. By design, CP/M was based on the IBM 3740 diskette layout, i.e., 77 tracks, 26 sectors, 128 bytes per sector, single sided. This is what BDOS logically works with. As Western Digital (not WDC) made IBM compatible diskette controllers (as did Intel with the 8272 and Nec with the 765), that's what was available in the early days.

I did find the CP/M 2.2 Alteration Guide on bitsavers... it shows a sample BIOS and details the DPH (Disk Parameter Header) which defines the various drives accessible by the BIOS and the DPB (Disk Parameter Block) which defines the allocation of directories, data, allocation bits and system tracks. As these are built into the BIOS, it's no surprise that different systems might not be able to read or write diskettes from another system. The Guide does however, suggest that a standard IBM format diskette setup be maintained specifically for compatibility. Note that the DPB is not maintained on the diskette media, hence the swap problem between systems. This was addressed in later DOS releases as additional diskette formats became available and was contained in the first physical sector as part of the BPB (BIOS Parameter Block) and IIRC it's when the magic number 0x55, 0xAA came in at the end of the boot sector.

On the Commodore drives that Mike mentioned (1571 and 1581) these drives use Western Digital floppy controllers (WD1772) which natively support the IBM 3740 and System/34 formats and allow additional flexibility for 512- and 1024-byte sector sizes. With some downloaded code to either drive, you can directly access the FDC and read/write sectors directly, bypassing the onboard DOS contained in ROM. This would allow direct access to pretty much any supported format that the WD1772 provides, but you still need to determine the DPB for CP/M and manage deblocking if the sectors are not 128-byte sized. Having a couple 1581 drives, Commodore used 512-byte sector sizes (like the IBM 3.5-inch diskette) but stuffed one extra sector on a track to get 800KB versus 720KB on the standard IBM formatted diskette (non-HD diskettes). This might account for some odd errors... I know for a fact that IBM did exhaustive testing on diskettes to finalize the formatted structure with the required gaps and such between sectors (ID fields, data fields, etc.).

In any case... where am I going with this.... hmmm. So, as all of this gets handled in BIOS, it might make sense to try and manage this in the BIOS for devices which will not be diskette based. Any other storage media (IDE devices, SCSI, Compact Flash, SD Card, etc,) default to 512 byte block sizes, so keeping the required parameters for the storage media would make sense, especially withe any removable media (CF Card, SD Card, etc.) so the BIOS can load the DPB and provide the correct drive details to BDOS.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

CP/M disk formats are a pain --- CP/M is a software standard, not a hardware one, as of course Digital Research couldn't mandate what kind of disk controllers or physical medium each vendor was going to use, and this was all too early for there to be any kind of standardisation. Plus, even if you have compatible hardware, the file system itself isn't self describing in any way. Block size, directory size, number of blocks on the disk and the dreaded sector translation table are all baked into the BIOS and can't be easily determined from inspecting the disk.

Some platforms (added BIOS support for detecting the format of a given disk, but this was of course vendor specific and not at all standardised. And you still need disks which are physically compatible.

Agreed that CP/M disk formats can be annoying. Bottom line, CP/M doesn't manage them. It simply uses what the BIOS presents for sectors and tracks and the disk parameter block which defines the details for the rest of it.

Now, as you're porting CP/M to the 6502, you've chosen two platforms (initially)... the BBC Micro (with extended versions) and the Commodore 64. In both cases, you have to "shoehorn" a disk specification in their respective disk drives and manage the track and sectors available along with the disk parameter block. In short, you're defining the BIOS disk parameters that CP/M will ultimately use. That's perfectly fine, as you don't have a choice.

If you decide to extend your platforms, you might as well define some sort of standard for the BIOS to present a set of drive parameters to CP/M. For the most part I don't see CP/M 65 being an alternative OS that people will run on retro hardware, they already have their default software environments. I see more of a use with folks designing and building 6502 type systems and looking for some sort of lightweight OS/Filesystem they can use, without having to write one on their own. Of course, I could be dead wrong... who knows.

But if the latter proves to be the case, the storage media that will likely be used will be block based (not CHS) and using more common hardware like SD Card, Compact Flash and standard IDE devices. And yes... some folks have implemented SCSI block devices for storage. Once again, selfish switch on... but looking to define a standard block based interface to mate up with CP/M 65 could result in a larger audience for it's adoption.

Once again, just my $0.02.

_________________
Regards, KM
https://github.com/floobydust

Since many may be using emulation instead of real hardware, it is probably beneficial to designate a standard distribution disk format.

To encourage adaptation, it may be beneficial to distribute pre-built binaries for the BDOS, CCP and the transient commands similar to the way CPM-80 did it. People can then use any assembler they want to build their BIOS.

CP/M actually already has that --- the BIOS describes the disk format to the BDOS, and then just provides get sector / put sector calls. Original CP/M used track/sector addressing but I'm using block addressing for exactly the reasons you say. (Even original CP/M didn't really do track/sector. If the BIOS wanted, for example, to put data on both sides of the disk, it would usually pull the head number from the LSB of the track and lie to the BDOS about the disk layout.)

I do think that having self-describing disks is a good idea. Defining a standard superblock sector which contains the BDOS disk layout would be easy. The BIOS can then read this and pass it to the BDOS. This would very much be an opt-in thing by individual BIOSes and not actually part of the core BDOS.

(Just to note, on Acorn's platforms it's not too unusual to use a native filesystem to hold an image of a foreign filesystem. Although, it adds a potential performance problem: sector access is fast, AIUI, whereas random access into files can be slow.)

Has anybody done anything further with this?

The relocatable binary idea showed so much promise. It would be a shame if it faded away.

Not that I've seen... looking at David's Github repository, the last updates go back 3 months. I've not had a chance to to do a deep dive into his second release of the code, but the toolset he uses is not one I'm familiar with, so trying to modify the source code for what I use doesn't look that straightforward, but again... no deep dive as of yet.

_________________
Regards, KM
https://github.com/floobydust

I finally got around to trying to watch the final episode "to see how the movie ends" and discovered that doubling the playback speed made it actually quite watchable.

Using that trick, I went back to #3 to #n-1

Episode #2 is still a snooze fest though. But I digress....

I noticed a hex dump of the DUMP command in the last episode, paused it, keyed it into my machine and reverse engineered the file format to fill in the gaps in the description on GitHub.

Then I modified my 8080 simulator to load that instead a CP/M-80 flat .COM file.

If I find the motivation, I may

1. Rip out the 8080 simulator and connect the BDOS and BIOS calls directly to my CP/M to FLEX conversion code. This will allow me to run a CPM65 program on FLEX
2. Modify my 6502 cross assembler to generate a relocatable CPM65 binary
3. Port the 8080 simulator to CPM65 using my FLEX development environment

Why do this? Converting CP/M style system calls to FLEX calls has been very troublesome and I do not believe that I can properly emulate every system function. The is not a problem if I run a CP/M-80 program and convert system calls to CPM65 calls.

That is why I came here to see if there had been any new developments.

I got distracted by other things --- Christmas, catching Covid, writing a novel...

The biggest missing piece is a native assembler. It turns out that adding the requirement to produce relocatable binaries substantially increases the complexity of the assembler. It needs to keep track of which symbols are absolute and which are relocatable, plus the appropriate logic in the expression evaluation, and also needs to somehow keep track of the relocation table itself for emission, making memory management harder. There are also design constraints to juggle --- keeping all the data structures in memory is dramatically faster, but 6502 systems are typically fairly short on RAM and if the system's intended to be self-hosted it may need to be a disk-based assembler. Also, I really want it to be in C so I can use the assembler for cross-compilation.

Native support has been upstreamed into LLVM-MOS, so you should be able to write C and assembler programs with their toolchain and it should Just Work. But I'm not very happy about requiring it as a prerequisite because it's vast, rather quirky and requires a different syntax for anything which will run natively. But writing complex tools in raw assembly is a PITA, and even DR thought so.

I am glad you recovered from COVID. I hear there is a lot of that going around...

NaNoWriMo or something else? I almost went down that rabbit hole...


We are in the same boat. One of the reasons I have been holding off on releasing FLEX is the lack of a native assembler. Luckily, the FLEX 6800 assembler source is available. Unfortunately, modifying it to handle 6502 instead of 6800 has not been easy, particularly handling the many addressing modes. I am making headway, however. Further challenges include:

* As with many assemblers (especially native) from the time, expression evaluation is strictly left-to-right instead of algebraic priority and it does not allow the use of parenthesis to specify priority. I have become too used to the latter
* Allow putting a colon after a label
* Symbols are limited to six significant characters and I want more
* Cannot use underscore in a symbol
* Directives are naturally Motorola style and some of the 6502isms are very different
* File inclusion can only be nested a single level; I need at least two
* My FLEX code depends upon conditional assembly to configure for different platforms, especially for the ROMmable version
* I have become dependent upon using local labels, so I will also need to add that

My approach has been to break it up into several smaller projects:

* Port the 6800 assembler to the 6502, yielding a 6800 cross-assembler running on the 6502 - done.
* Assemble 6502 instead of 6800, yielding a 6502 cross-assembler running on the 6800 - coming along
* Add the above desired features into the 6800 native assembler - barely started
* Combine all of the above into a native 6502 assembler


You may be able to increase adoption by doing what Digital Research did, namely provide pre-built binaries for everything possible so that someone can use their current toolset. Also provide images for the boot disks you are using for development.

That is the dark side of open source. You not only get to build it from the source, but you often have to which requires getting the toolchain going first. Linux would not have gotten going if everybody had to bootstrap up instead of merely downloading and installing a distro...

Edit: I thought you were off converting the 8080 assembler you had previously written into a 6502 assembler for CPM65.
Further: Added to comment about expression evaluation

Something else worth porting to CPM65:

I have been working on a SWEEP workalike for 6800, 6809 and 6502 FLEX.

What is CP/M without SWEEP?

Belatedly: I have finally written about 3/4 of a functioning assembler for CP/M-65. It's good enough to compile small programs and produce native binaries. It's about 1800 lines of C which compiles into an eye-watering 11kB of 6502 code but even on a BBC B there should be enough spare RAM to compile at least something. And I recorded it all! Do you like very long, boring live coding videos?

http://youtube.com/watch?v=qT2Efjein68

It reads and heavily tokenises the source in one pass, so that it can do subsequent passes from memory. It seems to want about half the source file size in RAM. Given that my BDOS source is 56kB, then that bodes well for actually assembling it natively, although the syntax is different so the source will need heavy editing. It supports my structured programming pseudoops, but no macros, include files or, er, any expression parsing beyong 'label + constant' so far... although you can work around that with equates.

https://github.com/davidgiven/cpm65/blo ... apps/asm.c

So the only remaining piece of the puzzle to produce an actually useful (for some definitions of useful) operating system is an editor. CP/M traditionally uses edlin. I've found a copy of the original PL/M source, and bleagh.

Does anyone know of any existing ports of something like edlin for the 6502 that I might be able to rip off, I mean, reuse? Was the DOS-65 source ever confirmed to be GPL? At one point someone told me about a third CP/M for the 6502 project, but I can't find their message now...

Hi David,

As far as the license status of DOS/65, here's the last V3 ROM Supplement (PDF) that I received from Richard Leary when I was initially working with his ROM version.



Near the bottom of the first page, it states the following:



Hope this helps.

_________________
Regards, KM
https://github.com/floobydust