The hardware design was finalised and sent off to be built. David Callan picks up the story: "A minor rework of the board at the board manufacturers (to accommodate a screw hole, I believe) accidentally discarded the high-speed wire." 52/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Cutting through the fast-serial-bus line doomed the C64 to the same slow data transfer speeds as the VIC-20: around 1kB per second. The boards were already designed around the 6526's layout, but they would be left in VIC-20 compatibility mode. 53/
=> More informations about this toot | More toots from Two9A@hachyderm.io
But we don't see the 1kB/s achieved by the VIC-20 when measuring the disk loading speed on a real C64: we actually get less than half that. So what's going on to make the C64 slower? Now bear with me, we're going to get technical. (Yep, we haven't been technical thus far.) 54/
=> More informations about this toot | More toots from Two9A@hachyderm.io
We're going to take a little bit of a detour from talking about disk drives and interface adapters, and look at the history of television real quick. Stay with me, we'll get back on track very shortly. If you're already familiar with TV signals, come back in fifteen posts or so. 55/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The first TV broadcast systems took a two-dimensional picture that varied with time, and crammed that information into a one-dimensional radio signal: kinda like a sound wave, all you had was a volume (or amplitude) that went up and down with time. 56/
=> More informations about this toot | More toots from Two9A@hachyderm.io
So how do you turn 2D frames of video into 1D? By breaking them up into lines, and sending the lines one after another. If you used enough lines, you could send a full picture without things looking janky; if you then sent a frame very quickly after the first, you had the illusion of motion. 57/
=> More informations about this toot | More toots from Two9A@hachyderm.io
In the US, things eventually coalesced around a 525-line standard, but if you wanted to send 525 lines of picture at 60 frames per second there wasn't a way to fit that much signal into the allocated radio bands. The ingenious solution was to send half the picture at a time. 58/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The transmitter actually takes 60 frames of video per second, but it sends every other line from one frame and the lines it missed from the next frame; at the receiving end, the eye and brain blur things together and it looks like the whole frame is moving at full speed. 59/
=> More informations about this toot | More toots from Two9A@hachyderm.io
So let's have a quick look at one of these lines, as it comes in from the VHF antenna. If we want to show bands fading between white and black across the screen, that's represented by a signal that starts high (for white) and drops to low (for black), then back up. 60/
=> View attached media | View attached media
=> More informations about this toot | More toots from Two9A@hachyderm.io
But what's this "Horizontal Blanking Period" that shows up after the picture data? To understand why that appears, we need to look at the television technology of the time: the cathode ray tube. 61/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The CRT is actually a 19th-century invention: the story starts with Julius Plücker playing around with sealed glass tubes containing various gases. By putting a wire at each end, Plücker found he could get a current to run through the tube, and some gases would glow under current. 62/
=> More informations about this toot | More toots from Two9A@hachyderm.io
(As an aside, the Plücker tube is nowadays called the Geissler tube, and types of Geissler tube include neon signs and the sodium lamps you find in streetlights.) 63/
=> More informations about this toot | More toots from Two9A@hachyderm.io
In 1859, Plücker noticed that the wall of the tube was itself glowing near the cathode end of the electric flow, and he could get the glow to move around by applying an electromagnet to the outside. There was something about the cathode that was causing the glass to phosphoresce... 64/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Cathodoluminescence, as it came to be known, was neatly explained by Einstein as a side-effect of his exploration of the photoelectric effect in 1905. If we take the photoelectric effect first, that occurs when light falls on a surface of a particular material, ejecting electrons. 65/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The opposite of this is when electrons are fired at a substance and it starts to emit light. A mix of zinc cadmium sulfide and zinc silver sulfide will output white light when struck by electrons, and it's this mix that coats the inside of a monochrome display CRT. 66/
=> More informations about this toot | More toots from Two9A@hachyderm.io
By combining cathodoluminescence and Plücker's insight that the cathode ray can be deflected with magnets, we can program a CRT to scan across the screen and produce a picture: white areas are activated with more power from the cathode, black areas with less power. 67/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The beam can be deflected from left to right by applying more magnetic field strength to one side or the other, gradually fading from one magnetic coil to the other. But what happens when we reach the right edge, and want to come back to the left? 68/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Magnetically it's simple: drop the power on the right deflection coil to nothing, and turn the left to full. But the beam doesn't simply blink out of existence and reappear on the left: it takes time for the magnetic field to dissipate. 69/
=> More informations about this toot | More toots from Two9A@hachyderm.io
And that's why television signals have a blanking period: to provide time for the magnets in the CRT to flip polarity and bring the beam across to the left for the next scan. As well as horizontal blanking, there's a vertical blanking period to allow for travel back to the top for the next run. 70/
=> More informations about this toot | More toots from Two9A@hachyderm.io
So why do we care about the architecture of TV signals when we're dealing with computers? Because they have to have somewhere to output their video, and it makes sense for computers destined for the home to output onto the TVs that people already had in their homes. 71/
=> More informations about this toot | More toots from Two9A@hachyderm.io
We've looked at how video comes out of the computer onto a TV, let's have a look at what is displayed. On the VIC-20, the default video mode is tiled, or character mode: 23 rows of 22 characters, with each character being 8x8 pixels, for a resolution of 176x184. 72/
=> More informations about this toot | More toots from Two9A@hachyderm.io
To get a character rendered on the screen, the VIC chip needs data from three places: which character to show, its colour, and information about its shape. Each of these uses a region of memory on the VIC-20: screen RAM, colour RAM, and the built-in character generator ROM. 73/
=> More informations about this toot | More toots from Two9A@hachyderm.io
You'll recall from earlier that we talked about how the VIC-20 interleaves its CPU and video clocks, allowing the video chip to access memory at the same time as the CPU. At 22 characters across, it takes 44 cycles of the clock to pull in what the VIC needs to draw a given line. 74/
=> More informations about this toot | More toots from Two9A@hachyderm.io
"But wait", I hear perhaps a few of you cry. If we need three pieces of data to render a character, that should be 66 cycles of memory access; what magic allows each character to be rendered in two memory reads instead of three? Once again, we turn to the magicians at MOS. 75/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The VIC has 16 colours: every unique combination can be expressed in four bits. Colour RAM on the VIC-20 isn't the normal eight-bit memory of the rest of the machine, it's four-bit RAM, and the VIC chip itself has a combined 12-bit data bus to read from both types of memory at once. 76/
=> More informations about this toot | More toots from Two9A@hachyderm.io
And finally, we cycle back around to the disk drive. With this interleaving of memory access in the VIC-20, the CPU does its best impression of a shift register, and the VIC has 65 cycles (including the horizontal blanking period) to do 44 memory reads; positively relaxed. 77/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The C64 is a different story. We're still in 16 colours, but tiled character mode now yields a screen of 40 characters by 25 rows, for an effective resolution of 320x200; the VIC-II chip would need 80 cycles to get all its data read in, and it only has 65 cycles to play with. 78/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Yet again we call on the wizards at MOS for an ingenious solution, and this one was a doozy. They noticed that it takes around 500μs to draw eight lines (one row of characters) on the screen, and generally users weren't changing the characters in RAM in that short span of time. 79/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The original VIC would read a character number from screen RAM, then head into the character generator ROM to find the line of that character it needed to draw; on the next line, it would do the same steps, but the character number would very likely be the same. 80/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Wouldn't it be neat if we could cache screen RAM somewhere (inside the VIC-II, say) every eight lines, and read from there instead of heading out to memory so many extra times? You could even apply the same logic to colour RAM, since it was read at the same time on that 12-bit bus. 81/
=> More informations about this toot | More toots from Two9A@hachyderm.io
So that's what they did: build a 12-bit cache for the screen and colour RAM values onto the VIC-II silicon, and push everything else around to compensate. The video chip uses this cached copy of the screen to index the character generator ROM and work out which shapes to draw. 82/
=> More informations about this toot | More toots from Two9A@hachyderm.io
There's just one problem. This works great for seven out of eight lines where we already have the screen/colour data cached, but the first line of each row of characters invalidates the cache, and we need to fetch from all three places. We're back to having 65 cycles to do 80 cycles' work. 83/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Fortunately, this problem was found before the hardware was finalised, so there was time for a hack: every eight lines, the VIC signals to the CPU that it's taking over the memory bus, and the CPU isn't allowed to do any work for 40 cycles. 84/
=> More informations about this toot | More toots from Two9A@hachyderm.io
By building an Address Enable Control line into both the VIC and the 6510 CPU, the VIC can steal access to memory by pulling the line from its default state of full voltage down to zero; when this happens, the 6510 puts its memory bus into high-impedance mode, which blocks any usage by the CPU. 85/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Of course, this includes the serial bus's data line, so the CPU is locked out from camping on the serial bus 12.5% of the time during normal computer operation. This is often referred to as a "badline" condition, because the one in eight lines where this happens are the bad lines. 86/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Let's detour real quick into what it means to camp on the data line: what is the CPU actually doing when it spins its wheels waiting for data to come in? To find out, we need to dig into the operating system that was burned into the VIC-20's ROM chips. 87/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Many people have done excellent work disassembling and annotating the VIC-20 ROM, and a complete set has been compiled by Lee Davison; the file is hosted by Matt Dawson here: https://www.mdawson.net/vic20chrome/vic20/docs/kernel_disassembly.txt 88/
=> More informations about this toot | More toots from Two9A@hachyderm.io
If we count up the time taken by the instructions in the relevant section of this disassembly, we find it takes at least 19μs to read in a single bit from the serial bus; with the surrounding code, it can be more like 500μs to read a full byte, before the rest of the OS even sees it. 89/
=> More informations about this toot | More toots from Two9A@hachyderm.io
If we take this same code and run it on the C64, it's going to miss bits: if it runs through every 19 cycles, but the CPU is occasionally locked out for 40 cycles, you can miss two or even sometimes three bits of data. 90/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Luckily, the serial bus is robust enough to handle this: it will hold a value on the data line until it's told by the other end that the value has been saved. If the CPU is locked out, the data stays there until it comes back from its short coma. 91/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The final solution that Commodore landed on was to delay the C64 end of the serial bus so it sent a bit every 60μs, to be sure it wasn't catching a badline in its own CPU, and to leverage the serial bus's acknowledgement mechanism for any delays in reading data. 92/
=> More informations about this toot | More toots from Two9A@hachyderm.io
And there we have it: with the change from 19μs/bit to 60μs, we find the effective speed of the C64 and its disk drive comes out to 400 bytes per second. That leaves us with only a couple of questions... 93/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Did this affect sales of the C64? Eh, not really. Being heavily advertised to the home market as a successor to the VIC-20, users were willing to wait a little while for their games to load, and even 400 bytes per second was better than the interminable wait for tapes to load. 94/
=> More informations about this toot | More toots from Two9A@hachyderm.io
And whatever happened to Commodore? Well, Jack Tramiel stepped down after the success of the C64, and he was very much in the mould of Steve Jobs: a driver of high concept. Without Tramiel, Commodore started to pull in multiple directions at once... 95/
=> More informations about this toot | More toots from Two9A@hachyderm.io
The Plus-4 and 264 home machines with low prices and low specs to match performed badly; a new series of PET-derived 8-bit business computers didn't sell as the IBM PC and its clones started eating the business market; Tramiel went on to head Atari and release the ST line of 16-bits. 96/
=> More informations about this toot | More toots from Two9A@hachyderm.io
Commodore's last gasp effort was to buy Amiga and develop their prototype 16-bit machine into the Amiga 1000, but even that faltered as Commodore demanded it be treated as a Serious Business Machine; it took until 1987 before the A500 was sold as a 16-bit home machine, and profits returned. 97/
=> More informations about this toot | More toots from Two9A@hachyderm.io
But profits didn't rebound by enough for Irving Gould, main investor in Commodore, to be happy; he fired the CEO, laid off half the staff, and directed work back to 8-bit machines. Only one of these ever saw the light of day: a 1991 rework of the C64 in a slimline Amiga-style case. 98/
=> More informations about this toot | More toots from Two9A@hachyderm.io
And then a patent troll sued over the use of mouse cursors in the Amiga, and incredibly, Commodore lost. That was 1993, they refused to pay up, and were banned from selling in the US; Commodore shut their doors in April of 1994, but the C64's sales record stands to this day. 99/
=> More informations about this toot | More toots from Two9A@hachyderm.io
If anyone ever asks you "Why was the #C64 disk drive so slow?", now you'll have an answer. A full list of sources for this tale is in the alt text; do drop me a note if you have any questions about the (even) finer technical details. Merry Christmas. 100/100
=> More informations about this toot | More toots from Two9A@hachyderm.io
(Postscript: I bought a copy of the C64 Programmer's Reference at a yard sale when I was 12, and called the number on the back from a payphone. I was told that the number didn't go to Commodore any more, and that's how I learned they were no longer a going concern. Devastated.) 101/100
=> More informations about this toot | More toots from Two9A@hachyderm.io This content has been proxied by September (ba2dc).Proxy Information
text/gemini