FLEX was no more exciting than CP/M in the OS space -- i.e. it was a shell that could load programs and offered a BIOS/BDOS. SpartaDOS was no slouch on the Atari 8-Bit.

OS/9 was a multi-tasking OS for the '09, and, early on, all of its processes were written using position independent code, no launch time loader was necessary.

Early MacOS did this also, relying on PIC routines. This was fully exploited by the MultiFinder. There was system support (notably for calling different segments of code within the application), but no real loader per se. Of course, UCSD P-Machine did this also, at the p-code level. All of their code was PIC with the segments tied dynamically loaded at runtime. Both the Mac and UCSD required compiler support for multi-segment calls.

You could do the same thing on the '816 (IIGS did this a little bit, with desk accessories), with the caveat that your individual processes could only have < 64K of code, but they could access more than that for data. The OS would need to have a way to portion out Bank 0 as a shared stack space among the processes, but (almost) 64K of Bank 0 should handle hundreds of processes. Each processes meta data can specify a stack size.

None of this requires a loader, but it does need a decent memory manager. And, yes, there's no protection among the processes -- that's a different issue.

So, which 6809 and 6309 datasheets are you using, BDD? My 1981 Motorola manual says the 6809 Fast Interrupt Request (FIRQ) takes just 9 cycles after completion of the currently-executing instruction. IIRC this is just one cycle slower than an '816 in Native Mode. IOW, 9~ vs 8~. These are both favorable figures. (As for 6309, I suspect its FIRQ response may take as little as 7~ due to freedom from dead cycles when not in Emulation Mode but I haven't checked this.)

Re power: the 6309 is, like the 65816, a CMOS design. Have you actually compared their respective consumptions?

Edit: "after completion of the currently-executing instruction" is somewhat of a wild card. Multiply, for example, is a comparatively slow instruction, and its use will impact interrupt latency. But it would be misguided to praise 65xx for its lack of a multiply instruction! And of course if its avoidance really is desirable then the 68/6309 coder can simply not use it.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Some ARMs have a selectable mode, as to whether an interrupted instruction should be completed, or abandoned (and rerun when the ISR returns.)

FWIW there's a book all about the 6309, legitimately available as a free PDF:
http://cyberabi.ipower.com/Downloads/The_6309_Book.pdf
(It suggests a FIRQ takes 10 cycles, and weakly implies it's the same in both native and emulation mode.)
(And there's a 6809/6309 ref card here.)

Not always, but a division is much more common than a log. And when I do need a log, it's another big assumption that 16 bits will be sufficient.


What ? We were talking about cycles, not microseconds. And even if you're going to introduce clock rate, it would be honest to pick off-the-shelf parts for both contenders, and not pull out hypothetical ASICs that none of us have access to.

The 6309 has two interrupt levels, which can help to make it faster than a 6502. If you have multiple interrupt sources, but only one that's time critical, you can attach that to the FIRQ, and save time because you don't have to look up the interrupt source.

Of course the 6809 has the same FIRQ/IRQ (and NMI) setup.

What attracted me to the 6809 for my projects is the programming model. I'm still waiting to see a dynamic memory allocator written for the 6502, just to see how it "reads".

That said it's good to see some numbers on the whole "6502 interrupt performance" thing.

_________________
8 bit fun and games: https://www.aslak.net/

I have part of it done, but it's painful Compared to 6502, the ARM version was a breeze. I'm also hoping someone will make a 65816 version.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

(I'd feel more comfortable if we could get back to "this thing is a good thing" and away from "this thing is better than that thing")

But CP/M is very exciting in OS space. It has dozens thousand useful software items. It can run with almost any 8080/8085/z80/v20 hardware. CP/M was useful to the late 90s. There is good software for 6502 too, but it is strictly isolated in Apple ][ zone, or Atari 800, or Commodore 64, .... The absence of common OS always made 6502 position very feeble. I'm still curious why there were no attempts to port cp/m for 6502 in 70s. IMHO it was easy just to change start of TPA from $100 to $200. It is also easy to convert 8080/z80 codes to 6502.
BTW CP/M-programs and even COM-programs for much more advanced MS-DOS do not require a loader but it is a sign only of a simplicity of these OS. Even PDP-11 OS, which use hardware with a very good support for the code relocation and are relatively simple, use loaders.
EDIT. IMHO Independent MOS Technology would provide the environment where common 6502+ OS soon would become a necessity and would be eventually made.

_________________
my blog about processors

I feel we almost need a separate thread for questions of OS advantages and history. I suppose we've got into an enthusiastic debate about the 70s/80s/90s generally, and the winners and losers as things happened. Of course, things could have happened differently. Success in the embedded world - both 68xx and 65xx having had success there - is less visible than success in the world of computers.

I've just finished reading an oral history of some of the engineers and managers behind National Semiconductor's 32000 CPU series. It's interesting to read about the challenges and the mistakes. One takeaway from them is that it was all about the software, and about the commitment of a company to a product line and its future support. If NatSemi were not as credibly committed as Motorola who were not as credibly committed as Intel, then Intel wins the corporate buyin from huge important customers. If Dell picks the '386 because of the available software for the end-user, it's not a statement about how excellent the alternative choices were.

On the topic of "What if independent MOS Technology had survived?" I'm sure that the availability of software and the commitment to support, manufacture and development would have been crucial. Visicalc changed Apple's fortunes, and that helped the 6502 and WDC to keep going. But WDC never had the size to change the world. If MOS had survived independent of Commodore, they would have needed to grow like Intel and fight like Intel in order to change the world. They would have needed to embrace something like Unix, I think, and that would mean adding layers to the architecture the way Intel did. Intel themselves had several tries at a fresh start, away from x86, and got nowhere.

I think Intel was in a very starting good position because of their early design choices, allowing for a long and smooth upgrade path with regular performance increases, while keeping support for the existing software base. Try that with the 6502, like we've talked about in this thread, and you get stuck dealing with the bad baggage from the beginning.

AIUI, one disadvantage Intel had, internally, was the huge success of their RAM business. It took a determined effort, first, to sponsor a CPU project, and second (much later) to drop the RAM and become a CPU company.

I'm not sure that the 6502 couldn't have pulled similar tricks to the x86, but I think it would have needed prefix bytes, or postfix bytes, or both. Once you have some on-chip instruction buffer or cache, and a wider path to memory, that starts to look less problematic. But eventually, as we saw with x86, you end up with very complex and power-hungry implementations to raise the performance.

I think the 6502 even with prefix/postfix bytes would still suffer from a barely useful zeropage and the sizeable chunk of opcodes involved with it. Reusing that opcode space would break compatibility. Later generations of '02 have also quickly claimed large parts of opcode space for dubious extensions, such as the bit test/set/clear instructions. It would have been better to go for multi-byte opcodes from the beginning.

Sure, but I don't think that's a specific x86 issue. Try getting the same performance out of an out ISA, and you'd also end up with the same complexity.