Byte Buster: Utility to extract hex bytes to a file

[+therealbountybob]

Anyone following the "What is a good disassembler on XL/XE" thread might have seen that I was looking for a way to pull data bytes from a executable file into a data file for use with assembler (all on the Atari). I've copied the relevant posts below.

 

I've created BYTE BUSTER - a BASIC program to do the job DOS25-BYTE-BUSTER-1v0.ATR

(RUN "D:BYTEBUST.BAS" to use it). It's a bit rough & ready but it works. I based it on one of the utilities that came with Genesis the PMG editor I used for Ramp Rage, so the credit goes to Jeff Davis for doing most of the work

 

Instructions are on screen - inputs are in decimal. Filenames must be prefixed by D: etc The screen will be turned off during processing (your 1050's red light will provide comfort!)

After importing the file to your assembler you can replace DATA with .BYTE e.g. REP/DATA/ .BYTE/A

 

You will need to manually edit the source file's directory entry to point it to the first sector you wish to extract, (or in theory you could use the offset to skip though all the bytes). It works with DOS2.5 and reads the data ignoring the disk management bytes 126-128 on each sector, which is good for me.

 

Seems 55 sectors of data is the max that will fit into RAM in BASIC. This 'largest' file will fit into RAM with MAC/65 too, but there is not enough free memory to replace all the data statements in one go; so you will need to split it again first (or create a smaller file in the first place!! looks like 54 sectors of data will fit). [edit: If you read past the end of file by reading too many sectors the trap will re-run the program so just press break and you can still list the data lines to disk manually]

 

If there is a file splitter (that runs on the Atari) or better still if someone can improve this to allow you to operate on a range of sectors that would be neat.

 

Hope this is of use

 

Thanks 1050, very much appreciated The WosFilm disassembler now works great on multiple drives (I guess someone made it single drive for their convenience).

 

I have been tinkering and used the disassemble by sector to split an XEX file into various MAC/65 files. I had a print out of the code so could see some logical points to split the file: blocks of code / data. Seems MAC/65 doesn't like anything too large so I need to split some further.

 

My aim is to take a well known game, tweak it and then re-assemble it. All on real hardware (with a little help from APE). The next challenge is how to get a block of data bytes into a format that I can use, ideally to be INCLUDEd in the assembler.

 

The problem is MAC/65 file thinks it is code, where as I want the data as .BYTE statements etc. I could search and replace each command e.g. replace BRK with .BYTE $00 but I would have issues with STA commands etc depending on the mode they are used in: STA $nnn,Y = $99, where as STA $nnnn = $8D - plus this would be a right pain as the files are large.

 

Suggestions please

 

 

Eventually everyone notices that same weakness with MAC/65 and they write more better assemblers that allow to include data files - end of problem. And you are very welcome, I'm glad I actually could pull it off.

You might consider using BASIC to make a block of .BYTE file with instead of the disassembler as there is where the actual problem is (disassembly). MAC/65 should accept a block of .BYTE just as easily as the regular stuff. Making that block is the issue. MAC/65 will accept text files as a source and then you can save it in the tokenized form for disk space and speed when assembling.

Some disassemblers can do this trick where you tell it from here to there is block mode, most do not. Because references to various parts within that block are very likely to exist and MAC/65 will still need those to be inserted as labels in order to assemble good code outside the block we have real issues right away with block disassembly. Which is the main reason none of this gets done very often.

Very real programmer's dilemma has no easy solution that I'm aware of - I've never gone there though, so I'm just kicking ideas around here. Dis6502 could be used to force a block into .BYTEs for you? Others will have better suggestions I hope. It also kinda all depends on what exactly what you mean by 'real hardware' too.

 

 

by real hardware I plan to continue using the 130XE and Atari based software

 

I'm betting there is at least one Atari utility to export a block of bytes (from a range of secrors) and probably something designed for use with MAC/65 might exist if I'm lucky. I guess I can create something in BASIC like you say, but I'll have a trawl through the utilites archives. Interesting that when you disassemble (using WosFilm) by sector it still puts in the correct branch addresses to other parts of the file - I wasn't expecting this to be the case but I suppose they are all hard coded thinking about it. I'm still experimenting - and having fun

Edited September 11, 2015 by therealbountybob

[kenjennings]

I did something similar-ish on my blog.

 

http://atariage.com/forums/blog/576/entry-11920-convert-binary-file-to-basic-xl-data/

 

It can load a segmented binary file (in a rather stupid way) which depends on the machine language program not loading into the same space as the BASIC program. So, this is mostly intended for new binary file work that the user controls, not debugging legacy code occupying the BASIC program space.

 

Alternatively, it can ignore the load file structure and just put the binary into any starting address, but this means the segment information is also part of the binary/program output.

[+therealbountybob]

Reporting back! Using "Byte Buster" to create my data segments and the Wos Film Disassembler for the code I managed to extract all the parts from a proper game, successfully re-assemble them all in MAC/65, and get the XEX to run This is a serious break through for me, now I can get to making some minor changes, when I get some time, and see If I can find some space to try out a few things too

[+therealbountybob]

Some more info:

 

I've used Byte Buster to transfer an exported PC art program file that an atariage user sent me into MAC/65 (in this case it was title screen image data).

 

BB worked nicely just pointed to the PC file via APE and set a lot of sectors to make sure it got to the end. See 1st post re the trap restarting the program: the data is there in RAM and can be listed to a file.

 

Note the last few bytes may be missed - possibly as the utility expects a full 16 bytes for each line so just enter these manually - will fix this one day

[Rybags]

I did such a program back in the day. IMO the $ prefixes are superfluous and eliminate much of the potential savings.

There's more saving to be had by just doing each data line as a single string rather than a bunch of individuals as the commas are a byte wasted each.
The program I did had the option to use spaces or not, and I think it also allowed single hex characters to save that extra byte once in a while.

 

I had a quick look but couldn't find it. I'm sure I used it in a Basic utility or two that I made, if I can find it I'll put it up.