kyuusaku wrote:tepples wrote:The 1A is there for a reason, the same reason that PNG uses it: to stop MS-DOS TYPE from continuing to read the file.
Who uses type?
I don't know, but a lot of C standard libraries under DOS and Windows stop before the first ^Z when reading files where fopen() specified text mode. Given that some FTP programs behave the same way, it's also useful to make sure the file was transferred in binary mode.
Are there any other escape characters that could be used to do essentially the same as EOF?
In CP/M, ^Z is end of file. MS-DOS is Microsoft's fork of QDOS, a clone of CP/M. I know of no other character that MS-DOS file readers use as end-of-file.
Because the SRAM can be cleanly erased without affecting the ROM.
But why shouldn't they be packaged together? If the SRAM is chunked or in a predictable place, everyone capable of using a hex editor can clean or remove it.
But buggy implementations may overwrite the ROM. In general, applications are not as well tested as an operating system's file system code. Putting the responsibility to keep the data streams separate on the file system will result in less chance of data loss.
Having it packaged would also allow people to use SRAM between emulators without having to reconfigure the SRAM directories unless SRAM is defaulted to the ROM directory which makes clutter.
Storing SRAM in the ROM file also clutters up the Last Modified dates. And would you also want to store the save states for a game in the ROM file itself? This would make it more difficult to trade save states, as a lot of online communities encourage trading of SRAM files, save states, and movies but
not the ROM files themselves due to copyright.
It would also allow people to distribute extra code in SRAM (sorta like the GAR.) If people really wanted to store ROMs as read only archive files, they could have the emulator redirect SRAM to a file.
Which reintroduces having to reconfigure the SRAM directories.