Experimenting with TG68

Part 8 – Timers and C code

Having successfully uploaded an S-record program over RS232 last time, I’ve since followed the helpful instructions in Christian Vogelgsang’s Chameleon Minimig repo for setting up a cross-compilation toolchain.  I’m now able to build C software for this project, which in the absence of a more imaginative name, I’m coming to think of as “MiniSOC”.

(In fact, I haven’t used newlib – and nor did Christian in the finish – instead we’ve drawn from klibc, just cherry-picking the routines needed for the task at hand.  There are also a couple of other dependencies for building GCC – gmp, mpfr and mpc, which are a stack of libraries for handling multi-precision arithmetic.)

Since I’m not familiar with the syntax used by GCC’s assembler (which is very unlike the “normal” Motorola syntax) I also used VASM to build assembly components to Elf format, then the cross-compiled objdump to create S-records from the final project.

I also used srec_cat, as before, to create .mif files from the lowest-level startup file, which ends up in an M4K.

The biggest change hardware-wise this time round is the addition of some timers.  There are now eight in total, two of which directly divide the system clock, and the other six divide the output of the first timer.  Three of those run in continuous mode, and three run as one-shot timers.

An event on any of those six timers will trigger an interrupt, and the one timer I haven’t yet mentioned will eventually be used to provide an SPI clock when I implement SD card access.

The firmware file CFirmware/out.srec contains basically the same graphics demo as previous builds, implemented in assembler, but with the housekeeping and keyboard/mouse drivers in C.  One of the one-shot timers is used to provide a mouse time-out, so the project will still run even if there’s no mouse connected.

Thanks to code borrowed from klibc, the FrameBuffer’s address is no longer hardcoded, and instead is malloc()ed.  Since there’s no operating system to provide memory blocks to the malloc arena, I’ve added a routine to add a hardcoded block of memory for use by malloc().  The actual bounds of that block are specified by the GCC linker script.  This allows me to hardcode the upper bound to match the hardware, but have the lower bound automatically set immediately above the region occupied by the firmware itself.

This version has a keyboard driver, too – incomplete but functional enough that what you type ends up on screen.  Mouse buttons are also detected, and will cause the colours to cycle more rapidly.

Full source and binaries can be found here.

Leave a Reply

Your email address will not be published.