Import of binary file does not set address in file header.
Logged In: YES
It is worse than that.
When you export a binary file, the resulting .DUMP file does
not contain the start address or length.
If you are trying to move a binary between disks, e.g. in my
case I was trying to move from Unidos to DOS 3.3 formats,
then the binary file won't run.
You MUST save the start address somehow. It *IS* part of
the overall binary file.
As you point out, when trying to enter a start address via the
Import dialog box, it does not get written to the file (just a
pair of 00 00 bytes)
I think this makes the priority more like a 9 (showstopper)
The only way I've figured out to work around this is to hack
the resulting DSK file with a binary editor (in my case
MultiEdit) to put back the correct start address once I've
viewed the source data in Raw format within
AppleCommander. Of course, this is a huge pain in the
backside, especially when trying to move lots of files across.
Let me say that I think AppleCommander is a really neat
program. I'm still not 100% sure why you chose Java
(platform independence with a GUI I guess).
What development environment (complete list of software)
are you using ? I was thinking about trying it in Borland
JBuilder X (free download of their Foundation version), but
want to know what I'm up against before I get too seriously
Logged In: YES
I *was* going to suggest you try the raw disk format... but
that is crashing my JVM. So, you're definately correct on
I chose Java since that is what I've been developing with for
quite a while - plus it's cross-platform. It has given me some
experience with the SWT windowing toolkit also. I've been
swamped with work and life so haven't had a chance to get
back into it lately...
I've been using Eclipse to develop AppleCommander. It hooks
directly into CVS, so if you want the play with the code,
download it. Better yet, give Eclipse a whirl!
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.