Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Floppy disk drive emulator for Sol-20

  1. #11
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,230

    Default

    Quote Originally Posted by deramp5113 View Post
    Recording flux transitions (just like a real disk drive) takes about 25Kb/track for a 300rpm drive. No attempt is made to decode the data. Otherwise, you'd have to make assumptions about how the controller encoded the data, bit order, etc.
    I guess what I was envisioning wasn't actually a flux transition device, more along the lines of a conventional "higher level" floppy emulator. So strictly speaking it'd only have to store the actual sector data. (Looking in the Northstar manual a double density sector is 32 bytes of zeros, a sync character, 512 bytes of data, and a check character. Everything but the data itself looks not too hard to synthesize on the fly.)

    Floppy drives with a 3ms step rate were available as early as the days of the North Star DD controller, so 3ms needs to be the design target. Adding heat settle time of 15ms after a step, by which time you should be spitting out the correct data, is a reasonable design target. No other read delays can be assumed.
    I guess I can't find anything in the disk controller hardware manual that says anything about stepping time. Maybe that's up to the CP/M driver? I did find some assembly code for the boot PROM, and just scanning it... I find a part that says "Step out once, and delay (for 2 sector times) while it steps". Two sector times would be roughly (200ms/10) * 2, aka 40ms? My North Star has SA400s in it which would need that much time, was it normal for people to hack faster times into the CP/M driver?

    Most hard sector controllers have a sector register that is incremented by the hard sector pulses and is sync'd by the index pulse. Sync is not lost due to a stepping operation. Data would need to be retrieved starting at the next expected sector and then wrap back around.
    So that appears to be true. The controller has a special status bit that's lit up when it passes the "Index" mark so it does care where the "start" of the disk is, but it would certainly be possible, in theory, for CP/M to request a sector on the next track within the same rotation after the stepping pulse.

    The really critical thing it seems to care about it, yes, it can *never* miss a sector pulse or have it delayed. If I'm reading the manual correctly it starts an aggressive timeout after the index pulse waiting for the first sector pulse and you'll get a hardware error if it doesn't get it and subsequent pulses on schedule. Whatever else a simulator for this does it has to keep spitting out pulses constantly.

    The kicker in all of this is writes. With a USB stick or SD card, the application has to tolerate random latency periods of 200ms by spec, easily over 500ms in reality. If a read is needed at one of these times, you're stuck. Even with a background thread doing writes, the high-priority read would still have to wait on the hardware to finish its write operation and the read has then failed.
    In the "GreaseWeazle" application the Blue Pill acts like a USB Full Speed *peripheral* to a host, that's what I was thinking with this idea. IE, the disk image(s) in use would be resident in RAM on whatever PC (it could be a raspberry Pi or whatever) that's driving the Blue Pill. So as long as whatever OS you're running there has adequate timeslice resolution latency should be possible to keep down to a few milliseconds. Or that's the thought, anyway.

    I definitely agree with you that the timing constraints imposed by the inability to "fake" sector boundaries on a hard sector disk make directly running from flash (whether USB or SD) *really hard* and would probably pretty much necessitate onboard RAM in a stand-alone device.

    Maybe the reverse-greaseweazle idea isn't worth pursuing given how easy it is to find ARM-based devices with a few MB of RAM onboard for a few bucks. (Bare-metal Raspberry Pi Zero would be an obvious possibility.) I just happened to have a couple Blue Pills lying around that I bought for a different project I haven't gotten to yet.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  2. #12

    Default

    Yes, you can simplify things in a number of places if you make a storage solution specifically for the North Star double-density controller and for the host applications you intend to run (e.g., CP/M, NSDOS).

    Mike

  3. #13

    Default

    Quote Originally Posted by nullvalue View Post
    Will it support Micropolis/VG systems? If so that would be amazing! What's the plan, would it be a S-100 card with an SD card slot onboard? Or would it be an external device that interfaces to your existing FD controller? Would it have the ability to read disk images?
    The device will be a small standalone board with a 50 pin and 34 pin header to accept the corresponding ribbon cable connector for an 8" or 5.25" drive. Most likely battery powered. The device will appear as two drives to the controller. The controller will think it's connected to two 8" or 5.25" drives. Disk images will be saved on a micro-SD card. A two line text display shows the name of the disk image in each of the two drives. Buttons let you scroll through a library of up to 100 disk images by tens or by ones.

    I have tested my prototype version with Micropolis, VG/Tandon (DSDD "Micropolis"), Altair 8" and 5.25", North Star (SD and DD), Polymorphic, Tarbell (SSSD soft sector WD1771), and Vector Graphic 8" (DSDD soft sector WD1793).

    Mike

  4. #14

    Default

    Quote Originally Posted by Eudimorphodon View Post
    I guess what I was envisioning wasn't actually a flux transition device, more along the lines of a conventional "higher level" floppy emulator. So strictly speaking it'd only have to store the actual sector data. (Looking in the Northstar manual a double density sector is 32 bytes of zeros, a sync character, 512 bytes of data, and a check character. Everything but the data itself looks not too hard to synthesize on the fly.)
    The solution you described is used by this combination floppy and MFM hard drive emulator product:
    https://www.drem.info
    That device emulates the NorthStar and Heathkit hard sector floppy drive formats, in addition to many common soft sector floppy formats.
    The MFM hard drive emulator built into the device has been designed to emulate a long list of MFM low level formats.
    Last edited by hmb; August 13th, 2020 at 12:23 PM.

  5. #15

    Default

    acb.jpg

    Seriously when do you think it'll be ready? I never did get that Micropolis drive working that you were helping me with. This'd at least get that system up & running.

  6. #16

    Default

    Quote Originally Posted by nullvalue View Post
    acb.jpg

    Seriously when do you think it'll be ready? I never did get that Micropolis drive working that you were helping me with. This'd at least get that system up & running.
    My plan is to finish the final version this Fall.

    Mike

  7. #17

    Default

    Just saw this thread - do keep us informed of your progress, Mike. I, for one, am very interested!
    Bob Stek
    Saver of Lost Sols

  8. #18

    Default

    Quote Originally Posted by deramp5113 View Post
    My plan is to finish the final version this Fall.

    Mike
    Hey Mike, how are things going with this project? Hope you're making good progress. Still very interested.

  9. #19

    Default

    I planned on having lots of time starting in October to get some serious development done, but unfortunately, real life has gotten in the way. I finally had a bit of time this last week and started PCB layout.

    Mike

  10. #20

    Default

    Quote Originally Posted by deramp5113 View Post
    I planned on having lots of time starting in October to get some serious development done, but unfortunately, real life has gotten in the way. I finally had a bit of time this last week and started PCB layout.

    Mike
    That's awesome! glad to hear it's still in the works.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •