
OUP/M: CP/M-like operating system for 6502 - ingve
https://github.com/option8/OUP-M
======
hermanhermitage
For another CP/M take on 6502 see DOS/65 at
[http://www.z80.eu/dos65.html](http://www.z80.eu/dos65.html)

------
sedatk
6502 is a harsher environment than Z80 which CP/M was originally designed for.
It's a good candidate for a C64 port too.

~~~
ido
what makes it harsher? Also I believe CP/M was originally designed for the
i8080.

~~~
flohofwoe
I guess it's about the 6502's more RISC-like philosophy, which made it a bit
more cumbersome to program in assembly code (even though the resulting
performance was mostly similar to the Z80 because the 6502 could do more
things in fewer cycles).

Even with the whole 'extended register set in the zero page', the 6502 didn't
have convenient features like 16-bit math, memory block instructions, and even
8-bit math was less convenient (e.g. no separate add/adc, sub/sbc
instructions, so you always had to clear the carry flag before a math
operation etc...)

But I think this didn't matter for porting the operating system CP/M itself to
6502, the actual problem was binary compatibility with applications, and the
Z80 was backward compatible with the i8080 (as long as only documented
instructions were used).

I guess being compatible with the i8080 (and CP/M 'office software') was the
whole point why the Z80 was even created (as an i8080 killer), and that it was
as successful as it was.

------
dbrower
Is there a C compiler for it?

~~~
dmitrygr
Probably not a very good one. 6502 architecture is quite hostile to c
compilers

~~~
i_am_nomad
Interesting - I grew up with a 6502-based computer (Atari 800), and never got
around to using C. Any sources for this?

Edit: here’s one. [https://dwheeler.com/6502/](https://dwheeler.com/6502/)

~~~
duskwuff
A couple of major reasons:

1\. The 6502 is heavily register-starved. Three limited-purpose registers is
pretty rough.

2\. There are no 16-bit registers, so you can't put a pointer in a register.
You can put one on the zero page, but that's much more limited. Indexing into
arrays larger than 256 bytes gets complicated, too.

3\. The 6502's stack isn't well suited for storing data. There's no SP-
relative addressing, for instance. It's possible to get the value of SP with
PHP/PLA, but this is pretty awkward to work with.

~~~
david-given
I wrote a self-hosting (if you're very patient) compiler for the 6502 and Z80
a while back. Both are a bit of a shock if you're used to true 16 bit arch
architectures. I did a couple of writeups on the problems of doing basic
arithmetic in them:

[http://cowlark.com/2018-02-27-6502-arithmetic/index.html](http://cowlark.com/2018-02-27-6502-arithmetic/index.html)

[http://cowlark.com/2018-03-18-z80-arithmetic/index.html](http://cowlark.com/2018-03-18-z80-arithmetic/index.html)

The 6502 is more orthogonal, and while each instruction does less they're very
fast; the Z80 is fundamentally more powerful but weirdly inconsistent,
terrifyingly slow, and the unorthogonal register system means that you spend
half your time shuffling registers.

