Building the Commodore computer that should have existed | Hacker News Reader

Building the Commodore computer that should have existed

blog.snapeda.com

124 pointsnatashabaker60 comments

I wonder if Ms. Allaire knows about the C65[1]. Her initial sketch of specs[2] is not too far off from that.

IMHO Commodore was right to kill the C65 when they were already making the Amiga 1000. The end of all the 8-bit systems was pretty obvious by '89, when rumors of the c65 started going around - the Mac had been out for five years, the Amiga and Atari ST for four. It would have suffered a fate almost as ignominious as the Sega Saturn.

1: https://en.wikipedia.org/wiki/Commodore_65

2: https://www.c256foenix.com/forum/the-specifications/early-sp...

Yes, the death of 8-bit systems was obvious by 89, but so was the death of the 68000. Motorola was already pushing the failed 88000 by the late 80s. And the 68000 itself was killed off only a couple years later. So I don't really agree with you here. The 68000 was as big of a dead end, and IMHO was a terrible CPU for home computers and gaming machines. It was fast for 16 and 32 bit integer arithmetic, so basically good for its target market of minicomputer replacements and workstations -- but very slow at memory accesses and interrupt response, two things that slow down gaming/graphics type machines.

The Amiga would have been more responsive and really just as powerful with the same custom chipset tied to something like a 65816 clocked at 8mhz. Would have been able to address just as much RAM but would have higher interrupt responsiveness, and Commodore could have made use of its existing 6502 expertise, thrown in a couple SID chips, and maybe even a VICII for C64 portability. What a machine that would have been!

Likewise, I think Tramiel could have done something similar instead of diving down the 68000 path with the Atari ST. They could have improved on the excellent Jay Miner designed A8 chipset but tied it to something like the 816, which was just coming out in 84 when they started the ST project.

Just some fantasy alternative history :-)

>Likewise, I think Tramiel could have done something similar instead of diving down the 68000 path with the Atari ST.

The Atari ST was built from scratch in less than 8 months after the deal to license the Amiga chipset fell trouhg. The ST is an amazing engineering feat considering the insane schedule.

I agree on you that the 68k is a terrible CPU for gaming, but it got better when there was some cache added to it, starting with the 68030.

I had an Acorn Archimedes with an ARM 2 clocked 8 Mhz (the same speed as the Atari ST, and 1 Mhz faster than the Amiga 1000/500), it was so much faster than my ST.

I always wonder if considering the processor and the “chunky pixels” of the Archimedes if had had something like a Wolfenstein or Doom back in 1987 if it would have driven sales enough to change.

Ofcourse that was probably pretty unlikely considering the Acorn/Olivetti bet so heavily on the education market.

That was Zarch : https://www.youtube.com/watch?v=MNXypBxNGMo

This was the gold standard at the time.

Very much like the Zeewolf https://youtu.be/tVwScInZfP8?t=159

I wonder what the connection is.

Zarch : https://en.wikipedia.org/wiki/Zarch, 1987 Zeewolf : https://en.wikipedia.org/wiki/Zeewolf, 1994

The visuals look very similar, but I can't see any continuity in the wikipeadia article.

OTOH, the sqare grid terrain can be traced to at least https://en.wikipedia.org/wiki/Return_Fire although that was a sequel to a completely different game

Zarch was out out 1988, the port of Zarch, Virus, came out on Atari/Amiga a bit later, this came out 1995...

Chunky pixels? =) [1]

[1] https://www.youtube.com/watch?v=ACb0h7mmcQ8

Chuncky pixels refers to the "1 byte = 1 pixel" in this case, both the Atari and the Amiga had bitplanes, where the separate planes where interleaved into the bytes, this was a product of hardware limitations at times, for example using bitplanes you could do foreground graphics without the need to redraw the background graphics when the foreground moved, something that was valuable since the slow hardware (CPU and memory) could hardly keep up with the racing raster beam otherwise.

Probably not quite enough raw MIPS in 1987, but people have since ported it: http://gerph.org/riscos/ramble/doomplus.html

Maybe it was more a lack of the DOOM source code or know-how?

According to https://en.wikipedia.org/wiki/Instructions_per_second#Millio... the ARM2 at 8MHz was 4MIPS. The 386DX at 33MHz was 4.3MIPS. The 8MHz 68000 was 1.4MIPS.

Of course there could be other things that made it hard, such as too few bus cycles when running the 8-bit chunky graphics mode? Or that sound did not use DMA(I don't know if the Archimedes had sound DMA) or that the CPU had to mix samples instead of the sound hardware doing it?

Yeah don't get me wrong, I was an ST user and loved it. It was a business and technical accomplishment. All respect to it. My point was only that for that class of machines what we really needed was wider address buses, not necessarily wider data buses. Along with a wider data bus came slower cycle times for a bunch of operations. And cost.

> [Atari] ST.... what we really needed was wider address buses,

Are you sure? With memory costing hundreds of dollars per MB in the mid-80's, I remember thinking a 24-bit address bus was plenty. (I actually don't think I personally had a computer with enough RAM to need more than 24-bits of physical addressing until the mid-90's.)

I never meant wider than 24 bits. I meant wider than the 16 bits on the 8-bit machines. Sorry if I was unclear. I didn't need a machine with more than 16MB until the mid 90s.

Agreed... 16-bit physical addressing was very limiting. (x86's 16-bit segment offsets were bad enough.)

> The Amiga would have been more responsive

What was the problem with Amiga responsiveness? Never heard about this. Interrupt response? What?

For several years, it had the best games. The bitplane-based graphics system became a hindrance with FPS-games but that was never about the CPU.

If you go back and look at those games again, the frame rate, it's not that great. Many of the 8-bit machines actually had better responsiveness and frame rates. Yes, the Amiga was awesome. It was not perfect.

Also, as far as 68000-based machines goes, the X68000 kicks the Amiga's ass.

The Amiga chipset used DMA very extensively, so the CPU's memory access speed is not as important as on other machines. There were other architectural constraints, like the fact that the CPU had to compete with such chips for access to the same memory. So-called Fast memory was not a default setup for years. And the true solution, dual-ported RAM would have been too expensive.

Which games do you think were constrained by the CPU? I can think of other factors first:

- sloppy ports

- it was a more complex system to tame than most of those that preceded it

- the sprites were simply too limited, so you had to use the Blitter a lot

- unlike a lot of chips of the era, Denise had no tile or character generator so, again, you had to use the Blitter

- the CPU was clocked at 7.14MHz to align with the PAL/NTSC clock even if it could run at 8MHz

- if you used more than four bitplanes in low resolution, the Agnus chip would let Denise starve the CPU even on cycles where the latter would normally have access (if you set the right bit, the Blitter could be allowed to win, too)

I don't see how a different CPU would have helped with any of the above. In a time period during which memory wasn't typically the limit, the Amiga was one of the first systems where the CPU starved for it.

The X68000 was better, sure, but it came out later and, being in the same mold as the arcade systems of the era, it had dedicated video RAM, tiles and more powerful, actually useful sprites.

Frame rate? I don't see how any lack of framerate on Amiga was due to CPU because peripheral chips performed all the video and audio using DMA from dedicated graphics (CHIP) memory.

Again, what "responsiveness"? There doesn't seem to be any problem with that on Amiga other than what you say.

I think you remember wrong. Most of the games were ports from the Atari ST and seldom used the blitter, sprites or dual-playfield. When you have a 80's computer with pretty severe limitations you often design your game visuals around those limitations.

As for your statement on "many of the 8-bit machines", only the C64 had good 50/60fps shooters of the 8-bit home computers. The 8-bit consoles had better graphics hardware than the C64 and sometimes had the better games.

Properly implemented Amiga games were not that many though. It was hard to utilize the machine and it required good graphic artists to make it look fresh and sharp with the limitations of dual playfields.

But take a look at these games, I think they all run on a 512kb chipmem only OCS Amiga.

Mega Typhoon: https://www.youtube.com/watch?v=zk3LNdPTnMw

Agony: https://www.youtube.com/watch?v=a839o59Bt4s

Apidya: https://www.youtube.com/watch?v=QBJNbDidxcM

And of course the R-Type and Turrican series. Those were 12 or 25fps on the ST but silky smooth 50fps on the Amiga 500. Especially Mega Typhoon looks like a Raiden clone. It's very hectic, lots of bullets and big enemies and snake formations. The only thing that stands out is the lack of colors. I suspect this is because of using dual playfield and that limits the number of colors to 8+8+sprite colors.

I'm an old demo coder(C64 and Amiga) and was very picky about framerate back then. The only shootemups I liked that was not 50fps was Battle Squadron and Wings of Death.

And then you talk vaguely about responsiveness. Do you mean the number of cycles spent by the machinery to process and IRQ? I never saw that as a problem. On the Atari ST they use timer IRQ's to make rasterbars in demos and games. Seems to me they would not do that if the cost was too high.

The Amiga mouse-pointer was a sprite. I never saw a delay on that. It felt like a game character. At most 1 frame delay. And dragging Amiga "screens" up and down was usually only one frame after the sprite movement. But that's logical since the system copperlist has to be updated and that is definitely one frame delay on that.

> Yes, the death of 8-bit systems was obvious by 89, but so was the death of the 68000. Motorola was already pushing the failed 88000 by the late 80s. And the 68000 itself was killed off only a couple years later.

You may be overstating the death of the 68000... the 68060 was introduced in 1994, and I remember doing embedded work on 68000 based designs in 1999-2000. (In fact, some of the processors are still available, although not recommended for new designs.)

And even into the early 2000s, Palm and other handhelds had Freescale Dragonball processors inside, and that was based off of the 68000 core which was licensed from Motorola.

Sure, and ColdFire is still around to some degree. But Motorola/Freescale was not promoting this architecture for new desktop designs past the very early 90s. Yes, Apple and others continued to make machines until the mid-90s around 68k, but it was seen as dead in the water and the push was to get onto PowerPC (itself an unfortunate dead-end).

I still like the 68k. It has a very nice instruction set. It makes a great target for C compilers. I still enjoy writing assembler for it here and there. I like my Atari STs.

But for the market that Atari and Amiga were going for, I am still not convinced it was appropriate. I think Apple made the right choices with the IIgs. Except they underclocked it, overpriced it, and handicapped it in favour of promoting the Macintosh despite the II line being a big profit centre for them.

or this: http://mega65.org/

> The end of all the 8-bit systems was pretty obvious by '89

While it might not have been as easy to see /in/ '89 in hindsight the seeds for the rise (and crowding out of other architectures) of the Intel x86 chips were already well sown and growing rapidly by then:

i386: released Oct 1985 (https://en.wikipedia.org/wiki/Intel_80386)

i486: released April 1989 (https://en.wikipedia.org/wiki/Intel_80486)

We all knew where it was going back in the late 80's, there was no question about that, Motorola had a hard time getting traction where it matter, the PC.

I was programming the Acorn Archimedes with its 32 bit CPU in 1988. Took a while for everyone else to get on board tho.

There was a brief discussion on an Acorn forum semi-recently about "If there had been another BBC Micro, what would it have looked like?"

And the consensus was, probably it would have looked like the Acorn Archimedes. Acorn really got it right, and they got it right shockingly early.

The BBC successor was the Acorn Archimedes, really - the only thing it lacked was the branding. Fit the same educational niche, spoke Econet, it even ran BBC basic.

One of the first ones didn’t even lack the branding. The A3000 was a “BBC Micro”. Even had red function keys.

https://upload.wikimedia.org/wikipedia/commons/1/11/Acorn_A3...

Yes, I am aware of the Mega65.

Two different computer from 2 different visions...

My take on it, in a nutshell, is really to come up with a bridge in between the C128 and the Amiga500... With the design restriction of the time. At least as much as I can with the resources I have. I won't go about creating a new mold... Cheers!

Any tips getting into mechanical design ? I love designing PCBs, creating a schematic, then laying out the component and traces in the most elegant way is very satisfying. However when it comes to 3D stuff I wouldn't know where to begin.

Download Fusion 360 (probably the easiest of the serious programs and free for hobbyists), and start playing around, try making some enclosures for your PCBs copying features from existing objects around you.

However, I believe that restriction is the mother of creativity, so I’m trying to restrict myself to keep it limited to what would have been available back then.

I'm going to steal that phrasing.

"The more constraints one imposes, the more one frees one's self. And the arbitrariness of the constraint serves only to obtain precision of execution."

- Igor Stravinsky

"Solve the problem with what's in the room."—Edwin Land

Reminds me of Computer latency: 1977-2017 [1] as recently linked on HN. 1977 and 60 ms latency. The SGI Indy of 1993 also had 60 ms latency.

[1] https://danluu.com/input-lag/

That grey and fine font on a white background is pretty hostile to the older sets of eyes that might like this article.

I know this comes up a bit too often on HN but it's pretty, um, glaring, in this case.

Shouldn't it be beige?

Why? Many of Commodore’s later models weren’t.

I would hope it runs something other than BASIC. BASIC is a terrible language, and the only reason it became popular is that there was a book published with a lot of games written in that language. People buying a home computer wanted games, and the commercial game market was initially nonexistent, so people wanted a computer with BASIC, since then they assumed they could play those games. The designers of this new computer might want to restrict themselves to old hardware, but there is no reason for them to restrict themselves to that old accident of history.

Naïvely, I would assume that something like Forth or Occam would be much better for this, and both are also age-appropriate.

What's the best introduction to Forth or Occam for complete beginners to programming.

(I didn't downvote you, and I have upvoted your post.)

Starting FORTH was aimed at beginners. I wasn't one when I read it, so I couldn't really say. Certainly you wouldn't find a lot of games in Forth in the magazines.

BASIC is just a ROM. If I recall correctly, I had a LISP cartridge for my Acorn Electron. Except I didn't know LISP and there was no internet. We had a library though.

the c64 supported k&r c via the abacus c compiler.

I learned c on my c64, in fact. a skill I still use 32 years later.

you can download the manual courtesy of archive.org: https://archive.org/details/Super-C_1986_Abacus

I had that. I interned at NASA as a high schooler, got exposed to C, and suddenly found BASIC lacking. SO I tracked down Abacus C at, as I recall, a JC Penney electronics section.

It didn't support then entire K&R standard though. No function pointers.

no, I had to learn about function pointers through my work with MUDs, had a nice curiosity to go along with it, and an excitement when I figured out how powerful they were.

mine came from a small software store that was a bed store the last time I drove by.

BASIC is a terrible language, and the only reason it became popular is that there was a book published with a lot of games written in that language.

Not even close.

BASIC was a very powerful language. Not "powerful" in the way we think of languages today with OOP and all that, but powerful in its flexibility. Each machine had its own version of BASIC that made the most of each machine's unique capabilities.

Games were probably the minority of BASIC programs. BASIC was a serious language for serious business programs, especially in sales and accounting.

If your needs were scientific, you went with FORTRAN. If you were needs were hardcore business, you went with COBOL. If your needs were academic, there was Lisp and a bunch of others. But BASIC was the common language that almost every computer had available.

Huge companies managed inventory with BASIC. Transit timetables were calculated in BASIC. Machine control, non-mainframe astronomy, specialized journalism applications, record-keeping, and dozens of other needs were handled well by programs written in BASIC.

The first program I ever sold commercially was essentially a single-user Salesforce for the Commodore 64 tailored for limousine companies. I wrote it in BASIC.

If you think BASIC was only used for games, that's a reflection of your limited experience, not of the limitations of BASIC.

No, not every version of BASIC made the most of the underlying machine's capabilities. The BASIC on the C64 (the most popular 8-bit machine of all time) did not support graphics or sound.

Seriously, there was no support for what made the C64 the C64 in the C64 BASIC! You wanted grpahics? PEEK and POKE. Sound? PEEK and POKE.

You're right, there was no direct CIRCLE or BOX or other easy BASIC commands on the 64 unless you had a Simon's BASIC cart or something similar.

That said, I didn't have any trouble doing graphics on the 64 with PEEKS and POKES that was good enough to get one of my screens on the cover of Run Magazine. It wasn't easy, but once you got your brain around it, I remember it being pretty fun.

Sound, however... no argument there. But that could be because I've never been musical in any way whatsoever. Never understood notes and scales and such.

Basic was a fantastic choice for a computer back in the day, it was very straight forward for people that never used a computer before and pretty easy to fit into the ridiculous size constraints, most Basic interpreters had a few thousand bytes carved out for it, since many computers of the time had around 64 Kb in RAM and less in ROM.

I...don't think that's accurate. As far as I can tell, just about every significant 8-bit personal computer shipped with its own version of BASIC, starting with the Apple II in 1977. I really doubt that all of those were inspired by one book, especially since they used such different implementations that only the very simplest text-only programs could be ported without modification.

https://en.wikipedia.org/wiki/BASIC_Computer_Games

That's the book I learned to program from, a compilation of games in BASIC published in 1973. I don't know the truth of the GP's claim but reportedly that book was very influential so there might be something to it.

People forget that the B in BASIC stands for beginners, and for this purpose it's been tremendously successful. There's a real tension between the kind of languages that are preferred by users and those that are preferred by CS theorists.

Err no it wasn't because of a book! Its because most of the early machines had basic and normally the ones by Microsoft.

You might not know that is where Microsoft made its initial $

Most of the early machines had BASIC because of the book and the rising desire for BASIC. Also, the reason Microsoft made it initial money selling a BASIC interpreter for the ALTAIR is because people wanted BASIC, again mostly because of the book.

Almost all of the 8-bit micros came with some dialect of BASIC built-in. The only one that I know of that had Forth out of the box, was the Jupiter Ace.

Also, Occam?! That is a concurrent programming language... I'm not sure it would have done too well on the machines of the day.

> BASIC is a terrible language... I would assume that something like Forth or Occam would be much better for this, and both are also age-appropriate.

BASIC had a couple huge advantages in that it ran in minimal memory and had a reasonable infix syntax. The infix syntax was a particular advantage in educational scenarios where it matched (roughly) with the way math was taught. (Which was never in pre or postfix notation.)

The cross-platform nature of BASIC was also useful. If you knew one microcomputer, it made it more likely that you could sit down at another and get it to do useful things.

It's easy to second-guess, but even in hindsight I think BASIC was a reasonable choice for the time, goals, and hardware limitations.

Reply on news.ycombinator.com