Getting files from 8" format to 5.25"

[lowrybt1]

I have a BASIC program coded and saved on 8" floppies (and on a 8" HFE virtual floppy), along with two screen saves I stored on 8" floppy tracks. I'd like to get all 3 move to a 5.25 format. Is there some way that I can use WinOSI and HFE file formats to transfer the files from 8" format to 5.25 HFE format?

Many thanks to all with recommendations.

[Mark]

I'm working on an OSI filemanager type application. Right now it can extract data from most OSI disk formats, but does not have the ability to write them. However I can do this manually. If you're comfortable with sending the 8" disk image I can probably convert them without too much effort.
Otherwise you could load them into WinOSI, use the built-in BASIC decoder, cut/save the data then paste the contents via simulated keypresses in a prepared OSI destination file. The saved screenshots (binary data) may be more difficult.

Otherwise manipulation of the .65D disk format may be easier with a binary editor -> 12 sector/$f00 byte track to 8 sector/$900 byte track.
.... ?

fileman.jpg (105.23 KiB) Viewed 12660 times

[bxdanny]

I'd like to add a few comments, if I may.

With regard to the binary screen images: they can be loaded into memory and then saved from the WinOSI Debugger's File menu. To load them back, you will need to use the "Attach Serial Input File..." option and then a short program such as the following:

10 FOR I=0 TO 2047
20 D=PEEK(64513)
30 POKE 32768+I,D
40 NEXT

The above statements could even be entered in immediate mode, as a single line with no line numbers and statements separated by colons. (It is apparently not necessary to check the ACIA status port to see when there is a character ready.)

Another possible way would be to use a really old version of WinOSI (1.3), which didn't clear the emulated system's RAM when doing a "hard reset". You could just load the sectors with the screen images into RAM from the 8" configuration, then switch to a 5.25" configuration and save the data, still in RAM, to sectors on the 5.25" disk image. (To use this method, you would first need to convert the .HFE file to .65D format, using current software, since the 1.3 software doesn't understand HFE images.)

In case you aren't sure about what Mark meant by using "simulated keypresses" to copy the BASIC program, that is activated by pressing the right mouse button in the (current version) WinOSI window, after copying the BASIC program to the clipboard from the 8" configuration. The process is slow, but it is reliable. Depending on the length of the BASIC program, it might or might not be faster to paste the program text into a PC text file, then import it into the 5.25" configuration by using "Attach Serial Input File..." followed by POKE 8993,1 or DISK!"IO 01". If you use that method, be sure to add a line containing just "OK" or "STOP" at the end of the file, to switch input back to the keyboard. Using this method might also be needed if there are any lines in the program listing longer than 71 characters. If so, you can edit them on the PC by changing any occurrences of the keyword PRINT to ?, and possibly deleting the space after a line number.

[lowrybt1]

Circling back to this topic. Now I'm interested in moving Ardvaark's 32K Colossal Cave from its 5.25" OS65D format to a 8" OS65D format. I think the process may be fairly straightforward. The core game code of the 5.25 version is stored on tracks 31-39. (Aside: I hadn't realized that you can launch a BASIC program with the syntax RUN"[Track#])

It looks as if tracks 13-30 are used as serial datafiles accessed with DISKOPEN, 6 and DISKCLOSE, 6 commands to load descriptions of the cave at different locations and to store the explorer's status. So, I've copy the core BASIC code into a txt file which I can load back into WINOSI and save in 8" format. Here's where the limits of my understanding get in the way:

1) Since DISKOPEN and DISKCLOSE are being used, there needs to be a buffer saved with the BASIC file (right?). How is that buffer added before/as the BASIC program is saved to the 8" format .65D?
2) What is the right way to copy and capture the contents of each of the datafile tracks from the 5.25 format and save them to the 8" format? I figure this may be an iterative process, track by track.

Thanks for any and all guidance.
Tom

[bxdanny]

On 8" disk, the disk buffer is from $317E to $3D7D (12 "pages"), versus $327E through $3A7D (8 pages) for the 5" version. (Under 65D 3.3, both buffers would begin at $3A7E, but would still be 12 and 8 pages long. But game disks didn't normally use 3.3, so I'll assume yours doesn't.)

Multiply the # of tracks in each data file by 8 to get the # of pages it uses, then divide by 12 (rounding up) to get the number of 8" tracks it will need. If the number is small enough (and it probably will be), you should be able hold the full contents of a file in memory. For example, if a file occupies five tracks on a 5" disk image, starting with track 24, you could do this at a 65D prompt in WinOSI:

CA 4000=24,1
CA 4800=25,1
CA 5000=26,1
CA 5800=27,1
CA 6000=28,1

Then select File/Debugger, followed by File/Save Memory in the debugger window, and Save as Binary from 4000 to 67ff.

Repeat as needed for additional data files.

When done, switch to the 8" configuration and reboot under the 8" OS, and use File/Debugger and File/Load Memory to restore the file to $4000 and up. (If WinOSI still allowed switching configurations without clearing the contents of memory, this step wouldn't be needed.) Then save the memory contents onto the appropriate tracks of an 8" disk image:

SA 24,1=4000/C
SA 25,1=4C00/C
SA 26,1=5800/C
SA 27,1=6400/C

(i guess you could get by saving only 4 pages on the final track in this example, but it's probably best to keep all data file sectors as 12 ($C) pages.)

Repeat as needed for additional data files.

Finally, use the CHANGE program to set up one data buffer (or just type POKE 121,61:POKE 15742,0:NEW) in BASIC, and bring the listing of the BASIC program back in, using Attach Serial Input File, followed by POKE 8993,1. (Make sure there is an OK or other error-causing line at the end of the file so that input will be switched back to the keyboard at the file's end. Also, make sure that no line is longer than 71 characters. In some cases you may have to change PRINT commands back to ?, and/or delete the spaces before and/or after line numbers in the file of the program listing.)

I converted another adventure game (from Aurora Software) this way, and it does work.'

Good luck.

[Mark]

Since an 8" disk can hold the entire contents of a 5.25" disk, we can use the OSI raw disk dump format to transfer the contents from a 5" to 8" disk just by manipulating the track size of the disk image.
I've written a simple program to do this "OSI5to8" and the resulting converted disk image should work on an 8" system without additional modification, however the OS used will still treat the disk as 5.25" and the directory track will be unreadable by 8" versions of the OS. I'm not entirely sure if writing to the resulting disk will work without errors on an 8" system using a 5.25" OS, but I can't think of any major issues off hand.

At the very least, it provides a way to get the 5.25" contents on an 8" system for further processing & conversion. You can still run the resulting file through OSIHFE to make machine readable disk images. I've included a test conversion of the 5.25" Adventure disk, along with the conversion program and source.
Cheers,

-Mark

[bxdanny]

Hi Mark,

Yeah, that method of expanding a 5" disk image to an 8" one is what I actually used first when I converted that Aurora adventure also. One small problem I ran into is that, since it was an all-text program, I wanted it to be able to run on a serial configuration as well, and IIRC the 5-to-8 expanded image of the Aurora disk didn't boot on the serial configuration. But I was able to substitute a different version of the 5.25" OS that did. Whether some time delays would have to be adjusted to make it work reliably on a real 8" drive, especially for writing (like saving a game position), I don''t know.

But I wanted to make it work with a standard 8" OS, and so I then did what I described in the previous message. I also tried to add some kind of index file to speed things up, and I think I did get that working, but the speedup wasn't as great as I'd hoped.

Lowrybt1, by all means try Mark's 5-to-8 program with your Adventure game, and write the resulting image to a real 8" disk (if that was your intent, which I presume it was). I'd be curious whether there are any issues with timing (drive makes odd sounds?) or with saving game positions.

And of course, with a Gotek drive, disk images can be transferred between 5" and 8" systems simply by changing the bit rate rate field at offset 12 ($C) between 250 (FA 00) for 5" systems and 500 (F4 01) for 8" ones.