H17 Hard Sector SSD.
Norberto Collado
H17 floppy drives aging issues has been in my mind for a while after losing several of them. A while ago, I started the idea to create a solid state “H17 drive (40/80 track SD/DS)” as a replacement of the current floppy drive. The idea was to use two small microcontrollers to divide the workload with high speed RAM + battery backup + CF card to store RAM content and be compatible with the HDOS TEST17.ABS file. As there are no moving parts, aging should not be an issue. No need to buy expensive floppy media, etc. This design should be a direct replacement of the H17 drive.
It is more like merging the SVD design + Z67-IDE+ design + H89-SBC-4MB SSD design into a single solution. Start first with the 40/80 track, single density, double sided capability and then expand to double density capability if possible.
Power-on/reset
- H17 SSD ready for read/write operations
o Note: The battery backup should keep the data safe, no need to read from the CF card. There should be another copy in the CF card if needed.
DIP switch or jumpers
- Select drive 0/1/2
Hex Switches
- Select floppy position to load/download data from/to CF card into/from RAM (00-99).
CF write
- Select Hex switch position
- Disable Write protect switch
- Press CF write switch
- Data from RAM loaded into the CF card
- Enable write protect switch if needed
- H17 SSD ready for RAM read/write operations
CF read
- Select Hex switch position
- Press CF read switch
- Data loaded from the CF card into RAM
- Reset H8/H89 computer
- H17 SSD ready for RAM read/write operations
Serial Port
- Controller’s FW update
RAM
- 2MB RAM
Microcontroller #1
- Manage all I/O signals from the H17 controller
Microcontroller #2
- Manage Read/Write operations from the H17 controller
I will keep polishing this idea…
Thanks,
Norberto
Douglas Miller
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/44A79F50-CFC3-4415-8CC0-695FE4BE73B0%40koyado.com.
For more options, visit https://groups.google.com/d/optout.
Bob Groh
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/44A79F50-CFC3-4415-8CC0-695FE4BE73B0%40koyado.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/76dciwrlcvihnrvs4xsjgibh.1513779948948%40email.android.com.
John Toscano
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/44A79F50-CFC3-4415-8CC0-695FE4BE73B0%40koyado.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/76dciwrlcvihnrvs4xsjgibh.1513779948948%40email.android.com.
dwight
Do remember, the H17 card would be easy to replace with a uP. It is just a little logic to generate index pulses and uses a USART for data. Both could easily be handled by a uP. It is a little tougher to try to use something in place of the drive.
A Gotex would make a good starting point. It is intended to be use with a USB thumb drive so you have the added complexity of the USB, compared to the CF.
There is a fellow in France at a company called HxC that makes emulators for most MFM and FM drives that you can down load to the Gotex box. I haven't seen any hard sectored emulations yet, though.
The Gotex is intended to be a 3.5 inch but the board can easily be removed and a 5.25 frame made.
I'm fiddling with one the these Gotex right now to see if I can make it do something with my Nicolet 1080. ( 8 inch 32 hard sectored SSSD ).
Anyway, the Gotex uses a STM32F105 with 128K flash and 64K RAM, at 72MHz, so it makes a good playground for fiddling with.
Even if one eventually expected to make one's own boards it makes a nice starting point. Some of the newer STM32 parts run at over 200MHz, with even more Flash and RAM. One might start playing with one of ST Micros Discover
boards in the $20-$30 range.
Dwight
Sent: Wednesday, December 20, 2017 8:54:29 AM
To: se...@googlegroups.com
Subject: RE: [sebhc] H17 Hard Sector SSD.
Lee Hart
> Maybe you should incorporate some Everspin Magnetoresistive RAM (a/k/a
> MRAM): no battery needed for permanent data retention, faster than
> flash memory without the short life in read/write applications, etc.
> Available in parallel or SPI configuration.
>
and drives. Like everyone else, I have a dwindling collection of drives
and disks that still work. Someday, my last working ones will die, and I
won't be able to fix or replace them.
It's also an interesting problem to think about. Lots of solutions exist
today that were unthinkable back then. Gigantic hard drives, massive
memories with non-volatile options like flash ROM, ferroRAM, EEPROM.
Inexpensive mass-produced packaged mass storage like USB thumb drives,
parallel CF cards, serial SD-cards, etc. What to choose?
If the package physically replaces a 5-1/4" half-height drive, there is
lots of room to work. There could be an LCD screen on the front, to
display the "disk label", and perhaps some buttons to step through a
catalog of disks that the box contains. There is plenty of room for
batteries, which with modern CMOS RAMs, could last for decades. There
could be a socket a CF flash, SD-card, or USB stick, for loading or
transferring data and backup to/from a PC or other computer. It could
even have its own Z80; in fact, it could *be* an H8 or H89 computer in
its own right! (My little "Z80 Membership Card" is only 2" x 3.5", and
has a Z80, 64k of memory, SD-card mass storage, runs CP/M, etc.)
I have a "mad" idea that I've often thought would be fun. Have you seen
those cassette tape adapters to play your iPod through your car radio?
It physically looks like a cassette tape, but has a wire dangling out
that you plug into your music player. The music goes to a tape head in
the adapter, which is positioned right against the tape head in the car
radio's tape player.
Now... Have you noticed that a 5-1/4" square piece of ordinary PCB
material fits perfectly in a disk drive? That means we could make a PCB
with a read/write head positioned exactly over the disk drive's own
head. Electronics on the card could "fake out" the drive to make it
think it's reading and writing to a real disk! LEDs can fake the sector
holes and write-protect. Thus, you could have an old computer, complete
with disk drives. Insert this "solid state disk", and you have a working
computer, even if none of the motors in the old drive work!
--
"Verschlimmbessern" (German, verb) - To make something worse by
trying to improve it. (English translation: "Microsoft"?)
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com
John Toscano
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5A3AA271.6010706%40earthlink.net.
Steven Hirsch
> A Gotex would make a good starting point. It is intended to be use with a
> USB thumb drive so you have the added complexity of the USB, compared to
> the CF.
>
> There is a fellow in France at a company called HxC that makes emulators
> for most MFM and FM drives that you can down load to the Gotex box. I
> haven't seen any hard sectored emulations yet, though.
>
> The Gotex is intended to be a 3.5 inch but the board can easily be removed
> and a 5.25 frame made.
>
> I'm fiddling with one the these Gotex right now to see if I can make it do
> something with my Nicolet 1080. ( 8 inch 32 hard sectored SSSD ).
>
> Anyway, the Gotex uses a STM32F105 with 128K flash and 64K RAM, at 72MHz,
> so it makes a good playground for fiddling with.
>
> Even if one eventually expected to make one's own boards it makes a nice
> starting point. Some of the newer STM32 parts run at over 200MHz, with even
> more Flash and RAM. One might start playing with one of ST Micros Discover
> boards in the $20-$30 range.
about hard sector support and he intends to work on it soon. We're starting
with the Northstar floppy format and I hope to forward information on Heath as
well.
On a slightly related subject, the Kryoflux folks have contacted me and asked
for disk format specifications and sample media for Heath and Northstar. They
intend to fully support imaging and (I believe) writing of all common
hard-sector formats. I just dropped a bunch of diskettes in the mail for them
to analyze.
I'm already using Gotek emulators in my Kaypro and have successfully run one
on a Z37 controller (soft-sector, obviously). Oddly, the last time I tried
there were problems writing from an MMS 77316 controller. Something funny
about the timing I think.
Douglas Miller
about the emulator and how it works. Doug Sauby (R.I.P.) spent a lot of
time on the '316 analog circuits, in order to get it to switch "glitch
free" between 8" and 5.25" data rates. Although, the write data side
seems much simpler. But perhaps there is something a little different
about how that signal is generated. MMS didn't use the WD chipset, for
whatever reasons.
On 12/20/2017 03:17 PM, Steven Hirsch wrote:
> ...snip...
Norberto Collado
Did you run the MMS 77316 with the Heath HDOS and CPM OS’s or did you use MMS CP/M?
Thanks,
Norberto
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
Norberto Collado
You read my mind as I was thinking in re-using the drive mechanics with this idea, so that you can get the same sound as the original drive.
Norberto
You received this message because you are subscribed to the Google Groups "SEBHC" group.
Norberto Collado
I looked at the MRAM. They are surface mount and very expensive ($39.46 each). My idea is to re-use what I have in my current tool kit.
Thanks,
Norberto
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/44A79F50-CFC3-4415-8CC0-695FE4BE73B0%40koyado.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/76dciwrlcvihnrvs4xsjgibh.1513779948948%40email.android.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAD9POubMgh9fq3h5JGfdtQ%3DGhdnuJndgg8V89PUcFmtBYVz4Sw%40mail.gmail.com.
Doty, James
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5A3AA271.6010706%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/F57F158C-9AB2-4540-94BA-B9048FF8B658%40koyado.com.
For more options, visit https://groups.google.com/d/optout.
Norberto Collado
You can buy such SSD 5.25” floppy drives from several manufacturers but are very expensive. For example,
http://www.floppyemulator.com/products/flexidrivemv-usb/
http://jimwarholic.com/2009/04/fdd-floppy-disk-drive-emulators.php
Thanks,
Norberto
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5A3AA271.6010706%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/F57F158C-9AB2-4540-94BA-B9048FF8B658%40koyado.com.
For more options, visit https://groups.google.com/d/optout.
--
=================================================================
"Pizza must be good for you. It has dairy products, bread, veggies, and meat! Pizza is like a flat, round food pyramid."
James A. Doty February 9, 2007
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAEC4ejZSa2VzqB0YQTqANnv5GH1HwXrG7OATJRuhKNL43TOt4g%40mail.gmail.com.
david
Norby and the Group,
This is a timely idea. It is a practical solution to a problem we have all faced to some extent. Replacement drives and disks are increasingly difficult to find.
I would like to offer an alternative approach.
The
Raspberry Pi has been used to create virtual floppy drives. A quick web search will reveal
them (https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=58345, http://virtualfloppy.blogspot.ca/2013/10/using-raspberry-pi-to-read-floppy-disks.html, http://amigadrive.blogspot.com.tr/?utm_source=pihuntco&utm_medium=post&utm_campaign=pihunt, etc). I did not see any that are up to the quality of what the folks in this group have produced.
The Pi has most of what is needed, but a simple interface PCB that hosts the Pi is needed. Here are some of the benefits of the approach:
- The Pi 3 uses a real full function OS -- CentOS (Red Hat clone).
- Linux has a large base of well-tested support code, e.g., SSH, Apache, and gcc.
- Has a micro SD slot for disk image storage and all drivers. A 128GB micro SD card should hold more disk images than would ever be needed. No need for backup power.
- Supports a web browser that could host a control program that would manage images, e.g., mount and unmount/save image, transfer images to and from user's workstation.
- The Pi 3 has on board fast ethernet and wireless. This would allow wireless access to the control program for normal operation.
- Command line interface could be implemented via SSH. (Probably the initial interface.)
- Will run NoMachine, which allows full wireless remote access and file sharing to the Pi for development and testing from the developers workstation.
- Should easily fit in half height 5.25" floppy drive form.
- The Pi 3 is a quad core ARM with 40 GPIO pins and 1GB of memory. This should be good enough to support soft and hard sector virtualization simultaneously. (You would need one connector for each drive type.) It should be able to emulate 3 drives of each type simultaneously.
- Leveraging off-the-shelf technology should speed up development cycle.
- And last but not least, it has audio out, so we can provide clanking and whirring sounds. :)
Skills needed would be PCB design, Pi programming skills, knowledge of FM and MFM encoding, mechanical engineering of a 5.25" half height form enclosure.
I can do the interface PCB and some of the Pi programming, but my knowledge of FM and MFM is not very deep. I am a total klutz when it comes to the enclosure.
Any interest in developing this approach?
David
Lee Hart
> I have a "mad" idea... Have you noticed that a 5-1/4" square piece of
> could make a PCB with a read/write head positioned exactly over the
> disk drive's own head. Electronics on the card could "fake out" the
> drive to make it think it's reading and writing to a real disk!
> Wow, a REAL solid-state floppy disk drive!
The one question I have is where to find the head? Would I block the
track motor so it stays in one position, and tap into the STEP an
DIRECTION lines? Or use 40 heads? Or a single long thin head, so it
could be used regardless of the position of the head stepper?
Steven Hirsch
> Did you run the MMS 77316 with the Heath HDOS and CPM OS’s or did you use MMS CP/M?
being available for the 77316.
Steven Hirsch
> I wonder what the problem could be, but I'd probably need to know more about
> the emulator and how it works. Doug Sauby (R.I.P.) spent a lot of time on the
> '316 analog circuits, in order to get it to switch "glitch free" between 8"
> and 5.25" data rates. Although, the write data side seems much simpler. But
> perhaps there is something a little different about how that signal is
> generated. MMS didn't use the WD chipset, for whatever reasons.
difference. It was equally unreliable with Z37 or MMS track format.
The Gotek with HxC firmware is dead reliable with a Z37 controller (both Heath
and Norberto's design).
If / when Jeff gets hard-sector support working it will be very helpful.
Bob Groh
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b4664b2f-1cf4-4a7c-89cd-a5851914cb5d%40googlegroups.com.
Lee Hart
> You read my mind as I was thinking in re-using the drive mechanics with this idea, so that you can get the same sound as the original drive.
you'd have all the right noises. :-)
It's certainly a fun thought-project. All *sorts* of interesting ways to
do it! Everything from the oldest old-school to the very latest
high-tech. I suppose every person implementing it would pick their own
favorite approach.
But I suspect the simplest approach would be to physically remove the
disk controller chip, and replace it with a little adapter board. Reads
and writes to the controller chip would now go to some microcontroller's
I/O ports. This microcontroller would respond like the disk controller
chip would have. The software in the microcontroller to make this work
should be far simpler than trying to "sniff" the serial data stream on
the 34-pin cable.
Norberto Collado
Thanks for the feedback,
Norberto
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
Douglas Miller
the original H17 controller and then simulating the data/signals from
the floppy drive itself (which really doesn't care whether hard-sectored
or soft-sectored media is present). In addition, the pseudo-drive will
need to interpret the signals generated by the H17 controller. That will
be quite different from the "clean" signal protocol of the SASI bus.
Reminds me of what I had to do for the cassette interface for the Wang
programmable calculators. The original hardware has some firm
expectations on how those signals will appear, and they are essentially
analog w.r.t. timing. On the pseudo-drive end you'll also need to
properly interpret the signals from the original hardware - which can
vary subtly in timing. I'm guessing this is the problem seen with Gotek
and the MMS77316.
Long winded way of saying I don't envy you, having to write the firmware.
dwight
As Lee mentioned, it would be much easier to replace the H17 board with a uP and SD card. The Gotek is only missing the sector marking between sectors. That is if it is based on the code that HxC has.
One of the things I was thinking of is to add automatic interleaving. I recall how much difference proper sector interleaving made to BASIC programs that had to read a large amount of data. The emulator could watch and see how much delay was happening between accesses of the next sector. If it found a delay of 1 or 2, it could automatically interleave the sectors, on the fly.
Dwight
Sent: Thursday, December 21, 2017 2:58:31 PM
To: se...@googlegroups.com
Subject: Re: [sebhc] H17 Hard Sector SSD.
Norberto Collado
Glenn Roberts
You lost me Dwight. Why would there ever be an interleave issue on a solid state drive?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/MWHPR14MB1600712178F054E5863F0E23A3020%40MWHPR14MB1600.namprd14.prod.outlook.com.
Norberto Collado
-------- Original Message --------
Subject: RE: [sebhc] H17 Hard Sector SSD.
From: "Norberto Collado" <norberto...@koyado.com>
Date: Thu, December 21, 2017 6:16 pm
To: se...@googlegroups.com
The new board will need to have a jumper to select between hard/soft sectors. Initially I will start with the floppy hard sector support and when stable and working properly, we can add support for soft sector.Norby
-------- Original Message --------
Subject: Re: [sebhc] H17 Hard Sector SSD.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20171221191624.1321cca37f09b4ab87c5049afdc8ceaa.ee55bfa607.wbe%40email09.godaddy.com.
dwight
Hi Glenn R.
Even on the H17 board, the H89 processor concerns itself with index marks and timing. The board doesn't do any processing like a soft sectored floppy controller.
One doesn't write the desired sector or track to the controller card, so it has no idea what the next desired sector will be.
If you are on the floppy side of the controller you don't even know if the processor is looking at the sector marks at the time so you have to generate them as though the disk were rotating.
When BASIC reads a DATA block from the source file, with the resynching of the sectors, it skips 2 sector times before it starts looking for the next sector. This means if it is reading several sectors, you have to wait an additional revolution before you can read the next sector.
Since neither the controller or the drive know the intent of the software, they have to either use interleaved sectors for all applications or send index marks as though sectors were going by.
If it saw delayed sequential sector accesses, it could change the interleave on the next access to help optimize the access time.
Not all programs add delay when reading sequential sectors but BASIC does. One could build in an interleave and penalize other programs or tr to be smarter and optimize access.
Dwight
Sent: Thursday, December 21, 2017 6:17:52 PM
To: se...@googlegroups.com
Subject: RE: [sebhc] H17 Hard Sector SSD.
Douglas Miller
One can also "program" (format) the sectors with a skew, so the
software accesses sectors 1,2,3,4... but might actually be reading
physical sectors 1,6,2,7... (the sector IDs in headers are not
sequential on disk). You still have the risk of penalizing some
applications that are faster/slower. This method was used on many
softsectored formats.
One thing I was wondering is, do these devices record the
bitstream, complete with timing, or do they decypher the bitstream
and store data bytes on the SSD? The most universal method would
be the bitstream, but even then you are concerned with sampling
rate at least. If you decypher data bytes you have a chance of
accessing the data from outside the device, but you run into
issues with any deviations a driver/app might use. A sticky wicket
either way, I think.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/MWHPR14MB1600BB84C5A79E9A6633B5C0A3020%40MWHPR14MB1600.namprd14.prod.outlook.com.
dwight
The Gotek doesn't have a lot of RAM to store data but I suspect it uses bit streams. When reading data it looks to be using a counter to measure the span between falling edges and then converts them into bit streams. The way they are stored on the source files could be anything some just store bit streams. Some of the formats expect data bytes. Reading soft sectored floppies requires some bit streams for the formatting information but the data field could be bytes of data ( you know things like address marks ).
Doing anything other than a bit stream requires knowing something about the original format. If you look on HxC's web page you'll see that he expects the data file to have a header, describing that the sector data looks
like as well as sector size, tracks and sides.
Dwight
William Sudbrink
Hi All,
I’m going to jump into this in a similar vein to Douglas. Why, in this day and age, can’t we just have a simple “raw” virtual floppy? One with no “idea” of the format or other particulars of the stored data. I ask in particular because, besides Heath and S-100, my other favorite vintage “make” is Ohio Scientific. OSI completely rolled their own controller like nothing else in the floppy world.
Anyway, I’m sure that there are relatively cheap stereo record/playback chips where you could use one channel for the data and the other channel for the index (hard or soft sectored pulses) and be guaranteed of the sync. Similar for record, but play the existing index track into the new track. As Douglas said, with this approach, your only limitation seems to be the sampling rate. I’ve suggested this to people in the past and they’ve either started talking to me slowly with words of few syllables or come back with “what’s the use of that”. The first I can’t really address, maybe someone could politely clue me into why the concept is so naively stupid/impossible if it is so. As to the second, yes, you need an existing operating machine to format empty images and copy data onto them, but once you get working images, you can bring up machines with no working floppy (drive or media), I don’t see the need to manipulate the data on other modern platforms. I’d just like collectors to be able to exchange “disks” over the internet. No more “please send me a boot disk”. No more “it didn’t work, maybe something’s wrong with my drive”…”the alignment may be off”…”it’s not rotating at the correct rate”.
Thanks,
Bill S.
Glenn Roberts
Very interesting! Thanks for the education!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/MWHPR14MB1600BB84C5A79E9A6633B5C0A3020%40MWHPR14MB1600.namprd14.prod.outlook.com.
Rob Doyle
you can get them at Walmart, and has a relatively simple interface.
If you can read/write to RAM, it's not that much more difficult to
read/write to an SD card. In it's simplest mode, the SD protocol is
just SPI.
The only limitation is that most modern storage media (SD and otherwise)
has 512 byte sectors. I don't know the sector size of the H17.
I've done SD interfaces in both microcontroller software and in FPGA and
could assist.
On 12/20/2017 3:58 PM, Norberto Collado wrote:
> I looked at the MRAM. They are surface mount and very expensive ($39.46
> each). My idea is to re-use what I have in my current tool kit.
>
> Thanks,
>
Norberto Collado
-------- Original Message --------
Subject: RE: [sebhc] H17 Hard Sector SSD.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/124901d37b59%24fe65b320%24fb311960%24%40verizon.net.
Douglas Miller
Hey Norberto, I'm not sure of the significance of the "one side as the original H17 design" comment. Are you making a replacement controller card for the H17 card? or a replacement for the diskettes and drive(s) that plug onto the H17 controller? I was assuming a replace disk drive to plug into the H17. One issue I can see is that whatever SSD media you use there will be much more space than needed for one diskette, and so there needs to be a way to organize floppy images and "swap out the current floppy", as well as swap out SSD media "on the fly". Since these images are completely abstract to the device, there will need to be some way to stick a label on it - possibly a special program to setup the label before formatting, or else some external interface to add labels (got room on the face plate next to the LCD for a keyboard? Another tricky spot may be the writing of sectors (as opposed to formating tracks). The H89 will be reading the sector header and then will turn on Write Gate and start overwriting the sector data. This was a messy part of normal floppies anyway, so maybe it won't be any more difficult. The signal splicing will be the pudding with the proof. The "spliced in" sector will almost-certainly be out of sync (bitwise, even sub-bitwise) with the sector header formatting, but maybe this will just work as it does now on real floppy disks. I'm still thinking that it will be tricky to get the splicing correct, on both front and back side of the sector data. It depends on how the bitstream and timing is being encoded. It should be possible to write utilities that can extract, as well as generate, images on a modern computer. "It's just software"... It's gonna require copious volumes of viscous liquids I bet.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20171222132326.1321cca37f09b4ab87c5049afdc8ceaa.60f32b0686.wbe%40email09.godaddy.com.
Douglas Miller
Another thought - maybe you're already planning this - seems like
you might as well make this device "simulate" multiple drives in
one. Although that might require multiple media sockets, in order
to provide a similar capability of being able to swap out floppies
from any of the "drives". Introduces some interesting questions on
how to access different images, too. But since the interface cable
has the drive select signals on it, you can just use those to
select a different image file.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/72dbee5e-2d9f-c9c2-9975-b191800ab423%40gmail.com.
Norby
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f1e3f6f5-797c-18bb-80ed-89cc0a67601f%40gmail.com.
deramp
I’ve been a long way down this path in creating a system independent solid state drive that simply records and plays back the flux transitions that would have been recorded on the magnetic media. No attempts are made to interpret the data. It’s only job is to record the data line pulses when writing and play them back when reading.
As mentioned by Bill S and others, a “raw” media replacement like this has the advantage of working transparently with most any type of floppy controller. The only parameters required are:
1) rotation rate (index hole period)
2) number of hard sectors (if any)
3) #tracks and sides
4) read/write precomp model selection
For single density 8” and 5.25” controllers I have found modeling of pulse period compression/expansion is not required for reliable operation, however, it is required for double density applications since most controllers implement either write or read precompensation (mostly write precomp).
Mike
Norberto Collado
The H89 will be reading the sector header and then
will turn on Write Gate and start overwriting the sector data.
This is something that I need to pay attention to have a reliable operation. So, after sending the data Sync byte, I need to pay attention to the write gate signal.
For floppy swapping, I will need to rely on the LCD display with the capability to select which one to mount.
Attached are the index/sector pulses on the cable along with the data when doing an INIT.
Thanks,
Norberto
From: "se...@googlegroups.com" <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Reply-To: "se...@googlegroups.com" <se...@googlegroups.com>
Date: Friday, December 22, 2017 at 1:49 PM
To: "se...@googlegroups.com" <se...@googlegroups.com>
Virus-free. www.avast.com
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/124901d37b59%24fe65b320%24fb311960%24%40verizon.net.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20171222132326.1321cca37f09b4ab87c5049afdc8ceaa.60f32b0686.wbe%40email09.godaddy.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/72dbee5e-2d9f-c9c2-9975-b191800ab423%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f1e3f6f5-797c-18bb-80ed-89cc0a67601f%40gmail.com.
Douglas Miller
Actually, the WG is turned on during the gap between the CRC of the sector header and the data sync byte. Each time a sector is written, a new gap, sync, data, crc (and trailing gap) are written (then WG is turned off) - complete with "jitter" compared to the sector header. But for formatting, WG will be turned on right after the index pulse is detected. Actually, I think I've seen some format code that starts writing at the next sector pulse regardless (I think media test code does that when writing test patterns to the track, which Health/Zenith code did). I would expect that WG is higher priority than data - i.e. anytime WG is on the bit stream is overwritten regardless of where in the bitstream it is.
The difficulty probably varies depending on how you store the bitstream. One method I thought of was to detect the transitions and record the time between them (e.g. counts of the sampling clock). But, if you do that then you have more difficulty when WG is turned on, as it may happen between transitions and so you (may) have to re-organize the data. Also, this method does not produce a predictable track length, as that varies with the number of transitions.
Also, the "gap" is actually not dead-air (void of flux
transitions) but rather a field of 00 bytes. So, as a sector gets
rewritten there appear little glitches in the 00 data at the
points the WG is turned on/off. The idea is that those glitches
should never equate to the sync byte, so it is just a little noise
to be ignored (the data in the gaps is for timing only and never
interpreted).
The whole project is full of interesting problems to solve. I
look forward to seeing how it goes.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4B06AC08-13AA-4368-8C49-B2024422DFDA%40koyado.com.
Norberto Collado
Thanks for the feedback on WG. I think as long the SSD drive can pass without any issues the H17 Heathkit Manual drive tests along with the TEST17.ABS, INIT.ABS, and SYSGEN.ABS, we should be fine.
Norberto
From: "se...@googlegroups.com" <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Reply-To: "se...@googlegroups.com" <se...@googlegroups.com>
Date: Saturday, December 23, 2017 at 3:01 PM
To: "se...@googlegroups.com" <se...@googlegroups.com>
Subject: Re: [sebhc] H17 Hard Sector SSD.
Actually, the WG is turned on during the gap between the CRC of the sector header and the data sync byte. Each time a sector is written, a new gap, sync, data, crc (and trailing gap) are written (then WG is turned off) - complete with "jitter" compared to the sector header. But for formatting, WG will be turned on right after the index pulse is detected. Actually, I think I've seen some format code that starts writing at the next sector pulse regardless (I think media test code does that when writing test patterns to the track, which Health/Zenith code did). I would expect that WG is higher priority than data - i.e. anytime WG is on the bit stream is overwritten regardless of where in the bitstream it is.
Douglas Miller
-------- Original message --------
From: Norberto Collado
Date:12/24/2017 13:56 (GMT-06:00)
To: se...@googlegroups.com
Subject: Re: [sebhc] H17 Hard Sector SSD.
Thanks for the feedback on WG. I think as long the SSD drive can pass without any issues the H17 Heathkit Manual drive tests along with the TEST17.ABS, INIT.ABS, and SYSGEN.ABS, we should be fine.
Norberto
From: "se...@googlegroups.com" <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Reply-To: "se...@googlegroups.com" <se...@googlegroups.com>
Date: Saturday, December 23, 2017 at 3:01 PM
To: "se...@googlegroups.com" <se...@googlegroups.com>
Subject: Re: [sebhc] H17 Hard Sector SSD.
Actually, the WG is turned on during the gap between the CRC of the sector header and the data sync byte. Each time a sector is written, a new gap, sync, data, crc (and trailing gap) are written (then WG is turned off) - complete with "jitter" compared to the sector header. But for formatting, WG will be turned on right after the index pulse is detected. Actually, I think I've seen some format code that starts writing at the next sector pulse regardless (I think media test code does that when writing test patterns to the track, which Health/Zenith code did). I would expect that WG is higher priority than data - i.e. anytime WG is on the bit stream is overwritten regardless of where in the bitstream it is.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
dwight
Since we know what the format is, we don't really need to record every transition. The H17 doesn't use a PLL as I recall, it just uses a clocked oneshot as I recall. The fact that there is jitter between the header and data shouldn't be an issue because there is no memory from pulse to pulse. Since the USART is running in synchronous mode, it will continue to pad stuff out, even when you are not putting anything into the transmit data register.
This simplifies things.
When I wrote the original client code for the disk transfer, I was more in tune with how the format worked. I needed to format the disk to make a boot disk. At least the first track, as I recall.
The code is relatively lacks waiting for the next index so the timing isn't critical. It may not be easy to send pulses for the index while dealing with data but I believe the controller or software isn't looking for exact timing of the pulsed from the sectors or the index.
I think one might be able to use two timers with the outputs wired as open drain. One timer would put out a pulse every rotation while the other would put a pulse out every sector.
It would just be critical to make sure both are always in sync.
As for CP/M or HDOS, I don't think there is any significant difference on the format, for the H17. It is just the data that is different.
Dwight
Douglas Miller
Not to harp on this, but even a field of zeros has magnetic transitions (for the clock), all digital magnetic recording relies on this. So, there will be glitches when WG is turned on/off during a field of zeros, possibly inserting (the appearance of) data or clock pulses.
I thought Norberto said he was looking to do a generic recording
of the signal, in which case no knowledge of the format will exist
in the pseudo-drive. I think the effect of the glitches remains to
be seen in that case.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/MWHPR14MB1600172826AF91F1E13B67F1A3010%40MWHPR14MB1600.namprd14.prod.outlook.com.
dwight
We know where the glitches are so we don't need to reproduce those digitally.
In any case, once the sync value starts there will no longer be glitches. I just looked at the schematic again to make sure and I was right, the H17 data/clock separator uses a clocked counter as the discriminator. After the glitch it only needs one clean clocked 0 to restore its ability to tell clock from data. The sync byte could follow most anywhere after that.
It is not like a PLL that takes some time to recover.
Dwight
Norberto Collado
Douglas Miller
The issue I'm concerned with is not whether the pseudo-drive
accurately reproduces all the nuances of the original
hardware/media, but whether it does not have bugs that cause it
break. This area, where a sector is written, is a very likely area
for problems to arise, if care is not taken. That is the whole
reason I brought it up. It's not an issue of whether the H17 can
tolerate standard drives and media, but whether the pseudo-drive
creates too large of an anomaly or just plain crashes or corrupts
the track. A lot of this depends on how the "data signal" is being
recorded. All I'm saying is that the parts of the firmware that
deal transitions between reading and writing are susceptible to
issues and warrant extra attention.
Also, HDOS and CP/M FORMAT programs are not identical. They each
exposed different bugs in my H17 emulation, and so they interact
(subtly) differently with the hardware. Whether this results in
differences on the drive interface is the question, and the reason
to test using both of them.
Norberto, did I read you correctly in that you desire to making
this a generic floppy drive replacement, and not strictly an H17
10-sector floppy? If a generic solution, then it would need to
save a media type indicator with the floppy image, so you know
whether it has 1 index pulse or 11 (10+1). In theory, the H17 does
not require hard-sector media but it greatly simplifies the
driver. And of course the drives used for the H17 would work on a
soft-sector controller as well.
Having a timer for the index pulse could work well, provided the micro-controller can respond fast enough and rewind the playback without impacting timing. That's another area that will require some attention, I think. It will probably also drive the choice of how to record the bitstream. Wrapping around the playback, without any critical "glitches", will be important, as will handling of WG in proximity to the wrap (although typically the WG will be turned on/off based in response to the index pulse and so will (presumably) be *after* the wrap). I forget the exact timing used to format on the H17, w.r.t. leading or trailing edges of the index/sector pulses. But, the drive probably shouldn't make any assumptions there.
I found Norberto's scope traces interesting. If I read them
correctly, the data trace seemed to show that there were actually
no flux transitions between sectors, as if those areas never got
formatted. I think MMS FORMAT actually formatted the entire track,
but perhaps Heath/Zenith software turned off WG between sectors
during formatting. Although, I thought their FORMAT programs did
full-track verification before formatting into sectors, so the
lack of flux transitions seems odd. Another assumption that the
pseudo-drive shouldn't make (IMHO).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/MWHPR14MB1600F84E460A4986E477B508A3010%40MWHPR14MB1600.namprd14.prod.outlook.com.
dwight
To may knowledge, the CP/M and HDOS H17 disk have the same low level format. It is the data fields that count. The exception is that as I recall, the volume number for CP/M was always 0. Since this is part of the sector headers, it would be considered part of the low level format.
I believe H17 uses the leading edges of the index ( or should based on signal quality ) but I could be wrong.
I've just started to play with my Gotek. I've modified a eForth from Dr Ting so that I can make intelligent tinkering with the ports and counters ( It uses a STM32F107 with 128K of flash for those that want to look it up ). I'm giving though to different options on data storage ( not for the Heath H17 ) but have not decided. The Gotek uses a USB thumbdrive. It has a place a person could stack a number of serial EEPROMs. USB is still a little hidden science to me but I guess I could down load the libraries from STM and use that but I find libraries to carry large amounts of baggage that is never used. I usually go to the CPP files and clean the trash out.
I any case, with the Forth interpreter on the Gotek I can experiment with how to control the different features ( making useful sense of the data sheets ). I don't know why but it takes 5 pdfs to get a handle on the F105 part. STM is a little better with newer parts. The STM32F4xx parts manuals are a lot better organized.
Anyway, I just this last weekend got to the point that I can turn a LED on and off. I'm attacking the from panel 7seg x3 display. It is through an almost I2C interface. It has no address part, just the data.
Dwight
Norberto Collado
“Norberto, did I read you correctly in that you desire to making this a generic floppy drive replacement, and not strictly an H17 10-sector floppy? If a generic solution, then it would need to save a media type indicator with the floppy image, so you know whether it has 1 index pulse or 11 (10+1). In theory, the H17 does not require hard-sector media but it greatly simplifies the driver. And of course the drives used for the H17 would work on a soft-sector controller as well.”
I will start first with the H17 SDD and then as I build knowledge on this, I will add H37 support (use jumpers to select which one to use). Start simple first and then grow to a more complex solution. The best configuration to have is the H17 along with the H67 controllers (sweet spot).
“Having a timer for the index pulse could work well, provided the micro-controller can respond fast enough and rewind the playback without impacting timing.”
Once a hole is detected (4ms hole +16ms no-hole), I have 20ms to read or write a sector into/from RAM (350 bytes), so using a timer for Index and sector count, should not be a problem. If the hardware can do it, then less FW to develop. I can use the sector pulse to interrupt the controller to find out the sector number (0-9) before starting any reads/writes. The index pulse will be used to sync the timers. Also, same index pulse (without the hard sectors holes) can be used for H37 floppy support.
I’m still scoping/brainstorming this, so things might change as I build out information on how this will work from a hardware/FW point of view. I will capture more waveforms with the sector/index holes + data + WG to understand better the timing. Attached is what I captured when doing INIT.ABS. You can see immediately during the assertion of the hole pulse, there is a sync pulse + Zero Gap, so I have to do the same. In this waveform, I was checking the “Zero Gap” timing at the end and beginning of a sector.
Thanks,
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/MWHPR14MB16000639984F7E970B07B917A3060%40MWHPR14MB1600.namprd14.prod.outlook.com.
Norberto Collado
I will need help in getting a simple HDOS program to write/read the following pattern (provide by Mark), after selecting specific track number and specific sector number, from a given floppy drive.
The HDOS program will ask for the drive number, track number, and for the sector number to write/read such pattern.
This will help me in debugging the timing/FW.
Something like this:
> WTRKSEC.ABS
Drive number <0,1,2>: 1
Enter track number <0-80>: 12
Enter sector number <0-9>: 9
Operation completed.
>
>RTRKSEC.ABS
Drive number <0,1,2>: 1
Enter track number <0-80>: 12
Enter sector number <0-9>: 9
Operation completed.
Pattern:
Sector Sub-Block:
Sector: 9
Sector Valid
Length: 350
Data:---------------------------------------------------------------
000: 0000000000000000 000000fd00000912 |........ ........|
016: 0000000000000000 0000000000000000 |........ ........|
032: 0000fd9a2916de00 ee00020116000000 |....)... ........|
048: 0000000046494c45 20434f504945522d |....FILE COPIER-|
064: 2d544f20434f5059 20414e4420524556 |-TO COPY AND REV|
080: 4953452042415349 432046494c455320 |ISE BASI C FILES |
096: 4f4e203220444953 4b53202020202020 |ON 2 DIS KS |
112: 200020202020200d 0a53595354454d20 | . . .SYSTEM |
128: 434f505952494748 5420484541544820 |COPYRIGH T HEATH |
144: 434f2e2c2031302f 313937372c203739 |CO., 10/ 1977, 79|
160: 2f340d0a20425920 4a474c2c2031302f |/4.. BY JGL, 10/|
176: 313937372f676320 2867687420284329 |1977/gc (ght (C)|
192: 2048454154482043 4f2e2c2031393739 | HEATH C O., 1979|
208: 0a20286279204741 4328696e2072656d |. (by GA C(in rem|
224: 656d6272616e6365 206f66204a474c29 |embrance of JGL)|
240: 290a0a040a0a436f 7079726967687420 |).....Co pyright |
256: 2843292048454154 4820434f2e2c2031 |(C) HEAT H CO., 1|
272: 3937390a20286279 2047414328696e20 |979. (by GAC(in |
288: 72656d1700000000 0000000000000000 |rem..... ........|
304: 0000000000000000 0000000000000000 |........ ........|
320: 0000000000000000 000000fd00000000 |........ ........|
336: 0000000000000100 000000000000 |........ ...... |
------------------------------------------------------------------
Thanks,
Norberto
deramp
If you are making a raw replacement of a floppy drive where the unit is merely recording the timing of the write line pulses during writes and playing that recording back when not writing, all of these various timing and data issues you are worrying about go away. If it worked on a real floppy, it will work on your device. The original controller and software were designed to work around the drive and it’s timing, not the other way around. If your device is simply replacing the recording and playback of what would have ended up as flux transitions on the mag media with solid state recording, then it just works.
I’ve done this, it works with hard sector Altair, Micropolis, and North Star. It works with soft sector controllers as well. It works because it duplicates a floppy drive at the lowest level - no attempt is made to figure out what data is sent or read from the disk.
The only issue I ran into was the move to support double density in which the pulse crowding/expansion of the flux transitions on magnetic media must be modeled in your solid state record/playback. This is because the controllers are compensating for this effect in their precomp circuits. Therefore, your record/playback must also duplicate this effect.
Mike
Steven Hirsch
--
deramp
Can you tell us more about the device you built?
--
Steven Hirsch
>
reliably. A few years ago I tried to use a Kryoflux board to read 8"
diskettes in MMS 77316 native format (512-byte sectors). It had a lot of
problems on the inner tracks of disks that read just fine on a WD style
controller.
> I only had 96K of RAM in the PIC so I could only emulate a single track
> of data at a time. An Arduino Due with just a bit of external interface
> hardware and an SSD card would probably be a good way to implement a
> fully functional version of this before diving into a fully custom
> hardware development.
Rob Doyle
to me that this might be a decent platform for this also.
http://wiki.stm32duino.com/index.php?title=STM32F407
http://wiki.stm32duino.com/images/4/4f/STM32F407ZET6_sch-1.pdf
This is a 168 MHz ARM Cortex M4 with all the goodies including 5V
tolerant IO, 512K Flash, 192K RAM, 3x SPI, 6x UARTS, PWM, 17x Timers,
SD Card, Ethernet, etc. It looks like you can run the timers at 168 MHz
- so better than 10ns timing should be easy.
$10.50 on EBAY.
<https://www.ebay.com/itm/STM32F407VET6-STM32-Cortex-M4-Development-Board-NRF2410-FMSG-SD-Card-No-Battery/201950756099?epid=15002706333&hash=item2f0533fd03:g:1QQAAOSwDtpZbiNZ>
Rob.