I love the enthusiasm of my contemporaries that were the founding fathers of todays electronics. ... too bad I took a detour to nowhere...

Agreed. And these guys, who created the chips which sucked us into the field always seem to be so humble. I think that's a side-effect of knowing how things work at such a basic level and assuming everyone else does. Albert's creations are one of the biggest reasons I was so enamored with computers at that early age - he deserves all the kudos he gets.

...and it is a machine that you can completely know inside and out, and for me, at the time I had my C128(it spent most of it's time in C64 mode) I knew very little about the hardware.

After watching it from the start, at 27minutes Albert explains a lot better what I just trying to say above.

Besides the disk and tape bugs, yes.

I also still think it a marvel what could be done on a 1 MHz CPU and a decent graphic system. Have a friend that made a "live" sprite editor that had: - An editor at the top using 8 sprite - A line of the sprites in the animation that was edited - A display on the lower 3rd of the screen showing 8 of the current animation in memory that could be grouped and set to move as one unit. Programmed using the cartridge "Edna" assembler. Just a fantastic example on what a Commodore 64 could do.

@@IntenseGrid I still have 2 128D machines, and still write code for those.. lots of fun to do.

Exactly. That really unlocks the gems from the interviewees…

What do you mean by yield?

​@@SheikhN-bible-syndrome the number of usable chips for a given amount of raw material. Usually in this case it's the number of usable chips from a wafer. A wafer might have space for 100/200/300 chips depending on the size of the chip and wafer, but a low yield might mean only a few 10s of chips out of the 100s planned are usable. Such a low yield would be inefficient and costly.

@Chip Belori I mostly wrote code in assembly language. I think the Motorola processors were easier to code for. That includes the 68000 series. I don't know how they were to design hardware around. My first home computer build was a SWTPC 6800.

Just curious, why did they shut the plant down every summer? Was it required for maintenance? Based on the yield issues you describe from restarting production it just seems to be ignoring something fundamental to the ongoing success of the business. I know hindsight is 20/20 but with business decisions like that it begins to put in perspective why Motorola just evaporated.

@@jimfrench2001 I don't have an answer. It didn't seem to be a problem with older products. In the 1960s, I worked for NCR in Dayton and they also closed the manufacturing plant for a couple of weeks in the summer. I remember that many of the factory workers drove to work with their vehicles packed for a vacation. At quitting time they would dash to their cars to leave. It seemed to be common in manufacturing. With staggered vacations, they couldn't rely on have a full workforce all the time.

Seems that time goldens memories… The C64 did not have a db25 port. And the user port registers were published, but the I/O couldn’t sink/source much current - driving LEDs was a stretch.

@@alfa-psi It would be a real loss to lose those loose minds.

Let LLL LLL LLL LL l

@@brad9529 brilliant

Is that "loose them" as in set them loose? Or to tighten them?

Sadly it will, like all things, when the people that grew up with it do. But that era has yet to pass, so let's make the most of it while it lasts!

@@neogen23 It is told in the interview that quite some young people get into the C64 because it is probably the most advanced computer that can still be understood in all parts to the ground level.

As a current computer science student, I'm somewhat envious of people like yourself. You got to experience a time before complexity got too big for a single mind to understand wholely!

The difference is back then we had a select few resources, what manuals we could find, schematics and talking to others. We had to just figure things out, manually, on our own and without the Internet. Yes, that’s harder.

Yes! Everyone learning and inventing. Magazines in the grocery store would cover topics like scrolling, drawing lines, bitmap drawing, optimizations. People would write code, share with others sometimes, often not due to people being spread out. Getting something to work was amazing! Coming from the Apple 2, things like sprites, the Atari player missile system were powerful! And the hardware colored the games and applications. Sprite systems tended to work with the hardware, and or bugs in it that got turned into features, as much as possible. Bitmap games, like on the Apple, or when C64 and Atari sprites were ignored, like for a port of a game, tended to have crazy optimizations. Self modifying code, things like writes hard coded to screen addresses, unrolled loops, drawing only differences and more were used to push pixels and make things move where a Sprite can do the same by updating a pointer! The Atari sprites were long strips, a byte wide, with an X pointer. Moving an object in the Y direction, vertical, meant moving all the bytes for it. Like scrolling. C64 sprites could move freely. Too great! And as cool as the video chips were, one has to give Woz credit for hacking color in to get 6 colors on the graphics screen, but with crazy addressing, 7 pixels per byte and artifact colors. It really was a beautiful era! Everything was news and new at the same time. Today, people can experience it with microcontrollers or by getting old gear, like my Apple //e I like to program, or a MISTer FPGA running a hardware emulation. And people do! Great new software continues to be done and released. Too cool.

What no PET?

Ben’s bread board projects are amazing. My favourites are the worlds worst graphics card and implementing ‘Hello World’ in hardware by building a 6502 based computer from scratch

Correct. Two more things: the 8 scan lines thingy is commonly refered to "Bad line" (and you can actually trick the VIC to genereate a Bad line at every scan line which enables you to redefine colors every single scan line. The "attribute data" in bitmap data is actually "color data" :)...

IIRC, unlike the Amiga, the C64 is all or nothing when it comes to stealing processor cycles for Sprite fetches. That is, if one C64 Sprite is on, then data is fetched for all 8 Sprites, even if only one is on.

@@saganandroid4175 no not really, but it is somewhat complex. The issue is it taking a few cycles for the cpu to stop, so you can't have vic2 steal a cycle, give the following cycle to the cpu, and steal the next cycle again. There always will be a few cycles inbetween. The way in which the cpu gets 'stunned' is somewhat more complex than one might expect, because a 6502, and by extension a 6510 cannot be stopped in the middle of an instruction, you have to let it finish that instruction (tho the last cycle of that can overlap with the cpu getting tristated) To allow fetching multiple sprites using the remaining cycles outside the visible screen area, vic2 will start 'stunning' the cpu a few cycles before the first sprite data it actually has to read, and keep it stunned until it is done with the last one. But that is based on what sprite data it actually needs to read, based on which sprites are enabled, and also means that you can have it fetch data for one sprite only. It doesn't always fetch all bytes for all sprites.

I just did some practical timings, and it turns out that with the screen blanked and the 1540 (or the 1541 in "fast" VIC-20 mode), the C64 loads nearly 17% faster, so you're right about the speed difference. And with the original routines that have lower overhead, the VIC-20 and 1540 loads about 20% faster. That's not great considering that the "bad lines" only slow down the C64's CPU by about 6%. But what's really sad was that both the VIC-20 and C64 were supposed to have fast serial "burst" transfer just like the C128 and 1571 combination. Commodore actually screwed up *twice* to give them both slow disk data transfer rates. 😵‍💫 With the VIC-20, the problem was a previously unknown bug in the hardware bit-shifter in the 6522 VIA that forced the design team to fall back to a slow but reliable CPU-driven serial protocol. The C64 got the 6526 CIA instead and the 1541 was supposed to have at least one of those, as well, so everything was all set for fast disk data transfer, but then some idiot manufacturing engineer had to make room for a new mounting hole, so he deleted a line or two because it was easier to do that than reroute the lines! For some reason, he thought that they were unused, and did not ask the designers before taking the liberty of removing the traces completely (might have had an outdated version of the Kernal ROM), which broke the fast serial transfer mode. Unfortunately, hundreds of thousands of C64 mainboards were manufactured before anyone knew there was a problem (probably sent the production samples to the designers for approval just before making this last-minute change), making the problem expensive to fix by hand, and management wasn't interested anyway because they considered the 1541 a waste of time to begin with (they thought that everyone would be using Datasettes instead, like with the VIC-20). So the 1541 got the 6522 instead (slightly cheaper and everyone used it, so they had tons on hand), and the C64 got super-slow disk transfer. Oh well, that's "water under the bridge", and in return we got all kinds of interesting solutions to this issue, the vast majority of which were software-only and many times faster, proving that the C64 didn't and doesn't really need to have slow disk data transfer rates, even with the broken stock hardware.

@@Lofote You are correct that the attribute data that is read during bad lines in the bitmap modes are exclusively color data or maps (two colors per byte), but concerning color maps in general, the main color map at $D800 (stored in an SRAM chip on the board rather than the main DRAM) also contains an attribute bit while in multicolor character mode. This bit determines whether the corresponding character cell is in hi-res or multicolor mode, leaving only 3 bits for the color, which limits the main foreground color to the first 8 of the palette. It is for this reason that I, for one, often refer to the color maps as attribute maps. Sometimes they do contain only color data, but color is itself an attribute, so this term is still appropriate, and other times they contain other attribute data in addition to color. Furthermore, multicolor character mode is perhaps the most common mode that is used overall, especially for games, of course, so this exception to the rule is a pretty major one that programmers have to deal with on a regular basis.

Midi getting my keyboard and tracks together in 1992 was simply way ahead of it's time. Geez it was challenging and fun. 16 track 32 bit sounds ( I believe) classic infinite waveform generation with 3 waveform generators. What a pushbutton classic. I still navigate those press buttons like it's 1992

Same here! ❤❤

Great idea Christian! Yes please... Bob Yannes next 😀

Yes please! Ensoniq architects

@Christopher Jackson This approach was used all over the place. It was fascilitated by ram at the time being easily twice as fast as the cpu. For example the older IEEE-488 floppy drives from Commodore have 2 6502 CPUs, which share ram in exactly the same way, one having half a cycle offset to make it run on 'the other phase'.

@@alfa-psi Did you actually listen to the interview?

@@alfa-psi In a C64 ram is shared between the VIC2 chip and the CPU.

@@c128stuff Not really. Affordable MOS RAM was generally slower than most processors could be clocked around 1975-85 (expensive bipolar RAM was faster though). Moreover, the 6800 and 6502 didn't use the RAM access time efficiently either, allowing only a third of cycle for memory to respond. That's why the Apple II, VIC-20/64 and others used this slow 1 MHz clock speed, in order to be cheap enough for the masses. Memory was a large part of the cost. It's true that many computers (using all sorts of processors) had a shared main- and graphics memory. But this particularly simple method with the display circuitry using one half cycle and the CPU the other half could be used with the 6800/09 or 6502/10 simply because they used only one of the two halves when accessing memory. Processors like the Z80, 8086, 68000 and others had more uneven or "unpredictable" accesses, that needed more complex circuitry regarding the video interface.

@@herrbonk3635 Not when talking 6502 and similar CPUs.

Of course Apple would not release a desktop multitasking OS until 2001, which was really a unix variant with a Mac emulator slapped on it.

Dave was an Amiga user and developer? Before he went to work for MS, on the MSDOS and Win95 dev teams?

@@RetroDawn Yes, he made HyperCache for the Amiga, which was a fantastic cacher that I actually still use on my Amiga 3000 today.

Commodore's zenith was as the world market leader with the C64. They should have developed the C64 into a compatible 16-bit machine - that could have been an IBM PC (clone) and Mac killer. A compatible 16-bit CPU by WDC had been around since 1983.

Thanks! I have to be careful about that, so glad you noticed I didn't fail badly :-)