A quick and dirty emulator for Usagi Electric's homebrew computer using the TI-TMS9900 cpu.
The CPU emulation and a some ancillary files are taken from the js99er project by Rasmus Moustgaard.
Assembler and linker. Compile and run fine under linux. Some small changed needed to compile under modern windows, find them in this repo's history.
Assembler and linker disagree on object files being binary or text with respect to linefeeds. Changes applied in this repo.
After these changes Linux and Windows results are identical.
Linker only outputs a.out format... Simple programs can just have the 16 bytes of header ripped off, but this seems to fail for more complex programs.
We suspect there is a bug in the a.out format when using AORG statements, they are not in the right place, but I wonder if it is something more complex about a.out format.
These tools are written in python. The -b option generates binary images suitable for direct use as roms. (They still must be split into low and high byte roms for Usagi's homebrew).
RORG, AORG and DORG all seem to work properly.
I think this is the better solution for assembly programs
I took The docker image from Chris Cureau and slightly modernized it. You can find it here.
His repo was missing the actual patches from the AtariAge forum, and was using a base Centos image so old the yum steps faild when building. Make was also segfaulting sometimes for no reasona at all.
If you are not using Docker or Podman or something it's time to learn that skill. The entire gcc & binutils compile happens in a container (kind of like a VM) and none of the mess leaks out into your real computer. The same is true when you run it, source goes in, results come out, nothing gross happens.
Updates at https://github.com/mburkley/tms9900-gcc
So you think the main function is where your program starts?
The example I have now is suitable for writing a C program that generates a full ROM image that can be directly loaded into Usagi's homebrew.
It describes the memory layout so that the linker can put everything in the right place. It gives names to various sections, like the familiar .text, .data and .bss, but also some special ones like .vectors and .workspace.
It does something I don't understand the syntax for, that seems to work... Your global variable are things that live in RAM, but should be initialized before the program starts. The .data section is somehow defined in RAM but with a copy stored in ROM so that it can be copied from ROM to RAM at startup. The copy is not magic, explained in the crt0.s section.
It also defines the top of the stack, at the top of actual physical ram (no virtual memory here!). Also mentioned in the next section.
This file is a small assembly program. In the .vectors section it sets up your intial on-reset workspace and PC values.
Then comes the .text section. Forget about main, _start is where your code actually starts!
The current version of this code:
- Turns off interrupts
- Sets the stack pointer (r10) to the address defined in link.ld
- Copies the initial values of globals from ROM to
.datain RAM - Zeros out the
.bsssecion in ram - Calls the
main()funciton - Loops forever when main returns
It's just C, hooray! And by just C I mean just C. You weren't expecting any libraries were you?
- If you do not
-fomit-frame-pointersit generates bad code where the stack gets clobbered during function calls. - I am not sure why it chooses R10 for the stack pointer.
- Optimizations are pretty basic. -O1 and -Os generate slightly different code.
Pretty normal.