How did the Commodore 64 show a picture while reading cassette?

Question

I was watching this video just now https://www.youtube.com/watch?v=I0YmJluYb6Q&ab_channel=NostalgiaNerd on things that early home computers displayed on the screen while reading cassettes, and reminded of something. The loading bars are easy to explain, and so are the other contents on some machines, but I'm puzzled about the ability of the Commodore 64 to show pictures (or, really, anything but loading bars) while reading.

Why? Because one in every eight scan lines on that machine is a 'bad line' in which the video chip has so much data to read, that it needs to hog all the memory bandwidth, entirely locking out the CPU for about forty microseconds.

This doesn't have a big impact on performance (it only happens for the active portion of one every eight scan lines, after all), but I would expect it to make a hash of predictable timing, and I would expect reading tape, to absolutely depend on predictable timing.

How is this problem solved?

Answer 1

TL;DR Should not be a problem.

There are two separate issues:

predictable timing

Actually, I would expect that standard video memory access and similar things would have very predictable timing. I don't see that as an issue at all.

entirely locking out the CPU for about forty microseconds

That's the big one. But not so bad, really. 40 microseconds = 1/25,000 of a second. Clearly at 25,000 bits per second reading a tape would have an issue. As a rough guess you would want to miss less than 1/2 of a bit, ideally less than 1/4. That gets it down to roughly 6,000 bits per second.

According to https://en.wikipedia.org/wiki/Commodore_Datasette the tape speed was around 50 bytes per second - figure on the order of 500 bits per second. Another reference I found said 1200 baud. Baud and bits are not the same thing, but for this rough calculation I'll treat them the same. 1200 < 6,000, by a factor of 5.

Answer 2

There are a number of approaches that can be used when trying to measure the timing of incoming pulses from the datasette, but the most accurate is probably having an interrupt trigger on every incoming pulse, and having one of the timers set to free-run so it simply counts the same thing repeatedly. Although badlines introduce 43 cycles of uncertainty, it's possible to detect which pulses arrive during badlines. If one assumes that every pulse that arrives during a badline actually occurs 22 cycles earlier than measured, this will reduce the amount of badline-induced timing uncertainty for pulse widths from +/- 43 cycles to +/- 22.

An alternative approach would be to sample incoming data precisely once per scan line, but choose the data rate so that short pulses are about 1.7 scan lines and long pulses are 3.3 scan lines. If one sends each byte using nine pulses, one could use the first pulse to indicate that the other eight need to be inverted, the worst-case time to send a byte would be five short and four long pulses, i.e. 21.7 scan lines, or about 2.7 scan lines per useful bit. Depending upon the quality of tape, it may be possible to reduce the length of the short pulses, and depending upon motor speed stability it may be possible to reduce the length of the long ones.

Answer 3

TL;DR: VIC II DMA is always present and all existing loader routines take care of this (if needed) by default.

No need to reason with low level timing at all :))

---

As other answers already explained, the 'hiccup' caused by VIC II (*1) character (*2) fetch, is of such a short duration compared to the slow cassette data (similar for floppy *3) that it causes no issue at all.

These 'bad lines' are a basic part of the C64 timing. They are always present and can't be switched off (*4). Even an empty text screen has them. Thus, any effect thereof had to be incorporated into all loader routines.

Programs can load a title graphic first and then continue loading, all by using standard kernel functions without any need to care for display workings.

It gets a bit more challenging when graphics need to be animated, as then a custom loaders is needed. Still there's plenty room to do so. Sprite usage may add more complication as sprites do create additional DMA cycles. not many, but with multiple sprites on the same line it may need careful orchestration.

---

*1 - IIRC the VC20's VIC(I) did not need to do any DMA during CPU access, simply because it needs less data for a line.

*2 - Or colour in graphic modes.

*3 - IIRC they are the reason why the 1541 has a slightly slower communication rate than the VIC20's 1540.

*4 - Well, as OmarL mentions, there are of course ways to have them (seemingly) switched off, like tricks have been found to do quite interesting effects, not planned when the system was designed. They come with severe limitations and work, ofc, only with disabling normal operation first :)