Lallafa's Blog » Hardware

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…

plip2slip 0.1 released

lallafa — Sun, 28 Aug 2011 16:13:09 +0000

While playing with my A500 recently, I had the idea to try out the TCP Stacks available for this platform. Since the little Amiga lacks a decent ethernet card I had to get along with the internal serial port and a SLIP connection. With 9600 Baud this is very slooow. So I kept on searching for a faster solution and found a PLIP implementation on Aminet. PLIP using the parallel port is much faster than SLIP, but you need a peer with a parallel port, too… and that’s the hard part today

Following the same approach as found in my dtv2ser project, I just attached an AVR ATmega microcontroller to the parallel lines of my Amiga and implemented the PLIP counterpart there. The ATmega on the popular Arduino 2009 boards has a fast serial connection that maps to a USB port via a FTDI 232. This is the ideal data channel for transporting the PLIP packets to your host Mac or PC. With baudrates up to 500 kBaud (~50 KiB/s) and hardware handshaking with RTS/CTS you can easily transfer the data packets very fast to your PC and encapsulate them again in SLIP.

With this idea I started to implement the plip2slip firmware. Fortunately, the magPLIP driver for the Amiga comes with source and so I could port the code to the AVR. With slight modifications on the Amiga part (patch included) I was able to receive the first packets from the Amiga on the Arduino. Then I implemented a simple Ping mode that receives ICMP Ping Requests transforms them to Replies and returns them to the Amiga: plip2slip soon was a ping machine I repeated the same thing for the SLIP side and with a patched slattach tool on Ubuntu Linux I was soon able to ping the AVR from this side, too.

With the basic parts of plip2slip in place and working I finally added the transport/bridging mode that transfers all received PLIP packets to SLIP and vice versa. With this mode running I could ping the Ubuntu host from my Amiga! After some IP forward configuration on Ubuntu I was able to reach my home network and also the Internet with the A500.

And its real fast! An FTP download on my Amiga reaches 25 KiB/s when transferring 10k from Linux! So compared to SLIP with 9600 Baud its a real break through and worth the little hardware effort needed to build the Arduino device…

There is still lots of potential for tuning and optimizing, but I wanted to share this little project as soon as possible with you. So I crammed up everything you need into a little 0.1 release that is available on my shiny new plip2slip homepage. I hope you enjoy it and bring lots of your classic machines back to the net with decent speed…

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…

Nibtools on Mac added and OpenCBM on Mac updated

lallafa — Tue, 01 Feb 2011 18:50:16 +0000

Now with ZoomFloppy device hitting the streets and a growing number of Mac users that own this device its about time to give them decent software packages to work with. I already started the OpenCBM on Mac page quite some time ago when I started to help porting the code for Macs. I reworked the full page and simplified a lot of things. Here it is the shiny new OpenCBM on Mac page with special attention for easy setup of ZoomFloppy users!

The OpenCBM tools are really useful for day-to-day normal disk transfers. But when it comes to copy-protected disks the only tool there is Nibtools from C64Preservation. These tools use the OpenCBM libraries and I soon got them to compile on my machine. The only thing missing there was writing a Portfile and setting up a page similar to the OpenCBM on Mac one. Here we go: I added a shiny new Portfile for Nibtools and described its installation on the Nibtools on Mac page.

Enjoy installing all the nice tools on your Mac and have lots of fun capturing your old treasures to disk images…

dtv2ser 0.5 released

lallafa — Sat, 11 Dec 2010 21:20:25 +0000

From time to time I get requests of users who want to buy or build their own dtv2ser device from the schematics I published in previous dtv2ser versions. Unfortunately, I only ordered a small number of prototype boards and those boards are already all sold out. For most users the schematic is too difficult to build from scratch and so they couldn’t use dtv2ser at all

With the growing popularity of the Arduino platform I soon had the idea to “port” the dtv2ser firmware to this common and easy available boards. I managed to get the firmware running in about a day and the good thing is: only three tiny HW modifications are required to transform a Arduino 2009 board into a fully functional dtv2ser device… So time to pack all the new stuff together and make a new release…

..here it is: dtv2ser 0.5 with Arduino 2009 support is available. The release mainly contains the new board support and some minor bug fixes.

Enjoy and have fun building your own dtv2ser

XUM1541 and OpenCBM for Mac

lallafa — Sat, 19 Dec 2009 20:18:33 +0000

With christmas time the presents arrive… Nate Lawson presented the beta of his incredible XUM1541 USB to IEC/parallel adapter for OpenCBM. I was immediately amazed by this project and built my own version of the XUM1541. I had the chance to help out testing the software on Macs even in its early stages, so everything will work smoothly on our favorite platform…

Lallafa's XUM1541 Prototype

Now with the beta of XUM1541 online, I have another present for you: The OpenCBM on Mac page on my site. This page describes how to compile and set up the OpenCBM software yourself and how to get your device running on your Mac. Have fun!

dtv2ser 0.4 released!

lallafa — Sun, 28 Sep 2008 16:58:41 +0000

LTNS! Yes, indeed… it took quite a while to finish this new version, but its really worth the wait!

dtv2ser 0.4 now supports all new features of dtvtrans 1.0 including init after reset, BASIC loading, saving and RUN. Furthermore, full flash support was added!

If you are impatient then just head over to the dtv2ser homepage and download your copy.

What’s new in this version? Let me explain it with a short walk through:

Basics

After flashing the new 0.4 firmware, you launch the dtv2sertrans client as usual. On Macs you can see some kind of auto-detection of the serial port:

> dtv2sertrans
dtv2sertrans version 0.4, dtv2ser device version 0.4
dtvtrans server NOT responding!!

Ah… no dtvtrans server is running on my DTV. So let’s reset the DTV (and enter dtvtrans via dtvboot):

> dtv2sertrans reset
dtv2sertrans version 0.4, dtv2ser device version 0.4
  resetting dtv... enter dtvtrans
  initializing full BASIC

That’s new: BASIC and KERNAL is fully initialized after a reset, so BASIC commands like load, save, run will work. Querying dtv2sertrans again:

> dtv2sertrans
dtv2sertrans version 0.4, dtv2ser device version 0.4
dtvtrans server version 1.0 (DTVBOOT 1.2 via joy2 in ROM)

Now the server is detected and reports the version, the port and if it resides in RAM or ROM.
You can query more info with:

> dtv2sertrans server info
  dtvtrans revision: 1.0
    implementation:  DTVBOOT 1.2
    port:            joy2
    mode:            ROM
    range:           0x1f8000-0x1fb3db

dtvtrans 1.0 Features

Let’s check out the new dtvtrans 1.0 features that support BASIC commands and simplify loading, running programs:

> dtv2sertrans reset + load mygame.prg + run

Reset + init BASIC, load a program via dtv2ser and run it… That’s easy!

> dtv2sertrans save myprog.prg

This call saves the current program like the BASIC SAVE does only via dtv2ser…

Whats quite handy is a fill commando to simple write a value (e.g. 0) to a range of memory:

> dtv2sertrans fill 0x18000-0x20000 0

Flash Commands

And now flashing! But first a Warning: Flashing operation can destroy your DTV. So you have to be sure what you are doing. In this guide I’ll warn you, if something dangerous will happen. So you can decide if you dare it

First let’s see if your dtv2ser device can handle sys calls:

> dtv2sertrans diag sys
dtv2sertrans version 0.4, dtv2ser device version 0.4
  loading servlet '/Users/chris/Projects/svn/dtv2ser/servlet/diag_srv.prg'
  testing 25 sys calls with wait and return value fetch
  * 0/25: testing sys call with 84 frames duration
  duration: 00:01.823
...
  * 24/25: testing sys call with 51 frames duration
  duration: 00:01.219
  * 25/25: all calls passed OK!

Ok, sys call test passed without errors… So the flash commands that are called via sys should work.
Now let’s ensure that the dtvtrans server program is runnning from RAM and not from ROM!

> dtv2sertrans server ram
dtv2sertrans version 0.4, dtv2ser device version 0.4
  resetting...
  is alive?
  initializing BASIC
  query dtvtrans server
  dtvtrans running in ROM. loading RAM version
  loading prg file '/Users/chris/Projects/svn/dtv2ser/contrib/dtvtrans_joy2.prg': 2548/0x0009f4 bytes, start: 0x0801
  sending program to DTV
    speed:  client=16.48 server=16.59 (kbyte/s)
    time:   00:00.191 for 2548/0x0009f4 bytes
  run program
  query dtvtrans server
  dtvtrans is now in RAM. Good!
    implementation: DTVTRANS 1.0

Fine, server now running from RAM… We are ready for flashing!
Let’s check the type of the flash ROM found in the DTV:

> dtv2sertrans flash id
dtv2sertrans version 0.4, dtv2ser device version 0.4
  flash type: SST39VF1681

Now let’s have a look a the flash usage:

> dtv2sertrans flash map
dtv2sertrans version 0.4, dtv2ser device version 0.4
  generating flash map on DTV
  duration: 00:04.731
          flash ROM map ('.'=empty '*'=filled)
          0xxx 1xxx 2xxx 3xxx 4xxx 5xxx 6xxx 7xxx 8xxx 9xxx Axxx Bxxx Cxxx Dxxx Exxx Fxxx
  000000: .... **** .... .... .... .... .... .... .... **** **** **** .... **** **** ****
  010000: **** ***. .... .... **** **** **** **** **** **** **** **** **** **** **** ****
  020000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  030000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  040000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  050000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  060000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  070000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  080000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  090000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  0a0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  0b0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  0c0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  0d0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  0e0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  0f0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  100000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  110000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  120000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  130000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  140000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  150000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  160000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  170000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  180000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  190000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  1a0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  1b0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **** **** ****
  1c0000: **** **** **** **** **** **** **** **** **** **** **** **** **** **.. .... ....
  1d0000: .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... ....
  1e0000: .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... ....
  1f0000: .... .... .... .... .... .... .... .... **** **** **** **** **** **** **** ****

The first step in flashing is to store the current contents of the flash ROM in a file:

> dtv2sertrans flash dump orig_rom.bin
dtv2sertrans version 0.4, dtv2ser device version 0.4
  dumping flash ROM to file 'orig_rom.bin'
    speed:  client=17.95 server=17.96 (kbyte/s)
    time:   01:54.116 for 2097152/0x200000 bytes
  saving raw file 'orig_rom.bin': 2097152/0x200000 bytes

Now, create or alter the ROM file (e.g. use tools like DTVFSEdit).
If the new ROM is ready, you can flash it back to your DTV with (first in dummy mode w/o flashing):

> dtv2sertrans flash sync new_rom.bin
dtv2sertrans version 0.4, dtv2ser device version 0.4
  loading raw file 'new_rom.bin': 2097152/0x200000 bytes
  syncing flash ROM
          flash ROM map ('*'=flash '#'=erase+flash)
          0xxx 1xxx 2xxx 3xxx 4xxx 5xxx 6xxx 7xxx 8xxx 9xxx Axxx Bxxx Cxxx Dxxx Exxx Fxxx
  010000: #... ..#. .... .... .... .... .... .... .... .... .... .... .... .... .... ....
  020000: .... .... .... .... .... .... .... .... .... .... .... .... .... .... .... ....
...

If you add the -f switch then a real flash operation is performed. This will alter your DTV! So make sure the image is correct:

> dtv2sertrans flash sync -f new_rom.img
...

Ok, that’s it! This was a short walk through for all the new dtv2ser 0.4 features. But there are many more things to discover. Just run dtv2sertrans -h to see more options…

Have Fun,
-chris

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!

sd2iec in DTV Joystick

admin — Sun, 06 Apr 2008 13:25:44 +0000

I just built my sd2iec device board from Shadowolf. Its really small and compact so I thought why not integrate it into my modded DTV with the original joystick case. I don’t wanted to sacrificy the battery case so I knew there is not much place left…

With a lot of cramming and fiddling around I finally managed to insert the sd2iec inside my DTV Mod. Phew! Now the case is filled up to the limit – but its cool to have a sd2iec right inside the joystick;)

Have a look here at my gallery for more pictures!

dtv2ser 0.3 released

lallafa — Mon, 03 Mar 2008 20:15:26 +0000

Finally dtv2ser 0.3 is ready for prime time!

Grab your copy here: dtv2ser Homepage

The new version introduces a fully automatic bootstrap command that brings an unmodified DTV (with only a DB9 joystick connector attached) into dtvtrans mode in a few minutes without manual intervention. A normal mode types in TLR’s boot.txt basic booter on the virtual keyboard and fetches mlboot.prg and dtvtrans.prg afterwards. A new improved fast bootstrap method does some pre POKEs to speed up typing and boots in half the time. Additionally, a screen code compiler allows to type in mlboot.prg directly to screen space and run it there without the need to execute boot.txt first.

Additionally, the JoyStream is introduced to describe and execute sequences of joystick input via a special string language syntax. AutoType allows to type in arbitrary files or strings via the virtual keyboard of DTV’s basic prompt. A Screen Code compiler encodes an assembler program and directly types in the corresponding character codes on the screen to run it there.

Have fun!