OSI + Gotek (youtube video)

[bxdanny]

As far as I know, I just used OSIHFE on the Hexdos 4 image that you had sent me. I don't know why it would have worked for me but not for you.

I'm a little surprised that keeping everything up to 0x7000 in the Hexdos HFE image does not interfere with the directory of the new disk. If I am interpreting the file contents correctly, based on the spec you sent me, the track data for track 1 (the second track), where the Hexdos directory is stored, should start at 0x6A00.

Based on everything I've read, you SHOULD be able to copy from floppies to Gotek images with disk copy programs. If it doesn't work when you are trying to overwrite existing images, try formatting the intended destination first. That is, say IN and respond Y at a 65D prompt for a formatted "blank" 65D image, or run the Hexdos Format program for a blank Hexdos image. (You could save several copies of these "blank" images on the memory medium used by the Gotek to serve as targets for copying to.) If that still doesn't work, you could try making an image (.65D format) of the source disk, "cleaning" it with OSIHFE, writing the cleaned image back to a floppy, and copying from that.

[davisgw]

Danny,
You are partly correct about image copying. If I format and copy a OS65D image on the Gotek with a OS65D floppy the resulting image boots and runs on the Gotek perfectly. But If I format and copy a HEXDOS image on the Gotek with a HEXDOS floppy the resulting image does NOT boot. But if I copy a HEXDOS image on the Gotek to a blank floppy the result is a floppy boots and runs perfectly. Go figure I cannot explain it.
Secondly when I copied the binary data from a good HEXDOS image to one that would not boot I tried 0x6900 and 0x6B00 before trying 0x7000, but I did not try 0x6A00 so perhaps that will work.
But I wonder whether you have a different version of OSIHFE (a bootleg copy from Mark ) from the one I have. Mine is supposed to be V2.21 and the file is dated 3/4/2022. I have tried to create a bootable HEXDOS image many times and none have worked.

[davisgw]

Danny,
I looked for a later version of OSIHFE today and discovered V2.22beta. So I created images for HEXDOS, HEXASM, and Disktool5. The headers still needed to be corrected and the HEXDOS and HEXASM both boot on the Gotek,,,,but a Load/ hangs EXACTLY like the hexdos4 image you posted a couple weeks ago for me to try. So now I know what version of OSIHFE you used to create that image. Is there a different version you used to create the hexdosv4nhd imaged you also posted? If not, can you explain why that one is different?

Mark,
Also, I noticed that the Disktool5 image ONLY BOOTS ONCE and never again. I've seen this before when I was struggling with getting the Gotek to work reliably so I thought it was not the fault of the image. Now I think the image self destructs when first booted and thereafter it stops on track 5.

Comments?

[bxdanny]

Actually, all I did was change the three bytes that I mentioned in the header, two for the bit rate and one for the rpm. The folowing dialog with the old MS-DOS command fc.exe should verify that:

C:\Users\Danny\Desktop\winOSI\OSI-Dump>fc /b hexdosv4.hfe hexdosv4nhd.hfe
Comparing files hexdosv4.HFE and HEXDOSV4NHD.HFE
0000000C: F4 FA
0000000D: 01 00
0000000E: 68 2C

C:\Users\Danny\Desktop\winOSI\OSI-Dump>

I was mistaken when I said I created hexdosv4nhd.hfe using the osihfe program; I didn't. I created it with theHxD hex editor program.

Yes, I have both those versions of osihfe.exe as well. There do seem to be a lot of additional options in the later version. But I didn't use that newer version in creating any files that I sent to you.

[davisgw]

Mark,
I began to suspect that the Disktool5 image on the Gotek is overwriting itself and found that my theHxD hex editor program can compare two images. So I put a fresh image on the flash drive and booted it on the Gotek once. Then I compared the fresh image to the one on the flash drive that had been booted once. I found that the binary data from offset 0x20200 to offset 0x26C00 has all been changed but does not appear to be random garbage.
Could this be caused by OSIHFE? Any ideas?

Danny,
How did you create an image with theHxD hex editor program without first using OSIHFE? I've been using it for a couple weeks.

[bxdanny]

davisgw,

How did you create an image with theHxD hex editor program without first using OSIHFE? I've been using it for a couple weeks.

YOU used OSIHFE to create the image that you sent to me, saying it didn't work. I compared it to images that did work, noticed those three bytes were different, and so I modified them and sent the modified image back to you. That's it.

-Danny

[davisgw]

Danny,
Sorry. I had forgotten or misunderstood that the good hexdos images you posted were originally from me after you corrected the 3 bytes in the header. I thought you had a better magic rubber chicken than mine

Mark,
Here is what I think I know about OSIHFE conversion of hexdos dumps:
1) The header is always incorrect and correcting the 3 bytes in the header does not always result in a bootable image.
2) I can use HxD to copy the first 0x7000 bytes from a bootable image to one that does not boot to "fix" the image to be bootable.
3) Copying a bootable image or even a single file to a bootable image corrupts that image so it no longer boots.
4) I ran OSIHFE with the -t option against ALL of my images. No errors were found in all of the OS65D, DOS/65, Disktool5, and PicoDos images, but ALL of the hexdos images failed with errors on track 0, INCLUDING the ones that boot and run on the Gotek.

So I'm convinced that OSIHFE has a problem with hexdos images. Let me know if there is more info I can provide. Thanks.

[davisgw]

Mark, bxdanny,
Great news! I have a solid workaround for OSIHFE conversion of hexdos images. From a comment Mark made awhile back the OSIHFE "thinks that hexdos floppy images are from 8 inch floppies" I tried a theory that I could override this behavior with the -5 option. So I entered the command "osihfe -5 hexdos.65d hexdos.hfe" on the PC. The resultant hfe file still has offset 0x0E and 0x0F in the header set to 0 and 0 so I changed them to 2C and 01 and the image boots and runs on the Gotek. Then I tried the same with hexasm and that also boots and runs. I even added a file to each image and that also works and still boots. Success!!

[nama]

Oh...it's been ages since I've been back to the forum... this post has taken on a life of its own. Sorry for the very late response.
I have attached all the .hfe files I've made and work on my C4.
Nothing is named, but I'm sure you can figure it all out.

Enjoy.

disk Images working on C4.zip

(3.26 MiB) Downloaded 67 times

[bxdanny]

davisgw: Congratulations.

nama,

That's a sizable collection of disk images. I went through it and made a list of what is what, which I am pasting in below:

Code: Select all

                                                          OS disk
Disk #  Disk Title [Bracketed text = comment]     OS ver  Rel date
------  ----------------------------------------  ------  --------
00      COLOR DEMONSTRATION DISK / OS-65D V3.1    3.1 HC            [Edit: same OS as what's called 3.2 HC below]
01      OS-65D Tutorial disk one                  3.2     09/16/81
02      OS-65D Tutorial disk two                  3.2     09/16/81
03      OS-65D Tutorial disk three                3.3     09/16/81
04      OS-65D Tutorial disk four                 3.3     09/16/81
05      OS-65D  Tutorial disk five                3.3     09/16/81
06      OS-65D VERSION 3.2 -- NMHZ                3.2     11/01/79
07      AARDVARK GAMES DISK 1                     3.1
08      [Aardvark] GAMES DISK III                 3.1
09      [Aardvark] GAMES DISK IV                  3.1
10      OS-65D V3.1 Game disk six                 3.1               [Edit: really 3.2]
11      O.S.I. GAMES DISKS 4 & 6 [Aardvark menu]  3.1
12      O.S.I. GAMES DISKS 6 & 7 [Aardvark menu]  3.1
13      GAMES DISK NUMBER 8 [Doesn't boot]        3.2
14      OS-65D V3.1 Game disk eight               3.1               [Edit: really 3.2]
15      OS-65D V3.1 Game disk nine                3.1               [Edit: really 3.2]
16      GAMES DISK NUMBER 10 [Doesn't boot]       3.2 HC
17      OS-65D V3.2  (NMHz)                       3.2     04/21/80
18      [Runs DIR on boot: PINBAL, TEMPIT, etc.]  3.2
19      AARDVARK GAMES DISK II                    3.1
20      Mark Endicott's DUNGEONS & DRAGONS        3.2 PB
21      [Auto-boots Galaxia game (GLA.1)]         3.2
22      TIMETREK FROM AARDVARK [Doesn't boot]     3.2
23      AARDVARK DISK CATALOG                     3.2
24      MAXI - PROS                               3.2
25      Machine Code Games #1 [says 65D V3.1]     3.2
26      Plot BASIC [gives ERR #9 ERROR IN  17]    3.2 PB  07/01/80
27      Digital Systems S-FORTH V1.1              3.2
28      fig-FORTH 1.0                             custom
29      OHIO  SCIENTIFIC  COMPUTERS  ARE: [demo]  3.2 HC
30      WP6502 [Doesn't boot]                     3.2
31      *** Single Disk Copy Program ***          3.2
32      [Aardvark utilities disk, doesn't boot]   3.2
33      MINIPROS - BY AARDVARK                    3.2
34      [8-inch disk image, doesn't boot]         ---

HC = Home Control
PB = Plot BASIC

Regarding the five images (13, 16, 22, 30, and 32) that don't boot (but can otherwise be read), I figured out the reason they are not booting. It's because the BASIC overlay on Track 12, Sector 3 that they contain is for the C1P. They are crashing when attempting to do a Control-C check. The easiest way to fix that would be as follows:

1) Boot the system from Tutorial disk two (Image #2, DSKA0002.HFE).

2) Type in the following one-line BASIC program:

10 DISK!"SA 12,3=20C4/1"

3) Switch to each of the non-booting images in turn and, with each one in place, RUN that one-line program to write the correct overlay sector to it.