Something I just knocked up today because it was useful to me. Give this an Anadisk dump (with sector IDs enabled) and it will produce a VDK file.
(If Anadisk couldn't read some sectors, then this program will put the sectors it could read into the correct places, so you may be able to recover something)
Run at command prompt as:
anadisk-to-vdk <source file> <target file>
eg
anadisk-to-vdk mydisk mydisk.vdk
Utility to convert Anadisk "dumps" to VDK
Utility to convert Anadisk "dumps" to VDK
- Attachments
-
- anadisk-to-vdk.zip
- (6.52 KiB) Downloaded 185 times
Re: Utility to convert Anadisk "dumps" to VDK
Hang on... That tiny program is 13kB and it does virtually nothing! How did we write programs to do anything useful in just 24kB or so?
Re: Utility to convert Anadisk "dumps" to VDK
Well, it's easy to explain.
Each opcode on the 6809 is 8 bits wide, while on a modern 64 bit architecture it takes 8 bytes, that's eight times the size.
Plus, code is not pure assembly, it rather targets a platform dependent layer of code, which has to be linked to the executable file. The good thing is that by only changing that layer, you can compile the same code on multiple platforms. The bad thing is that it takes more size again.
So there goes your 13kb.
Of course, if you do pure assembly coding you may get obviously more performance per byte.
Each opcode on the 6809 is 8 bits wide, while on a modern 64 bit architecture it takes 8 bytes, that's eight times the size.
Plus, code is not pure assembly, it rather targets a platform dependent layer of code, which has to be linked to the executable file. The good thing is that by only changing that layer, you can compile the same code on multiple platforms. The bad thing is that it takes more size again.
So there goes your 13kb.
Of course, if you do pure assembly coding you may get obviously more performance per byte.
Re: Utility to convert Anadisk "dumps" to VDK
Not quite - most 80x86 opcodes are still 8 bits wide. Some are 3 or 4 bytes wide (with prefixes etc) but those are the rarer op codes (some 6809 op codes were 2 bytes wide).
eg. ADC AL,02 is 14 02
Some of the operands will be 8 bits wide, but only if you're using 64 bit values.
The biggest problem is that everything is just very inefficient, because memory/disk space is so plentiful, so there's loads of stuff in that 13kB that isn't what I wrote. There are exception handlers, resource tables (even though I didn't add any resources), manifests, relocation tables, etc.
The program is actually about 5.6kB (a fair portion of this is exception handling, which I can't disable), the rest of the 13kB is Windows 'necessities' added on.
Note that I've actually linked to the MSVC runtime DLL, so it's a lot smaller than it should be - If I include all the functions statically - this tiny 83 line C++ program is 165kB... I wrote much bigger programs than that using the OS9 C compiler, and they definitely weren't that big !
eg. ADC AL,02 is 14 02
Some of the operands will be 8 bits wide, but only if you're using 64 bit values.
The biggest problem is that everything is just very inefficient, because memory/disk space is so plentiful, so there's loads of stuff in that 13kB that isn't what I wrote. There are exception handlers, resource tables (even though I didn't add any resources), manifests, relocation tables, etc.
The program is actually about 5.6kB (a fair portion of this is exception handling, which I can't disable), the rest of the 13kB is Windows 'necessities' added on.
Note that I've actually linked to the MSVC runtime DLL, so it's a lot smaller than it should be - If I include all the functions statically - this tiny 83 line C++ program is 165kB... I wrote much bigger programs than that using the OS9 C compiler, and they definitely weren't that big !
Re: Utility to convert Anadisk "dumps" to VDK
Sure, but you are working under a machine that is changing from one day to another, under different operating systems.
It's much different to have a machine that does not change anymore, like the Dragon. It's not inefficient, it's designed with other purpose in mind.
Of course, there's inefficient software out there, but you also get the chance to do more thing and for a wider audience.
It's much different to have a machine that does not change anymore, like the Dragon. It's not inefficient, it's designed with other purpose in mind.
Of course, there's inefficient software out there, but you also get the chance to do more thing and for a wider audience.
Re: Utility to convert Anadisk "dumps" to VDK
Most of the 'machine that is changing' stuff should be handled by the OS, not the application software.
It seems that most of it just because the linker/run-time-library authors just don't care. What is an extra 40-80kB or so on Windows nowadays?
It seems that most of it just because the linker/run-time-library authors just don't care. What is an extra 40-80kB or so on Windows nowadays?
Re: Utility to convert Anadisk "dumps" to VDK
Precisely, but for that you need that intermediate layer. The operating system does no magic, so you need to link the OS functions library so you can interface it.
Things aren't as easy as they were in the 80's.
Things aren't as easy as they were in the 80's.
Re: Utility to convert Anadisk "dumps" to VDK
This is going further off-topic, and is not about the most critical issue which is the library dependencies and their bloat, but you might enjoy this great piece on dissection of the ELF binary file format (not so different from the PE format used on Windows), and how to make a minimal executable on Linux: http://www.muppetlabs.com/~breadbox/sof ... eensy.html