Well, if the original data contains slack space it was never saved correctly in the first place...
If the data is written to disk without packed, its alignment can be either byte aligned or word aligned in the case of TP.
Byte aligned is the same as packed. If you stored the data word aligned you have to read it back word aligned of course, but that was programmer error even then.
The data should have been stored as packed.
The morale is, that if you stored it wrong back then (word aligned) you can only read and write it with a file of records that are word aligned.
That is also documented in the TP55 User manual.
That has nothing to do with FPC, but with how you used TP to create the file in the first place.
packed was important even back then....
I would simply test what alignment was used by simple using {$packrecords 2} and see if you can read the records sequentially..
If that works correct, you know you made a mistake in the past....and wasted disk space, which was expensive back then
One other pitfall is of course the size of integer. Hence I showed that my example records would be size 4 and 3 in TP mode (integer = 2 bytes) and not 6 and 5 (integer = 4 bytes) like in objfpc or Delphi mode.
Working with old code and old files is not always easy if you do not know what you are doing. It needs careful consideration and knowledge about those old formats.
Other pitfalls include real and comp. Real is now an alias for double, so 8 bytes, not 6! There is a helper unit btw to mitigate that for files that stored a real as 6 bytes, Real48Utils.
So if your records contained reals... Boom...
You should really need to learn to use packed for records on disk. You should have learned that back then....