BASIC is a relatively straightforward imperative language, so adapting the control flow is relatively simple. Constant data arrays can just be baked into the ROM with db statements. GOTO is just an unconditional jump. GOSUB/RETURN are just normal instructions for almost any processor.* And IF/ELSE/FOR are just different flavors of a conditional branch. Reorganizing the code is largely unnecessary, except for legibility.
Of course, how many assembly instructions correlate to one line of BASIC varies wildly. Something like 690 o = 1 is still a one-liner in F8 assembly, while something like 610 on j-1 goto 615,625,625,635,635 requires baking a jump table into the rom, multiple instructions to load the address from it, and then doing the jump, which is probably 10 lines of assembly, at least. (I can’t remember what line tripped me up, but it might (maybe) have been that one, actually.)
* On the F8, they are actually much less normal than you’d want, but for simple programs it’s not too much of an issue.
The Channel F has a rudimentary, low-resolution/low-bitdepth framebuffer (write-only). One interesting thing about it is that one of the offscreen columns is used to provide row attributes: you can either have a row be in color (with a choice of three different backdrop colors), or have a row be in black and white.
My main thought with this is that you could force the rows the player is not on to be monochrome, creating the impression of darkness. Perhaps some trickery could be done with the loss of color information as well — maybe the map could come with some hazards pre-marked (e.g. pits), but also have some red herrings (e.g. harmless boulders). The player could place markers on the map at suspicious places. Each of the obstacles would look identical without color, so part of the cognitive load would be keeping track of what is what (and perhaps also dealing with the bat switching things on harder difficulties).
Anyhow, thinking about this made me feel like whipping up a simple mockup:
With the system using a frame-buffer, it would also be quite trivial to have the maze be revealed in a fog-of-war style like an RTS, rather than having the whole maze revealed from the start, like this perhaps:
(Another completely different idea would be to have it be largely faithful to the original game, but presented as a rudimentary first-person dungeon crawler, but that seems like an idea that’s probably been done before already.)
You could simply declare ASCII text strings in the assembly like dc "TEXT", though one caveat is that the assembler did not automatically null-terminate the strings, so if you wanted to encode your strings that way you’d have to type it like dc "TEXT", 0. (I guess you could also manually encode your strings like Pascal strings (length then text, with no terminator), but that would use up an extra register for counting.)
The string function wasn’t too weird — load a letter, bail if we ran into a \0, adjust the ASCII code to match the internal table (subtract by some constant), call the blit function, increment the x position by 6, and then repeat. IIRC, the blit function was interesting because it modified the x and y positions while drawing, so it had to reset those back to their original position at the end of each call. Oh, and since the blit function I used was 1 bit-per-pixel, it took an argument to specify the FG/BG colors, so by extension the print string function took the same arguments as well.
The graphics themselves were 1 bit-per-pixel bitmaps, with the rows bitpacked together. A weird optimization I had considered was to have the letters be 5x5 pixels (25 bits), but pack them into 3 bytes (instead of 4) by having the bottom-right pixel of each character take from the top-left pixel of the next. I’m pretty sure I labbed it out as being possible at one point, but it looks like I was using a 5x6 pixel font, so I don’t think I was that desperate for space.
Most commercial Channel F games were only 2K, though back in the day that was fairly common. Most early Atari 2600 games were also 2K, with only later releases upgrading to 4K and beyond. There are a handful of Channel F games that are 3K or 4K or even 6K, but ultimately the relative lack of larger titles of more expert craftsmanship was due to the system’s failure in the marketplace (I rambled a bit about this point here).
(Speaking of the 2600, it’s funny that the 2600 can only have 4 KB carts before needing to resort to bankswitching, while the Channel F has a full 64 KB address space that it could work with, in theory.)
The real memory limitation with the Channel F is actually the RAM — it has none. Instead, it has a scratchpad of 64 registers (1 byte each) inside the processor itself. A register known as the ISAR (indirect scratchpad access register) allows indirection to be applied to the scratchpad (though it has some odd quirks). Some carts have a healthy amount of built-in RAM, though the instructions and semantics for reading from the scratchpad and actual memory are entirely different things.
Slightly musty and sweaty, with a strong undercurrent of pleasant wet earth, and an inexplicable hint of citrus.
Random thought: I think it’s fairly likely that the Grue in Zork and the bat in Atari’s Adventure both stem from this game.