ROM to RAM ToolKit Conversion

[tcat]

Hi,

I am still trying to relocate addresses, to avoid typing errors I prepared a small shell script, that computes offsets and values. It reads the dissassembly text file, and puts out respective DATA statements to be merged with S*BASIC relocation program posted here earlier.

Code: Select all

#!/bin/sh
# reports addresses [C000-10000] to relocate
# of QLC_ROM disassembly in file 'qlc_asm'
# origin at 3C000

num=1000
grep \$0000[C-F] qlc_asm |
while read ln
do
 # adr start   >|< here
 # 0003C068 247C0000C000                  move.l #$0000C000,a2
 off=$(echo $ln | cut -c-8)
 off=$(( 0x${off} - 0x3c000 + 2 ))
 val=$(echo $ln | cut -c14-21)
 val=$(( 0x${val} - 0xc000 ))
 printf '%d DATA "%x","%x"\n' $num $off $val
 num=$((num+10))
done

While I believe I probably relocated most addresses correctly, there must be much more to it, as S*BASIC words are recognised, but Latice PHASE 1 or 2 does not get loaded as they should.

e.g.
lc1 'mdv2_' should bring copyright message and 'file not found' error, instead it reports 'out of memory'.

I wonder what tricks QLC_ROM does with binary files P1 or P2 containing the compiler code in order to execute them?

Tom

[tcat]

Hi,

I wish to debug the relocated code of the QLC_ROM loaded into RAM.

I want to begin with LC1 procedure, that starts at offset $C0 from the base. Using C1M monitor seems ideal for the task, so I can trace from the offset $C0 down.

Early in the code, the routine takes command string from the parameter list, making call to vectored routine CA.GTSTR

I wish to pass a parameter string to it like this ...

Code: Select all

'mdv2_ mdv2_hello'

Question is, how do I set up the parameters in the stack before tracing the code?
In other words, how do I debug S*BASIC extension?

Many thanks
Tom

[pjw]

tcat,

Find the address of the extension you want to trace (various utilities do that). Start monitoring job #0 (or the relevant SBASIC daughter job). Set a breakpoint at that address. Then call the extension with your desired parameters.

Per

[pjw]

For extension (above) read keyword. I use JMON, which is a version of Qmon, I believe. This may be a commercial program, I no longer remember. Presumably your debugger will have similar facilities.

So, I find the address of the keyword (In my example the function TX2CD$) using IDIS'es WHERE "TX2CD$". (If you need help with finding the keyword address, give a shout.) Say Im using job #0, the main S*BASIC job, and the keyword address is at $13B720. I give the command JMON 0, to monitor job #0. Then, in JMON, I set the break point: b 13B720. Then I let the monitor/debugger loose with the GO command (in JMON: g). Going back to S*BASIC I type the keyword, in my example case: PRINT TX2CD$('abc'). JMON pops up and stops at the break point. At that point (a6,a3) points to the name table entry of the first parameter, and can be read at the address pointed to by the 2nd long word therein, or you can step through the instructions and wait til the function fetches the parameter, and read it from the S*BASIC stack at (a6,a1)..

IHTH

Per

[Silvester]

Re QLC ROM to RAM conversion :

Sorry Tom, but I think things may be trickier.

Out of curiosity I had a quick look with DISA and although it is possible to convert all the absolute JMPs and JSRs to PC-relative, there is an unreferenced table of JMPs at $C800. I can only guess other QLC files must make the direct reference to them (hence the neatly rounded $C800 address).

If I am correct, you would then have to patch the files each and every time you loaded the modified ROM code at whatever place in RAM it resided.

Attached listing shows all JMP/JSR changes done (each padded with a NOP).

[tcat]

Silvester,

Thank you for your help.

Besides, it is amazing what DISA can do, so far I used disassembly produced by C1M, QDOS calls annotated by hand with the help of QL Technical guide. It can also identify S*BASIC procedures, and ROM headers.

I have spotted a row of JUMPs in the code as well, not knowing about 'JUMP TABLES' then.

These long JUMPS are referenced from within the ROM code too, as I tried randomly to check. I believe such tables with long jumps may pose a solution to overcome 64K code limit, but within 16K ROM, I cannot think of what use they might be.

I tried to reassemble your file, suprisingly it compiles only into 4678 bytes of code.

I have traced the whole LC1 procedure using C1M.

The procedure seems to load P1 file (Lattice C Phase 1), create a job for it (MT.CJOB), and pass on the parameters from the command line. But with relocated code does not work so far.

Many thanks
Tom

[Derek_Stewart]

Hi,

In SMSQ/E there is a command called EPROM_LOAD, which will load Erpoms into memory.
The SMSQ/E manual indicates that the rom image should be loaded into a RESPR area and SBYTEd to a new file.

I have tried this on Pro Fortran F77 and Pascal, which seems to work. I wonder if EPROM_LOAD does all the resolving of relative jumps.

[Silvester]

I couldn't find any reference to the location of the jump table from within the rom code. Quite often the reference can be very indirect, but I didn't see that either. Its location has been deliberately padded out to place it at $C800 (for external reference).

To be honest my first thought was 'why do they use a rom?' As you have noticed, not much of the 16K is used (hence small asm, rest of rom was nonsense and so was not included). So it is not as if they were looking for extra space on limited 128K QL. Therefore it looks like it was done to tie the package to the rom.

I have had a quick look at the QLC documentation (poor scanned copy on web) but it didn't state rom was required for runtimes etc. Perhaps it is, I've never used QLC, only C68 on QL.

[Silvester]

> I wonder if EPROM_LOAD does all the resolving of relative jumps.

I think it just copies eprom image to ram at $C000 so doesn't need (or attempt!) to resolve absolute jumps. Must admit I don't think I've ever tried EPROM_LOAD

[tofro]

The command doesn't do anything beyond loading the ROM file into the memory starting at $C000 in case it is the first EPROM_LOADed file. All others are loaded to arbitrary addresses.

Relocating a binary file containing absolute addresses, jumps and jump tables that has not been prepared for relocation (i.e. addresses and jumps marked as such) is a task no computer can do - You need to disassemble and understand the code.

Tobias