Sunday 31 December 2023

25 year old DIY valve amp revisit

On the top shelf of my workshop for probably the last 20 years has been a little black box with a couple of valves on the top.

You might think it is the original valve based version of The Internet, but it isn't. 

You might think this is one of many old projects gathering dust. And indeed it is, but there is a difference. You might just be able to see there is a warm glow coming from the tubes.

That is because this is in use, and has been in use pretty much daily all the time it has been there.

I built this 20-25 years ago. I can't remember when specifically, before the blog, before Tynemouth Software even. I didn't have a digital camera at that point, and there is no email trail for the parts as it was well before I got my gmail account (2007?).

I did think I might get a result from some of the valves I bought from Rapid Electronics (yes, they used to sell valves!) but my order history does not go back that far either.

I can't find my notebooks from back then. I am pretty certain I know where they are, just there are rather a lot of things between me and them.

So I thought it might be interesting to reverse engineer it. See how bad it is, and if there is anything I would do differently today.

Step 1 was to clean it up a bit.

You might notice it is resting on a bit of cardboard, that is because the feet have dissolved. There seem to be a problem with rubberised plastic from that era, things that had that sort of coating break down and go sticky over time (e.g. the old sky remote controls)

With that cleaned up a bit, and some new plastic feet fitted, it looks a lot better.

It is a very minimal design. A power switch on the left and a volume control on the right. With a good old chicken head knob like every valve amp should have.

The back has a fixed mains lead, two phono jacks for the input and four 4mm jacks for the speaker outputs (somewhat faded in a quarter of a century of sunlight).

I managed to round one of the screws that was quite persistently stuck, so I had to drill that out.(well, first I had to find my drill, that I had conveniently ran flat last time I had used it, then find the charger for it, then wait for it to charge......)

That's better, all six screws removed.

One of these things is not like the others.

Time to open it up.

But first, a couple of things.

Main voltages and higher are present in here. They can be lethal. If you ever do anything like this, be sensible, take the usual precautions etc.

Secondly, the design is wrong. I know that. I knew that at the time. The transformers and wrong, the valves are wrong. I could have built one with the right parts (and indeed I did start that), but they are very expensive, and not easily available. So, I thought I would see what I could do with parts that were not ideal, but were cheap and easily available. (I am sure that will not stop people on the internet telling me that it is wrong in even more ways that I realise).

OK, those of a nervous disposition, look away now.

OK, there is a lot going on there. Let me reverse engineer my own 25 year old design.

One moment please.

Let's look at that in more detail.

Power Supply

I'll start with the power. This is the first bodge. A proper valve amp would have a proper power transformer with a high voltage winding for the B+ and a low voltage winding for the tube filaments.

I didn't have that, so I improvised with two normal mains transformers.

The mains comes in via a toggle switch and goes to the primary of the first transformer. This has two 15V secondaries.

B+ High Voltage Supply

The first of these is wired to the secondary of a second transformer. This is two 6V windings in series to give a 12V winding. The primary of that becomes the output, one of the 120V is used.

I have redrawn that in simplified form.

The first transformer is designed for 240V to 15V, so a 16:1 windings ratio. The second is designed as 240V to 12V, so 20:1, but in reverse, so 1:20, and only one of the output windings is used, so 1:10.

When arranged like this, you get a single transformer with a windings ration of 16:10, or 8:5.

So with 240V in, there should be approximately 150V AC output. This is not very efficient, but it does give a high voltage, low current supply, and more importantly, isolation from the mains.

(N.B. I am using a nominal 240V here as these transformers are marked as having dual 120V primaries and it makes the maths neater. The UK mains voltage is more like 230V these days, so the output would be 143.75V not 150V)

The high voltage is rectified with a little bridge rectifier module and smoothed with a 47µF capacitor. It is further filtered with a 100Ω resistor and a 100µF capacitor. In circuit, that gives a measured B+ of around 200V in use. (143.75 * √2 is 203.29, so I am happy that the maths seems to work out, given the tolerances of the transformers and the losses in the inefficient design).

I have redrawn that section using this simplified view of the transformer.

In value amps you often see a series of these R/C filters added, with voltages tapped at each stage to feed different parts of the circuit. I thought I would have taken the output transformer feeds from the first capacitor and the triodes from the second, but it appears I have taken all the supplies from the second one. Not sure why. I am sure I prototyped all of this with crocodile clip leads and would have moved things around until I was happy.

It seems the last thing I was testing out were some EM80 "magic eye" type values for a VU meter project that never happened. But that is the sort of crocodile clip lead spaghetti that would have been involved.

Heater Filament Supply

The second 15V secondary on the mains transformer goes to a second bridge rectifier and a 2200µF smoothing capacitor. This voltage rail is regulated by a 7812 linear regulator, with a 1N4001 diode in it's ground wire, giving an output voltage of 12.6V, perfect for the heater filaments of a pair of ECC82 / 12AU7 valves.(Those valves have two 6.3V filaments that can be wired in parallel or series for 6.3V or 12.6V operation)

I was surprised to see the 7812 in there, I did not remember adding that, but I guess it makes sense to regulate that supply. I think I would have planned to end up with a 6V or 12V AC winding that I could use directly, but this works and gives a clean regulated DC supply for the filaments.

Amplifier Circuit

The amplifier circuit is constructed directly on the valve bases. These are mounted in the lid. Normally with a case like that I would have used it the other way up with the lid (and the mounting screws) as the base to give a neater appearance. However here is clearly makes sense to have access to the sockets directly and the big transformers bolted to the base.

Valve circuits can be beautifully simple, this one is pretty minimal. Here are more bodges. These are not really output tubes. The transformers I used are not really suitable for audio frequency. You know the story by now.

I am using a pair of ECC82 / 12AU7 valves. One per channel. These are dual triodes, a pair of identical voltage controlled amplifiers in each tube. These act a bit like FETs. The voltage at the grid controls how much current flows between the cathode and the anode. Google it, I am sure there are many better explanations than that.

There is very low input impedance, which make this an ideal input stage. There is a 1M resistor to ground just to stop it floating. The first triode takes the input signal and amplifies it. The ECC82 has a gain of around 17, but there will be loads of headroom from a 1V peak to peak signal with a 200V supply.

This is capacitively coupled to the one half of the volume control. The output of which goes to the grid of the second triode, where the output is generated across the output transformer.

Yes, you guessed it, another mains transformer. This 240V-6V, 40:1 ratio drops down the very high voltage, very low current output to something low voltage, higher current, suitable for driving a speaker.

Here it is redrawn with the transformer simplified.

A mains transformer is completely the wrong thing to use here. They are not designed for audio frequency use. There are also potentially problems with the placement and proximity of all the transformers which could lead to coupling between them.

The right hand channel is, as you might have guessed, identical (but I drew it anyway)

Testing it out

Using the signal generator in my scope, I can feed in a 1KHz sine wave, and the output looks decent enough. You have to be very careful with things like this as the scope probe ground is connected to mains earth, as are parts of the amplifier circuit. In this case, I was measuring the input (which was grounded to mains earth at both ends) and the speaker output (which was isolated).

If I read that right, yellow is showing the input signal (I didn't disable the 10:1, so it is 1V p-p not 10V), and green is the ouput, looks to be about 500mV. Into a 4Ω speaker that would be 62mW? (I am going to pretend I didn't see that, it sounds loud enough to me.)

I don't have the necessary bits to do a frequency response plot. (I think the scope could do it, but it's one of the things knobbled by a license that I don't have) I expect the response would drop off at higher frequencies due to the properties of the wrong transformers I used. The frequency response of my ears is probably no better these days.


It is not very powerful, but it's fine for driving a couple of 1970s hi-fi speakers in a small room. The volume is usually set between 50% and 100%, I have not needed it to be any higher than that.

I built it as an experiment, to see if I could do it and how well it would work. I didn't have a use for it initially, but when the hi-fi amp in my workshop broke, I swapped this in as a temporary replacement. That must have been about 20 years ago. 

Valve circuits can be incredibly simple and incredibly reliable. I use it because it just sits there and works. I have a big switch by the door that cuts the power to the whole workshop when I leave, so this amplifier is on, and in use, any time I am in there.

It sounds fine to me, to listen to music or audio books when I am soldering, played from MP3 files by a Raspberry Pi that is wired to various amplifiers around the house. It is not the audiophile valve amplifier experience, that has been nullified by the use of the wrong parts and the signal source. 

I did start to make a better one, with a pair of EL84s per channel, one that I would listen to my vinyl records on my 1969 Goldring Lenco GL75 turntable. I got as far as drilling out a chassis, but I never got around to ordering the correct transformers, as they were so expensive. Any interest in my continuing with that? Any generous donors or anyone with some suitable transformers they no longer need?

Would I do anything different today? well, no, not with those parts. There are things I could improve if I wanted to make a better amplifier, but for this application it is fine.

  • I could tie the centre tap of the two filaments to ground via a 10K resistor to maybe reduce noise.
  • I could probably have done the wiring more neatly, but no one has had to look at it for 25 years, so it has not been a problem.
  • I could use a single ECC83 as the input stage for both channels and get 100x gain, and use a single ECC82 with it's lower gain / higher power as the output stages?
  • I could create a second B+ using the other 120V tap on the second transformer to give left and right isolated supplies.
  • I don't know if it would help to bypass the grid of the second triode with a capacitor. I have that on the input stage.

So, 25 year service is wiping off the dust, replacing the stick on feet on the bottom of the case and replacing a rounded screw. Here's to another 25 years.

Hope you enjoyed something different for a change.


I normally work on old computers, or new things for old computers, such as these:

ZX80, ZX81, Commodore PET and Jupiter Ace compatible computer kits


You can support me via Patreon, and get access to advance previews of blog posts and behind the scenes updates. This also includes access to my Patreon only Discord server for even more regular updates.

Saturday 23 December 2023

Commodore Disk Directory Structure

One from the Patreon archive, this from the development of the Penultimate +2 Cartridge file browser.

I am sure any Commodore user is very familiar with typing LOAD "$",8 and then LIST but what exactly is going on when you do that?

I wanted to add a file browser to the Penultimate +2 Cartridge so I looked for more information. I have several very thick and weighty tomes about Commodore disk drives, but none of them seemed to go into any detail about the directory format, so time to do some digging.

I started doing this on the VIC20, since it seemed appropriate, but the way this is handled in Commodore DOS is pretty much unchanged in all the 8 bit machines. I've gone back to the PET because that's where it all started, and it is easier to see what is going on with a 40 column screen.

I'd buy that for a dollar

Back in the late 1970s, Commodore BASIC was on five very expensive ROM chips, so it would not have been an easy option to extend that to a sixth or seventh to add support for DOS. Instead, the first disk drives found ways to work with what was already there. Rather than adding a DIRECTORY command (which finally appeared in BASIC 4), they created the concept of a special file called $.

To get a directory of a disk, you load that special file.

LOAD "$",8

And then you list it.


And you see a directory of the files on the disk.

But what you are seeing is actually a BASIC program. The drive creates this BASIC program on the fly, with a line for each file.

You can see that if you add your own lines to it and list again.

Back to BASICs

Time for a quick overview of how Commodore BASIC programs are stored.

Let's start with something simple.

20 GOTO 10

The PET stores programs in RAM starting at address $0401.

Looking at the memory at $0401, you can see the following structure:

>C:0401  15 04 0a 00  99 20 22 48  45 4c 4c 4f  20 57 4f 52   ..... "HELLO WOR
>C:0411  4c 44 22 00  1e 04 14 00  89 20 31 30  00 00 00 ff   LD"...... 10....
>C:0421  ff ff ff ff  ff ff ff ff  ff ff ff ff  ff ff ff ff   ................

I filled the RAM with FF before typing the program, so you can more easily see where it ends

Each line starts with the address of the next line.

15 04

So the second line starts at $0415 (the 6502 is little-endian).

Next is the line number, in this case 10 ($0A in hex).

0a 00

Then the code starts. Here 99 is the token for PRINT, and 20 is the space after it. (hint, get rid of the spaces if you want your programs to be smaller and faster)

99 20

Then comes the string "HELLO WORLD" in quotes.

22 48 45 4c 4c 4f 20 57 4f 52 4c 44 22

Finally a null ends the line.


Line 20 is a similar format, address of the next line, line number, GOTO (code $89), space and the destination line number as a string and finally a null.

1e 04 14 00 89 20 31 30 00

The address of the next line is $041E, and at $041E, there are two zeroes, indicating the end of the program.

00 00

And that's it.

Now, let's save that to disk. I formatted a new disk, again there is no FORMAT command (when BASIC 4 arrived, it used INITIALISE). So the BASIC OPEN and CLOSE commands are used, n is initialise, 0 is the drive number within the device (0 or 1 on a dual drive, 0 on single). The name can be followed by a number, which is displayed in the directory listings. I used 10 here. It is used by the drive to work out if the disk has been changed so it can reload it's cache.


I can now save the program with the SAVE command with ,8 to indicate device 8, the disk drive.


(you could verify at this point to make sure it has saved, but we have nice reliable storage these days, so no need).


Now we can get to the actually important bit.

LOAD "$",8

If I LIST now, the hello program has been overwritten, and I get a directory. It is important to remember that LOAD "$",8 will overwrite the program. It was not until BASIC 4 added the DIRECTORY command (and rather redundant identical CATALOG command) that you could do that without overwriting the program. 

(DIRECTORY was a nightmare to support on the SD2PET, it reads a few bytes - not a consistent number - then stops mid flow to update the screen, then reads a few more - again 1, 2 or 3, then interrupts the drive again. Would have made sense to do 32 characters at a time at least, but maybe it was also trying to deal with some of the oddities - see later.)

So if that last been listed, then it must be a program, right?

Let's have a look at $0401.

>C:0401  1f 04 00 00  12 22 54 45  53 54 44 49  53 4b 20 20   ....."TESTDISK  
>C:0411  20 20 20 20  20 20 22 20  31 30 20 32  41 00 3f 04         " 10 2A.?.
>C:0421  01 00 20 20  20 22 48 45  4c 4c 4f 22  20 20 20 20   ..   "HELLO"    
>C:0431  20 20 20 20  20 20 20 20  50 52 47 20  20 00 5d 04           PRG  .].
>C:0441  97 02 42 4c  4f 43 4b 53  20 46 52 45  45 2e 20 20   ..BLOCKS FREE.  
>C:0451  20 20 20 20  20 20 20 20  20 20 20 00  00 00 0d ff              .....
>C:0461  ff ff ff ff  ff ff ff ff  ff ff ff ff  ff ff ff ff   ................

The structure is the same, just a nonsensical program that is only useful for listing.

So the first two bytes tell us that the second line starts at $041F. Then there is the line number, in this case zero ($00 $00). 

1f 04 00 00

Next there is a $12 which is the PETSCII code to switch to inverse text. After that, there is the string which is the disk title, padded with spaces inside the quotes.

12 22 54 45 53 54 44 49 53 4b 20 20 20 20 20 20 20 20 22

The a space, then the disk number as a string (as typed in above, in this case 10).

20 31 30

Then another space and the disk type, which is always $2A (Do you think the Commodore guys were Hitch Hikers Guide to the Galaxy fans?) and finally a null which signals the end of the line.

20 32 41 00

There is no $92 to cancel the inverse characters, but that will be cancelled by the end of line so it is not required.

The second line is the first file, the first two bytes point to the next entry, $043F, and then the line number, 0001 in this case, although it is actually the number of blocks used by the file. Neat huh?

3f 04 01 00

Next comes the filename, padded with some spaces outside the quotes.

20 20 20 22 48 45 4c 4c 4f 22 20 20 20 20 20 20 20 20 20 20 20 20

The space padding continues up to the file type, not in quotes, in this case PRG

50 52 47

Finally a couple of spaces and then a null.

20 20 00

The third line is the "blocks free" information.

5d 04

This one starts as normal, the next line is at $045D, but the line number is actually the number of blocks free, 663 in this case, as $0297 in hex.

97 02

After that is the BLOCKS FREE. text (no quotes)

42 4c 4f 43 4b 53 20 46 52 45 45 2e

And then a load of spaces padding it to the end of the line. A final null, and then the two nulls at start of the next line indicate the end of the program.

20 20 20 20 20 20 20 20 20 20 20 20 20 00  00 00

All the entries are exactly 32 bytes long.

When there are multiple files, there are simply more lines in the middle, and if the files are the same size, the line numbers are duplicated, but that does not matter as it is just used for listing.

Here I went back and using the magic of the screen editor, entered the program again, formatted the disk again (with a different ID) and save the program 4 times.

>C:0401  1f 04 00 00  12 22 54 45  53 54 44 49  53 4b 20 20   ....."TESTDISK  
>C:0411  20 20 20 20  20 20 22 20  32 30 20 32  41 00 3f 04         " 20 2A.?.
>C:0421  01 00 20 20  20 22 48 45  4c 4c 4f 20  31 22 20 20   ..   "HELLO 1"  
>C:0431  20 20 20 20  20 20 20 20  50 52 47 20  20 00 5f 04           PRG  ._.
>C:0441  01 00 20 20  20 22 48 45  4c 4c 4f 20  32 22 20 20   ..   "HELLO 2"  
>C:0451  20 20 20 20  20 20 20 20  50 52 47 20  20 00 7f 04           PRG  ...
>C:0461  01 00 20 20  20 22 48 45  4c 4c 4f 20  33 22 20 20   ..   "HELLO 3"  
>C:0471  20 20 20 20  20 20 20 20  50 52 47 20  20 00 9f 04           PRG  ...
>C:0481  01 00 20 20  20 22 48 45  4c 4c 4f 20  34 22 20 20   ..   "HELLO 4"  
>C:0491  20 20 20 20  20 20 20 20  50 52 47 20  20 00 bd 04           PRG  ...
>C:04a1  94 02 42 4c  4f 43 4b 53  20 46 52 45  45 2e 20 20   ..BLOCKS FREE.  
>C:04b1  20 20 20 20  20 20 20 20  20 20 20 00  00 00 0d ff              .....
>C:04c1  ff ff ff ff  ff ff ff ff  ff ff ff ff  ff ff ff ff   ................

By the way, on the subject of things you can do with the screen editor. Whether by design or accident, the position of the filenames in a directory listing means you can cursor up and have space to type in LOAD before the name, then just cursor along and add ,8 in place of the PRG and load your program. Handy with long filenames, or ones with odd characters that are not easy to type out.

Penultimate Cartridge File Browser

I wanted to integrate the file browser into the existing menu structure. This stile of menu was introduced for the Penultimate +, and has been added to with each release, as the list of games grew. The latest improvement that has made it a lot faster to use was adding SHIFT + letter navigation to jump directly to a page of the games list, starting with that letter.

I could have looked at building in something like the FB program that is used on the SD2IEC, but I thought the difference in appearance was a bit jarring, and it would require a lot of work to deal with the memory management of the loading side.

To make that work with the existing menu structure meant I had to adapt that from using the hard coded games list and fixed menus to being able to work with a dynamically loaded file list from disk. I will not go into the internal workings of the menu, but I do want to look at getting the data to create the directory listings.

Having the games list dynamically loaded did come in very handy for adding the "filter by category" and the source for the random games list.

Based on what I had learned, I was able to implement the file browser in the Penultimate +2 Cartridge.

Once you are thinking about the directory as a program, then all I have to do is load the program into memory. The maximum number of files on a Commodore disk is 144. Each entry is 32 bytes, so the total is about 4.5K, including the extra lines for the disk title and blocks free. That means I couldn't load the listing to $0401 as it was on the PET as that would overwrite the screen when it got to $1000.

The menu program on the cartridge is already taking up three 8K blocks of ROM, and is ever growing with all the new things being added. I was thinking I might expand that to four 8K blocks of ROM, but I will need to keep 8K free to load the directory listing.

I override the load address, and load the data to RAM at $2000, the start of the 8K bank 1.

>C:2000  01 01 00 00  12 22 54 45  53 54 44 49  53 4b 20 20   ....."TESTDISK  
>C:2010  20 20 20 20  20 20 22 20  32 30 20 32  41 00 01 01         " 20 2A...
>C:2020  01 00 20 20  20 22 48 45  4c 4c 4f 20  31 22 20 20   ..   "HELLO 1"  
>C:2030  20 20 20 20  20 20 20 20  50 52 47 20  20 00 01 01           PRG  ...
>C:2040  01 00 20 20  20 22 48 45  4c 4c 4f 20  32 22 20 20   ..   "HELLO 2"  
>C:2050  20 20 20 20  20 20 20 20  50 52 47 20  20 00 01 01           PRG  ...
>C:2060  01 00 20 20  20 22 48 45  4c 4c 4f 20  33 22 20 20   ..   "HELLO 3"  
>C:2070  20 20 20 20  20 20 20 20  50 52 47 20  20 00 01 01           PRG  ...
>C:2080  01 00 20 20  20 22 48 45  4c 4c 4f 20  34 22 20 20   ..   "HELLO 4"  
>C:2090  20 20 20 20  20 20 20 20  50 52 47 20  20 00 01 01           PRG  ...
>C:20a0  94 02 42 4c  4f 43 4b 53  20 46 52 45  45 2e 20 20   ..BLOCKS FREE.  
>C:20b0  20 20 20 20  20 20 20 20  20 20 20 00  00 00 00 00

Looking at the data which is loaded, you can see the addresses for the next lines are not as they were before. The are all $0101. This is because the BASIC LOAD command relinks the program lines depending on where they are loaded in memory. The disk drive doesn't know what machine you have. Back in 1978, they could not even dream that the VIC20 would follow a couple of years later and have three different load addresses based on the amount of expansion RAM installed.

So going back to the VIC20, if I load the same "$" file from the same drive, it lists the same, but when you look at the RAM, you can see the line addresses have all been changed.

>C:1000  00 1f 10 00  00 12 22 54  45 53 54 44  49 53 4b 20   ......"TESTDISK 
>C:1010  20 20 20 20  20 20 20 22  20 32 30 20  32 41 00 3f          " 20 2A.?
>C:1020  10 01 00 20  20 20 22 48  45 4c 4c 4f  20 31 22 20   ...   "HELLO 1" 
>C:1030  20 20 20 20  20 20 20 20  20 50 52 47  20 20 00 5f            PRG  ._
>C:1040  10 01 00 20  20 20 22 48  45 4c 4c 4f  20 32 22 20   ...   "HELLO 2" 
>C:1050  20 20 20 20  20 20 20 20  20 50 52 47  20 20 00 7f            PRG  ..
>C:1060  10 01 00 20  20 20 22 48  45 4c 4c 4f  20 33 22 20   ...   "HELLO 3" 
>C:1070  20 20 20 20  20 20 20 20  20 50 52 47  20 20 00 9f            PRG  ..
>C:1080  10 01 00 20  20 20 22 48  45 4c 4c 4f  20 34 22 20   ...   "HELLO 4" 
>C:1090  20 20 20 20  20 20 20 20  20 50 52 47  20 20 00 bd            PRG  ..
>C:10a0  10 94 02 42  4c 4f 43 4b  53 20 46 52  45 45 2e 20   ...BLOCKS FREE. 
>C:10b0  20 20 20 20  20 20 20 20  20 20 20 20  00 00 00 00               ....

It all looks fine, to the naked eye, but it don't really happen that way at all.

That all looks good, but I have found quite a few oddities. Consider this, the 1540/1541 demo disk.

Listing looks good doesn't it.

But looking at the program in memory it is not consistent. Some lines have two spaces before the quotes, some three. 

>C:0401  1f 04 00 00  12 22 31 35  34 30 54 45  53 54 2f 44   ....."1540TEST/D
>C:0411  45 4d 4f 20  20 20 22 20  5a 5a 20 32  41 00 3f 04   EMO   " ZZ 2A.?.
>C:0421  04 00 20 20  20 22 44 49  52 22 20 20  20 20 20 20   ..   "DIR"      
>C:0431  20 20 20 20  20 20 20 20  50 52 47 20  20 00 5f 04           PRG  ._.
>C:0441  06 00 20 20  20 22 56 49  45 57 20 42  41 4d 22 20   ..   "VIEW BAM" 
>C:0451  20 20 20 20  20 20 20 20  50 52 47 20  20 00 7f 04           PRG  ...
>C:0461  0e 00 20 20  22 44 49 53  50 4c 41 59  20 54 26 53   ..  "DISPLAY T&S
>C:0471  22 20 20 20  20 20 20 50  52 47 20 20  20 00 9f 04   "      PRG   ...
>C:0481  04 00 20 20  20 22 43 48  45 43 4b 20  44 49 53 4b   ..   "CHECK DISK
>C:0491  22 20 20 20  20 20 20 20  50 52 47 20  20 00 bf 04   "       PRG  ...
>C:04a1  09 00 20 20  20 22 50 45  52 46 4f 52  4d 41 4e 43   ..   "PERFORMANC
>C:04b1  45 20 54 45  53 54 22 20  50 52 47 20  20 00 df 04   E TEST" PRG  ...
>C:04c1  05 00 20 20  20 22 53 45  51 55 45 4e  54 49 41 4c   ..   "SEQUENTIAL
>C:04d1  20 46 49 4c  45 22 20 20  50 52 47 20  20 00 ff 04    FILE"  PRG  ...
>C:04e1  0d 00 20 20  22 52 41 4e  44 4f 4d 20  46 49 4c 45   ..  "RANDOM FILE
>C:04f1  22 20 20 20  20 20 20 50  52 47 20 20  20 00 1d 05   "      PRG   ...
>C:0501  61 02 42 4c  4f 43 4b 53  20 46 52 45  45 2e 20 20   a.BLOCKS FREE.  

It took me quite a while to realise this was to make all the quotes line up. The line number is the number of blocks, which can be 1, 2 or 3 digits long, so the number of spaces after the line number is reduced by 1 for >9 and by two for >99. Seems perfectly logical once I worked it out, but before that it just looked like it randomly changed the padding.

It does make it quite a challenge to parse that to extract the data because you can't just read filename, skip 32 bytes, read next filename etc.

But, I got there in the end. I spent quite a while searching out various esoteric disk images to make sure all would be supported, and with the exception of some animated ones with trick graphics, all work well. Up to, and including the maximum 144 files.

What about directories?

I couldn't find any way to create a directory within a D64 image, I do not think it was ever supported, however, it is supported by things like the SD2IEC disk drive.

However, this is no support for it in the LOAD "$" directories. What you see if the folder name instead of the disk name, and the list of files. No ".." for the root directory as you might expect.

I have to manually add the .. to the list of files, as well as the back arrow to go back to the menu.

I have switched to photos from a real VIC20 (in this case an NTSC one) to show the folder structure, since I cannot get a disk image with subdirectories on the Vice emulator I have been for the other screenshots in this post.

There was a bug in the original version where the extra line needed for the .. was not taken into account when moving to the second screen, so in the case of A-Z folders in a subdirectory, the Q would be skipped. This is fixed in later versions.


Just to add to this, the version of BASIC 4 for the VIC20 includes the DIRECTORY and CATALOG commands, and they appear to be better formatted for the available screen width.

You can type out DIRECTORY or CATALOG in full, but I find the shortcuts easier, I normally use C shift A.


Penultimate +2 Cartridge

The Penultimate +2 Cartridge, with built in file browser and so much more are in stock at The Future Was 8 bit:

More info in a previous post:

See also a great video from Robin, 8 bit show and tell:


You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here. This also includes access to my Patreon only Discord server for even more regular updates.