Ultimate Amiga

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: "re-sourcing" AMOS Code?  (Read 5330 times)

0 Members and 1 Guest are viewing this topic.

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
"re-sourcing" AMOS Code?
« on: January 30, 2013, 08:56:03 AM »

Hi guys,

I was just wondering if now that you have the original source, and you are in the process of re-building AMOS if there is any potential for an AMOS pro "disassembler" to generate AMOS code from compiled programs?

I realise you may have some blanks to fill in where extensions are used, but maybe even then a solution can be found, if there is a way of working out which have been used in the compiling (assuming there is some kind of "footprint")

It would be quite nice for getting inside some games compiled back-in-the-day!
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Gender: Male
  • Posts: 425
  • WINUAE Amiga User
Re: "re-sourcing" AMOS Code?
« Reply #1 on: January 31, 2013, 07:33:49 AM »

if there is any potential for an AMOS pro "disassembler" to generate AMOS code from compiled programs?

Aaw, that's a tall order.  Haven't looked too hard at the compiler yet but it does do some optimisations here and there.  That's good for the compiled code but harder to 'disassemble' back to the AMOS language.

Bear in mind that disassembling to ASM source is a piece of cake compared to what you're suggesting.  It does use discrete chunks of code (the stuff in the main libraries and extensions, each chunk representing an instruction, separate and loadable as position independent code).  That should be relatively easily recognisable so it could be done.  But what you'd get would have no recognisable variable names!  Just V001, V002, V003$, V004#, and so on for however many are used in the program.

Anything is possible, it's just the amount of effort that varies!  I'd think that it would be easier to use Resource on an executable to see to how it works.

In any case, we won't really know until we've been through all the sources and understand how it all works in detail.  We've got a 'big picture' view but there's one heck of a lot more work to do before we could get anywhere near what you're asking for.
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 307
  • Offline Offline
  • Gender: Male
  • Posts: 3,364
  • Don't forget... Ameboid's need love too!
    • AUW
Re: "re-sourcing" AMOS Code?
« Reply #2 on: January 31, 2013, 04:06:33 PM »

.  But what you'd get would have no recognisable variable names!  Just V001, V002, V003$, V004#, and so on for however many are used in the program.p

That would still be fine though - the program would still compile and you would simply need to 'assess' each variable as you go through the code...


Code: [Select]
Anything is possible, it's just the amount of effort that varies!  I'd think that it would be easier to use Resource on an executable to see to how it works.
anywhere i have tried resourcing AMOS compiled programs has come out rather messy!

Quote
We've got a 'big picture' view but there's one heck of a lot more work to do before we could get anywhere near what you're asking for.

True - and i appreciate the mammoth task ahead - I was just interesting in guaging a viewpoint on it - i had some success with a good Basic res-sourcing program back in the days when my portable device was a Psion 3A rather than a PSP!
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Lonewolf10

  • AMOS Extensions Developer
  • AMOS Dev
  • A2000
  • *****
  • Karma: 3
  • Offline Offline
  • Gender: Male
  • Posts: 618
    • http://www.aliensrcooluk.com
Re: "re-sourcing" AMOS Code?
« Reply #3 on: February 02, 2013, 08:56:07 PM »

if there is any potential for an AMOS pro "disassembler" to generate AMOS code from compiled programs?

It's a possibility... however you are asking us to fly before we can walk!


Bear in mind that disassembling to ASM source is a piece of cake compared to what you're suggesting.  It does use discrete chunks of code (the stuff in the main libraries and extensions, each chunk representing an instruction, separate and loadable as position independent code).  That should be relatively easily recognisable so it could be done.  But what you'd get would have no recognisable variable names!  Just V001, V002, V003$, V004#, and so on for however many are used in the program.

Anything is possible, it's just the amount of effort that varies!  I'd think that it would be easier to use Resource on an executable to see to how it works.

Having quickly looked at some of my executables in Notepad (on my laptop), extension names and other AMOS paths are stored near the end of the executable (if include AMOS.lib is selected in compiler?). Error messages are stored next (if the option is set to include them), with data/sound/music/sprite banks stored at the very end. Quick summary of how an executable appears to be stored:

 - ASM code (compiled AMOS code?)
 * String variables (followed by numeric ones?)
 - AMOS file paths (including default flash pattern)
 - A list of extensions (used in code, or just those available when compiled??)
 - AMOS banks (presumably in numerical order?)

Going back to sleep soon... I'm working this weekend :(

Edit: Just added the bit marked with an asterisk (*) at the start.
« Last Edit: February 02, 2013, 09:06:20 PM by Lonewolf10 »
Logged
Pages: [1]   Go Up
 

TinyPortal 2.2.2 © 2005-2022