Building a hybrid Z80-6502 with ChatGPT

I wonder if this is the somewhat genius (in retrospect) move of getting CP/M going on the RC2014 - and it also seems a bit of a “right of passage” for a lot of the Z80 systems I see being able to boot CP/M.

There simply isn’t anything equivalent for the 6502. It’s as fragmented as there were systems makers - both back then and today. There are CP/M like systems for the 6502 but adoption is very low and that’s only really come to light in the past few (single digit) years.

Personally I think that sort of diversity is good, but it does seem to have been a bit limiting.

-Gordon
(With a few 6502 and 65816 boards!)

2 Likes

Interesting point about CP/M - it does give a common substrate to z80 systems, old and new. (And it has more than a few applications, including interpreters and compilers, even word processors and spreadsheets.) But also, it comes from a tradition of text interfaces, which on the one hand makes it very portable, and on the other hand removes the tight connection to games, consoles, and cycle-counting. Whereas the 6502 community is, I think, dominated by gaming and demo interests, often with particular loyalty to one platform. There’s a sizeable minority, of course, with wider interests. Overall, not sure if CP/M or 6502 would have the bigger pool of “serious” users - by which I mean anything other than the enjoyment of graphical games or demos. Interactive fiction is of course “serious”, as is the writing of games and demos!

2 Likes

CP/M is the “killer application” that serious Z80/z180/Z280/eZ80 designers strive to. It has a unifying effect on hardware to page out ROM, enable memory banking, and console serial port. The Zx80 operating system continue to evolve and consolidate; In the past 5-6 years RomWBW has emerged as the superset OS incorporating both version of CPM and various CPM clones for Z80, Z180, and Z280 (I just read about eZ80 joining the lineup of processors). It also provide unified interface to sound, text/graphic video, network, RTC, serial, SD card, and CF disk. I have jokingly said “Resistance is futile; RomWBW is inevitable”. I’m not sure it is in jest anymore. I myself have designed about a dozen RomWBW capable Z80/Z180/Z280 boards.
Bill

4 Likes

I guess the closest thing is Commodore-like BASIC and KERNAL I/O … see stuff like Commander X16 and maybe C64DTV (which added new modes).

But this stuff is only minimally supported by generic software. Nothing at all like CP/M.

What about the unix clones for the Z80, and Fuzix?

Well… Microsoft Basic is a common theme used on many platforms, (Commodore, Apple, OSI/UK101, etc.) but the underlying “OS” (Monitor, Kernal, etc.) is the platform specific things. MS Basic just specified some basic IO routines and the rest was up to the system integrator… So I guess Commodore wanted to capitalise on their investment in writing “Kernal” and so they used it on everything from the PET through the C64.

The X-16 people found it wasn’t that easy to use in a commercial setting though, so not as free and easy as (say) Wozmon or the Acorn MOS so most home-brew 6502 systems are probably running something like a wozmon look-a-like or in exceptionally few cases (ie. mine) an Acorn MOS look-a-like.

And before MS published the sources to their 8-bit 6502 Basic, there was EhBasic which was a slightly enhanced reverse engineered MS Basic - that’s found an outlet on many 6502 systems since then.

But that’s just Basic - nothing to do with file, terminal, etc. … which is where CP/M has the edge…

Indeed.

I have written my own Acorn MOS look-a-like - it’s good enough to make BBC Basic and a few other Acornsoft Language ROMs “just work” but porting it to other hardware would not be a trivial task… especially if you want to make all the file IO work as intended…

-Gordon

Regarding CP/M, the Z80 is profiting here really from 8080 compatibility. It’s part of a greater ecosystem. An equivalent for the 6502 would have been, if it had been 680x compatible and could run OS9, I guess.

One interesting thing about this discussion (and also ChatGPT’s suggestions) is that the question of stack sizes doesn’t arise. Looking at Chuck Peddle’s oral history, it seems that the stack size is about the only comprise, he seemed to have been somewhat worried about. Compare the following sentences (the first one explicitly on the subject of the merits of 6502 and not regretting anything):

So what would we have done? you don’t put a 256 stack into a computer, and we’re going to talk about that, right?

Gates took a look at the 6502 and says it’s a piece of junk, because it’s got a 256 byte stack.

(…) we felt we had to make a major step up, not just an extension of the 6502, but a major step up to a product like the 8080 or the 68000. That was the next generation because of the memory addressing capabilities. The structure that was in those machines were quite better than 6502, which only had a 256-byte stack.

In other words, compared to the virtually unlimited stack size of the 8080 (and Z80) inside the bounds of the total 64K address space, the single-page stack appears as kind of a major structural compromise of the entire architecture. In practice, this wasn’t really much of a hindrance, especially thanks to BASIC. – As attributed by Chuck Peddle:

let me make a point-- that Bill Gates had the solution for the stack problem.
He wasn’t paying attention to what he was selling. BASIC is an interpreter. It does one instruction at time.
You don’t need a stack heavy to do one instruction at a time. It doesn’t generate stack commands. So he was offering me the solution to this 256 byte stack, without realizing it. He didn’t-- it didn’t come together with him, that was enough. And that’s why the 6502 worked as the computer for the PET, is because the BASIC didn’t need a bigger stack.

Still, the stack size of the 6502 is a reoccurring theme, and Chuck Peddle is peculiarly defensive about it. But – as far as I would know – it never was a real-world problem. Or, is it just that BASIC shaped 8-bit microcomputing as much that this didn’t arise? Chuck Peddle seems to have been suggesting so.

(Quite to the contrary, to a normal programmer, like me, the limited size and fixed location of the stack ($0100–$01FF) appears more as a virtue of the architecture, as this makes the memory layout and use deterministic. E.g., it’s what enables the Atari VCS/2600 to work with just 128 bytes of memory, without running into major software hazards.)

Speaking as someone who was only a lone novice programmer back then, with no insight into what anyone else was thinking, I DID see the 256 byte stack as an embarrassment.

I found recursive algorithms really cool, and I thought the 256 byte stack was an annoying hindrance to massively recursive code.

However, I didn’t realize that massively recursive code was also massively inefficient code, and it just wasn’t a hindrance in actual sensible use.

Well, personally (maybe even a bit ironically in the face of Chuck Peddle’s praises of BASIC in this context), I did see and encountered problems with the limited stack size in BASIC (I think, 16 nesting levels). But less so with machine language.

Edit: If I do see compromises in the 6502 architecture, it’s less so on a technical level, but more on an intellectual level. Ideally, an instruction should match an “atomic thought”. While the 6502 instruction set generally does a good job, it’s also lacking in certain instances, where a certain amount of microcode ability would help. E.g., it’s embarrassing to have to branch on the carry flag and on the zero flag in separate instructions to evaluate certain conditions. (Combining flag conditions in a bit vector would be ideal, or having negatable/inverse conditions.) Or to have multiple consecutive shifts for what is essentially a single operation, like isolating the high nibble or a certain bit. (Here, any kind of sequential or barrel shifter would be desirable.) But, I guess, for a microcontroller, it’s ok.

1 Like

The 8 and 12 bitters are designed as a micro-controlers. That is why BASIC
in rom lasted so long. The only 16 bit CPU that had the power, was the PDP 11 because you could get it with a good MMU. Every thing else gave you segment
registers, or 64K banks. A 256 byte stack is just a minor point in the big picture
of 16 bit addressing.

Having done code generation for all of them the 6809 is I think roughly where you inevitably end up. That’s probably not surprising. The 8080 was fixing up the 8008, the Z80 was constrained by the 8080 errors and added an enormous instruction set for little gain. The 6800 was a first attempt and limit hard by gate count, the 6502 was designed to be cheap not pretty.

So the 6809 was the point at which someone actual got down to work partly from scratch with the goal of doing it right in the first place.

Some bits of Z80 accidentally ended up being good for the future. The register oriented architecture is totally inappropriate for a system with memory running at CPU speed, but becomes a rather nice fit for modern fast equivalents like ez80 where it’s hard to run zero wait state memory.

Rabbit was IMHO the best z80 influenced device though. It’s not quite Z80 compatible but they used that to fix the really dumb bits and also to add a some actually useful ops.

In comparison to 8060, 8070, 1802 and some of the other period devices though none of them were bad at all 8)

4 Likes

I have Fuzix running on a load of 8 bit : 8080, 8085, Z80, 6303, 6502, 6803, 6809, 68HC11 and the kernel also running on 6800 (although it’s taking a break whilst I rewrite the 680x C compiler)

6809 is the tightest and cleanest. 68HC11 isn’t far behind, 6303, 6803 and 8085 a bit further. 6800, 8080 and Z80 are just painful in comparison. Z80 has better code density than 6800/8080 but it’s not that great for performance.

3 Likes

ARM has very little in common with 6502. The designers cite powerpc as one key influence but in so many ways the original ARM was a stretch DG Nova.

The combination of maths operations with shifts and byte swaps. The use of conditions nailed to operations (although the Nova nails them as skips to register/register ops rather than prefixes to all), and the like make it far more Nova like than 6502 like, although they did at least make it byte addressed.

@Plasmo
8080/Z80 had CP/M and a bunch of related operating systems. 6809 had OS/9 (and now NitrOS/9) and Flex, 6800 had Flex. (there are a bunch of other more weird things too). 6502 was unlucky in that the only “real” OS (as opposed to stuff nailed onto BASIC) was on the Apple machines, and whilst it had a huge volume it was and still is tied to Apple architecture in a way that CP/M , Flex and OS/9 were not.

OS/9 is way superior to CP/M and has a very rich software pool to the point NitroOS/9 is self hosting on a Tandy COCO3. Flex had a rich pool of software too and functionality roughly equivalent to CP/M but with some addons CP/M lacks (like heirarchical file systems on Flex/9)

1 Like

triva : If you have OS/9 level II, you can run FLEX on it.
Is any one here running Uniflex from the missing 6809 uniflex
archive? The Missing 6809 UniFLEX Archive
You can’t blame CP/M having no sub directores, you had the
Single Sided, single density 8" floppy for media.

Hang on! Acorn might not have taken over the world, but certainly the Beeb MOS is much more than that.

1 Like

This seems anachronistic to me; didn’t ARM predate POWER1 by several years, and PowerPC by a few more yet?

2 Likes

Furber is quoted mentioning the Berkeley and Stanford papers in here:

Steve Furber of Acorn computers, who would go on to develop the ARM architecture, would later say:

… the other feature of the Berkeley and Stanford stories was that they had managed to produce reasonably competitive microprocessors just using a class of graduate students for a year. So they had a lot less experience and a lot less resource than the big companies had used, and therefore we thought maybe, just maybe, with these ideas if we set off we’ll come up with something interesting possibly.

1 Like

6 posts were merged into an existing topic: Isetta TTL computer, runs 6502 and Z80 code