6502.org

The idea to create a CP/M alike OS for 6502 computers is not really new. In fact, there are a couple of approaches on 6502.org. Nevertheless I started my approach in 1988 on my Elektor Junior Computer blissfully unaware of any other approaches and now in 2022 it is still alive, healthy and active. So I guess its worthwhile to share it with the community.

The repository is on GitHub https://github.com/dietrich-l/CPM-65

It contains CPM-65, a CP/M-80 analogue operating system for 6502 based microcomputers

System Requirements
--------------------------
6502 processor
12 kByte RAM (not tested)
6532 I/O chip for the system timer (could be replaced by a 6522 or other)
min 1 Floppy drive
Serial-I/O

My system is a heavily modified and expanded Elektor Junior Computer with 57 kB RAM. For system components and memory map see separate docs

System Structure
--------------------
CPM-65 consists of 3 layers:
- BIOS Basic I/O system - currently 3 kB, could be reduced to 2kB by removing SCSI and I2C drivers. Drives can be A-H non consecutive. I/O console is serial TTY 1200 - 9600 Baud
- BDOS Basic disc operating system - this is the CPM-65 kernal. Size 2 kB
- CCP Console command program - a simple console which only allows to invoke CPM-65 programs. No resident commands. Size 1 kB

File & Disc Format
----------------------
Filenames are CP/M-style d:filename.ext with d <Drive A-H>
Programs must have .COM as extension and are loaded to $0200 and started there.

The directory structure is CP/M-compatible and can be read with appropriate tools like CPMTOOLS

The Disc format is typically 40 tracks/ 8 sectors/ 256 byte/sector. It is defined in the BIOS. The BDOS operates on sector numbers. Maximum sector number is $800 blocks with $20 sectors = 65536 sectors á 256 bytes = 16 MBytes

Software List
---------------------
Name Version
ALLOC 2.8
ASM 2.5
BASIC 1.4
BDOS 2.2
BIOS 3.0
BOOT 1.7
BOOTPROM 3.0
BROWSE 1.0
CCP 1.5
COPY 1.4
D 2.0
DATETIME 1.1
DEBUG 1.5
DRUCKER 1.0
DUTIL 1.5
EPROMMER 1.2
ERASE 1.5
FORMAT 2.4
FORTH 1.6a
HEXMON 1.1
I2C-UTIL 1.2
RENAME 1.1
RFILE 1.1
SCSIMGR 1.1
STEP 1.0a
SUPERTAP 1.4
SYS 1.5
SYSGEN 1.0
TYPE 1.6
XMODEM 1.2

All software is supplied as assembler files to be assembled with the CPM-65 assembler. In case you wish to use a different assembler, the syntax has to be adapted accordingly.

Documentation
--------------------
Currently the documentation of CPM-65 is sparse and only for my personal needs. I plan to write appropriate docs over time. If there are any whishes, please open a DISCUSSION

Errors
--------------------
The CPM-65 system has now seen more than 30 years of service. Currently there are no known errors. However, since an error free software does not exist, please report any errors in the ISSUE section

Other related systems
---------------------
When I started the development of cpm-65, I was blissfully unaware of any other aproaches. However there are some, most notably:
- DOS/65 by Richard Leary. There is a limited compatibility
- OUP/M by Jiang - Xiong Shao. Published 1983, no further development
- CPM65 by David Given, published 2022


Redistribution
--------------
Source code, and all documents, are freely redistributable in
any form. Please see the the COPYRIGHT file included in this
Repository.

Any comment, suggestions and code stealings are highly welcome

Enjoy
Dietrich

Fantastic! Especially
> The CPM-65 system has now seen more than 40 years of service.

Ok, I exagerated. It must read 'more than 30 years of service'.

My trusty Junior Computer on the other hand has more than 40 years of service - 41 to be exact.

Dietrich

This is excellent!

I just ported Richard Leary's DOS/65 to CRC65, a 6502 single-board computer. I'd love to port CPM-65 to CRC65 as well. So what kind of hardware functions do CPM-65 need? CRC65 has 58K RAM, a serial port, compact flash, I2C, and expansion bus to off-board peripherals. It has no timer, but can interface to RTC via I2C bus. I implemented DOS/65 without using interrupt; is interrupt service required? Do CPM-65 programs must start from $200 or can that be moved by re-assemble the source codes?
Bill

Edit, A "Chicken and Egg" question: All programs are assembled by the native 6502 assembler but the native assembler must first exist as an executable program. So what tool you used to assemble the native assembler and load it into a new system?

The timer is used mostly by BIOS to shut down the floppy drive motors after 5s and to have a timeout when checking on floppies and scsi drives. Also the BIOS offers 2 user timers, but only very few programs use them. So you can take timer support from the system and modify your BIOS accordingly.

However the debugger needs to point the BRK vector to its break entry point. So a proper IRQ handling is required. I do this in the Bootprom, which also holds a large part of the BIOS.

Dietrich

To get the ASM on your system, I recommend to adapt the syntax to your assembler. I many cases this is relatively easy done with search&replace, depending of course on your assembler. A little tricky is the way, I generate the high byte of a 16 bit label. Its done by calculating LABEL/256. I have added my ASM test files TEST.ASM and TEST.APP to the repo to show a little bit better how the syntax works.

Also your operating system has to provide sequential file R/W. So you may need to provide that. CPM-65 reads/writes 1 page per call.

Around 1987, when i was usind the OS65 assembler, I had to split the code in 3 parts because this assembler could only generate around 2 kB code on my system at the time. Today it should be easier.

Sorry for not supplying a better migration support, but since this is a one time effort, I never again had the need to think about it.


Dietrich

The starting point for all CPM-65 programs is the TPA, which in my case starts at $200. In my sources its always set as a Label - TPA =$200. Thus it can be easily moved. Some programs check for HIMEM by checking for the BDOS entry vector. So you need consecutive memory up to the CCP in those cases.
Since the CCP loads the programs to memory, you have to change it too, obviously

Dietrich

I ported BDOS, CCP to CA65 assembler. It is relatively easy, mostly converting DS, DB, DW, DD to .res, .byte, .word, .dword. I also use the '#<address' and '#>address' to replace LDA #address and LDA #address/256. I see CCP starts from $D800, followed by BDOS at $DC00, then BIOS at $E400. Top of my RAM is E7FF so I'll need to move CCP/BDOS down by 2K bytes to give BIOS more room. For now, I can work with existing memory allocation. My immediate goal is writing the minimal BIOS functions so it can cold boot, display sign on message, and show the CPM-65 prompt.

Looking at the BIOS code, BOOT, WBOOT, CONST, CONIN, CONOUT are simple enough. I need to understand the disk parameter header (DPH) to work with HOME, SELDSK, SETTRK, SETSEC, READ, WRITE routines. The DPH looks familiar to CP/M80, but not quite the same. Could you tell me more about it?

Maybe it is better for me to describe what disk format I like to have. I hope to use the same disk format of CP/M80; this way I can transfer CPM65 files while in CP/M80 environment and move the CF disk over to CPM65 environment and have all CPM65 files already installed. The CP/M80 DPH for drive A looks like this:
The reason there are 1024 sectors per track is to simplify calculation of track and sector to CF disk's logical block address. The track offset of 1 is important because the first track contains bootstrap/monitor/CCP/BDOS/BIOS.

Thanks for your help.
Bill

@plasmo - Congrats so far

My DPB is part of the BIOS and similar to CP/M-80 - here for drive e:, which is an SCSI HD with 512 byte/sector
You will notice, that BDOS handles only 256 byte sectors. All translation into physical tracks and sectors has to be done in the BIOS see BIOS-Call SETSEC and the drive specific code in BIOS
So the setup is very close to what you want to have

Dietrich

Thanks for the DPB description.

I have not made as much progress as I've hoped. I start off wanting the disk format to be compatible with existing CP/M-80 and DOS/65 format so I can transfer CPM65's files across. That approach ran into problem with SYS being 512 and I don't know how to accommodate that in disk parameter header. I also don't know how to work with directory mask (DIRMSK) parameter. The first byte of Block Allocation Table appears to be a mask of some sort, I also not sure whether it needs to modified or not.

My latest attempt is to preserve the original disk parameter header of your BIOS and use just one drive, the original drive F is now drive A; Floppy disks are removed. I also preserved the original memory allocation for CCP, BDOS, and BIOS which are $D800, $DC00, and $E400, respectively. I only have 1K RAM from $E400 to $E7FF, so I put DMA, DIRBF, and SCSIBUF starting from $D000, which will cause problem if a big program is loading in CPM65, but I'll figure that out later. However, it still is not working. By "not working", I meant it did print the CPM65 sign-on message embedded in BOOT routine and access the CF disk briefly but it didn't display a CPM prompt.

I have a few questions:
1. 6502's carry flag is used to signal whether a routine has executed successfully or not. The CONST, CONIN, and CONOUT routines are ROM calls so I do not know the protocol for indicating data is available in CONST or whether carry flag needs to be cleared for CONIN and CONOUT.
2. CP/M-80 has a BIOS routine for DMA. I did not see that in CPM65 list of BIOS. So is DMAV set somehow and I can use DMAV for disk operation?
3. The CP/M-80 track and sector seem to be replaced with 3-byte SECS. I'm guessing SECS is like sector, SECS+1 is like track, and SECS+2 is like head. If sectors and tracks are power of 2, it may be as simple as a shift right one bit of the entire 3-byte SECS and the resulting values become the Logical Block Address?
4. at the end of the BIOS BOOT routine, there is a JSR to BDOS with regX set to $E, followed by JSR to BDOS with regX set to 0. What does JSR to BDOS with X=$E do?

Attached is my BIOS assembly and listing. I hope you can look it over and give me some feedback. Thanks,
Bill

Dietrich,
I have new development on porting CPM-65:

The BIOS has not changed, but I changed BDOS. This is because I didn't know what 'DD' directive associated with command table BEFTAB does in the original assembly, so I substitute '.dword' which was a mistake. BEFTAB is collection of jump tables invoked by push high jump address byte into stack then low jump address byte into stack then execute a rts. So 'DD' directive probably rearrange the table so high address is first and low address next so the BDOS routine will push the correct byte order into stack and execute rts. I separated the jump table into high address bytes table, BEFTABhi, and low address bytes table, BEFTABlo, and re-wrote the BDOS dispatcher. Attached it the original BDOS.ASM and modified BDOS assembled by CA65.

With the BDOS modification, I now have CPM-65 sign on, follow by A> prompt. If I enter a 'd' it responded with BDOS Error $DD because 'd.com' does not exist. OK, I'm making progress.
Bill

Hi Bill, glad to see you making real progress really fast.
Regarding 'DD', you got that right. My assembler knows 2 directives to place 16 bit values in code: Thats sometimes handy, but you found a valid solution anyhow.

I quickly skimmed above your modified code - looks good. And definitely your system prompt indicates, that essential functions of the systems are there especially console input and disc read commands.

Dietrich

SYS is a L/M/H value of the reserved logical sectors (i.e. 256 bytes) at the beginning of a disc. These sectors are not counted by BDOS, i.e. first usable sector on a disc is always $000000. If your system needs 512 sectors a 512 bytes, SYS = $000200, if it's 512 sectors a 256 bytes, SYS = $000100.
DIRMSK marks the directory blocks in BAT permanently as occupied, thus preventing BDOS using them for file storage. It is actually the first byte of the BAT and just copied into it before BAT is rebuild, e.g. after a disc change.
You should place DIRBF and SCSIBUF above BIOS to prevent programs accidentially overwriting those. DMA can be placed where you want data loaded or saved by BDOS, e.g. to load file (see CCP) 1. Carry set indeed signals an error condition in BDOS and also BIOS calls. It never needs to be reset. However, I was a bit inconsequential. Some calls, where errors are impossible by design, do not report a valid Carry, e.g. CONST, CONIN, CONOUT. I definetily have to write some documentation...
2. Right, BDOS does not handle DMA. The DMA is a fixed vector in page $00 (DMAV = $FE). CCP uses it and all user programs which need disc I/O
3. Right SECS/SECS+1/SECS+2 is a 24 bit LBA with fixed sector size of 256 bytes. So yes, the BIOS has to translate is in real disc parameters. The calculation of SECS is handled in BDOS and uses the DPH.
4. BDOS_$0E logs in the current drive defined in DEFDRV. It sets the DPH-values and resets some flags. BDOS_$00 is a warm boot resetting some BDOS vectors and parameters and calling the CCP

Regarding your BIOS code, this is where most changes have to be made, because this is the interface layer to your specific system. I suggest to replace my code by as many of your system monitor functions as possible. CONST, CONIN,CONOUT,LIST should be easy. For the disc ops, there is more to do
SELDSK sets DRIVE and selects the correct DPH
READ reads the 256 byte block defined in SECS to the memory location defined in DMAV ($00FE). So here the translation from logical sectors to physical sectors, tracks, side etc. has to be made including a blocking/deblocking for sector sizes other than 256 bytes.
WRITE same for writing a sector
SELDSK, READ and WRITE set carry if an error occurs

It seems you got it mostly right already

I will be travelling for the next 2 weeks, so I might be a little slow to react

Dietrich

Thank you for your detailed reply. You've resolved most of my questions. I do know putting DIRBF, SCSIBUF, and DMA below CCP can be problematic but I have insufficient space above the original BIOS memory allocation to accommodate these big buffers. Now I have a better understanding, I'll relocate BDOS, CCP so to give BIOS more space.

I'm still confused about DIRMSK. In the original BIOS there are 32 sectors designated for directory, so that's 256 directory entries and value of DIRMSK is %10000000. I want to have 512 directory entries so that's 64 sectors for directory. What should the DIRMSK value be?

*************************************************
The question now is how to get CPM65 files into the CF disk. In CP/M-80 I would load the XMODEM binary in TPA, start CP/M and use CCP's 'Save' command to create XMODEM.COM and then use XMODEM to bring in rest of the files. 'Save' command is not in CPM65's CCP, but I can still load XMODEM binary in TPA, patch the CCP so when CPM65 starts up, it jumps to TPA to execute XMODEM binary. There is a 'cflag' for CPM65's CCP that may be used for this purpose?

But this morning I tried another method to load CPM65 files into the CF disk. What I did was modifying DOS/65 disk format to match CPM65 DPH and use DOS/65's XMODEM to copy CPM65 files to the CF disk. I also assembled d.asm using CA65 assembler and copy the resulting d.com to CF disk. The screen shot shows the results. First half of the screen shot shows DOS/65 booting up and display the content of drive A which are the CPM65 files I previously xmodem over. I used DOS/65's 'go' command to enter my monitor and load CPM65's BDOS, CCP, BIOS and start execution at BIOS's BOOT @ $e400. 2nd half of the screenshot shows CPM-65 boot up and I entered 'd' to invoke d.com which display the CPM65 files. Pretty cool, huh.

Still lots to work on but I think I have a good grasp of CPM65 now.
Bill