ROM to RAM ToolKit Conversion

[tcat]

Hi All,

Has anyone thought of converting ROM ToolKits into their RAM versions? Using RAM version would not require plugging ROM dongle into a QL slot.

I already tested standard TK2 by loading it into RAM and calling its initilisation routine by skipping ROM header - $4AFB0001 (pls see QL Technical Guide 2.4 and 8.0)

This works with TK2 ROM extension w/o need of any conversion as described at Dillwyn's site.

Code: Select all

ADR=RESPR(16384)
LBYTES TK2_EXT, ADR
CALL ADR + PEEK_W(ADR+6)

This possibly requires the ROM code is pure relocatable. But how about some other ROMs namely Metacomco? Is there a way to provide RAM version easilly for them?

I looked at QLC_ROM it has this header, the word pointer at offset $6 is actually $0000, which does not make much sense as it cannot be initialised at that offset.

Code: Select all

00000000  4a fb 00 01 00 26 00 00  00 00 20 20 20 20 20 20  |J....&....      |
00000010  20 20 20 20 51 4c 43 20  20 56 65 72 73 69 6f 6e  |    QLC  Version|
00000020  20 33 2e 30 32 0a 00 05  00 32 03 52 4f 4d 00 92  | 3.02....2.ROM..|

The ROM gets initialised under uQLx emulator on startup normally, but it does not put up Metacomco copyright message on F1/F2 screen, though.

Following Metacomco QLC manual, ROM command verifies its integrity, and it reports ROM is alright.

Many thanks
Tom

[tofro]

Hi All,
I already tested standard TK2 by loading it into RAM and calling its initilisation routine by skipping ROM header - $4AFB0001 (pls see QL Technical Guide 2.4 and 8.0)

This works with TK2 ROM extension w/o need of any conversion as described at Dillwyn's site.

Code: Select all

ADR=RESPR(16384)
LBYTES TK2_EXT, ADR
CALL ADR + PEEK_W(ADR+6)

This possibly requires the ROM code is pure relocatable. But how about some other ROMs namely Metacomco? Is there a way to provide RAM version easilly for them?

I looked at QLC_ROM it has this header, the word pointer at offset $6 is actually $0000, which does not make much sense as it cannot be initialised at that offset.

Code: Select all

00000000  4a fb 00 01 00 26 00 00  00 00 20 20 20 20 20 20  |J....&....      |
00000010  20 20 20 20 51 4c 43 20  20 56 65 72 73 69 6f 6e  |    QLC  Version|
00000020  20 33 2e 30 32 0a 00 05  00 32 03 52 4f 4d 00 92  | 3.02....2.ROM..|

Tom,
beyond the (optional, 0 means "unused") pointer to the ROM initialisation code, a standard QL ROM header contains a bit more information.

PEEK_W (base + 4) contains a (relative) pointer to a list of BASIC procedures and functions in the ROM that are linked in to the operating system if that pointer is valid. ROMs can use that alternative way to link into the system. This makes it a bit harder to load this ROM into RAM, but it is still possible. One could write a small piece of code using vector BP.INIT to link in those procedures or simply use EPROM_LOAD available in SMSQ/E that basically does the same thing. If the ROM code does, however, assume that it will be fixed to $C000, that would not work on a standard QL and only for the first ROM loaded with EPROM_LOAD on a suitable SMSQ/E machine.

The QLC ROM has that BP.INIT table at (base + $100). (The Prospero Pascal/Fortran ROM does something similar, but still has an initialisation routine)

In case the ROM code is however, compiled to fixed addresses $C000 and above (i.e. position-dependant code), you're doomed on a standard QL however, and would need to disassemble and completely rebuild the code.

Regards,
Tobias

[tcat]

Hi Tobias,

Thank you, following your guidance, I coded this little snippet

Code: Select all

; INIT_ASM simply calls BP.INIT
; usage from BASIC: call [address],[^list]
; d1-pointer to list of BASIC procedures and functions

        movea.l d1,a1           
        movea.w $110,a2         BP.INIT
        jmp     (a2)

        end

And this appears to link the BASIC procedures from QLC_ROM alright

Code: Select all

a=respr(16384)
b=respr(20)
lbytes qlc_rom,a
lbytes init_bin,b
call b,a+38

All extra QLC_ROM words appear as linked and I need to do further testing, e.g. ROM now reports BAD_ROM, but that's possibly because check sum has changed by relocating the code into RAM.

Also it might be an idea to patch over ROM header with a similar code as above, so simple LRESPR will work over it.

What I do not quite understand is, why I have to JMP(A2) to BP.INIT rather than JSR(A2) to it? This is how vectored utilities are documented in the QL Guide.

Cheers and thanks
Tom

[NormanDunbar]

Hi Tom,

Code: Select all

What I do not quite understand is, why I have to JMP(A2) to BP.INIT rather than JSR(A2) to it? This is how vectored utilities are documented in the QL Guide.

You can do either. If you JSR you'll need a spare RTS on return from BP_INIT. If you JMP then the RTS at the end of BP_INIT will return you to SuperBasic. (The caller in this case.) That saves you 2 whole bytes!


HTH

Cheers,
Norm.

[tofro]

Nice!
I like it, when I write "one could write a small piece of code" and someone just does it

Tobias

[tcat]

Tobias, Norman,

Thank you for your encouragement, I was probably keeping my hopes too high, as the ROM code contains quite a few abosolute long addresses. In the disassembly I spotted JSR, MOVE, CMP, JMP etc that I tried to relocate with a small BASIC routine.

As the ROM range is $C000 - $10000-1, any long addresses like below needs relocating from the new base of origin.

move.l #$0000C000,a2
jsr $0000C376
cmpa.l #$0000D254,a2
... etc.

Unfortunatelly, it does not work, either I have mistyped some offsets, relocated something I shouldn't or I am just doing something silly, is there a better way?

Thanks
Tom

Code: Select all

10 RESTORE 1000
20 adr=RESPR(16384)
30 LBYTES qlc_rom,adr
40 REPeat reloc
50   IF EOF THEN EXIT reloc
60   READ off$,val$
85   POKE_L adr+HEX(off$),adr+HEX(val$)
90 END REPeat reloc
1000 DATA "6a","00"
1010 DATA "82","14"
1020 DATA "4cc","ee"
1030 DATA "542","ee"
1040 DATA "1a6","376"
1050 DATA "26c","376"
1060 DATA "39c","560"
1070 DATA "3d4","58c"
1080 DATA "3ee","58c"
1090 DATA "408","58c"
1100 DATA "412","58c"
1110 DATA "498","598"
1120 DATA "4aa","584"
1130 DATA "4b0","57c"
1140 DATA "4ce","0ee"
1150 DATA "4dc","560"
1160 DATA "4ee","584"
1170 DATA "510","598"
1180 DATA "522","584"
1190 DATA "528","57c"
1200 DATA "542","0ee"
1210 DATA "54e","560"
1220 DATA "56c","57c"
1230 DATA "95c","bb4"
1240 DATA "9b8","bb4"
1250 DATA "9d4","bb4"
1260 DATA "a00","bb4"
1270 DATA "a58","bb4"
1280 DATA "a92","bd6"
1290 DATA "ad0","bd6"
1300 DATA "b38","bd6"
1310 DATA "b5c","bd6"
1320 DATA "bfc","ec2"
1330 DATA "c02","dc4"
1340 DATA "c0e","d96"
1350 DATA "c14","e8c"
1360 DATA "c3c","b92"
1370 DATA "c74","b92"
1380 DATA "caa","bd6"
1390 DATA "cf0","bd6"
1400 DATA "d9a","de4"
1410 DATA "dd0","e06"
1420 DATA "e64","b84"
1430 DATA "e74","b84"
1440 DATA "ef2","b84"
1450 DATA "11a0","b84"
1460 DATA "11b0","b84"
1470 DATA "802","b92"
1480 DATA "808","bb4"
1490 DATA "80e","bd6"
1500 DATA "814","c1c"
1510 DATA "81a","c5a"
1520 DATA "820","c7e"
1530 DATA "826","cc4"
1540 DATA "82c","d0a"
1550 DATA "832","d2e"
1560 DATA "838","d58"
1570 DATA "83e","dac"
1580 DATA "844","dd8"
1590 DATA "862","90e"
1600 DATA "86e","96e"
1610 DATA "87a","9e6"
1620 DATA "886","a0e"
1630 DATA "892","a66"
1640 DATA "89e","aa4"
1650 DATA "8aa","ae2"
1660 DATA "8b6","b84"
1670 DATA "8bc","de4"
1680 DATA "8c2","e06"
1690 DATA "8e0","f7a"
1700 DATA "8e6","edc"
1710 DATA "8ec","ec2"
1720 DATA "8f2","e8c"
1730 DATA "8f8","dc4"
1740 DATA "8fe","d96"
1750 DATA "904","c0a"
1760 DATA "90a","bf8"
1770 DATA "072","1254"
1780 DATA "84a","10c6"
1790 DATA "850","11c8"
1800 DATA "856","120a"
1810 DATA "8c8","10f2"
1820 DATA "8ce","1128"
1830 DATA "8d4","1006"
1840 DATA "8da","100e"
1850 DATA "da4","1128"
1860 DATA "dc8","10f2"
1865 DATA "e9e","10f2"
1870 DATA "ed4","1128"
1880 DATA "f0e","10f2"
1890 DATA "f1e","10f2"
1900 DATA "f40","1128"
1910 DATA "f9c","10f2"
1920 DATA "fac","10f2"
1930 DATA "fda","1128"
1940 DATA "1040","10f2"
1950 DATA "1050","10f2"
1960 DATA "10bc","1128"

[RWAP]

You could try using DEAssembler (DEA) - I seem to recall it has some utilities for working with absolute addresses in code

http://www.dilwyn.me.uk/asm/index.html

[NormanDunbar]

DEA was and is a pretty intelligent disassembler. But the operating procedures are pretty grim as I remember and I last used it 2 days ago then gave up and used Disa instead. Not quite as intelligent, but a nice piece if code.

I've never been really able to use DEA without the manual close at hand. Maybe it's just me, of course.

Regarding ROM relocation, I suspect there isn't really a better way. I remember, just, some years ago disassembling the CRUN procedure in Metacomco C, and it too has a relocater built in and the C programs after compilation had a table of offsets buried within that had pointers to the bytes, words etc that needed relocating.

Maybe your pseudo ROM code needs something similar and a relocating loader to update the offsets?

Cheers,
Norm.

[tofro]

Unfortunatelly, it does not work, either I have mistyped some offsets, relocated something I shouldn't or I am just doing something silly, is there a better way?

Nope. What you're doing is the right thing, albeit tedious..... - And there is no other way to do it.

Provided:

• You have identified the right offsets to relocate (simply looking whether an address is in the range C000-10000 might not be enough - You need to disassemble the instruction that works with that address)
• you did not mistype anything
• The ROM code does not check its own load address either directly or in some obfuscated (i.e. not directly recognizable way) - Which I somehow fear is the case

Tobias

[Derek_Stewart]

Hi,

What you are trying will work, but is very hard to get right and I think it would take a long time get working.

Probably the better solution would be to disassemble the binary code and change the absolute addressing and reassemble the file.

I will have a try at dissassembling the QLC code, which I usually disassemble most thinkgs in SMSQmulator and DISA.

This has more problems, in that knowledge of QL hardware and 68000 assembly language is required.

I have DISA and DEA, I prefer DISA, but DEA have some nice features, though the interface is harder to use.

The other advantage of DEA, is that it is free, where as DISA is still commerical.