Why no discless cpm machines with cpm loaded from a rom abstracted as a rom disk?

[B3_B3_B3]

I wondered why no discless (ie tape based) cpm machines with cpm loaded from a rom abstracted as a rom disk seem to have existed. You would get a standard OS, large software availablilty (I am presuming it could be upgraded do discs easily).

I found some mention of DR working on tape based cpm and mention of sharps tapebased cpm machines but no actual models.
.

[DutchAcorn]

Epson PX8 / PX4?

[BigEd]

Epson PX8 / PX4?

Wow - wouldn't have guessed such a thing existed! It makes some sense, if a CP/M system is to be used as an appliance, that software in a ROM cartridge would be fine, and even have some advantages.

[paulb]

I wondered why no discless (ie tape based) cpm machines with cpm loaded from a rom abstracted as a rom disk seem to have existed. You would get a standard OS, large software availablilty (I am presuming it could be upgraded do discs easily).

I found some mention of DR working on tape based cpm and mention of sharps tapebased cpm machines but no actual models.

From what I was able to discover, Torch's CPN ran from ROM, at least in their Z80 second processor expansions:

"Launch your micro with the Torch Z80 disc pack"

I don't know enough about CPN or CP/M systems to say whether they could have presented ROM content in the form of virtual disks, but such things were done with embedded DOS-based systems. It would be interesting to read those remarks about tape-based CP/M.

[B3_B3_B3]

...... It would be interesting to read those remarks about tape-based CP/M....

The following, which I think I had read before my OP, mentions the Epson, but the Sharps only as a possibility plus I think It was in wiki I found the Sharp reference:

https://retrocomputing.stackexchange.co ... y-drive

...and here is the wiki link mentioning 'Personal CP/M, a ROM-based version' https://en.m.wikipedia.org/wiki/CP/M

But bundlinging conventional cp/m into a rom/ram disc would seem available to any manufacturer and apparently cp/m would support tape drives: in which case if the bbc could have found a company to add a graphics api and matching circuit for cpm (acorns VDU system and coordinate partial abstraction would have done?) maybe BBC/Electron owners would all be in the z80 group.

[paulb]

...... It would be interesting to read those remarks about tape-based CP/M....

The following, which I think I had read before my OP, mentions the Epson, but the Sharps only as a possibility plus I think It was in wiki I found the Sharp reference:

https://retrocomputing.stackexchange.co ... y-drive

...and here is the wiki link mentioning 'Personal CP/M, a ROM-based version' https://en.m.wikipedia.org/wiki/CP/M

I remember that now, and I was the person who added the paragraph describing it to the page! I just couldn't remember the context.

But bundlinging conventional cp/m into a rom/ram disc would seem available to any manufacturer and apparently cp/m would support tape drives: in which case if the bbc could have found a company to add a graphics api and matching circuit for cpm (acorns VDU system and coordinate partial abstraction would have done?) maybe BBC/Electron owners would all be in the z80 group.

Didn't Research Machines pursue a diskless (but networked) CP/M solution with the LINK 480Z?

I imagine that a CP/M strategy involving ROM was just too costly. RM declined to bid for the BBC contract on cost grounds, and in various respects the BBC Micro is designed for reduced cost: not relying on disk storage, using the 6502 and other chips instead of the Zilog chipset, and so on. It is just that the possibility of engineering it further for lower per-unit costs remained, leading to the Electron, and that effort seems to obscure the motivation for, and method of, formulating the Beeb in the way that it ended up.

Naturally, going with the 6502 meant that Acorn, like Apple (noting your other recent posts), had to develop its own software stack. Apple dedicated itself fully to a 6502-based solution with the Apple III, bringing some of the technologies back to the Apple II series when the Apple III failed in the market, but one could have imagined Acorn doing just enough to support a range of software running on a 6502-based platform and relying on the Z80 second processor to be the platform for more advanced applications. Instead, the Beeb was popular enough as it was, and so the investment in the 6502-based operating system framework paid off.

[B3_B3_B3]

..
I imagine that a CP/M strategy involving ROM was just too costly. RM declined to bid for the BBC contract on cost grounds, and in various respects the BBC Micro is designed for reduced cost: not relying on disk storage, using the 6502 and other chips instead of the Zilog chipset, and so on. It is just that the possibility of engineering it further for lower per-unit costs remained, leading to the Electron, and that effort seems to obscure the motivation for, and method of, formulating the Beeb in the way that it ended up....

Is the extra cost in the amount of roms required to make a cpm rom disk or in the z80 support chips?

I had thought it was the Bbc mixed text and hires bitmapped graphics including teletext requirements that put RM off.

The actual Bbc B micro seemed a rather middle class priced computer, rather than a computer for all classes*, creating the model A/electron by removing stuff from the designed first bbc b seems the wrong way round to me, some of the B's extra hardware is too ingrained in the design to remove it from an A/Electron without losing software compatibilty eg the speech ic support wastes half the system via for something hardly anyone fitted: surely the user port and user via timer would have been better there, teletext is deeply ingrained when it could have been an addon: more linear ram memory future expansion (ie 48k like an apple ii.... ), would seem a good swap, if base unit designed first then bitbanging the cassette would save requiring an acia ic etc.

*the Bbc would have preferred a computer affordable by all classes l presumed.

[DutchAcorn]

The Epson PX8 & PX4 support CP/M on tape. It’s not very fast, new files need to be written to the tape as well as the directory file at the start of the tape. So CP/M needs to be in full control of the tape drive to rewind and fast forward based on the information in the directory file.

But it behaves like a disc under CP/M this way.

[paulb]

Is the extra cost in the amount of roms required to make a cpm rom disk or in the z80 support chips?

Acorn people seemed to complain about the cost of support chips, at least in the context of their processor design efforts, recalling remarks about DMA controllers. One might imagine having to use four 16K ROMs or even eight 8K ROMs might be prohibitive both in terms of component cost and board cost, but I couldn't really quantify that.

I had thought it was the Bbc mixed text and hires bitmapped graphics including teletext requirements that put RM off.

I can imagine them considering a 640 pixel horizontal resolution to be out of reach for a low-cost machine, at least with an off-the-shelf graphics chipset and dedicated display RAM. The luxurious BBC requirements probably put a lot of vendors off, especially with the hybrid Teletext plus bitmap display video system.

The actual Bbc B micro seemed a rather middle class priced computer, rather than a computer for all classes*,

*the Bbc would have preferred a computer affordable by all classes l presumed.

My impression of the BBC even now, as far as the decision makers are concerned, is of people who are rather privileged and do not really understand the experiences and perspectives of most inhabitants of the nation. So, the BBC Micro was rather gold-plated in terms of specification, as wish lists were pooled together and incorporated into what the end product was meant to deliver, this even after the CP/M compatibility requirement had been separated out into a second processor option. That specification did serve it well in some ways and made the Model B a usable computer for several years, but it was priced beyond a readily justifiable level for most people.

In certain respects, Sinclair might be recognised as understanding the cost accessibility issue, but one might also say that his primary obsession was cost reduction and that in pursuing it vigorously, he compromised the usability of his machines for the people to whom he was supposedly making them accessible. The Electron attempts to resolve the conflict between cost and performance but, as you noted, has a difficult specification to target, and it didn't help that Acorn seem to have taken one too many pages out of Sinclair's book with its design, also apparently seeking to position the Electron far enough away from the Beeb as to not endanger Beeb sales.

I actually don't think there is enough awareness or acknowledgement of the affordability issues of microcomputers during the era in question, nor of things like the regional inequalities within the nation (at the time and even in the present day) governing what kind of opportunities people had and what they could afford or justify spending their money on. Since historical narratives are often crafted by the more privileged, it means that some things are shown more respect than others and that some products are given less favourable treatment because they would have been used by those who are either less well-off or just less willing to lay out more money.

What I find refreshing about some of the activity on these forums is that computers like the Atom and Electron get the attention they deserve, rather than being categorised as machines that people would simply want to upgrade from and as mere footnotes in another story.

[Coeus]

I wondered why no discless (ie tape based) cpm machines with cpm loaded from a rom abstracted as a rom disk seem to have existed. You would get a standard OS, large software availablilty (I am presuming it could be upgraded do discs easily).

I would think it trivial to be able to load the core of the CP/M system from ROM rather than from the system tracks on floppy discs. A CP/M machine has to have a boot ROM. Normally, to keep the boot ROM simple, it loads the first few tracks from the floppy disc and then transfers control. Those tracks contain, in ascending memory address, the CCP (console command processor), BDOS (basic disk operating system) and BIOS (basic input output system). That could be copied from ROM to RAM very easily on boot.

When a transient program has finished running, if it has not trashed the CCP, it can return to it, or it can make a call to BDOS that will cause BDOS to re-load the CCP and transfer control to it, so the CCP has to loadable separately.

Having that much in ROM would enable a very fast boot time. CP/M, though, like most disc-based OSes doesn't have most of the operating system commands in this core part of the OS - CCP has a bare minimum of commands and loads the others from disc as transient programs (.COM files). It would be possible to make a ROM disc to contain these. BDOS calls the BIOS for all disc access so to get files loading from ROM it needs a BIOS that detects calls for disk A and returns the data from ROM instead.

The same would apply to the library of software you refer to, though. That has to be loaded from somewhere. For just the core of the CP/M system the amount of ROM is small and would probably cheaper than providing discs. As the amount of software goes up, so does the cost of ROM. At some point discs would have been cheaper, even if slower. The other alternative is either tape or network-based storage as used by CP/NOS (used in the Link 480Z). Because CP/M was specifically written to take advantage of floppy discs it assumes block-level random access. The BIOS could make a tape drive look like a disc but it would be seeking back and forth and quite slow.

Wow - wouldn't have guessed such a thing existed! It makes some sense, if a CP/M system is to be used as an appliance, that software in a ROM cartridge would be fine, and even have some advantages.

I wonder about the NCR ATMs. Some of the early ones of those ran CP/M, I think, based on coming across one sitting at the A> prompt on one occasion.

[B3_B3_B3]

.....library of software you refer to, though..... 

I was presuming most application software would be loaded from tape, like other lower cost home computers and beebs , but the rom cpm rom disk system could be perhaps expandable by rom cartridge and/or a 'sideways rom-box'---y approach (would look like files to cpm os) for programs that are used often/need loaded quickly. It might also make single diskdrive operation feasible when upgraded, so upgrading to disk could be cheaper.

[Coeus]

.....library of software you refer to, though..... 

I was presuming most application software would be loaded from tape, like other lower cost home computers and beebs...

It would be feasible, but as per earlier comments, this cannot easily be a standard audio cassette recorder where the tape is positioned manually according to a tape counter. CP/M will think this device is a disc because this is the only device type it knows, so it will want to go to some location close to the start to search through the directory then once it has found the program it will want to specify a particular block number to begin loading the file. This would work naturally with block-oriented tape like some of the QIC cartridges, but I would think the hardware for them would be at least as expensive as disc drives.

To use standard audio tape the tape would need to be laid out like a single track on a floppy disc. With floppy discs, once the head is on the right track the controller cannot go straight to the sector it has been instructed to transfer, it has to read the disc and wait for the sector concerned to arrive under the head. There also needs to be a system of gaps so each sector has an ID header, a gap for the drive to be switched to write mode if necessary, then the data, then another gap before the next sector to take account of slight differences in speed between different drives.

Where audio tape differs from a floppy track is that the floppy track automatically goes back to the start, i.e. the last sector is then followed, after a gap, by the first one again. Tape instead has to be rewound. In the CP/M case, the BIOS will need to be able to indicate to the user when the tape is to be rewound, maybe with an LED? This rewind prompt would need to happen any time the CP/M BDOS requests a block number that is smaller than the one under the tape head, i.e. <= the block last transferred. Then the BIOS would need to read through blocks on the tape until the one with the right block number is found.

For a further complication, CP/M allows files to be fragmented. Instead of the Acorn system of just storing the beginning sector number for a file and relying on the rest of the file being in subsequent sectors, CP/M stores an array of block numbers. That means one or more rewind operations may be needed in loading a single file.

Writing would need yet more interaction. After the BIOS has read the header of the block to be written, it would need to stop the tape, prompt the user to engage record, write the block data, stop the tape again, prompt the user to disengage record, then carry on with the next operation. As the BIOS is fed one block at a time it also doesn't know if this block being written is the last so this stop and operate the controls would be repeated on every block written. That could possibly be mitigated by working one block behind with a cache but that then means a timer to write the last block if no more are coming.

You can see why Sinclair went for the microdrive. This is a tape loop system, so more like the floppy track and maybe a floppy controller chip could be employed. There would be computer control over the motor and whether the head is reading/writing.

...but the rom cpm rom disk system could be perhaps expandable by rom cartridge and/or a 'sideways rom-box'---y approach (would look like files to cpm os) for programs that are used often/need loaded quickly. It might also make single diskdrive operation feasible when upgraded, so upgrading to disk could be cheaper.

It only occurred to me recently why ROM was expensive back in the day. If we assume a ROM needs at least one transistor for every bit stored then an 8K-byte ROM, 64K bits, needs 65,536 transistors plus any that are used in address decoding. Given that the 6502 had less than 4,000 that makes the ROM a considerably bigger chip and more expensive, both because fewer of them fit on a wafer and because each is more likely to be affected by a defect and be useless.

Interestingly, this may go some way to explaining how Intel came up with the 8271 disc controller with its two embedded microprocessors and a higher transistor count than the 6502. Intel's main business at the time was memory so presumably their expertise, and the their strategic direction, was packing more and more transistors onto a chip so weren't too worried about the transistor count. The expertise in MOS seemed instead to be around implementing useful functionality with as few transistors as possible.

[B3_B3_B3]

It would be feasible, but as per earlier comments, this cannot easily be a standard audio cassette recorder where the tape is positioned manually according to a tape counter. CP/M will think this device is a disc because this is the only device type it knows, so it will want to go to some location close to the start to search through the directory then once it has found the program it will want to specify a particular block number to begin loading the file. .....

Drat, so to use conventional cassette tape you would need to persuade dr to make a custom version..

...
You can see why Sinclair went for the microdrive. This is a tape loop system, so more like the floppy track and maybe a floppy controller chip could be employed. There would be computer control over the motor and whether the head is reading/writing......

No such looped tape system (phloopy etc) seems to have been succesful, and the microdrives' Sinclair-y tinyness probably didn't help them. The Japanese spiral tracked quick discs look like they would have been a better bet to me but they seemed even rarer back in the day.(in Uk).

In 1981 how would 16k rom compare to 16k ram at bulk factory prices to a manufacturer?

[B3_B3_B3]

......
In certain respects, Sinclair might be recognised as understanding the cost accessibility issue, but one might also say that his primary obsession was cost reduction and that in pursuing it vigorously, he compromised the usability of his machines for the people to whom he was supposedly making them accessible. ....

I always thought the Spectrums design was impressively electronically minimalist but the unit flawed by Sinclair foibles (eg spacebar in wrong place , obsesion with smallness for its own sake etc): it has one simple colour low memory footprint graphics mode, : everyone seemed to survive the attributes colour clash unscathed, though I'd prefer 40 column text to 32 and
which other computers manage on 256 horizontal pixels,
Etc....
A Spectrum differing only by 40 x24/5 text ability , a structured bbc style basic, acceptable build quality(if that is a difference), a normal keyboard layout (even if it keeps the one key keyword entry ) and at least the option of an affordable keyboard upgrade by replacing the case top half with an official upgrade looking like an oric atmos one; of electron-keyboard quality; would seem good enough for bbc-tv viewers to learn programming upon, whilst remaining in spectrum price range. Squeezing in an assembler would be nice but optional. But no Sir Sinclair plus/minus model of human was in the right place at right time...



I quite like the atom forum the yarrb2 is impressive.

[Coeus]

BTW, the Grundy Newbrain, the machine that would have been the BBC Micro had Newbury been able to produce them, is another example of a machine with CP/M in ROM.

[scruss]

Personal CP/M in ROM was a whole product that DR wanted to make much more successful, but I think it only made it into one machine. CP/M did have a standard graphics system, GSX, but it was more for business presentation work. There was even talk of a Z80 clone with a masked ROM on board containing CP/M, but I'm not sure if it ever made it past news release status.

I can't really see why you'd want CP/M in ROM, or go near tapes with it at all. It was easy to ship new versions on disk, and formatting a new system disk copied the OS with it. CP/M was about customization, ROMs are not.

[Coeus]

I can't really see why you'd want CP/M in ROM, or go near tapes with it at all. It was easy to ship new versions on disk, and formatting a new system disk copied the OS with it. CP/M was about customization, ROMs are not.

I can certainly seem why you would not want it on ROM in a system-on-a-chip together with the processor. But when you say customisation, CP/M was designed to be easy to port to new systems by splitting the OS into the BDOS and BIOS. People probably didn't upgrade the BDOS very often. For many people, the attraction of CP/M was the applications written for it. People are more interested in the applications, and upgrades to them, than in new features of the operating system.

The same applies today. There was a piece of malware a few years ago that found Windows/XP still in common use, especially within the NHS in the UK. It doesn't strike me as a coincidence at all. To me, Windows/XP was the first version of Windows that was fit for purpose and, with that, if Microsoft had then disappeared most PC users would not have cared.

Obviously, different systems make different compromises. One of the nice things about the BBC Micro and many of the 8-bit home computers was that they start up instantly, a property of having the operating system in ROM, as well as of relative simplicity. It is a bane or modern life that we spend so much time waiting for things to get started and many embedded systems now have software sufficiently complex that they take a while to boot. The typical set top box for a modern TV takes turning on a TV and waiting for it to be ready back to the days of the CRT and valves.

Then, back to CP/M, the talk of tape is about cost. For a computer targetted at the business market no-one would consider a system without discs but for a home computer they were relatively expensive. But, as I was pointing out, it is not that natural a fit. CP/M was written around discs and, while you can make it work with something else, you aren't changing the core design.

[DutchAcorn]

BTW, the Grundy Newbrain, the machine that would have been the BBC Micro had Newbury been able to produce them, is another example of a machine with CP/M in ROM.

Interesting. Do we have examples of machines that offered CP/M tape storage other than the Epson PX?

[1024MAK]

If a system did have CP/M on ROM, the ROM could have been drive A, and the mass storage device would then have been drive B.

It is perfectly possible that the ROM could have included a custom ’driver’ to use normal cassette tape. But obviously this would have substantial limitations compared to using a disk drive.

Some normal ROM chips (used for memory, not faster applications) I believe are normally based on a matrix. Think like a keyboard matrix, but instead of switch contacts, instead you have a permanent metal layer grid or mask. Hence it may not have had one transistor per memory cell.

It’s EPROM and DRAM that have at least one transistor per memory cell. SRAM has more.

The cost of a mask ROM is very difficult to answer, as manufacturers did not normally publish prices. The cost to a manufacturer like Acorn, Amstrad, Sinclair or indeed other computer manufacturers, depended on the quality in the order, and the required access time.

When the BBC Micro was designed, we definitely know that RAM was expensive compared to a mask ROM of equivalent capacity. But later on that flipped around. But I have no idea whatsoever when that flip around happened.

In terms of what would have maybe made a better, although higher priced home computer, would have been a mix of parts of a Sinclair ZX Spectrum and parts of an Acorn Electron. There is absolutely no doubt that Sinclair used an inexpensive keyboard design to keep costs low. But Acorn used a good keyboard and saved money on DRAM and maximising as much circuitry in a ULA (keeping in mind that ULA technology had moved on from when the original ZX Spectrum ULA was designed).

So if Sinclair had mated a keyboard similar to the Electron’s to a Spectrum 48K board, included a composite video output good enough for the BBC, and maybe tweaked the Spectrum BASIC slightly, I think that may have been enough to give the BBC a bit of a dilemma. Especially as it’s clear that the BBC Micro did not meet all the original requirements in the base model.

But we will never know.

Mark

[algenon_iii]

BTW, the Grundy Newbrain, the machine that would have been the BBC Micro had Newbury been able to produce them, is another example of a machine with CP/M in ROM.

Interesting. Do we have examples of machines that offered CP/M tape storage other than the Epson PX?

Amstrad CPC 464 (with disc drive) or 664/6128 running CPM2.2? CPM 2.2 offered basic tape access but you couldn't load binaries
https://www.cpcwiki.eu/forum/programmin ... he-cpc464/

[scruss]

As a former Amstrad CPC464 + CP/M user, CLOAD and CSAVE weren't very useful at all.

Some S100 CP/M machines had tape interfaces. Sam Singer's TAPELIB was a way to use tapes as backup media and even load executables under CP/M-80.

[arg]

I'm late to this thread, but would like to note the existance of ZNOS - CP/M compatible OS for the BBC Z80 2nd processor, using Econet fileserver as the filesystem. Filenames got translated so that the .xxx extension became directory xxx with the files inside it.

[B3_B3_B3]

Someone has made a version of cpm for the 6502 (supporting relocatable binaries):

https://github.com/davidgiven/cpm65

I wonder why, back in the day, Digital Research never did such(or were commissioned to), given the amount of 6502 systems?

Would suit sideways or/and Beepbob OS ram...?

[scruss]

Gary Kildall was very close to Intel, having worked as a consultant for them and written their standard small systems programming language, PL/M. He might have been busy enough with CP/M-80, and was making plenty money sticking with what he knew. By 1980, there was already the Microsoft Z-80 SoftCard to bring CP/M to the Apple II, and by 1981 Digital Reasearch were busy with 16-bit CP/M-86.

David Given's CP/M for 6502 is an interesting idea, but doesn't really help porting 8080 software. CP/M-80 supports relocation through the simple expedient of every program running at &h100 and a contiguous TPA going all the way up to the top of available memory. CP/M's BDOS/BIOS call convention uses very 8080 features and would have to be reimagined entirely for the 6502.

[B3_B3_B3]

Thanks, I thought it would have some use back in the day simply by having the same user interface as the defacto business standard OS, allow new 6502 manufacturers to avoid the noone knows my OS hurdle etc.

On porting, is changing the call method of the API that much trouble, when the z80/8080 code (preferably with accompanying documentation/pseudocode) will need translated, but the algorithms / high level code structure should remain the same?

[scruss]

It wouldn't be that hard to change the calling convention (I haven't looked at David Givens' code). Apart from the small matter of code conversion, 8080 code can be very stack-heavy. The stack typically lives at the highest safe point in memory, and is free to grow down as much as it wants. This is quite different from the 6502's model.

VisiCalc was the original 6502 "killer app". Lots of Apple IIs were sold just to run it. But its reign didn't last long. Competitors on CP/M like SuperCalc appeared within a year or so.

[Coeus]

I wonder why, back in the day, Digital Research never did such(or were commissioned to), given the amount of 6502 systems?

Bear in mind that the heyday of RISC came and went, and Microsoft even ported Windows to a couple of RISC processors, possibly determined to proves that the redesign into Windows NT made it as portable and Unix and its derivatives, yet today people still run Windows and the apps that run under it on a a derivative of the 8086 which was, itself, quite 8080-like.

Then, the RISC era was one in which much application software was written in high level languages so simply re-compiling it would take care of both the different processor instruction set and a different OS ABI. In the days of CP/M, there were some high level language compilers especially for the 8080/Z80. PL/M, that Gary had written, was one of them. I don't think there was much of a selection for the 6502 - there may even have been none. The small stack and lack of 16-bit index registers may have something to do with that. Then there were almost certainly applications written in assembler that would take some effort to port. The two CPUs are sufficiently dissimilar that machine translation isn't likely to result in efficient code.

[paulb]

Bear in mind that the heyday of RISC came and went, and Microsoft even ported Windows to a couple of RISC processors, possibly determined to proves that the redesign into Windows NT made it as portable and Unix and its derivatives, yet today people still run Windows and the apps that run under it on a a derivative of the 8086 which was, itself, quite 8080-like.

The influence of the AMD 29000 on the implementation of modern x86 (and thus x86-64) processors is a story worth reading. When people argue about whether such processors are actually "RISC internally", they could save themselves a lot of time and just read articles like this one:

"AMD’s K5 Designed to Outrun Pentium", Microprocessor Report, 24 October 1994.

Or even AMD's own manual.

Then, the RISC era was one in which much application software was written in high level languages so simply re-compiling it would take care of both the different processor instruction set and a different OS ABI.

Indeed, one of the foundations of RISC is the property of the instruction set architecture to conveniently support the generation of code from high-level (systems) programming languages.

In the days of CP/M, there were some high level language compilers especially for the 8080/Z80. PL/M, that Gary had written, was one of them. I don't think there was much of a selection for the 6502 - there may even have been none. The small stack and lack of 16-bit index registers may have something to do with that. Then there were almost certainly applications written in assembler that would take some effort to port. The two CPUs are sufficiently dissimilar that machine translation isn't likely to result in efficient code.

I found myself thinking of 6502 assembly language programming as a bit like working with a machine where, soon enough, one's fingers are soiled with the grease of the machine: the need to shuffle values between registers, for instance. The fixed location, limited size processor stack is not really conducive to high-level language use, and there is a significant penalty for generated code that accesses stacks greater than a single page, as you note.

Even so, there are still people who claim that 6502 is somehow "RISC" as it practically fails all the key tests of what a RISC architecture should be.

[Coeus]

The influence of the AMD 29000 on the implementation of modern x86 (and thus x86-64) processors is a story worth reading....

Thanks, Paul. I have read the first two linked articles and sampled the AMD manual and found them very interesting. I think it was mentioned previously that processors could no longer be classified as purely RISC or CISC from the instruction set as seen by the programmer. Certainly I didn't mean to suggest that the era of processors with obviously RISC instruction sets and marketed as RISC had been a dead end or waste or time, it was more pointing out just how much inertia there can be in the defacto computing platform at any particular point in time.

Indeed, one of the foundations of RISC is the property of the instruction set architecture to conveniently support the generation of code from high-level (systems) programming languages.

This is presumably relevant to the direct conversion of those x86 instructions that result in a small number of ROPs, with microcode for the more complex ones. The set that translate to a small number of ROPs are presumably the ones that will be most often generated by compilers.

Even so, there are still people who claim that 6502 is somehow "RISC" as it practically fails all the key tests of what a RISC architecture should be.

I don't have a reference to hand for what counts as RISC. The 6502 certainly has a smaller instruction set than the 6800 or the Z80, probably the 8080 too but that depends on how you count all the register to register moves. But, the instructions it does have are not optimised for a compiler to generate. Apart from the stack and register size, some addressing modes can use X, some Y and some both.

[paulb]

Thanks, Paul. I have read the first two linked articles and sampled the AMD manual and found them very interesting. I think it was mentioned previously that processors could no longer be classified as purely RISC or CISC from the instruction set as seen by the programmer. Certainly I didn't mean to suggest that the era of processors with obviously RISC instruction sets and marketed as RISC had been a dead end or waste or time, it was more pointing out just how much inertia there can be in the defacto computing platform at any particular point in time.

No, you made a good point, and that is why I brought up the Am29000 and the K5 that followed on from it. AMD is obviously well known for its x86 clones and its own designs, but they could have pursued a RISC strategy based on the 29000. In the end, they decided that it was better to focus on the more lucrative x86 market and to apply knowledge from the 29000 to a Pentium competitor which their x86 business really needed at that point.

Indeed, one of the foundations of RISC is the property of the instruction set architecture to conveniently support the generation of code from high-level (systems) programming languages.

This is presumably relevant to the direct conversion of those x86 instructions that result in a small number of ROPs, with microcode for the more complex ones. The set that translate to a small number of ROPs are presumably the ones that will be most often generated by compilers.

Actually, the notion of RISC operations that are hidden from compilers itself makes the RISC nature of those operations questionable, if one is to insist that a RISC architecture is one that caters to compilers. I have seen the occasional enquiry by people wondering whether there is a way of getting the processor to use the ROPs directly, but the nature of the implementation precludes it. Clearly, compilers can only generate x86 instructions for processors like the K5, so the ROPs cannot benefit the compiler directly. I do wonder how their existence has influenced x86 compilers, however.

Even so, there are still people who claim that 6502 is somehow "RISC" as it practically fails all the key tests of what a RISC architecture should be.

I don't have a reference to hand for what counts as RISC. The 6502 certainly has a smaller instruction set than the 6800 or the Z80, probably the 8080 too but that depends on how you count all the register to register moves. But, the instructions it does have are not optimised for a compiler to generate. Apart from the stack and register size, some addressing modes can use X, some Y and some both.

Looking through the literature, some of the less controversial suggestions were:

• Orthogonal instruction set with few addressing modes, preferably separating instructions that do "work" with those that merely access memory
• General purpose registers, preferably in abundance, as opposed to ones reserved for specific purposes
• Regular, typically fixed-size, instruction formats that facilitate the decoding and issuing of instructions
• Use of pipelining to aim for single-cycle execution of instructions

An architecture that is convenient for a compiler to target follows from instruction set design and register availability. Meanwhile, things like the constraints on instruction size facilitate pipelining and the scheduling of the different tasks involved when handling each instruction. With the 6502, it has several addressing modes, few registers with these having specific applications, variable-length instructions that may or may not employ numerous formats (I haven't checked), and it doesn't aim for single-cycle execution beyond a few simple instructions.

Returning belatedly to the topic, your point about the suitability of the 6502 for higher-level systems, including its suitability for native compilers, is a crucial one. People were eager to use higher-level languages and systems, but the 6502 seems very much like a microcontroller-level product. Even augmented with additional logic to make more sophisticated systems possible, its instruction set architecture still seems to deter native code compiler development.

And compilers and high-level languages obviously became much more important over time. RISC architectures, despite having nicer instruction sets to use (an apparent motivation for the ARM designers), were introduced to leverage compiler availability. Compiler availability led to an emphasis on portability, at least in the sense of hiding the underlying architecture, taking us to the scenario you mention where many people run a legacy operating system on a superficially obsolete architecture. CP/M, the 8080 and Z80 seem to feature on that particular general path of progress, whereas the 6502 seems to sit on another.