[CSDb] - User Forums - Hermit Reloc-aid

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Hermit Reloc-aid

2009-11-03 15:51

Hermit

Registered: May 2008
Posts: 208

Hermit Reloc-aid

Dear Mates

Recently I had some tunes to be relocated.

As I couldn't find any appropriate tool to relocate
these old tunes (Galway, Joseph Richard, Hubbard,...),
I had to start writing a universal relocator.

Now it is useful to relocate the tune automatically,
leaving only some minor changes left for the user (coder), like setting pointers used for zeropage-indexed memory-calls.

If anyone need the code, I can upload it or send it as source code or as compiled code. It's NOT a COMPLETE TOOL, as doesn't include any loader/setting parts, settings and load/save can be done within assembler/IDE/monitor..
(I use 64tass cross assembler for fast work + VICE+Final Replay cart-image.)
The name 'Reloc-aid' comes from the fact that it saves much work for you, but doesn't do all the stuff. I had success with it for really old tunes, maybe you'll also have with enough reverse-coding/disassembling knowledge.

I'll tell what the workflow is, to get a tune relocated:
-------------------------------------------------------

-It distinguishes which is data, which is code, which data/code isn't used, and first makes a 'mask' with this information. (This is PASS1, the maskmaker...)
How this works?
Of course it runs the selected subtune, and breaks it at every command with an exactly timed one-shot CIA interrupt (on a non-badline!). I recommend to use VICE in warp+nosound mode here, as it takes a while for the tune to end or loop.
(The maskmaker takes the addressing-mode of command-opcodes from my pre-defined table.) Maskmaker simply ends with RUNSTOP-key.

-At PASS2 it simply changes all the absolute-addressing operands (addresses), even indirect-JMP addresses. This was the easy part, without much interaction needed from user.
(At relocation the mask is copied back to the source-range, and if you set, the unused areas remain zero (!) at target location for better compression later.)
Here I recommend to save the relocated tune and especially the mask to prevent doing PASS1 again.)

-PASS3: However (depending on tune) some pointers left unchanged in memory (used for zeropage-indexed (Y) instructions). These are hard to determine by software (this would need to virtually 'rewind' the CPU), but at least I made a function (follow mode 3) to run the relocated tune again, and stop it at every memory reads/writes that are still addressing memory in the original (source range) place.
At this stop user is prompted about the PC address, command, operand, registers.
The manual work starts with freezing/resetting the machine, and search+modify the pointers in memory. This needs well skilled coding knowledge, who did relocation before know what I mean.
Here the register/pointer info and mask can help a lot (with 'h' command of monitor, you can find self-writing codes or zeropage-pointer modifiers in the mask therefore also in routine).
After eliminating a 'stopping point', you have to start the tune again in this mode, and it will stop again, if the outside-call appears again.
You have to repeat this ('stop'+'search'+'modify'+'restart') process until all remaining (wrong) pointers are corrected by you. I recommend to save/write down the modifications that ended with success.
(Generally I found around 4...20 databytes in tunes that had to be changed manually after PASS2).

Here we are ready, our tune can be used in our proggy.

Appendix :)
-----------
the PASS1 recognises and signs these types into the 'mask' (this is an extract from sourcecode-comment):
;---------
;PASS1 ;write modifying-mask into target area
;mask: 0:will be left at moving, no used code/data here (shrinked parts)

;command/operand bytes (section 1.)
; 1-code/operand byte, that we'll never modify
; 2-absolute operand-bytes pointing into source range, always modify!
; 3-..(indirect operand pointing into source range)
; 4-..operand of immediate addressing command, maybe modified if affects indirect 0pg-pointer

; 5-absolute addressing command-byte, don't modify
; 6-..command-byte for indirect addressing (point 3) , don't modify
; 7-..immediate addressing command-byte , don't modify

;data-bytes
; 8-absolute/absX/absY/indirect addresed databyte, don't modify
; 9-zeropage-indirect X/Y indexed databyte,don't modify
; a-..(pointer-hi databyte, modify)
; b-..(pointer-lo databyte, modify)

;command/operand bytes (section 2.)
; c-zeropage writer command ('L')
; d-operand of zp-writer command ('M')
; e-zp-pointer modifier STA/STX/STY ('N')
; f-self writing code (operand modifier (absolute addressing) command)

If there's interest for this 'aid' (not 'tool') I'll upload it onto my homepage or CSDB (source+binary).
You may ask for it in this topic.

I use it with 64tass & VICE like this:

http://hermitsoft.uw.hu/doc/Hermit-reloc-aid.jpg

----------------------------------------------
Hermit Software Hungary

... 10 posts hidden. Click here to view all posts....

2009-11-05 23:19

Stone

Registered: Oct 2006
Posts: 172

Sounds like an awesome tool you've created there, but why do you use the CIA timer for breakpoints, why not the BRK instruction? I haven't looked at your code, so I may ofcourse be missing something...

2009-11-06 11:21

Ninja

Registered: Jan 2002
Posts: 411

I use the dis-/reassembler from 64copy (I still use V4.00 because I didn't like some changes in the newer versions, but haven't really checked for a while). It enabled me to quickly get recompilable sources for tunes I wanted to use in demos (it has autolabeling and such). That was very nice because I could save a few rasterlines, both in average and max \o/

2009-11-06 11:50

Hermit

Registered: May 2008
Posts: 208

A well working autolabel-function is what I'm dreaming about...I'll try the tool Ninja uses...

@Stein: The music-routine has to be stopped before every new command to let analysing them step-by-step. The CIA timer is making an IRQ in the 'middle' (1 or 2 cycles after start) of the actual command to make sure getting back to IRQ after it.
I don't have idea how I could realize this '1 cycle-delayed' IRQ with 'brk'. If you have, I'm curious what you found out..

My first thought was to emulate 6510 on C64 itself, but that would be very slow, and would require more RAM.

This is similar to stepping mode in VICE-monitor, but it's realized natively in C64 code.. the disadvantage that you cannot relocate program that uses the CIA1-TIMER1 and IRQ. As we are talking about tunes, they shouldn't use this, or you should find the playroutine-entry points for CIA-timed SIDs..

I agree a cross-platform tool with 6510 emulation would be the best in regards of speed and flexibility. And the next AI-part that does the remaining work, could be solved easier on PC.. maybe later.

Hermit Software Hungary

2009-11-06 12:11

JackAsser

Registered: Jun 2002
Posts: 2014

Quote: A well working autolabel-function is what I'm dreaming about...I'll try the tool Ninja uses...

@Stein: The music-routine has to be stopped before every new command to let analysing them step-by-step. The CIA timer is making an IRQ in the 'middle' (1 or 2 cycles after start) of the actual command to make sure getting back to IRQ after it.
I don't have idea how I could realize this '1 cycle-delayed' IRQ with 'brk'. If you have, I'm curious what you found out..

My first thought was to emulate 6510 on C64 itself, but that would be very slow, and would require more RAM.

This is similar to stepping mode in VICE-monitor, but it's realized natively in C64 code.. the disadvantage that you cannot relocate program that uses the CIA1-TIMER1 and IRQ. As we are talking about tunes, they shouldn't use this, or you should find the playroutine-entry points for CIA-timed SIDs..

I agree a cross-platform tool with 6510 emulation would be the best in regards of speed and flexibility. And the next AI-part that does the remaining work, could be solved easier on PC.. maybe later.

Hermit Software Hungary

When using brk for implementing a debugger you traditionally dynamically alters the code in front of you and insert brk's, then behind you, you restore the code. I think your method is more nice since you automagically get interrupts exactly between opcodes (that's the way the 6502 irq works), but with the brk-method one would have to parse the instruction code and insert the break either 1, 2 or 3 bytes forward (one simple 256-byte table ofcourse, but still).

2009-11-06 13:00

Stone

Registered: Oct 2006
Posts: 172

Like JackAsser said, modifying the code at each step with BRK instructions seems to me like the simplest way of single-stepping through the code. I guess with your method you don't have to analyze jump and branching instructions at each break, so it's neat in that way ;-)

2009-11-06 22:35

Stryyker

Registered: Dec 2001
Posts: 468

I don't see how BRK would make things any easier. Every time it did something you would need to write back the original opcode then fix the return address for the interrupt. BRK has a parameter so it is treated like a 2 byte operation.

2012-03-31 20:40

Jak T Rip

Registered: Feb 2002
Posts: 39

Hermit, it seems I shouldn't tell you about our unfinished projects or you'll redo them faster than we can finish them ;-)

So let's write about them even more so that everyone can overtake us :)
DMAgic is working on two unique tools:
- a universal relocator that does not (need to) detect code/data areas
- an updated version of omikron reassembler that has very good code/data detection, produces relative labels and provides some info on IO settings

Anyhow, great work so far, Hermit. I wonder how you detect the code areas...?

2015-12-14 23:35

AlexC

Registered: Jan 2008
Posts: 299

Sorry for re-discovering this old thread but I do wonder what is the status of this "new" turbo reassembler. Has it been released ever?

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread: