Anyone have any suggestions for how to do this?
Here is an example of how the Notepad++ reads the text file:
Each line is prefixed with a line number of the form :100tC000 , followed by the 16 hex bytes of interest and ending with a hex byte checksum.
Any suggestions will be appreciated.
Those lines are records in the "Intel Hex" format. Seeing it usually points to the data being intended for programming into a PROM or microcontroller. Device programmer software usually natively understands the format, and can do the conversion to binary within a data buffer.
If you want to convert the data to binary without any programmer software, it is not difficult. A one-line awk script could do it. Alternatively, there is algodesigner › hex2bin
I'm not totally understand what your goal is, but I was going to suggest hex2bin but noticed robespierre suggested it too and I second the .hex files are generally used to describe binary data used for bruning chips.
The :100tc000 means that line has a data size of 16 bytes (10) , your 0tC0 is all kinds of confusing. That's an address and incresing by 16 each line, then the record type (00) which means data for 16 bytes then the checksum as you said.
Whatever this is, it does not appear to be for a II. That address is meaningless without the base address. If you try to disassemble the hex it does not look like 6502 asm, but I didn't mess with too many staring addresses and several were doing things like modifying values in ROM addresses LOL. Could be data tables, but still no idea what this data is and what you're looking to do with it.
Thanks robespierre and jeff d for your comments. The "tc" was my typo and should have been "7c".
I should have mentioned that this Intel Hex Binary text file was read from 2716 EPROMs via a C64 some years ago.
Yes, this is data used to burn 2716 EPROMs used with the 6504/6502 CPU, and I'm aware it is the Intel Hex Binary Data format. I know the start address.
The hex values are Apple II family readable or executable. The example I provided is the start of a data table about 700 bytes long, but some of the 2K data also includes op code routines
This is all nice an readable on a PC, but moving this flat file onto a Apple II disk image carries the Intel format baggage with.
What I'm looking to do is to pull the pure hex bytes from this file into a binary file compatible with an A2 disk image, so that:
1. sections can be disassembled
2. raw hex data can be identified after the disassembly in imported into the S-C Assembler 2.0.
In Notepad++ you can simply hold down the <Alt> key in order to achieve grid selection and editing. Select the part you are interested in, copy it, paste it in a hex editor or whatever else you like:
NotepadPlusPlus.png
eeew! I should have thought of that!!
Using Notepad++ in Win10, I used the Alt+ to select the left line number column to delete it and the checksum column as well, leaving only the Hex bytes. I then save the remaining Hex to the default file type in a separate file, but it seems to not be true Hex, rather in ASCII. When I try to then copy the Hex only data file and add it to an Apple II disk image using Cider Press it alters the values. If the original Hex value was "5B" it becomes "31", a decimal difference of 42. ?? I don't understand this. Cider Press identifies the added file type as "F2" with a blue question mark to the left of the file name but the true Hex values are not preserved. Changing the file attributes in Cider Press to "BIN 06" doesn't help.
Entering the Hex values shown in the original .hex Intel Hex Binary Data format file in Notepad++ into the Apple IIe memory in Monitor mode results in the correct Hex data expected.
(Bear in mind that the Hex data expected is either going to express 6502 op code subroutines OR raw 8-bit Hex XY graphics coordinate data.
I've only glanced at the github link sent earlier so don't yet understand how that might help.
The problem is that there are about 12 2K x 8 EPROMs (2716) of data that I currently have as data dumps in PC .hex files from a C64 EPROM reader that needs to be loaded into my Apple IIe to glean some historic data that is native to a 6504 environment. I entered by hand about 512 bytes into my IIe just to verify the .hex data is valid, but I don't want to do it this way for twelve 2K data dumps.
I appreciate the help!
Your narrative of the steps taken never mentions actually converting to binary.
Of course you will need to do that, if your intention is to BLOAD it into an Apple II or something similar.
Exactly! This is a first time experience for me. It sounds like hex2bin is just what I need. But it seemed at first to involve compiling for Windows use with tools (I can get) but have never used, e.g. Cygwin, Msys, GCC. I read the README of hex2bin for compiling for Windows use. I said compile for Windows using Msys, Cygwin or DOS prompt. Windows cmd prompt didn't understand gcc. But then...
I just read further and it said the Windows hex2bin and mot2bin were already compiled...so I'll try this again and let you know how it goes!
Oh! hex2bin.exe went great!! Just what I needed. Thank you so much.
The hex2bin.exe for Windows generated the raw hex byte file perfectly using the command "hex2bin targetfilename.hex", where hex2bin was in the same folder as all the .hex file that needing converting. The output of hex2bin saved a file with the same name but ending in .bin, e.g. targetfilename.bin.
With a valid Apple II DOS3.3 disk image opened in CiderPress, I was then able to use Cider Press' "Add file" to add all these .bin files to the disk image. They did add with the file type of "F2" and a blue question mark as before. But before I could BLOAD these .bin files into the Apple IIe memory I had to change each .bin file's attributes by right-clicking on the file then select Edit Attributes. In the Edit Attributes dialog window the File Type was changed from F2 to "BIN $06". Although it wasn't necessary I changed the Alt File Type from "0000" to "4000" which was the default hex memory location I wanted the binary file to load if not specified with BLOAD.
Once this was done I was then able to BLOAD targetfilename.bin into Apple's memory @$4000 and then immediately BSAVE targetfilename,A$4000,L$800 to disk. This then provided me with a native Apple II binary file of the hex data.
Mission accomplished. Thanks again for the hex2bin tip!
Because I claimed that it was possible in a single line of awk, I felt compelled to write it in awk.
Sadly, it ran to four long-ish lines. Probably I'm missing some trick (awk is full of stupid tricks).
Here is the awk (place this in a file called "hex2bin" and make it executable with chmod +x hex2bin):
#!/usr/bin/awk -fBEGIN { FS="" }
function hex2dec(hs, a, t, i) { do { a = index("0123456789ABCDEF",toupper(substr(hs,++i,1))); t *= 16; t += a?a-1:0 } while (i<length(hs)); return t }
$8$9 ~ /00/ { len = hex2dec($2$3)*2; for (i=0; i<len; i+=2) printf("%c", hex2dec(substr($0,10+i,2))) }
You can pass multiple .hex files as arguments, and redirect the output to a single binary file; it will concatenate all the input files into the output.
The easiest approach would have been to simply use a freeware hex editor like HxD. It allows pasting the hexadecimal text out of Notepad++ directly into the binary file:
HexEditor.png
A lot of you guys are super programmers of many tongues. Never heard of AWK and it seems rather AWKward.Hex2bin was simple to use. It created the binary equivalent of 2048 bytes in milliseconds. The file, a true binary file was acceptable to Apple IIs on a DOS 3.3 disk image but not BLOADable into memory without doing what I described (which took seconds per file).
Thanks, I'll check it out.
Those of us that know, know! One very excellent tool!!
Yup, and you made me LOL. Thanks for that!!!