CP/M for the 6502!

[hjalfi]

Excellent, thank you! I'll try porting his edit. Do you have a online source of that document that I can use as a reference?

I also see that he has a port of the BASIC-E compiler, that'd be really nice to have. It says it's a translation of Gordon Eubanks' original, which was written in PL/M, so that's a nice piece of work. The original's in the public domain so provided I can plausibly argue that it's covered by the new GPL-3 license then there are no derived work issues to deal with.

[BillG]

hjalfi wrote:

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?

Bravo! What took you so long? The videos are quite watchable at 2x speed.

For a size reference, I have transcribed the 6800 FLEX native assembler to the 6502. It is a full featured assembler for its time though lacking advanced things like conditional assembly and macros. It weighs in at 7.7K.

hjalfi wrote:

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?

I have also transcribed the FLEX text editor to the 6502. It still lacks several commands and has bugs. I do not know enough to say how difficult it would be to make it run under CP/M-65. It is somewhat better than CP/M's ED, more like EDLIN.

This is the manual for the 6809 version; the 6800 version I started with is missing a few of the commands.

http://www.flexusergroup.com/flexusergr ... /tedit.pdf

How does a program determine the end of the usable TPA? With CP/M-80, the jump to BDOS indicates where the operating system code begins.

In the past, I have threatened to write a compiler for PL/M.

https://talk.dallasmakerspace.org/t/pro ... /18852/216

It is not very far along. <mumble>too many projects...</mumble>

hjalfi wrote:

At one point someone told me about a third CP/M for the 6502 project, but I can't find their message now...

That would be viewtopic.php?f=2&t=7394

It uses 256 byte record sizes, so may be difficult to port code to.

[floobydust]

hjalfi wrote:

Excellent, thank you! I'll try porting his edit. Do you have a online source of that document that I can use as a reference?

I also see that he has a port of the BASIC-E compiler, that'd be really nice to have. It says it's a translation of Gordon Eubanks' original, which was written in PL/M, so that's a nice piece of work. The original's in the public domain so provided I can plausibly argue that it's covered by the new GPL-3 license then there are no derived work issues to deal with.

Hans Otten had some correspondence with Richard a while back. That led to Hans putting some details on his website and some links for sources and documentation:

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

http://retro.hansotten.nl/uploads/dos65 ... 20docs.zip

The zip file linked above has the same PDF with the GPL 3 license that attached above. There's also numerous attachments directly from Richard on the V2 code from several years ago on the OSI web forum.

https://osiweb.org/osiforum/viewtopic.php?f=4&t=235

[Dietrich]

BillG wrote:

It is not very far along. <mumble>too many projects...</mumble>

hjalfi wrote:

At one point someone told me about a third CP/M for the 6502 project, but I can't find their message now...

That would be viewtopic.php?f=2&t=7394

It uses 256 byte record sizes, so may be difficult to port code to.

Well that would be my approach. Actually the Assembler should be easy to port. It just reads the *.ASM-file sequentially twice and at the end writes the source file and the label file to the disc. To adapt it to 128 byte blocks, just read 2 of them.

The whole CPM-65 package is another story though

Dietrich

[okwatts]

It's been awhile since there was an update on this project. It has been moving along and there are now ports to a few new systems including the Nano20K. Since I had just purchased a Sipeed Nano9K FPGA for trying out AtomFPGA and BeebFPGA, I ordered a Tang Nano20K and used nano6502 ( https://github.com/venomix666/nano6502) which has a version of CP/M65 already for it. This is a painless (although not totally inexpensive) way to see what has been going on. This seems to be progressing nicely with a version of Basic and Pascal as well as the Assembler and a couple of editors. The idea of the relocatable code will take a little getting used to for coding but I will explore further. Since I already have DOS65 for plasmo's CRC65 I should be able to find my way. If I had a ready way to compare to Dietrich's CPM-65 without having to do all the conversion (as plasmo started ) then I might be able to give a more complete review. As I do more comparisons I hope to be able to shed more details in future.

[hjalfi]

Looks like I missed several notifications for this thread...

Yeah, there's a bunch of new stuff and ports, including an extremely interesting 8080 emulator which is still a PR but will allow booting DR CP/M-80 on an applicable 6502-based system (currently Atari 8-bit and BBC Master). It's too slow to really be usable but it's miraculous that it actually works.

The Pascal system is a port of the Pascal-M subset compiler from 197x, and is capable of very nearly full self-hosting; the only missing bit is the loader, which converts the OBB intermediate files into loadable byte-code. That's currently written in C++ because life was too short and because Pascal-M has very little ability to handle dynamic memory. Compiling is slow but it's CP/M; it's not _meant_ to be fast.

Another cool new feature is the neo6502 port. This has a BDOS emulator which delegates filesystem calls to the native system, which has its own FAT filesystem (and whose workspace doesn't occupy the 6502's memory). For applicable platforms this would allow CP/M to operate using the native filesystem, which is frequently much more convenient. A second candidate platform for this is the BBC Master or Tube. Acorn's ADFS only supports ten-character filenames so some gymnastics would be needed to get around that but it should be perfectly reasonable. If anyone knows any other platforms that might benefit from this let me know.

[orac81]

Rather than running real DR CP/M, wouldn't it be better to run a CP/M80 emulator as a program on cpm-6502, then translate bdos calls?
While thinking of an 8080 emulator for the the 6502, i found this, one that runs on a 1k kim!

https://www.pagetable.com/?p=824

I guess it could emulate an 8080 running at about 10khz?
Cross compiling 8080 code to 6502 (revasm etc) would be more work but yeild faster results..

I was thinking of porting my asm502 to a 6502 cpm target, its small enough, and runs a ca65 subset. But it is missing some key features like obj files, so its a fair bit of work..

[hjalfi]

Yes, but it's someone else's PR so I'm not going to complain! A BDOS emulation would be fairly straightforward to add after the fact, within limits (there are some differences between the CP/M-80 and CP/M-65 APIs). It'd make anything with disk access a lot faster but probably still wouldn't be good enough to run WordStar.

The biggest issue with putting an assembler is getting relocatable files. It complicates the native assembler a lot. There is a host tool for comparing three binaries assembled at slightly different addresses, but that's ugly.

[orac81]

The other advantage of an 8080 emulator running inside a 6502 cpm is that would be portable across platforms. I wonder what 8080 speed a 2mhz 6502 machine like the bbc or commodore +4 could reach? There are some modern 16mhz 6502 machines.

Does cpm65 tell the user program how wide/high the vdu is? Most classic cpm80 stuff needs 80 columns. You can have an 80 col soft screen (4 pixel wide char) on a c64/+4, but its slow and you loose 10k+ to hires etc. A better idea might be keeping fast text mode 40x25, showing different parts (left, right, alternate lines) on hitting a hot key, and a mode80 command within cpm if that is not sufficient..
Thinking about running Wordstar ( or Dbase II) even an 8080 JIT Compiler would choke at the job!

At some stage i will setup a compile chain and cross compile some stuff..

[barnacle]

I've considered the problem, but not to the extent of actually trying it, and concluded that there's likely to be big hit with any of the 16-bit instructions. The ability to put the 8080 stack anywhere in 64k doesn't speed up access for call and return, let alone local storage.

I think you'd need to consider the interrupts quite carefully too - don't forget the 8080 family stuff an instruction on the address during the interrupt acknowledge phase, rather than just 'calling' a vector. Depending where your hardware interfaces, that might be tricky to implement. (And in reverse, the 6502 vectors aren't reserved for anything in 8080 land).

Neil

[hjalfi]

Currently the 8080 interpreter is too slow for real use. The target is to be able to run WordStar, but it's not capable of keeping up with typing. There's a video of the interpreter in action here: https://www.youtube.com/watch?v=5uONG8YH2L0 Currently it only works on the Atari XE and BBC Master computers, as only they have enough banked RAM.

Re screen sizes: one of the CP/M-65 features which CP/M-80 doesn't is a real driver model. Screen access goes through the SCREEN driver; if you want VT52 or ADM3A TTY support, you can load an escape sequence interpreter which works on top of SCREEN. One of the entrypoints gives you the screen size.

Re interrupts: neither CP/M use interrupts at all. They usually run with interrupts disabled! One thing I want to add is a TIMER driver which provides a system tick and delay function, which will most likely require adding interrupt support, but it's not done yet. That won't affect the 8080 emulator, of course.

[barnacle]

Ah, so all the disc and comms stuff in the BIOS and BDOS are polled? I'd forgotten that, if I ever knew it...

Off to watch the video.

Neil