Adding non-reloc tables to RAMTOS/SELTOS

Started by shazz, 29-12-2024, 16:52:47

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

shazz

Hi,

I'm trying to add support for TOS 2.06 FR in RAMTOS/SELTOS but I'm stuck on the non-relocated addresses table, I understood the goal of this table but looking at existing tables, I don't understand the "search pattern".

Can you give me a concrete example on how to spot those addresses that should not be relocated then I'll build the full table?

For German TOS 1.0
$17c8: bsr.w $fc18c6        (61 00 >00 FE)
$17d8: move.b #$fe, (a2)+  (14 FC >00 FE)
$252e: andi.#$fe, ccr      (02 3C >00 FE)

I see a pattern with instructions finishing with $00FE, is it the pattern to look for ? $00FE for TOS 1.x and $00E0 for TOS 2.x ?

For example is TOS 2.06 Swedish, I don't understand why:
- $e013ce 03f800e0        bset.b    d1, $e0.w  => $13d0 is in table
- $e106dc 4cdf00e0        movem.l    (a7)+, d5-d7 => $106de is in table, why ?
but
- $e00f5a 21ce00e0        move.l    a6, $e0.w  => $f5c is not in table

Thanks !
  •  

Petari

Welcome to the 16/32 bit, pardon - 8-bitchip forum  :)
I dealt with this some 16-18 years ago, so needed to look about details.
What remember well is that I used Steem Debugger (v 3.2) for developing it. It has very well made search and trace functions.
 So, I looked with it Swedish TOS 2.06 . What is there are not instructions, but address table . Something present in all TOS versions . And that wold be opposite case of non-reloc addresses - even if looks as instruction opcode it is not it, but TOS ROM address, what is used in some operations (if you try to find it in TOS content, it may not work - there are functions which start with concrete address, and then it is just increased by some address register, so can not find it).  My experience with disassembling TOS (started with 1.04) was big help in this.
 Well, another case where I saw how good tool Steem Debugger is . Thanx authors - Hayward brothers.
  •  

shazz

#2
Thanks :)

For example in the Swedish TOS, the movem.l looks to be a real instruction restoring the stack and not a dc.l table, no ?

$e106bc 207c00e35692     movea.l    #$e35692, a0                            ; 6
$e106c2 7207             moveq      #$7, d1                                 ; 2
$e106c4 b098             cmp.l      (a0)+, d0                               ; 2
$e106c6 57c9fffc         dbeq       d1, $e106c4                             ; 4
$e106ca 2068001c         movea.l    $1c(a0), a0                             ; 4
$e106ce 4ed0             jmp        (a0)                                    ; 2
$e106d0 ba6e000a         cmp.w      $a(a6), d5                              ; 4
$e106d4 6d00ff12         blt.w      $e105e8                                 ; 4
$e106d8 3005             move.w     d5, d0                                  ; 2
$e106da 4a9f             tst.l      (a7)+                                   ; 2
$e106dc 4cdf00e0         movem.l    (a7)+, d5-d7                            ; 4 <= this one
$e106e0 4e5e             unlk       a6                                      ; 2
$e106e2 4e75             rts                                                ; 2

In case of, I wrote a script to disassemble the TOS (but for sure it can confuse instructions and tables) and extract the possible addresses.
For Swedish TOS 2.06 the script extracted:

    dc.l    $89a                ; bsr.w  $e0097a
    dc.l    $f5c                ; move.l  a6, $e0.w => not in your table
    dc.l    $13d0               ; bset.b  d1, $e0.w
    dc.l    $1bca               ; bcs.w  $e01cac
    dc.l    $1d3a               ; and.b  #$e0, d0
    dc.l    $1d3e               ; and.b  #$e0, d1
    dc.l    $1df0               ; and.b  #$e0, d1
    dc.l    $1df6               ; and.b  #$e0, d0
    dc.l    $229c               ; bsr.w  $e0237c
    dc.l    $6bee               ; beq.w  $e06cd0
    dc.l    $742a               ; roxr.w  $e0.w => not in your table
    dc.l    $13334              ; bra.w  $e13416
    dc.l    $1585e              ; bra.w  $e15940
    dc.l    $1a988              ; bra.w  $e1aa68
    dc.l    $2418c              ; beq.w  $e2426c
    dc.l    $27266              ; beq.w  $e27348
    dc.l    $2aa2a              ; beq.w  $e2ab0c
    dc.l    $2b060              ; bra.w  $e2b140
    dc.l    $32860              ; ori.b  #$e0, d0 => looks to be bitmap data
    dc.l    $35412              ; ori.b  #$e0, d1 => not in your table, looks to be bitmap data
    dc.l    $354a6              ; or.b  $e0.w, d4 => not in your table, looks to be bitmap data
    dc.l    $354be              ; adda.w  #$e0, a1 => not in your table, looks to be bitmap data
    dc.l    $3566a              ; sub.l  d1, $e0.w => not in your table, looks to be bitmap data
    dc.l    $36566              ; ori.b  #$e2, d0 => not in your table, looks to be bitmap data
    dc.l    $3668a              ; cmp.w  #$e2, d0 => not in your table, looks to be bitmap data
    dc.l    $366e2              ; eor.w  d4, $e2.w => not in your table, looks to be bitmap data

Not so different from yours but movem.l were excluded
  •  

Petari

You can not write simple script what will recognize exact original source code - things would be much easier if we have access to source code - but that's done in C, not in ASM . And you may look about TOS 2.06 sources.
 
 I tried with some much newer disassemblers - like after 2018, and they did not recognize tables. Maybe there will be some progress in all it - if someone is interested about such thing in ancient CPU code ...
 All I can say is still: lot of hand work, time is needed for it to be proper. I did all it myself, and not only for 1 TOS version. 
  •  

shazz

#4
Yeah of course, the goal was to have less manual work to do then to debug and fix the addresses which cannot be discovered automatically.
And so, in 2024, disassemblers are still very bad to detect tables :D

Anyway, it helped me to spot the differences with other TOS versions you already carefully manage. And I need to do more tests but at least the TOS206FR boots and starts the GEM. So a good start.


  •  

shazz

#5
@Pera,

I think this is expected but in case of, better to check.
When a TOS is active in RAM using RAMTOS, I noticed that some programs don't work anymore:
- imgrun Image Runner (using IMGRF2.PRG while TOS2.06 in RAMTOS)



- at boot, your HD driver works but ACSI2STM built-in boot to set the Gemdrive doesn't

Do you think this is something that can be fixed?

  •  

Petari

 Lot of SW works not with TOS in RAM. And it actually can not be fixed in RAMTOS self. For instance because SW what works not accessing TOS in ROM .  And don't forget that plenty of SW works not with all TOS versions.
 I fixed lot of such incompatibility problems. But fixing SW for TOS in RAM is harder.

 GemDrive surely works not with TOS in RAM, it is coded for TOS in ROM . However, regular hard disk drivers should work with TOS in RAM, maybe not all of them. And to add that GemDrive is not so good solution as regular (AUTOboot) hard disk drivers, right because lower SW compatibility.
  •  

shazz

Thanks Pera. Understood.
Yeah, an Atari is not an emulator, it cannot be something else easily :)

About Gemdrive, on my ASCI2STM, I'm using your SD image to set partitions (C,D,E) then another SD card to mount the builtin ACSI2STM Gemdrive partition (N) used a temporary drive to copy from my PC to the D and E partitions.

  •  

Petari

 No need to use another SD card to be able to do file transfers with some modern, popular computer, OS - with my partitioning/driver SW, images since 2012 - they are TOS/DOS FAT16 compatible. So, if you attach such SD card to some PC with Win, Linux , to Mac,  will be able to do file transfers with their file tools. Only restriction I saw was Windows restriction to only first partition of attached SD card. Why was it made ? Really have no clue. Of course some solutions to override it appeared. 
CFAdisk
That makes Window seeing all partitions on removable, so SD, CF cards too . Not needed for latest versions of Win10,11 - where that flaw is corrected.

  •