Lallafa's Blog » Misc

SilverSurfer patched for Amiga 500

lallafa — Sat, 15 Oct 2011 16:53:05 +0000

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  pNup.NuJ......
 00000010: 37 f2 80 02 03 05 00 00 00 24 00 00 00 81 00 00  7<80>......$...<81>..
 00000020: 00 c8 00 00 73 69 6c 76 65 72 73 75 72 66 65 72  ...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.............
...

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…

What I’ve done lately…

lallafa — Sun, 05 Jun 2011 17:30:59 +0000

So many month passed by and no update here… I wasn’t lazy (at least not all the time and so I’ll give you a short summary what retro projects I’ve been involved with lately:

DiskFreeezerX – My pet project that aims to build a standalone disk capture device… Should come very handy for partys or meeting people that don’t want to leave their precious disks… Take the device with you, slip in a disk, press a button and some time later you have a shiny exact clone of the disk on your SD card… That’s the goal!
The current state here is: The device is built and functional as a prototype and as a first Rev A PCB… See my shiny new dfx hardware page for all the glory details and lots of photos…
MacVICE – Not much own contribs done here lately. But always following the flow of new features and busy building current snapshots. And before I forget it: With MagerValp’s help I finally fixed the dreaded “black-screen” display problem when the fine blended display is enabled… So enjoy temporal filtering with no more black outs!
PUAE – I am really happy that GnoStiC is now bringing together the current WinUAE and the already dated E-UAE code base to create finally a greate Amiga emualator for all *nix, Linux and Mac users… I really appreciate that and help by submitting small patches. I’ve created my own little fork/clone of the repository at GitHub: You can check this out if you want to have a look what I am patching lately: PUAE/cnvogelg
amitools – Another little crazy project started by me. Its a python library that allows you to read and parse Amiga’s Hunk-based binary format. With all the memory on the good ol’ times fading away and with UAE refreshing my old desire for the Amiga I wrote this lib to refresh and to store the old knowledge in readable python code. Currently, there is not much docs there. But a real hacker will find his/her way… I wrote a small sample that scans your harddrive for amiga files (even in adf, lha containers) and tries to parse the exe with the lib… The lib got a new push with the introduction of the AROS m68k Port (yay!!).. This port uses a decent gcc compiler to generate m68k-elf binaries. So I added ELF parsing to amitools. The only thing still missing is now the converter elf to hunk and back again in python (similar to elf2hunk)…

That’s it! See you soon with more updates…

DiskFreezerX going public

lallafa — Sun, 19 Sep 2010 13:04:55 +0000

Hi all,

its now quite a while that I released something… But I wasn’t lazy in that time. I got amazed by the possibilities of bit cell exact disk capture as presented by the Cyclone20 and KryoFlux… and so I wanted to build my own disk capture unit.

I recently bought a BeagleBoard clone board called IGEPv2 and soon the idea emerged to build a stand-alone disk copy unit based on this board. In the end I’d like to have a box with a floppy drive and a beagle with sd card slot. I can insert a disk to capture and then press a single button to create a bit cell exact and bit rot resistent disk image version on the SD card…

I started experimenting with the AT91SAM7x CPU used as a sampler device in the Cylcone20 and KryoFlux projects. Since no public firmware exists I wrote my own version from scratch. I don’t use USB for data transfer but an SPI channel between SAM7x and the Beagle. The beagleboard runs Poky/Angstrom Linux and therefore the host capture tool is written in C using spidev in user space. All processing tools working on the sampled bit cells are written as Python scripts.

Now everything works really well, i.e. I can capture a disk trackwise and store the samples reliably. Furthermore the conversion tools now can extract a bit stream, decode AmigaDOS blocks and derive an ADF Disk Image in the end. Its by far not a finished project but its in a state you can already work and experiment with…

If you got interested then head over to my DiskFreezerX project page

Finished my DIY 1541U Cartridge Case

lallafa — Sun, 01 Jun 2008 10:34:23 +0000

Puh, finally my 1541U cartridge has a decent case!
I created one myself starting with a generic case at the price of about one EUR…

Have a look at my Lallafa’s 1541U DIY Cartridge Case Page for more details!

D64QLPlugin 0.1 released

lallafa — Wed, 19 Mar 2008 21:31:33 +0000

Mac OS X 10.5 has a really nice feature called QuickLook. This renders the contents of your files into nice little thumbnails and also allows to inspect them in detail by pressing Space…

I have lying around hundreds of D64 disk images on my hard disk and thought it would be really nice to have a quick look at the directories…

So I wrote D64QLPlugin that allows to display the contents of a D64/D71/D81 disk image file in a small retro-style directory view…

Check it out at the D64QLPlugin Homepage!

doremac.com online!

lallafa — Sat, 16 Feb 2008 17:52:18 +0000

After thinkcommodore.com finally shut down its business, it was a sad time for Mac + Commodore fans without having a forum to discuss. Now the wait is over: a new site hit the ground: doremac.com. The site has a forum with strong focus on Commodore computing done by Mac users. Starting from data transfer connection issues to CBM emulators on the Mac you can find everything there. Head over and check it out!

Grasstust, the site maintainer, was kind enough to add a MacVICE Forum Thread. So all MacVICE related stuff including bug fixes and user support can be discussed there.

VICE and VICEplus Leopard fix

lallafa — Sat, 10 Nov 2007 16:27:31 +0000

Unfortunately, the new MacOS X 10.5 (Leopard) does not run the release binaries of VICE 1.22 and VICEplus 1.0 anymore.

Some debugging revealed three issues:

The X11.app startup has greatly simplified and does not need open-x11 (which by the way does not exist any more) to determine a valid DISPLAY value. Now MacOS X already defines a valid DISPLAY that automatically launches the X11 server. This needed a minor modification to the VICE launch scripts.
A really nasty bug in the CoreAudio sound driver now crashes the application. The bug existed for a long time but was never discovered since previous versions of MacOS X simply tolerated the wrong API call. Now Leopard is more picky and simply crashes. A small fix in the audio driver fixes this problem.
Finally, Apple updated the autoconf build tools and thus the build files needed minor modifications. Additionally, /bin/sh now seems to point to a real sh and since some scripts require /bin/bash they need to be changed to call the right shell.

I fixed these issues and now VICE and VICEplus run on Leopard, too. The fix is already applied to the current development versions of both branches.

For your convenience I also recompiled the current version with the patch applied:

DiskImagery64 0.6 released

lallafa — Fri, 05 Jan 2007 22:11:40 +0000

Yes, a new release is ready before I leave for the weekend Sorry, the documentation is not updated yet but there is lots of fresh code inside (bugs of course, too :/):

This time I added networking support. If you have a RRNet ethernet card and a Retro Replay with the Final Replay ROM 0.6 flashed on it then you are ready for real networking fun…

Simply connect your good old machine to the ethernet, run DiskImagery64 0.6 select a PRG file in a disk image or on your local disk and select “Network/Run Program”… tada! The file is transferred to your C64 and run immediately. That’s what I call confortable

Another new goody is the NetDrive support available in TFR: Simply open a disk image in DiskImagery64 0.6 and select “Network/Share Files”… Now the image is available on your C64 on device 6: a

LOAD "$",6

will load the directory of your virtual disk. It is also possible to select only some files on an image or some files on the local file system and share them in a NetDrive. NetDrive support is currently basic and only supports reading quite well… This will change in the next release;)

Have fun and keep the feedback coming!