eslapion wrote:I need a piece of software that would convert this single .BIN file into either two 32kBytes .PRG files or four 16kBytes .PRG files.
If you don't want the *.prg header, omit line 40.
Code: Select all
10 OPEN2,8,2,"BIGFILE.BIN,P,R"
20 N$=CHR$(0):FORT=0TO3
30 OPEN3,8,3,"SPLIT"+CHR$(48+T)+",P,W"
40 PRINT#3,CHR$(0)CHR$(64*T);
50 FORS=0TO16383:GET#2,A$:PRINT#3,LEFT$(A$+N$,1);:NEXT
60 CLOSE3
70 NEXT
80 CLOSE2
So far, no big problem, and possibly easier done outside the CBM environment, but ...
eslapion wrote:Do you guys think this is feasible?
... the big question remains, whether these .PRG files are really useful. You can't load them the normal way, as they would overwrite ZP, I/O, the loader (the loader might not be affected, if it is part of the *.BIN file).
So if the purpose of the *.BIN file is to re-load the entire memory-state, a *little* more work is needed than splitting the *.BIN file into *.PRG files.
I remember, that I once wrote a loader to fill the RAM addresses 1024-65535 on a C64 from such a long file. The loader resided in the stack. I used a simple program to start the C64 mode on a C128 in Bank 1 [*]. All addresses 1024-65279 were retained when with a reset back to C128, then saved to disc. Another program saved addresses 65280-65535 in C64 mode (therefore, a second start of the program to be saved was needed). A third program appended these two files. Finally I just needed to determine the starting address of the game by hand (most of the time something like $x000, and starting with: SEI, LDX#&FF, TXS, init background and border
).
Michael
[*] Poor man's freezer.