OSI + Gotek (youtube video)

[bxdanny]

davisgw,

First, congratulations on getting everything working. So the DOS/65 image works without further modification after you reset the FF.CFG defaults? Are you now able to have the Gotek unit and a real floppy work together as A and B drives?

I think you left out the "v" in the name of the working Hexdos file, am I right? "hexdos4nhd.hfe" was the corrupted one whose directory could not be loaded, while "hexdosv4nhd.hfe" was the working one, correct? I know, the names are ridiculously similar. (and both ended with nhd, not enh).

I think I had seen that .pdf of the specs for .hfe files before, but I didn't pay too much attention to it at the time. Anyway, the only changes I made to the three .hfe files you posted were the changes to the header that I described, which I now know represent the bit rate of the drive interface and the rotational speed of the drive being emulated (which is ignored).

Mark,

I looked at the contents of the .hfe files to see if I could figure out the encoding, but I couldn't. The actual track data seems to consist entirely of "2" and "A" nibbles, meaning bytes of 22, 2A, A2, and AA. At first, I thought that made sense, with A (1010) being a logic 1, consisting of a data pulse, a space between pulses, a clock pulse, and another space between pulses, while 2 (0010) meant NO data pulse, a space between [potential] pulses, a clock pulse, and another space between pulses. But that's backward, as the spec says the LSB comes first. And the very beginning of each track consists of "22" bytes, which would seem to mean a string of logic zeroes, whereas the ACIA would actually be putting out a steady logic 1 level before data was sent. Is it possible to explain how this works while keeping it relatively brief?

[davisgw]

bxdanny,

You are correct. The image named "hexdosv4nhd.hfe" boots and runs without errors on the Gotek. The image named "hexdos4nhd.hfe" boots OK but does not execute a Load 0 command, so the image seems corrupted.

The hex at offset x'0200' in the good image is:
02 00 8E 65 35 00 8E 65 68 00 8E 65 9B 00 8E 65 CE 00 8E 65 01 01 8E 65 34 01 8E 65 67 01 8E 65 9A 01 8E 65 CD 01 8E 65 00 02 8E 65 33 02 8E 65 66 02 8E 65 99 02 8E 65 CC 02 8E 65 FF 02 8E 65 32 03 8E 65 65 03 8E 65 98 03 8E 65 CB 03 8E 65 FE 03 8E 65 31 04 8E 65 64 04 8E 65 97 04 8E 65 CA 04 8E 65 FD 04 8E 65 30 05 8E 65 63 05 8E 65 96 05 8E 65 C9 05 8E 65 FC 05 8E 65 2F 06 8E 65 62 06 8E 65 95 06 8E 65 C8 06 8E 65 FB 06 8E 65 2E 07 8E 65 61 07 8E 65 94 07 8E 65 C7 07 8E 65
Whereas the hex at offset x'0200' in the bad hexdos4 image you had previously sent is:
02 00 C4 68 37 00 8E 65 6A 00 8E 65 9D 00 8E 65 D0 00 8E 65 03 01 8E 65 36 01 8E 65 69 01 8E 65 9C 01 8E 65 CF 01 8E 65 02 02 8E 65 35 02 8E 65 68 02 8E 65 9B 02 8E 65 CE 02 8E 65 01 03 8E 65 34 03 8E 65 67 03 8E 65 9A 03 8E 65 CD 03 8E 65 00 04 8E 65 33 04 8E 65 66 04 8E 65 99 04 8E 65 CC 04 8E 65 FF 04 8E 65 32 05 8E 65 65 05 8E 65 98 05 8E 65 CB 05 8E 65 FE 05 8E 65 31 06 8E 65 64 06 8E 65 97 06 8E 65 CA 06 8E 65 FD 06 8E 65 30 07 8E 65 63 07 8E 65 96 07 8E 65 C9 07 8E 65

You can easily see they are different. So that's why I asked how you created the good image. And the bad image does not appear to load/run track 0.

Yes I have the 600D I'm testing the Gotek on playing nicely with the floppy configured as drive B. OS65D booted from the Gotek correctly displays the directory for both A and B.

[davisgw]

bxdanny,

In my previous post I'm not sure I made it clear I was comparing hex bytes beginning at offset x'0200' in the good "hexdosv4nhd.hfe" image to the bad hexdos4.65d image that you or Mark posted, that I converted with OSIHFE and modified the header bytes. They should have been the same but are grossly different.

Also, now that my Gotek is not fighting with my floppy I tried copying a full OS65D disk from the Gotek to a blank floppy. I works perfectly. When I tried your Enhanced Pico Dos to copy from the Gotek to a floppy it does not work. It fails writing the first track, regardless whether I specified to start at
track 0. So it does not appear to be ready for prime time

[bxdanny]

OK, thanks for the update.

[bxdanny]

Glen,

I redid the copier "executable", basing it on the version of the copier found on Tutorial Disk 2, Track 13, rather than the version that (for some reason) was on OSI's original Pico-Dos 1.1 disks, Track 3 [Edit 1/30/24: that should say Track 2]. Nothing is changed in the attached image except what is on Track 39. (It's in standard .65d or .img format, change the extension. We know OSIHFE can convert it properly.) See if this works any better. If possible, try both Gotek to floppy and floppy to Gotek,and maybe even floppy to floppy. Thanks!


Edit (about 20 minutes later):

I got an error (ERR #9) even in the emulator when I tried to write over an existing disk image with the new version of the copier. But if I Initialized the "disk" first, I didn't get an error. So maybe try initializing the target (IN followed by Y) before use. You could try it with the previous version as well as the new one.

Edit #2 (next day, 1/24/24):
The error I got was not directly related to the copier at all, but rather to the disk image I was trying to copy over, which was a copy of Tutorial Disk 2 for the C1P. Track 4 of that image had a large number (8) of noise bytes before the track header, and apparently the version of 65D (3.0) that Pico-Dos is derived from can't handle that. Any attempt to read track 4 of that image gives an ERR #9 message. I verified that this also occurs trying to read that track with the full version of OS-65D 3.0 (as found on the disk image C4P-OSIBUSN1.65D). But 65D 3.1 and up read it fine.

[davisgw]

Danny, Good news! I tried the ep39 image disk copier going from Gotek to floppy and it fails every time with error #9 on track 5. Then I tried ep39a image disk copier and it works perfectly on the same floppy. I have not tried going floppy to floppy. Good job!

[bxdanny]

Interesting. Did you see the two edits I added to the message in which I posted the ep39a image?

Anyway, I'll wait a day or two and see if the difference between the two versions holds up for you. If it does, I will post the ep39a version in the "Enhanced Pico-Dos" thread.

[davisgw]

Can anyone tell me what are the rules/limitations of writing to the Gotek like it is a real floppy? I decided to experiment and created a couple blank OSI images on the flash drive for the Gotek....only I quickly discovered that the Gotek will not navigate to a blank image. So then I created a couple OS65D images on the flash drive and tried to use the disk copy function to copy over one from a Disktool5 floppy. It seemed to boot once and then would not boot any more and also the other OS65D image would no longer boot, indicating that both images had somehow been corrupted.
Is this an expected issue of copying over an image because of the header and timing that is embedded in the images? And can changing or adding files to an image be done successfully? Should Gotek images be considered as ROM? Thanks for any insight.

[davisgw]

Since nobody replied to my previous post, I did some more testing after additional thoughts. I assume that image copies from floppy to Gotek will not work because of the timing and track data that need to be stored in the Gotek images. So I used a OS65D image to modify BEXEC*, remove a file, create a file, and save a file. All were successful and also resulted in expected directory changes. So Modifications to an image DO in fact work like they would for a floppy. That is a definite plus. But creating or copying an image cannot be done except with OSIHFE. But I still don't understand the feature in OSIHFE to create a blank image since they can't be successfully overwritten and are not selected by the Gotek.

Mark,
Any comments?

[davisgw]

Danny, Mark,
With nothing better to do while waiting for maple sap to boil, I decided to figure out how to obtain a good hexdos image for the Gotek because I have some programs that are not part of the V4 distribution that Danny provided a good image for. So I transferred a new image from my floppy, ran the OSIHFE cleaner, created the HFE image, and edited the header to correct the known errors. It did not boot on the Gotek. Then I experimented replacing various sizes of binary data from the good image from Danny to the image just created. After several tries I discovered that replacing binary data up to offset x'7000' corrects the boot failure while preserving the directory and files on the failing image. Then I tried copying the same binary data to my failing hexasm image. It also works!

Danny,
Do you know how you created the good images hexdosv4 and hexdos4enh?

Mark,
Any progress to report on OSIHFE updates?