6502.org

I'm getting this peculiar urge to port CP/M to the 6502. I need help.

So, what I'm thinking about is a fairly simple rewrite of CP/M 2.2, initially targeted at something like a C64 with 1541 disk, although I'd like it to be portable (I have more experience with the BBC Micro). This consists of a BIOS, containing all the platform-specific stuff, the BDOS which has the filesystem and I/O layer, and the CCP command processor which gets loaded on demand.

The biggest issue is that the 6502 and the 8080/Z80 tend to have dramatically different address space designs. The former likes memory-mapped I/O, the latter likes I/O instructions. This means that the userland in CP/M systems all tend to be very similar: lots of RAM starting at 0000. Programs can be compiled at the fixed address of 0100 and they'll run on anything. (There were some CP/M systems with a different base address but they never prospered.) 6502 systems have zero page at 0000, the stack at 0100, vectors right at the top of memory, I/O scattered throughout --- the C64 has video memory from 0400 to 0800 IIRC. Then there's zero page. The C64 has the MMU registers at the bottom. The BBC Micro Tube has the Tube workspace at the top. So, your program load address will vary depending on system.

So, I thought that to be at all useful, you'd need relocatable binaries. This would allow programs to be loaded anywhere. But, simple relocation isn't enough as the system would also need to assign zero page addresses. This shouldn't actually be hard using the traditional approach of adding the required address to bytes in the program (either high byte of load address or low byte of zero page address). It would also have the side effect of making it easy to implement TSRs, which would be a nice bonus and is something that CP/M was never very good at. This means that the same program could be loaded at 0400 on a BBC Micro Tube system with ZP starting at 00, or at 0800 on a C64 with ZP starting at 02. (Or at 0200/00 on a PET.)

Size-wise I would expect the 6502 version to be similar to the 8080 version: the BDOS is 3.5kB, the CCP is 2kB. So, on a C64, assuming a 2kB BIOS, you'd get about a 55kB TPA, which is respectable. A BBC Micro Tube system would get a bit more. A stock BBC Micro B would get 17kB in MODE 7, which is pretty miserable. A BBC Micro in mode 3 would get about 4kB, which is pathetic, but at least it would run.

In terms of prior art: I know of DOS/65 by Richard Leary, but it's got an encumbered license and so I can't use it; and OUP/M, which has no license at all and is specific for OSI machines, but is very similar to what I have in mind. So I know it's possible. Have I missed anything?

Is the license actually an issue?

I read this on the original site:
Which seems fine to me for personal use. Even if you give it away, then that still looks fine to me. Or are you thinking of selling it?

Also, are you aware of another effort to port this too?

https://github.com/floobydust/DOS-65-V3.03-ROM

Been mentioned here a few times - Although it's derived from the original DOS/65 (as far as I know) there's no license obviously attached to it.

However, since you mention the Beeb - why not an Acorn MOS compatible system? The only issue I had when I did mine was that the filing system requires 2 extra attributes to be stored with each file - namely load and execute address for binary images. Then you can just /basic to load basic, or whatever application you like at whatever address you like with the OS living up at $C000 upwards...



Cheers,

-Gordon

Just a quick follow-up to this - here is a demo of my own version of the Acorn MOS running on a serial terminal - the first few minutes anyway and although it's running on my '816 system the effect is the same. Simple command-line with history & editing, a few built-in utilities and a way to run disc based programs. (And loaded programs can access the command-line if needed to pick up parameters, etc.) and there is a conversion "shim" in the terminal handler that converts Acorn VDU commands into (in this case) ANSI Terminal escape sequences. It normally runs with a "smart" terminal which is a Linux executable which does the VDU interpretation for text & graphics but the ANSI bit is a fall-back for when I just run minicom or other serial terminal application on my desktop.

https://www.youtube.com/watch?v=Bg-DcjrJ8g0

Cheers,

-Gordon

Richard has given me permission to publish what is available for DOS/65:

http://retro.hansotten.nl/6502-sbc/dos-65/ for 6502.

also check https://github.com/floobydust/DOS-65-V3.03-ROM for a working version (65c02 mostly)

I am afraid no more will be coming from Richard.

As a long term project i had planned to try to port DOS/65 to ca65 and make it (mostly) hardware independent. mainly because ca65 is powerful, open source, and runs natively on both Windows and Linux (modern ones!).
and i'd rather have old (and new) Projects use it instead of some random ancient (sometimes proprietary) assembler that was last updated in 200x and you can barely find any documentation about, or even a download for it.

so having flooby already port it to WDC's tools is a pretty big step, as WDC's syntax is much easier to convert to ca65 than whatever assembler the original used.
but there are still some hardwired hardware depended pieces in there that i need to manually remove, so it'll still take some work. (but if you read this flooby, it would be nice knowing specifically which parts/routines are hardware dependent )


anyways, back to the topic!
I'm very interested in how you would want to achieve Position Independent Code on the 6502/C02. it doesn't have the PER instruction of the 65816 so i'd imaging implementing relative versions of JMP and JSR are going to be the main problem (data access can be done exclusively through indirect addressing, using the X Register as an index into the ZP so the program doesn't overwrite any of the system's variables)

Re the license: the issue is that 'non-commercial use' is very fuzzily defined and as a result is the kiss of death for getting images distributed with emulators, shipped with hardware, packaged up for distribution in Debian, etc. Bear in mind that distributing such a thing from a website for which you get advertising revenue is technically commercial use! As a result aggregators tend to avoid such software like it'll give them plague.

Re Acorn's MOS: ooh, that's really cool. I love MOS, mostly, and think it's a very elegant system which should be better known, but it's also rather big and requires hardware support (e.g. paging for context switching between ROMs). CP/M's much smaller and should therefore be more portable. But running it as a language on MOS would be quite possible and would be a quick and easy way of getting the system up and running.

Re position independent code: I wouldn't. Instead I would fix up the code after loading to run at the desired address based on tables in the binary --- similar to traditional CP/M .PRL files, but different.

(Incidentally, some context: I've got this compiler, Cowgol, which at one point I wanted to run on the Commodore 64. As scripting together multiple machine code programs from Basic is difficult I ended up writing a tiny DOS shell, called cshell: https://github.com/davidgiven/cshell Unfortunately, while the compiler binaries ran on this fine, the C64 DOS is, um, a bit special in places and without the ability to seek inside files I couldn't actually make it do useful work. I found myself wishing I could just use CP/M on it, which led to the above post. But I'll admit I'm more interested in the intellectual exercise of doing the work than actually using the result.)

I had contacted Rich Leary via LinkedIn a couple years back I guess... we swapped some email and he sent me his V3 ROM code as well as his most recent 2.x and 3.x versions. As Rich worked to get the ROM code running on Daryl's SBC 2.5 and WDC's 65C02SXB (both using a SDcard interface) he did the initial code changes to get it over to WDC Tools.

There are basically 4 components of code for DOS/65:
- CCM (Concurrent Command Module) which is your basic command processor, i.e., the module the user interacts with to use the system. It has a total of 8 commands.
- PEM (Primitive Execution Module) which is the core of DOS/65 that manages disk allocation and file management, other resources like the console, reader/punch, etc.
- SIM (System Interface Module) which interfaces to the specific hardware at an abstraction level for Disk I/O and other hardware resources.
- MONITOR - This is generally an interface layer between SIM and whatever BIOS type functions the specific hardware provides.

My initial port (not a really accurate description) was writing a Monitor module using one that Richard provided. I simply linked the BIOS on my C02 Pocket SBC (with the CF Card/RTC adapter) to the SIM module and managed to get it working.

My later approach eliminated the Monitor module and I rewrote parts of SIM and included the access code to directly access the BIOS on my system. I also increased the number of supported drives to the maximum of 8, each a maximum of 8MB size.

Once this was completed, I went through the CCM and PEM modules and re-wrote some sections and modified many others to reduce the overall code size and use CMOS instructions and addressing modes. Note however, that these are separate modules which do NOT need any changes to move to another system. I also did the same with SIM, which did have some CMOS code in there. I also streamlined the ROM usage and initialization code so it fits into 6.5KB of ROM. It does however, require about 4KB of RAM at the top of the address space for variables and disk allocation maps. Each drive letter requires 512 bytes of RAM space. While my SIM code allocates and supports up to 8 drives, I'm only configured for 7, as the CCM, PEM and SIM variables take another 512 bytes.

My most recent DOS/65 code, now at Version 3.04, has some additional code updates which reduced the size of the modules a bit more. I also separated the source modules out so there are separate files for CCM, PEM, SIM, which are called by the main source file. Version 3.04 is sitting out on my GitHub page and I'm quite happy with it. I've been running it for months on a 3.3V prototype system with a Hitachi Microdrive with 35-pin PATA interface (true IDE, not a Compact Flash format device).

I still need to look more closely at the core set of DOS/65 utilities and start moving them over to WDC Tools and get them working with my current 3.04 version. A few are moved over already... the Super Directory, Submit and Ucopy utilities. There is an Xmodem utility I did some initial changes to and had that working, but my terminal app (Serial on OSX) stopped supporting the non-CRC Xmodem protocol, so I'll likely just rewrite that at a later date. For now I just the Xmodem commands in m Monitor code, which has the limitation of only transferring between RAM and the main system... which has a limit of 24KB when DOS/65 is loaded.

Hope this long post helps answer any questions about DOS/65 and perhaps some might find it useful. I've not had any recent communication with Richard lately, as he does have some health concerns and seems to have scaled back some of his projects. Still, I think he did a great job on porting CP/M over... and the disk format used is the same.

You don't necessarily need the sideways ROM support - however that would mean squeezing the CLI + basic commands, OS Calls (RDCH, WRCH, OSBYTE, OSWORD) and ... Filing system into about 16KB of space minus what you use for IO. Mine is currently about 10KB and has stuff like command line history, and nice line editing, however the filing system is handled in the board "host" MCU - I sort of think of my system as the Tube-side of a BC Micro with the host side being the MCU (ATmega) I think I could squeeze it down and include a simple filing system in that space if I tried hard though.

I did play with cc65 at one point with it too - so I could write and cross compile C code on my desktop and download it into the system and run the C applications like sideways Language ROMs before I moved onto the '816 system and BCPL.

-Gordon

DOS-65 license was probably restrictive because the murky status of CP/M, which has recently been open sourced.

https://blog.adafruit.com/2022/07/13/cp ... etronic80/

BTW there still is the o65 relocatable file format that I use in my GeckOS multitasking operating system for 6502 computers