| Brutal Deluxe OMF Analyzer for Multi-Segment Files [message #394979] |
Mon, 25 May 2020 22:54  |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Antoine,
This is just a note of thanks for your (and Olivier's) OMF Analyzer tool
and the instructions and examples you prepared on your site.
< http://www.brutaldeluxe.fr/products/crossdevtools/omfanalyze r/>
I've lately been working with Apple's LaserWriter printer driver and
testing some patches for it to work directly (rather than over an
AppleTalk network), and being unfamiliar with multi-segment GS/OS files
was struggling to explain the behavior of some of the code I was seeing.
Ewen's BrkDown does a great job dividing the file into its segments and
disassembling them, but I was puzzled when I examined (and patched)
certain of the bytes in the file.
Not until I found your tool and finally started to grasp what a
relocation dictionary was did things finally start to make sense. I now
know that there are certain parts of that code that can't be patched
willy-nilly, as I've many times done with 8-bit stuff.
Those of you who write 16-bit software for GS/OS really have my respect
for your technical prowess. Weekend warriors need not apply!
Hugh Hood
|
|
|
|
|
|
|
|
| Re: Brutal Deluxe OMF Analyzer for Multi-Segment Files [message #394986 is a reply to message #394979] |
Tue, 26 May 2020 02:51  |
spectrumdaddy
Messages: 191
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Hugh Hood,
> Ewen's BrkDown does a great job dividing the file into its segments and
> disassembling them, but I was puzzled when I examined (and patched)
> certain of the bytes in the file.
As always, I am, just glad my software is actualy being used.
> Not until I found your tool and finally started to grasp what a
> relocation dictionary was did things finally start to make sense. I now
> know that there are certain parts of that code that can't be patched
> willy-nilly, as I've many times done with 8-bit stuff.
It does rather seem like magic at times, that the code might land up
anywhere in memory, yet be automatically relocated so it works. As you
found, it is only the referenced code that nees the bytes to be
adjusted, and not blocks of data. For BrkDown, I actually load the
program into memory, so the relocation has already been applied, then
when labels have been applied, it can becone source code that will allow
the program to work if assembled again.
The problem though with any dissasembler, is trying to work out what is
data and what is code, and in the case of a 16 bit program, whether a
section of code is in native 16 bit mode, or 8 bit mode. If you run
across a section of data, the disassembler will attempt to make sense of
the data as code, and might make a mess of what follows. Usualy there
will be a label following a section of data where code starts again, so
you can define what follows as code, and so forth.
> Those of you who write 16-bit software for GS/OS really have my respect
> for your technical prowess. Weekend warriors need not apply!
It seems to have been a life-times work, for the last forty years at
least for me, and as I have not stopped, that rules me out of that
description!
Cheers - Ewen
|
|
|
|
| Re: Brutal Deluxe OMF Analyzer for Multi-Segment Files [message #395493 is a reply to message #394985] |
Sat, 06 June 2020 17:28 |
Christopher G. Mason
Messages: 156
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 5/26/2020 1:47 AM, Antoine Vignau wrote:
> Hi again Hugh,
> I read the thread on csa2.programmer and you should read the lw and new.lw source code,
>
> av
>
All nicely documented too. The question I have is that the driver
mentions color in the comments, but does the IIgs LaserWriter driver
actually support color printing? All I've ever gotten out of it was gray
scale from color laser printers and file output.
|
|
|
|
Members
Search
Help
Register
Login
Home
