6502.org

Looking at the C128D layout I got inspired thinking up a revisionist "what if" situation.
What if Commodore had actually used the budget on some worthwhile hardware that could actually be used in conjunction, instead of being split up into each its own little domain?
Let's just list the real C128Ds specs.:

- 6510 derivative @ 2 Mhz CPU
- Z80 for CP/M @ 4 Mhz
- Simple MMU
- 128Kb of DRAM
- VDC 80 Column graphics chip, with borked bitmap mode.
- 64Kb VRAM for the VDC
- VIC II
- SID II
- The PLA from C64 for BC.
- Another 6502 with 8Kb of SRAM for controlling the drive
- 340Kb 1571 drive
- Lots of separate ROMs for different parts of the firmware

All in all a very kludgey design with lots of redundancy. Surely the budget could have been used better?
How about:

- 65816 @ 8 Mhz. Even though none of the few machines that actually used the 65816 clocked it as high as 8 Mhz, I have no doubt that it was actually possible at the release time of the C128. It was just as matter of putting a cooling profile on it and giving it space to breath in the box. The CPU would of course also control the drive and IO devices, more than making up for the extra cost. A 65816 would have meant rougly double the power of a 68000, with BC to all 6502 code at a lower price.

- Simple but fast DSP like chip, for 3d and 2d transforms and possibly also part of the sound processing. Maybe done with TCL bitslice technology like the AMD 2901, but preferably with a proprietary static (asynchronous?) CMOS device. Little more than ALUs with multiplication accumulators. If necessary a differential analyser for line drawing.
This feature would really give the C128 a huge boost over then contemporary systems.

- DMA/MMU control unit for feeding the DSP, for blitter functionality, for simple virtual memory and for larger and more diverse address space in general.

- 8 Kb SRAM scratchpad (not a cache) for making it possible for all the processors to access memory at the same time, and for jobs that just need a small a amount of very fast memory.

- VIC III with compatibility for a VIC II calls but with the possibility of using the 1Kb of sprite RAM for palette, either 4bit with 512Kb left for sprite data or a full 8bit palette. 8 or 12 bit fixed palette. Simple line an column scaling for doing mode 7 and Wolfenstein like effects. This would be little more than an extension of the already present sprite sizing feature in the VIC II.
Also, if possible on the same die, compatibility for the very simple Apple II hardware. Access to the pre GS liberary of Apple II software would be a huge advantage, possibly bigger than CP/M compatibility and much easier and less expensive.

- SID II made by Bob Yannes. Identical to the one that wound up in the Apple IIgs but with BC for SID calls.

- 64Kb of VRAM split into two banks for double buffering.

- 128 Kb of RAM. No an larger than this because memory wouldn't be as important with a larger disc and VRAM. The memory could be expanded easily and relatively inexpensively with cartridges of either ROM or RAM discs.

- 1.2 Mb disc drive with a slowwrite mode for old formats. A 5¼ drive because of BC, but also because 5¼ discs was quite a bit cheaper to produce (until scale of economy caught up to 3.5) and have more recording area for a given head technology. I don't think a 1.2Mb drive would be that much more expensive than the drive already found in the C128D. After all, the X68000 included two in 1987. A 1.2 DD, perhaps coupled with programs in a ROM/RAM cartridge, would make up for a much more expensive harddrive.

- FORTH as the main "OS". It's small and much better than BASIC. With a simple and nice looking front end (also written in FORTH of course) for the most commonly used commands and disc ops.

I think a machine like the one described above would actually have been a better strategy than the Amiga. It would have been faster overall, have features the really changed the game and set it apart from other micros at the time; all in all I think it would give much more bang for the buck.
Actually it needen't be Commodore doing this machine at all. Why didn't anyone try at least parts of this more aggressive design strategy? It seems that it was more than technically and economically possible to do more than rudimentary 3D and have a much faster CPU at the time.
Arcade machines like I, Robot in 1984 and the unreleased Konix Slipstream, shows that it was very possible to design inexpensive hardware for pretty decent 3D in the mid 80's.

Actually, a 65816 represents about 0.8x the power of a 68000. What makes the 65816 appealing is the amount of performance you get for the cost. (The 68000 was much more expensive a chip.) But, the 68000 was still a more powerful CPU clock for clock.
These didn't really exist back then, and no prior application required such processing power (remember, we're still in the generation of POKEY and SID chips, and the Amiga's blitter was considered the eighth world wonder). There was no way they could have made this work, even if they could secure a specifications document for it (which they couldn't).

I would think an alternative is to just through another CPU on the board, perhaps another 65816 employing the opposite clock phase, like many arcade game systems of the time did.
I don't know the full details of the real-world VIC-III chip, but I do know it had 256 color support, and I believe a palette of 4096 colors. http://en.wikipedia.org/wiki/Commodore_65
If you want 12 bitplane displays, you're going to need a lot more than 64KB.
Experience with the Amiga suggests otherwise. The CPU can address 16MB -- let it have 16MB. Otherwise, performance drops to a crawl, since your applications are now I/O bound, not memory-bound. Floppy disk access is more than four orders of magnitude slower than simple RAM access, even considering the awkward banking architecture the 65816 sports.
But, not bit storage density, which is determined by the grain structure on the plastic surface.
As much as I love Forth, I must admit it's not friendly to someone who expects to use the computer as an appliance, as most people did. It's stupidly easy to crash a Forth system by mistyping commands, leaving the user wondering what happened, or worse, with corrupted storage media.
As an owner of a relatively unexpanded, first-series Amiga 500, I contest this. The Amiga would have outperformed the unit by a small amount, and that's assuming you don't cheat by using the Amiga's chipset in innovative ways.

One of the reasons the 128D(CR) was designed the way it was was Commodore's vertical integration. The Commodore Semiconductor Group (CSG), formerly MOS Technology, supplied all of the specialized silicon to produce the machine. It would have made no sense from Commodore's perspective to use an MPU or other silicon made by a third party manufacturer when CSG could design and produce it in-house.

Similarly, a goal of the 128 product line was to achieve 100 percent Commodore 64 compatibility, which they almost did (there are a few differences). That would not have been possible with the 65816 for a number of reasons, one being the formerly "illegal" instructions of the NMOS processors are legal operations on the '816. Also, how would you have prevented a program running on the C-64 side from switching the '816 to native mode, which surely would have crashed the system when the first IRQ occurred (the '816 native mode interrupt vectors are different than those of the NMOS MPU).

I understand your obvious fondness of the C-128 but were you to actually produce a machine such as you describe as your ideal, it wouldn't be a C-128. I believe what you think the 128 should have been is a fairly close description of the Apple IIgs, minus the C-64 compatibility mode, of course.

BTW, BASIC was not the "main OS" of any Commodore 8 bit computer. It was certainly possible to run a Commodore machine without using BASIC, which was the case with most professionally written software. I believe you may be confusing the BASIC interpreter with the command line interface (CLI) common to environments such as UNIX. Of course, UNIX's CLI itself is a means of communicating with the operating system kernel. In that regard, BASIC in 8 bit Commodore computers acted as a sort of CLI.

The 65816 is almost double as powerful as the 68000 per clock. Look up the specs. It does run slightly hotter at those speeds though but as I said, all that means is that you have to splash out a dime for a cooling profile.
There certainly were real DSPs at that time, TIs is probably the most canonical. And before that there were bitslice processors, that could be made to run very fast because of the bipolar fab, but were also quite simple per die, because it wasn't as dense.
Ataris Battlezone and more importantly I, Robot used AMD bitslice technology as DSP transformation hardware. Those were quite impressive for their time. The Star Wars vector game actually used an early DSP.
The Amiga tech. was good but also a bit overrated today. There were many other competing architectures and approaches that were as good or better in some ways.
That would be another approach. It certainly would be more flexible, but it would not get you the huge boost in vector multiplying power a DSP like processor would.
That was many years later and what price do you pay for the large amount of colours? Slower overall performance when anything has to move or with overdraw. There is also a limit to how many colours you can put to good use with a 320x200 resolution. It's far more important to have something interesting going on than a few more nuances.
I didn't say bitplanes and I didn't say 12 bit pixels. Bitplanes isn't really suited for 3d or anything not very predictable. Chunked pixels are better suited for general purpose stuff. And the 12 bits should be for the reference palette, so you could pick 16 or 256 out of 4096 colours.
I'm not saying "limit it to 128 Kb", I said 128 Kb as standard, more would be optional expansion. A full 128 Kb (with no graphics buffering eating into it) is enough for the most common tasks. The virtual memory thing, would just be for allowing programs to be relatively seamlessly larger than 128Kb.
And indeed there were HD 5¼ discs with finer grain structure. Hence they could store 1.2 Mb.
There were 5¼ discs that could store up to 10 Mb. The move to 3½ was for other reasons than capacity, some of them being political.
I don't know what kind of Forth system you're using but that sounds pretty asinine (hrm. stackdump?). And I did mention a "nice frontend"? By supplying Forth with the machine you would encourage use of it. System software written in it would be very fast while at the same time being much more translucent.
It was the interface to which the user was presented when he turned on the machine, and also the language he would be most likely to want to learn, because "it was right there". Forth is much better suited for that role than BASIC, and with a frontend for the most commonly used disc OS functions, it would be perfect.

I have. I even built a computer around the chip.

If you're trying to convince me of this because of the IIgs clock speed versus the original Macintosh, allow me to correct a possible misunderstanding. The Mac Classic architecture stole cycles from its 8MHz CPU to refresh the display. Of course, so too did the Amiga, but the method used was very different.

The Amiga engineers realized that the 68000 only really cares about two of its four clock cycles per memory cycle: the 3rd and 4th cycle. This is because _AS is asserted in cycle 1, cycle 2 is effectively dead, cycle 3 is when _DTACK is sampled for the first time, and cycle 4 is used to release the bus if _DTACK is asserted at the right time. So, if you multiplex the bus during cycles 1 and 2, you can get 8MBps (because it's a 16-bit wide bus) throughput on an 8MHz bus.

The Mac engineers, however, didn't do this. They emulated the entire bus state machine, which means the CPU generated all four cycles, or the video generated all four cycles. This had the effect of dropping performance down to only 4MHz, since the bus wasn't as efficiently multiplexed.

As a result, the Mac's 68000 can push (or consume) no more than 2MBps of data. (4MHz effective rate divided by 4 cycles per bus transaction, times two bytes per word.)

So, the 2.8MBps 65816 bus compares favorably with the Mac's 2.0MBps throughputs, and as a result the IIgs performs every bit as good as the Mac Classic. As it happens 0.8 * 2.8 = 2.24, so despite Job's best efforts, the IIgs should still be marginally faster than the Classic. This can easily be proved by launching DPaint on the IIgs in 16-color mode, drawing something, grabbing a brush, enabling the spirograph tool, and painting. It will snow the Mac.
I stand corrected; I wasn't aware of the TMS32C010 release date. However, that notwithstanding, the applications one typically uses a DSP for these days weren't conceived of back then.
But, not back then. The Amiga's blitter was considered quite earth-shattering technology at the time, particularly compared with many arcade blitters.
But not for the price point Commodore hit. The Amiga was the first computer with a blitter under $1000. That's a significant qualification.

Sure, you might have put a DSP on the board, but at what end-user cost? My research on the TMS32C010 indicates TI marketed pretty heavily to government and space agency markets, and not so much to home computer vendors. I don't think they did that until the 32C032.
The VIC-III delivered. Years later, sure, but who cares at this point. It was done. Hardware wise, I think it meets most of your desired specifications.
I'm sorry; I just don't understand what you're trying to say here. I'm aware that increasing pixel density requires more work to update, but beyond that, you've lost me here.
Oops -- you're right. However, . . .
I could be wrong about this, but I believe Silicon Graphics machines used a planar architecture and had 3D acceleration. Anyway, non-sequitor to your discussion.
Type 0 ' bye ! in most Forth systems, and it will likely crash the next time you enter a command (unless bye happens to be ROM-resident) I'm not saying users will overtly do this, but it illustrates that Forth is pretty happy at letting you shoot yourself in the foot with a simple typo in many situations.

One of the most common ways to nuke a Forth system is to perform a stack underflow, and then push something onto the stack. If you underflow far enough, you can inadvertently overwrite bits you shouldn't.

I've been coding in Forth for well over 10 years. My blog is written entirely in Forth (to the best of my knowledge, it's the only blog in the world written in Forth), I'm scheduled to give talks at Silicon Valley Forth Interest Group and at Ning. So, I'm not exactly a Forth n00b.

And, it's not assinine either; precious few Forth environments even bother with exploiting MMU circuitry to ensure wild pointers don't destroy your environment, and of those that do, you can still put them in states that make it impossible to do anything productive. Gforth under Linux is trivially easy to break, for example. I haven't tried under Windows because I don't run that OS, but I suspect the same is true there.

Have you tried running Moore's latest Forth environment, ColorForth? You can crash it by typing a command wrong (or, at least, you could as of four years ago; I'm sure that issue has been resolved now). How's that for fickle?

The general consensus in the Forth community has always been, "The programmer knows what he's doing."
Yes, you did; however, I don't have enough experience with Atari computers (which similarly had a menu-driven front-end interface to its DOS) to know if this would have made a difference or not in practice.
I think I agree with you here, definitely. They could have repackaged the C64 into a case with actual expansion slots, put in a faster disk communications bus (whether it relied on burst-mode or a C264-like parallel interface, it wouldn't matter -- as long as it was faster than the C64, it would have sold), and made BASIC optional on boot-up, they could have gone places with it. Finally, they could have addressed illegal opcode compatibility issues the same way Apple did -- by telling developers to go bugger off, and that they should have listened/read the section in the programmer's manual where it advised, overtly, against using undocumented opcodes.

(This is the approach Commodore took when the AmigaOS 2.0 environment was released, and it worked.)
You know, a "front-end" might not be needed; IIRC, the Acorn 8-bits had a system of invoking DOS commands from virtually anywhere by ensuring the 1st column of text you typed was "*". I know that SwiftForth under Linux and MacOS has a similar construct, $, which you can use to issue shell commands to. E.g., $ ls -la. I suppose that would have worked too...

Oh, BTW, I know I'm probably coming off as a bit of a moron, but I wanted you to know that I also asked the same questions. I wanted to build a 65816-based computer using an FPGA of some kind to envision an answer to the question, "If engineers from Commodore, Apple, and Atari got together to build the last 8/16-bit hurrah, what would it be like?"

If only I had more time...

and resources...

About 65816 being faster than 68000:

Listen to what Woz has to say in a 1984 byte interview:

BYTE: How is its performance compared to the 68000?

WOZNIAK: It should be available soon in an 8-MHz version that will beat the pants off a 68000 in most applications, and in graphics applications it comes pretty close. Some of the Macintosh people might disagree with me, but there are ways around most of the problems they see. An 8-MHz 65816 is about equivalent to a 16-MHz 68000 in speed, and a 16-MHz 68000 doesn’t exist.

Source: apple2history.org/museum/articles/byte8501

As you write the 68000 can only access memory every fourth cycle, while the 65816 can access every cycle. The 65816 only has an 8 bit databus so that slows it down by half, but the instructions are only 8 bits wide so they can be executed faster. So the 65816 while it has lower bandwidth, can make more efficient use of it, AND it can access it every cycle. The 68000 does have more registers though, which depending on what school you're from is a good or a bad investment. It does speed up matrix multiplications though, so a dedicated co-processor for that on a 65816 system would be nice.
I can't see how your GS vs. Mac example redeems the 68000. It flat out just was slower for a lot of operations.
That it had better compilers and some people like programming it more is another story. The Amiga just used the bus for something else while the 68000 didn't. The Mac couldn't afford special blitters and dedicated sound hardware at the time, so they had to make do.
They were used for sound processing, graphics and matrix multiplications in general. Of course new applications has cropped up since then and the field has widened considerably but many of the same needs existed back then as they do today. The first TI DSPs were geared toward ease of use and programming and very general use. A lot of silicon was "wasted" on that. A leaner more RISCy DSP like chip could have been made for considerably less and be faster...
You can do blitting in software very effectively. There were many add-on cards for PCs and Apple that allowed you to have similar or better performance in the same time frame and for approximately the same cost.
We care in this discussion. Going six or seven years into the future is cheating. And also, it was way to late to make anything of the C64 line at that point. That train had left 5 years earlier.
More bits per pixel means more data to move, hence slower display. If you want to do colour gradations (which is usually what more colours are for) you need resolution to let them develop over. For 320x200, which is the resolution a C64 successor would have used for graphics, 256 colours is a good balance between enough colours and being able to manipulate the screen fast.
I believe you are thinking of Pixelplanes, later Pixelflow, that was an extreme approach at cracking the fillrate problem with massively parallel hardware.
Well, Forth is nice because it's small, fast and has a healthy general approach to programming. BASIC does not. A lot of what you learn in BASIC is not good general practice, and certainly not with the 2.0 BASIC in the C64. Even though Forth is harder to learn and get started with, if you are serious about programming, it's a much better start. You can actually make great serious software in Forth, as opposed to any 8 bit BASIC. And BASIC isn't fickle too?
I can't see how it would not make all the difference in the world. It would give you a way to launch an app., format a disc, view the directory etc. without ever typing a command.
I agree, except they shouldn't have put in expansion slots. If you want a software centric machine you don't want to have people altering it all over the place, dividing up the userbase into single atoms. What's more, even on Apple II, few people ever used the slots for more than RAM expansions, if even that. People generally don't want to spend more on an already expensive computer, to get to run the few programs that support that particular piece of hardware. Only a few geeks will do that. Just look at the popularity of integrated graphics and sound and laptops today.
Yeah, as long as it's userfriendly. When you just want to launch a program, you don't want to have to type in short-story first.

Tempest and Red Baron also used the same bit slice processors as Battlezomne, 4 AMD2901s for mathbox calculations, with a 1 MHz 6502 for the main processor.

Atari later on went into serious DSP gfun with Hard Drivin which used the TI DSP set and dual 68000s. Insane motherboard set, though.

http://www.jmargolin.com/
Jed designed Hard Drivin and other games. A most fun website.

http://www.jmargolin.com/schem/schems.htm

Forth doesn't put the user in a straightjacket in a padded room to keep him from hurting himself. The freedom it gives is wonderful, but perhaps dangerous to someone who doesn't want to learn what they're doing. Still, misspelling a command usually just harmlessly gets you an error message that the word is not found in the dictionary. As for underflowing the stack and then pushing something, having at least a half-dozen available cells there that nothing else uses should keep it pretty safe, then things run without enough parameters will end harmlessly with an error message that the stack underflowed-- not that the user absolutely couldn't hurt himself, but the risk would be greatly reduced. I don't know-- I might be able to be convinced to let the user have a Forth command-line interface. The desire for more power and efficiency, along with getting rid of the punctuation, might be enough to motivate him to be careful enough.

The same can also be said about other operating systems. UNIX was long-criticized for not insulating the user from his own ineptitude. However, that lack of insulation means that an experienced user who knows the system is not hamstrung when he needs to do something unusual.

If you are working at the OS level you need to approach it the same way as an electronics technician would in working with the final stages of an RF transmitter: don't get into something you don't understand.

WOW! Thank you sir for that. There seems to be a wealth of schematics in there. Thanks for those links!!! I see Battlezone, Space Battle, Space Duel, Black Widow used the 6502. Still looking. Back to on-topic...

My experience tells me this is false, perhaps said in an attempt to boost IIgs recognition. Western Design themselves will tell you as much, as their benchmarks confirm the 65816 only comes in about the same as the 68000.

Garth, do you still have that link to the benchmarks document? I can't seem to locate it anymore.
Right, and I don't think this is in question. The problem I see is that the 65816's fastest instructions, those which consume only 2 cycles, are precisely those which do the least amount of work: TAX, NOP, etc. All other 65816 instructions take 3, 4, 5, 6, or 7 cycles, with the dynamic average weighing in at 3.5.

Hmm... maybe this is what Steve was referring to -- perhaps he's thinking about the 68000's longer addressing modes, which takes 8 to 16 clocks to evaluate, and not the simpler modes. In that case, I can readily agree with Steve. However, again, most 68K coders avoided the longer "mainframe-y" addressing modes in time-critical code.

There's only one way to solve this dilemma . . . MythBusters style! We should come up with some tasks for a 65816 and a 68000 to solve, and time each of them. Maybe we can pit an emulated IIgs against an emulated Atari ST, and see how they compete.
The Mac also used 4-cycle memory access, which like I said, dropped the 8MHz-clocked CPU to 4MHz equivalent bus throughput, and that's not counting the 4 cycles per memory access either. Even if they did have the hardware, they didn't have the cycles to use it all.

The Amiga didn't have this problem, so it had plenty of bandwidth for 64-color/4096-color (HAM) displays (though 16-color 640xH displays consumed 100% bus bandwidth). All of this is assuming OCS and ECS chipsets of course; AGA works very differently.
Of course, there are tricks you can play with software-only blitters: you can precompile blitter operations into machine code at run-time, and use that. I think Macintosh did that to push QuickDraw's performance as high as possible, sans dedicated hardware. Still, hardware blitting will be at least an order of magnitude faster.
Ahh, thanks -- I'll google this soon.
Oy -- my presentation at work is going to be on exactly this topic. I'm going up against a room full of Java coders. Wish me luck; this will be fun.

I don't remember ever having a url--just paper--but I found this one. The Sieve benchmark field for the 68000 is blank, but on the other stuff, the '816 compares handsomely to 68000 and "x86" (whichever one that's supposed to mean).

Edit: I see they have something again about the "Terbium," but I put it in quotes because it's not the hardware processor we were led to believe some years ago was about to be introduced, but rather IP that you scale to your requirements, if I understand it right.

Ah, sieving for primes - everyone's favourite benchmark!

Garth's link to WDC has the '816 performing at 2.4x the speed of an unidentified x86, both at the same 8MHz clock speed. (I would say that the relevant clock speed to compare at is what you'd need for a comparable memory system, or the same power budget.)

The old Apple Assembly Line magazines have a few postings on benchmarks:

• Peter J. McInerney finds his 68000 at 12.5MHz, DTACK grounded 4.6x faster than an Apple ][, noting that a 68000 in a Macintosh would be half the speed
  
  November 1982 AAL, by Tony Brightwell 6502 sieve referenced by the above
  
  Charles Putney's program from the February issue referenced by the above
  
  Bob Sander-Cederlof referenced by the above

Man, we sure have gone off-topic.