psfTo anyone who programs for the Motorola 68000, what is your favorite cross-assembler that works well on a Linux host pc?
Update: I forgot to mention that I'm targeting TI-89/TI-92+. From my research, it seems this locks me into using (tigcc or gcc4ti)/A68k, specifically because of the linking step. The underlying calculator platform has a not-entirely-trivial binary loader that may perform relocations, so symbol information must be exposed in a way it can understand.
I spent the better part of an evening trying to build a toolchain old enough to bootstrap gcc 4.1.2, without success. Good thing TIGCC's binary packages from 2006 (!) still work on a modern x86-64 linux system.
Anyway, here is hello world. It's in C not assembly, but I think that's enough progress for one night.
Hello world in assembly doesn't look much different, but you don't wanna know how many times I crashed my emulator trying (and failing) to shave a few bytes off the example program I found.
Against all judgment and taste, I am using gnu as, which is one of the two assemblers that comes tightly integrated into TIGCC. (The other is A68K, whose syntax is not meaningfully different). This means I'm saddled with AT&T syntax. and boy is that not how my brain works.
Switching back to x86 for a second for familiarity, compare:
GAS syntax
_start:
lea value, %eax # 0x40101c
mov $value, %ebx # 0x40101c
mov value, %ecx # 0x12345678
value:
.long 0x12345678, 0x12345678
NASM syntax
_start:
lea eax, value ; 0x40101c
mov ebx, value ; 0x40101c
mov ecx, [value] ; 0x12345678
value:
dd 0x12345678, 0x12345678
NASM's symmetry between the lea and first mov instruction (which resolve to the same value) makes sense to me. GAS makes no sense to me.
And that isn't even getting into the operands being backwards!
GNU "as" across different CPUs isn't even consistent!
Like on x86 to load literals you use,
mov $1, %eax # imm: 1
But on 68k this is,
move #1, %a1 | imm: 1
Even the comment character changes!
Pretty sure GAS is just a conspiracy to make people want to use C.
mirabilosAs is becoming usual, when I don't understand what a new platform is doing, I reach for #ghidra first and ask questions later.
It has revealed the "save/restore screen" code emitted by TIGCC, as well as some hardware/OS version checks that I didn't know were there. That explains why my Hello World binary was larger than expected.
Further, it confirms that absolute addresses are stored as all-zeros, to be fixed up later (at program launch?) by the calculator OS's internal relocating-loader. (There is some mysterious binary junk at the end of the executable that looks like it might be a table involves somehow in these fixup's.)
Okay yeah, the reloc table seems just about as simple as it could be. Just pairs of words arranged like (target, source).
I bet I know enough now to craft a loadable binary and a TI-Connect/TILP compatible .89z/.9xz variable file to wrap it while transferring to the calc.
This would unlock calc programming with any 68k toolchain, allowing me to drop the (aged, fragile) TIGCC/gcc4ti.
Might not have enough time to test this tonight, but it's certainly coming soon.
Armed with this knowledge, I've managed to load what I think is the smallest well-formed ASM program onto the TI-92+.
00 05 - Program size in bytes
4E 75 - 68k "RTS" opcode (immediate return).
00 00 - End of reloc table
F3 - Program end marker
It loads, runs, and successfully does nothing.
I wrote a utility called "wrap" that wraps an m68k binary in the 9xz format used to transfer data to the TI-92+. By writing position-independent code, I can get away without any relocs other than the "0000" end-of-reloc-table marker. This breaks the dependency on TIGCC's linker. So now I can comfortably write programs in any m68k assembler!
Here is my "hello world" produced by #vasm and my "wrap" tool. It is about half the size of the hello world emitted by TIGCC.
Update: I powered on my calc about 30 minutes later and it booted to the black bar of death and needed a reset. So there is still a bug somewhere - maybe my hello world program is slightly imbalancing the stack or failing to restore an important register.
No calculator crashes today. I'm beginning to think my hello world was actually fine and the problem was the Exec(...) commands I was playing around with before that.
Many of the TI-92's ROM routines, frequently used as building blocks in assembly programs, are accessible through TI-Basic. So I'm trying to get a passing familiarity with TI-Basic.
Here's a subroutine to generate a weighted random value. You call it like this: rlt({"a",10,"b",5}). This is twice as likely to return "a" than "b".
Making a TI-Basic hangman was obligatory, of course, having already made a TinyBasic hangman.
TI-Basic doesn't have the elemental simplicity of TinyBasic, but what it does have is structured programming, real string variables, and gasp multi-character variable names! Sooo fancy.
I uploaded my TI-89/92+ homebrew tools to https://gitlab.cs.washington.edu/fidelp/ti68k; maybe they will be useful to someone else who wants to develop from a host system that TIGCC doesn't support.
Mike Spooner@psf The "relocate-on-load" thing has typically done to work-round the lack of an MMU. Idris (a portable contemporary workalike of 6th Edition UNIX) did things that way in 1978 so that it could run on smaller PDP-11 systems than Bell UNIX, such as the LSI-11 and PDP-11/23.
@haitchfive@psf Your brain is healthy, gas is not.
Stylus@psf I have only done a tiny tiny bit and it's been m68k-linux-gnu-as.
@psf (to work on a m68k mac target, but basically not trying to use any definition/include files from that world, just a few constants defined right in my file)
Elias Mårtenson@psf vasm for me. I haven't really explored the options, but it's what most demo programmers use on the ST so it's easy to share code.
Bitslingers-R-Us@psf I suppose you’re not talking about running m68k natively.
The simplest thing, IMHO, is to just build NetBSD on Linux:
https://www.netbsd.org/docs/guide/en/chap-build.html
You don’t even need to build all of it - you can just build tools:
./build.sh -O /usr/obj-m68k -T /usr/tools -m amiga toolsThen you’ll have tools like /usr/tools/bin/m68k--netbsdelf-as and friends.
MontyOnTheRun@psf I use VASM, but not because I like it, but rather due to Kalms C2P requiring it (Amiga Chunky-to-planar public domain routines).
Bonus points: also works on Macs :)
Sigrid Solveig Haflínudóttir
winden^capsule^batman.group@psf seconded on using vasm, it is very very devpac / genam compatible which is what most of amiga coders used from mid 90s onwards