A Minimal C64 Datasette Program Loader | Hacker News Reader

A Minimal C64 Datasette Program Loader

pagetable.com

77 pointsingve29 comments

I once put an audio cassette of The Cure into my Datasette.

Then, I made a short assembly routine to copy that datasette output while playing to the SID. (I think I used the volume register?). it made a very badly sampled sounding version :) was fun :)

The Commodore Datasette was much more reliable than any of the other systems out there. The one on the Spectrum, Apple and Atari (all std. decks) pretty much gave you load issue 20% of the time. You had to mess with the volume level, etc. My Commodore one just worked.

Most cheap cassette recorders didn't have a gain control back then. I found my Atom (precursor to BBC B) worked well when I got a more expensive deck about £50-60 back in 1980.

I wonder how the Kernal writers decided on the two-pulse-per-bit scheme. They must have been targetting some awful hardware (or low quality tape media, I suppose)

The fastloaders that came after all worked fine using one pulse per bit.

And modern alternatives (for example c2t, which is for Apple II) can achieve even much higher data rates. I prototyped an encoding that packs 4 bits per pulse, achieving 23kbps but not reliably. One difference, though, is that this is designed for output from a modern digital sound interface, not designed to withstand degradation from analog tape recorders.

https://groups.google.com/forum/#!topic/comp.sys.apple2/qXZy...

I read the source code, and here are 2 improvements:

1) in get_block, we can replace "dec count" with "cpy count" It should save one or 2 cycles, if I'm not mistaken

2) get_countdown can be rewritten as follows:

        ldy #$89
 c4:
        cpy #$89
        bne c1
 c0:
        jsr get_byte
 c1:
        ldy #$89
        bne c2
 cx:
        jsr get_byte
 c2:
        sty tmp_cntdwn
        cmp tmp_cntdwn
        bne c4
        dey
        cpy #$80
        bne cx
        rts

which saves probably 4 bytes

> 1) in get_block, we can replace "dec count" with "cpy count" It should save one or 2 cycles, if I'm not mistaken

It would, but wouldn't it also set the carry flag? Thus the routine would always return with carry flag set.

It would, but the routine already modifies the carry flag, so no problem.

It won’t work because the carry flag signals end of file. This will cause an infinite loop.

Check the full source on GitHub.

(oops, now that I'm looking at the code again: it would not go into an infinite loop, but cut off after loading 1 block.)

You are completely right, I missed this carry. Thanks !

This is why I love and cherish HN. :)

Regarding 1) could you offset ptr backwards and y forward, so that last iny makes zero?

“The Commodore Datasette recording format is heavily optimized for data safety and can compensate for many typical issues of cassette tape, ”

I used the tape for a few days when I got my C64. It didn’t take more than a week before I realized that it was too slow and unreliable and talked my mom into getting the 1540 drive.

This is really funny because that drive was so incredibly slow, and especially the 1540 was unreliable. A tape with fastloader would approximate the speed of the stock drive...

Still, I did the same thing!

Well we eventually got the fast-loading cartridges which turned the 1541 into a speed beast.

Floppy disks where also much more convenient to handle. If you had more than one program on your cassette you had to wind the cassette to the right spot manually. This was not to unusual, a typical 60 minutes cassette could hold about 100 KiB per side, enough room for two or three simple games.

There were fastloaders for the 1540 too that boosted them 5-20x.

https://www.c64-wiki.com/wiki/Fast_loader

Fun fact: one of the popular fast loaders for the 1541, called "Hypra Load", was co-written by an 18-year old guy who later became one of Germany's game magazine pioneers, was the translator of LucasArt's adventure games to German, only to shift jobs once again in the 1990's when he became the product manager responsible the full Xbox product catalog at Microsoft.

The interface chip they were working with had a bug on a hardware shift register and the designer were not able to switch because management wanted it to be compatible with the VIC 20. So they implemented a software solution which was 5x slower that with hardware.

+1. Interested readers should check out the very good book "Commodore: A Company on the Edge" by Brian Bagnall for this and other fascinating stories from how the PET, VIC-20, and C64 came to be. (And parallels to Internet-age companies are a fun exercise for the reader)

My C64 shipped with a fastloader disk. You had to load and run the fastloader every time you restarted the computer, mind, but at least it was smaller than most of the programs you wanted to fastload.

All the CBM drives had their foibles there was knack to getting the 2020,3030 4040 to work reliably.

I had a Datasette. It was expensive at the time, and it was amazing that it worked at all. You could put one of the C64 tapes into your boom box and play them, and hear a series of unpleasant screeches and whoops.

>I had a Datasette. It was expensive at the time, and it was amazing that it worked at all.

It was expensive in the beginning, but later on it was cheap, at least in comparison to the 1541 floppy disk drive which was in the same price region as the C64 itself.

If you look at the hardware this is not surprising. The Datasette was basically a slightly modified cassette player. The Atari "Datasette" (410 Program Recorder) even looked like the typical portable cassette player of the time and could be used like one. It could play audio cassettes through an internal speaker. The 1541 and the 1541 II on the other hand were little 8-bit computers in their own right. They contained a 6502 (almost the same CPU as the C64) and there was software to use the floppy CPU as a co-processor.

>You could put one of the C64 tapes into your boom box and play them, and hear a series of unpleasant screeches and whoops.

You could not only play them, you could conveniently copy them with your boom box. This was the way software was pirated back then. A dual deck boom box with high speed dubbing - much faster than copying with the computer.

In the Netherlands there were also experiments where software was sent on FM radio. You recorded it on a audio cassette which you could then use in your Datasette.

While most people used regular 60 minutes audio cassettes for software there existed special 7 minute cassettes for some time. This saved you from a lot of winding and rewinding when you missed the program start.

Good times, good times...

I’m curious, who wrote software to use the 1541 cpu as a coprocessor? I did, as a science fair project, but I wasn’t aware of anyone else doing it.

In case anyone is curious about those radio experiments, OP is talking about Basicode:

https://en.wikipedia.org/wiki/BASICODE?wprov=sfla1

They also invented a kind of internal DSL within BASIC to get around inconsistencies in various BASIC dialects used by different platforms at the time.

That is amazing. Different manufacturers' dialects of basic were barely the same language. I think the only things generally held in common were basic logic and control flow, very basic string manipulation, printing characters line-by-line, and prompting the user to enter a string. It sounds like these guys essentially created a shared function library (libraries and functions were completely alien to BASIC!) and successful ported that library to a couple of dozen different computers, some of them with only 16KB of RAM.

(Technically functions were supported in some dialects at least, but they had to fit on one line and could only do mathematical operations, so they would be useless here.)

So a great video on some of the HW emulation projects around this (datasette for 80s 8-bits) from the Nostalgia Nerd.

https://youtu.be/DoMxl_RqQlQ

Pretty cool stuff.

Reply on news.ycombinator.com