Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Floppy disk drive emulator for Sol-20

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Floppy disk drive emulator for Sol-20

    Does anyone make a floppy disk drive emulator for the Sol-20 computer? I've been looking for actual floppy disk drive and controller card for a while, but have yet to see these for sale anywhere, except for the Helios drive which in most cases is very expensive and have a finicky reputation.

    #2
    The North Star double density controller and a couple of 5.25" drives was a very popular addition to the Sol-20. Far more so than the Helios. You can use a couple of 5.25" full height drives or a couple of 48 tpi half-height drives.

    Mike

    Comment


      #3
      Mike, Ok. Sounds good. Where can I get the 5.25" drives and controller card?

      -Gil

      Comment


        #4
        The double density card comes up from time to time on ebay, like this one in the completed listings:

        https://www.ebay.com/itm/S-100-North...p2047675.l2557

        It is a matter of waiting and watching to get one, unless one is for sale by a forum member.

        For my SOL-20 I use this card along with two new old stock IBM drives, and Mike's VSG.

        I got my disk drives from ebay.

        I wrote an article about the drives and putting them in a box with a power supply, which also powers the VSG, but it comes powered by a battery too. Mike supplies the VSG assembled & tested too, which is helpful to eliminate variables with the initial setup.

        Also with the Northstar card it pays to clean up the IC sockets & pins to make sure it is reliable. One day one of my Northstar cards just stopped because one of the socket claws was damaged and had a poor connection to an IC's pin. I test the socket claw tensions with a single pin from a defunct IC soldered to a wire handle, to make sure they are good, sometimes they were damaged by rough insertion of an IC, especially the TI type of socket.

        http://worldphaco.com/uploads/EXTERNAL_DUAL_5.pdf

        (PS: when you string the two(or more) drives together on the same ribbon cable, don't forget to take the terminator resistor out of the first one/s in the chain).
        Last edited by Hugo Holden; August 12, 2020, 04:14 PM.

        Comment


          #5
          I’m working on a solid state replacement for early disk drives. This will be a very low-level floppy drive emulation that simply records the flux transition pulses on the write data line during writes and then plays them back on the read data line the rest of the time. The unit needs to know nothing more than the rotation rate of the drive and the number of hard sectors (if any) to replace most any 8”, 5.25”, or 3.5” floppy drive.

          Mike

          Comment


            #6
            Originally posted by deramp5113 View Post
            Im working on a solid state replacement for early disk drives. This will be a very low-level floppy drive emulation that simply records the flux transition pulses on the write data line during writes and then plays them back on the read data line the rest of the time. The unit needs to know nothing more than the rotation rate of the drive and the number of hard sectors (if any) to replace most any 8, 5.25, or 3.5 floppy drive.
            I've been wondering about the possibilities for this myself, although it's a significantly more involved project than I've pulled off up to this point. The germ I've been pondering is if this could be done with the same "Blue Pill" hardware as the Greaseweazle; just load a track's worth of flux data at a time into the Blue Pill's meager RAM over USB and swap it out when the disk steps.

            (Using a controller with more RAM than the Blue Pill would make it easier, probably.)
            My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

            Comment


              #7
              With many of the early controllers (e.g., hard sector controllers), you have no way to stall the controller or host software without making assumptions about how the controller works and/or how the host software uses the controller. To make a drive replacement that is truly universal, and therefore independent of controller and/or host software specifics, disk data has to be immediately available as fast as it is in a real drive. Essentially, this means the entire disk needs to be in RAM.

              Mike

              Comment


                #8
                Originally posted by deramp5113 View Post
                With many of the early controllers (e.g., hard sector controllers), you have no way to stall the controller or host software without making assumptions about how the controller works and/or how the host software uses the controller. To make a drive replacement that is truly universal, and therefore independent of controller and/or host software specifics, disk data has to be immediately available as fast as it is in a real drive. Essentially, this means the entire disk needs to be in RAM.
                I was thinking specifically of a device that could work in the Northstar 10 sector Double Density controller, and the rough line of thinking was along the lines of:

                1: My memory isn't certain on this so I should probably look up a datasheet, but my vague recollection is that old floppy drives like the SA400 usually had track-to-track stepping times in the 30ms-ish ballpark? (Just looked up the datasheet, it says 40ms plus a 10ms settling time.)

                2: The quoted minimum latency for "full speed" USB is 1ms. If I assume that I need to transfer 10Kb of data for a track full of data the raw time necessary for that at 12mb/s is around... 7ms?

                Maybe the actual time to play with is less than the 50ms the SA400 manual implies, but... there is still about a 4x gap between the minimum USB latency + theoretical data transfer time? Obviously all bets are off if there's a USB hub in the way that makes the transfer time less predictable, but in theory at least that's what made me think it might be doable?

                Also, and I don't know if this saves it even more, at 300 RPM there's 200ms between full rotations. Does the Northstar controller want to see an "Index" pulse after stepping before continuing to read or write? If it does that gives you a full 1/5th of a second to shuffle buffers.

                Obviously this wouldn't work in the case of something like an Apple II drive, where the index pulse means nothing and you can do half-steps while reading and writing to do crazy stuff like spiral tracks...
                My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                Comment


                  #9
                  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.

                  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.

                  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.

                  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.

                  After trying all sorts of things, the only answer I can find than makes no assumptions about controller operation or host software is to keep the disk image in RAM (or other zero-latency storage). A non-real time transfer from RAM to SD card or USB stick can take place whenever a new disk file is selected to "insert" into the drive, the power-off button is pressed, etc.

                  Mike

                  Comment


                    #10
                    Originally posted by deramp5113 View Post
                    I’m working on a solid state replacement for early disk drives. This will be a very low-level floppy drive emulation that simply records the flux transition pulses on the write data line during writes and then plays them back on the read data line the rest of the time. The unit needs to know nothing more than the rotation rate of the drive and the number of hard sectors (if any) to replace most any 8”, 5.25”, or 3.5” floppy drive.

                    Mike
                    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?

                    Comment


                      #11
                      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 Also: Blogspot

                      Comment


                        #12
                        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

                        Comment


                          #13
                          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

                          Comment


                            #14
                            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 13, 2020, 11:23 AM.

                            Comment


                              #15
                              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.

                              Comment

                              Working...
                              X