18

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?

3

3 Answers 3

19

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.

4
  • True, the ROM tape loading routine was very slow. But it was common practice to use custom routines that were up to ten times as fast.
    – rwallace
    Nov 14, 2021 at 20:12
  • 1
    And my guess is that the ones that were 10 times as fast either were designed so that they could handle the video memory timing issues (i.e., if they were much faster then they couldn't) or they may have handled screen refresh differently when loading. I have extremely little hands-on experience with C64 so I can't speak from personal memory. (I did do quite a bit with Apple, but normally with disk not tape, and a little with TRS-80 and Atari. After high-school all disk.) Nov 14, 2021 at 20:18
  • 3
    In essence, standard tape bit timing is so slow the timing irregularity is not a problem, and fast loaders may turn off the screen to transfer faster with more deterministic timing.
    – Justme
    Nov 14, 2021 at 22:16
  • 2
    Glad you took up the challenge, and yes, it's really not a big issue - unless one wants to animate the picture shown as well, which would require a custom tape loader.
    – Raffzahn
    Nov 15, 2021 at 1:01
12

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.

10

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 :)

6
  • 1
    Little nitpick: Badlines can infact be switched off. There are a few ways to do this, for example disabling the display. Or, mucking about with YSCROLL. Of course, the latter incurs other costs that have to be accounted for. Nov 15, 2021 at 12:33
  • 1
    @OmarL Well, yes. Although, I wouldn't call that any normal operation mode. Point is that the (cassette) system was designed with bad lines on, like next to all software.
    – Raffzahn
    Nov 15, 2021 at 12:48
  • 1
    @Raffzahn: Third-party loaders and tape formats may have been designed for that, but the stock loading routines weren't, which is why they blank the screen.
    – supercat
    Nov 15, 2021 at 13:24
  • 2
    So, if the badlines aren't bad enough to cause any issue with tape loads, why was the C64 screen blanked by default during tape loads? Were the engineers being overly cautious?
    – Tim Locke
    Nov 15, 2021 at 13:59
  • 2
    @TimLocke exactly. Keep in mind, the C64 is a quick hack made in a few weeks from existing components (including software) to meet the CES deadline. And as usual with such projects, the fastest solution to any issue is selected - like as well lowering transfer speed for floppies. The C64 is the 8086 of home computers, a stop gap measure intended to bridge a limited time span to keep customers attached until the 'real' product will be ready.
    – Raffzahn
    Nov 15, 2021 at 14:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .