No Floppy Drive
#1
I just bought my SC Pro. It has HW ver. 1.1, SW ver. 1.2. When I plug it in I get two green lights. Like some other people, I had to manually copy the VB6 DLL to the 64-bit Win 10 directory but SCP starts up now. My problem is that the floppy doesn't show up anywhere in the SCP software. I can work with .scp files but can't write to a physical floppy because SCP doesn't know there is one. I have a Teac 55GFR connected via a standard floppy cable. it works fine with Kryoflux but I really want to use SCP because of the future firmware that will allow it to be used as a regular floppy drive letter (that project is going ahead isn't it?)

When I try to test the drive, of course I get errors such as Track 0 not found. Is this a problem with Win 10? Am I doing something else wrong?

Thanks for any help you may be able to give.

Tom L Huh
Reply
#2
How are you powering the drive? Is the drive cable plugged in correctly to the drive and also the SuperCard Pro board? There is really no magic here. It should just work. This has nothing to do with Windows.
Reply
#3
Thanks! You were on the right track (no pun!) My power supply to the floppy drive was bad. I replaced it and now I can create single and double-density disks for my TRS-80 that work. Now if only the disk type wouldn't change or it would allow me to change it after loading an scp file. Right now the disk type seems to change at random when I load the TRS-80 scp files. Usually it changes to Atari ST but sometimes it changes to C64 or Amiga. It's rather unnerving. After loading, if I manually change the disk type, the loaded file is unloaded. At least I can change the copy mode from splice to index without it affecting the loaded image but still, it would be nice to keep the disk type at what I set it to. If it's reading the disk type from the scp file, then why does it change to different values when I reload the file?
Reply
#4
I am not sure why it would change, but the disk type really doesn't matter. It's only there as a reference.
Reply
#5
(11-15-2016, 09:27 PM)admin Wrote: I am not sure why it would change, but the disk type really doesn't matter.  It's only there as a reference.

Great! I wont worry about it then. As I said the disks I make are working so I'm happy. Is there still a plan to let the SCP be used as a standard floppy drive? That facility would be a tremendous asset for me. If you ever need more beta testers, I'm available. I've done beta testing for HP and Microsoft and know how to thoroughly test software.

Tom L
Reply
#6
Yes, but not as a driver letter (as you eluded to in your post). The SCP will emulate a floppy drive itself and could be plugged into your TRS-80, using the .scp files that were created. You can already access the individual files from your .scp image using programs like the HxC Floppy Drive Emulator software.
Reply
#7
(11-16-2016, 09:01 AM)admin Wrote: Yes, but not as a driver letter (as you eluded to in your post).  The SCP will emulate a floppy drive itself and could be plugged into your TRS-80, using the .scp files that were created.  You can already access the individual files from your .scp image using programs like the HxC Floppy Drive Emulator software.

So the files will be stored on the mini SD card? I'm embarrassed to say how long it took me to figure out how to insert a card in that socket! All the other mini SD card sockets I've seen require the user to slide the card in. Some have a latching mechanism some don't but I never saw one that has a swing up plate!

Tom L
Reply
#8
Yes, the .scp files will be stored on the SD media card. I would LOVE to have access to a disk from Windows as a drive letter, but I have no idea how that is handled. There would need to be a handler for each type of disk (OS). If anyone knows how this is done, please let me know!

Yes, the SD slot is a latch/flip-up style.
Reply
#9
Doing it that way for anything other than standard MS-DOS disks would require writing a Windows filesystem driver for every single disk format. Just off the top of my head, differences such as file attributes, character encoding, maximum file sizes, file "types", and so on, would make that impractical. And as a drive letter, you are not just talking about reading and writing, but also allowing applications to keep files open for manipulation which could have some interesting semantic differences.

I guess that could also be done taking an approach to make it look like sort of a network drive rather than using an actual Windows filesystem driver, but there would still be similar complexities.

Another thing to keep in mind is that even with the built in Windows drivers, it doesn't technically know how to read and write FAT - Since 95 it technically reads and writes VFAT. That is mostly backwards compatible with DOS 6.x FAT, but writes all kinds of garbage such as last-accessed file dates and hidden LFNs to disks. Some systems and disk utilities will choke on VFAT, and there is no real option to filter that stuff out.

Honestly, I am somewhat surprised Microsoft hasn't dropped support for VFAT and made everyone use NTFS or one of their later FAT variates.

I'd think a more flexible solution would be just an application that integrates with the SCP and presents the contents of disks as a Windows Explorer-like drag and drop interface with optional batch tools. It could also manage things like formatting, checking, and coping with any non-automatically detectable file system variations. For some types of media an application like that could limit reading and writing to just the changed sectors or tracks. But where needed (or not implemented for simplicity) it could fall back to reading and writing the entire disk at once.

As it is right now, with a SCP or similar, one would have to prepare a disk image in a tool like WinImage, convert it with HxC and then write that image with the provided tools. (I guess HxC can do some file level stuff, but it is not friendly) Even if it is not accessible as a drive letter, a friendly well integrated tool could make accessing files much faster and easier.
Reply
#10
Under Total Commander I can read/write virtually every disk format (via image files).. Amiga, C64, TRS-80, Atari ST, etc. etc. So, it should be not much of a stretch to access the blocks on a disk instead of from a file.
Reply




Users browsing this thread: 1 Guest(s)