Blog reflection over 2024

Not much to report this year. I have only written one article: Using a Commodore Amiga 4000 in 2024.

Next year, I hope to find back my usual cadence. I am not out of ideas and there is definitely going to be more to report about.

The last thing I would like to say is:

HAPPY NEW YEAR!!!!

Using a Commodore Amiga 4000 in 2024

Some time ago, I have written a couple of blog posts about using my old Commodore computers that I grew up with: the Commodore 64, 128, and Amiga 500 in modern times.

At the time these machines were bought by my parents (in the late 80s and early 90s), Commodore still used to be a respected and mainstream computer brand. Times were quite exciting back then -- I had many relatives that used to own a Commodore computer. We also used to regularly visit local computer clubs in which we used to exchange ideas and software.

An uncle of mine was always very progressive with new computer models -- he was always the first in the family to make the switch to a new computer model. For example, when we all still used Commodore 64 and 128s, he was the first to make the switch to the Amiga 500 when it came out. He was also the only relative to buy an Amiga 4000 -- the most powerful Amiga model. After Commodore's demise, he was the first to switch to the PC.

I still remember that I was always excited to visit him in the Amiga days. The Amiga 4000 was much more advanced than the Amiga 500 (that we used to own at that time) and I was very impressed by its improved graphics and speed capabilities.

Contrary to the 64, 128 and Amiga 500, I have never worked with the Amiga 4000 much, aside from a couple of visits to my uncle and the Home Computer museum in Helmond.

Almost three years I ago, I ran into the opportunity of buying a second hand Amiga 4000.

Although I am quite happy to have a good working Amiga 4000 in my possession, there were a couple of subtle annoyances:

• The machine has quite a few hardware and software modifications. As a result, when I boot up the machine, it loads a heavily modified AmigaOS 3.9 Workbench with many additions and customizations, such as a high resolution screen with large high color icons.
  
  Although the installation works fine and provides useful features, this Workbench installation barely resembles the desktop environment I was used to in the 90s.
• I want control over the machine's hard-drive's software configuration -- I want to exactly know how to reproduce a machine's configuration from scratch, in case all data gets lost.
  
  As a consequence, I must exactly know which applications and dependencies I need to install, where these software packages came from, and what kind of configuration changes I want to make. I have such procedures documented for myself.
  
  Doing this for my Amiga 4000, turned out to be somewhat a challenge -- some floppy disks, such as driver disks, and instruction manuals were lost by the previous owner.
• I only want to install the software packages that I know. As a consequence, I want to get rid of the software that I do not use or care about.

In the last few weeks, I have managed to perform clean AmigaOS 3.1 and AmigaOS 3.9 installations on my Amiga 4000 -- I have identified all my required software packages, found the ones that were missing, and documented the installation procedures.

In this blog post, I will explain the properties of my Amiga 4000 and report about my findings.

Some interesting properties of the Amiga 4000

As I have already explained, the Amiga 4000 was the most advanced Amiga model produced by Commodore. It was released in mid-1992, but it took a little while longer before they became available on the market in my home country, the Netherlands.

Similar to the earlier Amiga models, such as the Amiga 500, it contains custom chips that give the Amiga all kinds of nice multimedia capabilities, such as a good working sound chip (Paula), a video beam-aligned co-processor: the copper, capable of generating all kinds of interesting visual effects, and the blitter, a co-processor capable of quickly copying data chunks (such as graphics surfaces).

The Amiga 4000 has the following improvements over its predecessor models:

• A more advanced and much faster CPU: a 68040 clocked at 25 MHz with an FPU (floating point unit) and a MMU (memory management unit). In contrast, the Amiga 500 has a 68000 CPU clocked at 7 MHz, without an FPU and MMU.
  
  (As a sidenote: Some time later, Commodore also introduced a lower priced Amiga 4000 model containing the 68EC030 CPU. Its capabilities are similar to the 68030 CPU that can also be found in the Amiga 3000, but the EC variant is cheaper, because it removes the MMU and FPU.)
• More RAM. By default, the Amiga 4000 came with 2 MiB chip RAM and 4 MiB fast RAM. The amount of fast RAM can be upgraded to 16 MiB. With a Zorro III expansion card, fast RAM can be extended even further to, for example, 64, 128, 256 MiB and even larger quantities.
• AGA graphics chipset. The AGA chipset is the successor to the previous Amigas' OCS and ECS graphics chipsets -- it expands the amount of color registers from 32 to 256, and increases the size of the red, green and blue color components from 4 bits (providing a set of 4096 possible colors) to 8 bits (providing a set of approximately 16.8 million possible colors).
  
  The OCS and ECS graphics chipsets also offer HAM-6 screen modes, that make it possible to use view photo realistic images using all 4096 colors by using only 6 bits per pixel (albeit with some compression limitations). The AGA chipset offers an additional 8-bits HAM mode capable of displaying 262144 colors on one screen, with some compression limitations.
• A high-density floppy drive. High density floppies have twice the amount of storage capacity of double density disks (1.72 MiB rather than 880 KiB).
• A new operating system Kickstart and Workbench (version 3.0), with all kinds of new features. Its successor version (version 3.1) also became available on the earlier Amiga models as an upgrade, such as the Amiga 500.

Contrary to the Amiga 500, but similar to the Amiga 2000 and 3000, the Amiga 4000 is a high-end computer model, not a budget model -- the computer is in a separate case (not integrated into the keyboard), and has much more extension capabilities. The Amiga 4000 has four Zorro III expansion slots, rather than one. You can use these slots to extend the machine with multiple hardware peripherals at the same time, such as external graphics, sound and network cards.

The Amiga 1200 and Amiga CD32 are the Amiga 4000's budget counterparts. The Amiga 1200 also contains the AGA chipset, but only has one expansion slot, less memory and a cheaper and less powerful CPU (the 68EC020). The CD32 is basically an Amiga 1200 that lacks a keyboard, but includes a CD-ROM drive.

Although the Amiga 4000 has quite a few nice improvements over its predecessor models, the competitive situation of Commodore was quite bad in 1992. Contrary to the introduction of the Amiga 1000 and 500 (in 1985-1987) Commodore no longer had the competitive edge in 1992.

In the late 80s, due to mismanagement and cuts in research budgets, the Amiga failed to innovate. With the introduction of the Amiga 4000 and 1200, Commodore was basically just "catching up". The competition, such as the IBM PC and compatibles, were ahead in many areas:

• VGA graphics (introduced in 1987) have become more common in PCs in the 90s. VGA provides a 320x200 screen mode with 256 colors (albeit out of a palette of 262144 possible colors) and has an easier method to address pixels -- chunky graphics, that address every pixel as a byte, rather than 8 separate bitplanes.
  
  Although for 2D games, the Amiga's AGA chipset did fine in comparison to VGA, it had no "good answer" to 3D games, such as Wolfenstein 3D and Doom, because it lacks the chunky graphics modes that these games heavily rely on.
  
  (As a sidenote: many years later, after Id software released the source code of Wolfenstein 3D and Doom, these games were ported to the classic Amiga models, but that is a different story).
• After VGA, even better graphics standards were developed for the PC in the late 80s and early 90s, such as Super VGA and XGA, that were much more powerful than Amiga's AGA chipset. These graphics standards support even higher resolutions and more colors (16-bit high color, and 24/32 bits true color screen modes).
  
  Aside from using an external RTG card, the Amiga did not provide any built-in solution to match these graphical features.
• From an audio perspective, the Amiga was also no longer leading. Although Paula was still a fine sound chip in 1992, cheaper and more powerful sound cards were developed for the PC that can provide an even better experience.

The only area that I believe the Amiga still had a competitive edge in 1992 was on operating system level. In 1992, Microsoft had no consumer operating system yet that was capable of doing pre-emptive multi-tasking. Windows NT 3.1 (release mid 1993) was the first version of Windows supporting pre-emptive multi-tasking, but it was an expensive operating system meant for business use. Windows 95 brought pre-emptive multi-tasking to consumers, but it became available in the middle of 1995. It took Apple even longer -- they brought pre-emptive multi-tasking to consumers with Mac OS X, introduced in 2001.

The Amiga 4000 also has a number of drawbacks over its predecessor models -- it used cheaper hardware components of lesser quality, such as IDE rather than SCSI for hard-drives (SCSI at that time provided better performance) and low quality capacitors and batteries, that will typically start to leak after years of inactivity, damaging the motherboard. Fortunately, my Amiga 4000 was revised in time to not suffer from any damage.

My Amiga 4000 specs

My Amiga 4000 has the following specs:

• It is the Amiga 4000/040 model, which means that it has a 68040 CPU (with an MMU and FPU), rather than the cheaper, slower and less powerful 68EC030 CPU (that lacks an MMU and FPU).
• The amount of fast RAM on the board was upgraded to 16 MiB.
• It also contains an expansion card: a Phase 5 Fastlane Z3 providing a SCSI controller (no devices are connected to it) and another 32 MiB of fast RAM, providing me a total of 48 MiB of fast RAM.
• Similar to my Amiga 500, the hard-drive was broken due to old age. It was replaced by a CF2IDE device, making it possible to use a Compact Flash card as a replacement hard drive. Compared to old hard drives, a Compact Flash card provides much more storage capability and higher I/O speeds.
• A DVD-ROM player was added
• An external RTG graphics card was added: the Cybervision 64/3D. This card provides chunky graphics at much higher resolutions and higher color modes than the AGA chipset (in addition to 8-bit colors, it provides 16-bit high color and 24/32-bit true color).
• The original 3.1 kickstart ROM was replaced by an AmigaOS 3.9 kickstart ROM. This requires some explanation.

I have also been using some of the replacement peripherals of my Amiga 500 in combination with the Amiga 4000:

• I can attach my GoTek floppy emulator to the external floppy disk connector and use it as the DF2: drive. Although the internal disk drive still works fine, using disk images from a USB memory stick is much more convenient than using real floppies.
• I can use the null modem cable to hook up the Amiga 4000 to my PC and conveniently exchange files.
• I can use the RGB2SCART cable to connect the RGB output to my LED TV, because I no longer have a working Amiga monitor.

AmigaOS 3.9

As I have already mentioned earlier, the original Kickstart 3.1 ROM chip in my Amiga was replaced by an "AmigaOS 3.9 Kickstart ROM". This kickstart ROM was a big mystery to me when I first saw it.

According to Wikipedia, AmigaOS 3.5 and 3.9 were developed by Haage & Partner after Commodore's demise. They were released in 1999 and 2002 as software-only updates to Kickstart 3.1 systems, that ran at least on a 68(EC)020 processor.

AmigaOS 3.9 has a variety of changes and additions over AmigaOS 3.1, such as:

• An updated SCSI driver that is not restricted to a maximum of 4 GiB of storage
• A TCP/IP stack and web browser
• An MP3 player
• Various look and feel updates
• NewIcons, providing 256 color, high resolution icons, rather than 4 color icons in the classic Workbench
• AmiDock (a menu application that can be used to conveniently launch applications)

After learning more about AmigaOS 3.5 and AmigaOS 3.9, I still did not understand where this ROM chip came from or why it was needed, because the official AmigaOS 3.9 documentation does not mention the kickstart part at all.

After some additional searching, I learned that this 3.9 ROM chip is a scene/homebrew ROM. Basically its value is that it provides a faster and more convenient AmigaOS 3.9 bootup.

Normally, AmigaOS 3.9 patches various aspects of the Kickstart 3.1 ROM on first startup with various kinds of modifications, such as a better SCSI driver and Workbench modifications. After the patching is complete, the machine reboots and then the system boots into Workbench 3.9, making the first startup process slow. With the AmigaOS 3.9 ROM chip these modifications are already present on powerup, making the boot process faster.

Moreover, because the Kickstart 3.1 ROM's internal SCSI driver is not able to escape the 4 GiB limit, the first partition of a hard drive needs to be smaller than 4 GiB. When using the AmigaOS 3.9 ROM, there is no such limitation because the patched SCSI driver is already present in memory.

Installing an AmigaOS 3.9 system from scratch

Another thing that I learned is that Amiga Workbench 3.1 does not boot on Kickstart 3.9. After some deeper inspection, I discovered that the LoadWB command in the Startup-Sequence fails with an "invalid resident library" error.

My guess is that AmigaOS 3.9's modified workbench.library is not compatible with the LoadWB command from Amiga Workbench 3.1. This incompatibility is a bit disappointing, because previous kickstart releases (provided by Commodore) were always backwards compatible with older Workbench releases. For example, you can still boot Workbench 1.3 on a system with a Kickstart 3.1 ROM.

Because of this incompatibility and because I learned the value of using AmigaOS 3.9, I have decided to first do a clean AmigaOS 3.9 installation on a new Compact Flash card.

Creating an AmigaOS 3.9 boot disk

Contrary to the Amiga Workbench versions provided by Commodore, AmigaOS 3.9 is distributed on a CD-ROM, rather than a set of floppy disks.

On my Amiga 4000, it is not possible to boot from a CD-ROM. To do a fresh AmigaOS 3.9 installation, I must first create an emergency boot disk that has access to the CD-ROM drive.

Creating an emergency disk is straight forward. I must first boot from an existing Workbench installation, insert the AmigaOS 3.9 CD-ROM and start the installer: CD0:OS-Version3.9/OS3.9-Installation. In the installer I need to pick the option: "Create emergency disk". The rest of the steps are self explanatory:

The size of my Compact Flash card is 32 GiB. As I already explained, Commodore never took drives of such large sizes into account because they simply did not exist yet in 1992. As a result, the SCSI driver and Amiga Fast File System were never designed to (efficiently) deal with them.

The previous owner decided to use Smart Filesystem (SFS) as the default filesystem for the harddisk partitions rather than Amiga's Fast File System, because it is much better suited for large partitions. I have decided to do the same.

To be able to create SFS partitions and format them, I have downloaded and unpacked the SFS distribution from Aminet and copied the following files to the emergency boot disk:

• The file system handler from: AmigaOS3.x/L/SmartFilesystem to DF2:L/.
• The SFSformat command from the base directory to DF2:C/.

Partitioning the hard drive

After finishing the emergency boot disk, I can switch off the machine, insert my blank Compact Flash card, and boot from the emergency disk to partition the hard drive.

As a sidenote: similar to my Amiga 500, I recommend to clear a memory card first before partitioning it. Traces of previous partitions may confuse tools, such as HDToolBox and DiskSalv. On Linux, I can clear a memory card by running the following command:

$ dd if=/dev/zero of=/dev/sdb bs=1M

I have used the HDToolBox tool included with the AmigaOS 3.9 installation CD (CD0:Emergency-Boot/Tools/HDToolBox) to do the partitioning:

• First, I need to select the drive that I want to partition. I have picked: SDCFXS-032G and clicked on the button: 'Install drive'
• Then I need to configure HDToolBox to recognize Smart Filesystem partitions. I can configure HDToolBox to use the SmartFileSystem handler, by selecting the first partition, and then clicking on: 'Add/Update...' button below the 'Filesystem / International (FFS)' text box.
• Then I must click on the button: 'Add New Filesystem...' and open DF2:L/SmartFileSystem handler
• Finally, when creating a partition, I must change the partition's file system to: CFS\00

Although with the custom kickstart 3.9 ROM it is possible to escape a partition's 4 GiB limit, I have still decided to keep the first two partitions below 2 GiB -- the operating system and Workbench may be able to work fine with larger partitions, but certain applications may still have problems. For example, AMOS BASIC internally uses signed 32-bit integers to indicate the amount of free disk space. As a consequence, it will overflow and report weird values if a partition is bigger than 2 GiB.

Formatting the hard drive partitions

After creating the partitions, I have to reboot the system once more and boot from the emergency disk so that these new partitions are recognized. Then I can format the partitions by running the following kinds of commands on the command-line interface (CLI):

DF2:C/SFSformat DEVICE DH0: NAME HARDDISK0 SHOWRECYCLED

The above command formats the device DH0:, gives it the name: HARDDISK0 and adds a recycle bin to it.

Installing Workbench 3.9

Finally, I can install AmigaOS 3.9 on the hard drive from the CD-ROM, by opening the installer: CD0:OS-Version3.9/OS3.9-Installation and selecting the option: "OS3.9 full installation over OS3.0 or empty HD". The procedure is straight forward and self explanatory.

After completing the installation, I can reboot the machine and boot into AmigaOS 3.9 installed on the hard disk. Then I can install the applications that I want.

Making the RTG graphics card work

Installing the applications that I want is generally a straight forward process. The only challenge was making the Cybervision 64/3D graphics work.

As I already explained in the beginning of this blog post, the driver disks and the manual were lost. Fortunately, this Amiga hardware database page can still offer me the missing copies.

In my search process, I also learned a thing or two about retargetable graphics (RTG) on the Amiga. It seems that Commodore never developed a standardized API for AmigaOS to facilitate retargetable graphics. It was on the planning, but they went out of business before it got realized.

Other parties eventually stepped up to fill the gap. The two most popular RTG APIs are CyberGraphX (launched in 1995) and Picasso96 (launched in 1996). Initially, CyberGraphX was the most popular, but the slowly Picasso96 overtook its popularity, because it provides much better integration with the Amiga Workbench. The two APIs have a high-degree of compatibility with each other.

First, I tried to install CyberGraphX that came with the missing driver disks. Although I was able to see the 'CyberGraphX' logo on my VGA monitor, RTG graphics were not usable. The system basically just hangs. I guess this problem may be caused by an incompatibility with AmigaOS 3.9 or the CyberGraphX libraries that were already stored in the Kickstart 3.9 ROM.

Then I tried Picasso96. A copy was included on my AmigaOS 3.9 CD-ROM. It includes a driver for my Cybergraphics 64/3D card.

Unfortunately, with Picasso96 I also ran into problems. Using the test feature in the Picasso96Mode Prefs program always showed me a black screen, no matter how much I change the display parameters.

After an extensive search on the web and comparing the content of my AmigaOS 3.9 installation with the installation of the previous owner I eventually discovered the root cause -- there was no 68040.libary installed on my system. I fixed the issue by copying the missing library from the directory: CD0:OS-Version3.9/Extras/Libs on the AmigaOS 3.9 CD-ROM to DH0:Libs.

After fixing the library issue, Picasso96 works fine. I can, for example, display the Workbench (and many Intuition/Workbench-based applications) at a much higher resolution on my VGA screen:

The above pictures show the effect of enabling RTG graphics. On the left, the Workbench screen is rendered by the AGA chipset (using a 640x256 resolution). The RGB output is attached with an RGB2SCART cable to the right screen. On the right, we have enabled the RTG card using a much higher resolution: 800x600. The RTG card is connected with a VGA cable to the left screen.

Installing an AmigaOS 3.1 system from scratch

After producing a working AmigaOS 3.9 configuration from scratch, I also wanted to have a working AmigaOS 3.1 installation so that I can enjoy the original user experience that I was used to in the 90s.

Because Compact Flash cards are cheap, and we can conveniently switch them at the back of the machine, we can easily make a second hard drive image with an AmigaOS 3.1 installation.

Getting a working AmigaOS 3.1 installation turned out to be quite an interesting puzzle :). As I have already explained, Workbench 3.1 is not compatible with Kickstart 3.9. Contrary to my Amiga 500, it seems that it is not possible to have multiple kickstart ROM chips in my Amiga 4000 -- my Amiga 500 has two kickstart ROM chips (1.3 and 2.0) and a kickstart switcher, but as far as I know, such a device does not exist for the Amiga 4000.

Moreover, I am hesitant to replace the Kickstart 3.9 ROM chip by the original Kickstart 3.1 ROM chip. Aside from the fact that I find replacing chips scary, it also feels as a step backwards to deliberately degrade a working system's functionality -- Kickstart 3.9 has useful features, such as an updated SCSI driver.

Soft kicking Kickstart 3.1

After recollecting my memories of earlier Amiga models, I realized that there is a different way to tackle my problem. The first Amiga model: the Amiga 1000, did not have a kickstart ROM at all. Instead, on initial power up, it showed a white screen requesting the user to load the kickstart from a floppy disk into a restricted area of the RAM. After the kickstart is loaded, it shows the well-known floppy disk splash screen and permanently stays in RAM, even after reboots.

After some searching, I learned that loading a Kickstart into RAM is possible on all Amiga models, by using a program called a "soft kicker". There are a variety of such programs available.

For example, SKick is a soft kicker that works well on my Amiga 500 -- it can patch a variety of Amiga 500 compatible kickstart ROM images, load them into a different area in memory, namely: RAM, and then reboot the machine to use that Kickstart version. The Kickstart stays in memory, even after a reboot.

The only price you need to pay is 256 KiB (for Kickstarts 1.x) or 512 KiB (for Kickstarts 2.x or newer) of RAM. If you have a memory expansion, such as an additional 8 MiB of fast RAM, this is typically not a big issue.

SKick does not seem to work well on my Amiga 4000. From what I have read, the problem is that the 68040 CPU has an MMU and puts things in memory differently than SKick is used to.

After some more searching on Aminet, I found BlizKick. This soft kicker is originally designed for phase5/DCE turbo boards, but it also supports the MAPROM feature of the Commodore A3640 CPU card that contains the 68040 CPU.

I discovered that the MAPROM feature was disabled on my CPU card. I had to open the Amiga 4000 case and change the jumper configuration to enable it:

After enabling the MAPROM feature, I can easily soft kick my machine from my existing AmigaOS 3.9 installation to load the original Kickstart 3.1, by running the following command-line instruction:

BlizKick CPUCARD KICKFILE DEVS:Kickstarts/kick40068.A4000

The above command-line instruction states that we need to load the 3.1 Kickstart ROM for the Amiga 4000 file into RAM: DEVS:Kickstarts/kick40068.A4000 and soft kick it by using the MAPROM feature of my A3640 CPU card.

"Bootstrapping" AmigaOS 3.1

The next step turned out to be a challenging one. I need to somehow partition the hard drive, format the partitions and install Workbench 3.1. My idea was to create a bootable floppy disk to soft kick my Amiga 4000 into Kickstart 3.1, and then boot from the Workbench 3.1 install disk.

Unfortunately, it turns out that calling BlizKick from a bootable floppy disk's Startup-Sequence, does not work. For reasons unknown to me, the Kickstart always seems to enter a crash loop after the reboot.

Eventually, I gave up the boot floppy approach and took a very unorthodox route. First, I used AmigaOS 3.9 to partition the hard-drive and format the SFS partitions, the same way described in the previous section.

I did not install AmigaOS 3.9 on the hard drive. Directly after formatting the partitions, I copied BlizKick and the 3.1 Kickstart ROM to the first hard-drive partition. I created a very basic Startup-Sequence that only does the following:

BlizKick CPUCARD KICKFILE DEVS:Kickstarts/kick40068.A4000

After rebooting the machine from the hard-drive I noticed that it had successfully soft kicked into Kickstart 3.1.

Then I booted from the Workbench 3.1 install disk to install the Workbench on the hard drive. The Workbench installation procedure is straight forward and self explanatory.

After the completing the Workbench installation, the old Startup-Sequence gets overridden. To allow the machine to soft kick into Kickstart 3.1 on the next reboots/power ups, I have added the following code fragment to the beginning of the hard drive's Startup-Sequence:

C:Version >NIL:

If NOT $Kickstart EQ "40.68"
    SYS:Programs/BlizKick/BlizKick CPUCARD KICKFILE DEVS:Kickstarts/kick40068.A4000 QUIET
EndIf

The above code fragment extends the previous example with a Kickstart version check: it checks whether the current kickstart version is 40.68 (the internal version number for the 3.1 kickstart release that we want to use) and only invokes BlizKick when this is not the case.

On a real Amiga 4000, this check is redundant -- BlizKick also checks whether the desired Kickstart version was soft kicked already. However, I also want to have the ability to put the Compact Flash card in my PC's card reader so that I can use it with FS-UAE. In FS-UAE, BlizKick is unable to determine that it had soft kicked already, causing the emulated machine to run in an infinite loop without this check.

Patching the Kickstart to use an updated SCSI driver

As I have already explained, one of the benefits of the 3.9 Kickstart ROM is that it includes an updated SCSI driver that is not limited by a maximum hard drive size of 4 GiB.

When booting my Workbench 3.1 configuration (that also soft kicks Kickstart 3.1), I have noticed that I was constrained by the 4 GiB limit again -- aside from the first partition, the remainder of the partitions were no longer visible.

To escape this 4 GiB limitation, I have installed the Install-SCSI package from Aminet. This package extracts the SCSI driver from the Kickstart, patches it with new features (such as the ability to use partitions larger than 4 GiB), and modifies the Startup-Sequence to patch the Kickstart to use the updated driver on startup. As long as the boot partition is below the 4 GiB limit, this approach works.

Result

Although I had to take a very unorthodox route, I am happy about the result. The following pictures demonstrate my Workbench 3.1 (on Kickstart 3.1) experience:

Similar to my AmigaOS 3.9, I can use both the AGA chipset (shown on the left) and the RTG card (shown on the right) to render the Workbench screen.

Using the Amiga 4000

After producing clean AmigaOS 3.1 and 3.9 configurations, I have been playing around with quite a few applications and games.

For example, when using Brilliance, a painting program, I can instantly see that AGA graphics are an improvement over ECS/OCS graphics:

The above picture shows an 256 color example picture that is included with Brilliance. Apart from using 256 colors, it can also use a high-resolution, interlaced screen mode (providing a resolution of 640x512). In comparison, an Amiga 500 can only use 32 colors (or the extra-half brite and HAM modes) in low resolution modes. In high resolution mode, it can only display 16 colors.

AGA games are also typically much more colorful, such as Pinball Fantasies (AGA version), Soccer Kid (AGA version) and Slamtilt:

Earlier in this blog post, I have mentioned that when Wolfenstein 3D and Doom were launched for the IBM PC and compatibles, the Commodore Amiga had no good answer. Not being able to catch up partially contributed to its demise.

After the source code of these games were released, these games were eventually ported to the Amiga (AmiWolf was released in 2013 and ADoom in 1997):

On my Amiga 4000, these games do not render extremely fast, but they are playable. I believe that the Doom gaming experience on early 80386 PCs was not particularly fast either.

I also tried a demo (Closer by CNCD) that was designed specifically for the Amiga 4000 showing me 3D animations:

The Cybervision 64/3D RTG card opens up even more possibilities. A higher resolution screen makes it possible for me to more conveniently use productivity software, such as FinalWriter and Deluxe Music:

Painting can also be done in high resolution, true-color modes with TVPaint:

One particular program I am still quite impressed with is LightWave. Although LightWave even works on an Amiga 500 (albeit with many limitations), having a much faster machine with an FPU at my disposal makes it much more usable:

In combination with my RTG card I can also render a scene at a much higher resolution, with more colors:

I must admit that the above rendered picture still looks nice today.

How does the Amiga 4000 experience compare to the Amiga 500?

As I have explained earlier, I have intensively used my Amiga 500 for years, but I have not used an Amiga 4000 much, so it is still (sort of) a new experience to me.

I have to say that the experience in the last couple of weeks was nice -- it was nice to explore the enhanced capabilities of the Amiga 4000 and the applications that use it:

• A faster CPU makes many applications much more responsive, which makes you as a user more productive. For example, FinalWriter and DeluxeMusic also work fine on my Amiga 500, but it sometimes takes a couple of seconds to render a page of a document or sheet music. On an Amiga 4000 these pages render almost instantly.
• Some applications are much more usable, such as LightWave. More abilities open up because of the machine's speed and the presence of an FPU. Although the non-floating point aspects of LightWave even work on an Amiga 500, it is too slow and limited to do anything useful.
• There are AGA games that look nice.
• There are some really nice demos using the enhanced capabilities of the Amiga 4000.
• With an RTG card you can do advanced, high resolution, true-color graphics. I am particularly impressed by the images that I can produce with LightWave in combination with a RTG card. With an RTG card, I have the feeling that the Amiga 4000 is still on par with PCs in the early 90s.

Although it is nice to have more power and new abilities, I do not want to claim that my Amiga 4000 experience is significantly better than my Amiga 500 experience.

For quite a few of my use cases an Amiga 4000 is "overkill" -- most of the software that I am interested in were developed for the Amiga 500, because that was the most popular Amiga model, despite being a lesser capable machine.

On my Amiga 4000, I still mostly use the same applications that also work fine on an Amiga 500, such as DirectoryOpus, Cygnus Editor, AMOS Professional, and ProTracker. Moreover, most of my favourite games were OCS/ECS-compatible games.

Furthermore, there are some aspects of my Amiga 4000 that I consider worse compared to my Amiga 500:

• I do not have the ability to (conveniently) switch the primary floppy disk drive (the DF0: drive) with an external drive. On my Amiga 500, there is a DF0 selector switch that I can use to make the secondary disk drive the primary disk drive and vice-versa. This feature makes it possible to conveniently boot disk images from my GoTek floppy drive.
  
  As far as I know, it is not possible to have such a facility on an Amiga 4000. Some applications and games can boot from any disk drive (if you select the boot device from the Kickstart by pressing both mouse buttons on startup), but many of them will only work if you boot from DF0:.
  
  I do not want to replace the internal floppy drive from my Amiga 4000 with a GoTek. Fortunately an alternative solution exists -- I can also find WHDLoad replacements of these games so that they can be played from the hard drive.
• To my knowledge, there is also no method to use multiple ROM chips. Although soft kicking is also possible, it is still a bit disappointing to require such a complex solution.
• The Amiga 4000 is not perfectly backwards compatible with software designed for older Amiga models. There are quite a few games that crash because of an incompatibility, such as one of my favourite Amiga 500 games: Turrican.
  
  There are a variety of reasons that older applications may not work: the AGA chipset, the CPU, and the Kickstart/Workbench version are components that could introduce incompatibilities.
  
  Fortunately, the WHDLoad project has addressed many compatibility issues. WHDLoad is somewhat comparable to Virtual Machines on modern computers -- aside from the fact that it loads disk images from an hard disk and prevents the user from switching disks, it can also soft-kick more compatible kickstart versions, disable CPU caches and perform other kinds of tweaks to make a game more compatible on a certain system.
  
  For example, the WHDLoad-version of Turrican is compatible with my Amiga 4000, because it provides all kinds of facilities/fixes to deal with incompatibilities.
• The Cybervision 64/3D is a nice graphics card for mid-90s standards, but not all software can effectively use it.

Conclusion

In this blog post, I have described the properties of my Amiga 4000, how I have installed the operating systems from scratch and my experiences using the machine.

13th annual blog reflection

Today, it is the 13th anniversary of my blog. As usual, this is a nice opportunity to reflect over last year's writings.

Similar to 2022, 2023 was not a very productive year compared to the years before -- I am still a bit in a state of recovery, because of the pressure that I was exposed to two years ago. Another reason is that a substantial amount of my spare time is spend on voluntary work for the musical society that I am a member of.

Web framework

I have been maintaining the website for the musical society for quite a few years and it is one of last applications that still use my custom web framework. Thanks to my voluntary work, I made a new feature addition to the layout framework: generating dynamic menus by using an HTML representation of a site map as a basis, such as a mobile navigation/hamburger menus and dropdown menus.

I never liked these kinds of menus very much, but they are quite commonly used. In particular, on mobile devices, a web application feels weird if it does not provide a mobile navigation menu.

The nice thing about using a site map as a basis is that web pages are still able to degrade gracefully -- when using a text-oriented browser or when JavaScript is disabled (JavaScript is mandatory to create an optimal mobile navigation menu), a web site remains usable.

Nix development

Last year, I explained that I had put my Nix development work on hold. This year, I still did not write any Nix-related blog posts, but I have picked up Nix development work again and I am much more active in the community.

I have visited NixCon 2023 and I had a great time. While I was at NixCon, I have decided to pick up my work for the experimental process management framework from where I left it behind -- I started writing RFC 163 that explains its features so that they can be integrated into the main Nixpkgs/NixOS distribution.

Writing an RFC was already on my TODO list for two years, and I always had the intention integrate the good ideas on this framework into Nixpkgs/NixOS so that the community can benefit from it.

The RFC is still being discussed and we are investigating some of the raised questions and concerns.

Research papers

I have also been sorting files on my hard drive, something that I commonly do at the end of the year. The interesting thing is that I also ran into research papers that I collected in the last sixteen years.

Since reading papers and maintaining your knowledge is quite important for researchers and not something that is easy to do, I wrote a blog post about my experiences.

Retro computing

Another area that I worked on is retro computing. I finally found the time to get all my old 8-bit Commodore machines (a Commodore 64 and 128) working in the way they should. The necessary repairs were made and I have ordered new and replacement peripherals. I wrote a blog post that shows how I have been using these 8-bit Commodore machines.

Conclusion

Next year, I intend to focus myself more on Nix development. I already have enough ideas the I am working on, so stay tuned!

The last thing I would like to say is:

HAPPY NEW YEAR!!!

Using my Commodore 64 and 128 in 2023

Two years ago, I wrote a blog post about using my Commodore Amiga 500 in 2021 after not having touched it in ten years. Although the computer was still mostly functional, some peripherals were broken.

To fix my problems, I brought it to the Home Computer Museum in Helmond for repairs.

Furthermore, I have ordered replacement peripherals so that the machine can be more conveniently used, such as a GoTek floppy emulator. The GoTek floppy emulator makes it possible to conveniently use disk images stored on an USB memory stick as a replacement for physical floppy disks.

I also briefly mentioned that I have been using my first computer: a Commodore 128 for a while. Moreover, I also have a functional Commodore 64, that used to be my third computer.

Although I have already been these 8-bit machines on a more regular basis since 2022, I was not satisfied enough yet to write about them, because there were still some open issues, such as a broken joystick cable and the unavailability of the 1541 Ultimate II cartridge. The delivery took a while because it had to be redesigned/reproduced due to chip shortages.

A couple of weeks ago, the cartridge was finally delivered. In my Christmas holiday, I finally found the time to do some more experiments and write about these old 8-bit Commodore machines.

My personal history

The Commodore 128, that is still in my possession, originally belonged to my parents and was the first computer I was exposed to. Already as a six year old, I knew the essential BASIC commands to control it, such as requesting a disk's contents (e.g. LOAD"$",8: LIST), loading programs from tape and disk (e.g. LOAD, LOAD"*",8,1) and running programs (RUN).

One of my favorite games was the Commodore 64 version of Teenage Mutant Ninja Turtles developed by Ultra Software, as can be seen in the above screenshot.

I liked the game very much because I was a fan of the TV show, but it was also quite buggy and notoriously difficult. Some parts of the game were as good as impossible to finish. As a result, I was never able to complete the game, despite having played it for many hours.

Many relatives of mine used to have an 8-bit Commodore machine. A cousin and uncle used to own a Commodore 64C, and another uncle owned a Commodore 128. We used to exchange ideas and software quite a lot.

At first, I did not know that a Commodore 128 was a more capable machine than an ordinary Commodore 64. My parents used to call it a Commodore 64, and for quite some time I did not know any better.

The main reason behind the confusion is that a Commodore 128 is nearly 100% backwards compatible with a Commodore 64 -- it contains the same kinds of chips and it offers a so-called Commodore 64 mode.

You can switch to Commodore 64 mode by holding the Commodore logo key on bootup or by typing: GO64 on the command prompt. When a utility cartridge is inserted, the machine always boots in Commodore 64 mode. The picture above shows my Commodore 128 running in Commodore 64 mode.

At the time, we had a utility cartridge inserted into the cartridge socket that offered fast loading, preventing us from seeing the Commodore 128 mode altogether. Moreover, with the exception of the standard software that was bundled with the machine, we only had Commodore 64 software at our disposal.

In 1992, I wrote my first BASIC program. The program was very simple -- it changes the colors of the text, screen and screen border, asks somebody to provide his name and then outputs a greeting.

At some point, by accident, the utility cartridge was removed and I discovered the Commodore 128 mode, as can be seen in the picture above. I learned that the Commodore 128 ROM had a more advanced BASIC version that, for example, also allows you to play music with the PLAY command.

I also discovered the CP/M disk that was included with the machine and tried it a few times. It looked interesting (as can be seen in the picture above) but I had no applications for it, so I had no idea what to do with it. :)

I liked the Commodore 128 features very much, but not long after my discovery, my parents bought a Commodore Amiga 500 and gave the Commodore 128 to another uncle. All my relatives that used to have an 8-bit Commodore machine already made the switch to the Amiga, and we were the last to make the transition.

Although switching to a next generation machine may sound exciting, I felt disappointed. In the last year that the Commodore 128 was still our main machine, I learned so much, and I did not like it that I was no longer be able to use the machine and learn more about my discoveries. Fortunately, I could still play with the old Commodore 128 once in a while when we visited that uncle that we gave the machine to.

Some time later, in late 1993, my parents gave me a Commodore 64 (the old fashioned breadbin model) that they found at a garage sale (as shown in the picture above). This was the third computer model that I was exposed to and the first computer that was truly mine, because I did not have to share it with my parents and brother. This machine gave me my second 8-bit Commodore experience, and I have been using this old machine for quite some time, until mid-1997.

Originally, the Commodore 64 did not come with any additional peripherals. It was just the computer with a cassette drive and no utility cartridges for fast loading. I had a cassette with some games and a fast loading program that was the first program on the tape. Nothing more. :)

I was given a few books and I picked up Commodore 64 programming again. In the following years, I learned much more about programming and the capabilities of the Commodore 64, such as for-loops, how to do I/O, how to render sprites and re-program characters.

I have also been playing around with audio, but my sound and music skills were far too limited to do anything that makes sense. Moreover, I did quite a few interesting attempts to create games, but nothing truly usable came out of it. :)

In 1994, I bought a 1541 disk drive and several utility cartridges at a garage sale, such as the Final Cartridge (shown above). The Final Cartridge provides all kinds of useful features, such as fast loading and the ability to interrupt the machine and inspect its memory with a monitor.

Owning a disk drive also allowed me to make copies of the games that I used to play on my parents' Commodore 128.

Eventually, in 1998 I switched to the Commodore Amiga 500 as my personal machine, but I kept my Commodore 64. In 1998, Commodore was already out of business for four years and completely lost its relevance. My parents bought a PC in 1996. After using the Amiga for a while on the attic, the Amiga's display broke rendering it unusable. In 1998, I discovered how to attach the Amiga to a TV.

In late 1999, I was finally able to buy my own PC. I kept the Amiga 500, because I still considered it a cool machine.

Several years later, the Commodore 128 was returned to me. My uncle no longer had any use for it and was considering to throw it away. Because I still remembered its unique features (compared to a regular Commodore 64), I have decided to take it back.

Some facts

Why is the Commodore 64 such an interesting machine? Besides the fact that it was the first machine that I truly owned, it has also been listed in the Guinness World Records as the highest-selling single computer model of all time.

Moreover, it also has interesting capabilities, such as:

• 64 KiB of RAM. This may not sound very impressive for nowadays' standards (for example, my current desktop PC has 64 GiB of RAM, a million times as much :) ), but in 1982 this used to be a huge amount.
• A 6510 CPU, which is a modified 6502 CPU that has an 8-bit I/O port added. On machines with a PAL display, it runs at a clock speed slightly under 1 MHz.
  Compared to modern CPUs, this may not sound impressive (a single core of my current CPU runs at 3.7 GHz :) ), but in the 80s the CPU was quite good -- it was cheap and very efficient.
  
  Despite the fact that there were competing CPUs at the time that ran at higher clock speeds, most 6502 instructions only take a few cycles and fetch the next instruction from memory while the previous instruction is still in execution. As a result, it was still a contender to most of its competitors that ran at higher clock speeds.
• A nice video chip: the VIC chip. It supports 16 preconfigured colors and various screen modes, including high resolution screen modes that can be used for addressing pixels. It also supports eight hardware managed sprites -- movable objects directly controlled by the video chip.
• A nice sound chip: the SID chip. It offers three audio channels, four kinds of waveforms (triangle, sawtooth, squarewave and white noise) and analog mixing. This may not sound impressive, but at the time, the fact that the three audio channels can be used to mix waveforms arbitrarily was a very powerful capability.
• An operating system using a BASIC programming language interpreter (Commodore BASIC v2) as a shell. In the 70s and 80s, BASIC was a very popular programming language due to its simplicity.

Other interesting capabilities of the Commodore 64 were:

• The RAM is shared between the CPU and other chips, such as the VIC and SID. As a result, the CPU is offloaded to do calculation work only.
• The CPU's clock speed is aligned with the video beam. The screen updates 50 times per second and the screen is rendered from top to bottom, left to right. Each screen block takes two cpu cycles to render.
  
  These properties make it possible to change the screen while it is rendered (a technique called racing the beam). For example, while the screen is drawn, it is possible to adjust the colors in color RAM, multiplexing sprites (by default you can only configure eight sprites), changing screen modes (e.g. from text to high res etc).
  
  For example, the following screenshot of a computer game called: Mayhem in Monsterland demonstrates what is possible by "racing the beam". In the intro screen (that uses multi-color bitmap mode), we can clearly see more colors per scanline than three unique colors and a background color per 8x8 block, that is normally only possible in this screen mode:
  
  
  
• And of course, the Commodore 64 has a huge collection games and applications.

The Commodore 128 has similar kinds of chips (as a result, it is nearly 100% compatible with the Commodore 64).

It has the following changes and additions:

• Double the amount of RAM: 128 KiB
• A second video chip: the VDC chip, that can render 80-column text and higher resolution graphics, but no sprites. To render 80-column output, you need to connect an RGBI cable to a monitor that is capable of displaying 80-column graphics. The VDC chip does not work with a TV screen.
• A CPU that is twice as fast: the 8502, but entirely backwards compatible with the 6510. However, if you use the VIC chip for rendering graphics (40 column mode) the chip still runs at half its speed, which is the same as the ordinary 6510. In 80-column mode or when the screen is disabled, it runs at twice the speed of a 6510.
• A second CPU: the Zilog Z80. This CPU is used after booting the machine in CP/M mode from the CP/M boot disk.
• An improved BASIC interpreter that supports many more features: Commodore BASIC v7.0

Using the Commodore machines

To conveniently use the Commodore machines in 2023, I have made a couple of repairs and I have ordered new peripherals.

Power supplies

I bought new power supplies. I learned that it is not safe to use the original Commodore 64 power supply as it gets older -- it may damage your motherboard and chips:

In a nutshell, the voltage regulator on the 5 volt DC output tends to fail in such a way that it lets a voltage spike go straight to your C64 motherboard, frying the precious chips.

Fortunately, modern replacement power supplies exist. I bought one from: c64lover.com that seems to work just fine.

I also bought a replacement power supply for the Commodore 128 from Keelog. The original Commodore 128 power supply is more robust than the Commodore 64 power supply, but I still want some extra safety.

Cassette drive

As I have already explained, my Commodore 64 breadbin model only included a cassette drive. I still have that cassette drive (as shown in the picture above), but after obtaining a 1541 disk drive, I never used it again.

Two years ago, I ordered an SD2IEC that included a bonus cassette with a game: Hi-Score. I wanted to try the game, but it turned out there was a problem with the cassette drive -- it seems to spin irregularly.

After a brief investigation I learned that the drive belt was in a bad condition. I have ordered a replacement belt from Ebay. Installing it was easy, and the game works great:

Disk drives

I have two disk drives. As I have already explained, I have a 1541 drive that I bought from a garage sale for my Commodore 64. The pictures above show the exterior and interior of the disk drive.

The disk drive still works, but I had a few subtle problems with running modern demos that concurrently load data while playing the demo. Such demos would sometimes fail (crash or the sound starts to run out of sync with the rest of the demo), because of timing problems.

I have cleaned the disk drive head with some alcohol and that seemed to improve the situation.

I also have a 1571 disk drive that came with the Commodore 128. The 1571 disk drive is a more advanced disk drive, that is largely backwards compatible with the 1541. The pictures above show the exterior and interior of the drive.

In addition to ordinary Commodore 64 disks, it can also read both sides of a floppy disk at the same time and use disks that are formatted to be as such. It can also run in MPM mode to read CP/M floppy disks.

My 1571 disk drive still seems to work fine. The main reason why I did not have to clean it is because I have not used it as much as the 1541 disk drive.

The 1541 and 1571 disk drives are interesting devices. They are computer systems themselves -- each of them contains two embedded machines each having their own 6502 CPUs. One sub system is responsible for managing filesystem operations and the communication with the main computer, while the other sub system is used for controlling the drive.

The 1541 disk drive contains 2 KiB of RAM and runs its own software from a ROM chip that provides the Commodore Disk Operating System.

Technically, using a disk drive on an 8-bit Commodore machine is the same as two computer systems communicating with each other over Commodore's proprietary serial interface (the IEC).

Monitor

I also have a monitor for the Commodore 128 machine: the Commodore 1901 that is capable of displaying graphics in 40 and 80 column modes. It has an RGBI socket for 80-column graphics and RCA sockets for 40-column graphics. I need to use a switch on the front panel to switch between the 40 and 80 column graphics modes. In the picture shown above, I have switched the monitor to 80-column mode.

The monitor still works fine, but in 2019 a capacitor burned out, causing smoke to come out of the monitor, which was a scary experience.

Fortunately, the monitor was not irreparably damaged and the home computer museum managed to replace the broken capacitors. After it was returned to me, it seems to work just fine again.

In 1992, besides "The Very First": a programming tutorial and CP/M, I did not have any software for the Commodore 128. In the recent years I have downloaded a few interesting applications for the Commodore 128, such as a Tetris game that works in 80-column mode:

Joysticks

As already shown in earlier pictures, I am using The Arcade joysticks produced by Suzo International. I have four of them.

Unfortunately, three of them did not work properly anymore because their cables were damaged. I have managed to have them repaired by using this cable from the Amiga shop as a replacement.

Mouse

The Commodore 128 also came with a 1351 mouse (a.k.a. tank mouse), but it was lost. I never used a mouse much, except for GEOS: a graphical operating system.

To get that GEOS experience back, I first bought an adapter device that allows you to use a PS/2 mouse as a 1351 mouse. Later, I found the same 1351 mouse model on Ebay:

SD2IEC

I have also been looking into more convenient ways to use software that I have downloaded from the Internet. Transferring downloaded disk images from and to physical floppy disks is possible, but quite inconvenient.

The SD2IEC is a nice modern replacement for a 1541 disk drive -- it is cheap, it can be attached to the IEC port and all high-level disk commands seem to be compatible. Physically, it also looks quite nice:

As can be seen it the picture above, it looks very similar to an ordinary 1541 disk drive.

Unfortunately, low-level disk-drive operations are not supported -- some applications need to carry out low-level operations for fast loading, such as demos.

Nonetheless, the SD2IEC is still a great solution, because there are plenty of applications and games that do not require any fast loading capabilities.

1541 Ultimate II cartridge

After happily using the SD2IEC for a while, I wanted better compatibility with the 1541 disk drive. For example, many modern demos are not compatible, and I do not have enough physical floppy disks to store these demos on.

As I have already explained, this year, I have ordered the 1541 Ultimate II cartridge, but it took a while before it could be delivered.

The 1541 Ultimate II cartridge is an impressive device -- it can be attached to the IEC port and the tape port (by using a tape adapter) and provides many interesting features, such as:

• It can cycle-exact emulate two 1541 disk drives
• It offers two emulated SID chips
• It can load cartridge images
• It simulates disk drive sounds
• You can attach up to two USB storage devices. You can load disk images and tape images, but you can also address files from the file system directly.
• It has an ethernet adapter.

The above two pictures demonstrate how the cartridge works and how it is attached to the Commodore 64.

I am very happy that I was able to run many modern demos developed by the Demoscene community, such as: Comaland by Oxyron and Next level by Performers etc. on a real Commodore 64 without using physical floppy disks:

UPDATE June 2024: I learned that it is also possible to use the 1541 Ultimate II cartridge in CP/M mode on the Commodore 128. Previously, I have noticed that it is possible to boot a CP/M disk image on a Commodore 128. However, in CP/M mode, the computer freezes when you press the menu button on the cartridge making it impossible for me to switch disk images.

To cope with this problem, it is also seems to be possible to control the cartridge with a special piece of software called: CPMUTools. By enabling the command-interface and the RAM extension with 16 MiB of RAM, it is possible to mount floppy disks by using a CP/M program called UMOUNT and integrate with the operating system configuration (such as the clock) with a tool called UCONFIG.

To conveniently use CP/M with the 1541 Ultimate cartridge, I enable a secondary simulated 1581 disk drive (B drive) that I use to mount the CPMUTools disk to. In CP/M, I can start the disk utility as follows:

B:
UMOUNT

showing me the following program allowing me to pick disk images:

By using CPMUTools, it has become possible for me to try out CP/M software on a real Commodore 128, such as Turbo Pascal, something that I have not been able to do in the last thirty years:

ZoomFloppy

Sometimes I also want to transfer data from my PC to physical floppy disks and vice versa.

For example, a couple of years ago, I wanted to make a backup of the programs that I wrote when I was young.

In 2014, I have ordered a ZoomFloppy device to make this possible.

ZoomFloppy is a device that offers an IEC socket to which a Commodore disk drive can be connected. As I have already explained, Commodore disk drives are self-contained computers. As a result, linking to the disk drive directly suffices.

The ZoomFloppy device can be connected to a PC through the USB port:

The above picture shows how my 1541 disk drived is connected to my ThinkPad laptop by using the ZoomFloppy device. If you carefully look at the screen, I have requested an overview of the content of the disk that is currently in the drive.

I use OpenCBM on my Linux machine to carry out disk operations. Although graphical shells exist (for example, the OpenCBM project provides a graphical shell for Windows called: cbm4wingui), I have been using command-line instructions. They may look scary, but I learned them quite quickly.

Here are some command-line instructions that I use frequently:

Request the status of the disk drive:

$ cbmctrl status 8
73,speeddos 2.7 1541,00,00

Format a floppy disk (with label: mydisk and id: aa):

$ cbmformat 8 "mydisk,aa"

Transfer a disk image's contents (mydisk.d64) to the floppy disk in the drive:

$ d64copy mydisk.d64 8

Make a D64 disk image (mydisk.d64) from the disk in the drive:

$ d64copy 8 mydisk.d64

Request and display the directory contents of a floppy:

$ cbmctrl dir 8

Transfer a file (myfile) from floppy disk to PC:

$ cbmcopy --read 8 myfile

Transfer a file (myfile) from PC to floppy disk:

$ cbmcopy --write 8 myfile

Conclusion

In this blog post, I have explained how I have been using my old 8-bit Commodore 64 and 128 machines in 2023. I made some repairs and I have ordered some replacement peripherals. With these new peripherals I can conveniently run software that I have downloaded from the Internet.