Experimental build for Mac OS X available

I am sharing an initial experimental build for Mac OS X of one of my GTK+ applications, C64 Raster Effect Editor.

C64 Raster Effect Editor: experimental build for Mac OS X by Luigi Di Fraia
C64 Raster Effect Editor: experimental build for Mac OS X

It comes as a DMG file but it appears that install_name_tool, which I use to bundle the application and its dependencies, corrupts one of the dependencies thus impairing the creation of GdkPixbuf from XPM data at execution time.
In fact, before GTK+ libraries go through install_name_tool, everything is working as expected, including the creation of GdkPixbuf. Unfortunately this means that PETSCII artwork cannot be loaded into the application.

Here’s a link to download the bundle.

If there’s any interest, I am going to look further into releasing my GTK+ apps for Mac OS X in the not too distant future. Therefore, leave a comment if you are interested!

Posted in Retrocomputing, Technical | Tagged , , , , | Leave a comment

C64 Cartridge Dumper: hardware version 2 testing

Today I finally managed to assemble one of the new C64 Cartridge Dumper devices I had re-designed a while back to use a Pro-Micro. I had the PCB manufactured weeks ago, but due to job-related commitments I never got around to building one of the new devices.

C64 Cartridge Dumper: hardware version 2 by Luigi Di Fraia
C64 Cartridge Dumper: hardware version 2

Well, the good news is that I tested the device with what I understand to be an Ultimax cartridge, Jupyter Lander, and it worked fine.
In fact, I was nervous about the fact that the data bus wiring is a bit awkward:

  • Bit 0 is PD3
  • Bit 1 is PD2
  • Bit 2 is PD1
  • Bit 3 id PD0
  • Bit 4 is PD4
  • Bit 5 is PD7
  • Bit 6 is PB4
  • Bit 7 is PB5

As you can appreciate, an 8-bit value read from the data bus has to be read from two different ports (PORT D and Port B) and bit values have to be shifted into position. A similar wrangling has to occur when writing a value to the data bus, for bank switching purposes.

The reason I went with a more complicated firmware, compared to the breadboard prototype I had used to develop the firmware, is that the PCB routing is much simpler 🙂

The next thing I did was to check whether using a 5V MCU instead of a 3.3V one makes any difference when driving the bank switching circuitry for gmod2 cartridges. Luckily, Andy had lent me his copy of “It’s Magic II” a while back, so I have material to test.

I was indeed able to appreciate that bank switching appears to be behaving differently with the new hardware. Here’s a comparative image, with the left side showing a bank switching taking place correctly at dumping time with the new hardware, while the right side shows a previous attempt:

C64 Cartridge Dumper: gmod2 dump comparison by Luigi Di Fraia
C64 Cartridge Dumper: gmod2 dump comparison

The bank switching logic doesn’t yet seem to be correctly driven though, as dump contents repeat at $4000.

I am starting to think that the bank switching hardware in gmod2 might require a signal edge on the Phi2 line to trigger, where I just pull it up with a resistor.
I’ll try to hack my own circuit to e.g. route IO2 to the Phi2 line and cause an edge that way. If that works for gmod2, in general I would just need a NOR port to combine IO1 and IO2 on the inputs and use its output to simulate Phi2.

Of course, if anyone knows the bank switching details for gmod2, I’d be happy to read what they have to say 🙂

Stay tuned for more!

Posted in Retrocomputing, Reverse Engineering, Technical | Tagged , , , | Leave a comment

Commodore 64 cartridges: theory of operation and Ocean bank switching described

As I mentioned before, I am rearranging my notes on Commodore 64 cartridges, especially on bank switching circuitry used by exotic cartridges (i.e. neither Normal nor Ultimax ones).

I plan to provide some schematic diagram to include in my book, but, as I had done in my article about Vorpal later, I think it’s important to understand what the problem is, rather than simply providing the schematics of the hardware that solves the problem. Furthermore, as I did in my article about sync signals available in Commodore disk drives, I plan to provide hardware information and relevant registers, side by side.

Let’s get into it.

We know that when either 8KiB or 16KiB of external EPROM/EEPROM are provided by a Normal or Ultimax cartridge, the Commodore 64 can map each 8KiB segment to one of the memory ranges $8000-$9FFF, $A000-$BFFF, or $E000-$FFFF.
Not just any combination is allowed, but what’s really important is that the Commodore 64 can only map one 8KiB segment of external memory to $8000, $A000, or $E000, and it can only map a 16KiB segment of external memory to base address $8000.

You might want to refer to this post on World of Jani for the values of /GAME and /EXROM used by Normal and Ultimax cartridges. The Commodore 64 Programmer’s Reference guide also provides a table with relevant information.

Here’s a summary:

  • /EXROM = 1 and /GAME = 0 (Ultimax mode)

    /ROML optionally enables the mapping of 8KiB to $8000 and
    /ROMH enables the mapping of 8KiB to $E000

  • /EXROM = 0 and /GAME = 1

    /ROML enables the mapping of 8KiB to $8000

  • /EXROM = 0 and /GAME = 0

    For a double-chip cartridge:

    /ROML enables the mapping of 8KiB to $8000 and
    /ROMH enables the mapping of 8KiB to $A000

    For a single-chip cartridge:

    /ROML AND /ROMH enable the mapping of 16KiB to $8000

A summary of the above mentioned table is also provided below:

         LHGE   LHGE   LHGE   LHGE   LHGE
         1111   1110   0100   1100   XX01
       default                     Ultimax
---------------------------------------------
 E000                                ROMH
---------------------------------------------
 A000                  ROMH   ROMH    -
---------------------------------------------
 8000           ROML          ROML   ROML

L = /LORAM
H = /HIRAM
G = /GAME
E = /EXROM

As for registers, bits 0 and 1 at location $1 on the Commodore 64 are mapped to the /LORAM and /HIRAM signal respectively and eventually routed to /ROML and /ROMH: I will cover this in more detail in a future post on the subject.

For an 8KiB block of memory, thirteen bits of addressing are required in order to select each byte in the block itself: this is the reason only address lines A0-A12 of the address bus are connected to the memory chip in a cartridge. In fact, we can’t connect the lines A14-A15 of the Commodore 64 address bus directly to the corresponding address lines of an external memory chip, because they would select addresses in the external memory chip that are not mapped to locations that the Commodore 64 can access, being these beyond the 16KiB limit. In reality even A13 is never connected because /ROML or /ROMH are used instead to drive the corresponding line of the external memory. So I hope it’s now clear why address lines A13-A15 are not used by cartridges.

The problem is: how do we allow a Commodore 64 to access external memory chips when these are larger than 16KiB? A good quality game with a lot of graphic elements and tunes would hardly fit in just 16KiB of memory. It’s more likely that a good quality multi-level game would require 200KiB or more. We could also be wanting to use two 128KiB memory chips, or one 256KiB chip, or even a 512KiB chip.

Fortunately, although we can only map one or two 8KiB sections of external memory chips at any given time, we do have options when it comes to driving lines A13 and above of the external chip (or chips) and selecting exactly the 8KiB block (or blocks) we want to map.

The fact that we have options means that different vendors came up with different schemes for exotic cartridges.

Let’s take Ocean, for example. Their strategy was simple: use the data bus to decide the state of the lines A13 and above for the memory chip (or chips) they mounted in their cartridges. Obviously the data bus is used for reading data out of the cartridge memory, so how can we use it to set the state of lines A13 and above?
Well, as well as connecting data lines D0 and above to the memory chip for reading out its contents at a given location, the cartridge hardware also connected some of these lines to an 8-bit register (a.k.a. latch). Such register would sample and hold the value of data bus lines, presenting their state on its outputs directly connected to A13 and above, if and only if the Commodore 64 wanted to switch to a different memory bank. The Commodore 64, in the case of Ocean cartridges, uses D0 to set A13, D1 to set A14, and so on.

The next question to understand is then: how does a Commodore 64 communicate to an Ocean cartridge that it wants to perform a bank switching? Loading the data bus with the desired state of lines A13 and above is not enough; it would have to cause the latch to sample and hold. Well, looking at any Ocean cartridge circuitry, it’s pretty simple to establish that:

  • Phi2 has to be high, meaning that it’s the CPU that’s controlling the bus
  • /IO1 has to be low, meaning that the Commodore 64 is addressing a location in $DE00-$DEFF

So, in short, all the Commodore 64 has to do when it wants to switch bank is to set the value for A13 and above in bits 0 and above at e.g. $DE00; the hardware circuitry of the Commodore 64 will make sure that /IO1 is briefly pulled low at some point when Phi2 is also high. That’s exactly what the cartridge’s own circuitry is waiting for to sample and hold the value on the data bus and use it to set lines A13 and above.

This means that, as an example, for a single-chip 256KiB Ocean cartridge, we can map the bottom 8KiB to $8000 by setting $DE00 to 0. The 8KiB after these would be mapped by setting $DE00 to 1, and so on.

That’s, essentially, what the Lua script for single-chip Ocean cartridges used my Commodore 64 Cartridge Dumper does:

-- Ocean type B (single chip) dumping definition file
-- for the Commodore 64 Cartridge Dumper client
-- (C) 2019-2021 Luigi Di Fraia

-- Supported titles:
--  All Ocean titles excluding "Robocop 2", "Shadow of the Beast", and "Space Gun"

-- Bank selection circuitry uses:
--  128 KiB cartridges (all known titles): bits 0-3 at $DE00 and ROML (single 128 KiB chip with A16 on pin 22, rather than the /OE signal)
--  256 KiB cartridges (just "Chase H.Q. II"): bits 0-4 at $DE00 and ROML (single 256 KiB chip)
--  512 KiB cartridges (just "Terminator 2"):  bits 0-5 at $DE00 and ROML (single 512 KiB chip)

-- Calculate the number of 8 KiB banks to dump
local banks = size_kb / 8
local b = 0

-- Mapping is at $8000-$9FFF for all banks
assert_roml()
deassert_romh()

while b < banks do
  io_store(0xDE00, b)

  dump_chip()

  b = b + 1
end

Stay tuned for more!

Posted in Retrocomputing, Reverse Engineering, Technical | Tagged , , , | Leave a comment

TAPClean update: “Anirog” clone support added

I am still quite busy at work, but today I had a chance to finally commit my changes to TAPClean for supporting an Anirog loader clone found quite often in Polish tapes.
The difference in encoding is that the clone uses a trailing sequence, where genuine Anirog doesn’t.
From a loader code perspective, the two differ, but also have a few similarities:

  • exact same pulse threshold and use of timer,
  • similar handoff code to execute a BASIC program at the end of the load.

That’s about it for now. Stay tuned for more!

Posted in Retrocomputing, Technical | Tagged , , , , , | Leave a comment

TAPClean update: “LK Avalon loader” support added

Back in November 2020, Adam approached me on SourceForge about a tape loader not recognized by TAPClean that was used by a Polish publisher in the 90s.
Subsequently, he sent me a number of tapes from the same publisher and many others. For months I have put the task to add support in TAPClean aside, due to lack of free time, and asked Adam to keep reminding me on a regular basis, i.e. once a month.

Well, yesterday I finally decided to add support for what I refer to as “LK Avalon loader” to TAPClean.

I guess that if you have approached me with requests for TAPClean you already know this, but in case you haven’t, it might come handy: If I have no time to assist with a request, it’s best if you periodically approach me about it. As long as you are happy to wait, it might actually work out just fine 🙂

Posted in Retrocomputing, Reverse Engineering, Technical | Tagged , , , , , | 12 Comments

Update to my book on tape and disk loaders for the Commodore 64

Having come back to proof-reading my book, after a few weeks since I last added content, I felt the need to clarify what “write splices” are for disk images, before referring to them in the chapter about Vorpal.

Therefore, I added a chapter on Disk image formats, track cycle detection, and the need of identifying write splices. This content is exclusive to the book, rather than being consolidated in the book from this blog, but I have been discussing those topics here in various posts.

Tape and disk loaders for the Commodore 64 by Luigi Di Fraia
Tape and disk loaders for the Commodore 64

Stay tuned for more!

Posted in Retrocomputing, Reverse Engineering, Technical | Tagged , , , | Leave a comment

C64 Cartridge Dumper: Hardware version 2

As genuine “blue pill” boards have become difficult to source, I decided to re-design my C64 Cartridge Dumper to use a Pro-Micro instead.

Here’s a preview of the testing circuit with which I am able to dump EPROMs successfully, using the same PC-side software I wrote for earlier versions of the hardware:

C64 Cartridge Dumper: test circuit for hardware version 2 by Luigi Di Fraia
C64 Cartridge Dumper: test circuit for hardware version 2

I am thinking of adding a bonus section on cartridges to my book, for the purpose of putting down my knowledge on the subject and sharing it, before I forget low-level technical details.

Stay tuned for more!

Posted in Uncategorized | Tagged , , , | 2 Comments

The first draft of my book on Commodore 64 loaders was published

I just published the first draft of my book on Leanpub. For those not familiar with Leanpub, one of the common book lifecycles involves frequent updates, all of which come at no further charge for those who buy the book.

What will you find in the first draft? Well, this is an initial attempt to get familiar with the publishing process on Leanpub. There is content found here on my blog, but also additional annotated code from Vorpal (later), specifically the code that is used to decode custom GCR bytes on-the-fly.

So, the publication is a starting point that gets me going and motivated. As a reader, please don’t feel like you are buying an unfinished work at full price: again, you will get all future updates for free, as and when they come.

Stay tuned for more!

Posted in Retrocomputing, Reverse Engineering, Technical | Tagged , , | 2 Comments

Exploring the possibility to build my GTK+ apps for Mac OS X

It’s still early stages and I haven’t looked into the integration with the menu system in OS X, but I am at a point where I can build and run my GTK+ based applications on Mac OS X 10.15 Catalina.

Here’s a selection of screenshots, provided without further comments. Bear in mind that the spartan look is due to the default theme that I am using for my apps.

TAPClean Front End running on Mac OS X by Luigi Di Fraia
TAPClean Front End running on Mac OS X
TAPClean Front End running on Mac OS X by Luigi Di Fraia
TAPClean Front End running on Mac OS X
IECHost GUI client running on Mac OS X by Luigi Di Fraia
IECHost GUI client running on Mac OS X
IECHost GUI client running on Mac OS X by Luigi Di Fraia
IECHost GUI client running on Mac OS X
IECHost GUI client running on Mac OS X by Luigi Di Fraia
IECHost GUI client running on Mac OS X
IECHost GUI client running on Mac OS X by Luigi Di Fraia
IECHost GUI client running on Mac OS X
IECHost GUI client running on Mac OS X by Luigi Di Fraia
IECHost GUI client running on Mac OS X
C64 Raster Effect Editor running on Mac OS X by Luigi Di Fraia
C64 Raster Effect Editor running on Mac OS X
The Last Ninja Construction Kit running on Mac OS X by Luigi Di Fraia
The Last Ninja Construction Kit running on Mac OS X

One issue I am having is that by the time the application goes through changed performed by install_name_tool, it seems to be stripped of its embedded XPM logo.

Stay tuned!

Posted in Technical | Tagged , | 2 Comments

CBM Flux Studio: NIB to G64 conversion for Vorpal (later) disks

In this video I show how CBM Flux Studio can be used to convert NIB files to G64 files, ready not only to be used in a C64 emulator but also for being written back to disk.

Stay tuned for more!

Posted in Retrocomputing, Reverse Engineering, Technical | Tagged , , , , , , , , | Leave a comment