2

I've given myself a project of writing Ghidra Loaders and FileSystems for an 8-bit retrocomputing platform, namely the Sinclair ZX Spectrum. But I'm new to Ghidra, Java, and Eclipse.

When developing a Ghidra Loader Module you deal with one single file, parse its headers and format to tell Ghidra which pieces of the file it needs, what memory regions it would load to, where its entry points are, etc.

This is fine because there are file formats that have been devised for retro system emulators to encapsulate a single game etc.

But there are also files for those emulators which represent disk images and cassette tape images containing multiple files.

But unlike modern systems, files in these old disks are just arrays of bytes. They don't have a format, a header, or any magic word bytes to identify them. Any metadata needed to load and run them is part of the disk format, not part of the file.

So I've figured out how to make a Ghidra FileSystem but I can't see a way to pass this file metadata directly to Ghidra from the FileSystem. Instead, I only find a way to pass a byte stream to Ghidra, which then gets passed to the Loader system, which relies on identifying the byte stream by looking for recognizable file formats/headers/magic bytes.

Must I then create "fake" wrappers for these files that make them identifiable and create a matching Loader that recognizes them?

Or is there a system already present in Ghidra for passing metadata directly along with such "raw" binary files that I just haven't discovered?

Ghidra FileSystems cover things such as disk image files, archive and compression formats, and even fat executable binaries. It's quite possible there are already FileSystem modules in there for formats that package raw binary code blobs. How do they do it?

(By the way, the only other project I've found so far that tackles a retro disk image format uses a hack to list the files in the Loader option dialog rather than making a FileSystem.)

3
  • For a ZX Spectrum tape, the initial loader supplies the starting address (and possibly more, such as an initial stack pointer and contents of registers). How are you going to hand these over to Ghidra? I think it indeed needs a custom file header. – Jongware May 8 '20 at 6:46
  • @usr2564301: Yes I'm working on that as at least a temporary solution. I have to figure out how to add the header within the framework. I'm doing two disk formats, DSK and TRD and the boot sector for DSK, which is the only one I know of so far that has an entry point different from the load address. This brought me to my next problem, that though I can write the code for both parts, I can't find a way to run Ghidra with both parts at the same time. – hippietrail May 8 '20 at 18:11
  • Another hack that would work besides adding a fake header would be to include the information in the filename. – hippietrail May 9 '20 at 2:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.