This posts interrupts the rather technical series of . . . → Read More: Running the Amiga SAS C 6.58 compiler with vamos]]> Well, the vamos project is progressing really, really well… And while I’m working at bringing more and more native Amiga tools to life on my Mac, I almost overlooked the first major milestone (and actually its primary initial goal) of the project: running the SAS C Compiler…

This posts interrupts the rather technical series of articles describing the internals of vamos and simply shows you how to actually use vamos the way its intended to be

Fasten your seatbelts, grab your old SAS C compiler disks and read on!

1. Installing SAS C in P-UAE

First thing we need to get the SAS C installation files including the Amiga binaries, the headers and libraries.

I actually own(!) the SAS C compiler 6.50 package (really impressive boxing and lots to read ) and the contained disks were captured to ADF disk images with my kryoflux device. (And no, don’t ask me for the disk images!)

Then I took my all-time-ready P-UAE (src or precompiled) emulation setup with a classic OS 3.9 and installed the disks there.

I use a host-based virtual directory for DH1: called Shared: and the SAS compiler was installed there.

BTW: Do not forget to install the latest update of the SAS C 6.5 series found on the net…

After this step I already had the necessary files for vamos residing on my Mac hard drive. (The Shared: volume is pointing to ~/amiga/shared on the Mac – keep this in mind to understand the following vamos setup)

If everything works out then your directory something like this:

chris@thaum:~/amiga/shared$ ls -la sc
total 160
drwxr-xr-x  28 chris  staff    952 24 Okt 18:11 ./
drwxr-xr-x  34 chris  staff   1156 26 Nov 16:42 ../
-rwxr-xr-x   1 chris  staff   5045  1 Okt  1993 READ.ME*
-rw-r-xr-x   1 chris  staff    838 13 Jan  2011 READ.ME.info*
-rwxr-xr-x   1 chris  staff  21515 27 Feb  1995 Read.Me.6.55*
-rw-r-xr-x   1 chris  staff    838 13 Jan  2011 Read.Me.6.55.info*
drwxr-xr-x  53 chris  staff   1802 25 Jun 12:58 c/
-rw-r-xr-x   1 chris  staff    628 13 Jan  2011 c.info*
drwxr-xr-x  11 chris  staff    374 13 Jan  2011 cxxinclude/
drwxr-xr-x   4 chris  staff    136 13 Jan  2011 env/
drwxr-xr-x  48 chris  staff   1632 16 Nov 21:32 examples/
-rw-r-xr-x   1 chris  staff    628 13 Jan  2011 examples.info*
drwxr-xr-x  32 chris  staff   1088 13 Jan  2011 extras/
-rw-r-xr-x   1 chris  staff    628 13 Jan  2011 extras.info*
drwxr-xr-x  18 chris  staff    612 13 Jan  2011 help/
-rw-r-xr-x   1 chris  staff    628 13 Jan  2011 help.info*
drwxr-xr-x  18 chris  staff    612 13 Jan  2011 icons/
-rw-r-xr-x   1 chris  staff    628 13 Jan  2011 icons.info*
drwxr-xr-x  56 chris  staff   1904 13 Jan  2011 include/
drwxr-xr-x  34 chris  staff   1156 13 Jan  2011 lib/
drwxr-xr-x  13 chris  staff    442 13 Jan  2011 libs/
-rwxr-xr-x   1 chris  staff   5935 13 Jan  2011 read.me.6.58*
-rw-r-xr-x   1 chris  staff    838 13 Jan  2011 read.me.6.58.info*
drwxr-xr-x  31 chris  staff   1054 13 Jan  2011 rexx/
drwxr-xr-x  28 chris  staff    952 13 Jan  2011 source/
-rw-r-xr-x   1 chris  staff    628 13 Jan  2011 source.info*
drwxr-xr-x   8 chris  staff    272 13 Jan  2011 starter_project/
-rw-r-xr-x   1 chris  staff    628 13 Jan  2011 starter_project.info*

2. Setting up vamos

I won’t go into detail on how to compile, install vamos on your machine – have a look at my amitools page for this.

Here we will write a config file for vamos that defines the mapping of the Mac paths to Amiga volumes and also adds the assigns SAS C will need to run.

I added a file called .vamosrc to my $HOME directory (this is the default location where vamos will look for this file. You can also store this file at any place and use the -c command line option to select the config file):

# .vamosrc - vamos config file for SAS C compiler
[volumes]
wb310=~/amiga/wb310
sc=~/amiga/shared/sc

[assigns]
include=sc:include
lib=sc:lib
t=root:tmp

[path]
path=sc:c,wb310:c

Let’s have a closer look of whats described here:

• The first section called volumes in the file describes the Mac Path to Amiga Volume mapping. Each entry gives a Amiga volume defined inside vamos (and visible to Amiga programs running inside vamos) and maps them to a native Mac Path. In my config the volumes wb310: and sc: are defined. (Use absolute paths here to make the config work from any location) The wb310: isn’t actually used in this example but having Workbench files handy is always a good idea (for later use of vamos)
• The next section assigns defines assigns inside vamos, like AmigaDOS does itself. Assign mapping always references Amiga paths on the right side and never native (Mac) paths! Furthermore, an assign must map either to another assign (optional plus path) or to an absolute path with volume. Relative paths are not allowed here. SAS C needs assigns for the headers (include:) and the link libraries (lib:). The last assign maps the temp dir of AmigaDOS as SAS C stores some files there temporarly. t: is mapped via the root: volume that is always defined in vamos and points to the file system root (/). So this assign actually points to /tmp…
• The last section path gives — similar to AmigaDOS — the search path for binaries. Again, only absolute Amiga paths are allowed. The path is searched in vamos whenever a binary is given on the command line… very handy we will see soon…

3. Run sc for the first time

With the config in place and vamos in your path, you can already call the SAS C compiler called sc from any place on your mac (Remember: vamos will look in your Amiga path for the binaries):

chris@thaum:~$ vamos sc
20:51:58.301       path:WARNING:  ami_to_sys_path: ami_path='env:sc/scoptions' -> abs_path='env:sc/scoptions' -> no resolved paths!
SAS/C Amiga Compiler 6.58
Copyright (c) 1988-1995 SAS Institute Inc.
20:51:58.322        lib:WARNING:  [    exec.library]  ? CALL:  324 Signal( task[a1]=108b4, signalSet[d0]=8000 ) from PC=020062 -> d0=0 (default)
20:51:58.322        lib:WARNING:  [    exec.library]  ? CALL:  252 Remove( node[a1]=2014c ) from PC=01ff36 -> d0=0 (default)
Error  : No files to compile
20:51:58.328        lib:WARNING:  [    exec.library]  ? CALL:  252 Remove( node[a1]=2014c ) from PC=01ff36 -> d0=0 (default)

The compiler is already running — only vamos mocks about some currently un-emulated (but harmless) library calls. You can make vamos quiet with the -q switch:

chris@thaum:~$ vamos -q sc
SAS/C Amiga Compiler 6.58
Copyright (c) 1988-1995 SAS Institute Inc.
Error  : No files to compile

Ah, that’s the SAS C I remember (Note: vamos options are placed before the Amiga binary. All options following the binary are passed to the Amiga program!)

Now we need a little program to test compile. Open your favorite editor (TextMate here) and enter the world famous “hello, world!” snippet:

/* hello.c - say no more  */
#include <stdio.h>

int main(int argc, char **argv)
{
   printf("hello, world!\n");
   return 0;
}

Let’s compile it:

chris@thaum:~/Projects/amitools.git/test_code$ vamos -q sc hello.c
SAS/C Amiga Compiler 6.58
Copyright (c) 1988-1995 SAS Institute Inc.

Hmm, not much to say here… But look what happened:

chris@thaum:~/Projects/amitools.git/test_code$ ls -la hello.o
-rw-r--r--  1 chris  staff  236  2 Dez 20:59 hello.o
chris@thaum:~/Projects/amitools.git/test_code$ file hello.o
hello.o: AmigaOS object/library data

yay! Your first SAS C compiled binary — and it was compiled on a Mac!!

4. Link and Run

Now we need to link our object file to get a program suitable for your Amiga.

The linker in SAS C is called slink and also ready to run on vamos:

chris@thaum:~/Projects/amitools.git/test_code$ vamos -q slink
Error 607: No FROM/ROOT files specified

Ok, it needs some options to perform its task… (The Error is not from vamos but from slink)

chris@thaum:~/Projects/amitools.git/test_code$ vamos -q slink from lib:c.o hello.o to hello lib lib:sc.lib lib:amiga.lib
Slink - Version 6.58
Copyright (c) 1988-1995 SAS Institute, Inc.  All Rights Reserved.

SLINK Complete - Maximum code size = 5384 ($00001508) bytes

Final output file size = 5396 ($00001514) bytes

I love it (now that it works )… slink just created an Amiga LoadSeg()able binary:

chris@thaum:~/Projects/amitools.git/test_code$ ls -la hello
-rwxr-xr-x  1 chris  staff  5396  2 Dez 21:06 hello*
chris@thaum:~/Projects/amitools.git/test_code$ file hello
hello: AmigaOS loadseg()ble executable/binary

Now comes the funny part:

chris@thaum:~/Projects/amitools.git/test_code$ vamos ./hello
hello, world!

Of, course! vamos can also run the created binary… If you don’t believe it try yourself, take hello to P-UAE or even better to the real(tm) machine…

5. Some more complex code

You can of course compile larger (aka “real”) code as well.

Just try one of the examples SAS C ships:

> cd ~/amiga/shared/sc/examples/amiproc
> vamos -q sc amiproc.c simple.c
> vamos -q slink from lib:c.o simple.o amiproc.o lib lib:sc.lib lib:amiga.lib
> ls -la simple
-rwxr-xr-x  1 chris  staff  6768  2 Dez 21:15 simple*
> file simple
simple: AmigaOS loadseg()ble executable/binary

Note: this binary does not run on vamos but needs UAE or a real machine…

BTW: If you want to know how well vamos performs running the compiler then call it with the -v switch and have a look at the last lines:

chris@thaum:~/Projects/amitools.git/sc/examples/amiproc$ vamos -v sc amiproc.c simple.c
21:24:13.888       main:   INFO:  read config file: /Users/chris/.vamosrc
21:24:13.888       main:   INFO:  setting up main memory with 1024 KiB RAM: top=100000
21:24:13.905       main:   INFO:  setting up m68k
21:24:13.906       main:   INFO:  start cpu: 0016bc
...
21:24:21.504       main:   INFO:  done (410454570 cycles in cpu time 2.3453s -> 54.02 MHz (30.87 %), trap time 5.2531s (69.13 %), total time 7.5984s)
21:24:21.505       main:   INFO:  exit code=0

Quite impressive compiling on a 54 MHz m68k… The trap time currently spent in the Python emulation has lots of potential for further optimization. But hey, first of all its running and then we think about getting it running real fast

With sc and slink running fairly well… Now what’s still missing to have a full featured cross compiler environment with a vamos-ed SAS C compiler?

6. What’s still missing?

Currently vamos has no ability to execute child processes. This is used in sc if you wan to link directly (sc bla.c to bla …). This is also the main reason why smake is a NOP right now…

I am currently working on this issue and I think with smake up and running the most important tools are available to start serious cross development with SAS C on the Mac…

Probably, lots of other things are still not working as well… So if you find something that currently breaks in sc and slink then I’d really be happy if you drop me a note… (Beta testers hoorray!

Always enjoy vamos now with SAS C on your Mac

Make sure to read Part 1 of the series first…

Todays topics:

We already know from our first expirments that an Amiga library . . . → Read More: Inside vamos (Part 2)]]> Today we continue our little journey through my newest project and have a look at libraries and structures in the “virtual” Amiga RAM of vamos.

Make sure to read Part 1 of the series first…

Todays topics:

• Amiga Libraries
• Amiga Structures

1. Amiga Libraries

We already know from our first expirments that an Amiga library has a large jump table for all functions which we already use to trap the calls and redirect them to our Python vamos code.

The open question is now what functions does a library have and what registers are filled by the application before calling this function. Furthermore, we need to know what we have to return in the registers before returning to the caller. The last question is answered quickly: data registrer D0 is the return value of all lib calls (if the lib call isn’t void then no register contains a return value). So mapping the python trapped call return value to D0 was quickly done.

For the function description in a library Commodore invented a textual programming language neutral description called the FD files describing each function call and the arguments required along with the CPU registers where the argument will be found.

To simplify my work with vamos I first wrote a parser for the FD files (that can be found in the Amiga NDKs). This little tool is called fdtool and also available in my amitools source tree. You simply call it with a single FD file and it shows all functions and the relative jump offset in the table:

> ./fdtool NDK_3.1/Includes\&Libs/fd/exec_lib.fd
NDK_3.1/Includes&Libs/fd/exec_lib.fd
 base: _SysBase
 #0001     30  0x001e                Supervisor [userFunction,a5]
 #0002     72  0x0048                  InitCode [startClass,d0][version,d1]
 #0003     78  0x004e                InitStruct [initTable,a1][memory,a2][size,d0]
 #0004     84  0x0054               MakeLibrary [funcInit,a0][structInit,a1][libInit,a2][dataSize,d0][segList,d1]
 #0005     90  0x005a             MakeFunctions [target,a0][functionArray,a1][funcDispBase,a2]
 #0006     96  0x0060              FindResident [name,a1]
 #0007    102  0x0066              InitResident [resident,a1][segList,d1]
 #0008    108  0x006c                     Alert [alertNum,d7]
 #0009    114  0x0072                     Debug [flags,d0]
 #0010    120  0x0078                   Disable
 #0011    126  0x007e                    Enable
 #0012    132  0x0084                    Forbid
 #0013    138  0x008a                    Permit
 #0014    144  0x0090                     SetSR [newSR,d0][mask,d1]
 #0015    150  0x0096                SuperState
 #0016    156  0x009c                 UserState [sysStack,d0
..

Its already very useful to decode jumps into the lib (Note: the jump uses a negative offset while the tools displays positive ones).

The next step was to create a code generator that writes stubs for Python that describe all functions:

./fdtool -g NDK_3.1/Includes\&Libs/fd/exec_lib.fd
 (30, 'Supervisor', (('userFunction', 'a5'),)),
 (36, 'execPrivate1', None),
 (42, 'execPrivate2', None),
 (48, 'execPrivate3', None),
 (54, 'execPrivate4', None),
 (60, 'execPrivate5', None),
 (66, 'execPrivate6', None),
 (72, 'InitCode', (('startClass', 'd0'), ('version', 'd1'))),
 (78, 'InitStruct', (('initTable', 'a1'), ('memory', 'a2'), ('size', 'd0'))),
 (84, 'MakeLibrary', (('funcInit', 'a0'), ('structInit', 'a1'), ('libInit', 'a2'), ('dataSize', 'd0'), ('segList', 'd1'))),
 (90, 'MakeFunctions', (('target', 'a0'), ('functionArray', 'a1'), ('funcDispBase', 'a2'))),
 (96, 'FindResident', (('name', 'a1'),)),
 (102, 'InitResident', (('resident', 'a1'), ('segList', 'd1'))),
 (108, 'Alert', (('alertNum', 'd7'),)),
 (114, 'Debug', (('flags', 'd0'),)),
 (120, 'Disable', None),
 (126, 'Enable', None),
 (132, 'Forbid', None),
 (138, 'Permit', None),
 (144, 'SetSR', (('newSR', 'd0'), ('mask', 'd1'))),
 (150, 'SuperState', None),

I simply copy & paste this output in my ExecLibrary class and this table now describes all functions available and also their parameters. This information is not used for trapping in the first place but for logging: Now I can decode each jump into the Lib and display the named function call...

19:39:29.159        lib:   INFO:  [    exec.library]  { CALL:  198 AllocMem( byteSize[d0]=def4, requirements[d1]=10001 ) from PC=00205a
19:39:29.159        lib:   INFO:  [    exec.library]  } END CALL: d0=000108ac
19:39:29.159        lib:   INFO:  [    exec.library]  { CALL:  732 StackSwap( newStack[a0]=113e8 ) from PC=0020e8
19:39:29.159        lib:   INFO:  [    exec.library]  } END CALL: d0=0000000

With this information in place I could add trapped functions by adding a new table to my Library object: this one maps the function offset (again positive) to an actual Python method inside the class. I can do this for only the functions I need – all others have a default handler that returns D0=0 and issues a warning trace that this function is still unimplemented.

An excerpt of the Python ExecLibrary class looks like this:

def __init__(self):
  exec_funcs = (
     (408, self.OldOpenLibrary),
     (414, self.CloseLibrary),
     ...
  )
  self.set_funcs(exec_funcs)

def OpenLibrary(self, lib, ctx):
  name_ptr = ctx.cpu.r_reg(REG_A1)
  ...
  return lib_addr

You see the mapping of Python functions in this example. Note that each Python call gets the same parameters and not the Amiga function calls directlly: It gets a context object and via this context the function can access the virtual CPU and read out the registers it needs…

The return value of the Python method will be directly written to D0 automatically. Returning None will not alter D0. This is useful for void function calls.

2. Amiga Structures

The library jump tables are not the only kind of data an Amiga application directly accesses outside its own memory segments: A lot of public data structures reside in memory and function calls often pass in pointers to them and also private ones. Some functions even require to create new structures and we then need to return their pointers. Furthermore, each library itself has (beside the jump table) a so called “pos size range” that contains data structures of “public” accessible information. E.g. exec.library has a large pos size with lots of system constants and also information like your own task structure…

Our task in vamos is now to correctly fill these structures as needed and provide a convinient mechanism in Python to access those data members. Unfortunately, those data structures are only defined in the language headers of Commodore’s NDKs and there is no generic description like there is the FDs for the calls

Without having a tool to decode some generic data structure definitions I started to convert the C Amiga headers manually into a Python structure definition. Those definition are not structures in Python itself but rather meta objects that describe a structure in the “virtual” Amiga Memory of vamos. This tedious process was only performed on demand, i.e. onyl the structures currently needed were transcribed to Pyhon.

Similar to fdtool I have written a typetool to provide a small command line utility that uses the structures defined in Python and displays them (This is again useful for disassembly reading as you can quickly look up and index and find the structure entry):

./typetool Library
 @0000        Library {
 @0000          Node {
0000 @0000/0000 +0004      Node*      ln_Succ               (ptr=True, sub=False)
0001 @0004/0004 +0004      Node*      ln_Pred               (ptr=True, sub=False)
0002 @0008/0008 +0001      UBYTE      ln_Type               (ptr=False, sub=False)
0003 @0009/0009 +0001      BYTE       ln_Pri                (ptr=False, sub=False)
0004 @0010/000a +0004      char*      ln_Name               (ptr=True, sub=False)
 @0014 =0014    } lib_Node
0005 @0014/000e +0001    UBYTE      lib_Flags             (ptr=False, sub=False)
0006 @0015/000f +0001    UBYTE      lib_pad               (ptr=False, sub=False)
0007 @0016/0010 +0002    UWORD      lib_NegSize           (ptr=False, sub=False)
0008 @0018/0012 +0002    UWORD      lib_PosSize           (ptr=False, sub=False)
0009 @0020/0014 +0002    UWORD      lib_Version           (ptr=False, sub=False)
0010 @0022/0016 +0002    UWORD      lib_Revision          (ptr=False, sub=False)
0011 @0024/0018 +0004    APTR       lib_IdString          (ptr=False, sub=False)
0012 @0028/001c +0004    ULONG      lib_Sum               (ptr=False, sub=False)
0013 @0032/0020 +0002    UWORD      lib_OpenCnt           (ptr=False, sub=False)
 @0034 =0034  }

This query for the Library structure of Exec displays all entries including nested structures, their byte offset from the beginning, the C type and the name to access each entry.

This structure information is now used for two purposes in vamos: First it provides a convinient way to access structures inside memory for the Python lib calls when they have to access data that was provided by giving structure pointers. The second use of structures is to provide so called memory labels for logging. Every time vamos allocates a structure (e.g. ExecLib pos space) it also registers a struct memory label for the same address. A label manager keeps all registered labels and if memory tracing is enabled then you can look up an arbitrary address if it can be labelled. A structure label looks like this:

19:22:23.891        mem:   INFO:  R(4): 0102a8: 00000000  Struct  [@010210 +000098 ThisTask] Process+152 = pr_CurrentDir(BPTR)+0
19:22:23.892        mem:   INFO:  R(4): 0102bc: 00004070  Struct  [@010210 +0000ac ThisTask] Process+172 = pr_CLI(BPTR)+0
19:22:23.892        mem:   INFO:  R(4): 0102bc: 00004070  Struct  [@010210 +0000ac ThisTask] Process+172 = pr_CLI(BPTR)+0
19:22:23.892        mem:   INFO:  R(4): 0101d0: 00004080  Struct  [@0101c0 +000010 CLI] CLI+16 = cli_CommandName(BSTR)+0

So a read access to memory address 0x0102a8 is detected as structure access to ThisTask.pr_CurrentDir. That’s what I call comfortable debugging   Note that the labelling look ups cost quite a lot of performance and that’s the reason why you have to enable memory tracing with a command line switch (-t/-T).

The most common use of Structures is to decode lib call arguments. In Python I provide a so called AccessStruct object that assist reading/writing structures:

def StackSwap(self, lib, ctx):
 stsw_ptr = ctx.cpu.r_reg(REG_A0)
 stsw = AccessStruct(ctx.mem, StackSwapDef, struct_addr=stsw_ptr)
 # get new stack values
 new_lower = stsw.r_s('stk_Lower')
 new_upper = stsw.r_s('stk_Upper')
 new_pointer = stsw.r_s('stk_Pointer')

This is an excerpt of the Python implemenation of the Exec StackSwap call: In A0 a pointer to a StackSwap structure is passed in. We have already declared the function in Python as a defintion (hence the trailing Def):

class StackSwapStruct(AmigaStruct):
 _name = "StackSwap"
 _format = [
 ('APTR', 'stk_Lower'),
 ('ULONG', 'stk_Upper'),
 ('APTR', 'stk_Pointer')
 ]
StackSwapDef = StackSwapStruct()

With a memory pointer and a structure definition we can create an access object. Now the reads and writes to the entries of the structure a simple calls can be performed with the entry name of the structure… Ok its slower than direct offset handling but far more confortable and less error prone…

Beside the structure access vamos also provides a more generic memory access object that allows to read and write blocks of data, reads c-type strings and bcpl strings with a single call:

def OpenLibrary(self, lib, ctx):
 ver = ctx.cpu.r_reg(REG_D0)
 name_ptr = ctx.cpu.r_reg(REG_A1)
 name = ctx.mem.access.r_cstr(name_ptr)
 ..

That’s it for today… I hope you got more insight on the Library and Struct handling and the confortable features available in vamos for working with them.

HW installation was fairly easy, but with the software the trouble began… The supplied drivers does not run on . . . → Read More: SilverSurfer patched for Amiga 500]]> I just purchased a new HW goodie for my classic Amiga 500. A clockport adapter and a SilverSurfer serial card that allows high baudrates (e.g. 115200 baud) on this machine without generating too much CPU load.

HW installation was fairly easy, but with the software the trouble began… The supplied drivers does not run on an Amiga 500 but only on an A1200 Being a real retro hacker I had a look at the driver binary, disassembled it and found out that the code could be easily patched to run on an A500, too.

Now it works like a charm even on the 680000 machines. Here try yourself: silversurfer104-a500.zip

If you want to know how this was done… then read on… Be warned: technical details ahead

1. Take a close look at the binary

First of all I did a disassembly of the original driver binary. As the Amiga binaries are in the LoagSeg()able Hunk Format you need a tool that can cope with this type of files.

Fortunately, in my amitools Project I am developing a tool called hunktool that allows to inspect those files. With the help of the dissassemblers vda68k or m68k-elf-objdump from the gnu toolchain (here created like described in the 68k AROS project) it even can disassemble the code segments… Since my tools are written in Python 2.x they run almost everywhere…

On my Mac I did a:

> hunktool info -A silversurfer.device > surfer.txt

Voila! A full disassembly nicely annoted with relocations was generated. You get something like this:

silversurfer.device TYPE_LOADSEG
 header (segments: first=0, last=0, table size=1)
 #000  CODE   size 000037f4  file header @00000018  data @00000020 
 reloc  absreloc32 #1
 To Segment #0:   23 entries

00000000        70ff                          moveq   #-0x1,d0        
00000002        4e75                          rts                     
00000004        7000                          moveq   #0,d0           
00000006        4e75                          rts                     
00000008        4afc                          illegal                 
0000000a        0000 0008                     ori.b   #0x8,d0          ; absreloc32: self: 00000008
0000000e        0000 37f2                     ori.b   #-0xe,d0        
00000012        8002                          or.b    d2,d0           
00000014        0305                          btst    d1,d5           
00000016        0000 0024                     ori.b   #0x24,d0         ; absreloc32: self: 00000024
0000001a        0000 0081                     ori.b   #-0x7f,d0        ; absreloc32: self: 00000081
0000001e        0000 00c8                     ori.b   #-0x38,d0        ; absreloc32: self: 000000c8
00000022        0000 7369                     ori.b   #0x69,d0        
00000026        6c76                          bge.b   0x9e            
00000028        6572                          bcs.b   0x9c            
0000002a        7375                          moveq   #0x75,d1        
0000002c        7266                          moveq   #0x66,d1        
0000002e        6572                          bcs.b   0xa2            
00000030        2e64                          movea.l -(a4),sp        
00000032        6576                          bcs.b   0xaa            
00000034        6963                          bvs.b   0x99            
00000036        6500 5369                     bcs.w   0x53a1          
0000003a        6c76                          bge.b   0xb2            
0000003c        6572                          bcs.b   0xb0            
0000003e        5375 7266                     subq.w  #0x1,(0x66,a5,d7.w*2)

Now its time to analyse the code and to refresh your amiga knowledge. Decode resident structures, library calls and look out for memory accesses in the range of the clockport… Have a look at Inside Silver Surfer and you’ll find out we have to look for addresses like $d80001 in the driver code…

For decoding library calls and data structures I wrote two additional tools in amitools: fdtool and typetool. The first on you run with a library FD file from your Commodore NDK and it gives you details about function calls in a library:

> ./fdtool NDK_3.1/Includes\&Libs/fd/exec_lib.fd NDK_3.1/Includes&Libs/fd/exec_lib.fd
 base: _SysBase
 #0001     30  0x001e                Supervisor [userFunction,a5]
 #0002     72  0x0048                  InitCode [startClass,d0][version,d1]
 #0003     78  0x004e                InitStruct [initTable,a1][memory,a2][size,d0]
 #0004     84  0x0054               MakeLibrary [funcInit,a0][structInit,a1][libInit,a2][dataSize,d0][segList,d1]
 #0005     90  0x005a             MakeFunctions [target,a0][functionArray,a1][funcDispBase,a2]
 #0006     96  0x0060              FindResident [name,a1]
 #0007    102  0x0066              InitResident [resident,a1][segList,d1]
 #0008    108  0x006c                     Alert [alertNum,d7]
 #0009    114  0x0072                     Debug [flags,d0]
...

Now its very easy to decode a jsr -off(a6) library call (see second column for offsets!). typetool gives you the offset of data structures (Unfortunately, not all NDK datatypes are available in this tool right now):

> ./typetool ExecLibrary
 @0000        ExecLibrary {
 @0000          Library {
 @0000            Node {
0000 @0000/0000 +0004        Node*      ln_Succ               (ptr=True, sub=False)
0001 @0004/0004 +0004        Node*      ln_Pred               (ptr=True, sub=False)
0002 @0008/0008 +0001        UBYTE      ln_Type               (ptr=False, sub=False)
0003 @0009/0009 +0001        BYTE       ln_Pri                (ptr=False, sub=False)
0004 @0010/000a +0004        char*      ln_Name               (ptr=True, sub=False)
 @0014 =0014      } lib_Node
0005 @0014/000e +0001      UBYTE      lib_Flags             (ptr=False, sub=False)
0006 @0015/000f +0001      UBYTE      lib_pad               (ptr=False, sub=False)
0007 @0016/0010 +0002      UWORD      lib_NegSize           (ptr=False, sub=False)
0008 @0018/0012 +0002      UWORD      lib_PosSize           (ptr=False, sub=False)
0009 @0020/0014 +0002      UWORD      lib_Version           (ptr=False, sub=False)
0010 @0022/0016 +0002      UWORD      lib_Revision          (ptr=False, sub=False)
0011 @0024/0018 +0004      APTR       lib_ldString          (ptr=False, sub=False)
0012 @0028/001c +0004      ULONG      lib_Sum               (ptr=False, sub=False)
0013 @0032/0020 +0002      UWORD      lib_OpenCnt           (ptr=False, sub=False)
 @0034 =0034    } LibNode
...

Furthermore, you can use hunktool to have a look at a hexdump of the segments, too.

> ./hunktool info -x silversurfer.device
silversurfer-hack.device TYPE_LOADSEG
 header (segments: first=0, last=0, table size=1)
 #000  CODE   size 000037f4  file header @00000018  data @00000020 
 00000000: 70 ff 4e 75 70 00 4e 75 4a fc 00 00 00 08 00 00  p<FF>Nup.NuJ<FC>......
 00000010: 37 f2 80 02 03 05 00 00 00 24 00 00 00 81 00 00  7<F2><80>......$...<81>..
 00000020: 00 c8 00 00 73 69 6c 76 65 72 73 75 72 66 65 72  .<C8>..silversurfer
 00000030: 2e 64 65 76 69 63 65 00 53 69 6c 76 65 72 53 75  .device.SilverSu
 00000040: 72 66 65 72 20 42 6f 61 72 64 2d 00 20 55 6e 69  rfer Board-. Uni
 00000050: 74 00 00 00 20 52 00 00 20 57 00 00 53 69 6c 76  t... R.. W..Silv
 00000060: 65 72 53 75 72 66 65 72 20 6c 69 67 68 74 73 70  erSurfer lightsp
 00000070: 65 65 64 20 53 65 72 76 65 72 00 00 24 56 45 52  eed Server..$VER
 00000080: 3a 53 69 6c 76 65 72 53 75 72 66 65 72 20 32 2e  :SilverSurfer 2.
 00000090: 31 30 34 20 28 31 33 2e 31 31 2e 30 30 29 0d 0a  104 (13.11.00)..
 000000a0: 28 63 29 20 31 39 39 31 2d 45 56 45 52 20 62 79  (c) 1991-EVER by
 000000b0: 20 56 4d 43 20 48 61 72 61 6c 64 20 46 72 61 6e   VMC Harald Fran
 000000c0: 6b 0d 0a 0d 0a 00 00 00 00 00 00 f4 00 00 00 d8  k..........<F4>...<D8>
...

With the help of these tools and my trusty old Developer manuals I soon found out everything I need to know about the driver. See my partially annotated disassembly here: silversurfer104-disasm.txt

Code Analysis

The interesting part looking for a silver surfer HW is here:

; ----- detecte silver surfer -----
00002b9c        48e7 7ffe                     movem.l d1-d7/a0-a6,-(sp)
00002ba0        2f0e                          move.l  a6,-(sp)        
00002ba2        2c6e 003c                     movea.l 0x3c(a6),a6      ; a6 = ExecBase
00002ba6        43fa 0be8                     lea     0x3790(pc),a1    ; a1 = "card.resource"
00002baa        4eae fe0e                     jsr     -0x1f2(a6)       ; OpenResource [resName,a1]
00002bae        2c5f                          movea.l (sp)+,a6         ; libaddr
00002bb0        4a80                          tst.l   d0              
00002bb2        6648                          bne.b   0x2bfc           ; ok! -> look for surfer

Aha! It looks for card.resource and if this is found then try to detect one. This one works like a charm on an A1200 with a card slot but not on A500 where this resource is missing. So on my machine this driver will never try to even look for the HW…

Ok, we need to patch this in order to have the driver look for my surfer… One way of doing this might be to replace the bne.s branch with a bra.s. I chose another option: just replace the resource name and use ciaa.resource instead of card.resource This resource is available on the A500, too A simple string replace in the driver binary does the trick!

Now the driver allows to open unit 0 on my machine! Yehaw!!

Unfortunately, it still crashes when trying to actually transfer data with it…

While scanning the disassembly I soon found some long branches (bra.l, bne.l, …) that are only available on cpus starting with 68020. So my A500 with a 68000 only sees a bogus (odd destination address) byte branch and crashes…

Damn! Its 68020 code… But as the init already works I need to find out how many 68020 instructions are actually used.. Again I use hunktool to find this out: It allows to use m68k-elf-objdump to do the disassemlby and this allows me to select the cpu type. So I did a dissassembly for the 68000 and the 68020 and simply diff’ed the result to see the 68020 portions:

> ./hunktool info -A -o -c 68000 silversurfer.device > ss000.txt
> ./hunktool info -A -o -c 68020 silversurfer.device > ss020.txt
> diff ss000.txt ss020.txt
307,308c307
< 0000040a    61ff                    bsrs 0x40b                    
< 0000040c    0000 02a6               orib #-90,%d0                 
---
> 0000040a    61ff 0000 02a6          bsrl 0x6b2                    
310,311c309
< 00000414    61ff                    bsrs 0x415                    
< 00000416    0000 029c               orib #-100,%d0                
..

Aha! Its only the long branches…  And we are lucky ones: the binary is only 16k and so each long branch could be converted into a 68000 compatible word branch… The spare word in each instruction will then be filled with a NOP opcode… So I could patch the binary in place and do not need to relocate anything… Phew!

The branch conversion actually needs to clear the branch offset in the first word (0xff -> 00), remove the next word and keep the lower branch offset. Then add a NOP opcode word. This could be done by hand, but we are hackers so I wrote a little Python script to perform the patch: fix_bsrl.py

Just call it with the offsets to patch and it will do the job… (If you wonder where the global offset 32 in the -a switch comes from: Its the begin of the code segment in the hunk file. You can find the value in the output of hunktool: look for CODE data @20)

> grep bsrl ss020.txt > offsets
> hacks/fix_bsrl.py -a 32 silversurfer.device offsets
OK: 0000042a  distance: 678
OK: 00000434  distance: 668
OK: 00000e80  distance: 6862
OK: 0000106a  distance: 236
OK: 000010a0  distance: 62
OK: 0000110a  distance: 26
OK: 0000111a  distance: 10
OK: 00002288  distance: 1930
OK: 000026e8  distance: 614
OK: 000028a2  distance: 172
writing 'silversurfer.device.patched'... done

Ok! Patch complete…

The driver now works on my A500 without any problems and I can do SLIP via AmiTCP with 115200 Baud resulting in approx. 8 KiB/s FTP transfer rate…

That’s it… I hope you enjoyed my little archeological excursion in hacking classic Amiga driver code…

On my neverending quest to have a powerful cross compiler for m68k Classic Amiga (i.e. OS <= 3.x) for my Mac I had a closer look on the fresh new release of Volker Barthelmann’s C Compiler.

In this post I’ll describe how to install this nice piece of code on your machine in a . . . → Read More: vbcc 0.9b: An Amiga Cross Compiler for Mac OS X]]>  

On my neverending quest to have a powerful cross compiler for m68k Classic Amiga (i.e. OS <= 3.x) for my Mac I had a closer look on the fresh new release of Volker Barthelmann’s C Compiler.

In this post I’ll describe how to install this nice piece of code on your machine in a few easy steps!

1. vasm 1.5b

First we build the cross assembler to assemble the output of vbcc.

• http://sun.hasenbraten.de/vasm/
• http://sun.hasenbraten.de/vasm/release/vasm.tar.gz

Download the source code from the above link. Now extract it:

tar xvfz vasm.tar.gz
cd vasm

Build the binary with:

make CPU=m68k SYNTAX=mot

Finally install with (note we use /opt/vbcc as the location for all this):

mkdir -p /opt/vbcc/bin
cp vasmm68k_std vasmm68k_mot vobjdump /opt/vbcc/bin

Ok, the assembler is ready!

2. vlink 0.14

vlink’s homepage and the source can also be found on Frank Wille’s site:

• http://sun.hasenbraten.de/vlink/
• http://sun.hasenbraten.de/vlink/release/vlink.tar.gz

Same game here: download source and untarring:

tar xvfz vlink.tar.gz
cd vlink

Build:

mkdir objects
make

Install:

mkdir -p /opt/vbcc/bin
cp vlink /opt/vbcc/bin

Done!

3. vbcc 0.9b

Finally, the compiler itself:

• http://www.compilers.de/vbcc.html
• http://www.ibaug.de/vbcc/vbcc.tar.gz

Pepare:

tar xvfz vbcc.tar.gz
cd vbcc

I removed the -DHAVE_AOS4 in the Makefile just to be sure.

Build:

mkdir bin
make TARGET=m68k
make TARGET=m68ks

Install:

cp bin/vbcc* bin/vc bin/vprof /opt/vbcc/bin

The compiler is in place now…

4. Target Environment

A cross compiler needs a target environment. This includes the system headers and libraries here for the m68k Amiga platform. Also the implementation for the c standard library (think of printf…) are required for the target.

Here I only install the amiga m68k target but vbcc supports also other targets. See the following homepage for more details:

• http://sun.hasenbraten.de/vbcc/
• http://mail.pb-owl.de/~frank/vbcc/2011-08-05/vbcc_target_m68k-amigaos.lha
• http://mail.pb-owl.de/~frank/vbcc/2011-08-05/vbcc_unix_config.zip

Download the given archives, one for the m68k target the other for the vbcc descriptions how to run the compiler on a unix-like operating system.

Unzip the archives (If you don’t have lha on your machine. Have a look in MacPorts!):

lha x vbcc_target_m68k-amigaos.lha
unzip vbcc_unix_config.zip

Now install the files into our destination directory:

export VBCC=/opt/vbcc
mv config $VBCC/
mv vbcc_target_m68k-amigaos/targets $VBCC/

Done! Now all components are in place and we are ready for our first compile…

5. First Test

Ok, for the first test, a simple hello world is fine (file hello.c):

#include <stdio.h>
int main(int argc, char **argv)
{
  printf("hello, world!\n");
  return 0;
}

To compile make sure you have the environment variable VBCC set to the install directory and tha PATH holds the bin directory there:

export VBCC=/opt/vbcc
export PATH=$VBCC/bin:$PATH

The compiler always needs the target platform specified with the + switch:

cv +aos68k -o hello hello.c

If all went well you have created a Amiga OS LoadSeg’able binary called hello:

> file hello
hello: AmigaOS loadseg()ble executable/binary

Now launch your favorite amiga emulator (e.g. P-UAE) and give it a try!

More information on the compiler and its options can be found in the documentation on the official home page of Volker:

• vbcc Manual

6. Amiga OS Development

If you want to use the Amiga Libraries in your Programs you will need the OS headers and libraries from a NDK. For the last OS 3.9 you can download it here: NDK 3.9. Simply untar the contents somewhere and define the following environment variables:

export NDK=/path/to/NDK_3.9
export NDK_INC=$NDK/include/include_h
export NDK_LIB=$NDK/linker_libs

Now a typical compile line looks like:

vc +aos68k -I$NDK_INC -L$NDK_LIB -o test test.c -lamiga

Use this to compile a sample taken from the NDK:

cd $NDK/Tutorials/ARexx/Host
vc +aos68k -I$NDK_INC -L$NDK_LIB RexxShell.c -lamiga

You can compare your compile (a.out) with the official binary:

> ls -la RexxShell a.out
-rwxr-xr-x  1 chris  staff  6652  1 Nov  1999 RexxShell*
-rwxr-xr-x  1 chris  staff  5988 18 Aug 20:38 a.out*

Quite nice small result! Now head on to some own code and enjoy your new compiler!

What has changed? Until now I had Portfiles that pick the source from a Snapshot tarball I have . . . → Read More: Updated OpenCBM and Nibtools Portfiles]]> If you are using OpenCBM or Nibtools with the MacPort Portfiles I offer here on my site then you can now find an update of both Portfiles on the following pages:

• OpenCBM on Mac
• Nibtools on Mac

What has changed? Until now I had Portfiles that pick the source from a Snapshot tarball I have stored on my site. This was the release version that made it to the public in January 2011. Now I added Portfiles that directly build the HEAD revision of the associated Source Repositories. With these ports you are always up to date,but they are development snapshots that might not work sometimes…You have been warned

Here is the story . . . → Read More: DICE 3.15 revisited on Mac]]> DICE (Matt Dillon’s C Compiler Environment) was one of the first C compiler I came in touch with back in the days on my A500. Recently,while scanning the Net for a m68k Amiga Cross Compiler solution for my Mac I stumbled across the source code release of DICE by Matt himself…

Here is the story of getting this old pearl running on my Mac…

Building DICE 3.15

• First download the source code and unpack it.
• Apply this patch: dice-rel-3.15-mac.patch.gz

  > cd dice-rel-3.15
  > gunzip -c dice-3.15-mac.patch | patch -p1
  

• Compile the whole stuff:

  > (cd suplib &&make all install)
  > (cd src &&make all install)

• Voliá! All binaries now reside in dice-rel-3.15/ubin

Setup Compiler Environment

There is a simple script called dice.env in the main directory. You can call this to set up your compiler environment automatically. Note that I introduced a new variable DHOME to describe where the compiler resides

> . dice.env

Calling dcc should give you the following

> dcc
DCC 1.12 (24.12.95)
Copyright (c) 1992,1993,1994 Obvious Implementations Corp., Redistribution & Use under DICE-LICENSE.TXT.

Building Amiga OS 1.3 and 2.0 Libs

First you need to copy your Amiga OS C includes (preferably from a Amiga developer CD, like ADCD 2.1) to include/amiga13 or amig20.

> cp -r ADCD_2.1/NDK/NDK_1.3/Includes1.3/include.h/* include/amiga13
> cp -r ADCD_2.1/NDK/NDK_2.0/NDK2.0-4/include/* include/amiga20

Like the README already tells you, now do a:

> cd lib
> export DCCOPTS="-// -1.3"
> dmake -f DMakefile.unix amiga13
> export DCCOPTS="-// -2.0"
> dmake -f DMakefile.unix amiga20

Ok! Libs are now ready…

A simple Test

To test the compiler I took one of the Amiga utility programs supplied with PUAE: transdisk.

The source transdisk.c can be directly downloaded from the repository.

Setup your compiler environment as above, download the source, and the following line does the trick (see doc/dcc.doc for details on the command line switches):

> dcc -mRR transdisk.c

Now a shiny new Amiga binary called transdisk was created in this directory and waits for execution in PUAE or on a real machine…

So much for now… I hope you enjoy your shiny new compiler!