Saturday, August 1, 2015

Technicalities

If you're porting a program from the Commodore 64 to the 128, there are some gotchas. Some are obvious, while others are more subtle. These are ones I ran into in my attempt to hack DurexForth to run on a C128.

Where Do I Start

The memory maps of the two machines are obviously different. But the C128 is more than different, it's also more complicated.

The C128 has, as the name implies, 128K of RAM. This is tricky, because 64K is all a 6502/8502 can see or address at one time. It gets more tricky because, in addition to two banks of 64K of RAM, you also need some ROM (BASIC, Kernal, characters sets, etc.). And, the 6502 chip interacts with peripherals via memory-mapping, where other chips like video and I/O appear as part of the 6502 memory space. That's a lot of stuff to cram into a virtual 64K area.

The complexity of this is probably beyond the scope of this post, but there's one question that you'd always need to ask - where in memory should I start my own program? On the Commodore 64, that's at hexadecimal 0801 ($0801). On the Commodore 128, it's $1C01. This change is required anywhere that the starting address of the program is specified.

DurexForth makes use of a popular trick where the first few bytes of code are, in fact, a BASIC line with a single SYS call to the real start of the program. So to fix the start point, not only do you need to change where your program starts, but you need to change the text of the SYS command to call the correct new location in memory.

You Can Take That to the Bank

Like the C64, the C128 has some built-in Kernal routines for loading a file from disk into memory. Unlike the C64, the C128 has various banks of RAM. Before you load a file, you need to tell the C128 what bank the filename is located in, and what bank the file should be loaded into. You do this with the SETBNK kernal call. If you don't do it, sometimes your file goes nowhere, or goes into limbo, as happened with me.

Don't POKE Me There

Controlling the RAM/ROM layout of the C128 is done with some memory configuration registers starting at location $FF00. On the Commodore 64, it's done with some manipulation of the ports at $0000 and $0001. DurexForth had some references to the C64 memory control locations, and I needed to take those out, lest anything weird happen.

A More BASIC Problem

The reason DurexForth messed with the C64 memory layout was to bring BASIC back into view sometimes to call routines within the BASIC ROM. That's fine on a C64, but BASIC on the C128 takes up a gigantic chunk of memory space right in the middle of everything. Therefore, rather than try to bring C128 BASIC in for these tasks (e.g., reading a user input line into a RAM buffer), I rewrote the tasks in straight assembler.

Just In Case

Finally, some niceties I had to deal with including setting colors and changing to lowercase mode. This is also done differently on the C128, with just a simple character print, whereas on the C64, it's another POKE.

These are some of my learnings, and as I progress, I'm sure there will be more. This is actually a lot of fun, and is one of the reasons I love retro computers. They are simple, and with effort, you can become highly proficient in just about every aspect of a machine.

That's it for my Retrochallenge-related blogging. However, stay tuned for more entries here, because my work with Forth128 has just begun.

4 comments:

  1. Hi Earl,

    This looks like a really cool project and I would love to use it once you have it finished. I started to learn Forth on the TI-99/4a but sort of got sidetracked. I'd love to pick it back up again and I think it would be really fun to do that on my C128.

    Keep up the good work!

    ReplyDelete
  2. Shocking that the C128 never got a Forth port back in the day. Have you been able to rectify this huge historical anomaly? Any thought to making it a 32K ROM-able image for the function ROM socket?

    ReplyDelete
  3. Making it a C128 ROM image would be really fun. Not sure who I'd get to burn ROMs for it, though. I'll try to ensure the code can be placed at the applicable ROM addresses. Thanks for that idea!

    ReplyDelete
  4. Hi Earl, is the work published anywhere? Would probably be interesting for many. Thanks!

    ReplyDelete