UK Vintage Radio Repair and Restoration Discussion Forum - View Single Post

SiriusHardware · 22nd Mar 2018, 11:48 pm

I went to that site and noticed that as as well as the PDF version there was also a 'text only' version which is a (not perfect) OCRed version. I cut and pasted the hex dump (only) out of that and have fixed quite a few errors - like "I" or lower case "L" instead of "1", and various characters like "!" which got inserted instead of ":" along with occasional extra or missing spaces, just by using find / replace in a text editor. It helps that the only valid characters are 0-9, A-F and ':' so any character which is not one of those is obviously wrong.

The main problem is the extreme difficulty of distinguishing, even with the human eye, the difference between capital 'B' and figure '8', and I have noticed a few cases where the OCR has decided one way and I think it is the other. In some cases even the crossed '0' has been misidentified as '8'. What this means is that even if a hex file can be generated the end result would still have to be checked byte by byte against a good printout, correcting where necessary.

Symon, which file formats does your programmer support? The least difficult to generate would probably be comma-separated ASCII hex, then plain binary .bin files. Intel Hex or Motorola 'S' would require the addition of extra information to each line, such as the address, the number of bytes in the line and a (calculated) checksum at the end of each line.

22nd Mar 2018, 11:48 pm	#26
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,586	Re: Interpreting a hexdump table I went to that site and noticed that as as well as the PDF version there was also a 'text only' version which is a (not perfect) OCRed version. I cut and pasted the hex dump (only) out of that and have fixed quite a few errors - like "I" or lower case "L" instead of "1", and various characters like "!" which got inserted instead of ":" along with occasional extra or missing spaces, just by using find / replace in a text editor. It helps that the only valid characters are 0-9, A-F and ':' so any character which is not one of those is obviously wrong. The main problem is the extreme difficulty of distinguishing, even with the human eye, the difference between capital 'B' and figure '8', and I have noticed a few cases where the OCR has decided one way and I think it is the other. In some cases even the crossed '0' has been misidentified as '8'. What this means is that even if a hex file can be generated the end result would still have to be checked byte by byte against a good printout, correcting where necessary. Symon, which file formats does your programmer support? The least difficult to generate would probably be comma-separated ASCII hex, then plain binary .bin files. Intel Hex or Motorola 'S' would require the addition of extra information to each line, such as the address, the number of bytes in the line and a (calculated) checksum at the end of each line.