Hi...!
A certain Maurizio <[EMAIL PROTECTED]> asked:
> I'm not a good programmer, i'm doing something in basic and nothing
> more.
> But i have a question: Why is so difficult to disassemble the dos2
> kernel?
> We can dump the bios to use it with an emulator but we can't look
> into it? why?
The problem here is not how-to-do-it, that's easy: take any debugger,
and you can look into the machine code in different ROM's.
On an emulator, this is even easier (apart from writing a good
emulator): you just USE those ROM's, but (for a large part) don't
really need to know what's in there. The same goes for applications:
if an emulator PROPERLY emulates a particular set of hardware parts,
everything should work on it, that uses THAT hardware, HOW that
software uses that hardware, is really not too important from an
emulator's point of view.
But when making a -really usefull, not a 'dump'- disassembly, there's
a whole lot of problems showing up, some examples:
In the code, you see:
put value xxx in memory location yyy
A bit further on:
get value from memory location (yyy+3)
test if this is zero
if not, do ....
if yes, do .... and do ...
What do these memory locations mean? Are they fixed? Are they just by
coincidence determined at compilation/assembly time of this code? Is
this yyy+3 location a 'random' address, independent from 'yyy', or
should this 'yyy+3' be 'whatever is used for yyy, and then 3 bytes
further in memory'?
In short: for a large part, you don't know these things. They're not
or poorly documented, application programs might use certain of these
addresses nevertheless, and add to that the complex things you can do
with machine code:
-You can use an address, that's not THAT address, but is coded as
'some other address, +some offset' in the source code.
-You can use routines that modify themselves
-The setup/initialisation of all these things is usually a highly
complex process
Than take 64Kbytes of machinecode (DOS2 kernel):
You can disassemble it in seconds with some Z80 disassembler on the
PC. But the assembler source you might get that way, is useless:
If you're lucky, you can find some assembler that assembles it to the
same original binairy code. But if you make ANY changes, because of
reasons like those mentioned above, the code produced then JUST WON'T
WORK. If you're lucky, you'll find out soon after you try it, but
often this would mean a bug, that will show up SOME other time.
To get an assembly listing that does succesfully assemble, even when
modified (little, or plenty), you have to at least understand what
parts of the produced code do what: what's code, what's data, what's
text, what tables/other data is in there, and where, how start/end
addresses are determined etc. etc.
In other words: for the larger part, you will have to UNDERSTAND many
of the details of how the whole thing works. For a DOS2 kernel, that
would mean having to understand most of all details that make up this
whole system: how file operations are processed, how disks are
accessed, what data structures are used for that, and not the general
principles here; THOSE are known, many of those details are not.
You might spend a couple of hours trying to figure out, how a couple
of dozen bytes (a short piece of code) fit in the entire thing. Then
multiply that with hundreds or thousands, and that would make a
complete DOS2 kernel disassembly a huge project. Even if divided
among a bunch of people, that still makes it very difficult.
Add to that the fact that you're talking about SYSTEM software, in
contrast to application software. If you don't get it exactly right,
and put that software in a ROM cartridge for instance, how are you
gonna fix it then when (serious?) bugs show up? If a game program
'screws up', you might have a machine hang, or a few files 'eaten'.
If a DOS2 kernel routine screws up, you might have a harddisk that
needs to be reformatted, where all files that were on it, are lost.
Are you prepared to take that chance for every important bug that
shows up? Ofcourse you're not.
So, such system software needs to be SOLID: checked, re-checked,
checked again, tested, checked again, tested several times more,
checked again, tested for a while, re-checked, and this for any
important change you make to it. Get the idea?
For anyone who wants to join in with such a project, I suggest making
a COMPLETE disassembly of DOS1 kernel first: many of the system
details used in DOS2 are somehow 'dictated' by what's done for DOS1.
I have done some important work here a couple of years back:
-I have a -partial- disassembly of a diskROM (mainly the part that
overlaps in a whole set of different diskROMs), which makes figuring
out the use of many of those undocumented memory locations and
variables a LOT easier.
-And I have an essentially complete disassembly of a DOS1 disk
'driver' (originally taken from a Philips NMS 8245 MSX-2), which can
be used to modify such a driver on a source code level, and is
easily made into a complete diskROM after that.
For instance, I used this once as follows: I had a Korean-built MSX-2
at my place for a while, which used a diskROM that I recognised as an
older type 'system part' (more bytes free in BASIC, but less
performance-optimised). This also used a disk controller I had never
seen in an MSX-2 before that: the Western Digital 1772 (even older
type than 1793 or 2793, worked perfectly though). For me, with all
this, just a couple of days were enough to produce a new diskROM for
this machine, using the same driver code, but with an optimised
system part (the same as those used in most MSX diskROMs), which made
normal disk operation a LOT faster. With the knowledge I had here,
the diskROM produced here worked 100% solid right away, like any
other separate or built-in disk-interface (I didn't hear any
complaints later on either). Just a matter of having the right
materials to produce it.
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page)
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
