How do I convert hex files to binary for use in the MK14 mame VDU emulator?

[777xxxx]

Originally Posted by SiriusHardware

If the file you are trying to convert spans several address blocks then the hex to bin converter may be generating a single binary file which spans all of the addresses from the lowest address in the hex file to the highest.

Can you provide a link to, or attach (as a .zip file) the actual hex file you are trying to convert, and then we may be able to suggest the required approach for that file.

ah, i see. ok, here:

[SiriusHardware]

OK, I recognise that file. Your problem is that it contains code in four distinct, different blocks, namely at

0880 onwards
0B00 onwards
0F00 onwards
FFFE onwards (2 bytes).

The last section (2 bytes at FFFE/FFFF) isn't actually needed as it is there to inform the keypad injection type loaders which address to execute from after loading, but it is fooling the converter into creating a really, really long file.

You could only represent that code file as a single binary file by creating one which spans from 0880 to FFFF with very small pockets of actual code and a lot of padding in between. Even if you took away just that part the converter would still generate a binary file spanning 0880-0FFF, and attempting to load it would result in some of the code being loaded into areas which aren't RAM.

This is why I was suggesting that the ability for MAME to load Intel Hex files natively would be particularly useful - no, I'm actually going to say - essential, in the case of the MK14, where the RAM is distributed as isolated little 'islands' instead of in one continuous run. Binary files are only useful for loading one continuous area of RAM in one go.

[777xxxx]

Originally Posted by SiriusHardware

OK, I recognise that file. Your problem is that it contains code in four distinct, different blocks, namely at

0880 onwards
0B00 onwards
0F00 onwards
FFFE onwards (2 bytes).

The last section (2 bytes at FFFE/FFFF) isn't actually needed as it is there to inform the keypad injection type loaders which address to execute from after loading, but it is fooling the converter into creating a really, really long file.

You could only represent that code file as a single binary file by creating one which spans from 0880 to FFFF with very small pockets of actual code and a lot of padding in between. Even if you took away just that part the converter would still generate a binary file spanning 0880-0FFF, and attempting to load it would result in some of the code being loaded into areas which aren't RAM.

This is why I was suggesting that the ability for MAME to load Intel Hex files natively would be particularly useful - no, I'm actually going to say - essential, in the case of the MK14, where the RAM is distributed as isolated little 'islands' instead of in one continuous run. Binary files are only useful for loading one continuous area of RAM in one go.

what about this file? its different. ive managed to load the hex file and save it as a small file but the .bin file is still hex. what do i need to do?

[777xxxx]

im not sure how to save it or what format to export it to...

[SiriusHardware]

It's the 'SC/MP Inside' image mapped at 0200-03FF by the addresses in the hex file. When successfully loaded the VDU would have to be configured to display the 0200-03FF RAM area in order to view it and I think it might necessary to turn SWAP PAGES on to arrange the two halves of the image in the right order.

I have to agree that HxD (if that is what 777xxxx is using and is what I have just been using) is absolutely shocking when it comes to loading and saving specific file formats and moving blocks of code around. It isn't intuitive at all.

When inside.hex is loaded HxD loads it at 0200 (as it should, because that this the address contained in the file).

If you do a 'Save' (which implies binary save) it saves from 0000-03FF as binary without asking you what range you want to save, so you end up with a 1024 byte (1K) file with the significant info stashed in the upper half.

You could try to copy the code from 0200-03FF down to 0000-1FFF and save only those 512 bytes as binary. In the short time I spent trying I couldn't see any way to do that. If anyone does know, please enlighten us.

Does anyone know of another Windows Hex editor which behaves more like the editor of an EPROM programmer's support software? The Dataman software has been mentioned but it seems absurd to have to load up actual eprommer support software in order to access a decent hex editor.

[Phil__G]

Try this:

[SiriusHardware]

That ought to be exactly 512 bytes I think, Phil. Oh sorry, you zipped it of course.

[SiriusHardware]

if Phil's done it right then you need to binary load it at address 0200 and there is no executable code, therefore no run address on this one. You just point the VDU at address 0200-03FF and the image will be there.

As said earlier you probably also need to activate SWAP PAGEs to show the upper and lower halves of the image in the correct order, also Graphics (not character) mode needs to be selected.

[777xxxx]

Originally Posted by SiriusHardware

if Phil's done it right then you need to binary load it at address 0200 and there is no executable code, therefore no run address on this one. You just point the VDU at address 0200-03FF and the image will be there.

As said earlier you probably also need to activate SWAP PAGEs to show the upper and lower halves of the image in the correct order, also Graphics (not character) mode needs to be selected.

yes, this works. thank you

the problem is, when i save it as inside.bin, it saves it as hex...

here are the other files i would like to convert:

[Pernod70]

Originally Posted by SiriusHardware

You could only represent that code file as a single binary file by creating one which spans from 0880 to FFFF with very small pockets of actual code and a lot of padding in between. Even if you took away just that part the converter would still generate a binary file spanning 0880-0FFF, and attempting to load it would result in some of the code being loaded into areas which aren't RAM.

It's worth trying to load it in the debugger at 880, it might not complain!

[SiriusHardware]

Perhaps Phil can now explain how he managed to convert the file to .bin. I suspect he didn't use HxD.

[777xxxx]

ive just attatched the files i would like to convert ^

[SiriusHardware]

It's worth trying to load it in the debugger at 880, it might not complain!

It might not, but there is a potential problem, if the RAM I/O chip is correctly positioned in the RAM then just like the PROMs on earlier MK14s, it too has several 'images' higher up - so your single-shot load would load the correct code into the RAM at 0880 but then it would wipe it out by writing 'padding' code to the same RAM accessed through its images at higher addresses.

[SiriusHardware]

ive just attatched the files i would like to convert ^

Not quite. Try again?

[777xxxx]

Originally Posted by SiriusHardware

Not quite. Try again?

ok, fixed:

[SiriusHardware]

Sorry, I must have caught you in mid-edit because your file was attached to #29 when I looked again. You realise your attached file is only 22 bytes? Even for a zipped file that is improbably small. Want to check it again?

[777xxxx]

Originally Posted by SiriusHardware

Sorry, I must have caught you in mid-edit because your file was attached to #29 when I looked again. You realise your attached file is only 22 bytes? Even for a zipped file that is improbably small. Want to check it again?

fixed ^

[SiriusHardware]

Some of those files have code in more than one area and will present difficulties with conversion to a single binary file. If they originate from Tim at least some of them will have the program execution address in addresses FFFE and FFFF of the file which will completely freak out any Intel to Binary converter.

777xxxx's original question was how to go about converting one format to the other. Phil seems to have a method but hasn't yet explained, for the benefit of the OP, what that is.

[Phil__G]

Clive:

[777xxxx]

Originally Posted by Phil__G

Clive:

thanks again. works perfectly