OSI + Gotek (youtube video)

[bxdanny]

My comment is this:

Hexdos is NOT going to work right with a 600D in 48-character mode that still has the normal SYN600 ROM, which only supports 24-character mode. It can kind-of work with the patched version of OSI's "Video Swap" program, which I am reposting in the "code window" in this message (davisgw posted it at some earlier part of this thread). Programs can then PRINT to the 48-character screen, and will LIST correctly as well. But backspacing and editing of lines will not work; the system will revert to the standard BASIC-in-ROM behavior of displaying underscores for characters deleted with Shift-O.

Code: Select all

 
 5  REM ENABLE HEXDOS 12X48 DISPLAY MODE
 10 FORI=1TO24:NEXT:POKE515,0
 100 SI=183:M=PEEK(133)+256*PEEK(134)
 200 M=M-SI:MH=INT(M/256):ML=M-MH*256
 300 POKE133,ML:POKE134,MH
 400 POKE2529,ML:POKE2530,MH
 500 FORJ=1TOSI:READY
 600 POKEM,Y:M=M+1:NEXT
 700 X=FRE(X):POKE251,0:POKE252,75:POKE255,32
 800 POKE251,1:REM ENABLE 12 X 48 DISPLAY MODE
 810 FORI=1TO13:PRINT" ":NEXTI
 900 PRINTML+MH*256-772"BYTES FREE"
 910 NEW
 1000 DATA133,254,72,165,251,48,11,141,0,216,41,1,133,250,169,255
 1010 DATA133,251,165,250,208,4,104,76,105,255,138,72,152,72,165
 1020 DATA254,164,255,166,253,41,127,201,13,240,90,201,8,240,72
 1030 DATA201,12,240,75,201,10,240,90,201,32,48,26,201,123,16,22
 1040 DATA157,0,211,232,224,123,240,70,208,33,188,0,211,132,255
 1050 DATA169,161,157,0,211,134,253,104,168,104,170,104,76,108,255
 1060 DATA138,41,63,201,10,208,229,138,233,16,170,208,223,138,41
 1070 DATA63,201,59,208,216,138,105,15,170,208,210,152,157,0,211
 1080 DATA202,176,223,152,157,0,211,232,176,229,152,157,0,211,162
 1090 DATA75,208,188,162,75,208,4,152,157,0,211,134,252,169,64,133
 1100 DATA248,160,0,132,246,162,207,232,134,249,134,247,177,248
 1110 DATA145,246,200,240,244,16,247,224,211,208,243,166,252,208
 1120 DATA190,51

[davisgw]

I have a mystery problem with one of my Superboards regarding the floppy interface. One Superboard works perfectly with either 2 floppies or with one floppy and one Gotek, allowing me to copy from Gotek to floppy. This Superboard is wired with 7407 drivers. The other Superboard did not have drivers for both drive selects and motor on, and because I have no more real estate on the floppy interface card I resorted to the attached circuit changes to eliminate an extra 7400 IC (used as a inverter), and adding a 7406, which is an inverting driver. This works perfectly with 2 floppies connected but when I have one floppy and one Gotek the floppy select signal appears to flip on/off when the drive is selected for a read or write. And I should also add that the 34 wire ribbon cable does NOT have a twist.
Does anyone have a theory why I am seeing this behavior with the Gotek replacing one floppy drive? It looks like the Gotek is loading the select line but that should not be the case.

[Thomas]

The change to the 7406 and eliminating the 7400 inverters should be ok and not causing the described behavior.
Have a look to the FF.CFG file on the Gotek flash drive, for configuration
pin02 = nc
pin34 = rdy
Also turn on
index-suppression = yes
Check also for motor-delay = 400
Have a look to the firmware, if you have two Gotek drives with different firmware revisions. The above values work fine for me.

If the drive LED flips on/off, the OS has not detected the drive because of missing index pulses.
To my knowledge, the index pulse is used for that. You may check the index signal on the board (PIA) with a scope, when the Gotek is selected.

[davisgw]

Thomas,
Thanks for your suggestions. I tried them but they were not the solution to the problem. But I found the problem and fixed it....and don't know why....
I went back and verified the wiring on the floppy interface card (piggybacked circuitry on the A13 floppy board that plugs into the 610 board) and found no issues. So using a digital VOM I probed drive select 0 while reading the floppy and it was indeed flipping 0n/off causing drive select 1 to do the opposite. Then I checked the signals coming from the 610 board and everything looked correct. After much head scratching I removed the Gotek and connected the second floppy....the flipping on/off of select 0 and 1 was gone when reading either floppy. So I suspected it was something wrong with the Gotek and I checked the jumpers and found I had a jumper on the MO pins because I had assumed it was to for Motor On, but the document (the "highly informative" one that comes in the box) did not show that being selected. so I removed it.
That fixed the problem!! Does anyone know why this jumper would mess with the drive selects?

[Thomas]

Great !

MO actually only connects Motor ON to either DS1 or DS0, see PDF
On my Gotek drives, MO is open, means the Gotek drive is activated just by the drive select lines.

[davisgw]

Thomas,
Thanks for the reply and schematic. This explains everything except why this same Gotek worked on my other Superboard....maybe more robust drivers?
On a related issue with the Gotek I've discovered many ways that it can clobber the selected image, requiring the image to be restored on the flash drive before it will boot again. One way is to select another image while the current one has not stopped (stupid of me....). Is there a way to make individual Gotek images READ ONLY? I thought I read this somewhere but the only way I know is to make the flash drive READ ONLY. Thanks.

[bxdanny]

davisgw,

According to the spec you posted, the 20th byte of an .hfe file (the byte at offset $13) is labeled write_allowed, and determines whether the file is write protected or not. The normal value is $00, so presumably changing it to $FF will write-protect the image file against changes by the Gotek unit.

Possibly, setting the read-only attribute in the file's directory entry (e.g. attrib +R myfile.hfe, or right-clicking on the filename, selecting Properties, and checking the read-only box) would be another way to do it.

[Thomas]

One typical root cause for damaged images is the fact, that the Gotek does not have a physical head load compared to a OSI compatible drive.
When you power cycle the computer, the output drivers with its pull up/down resistors will pull the line to ground.
Accordingly, Select and WE go low and anything can and will happen.
In my setup, I have removed the pull up/down resistors on the WE line (on the 610) board. You have to make sure, the connected drives have at least one termination resistor pack installed, usually on the floppy disk board. The pull up resistor inside the Gotek is too weak, in my opinion.
When your drives have their own PSU, it will perfectly prevent any unwanted write operation to the drive during power cycle.

In case of the MPI drives, with head load, and powered by the main machine PSU, the problem was not happening due to the fact, that the head is lifted up in the non-selected state. A Gotek behavior is completely different.

[davisgw]

I have not noticed the current image being clobbered during a power cycle because *most* of the time I reset the computer before powering off. But I used PC DOS to set an image to READ ONLY and was not able to clobber it by copy drive B to drive A or A to A, and I know I have done that before.
I doubt that would save the image during a power cycle because the software cannot check if the image is READ ONLY.

[davisgw]

Mark, bxdanny,
Let me first say that my floppy drives and stash of blank floppies are a limited resource, much alleviated by using Gotek to boot the system.

And since I plan to make use of Gotek for my Superboard systems I decided to take another look at the failure of Disktool5 to boot that I noted in this discussion on February 6th. I have already confirmed that simply setting a flashdrive image to "read only" on the PC solves the other boot failures I knew of (like switching images or perhaps powering off while an image is running). So I decided to see if this solves the Disktool5 issue due to my suspicion that it overwrites itself. And this works perfectly!! I can now boot Disktool5 repeatedly with this change. Even though I don't know WHY it overwrites itself I'm happy that I have a workaround.

On to the next problem....