Why does the Commodore C128 perform poorly when running CP/M?
retrocomputing.stackexchange.com
retrocomputing.stackexchange.com
So just to write one character onto the actual screen required six writes into the controller chip. Adress-low-register-number into D600, screen address LSB into D601. Then address-high-register-number into D600, then screen address MSB into D601. Now you're ready to write 'A' into the actual screen buffer! So, write-data-register-number into D600 and 0x41 into D601!
Do you want to put a 'B' on the screen right after that 'A'? Repeat the above - six more writes to get the 'B' showing! Why they didn't embed an auto-incrementing screen address counter in the controller is beyond reckoning. At least that way you'd only have need to set the address once, and could then leave the select register (D600) parked on the write-and-increment register, and merrily stuffed your display string into D601 with a relatively tight loop.
Presumably the Z80 had to put up with the same annoying 80 column controller. That can't have helped.
They did.
Page 361 of the Commodore 128 Programmer's Reference Guide (halfway down the page):
> At this point, the 8563 hardware takes over. It automatically increments the address contained in the update register pair (R18, R19). You as the programmer do not increment the update register pair's contents; the 8563 chip does this for you automatically. You can say that the update register pair is auto-incrementing.
You can get the ProgRef here: https://www.pagetable.com/docs/Commodore%20128%20Programmer'...
So, yes, it did auto increment. I think what happened is that after 35 years, I just recalled my initial aggravation with addressing the 8563's RAM through that keyhole of R18, R19, R31.
But .. looking around in the ol PRG, and finding some of Mr Herd's "choice comments" out on the web, I'd still say the 8563 was a dog. Case in point, having to poll D600 for bit 7 to become set just to make sure the 8563 had cottoned onto your request to set a register.
That bottleneck to get to the 8563's RAM was not fun. The bottleneck to get into the 8563s own registers was even goofy. Why not just map them to D600-D61F ?
The C128 was... it was just a bad computer, I'm sorry. This was the swan song for the 8 bit machine, the market was moving very rapidly onward in 1985 as it was released (within 3 years or so it would be routine to see new personal devices quoted with multiple megabytes of fully addressable RAM and 256kb+ color framebuffers).
Commodore threw together what they could to keep the C64 band together for one more tour, but... let's be honest, their last album sucked.
[1] vs. software for contemporary PC's that had largely abandoned the equivalent MS-DOS abstractions and was blasting bytes straight into the MDA or CGA text buffers. You could technically do that on the 128 also, but that would mean losing compatibility with a decade of CP/M software designed for other terminals, which was the only reason for having the Z80 there in the first place.
[2] The 6502 had an essentially synchronous bus where the data resulting from the address lines latched at the rising edge of the clock was present when the clock fell. The Z80 had a 3-cycle sequence that needed to be mediated by glue logic to fit what the VIC-II was expecting, and it didn't fit within a single cycle. That's the reason for the Z80 having to run at "half speed", essentially.
Exactly! Bil Herd said it was just supposed to get them through a year until the Amiga picked up. Nobody expected the 8-bit line to last so long with a multitasking multimedia powerhouse out there for under $1000.
It's hard to remember how fast things changed in the early era of computing. The killer app that finally put the knife in the 8 bit home computer was... the web browser.
Every new project was obsolete or nearly so at launch.
I've sometimes seen people say "Oh, modern computing sucks so much, if only the Commodore line had continued on and been the basis for computing instead of the IBM line"... and I have no idea what they mean. Even the Amiga may have been neat for the time, but trying to project that line forward all the way into 2022... well, whatever would have gotten here probably wouldn't be all that different than what we have now.
Commodore did some interesting things. They lost for reasons, though. Even the Amiga.
In the same way if we had of waited for Silicon Graphics to provide desktop 3D graphics, we would have been waiting for a LONG time and at a high price.
OTOH, we wouldn't need to put up with Windows for so long ;-)
They were lovely things, too. I wish I'd bought one when PIIIs were being flogged off.
The US market was the largest computer market at the time and the Amiga sales in the US were awful. This left Commodore financially incapable of continuing on the path of technical innovation. Even in the few countries where the Amiga could have been considered a success, UK, Germany and Italy, the vast majority of sales were for the low end and margin A500.
To me, the biggest tragedy was when Commodore refused to allow Sun to package the A3000 as a low-end Unix workstation.
It could have changed the world.
I regard the C128 as a very flawed project - even more of a kludge than the Apple IIgs (a 16-bit computer built around an 8-bit one from the previous decade, kind of a 16-bit Apple /// with a //c inside and two completely different ways to output pixels, plus a full professional synthesizer attached somewhere in there - fun machine, but don't look too close).
They could have used the effort that went into the 128 to beef up the VICII with a TED-like pallette and have a brilliant last C-64 computer to show.
Well, on the other hand, it did give us the 65816, which the SNES was built on top of.
On the other other hand, though, it probably would have been better if the SNES had gone with m68k.
Notably, IBM had a 68000 desktop computer that ran Xenix, the IBM CS 9000.
https://archive.org/details/byte-magazine-1984-02/page/n279/...
The 8086 was a... what now?
It may be a horrible architecture but the fact that we are here is a pretty good testament to it not being a dead end.
Personally, I think x86 is pretty ugly, but both compilers and chip designers have done an admirable job taming it, so it's not that bad. Process/fabrication concerns tend to dominate nowadays.
Practice beats perfection
The engineer’s game we play
Make do with what we've got
And make it work today
Intel/AMD could make their new CPUs start in protected mode, even long mode - and nowadays, likely nobody other than BIOS developers would ever notice. Why don’t they? I guess it would be a fair amount of work with no clear benefit.
One thing they could do - legacy features (real mode, 16-bit protected mode, V86 mode, etc) are now an optional feature for which you have to pay a premium. They could just have a mode which disables them, and fuse that mode on in the factory. With Microsoft’s cooperation, Windows 11 could be made to run on such a CPU without much work. Likely few would demand the optional feature, and it would soon disappear
Customers who need them could just emulate them. Almost everyone already does anyway (DOSBox, etc.)
Though, honestly, I highly suspect the die space spent to support those features is pretty small, and power dissipation concerns mean that it's quite possible there aren't much better uses for that silicon area.
Consider a code base filled with numerous legacy features which almost nobody ever uses. Their presence in the code and documentation means it takes longer for people to understand. Adding new features takes more time, because you have to consider how they interact with the legacy ones, and the risk of introducing regressions or security vulnerabilities through those obscure interactions. You need tests for all these legacy features, which makes testing take more time and be more expensive, and people working on newer features break the legacy tests and have to deal with that. Technical debt has a real cost - and why would that be any less true for a CPU defined in Verilog/VHDL than for a programming language?
And a feature flag is a good way to get rid of legacy features. First add the flag but leave it on. Then start turning it off by default but let people turn it back on for free. Then start charging people money to have it on. Then remove it entirely, and all the legacy features it gates. It works for software-I can’t see why it couldn’t work for hardware too.
If they really are such a security risk, surely enterprise customers would rather pay for the ability to turn them off.
There must be dies being thrown away right now because they work perfectly except for one of these legacy features. If they had SKUs with legacy features fused off, suddenly those dies might become usable.
Having lower-end SKUs with some features fused off allows you to use dies in which those features are broken. But, it means you have to fuse them off even on the dies in which they work. Buying a low end CPU and finding that some of them randomly have higher-end features would just be too confusing for everyone.
Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either.
You may well be right, that a die being damaged in exactly that way, is rare enough, that the additional yield from being able to use such dies is rather marginal. But I think it would be hard for anyone to know for sure without non-public info.
> Fundamentally changing the instruction format might save a little bit of space, but then it wouldn't be compatible with x86-64 anymore either.
I wasn't talking about that. A CPU which didn't support real mode, 16-bit segments, etc, would still have the same instruction format, so instruction decode would be largely unchanged.
I wonder if we'll ever see a CPU which supports executing both x86 and ARM code, through separate instruction decoders but with a shared execution engine. Of course, there are lots of differences between the two architectures beyond just the instruction decoding, yet in some ways those differences are shrinking (when you look at features like Apple Silicon TSO mode, and Windows 11 ARM64EC architecture).
If it is RISC-V, I will celebrate it.
Which is to say, the 65C816 did pretty much exactly what the 8086 had done, including a bunch of the same mistakes[1]. Which would have been fine if these were head-to-head competitors. But the 8086 shipped six years earlier!
[1] Though not quite 1:1. Intel had a 16 bit data bus from the start, but the WDC segmentation model was cleaner, etc...
Eh, I don't think this is generally true. Intel's decision to have the segments overlap so much was definitely very short-sighted, but the 8086 has a big advantage in having multiple segment registers with the ability to override which is used via an instruction prefix. This makes copying data between two pages straightforward on the 8086 whereas you need to constantly reload the databank register on the 65C816.
I think as a pure 16-bit design the 8086 is actually pretty good. It's not at all a forward-looking design though so it wasn't well suited to being the basis of the default PC architecture for decades to come.
Don't the MVN and MVP block transfer instructions let you specify separate data banks for the source and the destination?
(I agree that the 8086 was a superior design to the 65816 in most other ways.)
The only new registers are the code bank and data bank registers, and I think the code bank register can't even be directly set. You have to do a 24-bit JMP or JSR, and that automatically changes the bank.
The A/X/Y registers all get extended to 16-bits, but A can be addressed as 'A' and 'B', two 8-bit registers. A mode change is necessary for this.
It's a particularly hard CPU to generate code for. There's a commercial, free to use for private use C compiler, but most people use assembler.
Pointers are a pain in the butt... You have to use a direct page memory location to fake a 24-bit pointer. On the 8086, you could at least use the ES register to point anywhere without a DP access.
I had forgotten about that! Yeah, that's horrendous.
> The only new registers are the code bank and data bank registers
There's the relocatable DP register, which you could use as a frame pointer (I've written code that does this). It's still quite awkward though.
> I think the code bank register can't even be directly set. You have to do a 24-bit JMP or JSR, and that automatically changes the bank.
To be fair that's how x86 works too, right? You have to do a far jump or far call to switch CS. (Also you could push addresses on the stack and do a far return on both 65816 and x86.)
> It's a particularly hard CPU to generate code for. There's a commercial, free to use for private use C compiler, but most people use assembler.
This is absolutely true. 6502 derivatives are almost uniquely hostile to C-like languages—witness all the failed attempts at porting LLVM to them—and the 65816 is no exception. I'm pretty sure that in an alternate world where 6502-based microcomputers had become dominant, the classic 6502 ISA would have quickly become relegated to some sort of legacy emulation mode, and the "normal" ISA would be nothing like it, unlike the relatively modest extensions that the 286 and 386 made to the 8086 ISA.
This is another bit of Amiga lore that is a little spun. There was no space in the market for a 68030 Unix machine in 1992 though. Even SPARC's days were numbered. Not two years later we were all running Linux on Pentiums, and we never looked back.
https://en.wikipedia.org/wiki/Amiga_3000UX
$3400 in 1990 is pretty high, but I guess cheap for a "workstation." The average business would probably just suffer on a PC with DOS and Lotus 123 or something.
386 PCs were going for $3500+ in 1990.
But a 386 and graphics are not needed to do what I mentioned.
Apple IIgs (a 16-bit computer built around an
8-bit one from the previous decade, kind of a
16-bit Apple /// with a //c inside and two
completely different ways to output pixels,
plus a full professional synthesizer attached
somewhere in there - fun machine, but don't
look too close).
It simply didn't have the CPU horsepower to really do the things it was otherwise capable of... the Mac-like GUIs, the new graphical modes in games, etc.
When you use a IIGS with one of the accelerator cards (Transwarp, etc) that gives it a faster 65C816 (7mhz, 10mhz, etc)you really get a sense of what the IIGS could have been. Because at that point it was a solid Atari ST / Amiga peer (very roughly speaking, lots of feature differences)
It's not entirely clear to me why it didn't have a faster 65C816 to begin with. I know there was a lot of competition inside Apple between the AppleII and Mac divisions, and I suspect the IIGS was hobbled so that it didn't eclipse the entry level Macs. However I'm also not sure if higher-clocked 65C816 chips were even available at the time the IIgs was designed and released, so maybe it wasn't an option.
That's exactly why. Apple didn't want the GS cutting into Mac sales.
But... have you ever seen direct confirmation of that from folks who worked inside Apple at the time? Curiously, I've never much inside info materialize from the Apple II side of the business.
The Commodore 65 was going to be that, kind of. It really is a shame that it never saw the light of day. At least now we have the MEGA65 for some alternate history retrocomputing.
(On the other side of the spectrum, it also the year that the cheap famiclone home computers came about, which totally failed to make an impression on US or western European markets, despite their capability to run NES games out of the box. Well, there were probably legal issues involved, as well, but there wasn't even an interested gray market for them.)
680x0 Unix machines were pretty long-in-the-tooth by the time the Amiga 3000 was available. Sun themselves had moved on to Sparc. NeXT was about to give up on hardware. SGI would move on to MIPS CPUs... etc
If the 680x0 product is a failure, they've saved the cost of designing a custom machine and stocking inventory.
If it's a wild success, they have a partner which can scale up on demand. I suspect even in the Amiga's mid-life, Commodore was shipping an order of magnitude more machines than Sun was.
Also, Sun had launched a 386 system (Sun 386i) a year or two before that, so they were already on Intel. I think if they wanted to go the lower cost "consumer" route, they could've found a random PC clone vendor to help them scale up faster than Commodore.
Commodore was mismanaged and died. Apple was mismanaged and nearly died. A proprietary computer ecosystem controlled by a single company is at risk of being run into the ground by incompetent management or sheer bloody economics. That's why the PC and not the Amiga, Old World Mac, or Atari ST became the basis of modern computing.
And the IBM stamp of approval legitimized the PC, starting the unstoppable tsunami.
Note that they took out 7 patents on the PC AT (286). When their attempt to take back control via the PS/2 in 1987 failed, they spent the 1990s getting chipset makers and clone makers to license their patents. Had they tried this in the 1980s the industry might have gone in a different direction.
You can't clone a Mac without their ROMs, and a clean-room implementation would fall quickly behind without a sustained effort. But Microsoft can sell anyone the disks, and your clone can respond to the right interrupt calls, and IBM can't do a thing to stop either of you.
That's why Magic User Interface felt "wrong" on the Amiga, despite being a superb toolkit in lots of ways* - drawing was relegated to the application's task, making it feel "Windowsey".
(*I would genuinely like to see a port of MUI to X / Linux.)
That it can support a graphical user interface at all is only due to having a lot of CPU time to waste!
But 14-year-old me loved his tremendously. 80-column mode felt so futuristic! BBSes looked amazing! And BASIC 7 was a lot more fun than BASIC 2. I felt like I was getting away with something when I learned I could enable 2MHz mode in subroutines, and if they were fast enough, the screen wouldn't even flicker before I reverted to VIC-capable speeds. Good times.
7 cities of gold and Archon especially.
But note that the 128's Z-80 CP/M processor was effectively a recapitulation of the Microsoft (yes, that Microsoft) Softcard product that they shipped in 1980 for the Apple II. The Softcard was a huge hit and an absolute revelation to the small handful of users[1] in its world. In point of fact it was the single most popular CP/M computer sold anywhere.
And yet it was afflicted by most of the same problems the 128 was. Everything is about timing. Commodore happened to be five (yikes) years late to market with the idea.
[1] This was just a tiny bit before my time. And in any case I grew up in an Atari 800 family and wouldn't have been caught dead with a II plus.
This is a common statement. It's not true. As pointed out down the comments, it was pretty much only the last 8-bit in the US market.
https://news.ycombinator.com/item?id=33925871
The rest of the world carried on making 8-bits for another decade or more.
New 8-bit machines and ranges of machines launched after in or after 1985:
• Sinclair Spectrum +2
• Sinclair Spectrum +3
• Acorn BBC Master range
• MGT SAM Coupé
• Amstrad CPC Plus range
• Amstrad PCW series
• MSX 2
• MSX 2+
• MSX Turbo-R
That's not counting 21st century reboots, of which there are hundreds.
Notably, after the collapse of Communism in Europe, the West found out about legions of enhanced ZX Spectrum clones and the like from the Warsaw Pact countries. Amazing machines with built-in floppy drives, hard disk controllers, stereo sound, improved graphics, lots more RAM (megabytes of it) and so on.
http://rk.nvg.ntnu.no/sinclair/computers/clones/russian.htm
<- pay attention to the dates column.
Some are still being made.
https://www.hackster.io/news/css-electronics-zx-nucleon-is-a...
Note this is real hardware, not FPGA emulation or anything, although some of those are amazing too.
https://github.com/UzixLS/zx-sizif-512
I know that the USA thinks that the C128 was the last new 8-bit machine, but in fact it was only about the half way point of the evolution of 8-bit home computers, and some of the more interesting machines were yet to come. Entire families of native CP/M computers that sold in the millions of units in multiple countries. Capable home games computers with amazing graphics. Powerful educational/laboratory machines that gave rise to the ARM chip.
But they weren't American, and so everyone in the USA doesn't even know that most of them existed.
That and the SAM Coupé were kind of ridiculous, looking back, being so massively outdated at the time. In the UK, both were obviously worse for games than even the Atari ST, which was already starting to get shown up in that respect by the Amiga. (And the writing was on the wall for Amiga games too, thanks to increasingly impressive bitplane-unfriendly ALU-heavy PC games, and the SNES. And Windows 3.1 - which was actually turning out to be useful, no matter how janky - was attacking every other platform on the productivity side.)
The Amstrad and Sinclair markets kept going in the UK until 1991 or so, likewise the C64, as the machines were everywhere and so there was still a market for the games.
8-bit Acorn games dried up in 1990 (after probably last being a proper going concern in 1988 at best), but they kept producing the hardware until the early 90s because of demand for it from schools. (I have a BBC Master as part of my collection of crappy old UK 8-bit computers from the period. Manufacture date: week 47, 1989!)
The SAM Coupé was a great little machine -- I deeply regret selling mine -- but it took way too long to get to market.
I think in context with Communist Bloc improved Spectrum clones, it makes more sense. It was of course easier for companies and people over there (well, over here, for me now)_because they didn't need to worry about copyright law and could just copy the ROM.
I think there is an argument for high-end 8-bitters, and it's why the Spectrum Next exists. Because they are much easier to understand, and build, and modify, and copy, and program.
The industry rushed to 16-bit, because of the new features, but it took programmability out of owners' and users' hands.
Modern OSes are vastly, impossibly complex and people accustomed to them do not understand the virtue, indeed vital importance, of simplicity and comprehensibility.
This is why, for me, Python fails as a teaching tool for beginners. It embeds all the complexity of files handling, editors, OOPS, C output formats and so on. BASIC eliminated that. Its conceptual model was not of files and things but a much simpler and more accessible one:
You type some stuff.
No number in front? Computer does it now. Number in front? Keep it for later.
That is inspired brilliance, but the Unix weenies want pro tools for all, even for kids.
Interesting that some of the slowdowns are directly attributable, even back then, to greater abstraction in the newer CP/M BDOS.
It was so easy I wrote my own at one point (before I discovered/got nansi.sys? I can't remember the sequence). It was IIRC faster than the later nansi sys replacements but didn't work 100% of the time either. Probably because I only implemented the common subset needed to run a couple programs I wanted faster text output from. I remember for a while switching back and forth between mine and a replacement driver depending on application before I got a 486+VLB which was so fast that I could no longer tell the difference between the two.
Now in the glorious future of 2022, every console app runs on an emulated DEC VTxxx, and if you press "Esc" it can't be sure if that's a real key or part of some control sequence unless it waits a second to find out if more bytes arrive.
> each character is compared to every possible control character before it is decided that it isn't one
That's crazy; ASCII was carefully designed to avoid this kind of shit.
This is something to point them to.
There's not a lot in common between the ST and the C64 other than "rock bottom price" and "multiplex the memory BUS between the CPU and the VDP" (VICII/Shifter). The C64 laid in heavily on accelerating video via a custom chip (a bit like the Amiga and Atari 8 bits) but the ST's video was really just "spew a bitmap out of RAM."
Don't get me wrong, I loved my ST.