Floppy emulator

[Glenn Roberts]

I suspect we’ve discussed this device here before (?) but wondering what any of the group’s experience is with the HxC2001 floppy drive emulator:

 

http://hxc2001.com/index.html

 

I’m thinking of it for my old H120 (z100) machine that I built from a kit years ago.  That machine’s main issue is the unreliability of old floppy disks/drives.  I could add a hard drive emulator (like Norberto’s IDE+ device – there are S100 equivalents) but this device seems to allow you to load up disk images and electronically cycle through them, which might be a cool solution.  As I understand it, one device emulates two drives.  not clear how you load the images though (site says you need a “PC”)?

 

This device might also work with the soft sectored H8/H89 machines – maybe even with the H17 using HSFE? 

 

Thoughts? Experiences?

 

-          Glenn

 

[Steven Hirsch]

On 11/22/2015 08:29 AM, Glenn Roberts wrote:
> I suspect we've discussed this device here before (?) but wondering what any
> of the group's experience is with the HxC2001 floppy drive emulator:

> http://hxc2001.com/index.html

I see no indication that device can emulate a hard-sectored diskette drive.
If it did, I'd buy one in a heartbeat to support my Northstar systems.

[Kenneth L. Owen]

Hi Steven and Glenn,

I browsed the site acquired by the link. Since they are selling what they
have developed, there's not a lot of technical data, specifications, etc.

From what I did glean from the page, it appears that they are loading the
files to a standard SD card. The embedded processor reads the SD card
format and then outputs the data with appropriate data headers between the
blocks of file data. Hard sector interface would only require the pulse
signal for the extra holes (hard sectoring) to be in the output stream, much
like what was done with the HSFE. This would probably require a revision to
the firmware for the imbedded controller to emulate the H-17 floppy.

-- ken

--
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/5651CE65.3080006%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Norberto Collado]

Glenn,

The Big Board was using this device with CP/M. Please check the movie at:

http://koyado.com/Heathkit/Ferguson_BigBoard_II.html

A picture is attached along with the TRS80 computer!

Norberto

-------- Original Message --------
Subject: [sebhc] Floppy emulator
From: "Glenn Roberts" <glenn.f...@gmail.com>
Date: Sun, November 22, 2015 5:29 am
To: <se...@googlegroups.com>

I suspect we’ve discussed this device here before (?) but wondering what any of the group’s experience is with the HxC2001 floppy drive emulator:

 

http://hxc2001.com/index.html

 

I’m thinking of it for my old H120 (z100) machine that I built from a kit years ago.  That machine’s main issue is the unreliability of old floppy disks/drives.  I could add a hard drive emulator (like Norberto’s IDE+ device – there are S100 equivalents) but this device seems to allow you to load up disk images and electronically cycle through them, which might be a cool solution.  As I understand it, one device emulates two drives.  not clear how you load the images though (site says you need a “PC”)?

 

This device might also work with the soft sectored H8/H89 machines – maybe even with the H17 using HSFE? 

 

Thoughts? Experiences?

 

-          Glenn

 

--
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/001301d12529%24c5640b90%24502c22b0%24%40gmail.com.

[Norberto Collado]

I did try this one which is a different version and only works with the PC and not with the H8/H89.

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20151122123227.1321cca37f09b4ab87c5049afdc8ceaa.1b62e17cd2.wbe%40email09.secureserver.net.

[Steven Hirsch]

On 11/22/2015 02:32 PM, Norberto Collado wrote:

> The Big Board was using this device with CP/M. Please check the movie at:
>

> _http://koyado.com/Heathkit/Ferguson_BigBoard_II.html

Yes, but neither of those systems use hard-sector formats. It would be good
if the answer was as simple as using the sector pulse generator in between the
computer and the emulator, but I won't go to the bank on that. I've had a
fair amount of experience with drive emulators (for both floppy and hard disk)
and they are not a universal plug-and-play replacement for rotating media.
All have assumptions baked into their firmware regarding the signaling.

I've been working for a year with David Gesswein's MFM hard drive emulator and
there are still some lingering issues with compatibility on at least one of my
classic systems (Northstar Advantage). If anyone is curious:

http://www.pdp8online.com/mfm/mfm.shtml

[Chris Elmquist]

On Sunday (11/22/2015 at 12:46PM -0700), Norberto Collado wrote:
> I did try this one which is a different version and only works with the
> PC and not with the H8/H89.

I have played with one of the units Norberto references also and it
is true it is PC format specific. But I think that doesn't preclude
it working with the H/Z-100 since that machine uses the same MSDOS and
CP/M-86 disk format as a PC did-- 180K, 360K soft-sector at 80 tracks.
I can't guarantee it will work since I haven't tried it but I think the
likelihood is pretty high.

These are all based on a design from a Chinese outfit called "GoTek",

http://gotek.en.ecplaza.net/

https://www.youtube.com/watch?v=taFP1J_lZBI

http://virtuallyfun.superglobalmegacorp.com/2012/12/20/virtual-floppy-drive-part-ii-testing-gotek/

There are some projects out there where people are making their own
firmware for these units and repurposing them for specialized formats
found in older test equipment such as HP and LeCroy logic analyzers,
spectrum analyzers, etc.

Chris

> -------- Original Message --------
> Subject: RE: [sebhc] Floppy emulator
> From: "Norberto Collado" <[1]norberto...@koyado.com>
> Date: Sun, November 22, 2015 11:32 am
> To: [2]se...@googlegroups.com
> Glenn,
> The Big Board was using this device with CP/M. Please check the movie
> at:
> [3]http://koyado.com/Heathkit/Ferguson_BigBoard_II.html
> A picture is attached along with the TRS80 computer!
> Norberto
>
> -------- Original Message --------
> Subject: [sebhc] Floppy emulator
> From: "Glenn Roberts" <[4]glenn.f...@gmail.com>
> Date: Sun, November 22, 2015 5:29 am
> To: <[5]se...@googlegroups.com>
> I suspect weâve discussed this device here before (?) but wondering
> what any of the groupâs experience is with the HxC2001 floppy drive
> emulator:
>

> [6]http://hxc2001.com/index.html
>
> Iâm thinking of it for my old H120 (z100) machine that I built from a
> kit years ago. That machineâs main issue is the unreliability of old

> floppy disks/drives. I could add a hard drive emulator (like

> Norbertoâs IDE+ device â there are S100 equivalents) but this device

> seems to allow you to load up disk images and electronically cycle
> through them, which might be a cool solution. As I understand it, one
> device emulates two drives. not clear how you load the images though

> (site says you need a âPCâ)?
>
> This device might also work with the soft sectored H8/H89 machines â

> maybe even with the H17 using HSFE?
>
> Thoughts? Experiences?
>
> - Glenn
>
> --
> 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 [7]sebhc+un...@googlegroups.com.
> To post to this group, send email to [8]se...@googlegroups.com.

> To view this discussion on the web visit

> [9]https://groups.google.com/d/msgid/sebhc/001301d12529%24c5640b90%2450
> 2c22b0%24%40gmail.com.
> For more options, visit [10]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 [11]sebhc+un...@googlegroups.com.
> To post to this group, send email to [12]se...@googlegroups.com.

> To view this discussion on the web visit

> [13]https://groups.google.com/d/msgid/sebhc/20151122123227.1321cca37f09
> b4ab87c5049afdc8ceaa.1b62e17cd2.wbe%40email09.secureserver.net.
> For more options, visit [14]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 [15]sebhc+un...@googlegroups.com.
> To post to this group, send email to [16]se...@googlegroups.com.

> To view this discussion on the web visit

> [17]https://groups.google.com/d/msgid/sebhc/20151122124656.1321cca37f09
> b4ab87c5049afdc8ceaa.08adddfea8.wbe%40email09.secureserver.net.
> For more options, visit [18]https://groups.google.com/d/optout.
>
> References
>
> 1. mailto:norberto...@koyado.com
> 2. mailto:se...@googlegroups.com
> 3. http://koyado.com/Heathkit/Ferguson_BigBoard_II.html
> 4. mailto:glenn.f...@gmail.com
> 5. mailto:se...@googlegroups.com
> 6. http://hxc2001.com/index.html
> 7. mailto:sebhc+un...@googlegroups.com
> 8. mailto:se...@googlegroups.com
> 9. https://groups.google.com/d/msgid/sebhc/001301d12529%24c5640b90%24502c22b0%24%40gmail.com?utm_medium=email&utm_source=footer
> 10. https://groups.google.com/d/optout
> 11. mailto:sebhc+un...@googlegroups.com
> 12. mailto:se...@googlegroups.com
> 13. https://groups.google.com/d/msgid/sebhc/20151122123227.1321cca37f09b4ab87c5049afdc8ceaa.1b62e17cd2.wbe%40email09.secureserver.net?utm_medium=email&utm_source=footer
> 14. https://groups.google.com/d/optout
> 15. mailto:sebhc+un...@googlegroups.com
> 16. mailto:se...@googlegroups.com
> 17. https://groups.google.com/d/msgid/sebhc/20151122124656.1321cca37f09b4ab87c5049afdc8ceaa.08adddfea8.wbe%40email09.secureserver.net?utm_medium=email&utm_source=footer
> 18. https://groups.google.com/d/optout



--
Chris Elmquist

[Chris Elmquist]

On Sunday (11/22/2015 at 02:53PM -0500), Steven Hirsch wrote:
> On 11/22/2015 02:32 PM, Norberto Collado wrote:
>
> >The Big Board was using this device with CP/M. Please check the movie at:
> >
> >_http://koyado.com/Heathkit/Ferguson_BigBoard_II.html
>
> Yes, but neither of those systems use hard-sector formats. It would be good
> if the answer was as simple as using the sector pulse generator in between
> the computer and the emulator, but I won't go to the bank on that. I've had
> a fair amount of experience with drive emulators (for both floppy and hard
> disk) and they are not a universal plug-and-play replacement for rotating
> media. All have assumptions baked into their firmware regarding the
> signaling.

I'd recommend not going to the bank either since I tried it and it
doesn't work ;-)

The units are very specific to the sector format (specifically the sync
pattern, header structure, framing, CRC, bla, bla) that a WD or NEC
soft-sector controller in the PC would have produced. Therefore, the
off-the-beaten path format of the H-17's encoding is a significant fail.

You'll be much more likely to succeed with soft-sector formats that are
generated by a WD controller and pretty much match exactly what a PC
reads and writes. Outside that box and the units aren't going to work.

You definitely have all the hardware you'd need to do it in one of them
but you'd have to make your own firmware for it to get 'er done.

I started investigating this unit from an Estonian company,

http://www.floppydrive.eu/floppydrive-emu/emudrive.html

but ran into a language issue trying to determine if they were open to
allowing custom firmware to be developed. If anyone speaks Estonian,
we might be able to go farther down that path ;-)

> I've been working for a year with David Gesswein's MFM hard drive emulator
> and there are still some lingering issues with compatibility on at least one
> of my classic systems (Northstar Advantage). If anyone is curious:
>
> http://www.pdp8online.com/mfm/mfm.shtml

I have one too but it's still a ways down in my project queue. Goal is
to replace the MFM drive in my DEC Rainbow.

Chris
--
Chris Elmquist

[Norberto Collado]

Chris,

The link below describes on how to modify the gotek unit to work with the Amiga. Perhaps something like this could be done for the H8/H89.

https://cortexamigafloppydrive.wordpress.com/

Norbert

[Chris Elmquist]

On Sunday (11/22/2015 at 03:07PM -0700), Norberto Collado wrote:
> Chris,
>
> The link below describes on how to modify the gotek unit to work with
> the Amiga. Perhaps something like this could be done for the H8/H89.
>

> [1]https://cortexamigafloppydrive.wordpress.com/

Indeed it could _but_, you have a fairly steep clime to get to where
you have a firmware you could modify to do the H17 encoding.

I don't see any links to the firmware source those guys are working with
so if you can't get that, you're starting from zero and that's a long
way away from the endpoint.

Somebody must have reversed the hardware design and then you'd start
from scratch making a firmware with the goal of handling the H17 format
on the other side. It's a lot of work but definitely not impossible.

Chris
--
Chris Elmquist

[Brian Marstella]

While I haven't pursued this project, you might look at the downloads on the HCX2001 page http://hxc2001.free.fr/floppy_drive_emulator/index.html#download as it has source code for the CPLD, associated board schematics, etc. A firmware change would definitely be needed as it was designed to work with soft-sectored hardware and from my limited knowledge of the operation it wouldn't know how to deal with anything else. I purchased a bare board from him last year but never had a chance to assemble the unit. Lotharek seems willing to help with other formats as well although this is a fairly major departure from the existing firmware.

[Lee Hart]

Just thinking out loud here...

Is the goal to replace an old unreliable mechanical disk drive with
something more modern and reliable (like an SD-card or USB thumb drive)?
And the computer already has a working disk controller card (of any type
or format, be it 5.25", 8", hard-sector, soft-sector, etc.)? Is that
correct?

If so, maybe it's not necessary to decode, or even to understand the
format of the serial data that's written to the disk.

SD-cards and USB thumb drives have vast amounts of storage, and
extremely high data transfer rates. Fast microcontrollers are available
with on-chip support for these storage devices.

So, why not program a micro to simply read/write the serial data coming
from the disk controller chip, and blindly record/play it back from the
digital media? On read, It works like a tape recorder -- make no attempt
to understand the data format; just record it, and play it back as-is.
Let the disk controller chip and software in the target computer handle
the data encoding and decoding.

Such a brute-force solution might write a megabyte of data to store a
single 5k track of a floppy disk. It's wasteful; but even with this 20:1
loss, a 4Gb SD-card can hold 40,000 100k disks.

Or, a fast enough micro can "pack" the data by only storing the time
between data transitions or pulses.

There will also be some low-speed overhead. The micro will also need to
watch the digital control lines for the floppy disk drive (step in/out,
home, write protect, sector hole), and handle them.

Yes, I know I'm glossing over a lot of details to keep this post short.
But if this approach works, it should eliminate any need for the "disk
drive simulator" to know, or even care what the target computer is, what
disk controller card it has, what operating system it's running, or the
disk formats it uses.

--
Do the thing that needs to be done, even if no one else yet notices
that it needs doing. -- anonymous
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

[Norberto Collado]

Lee,

Thanks for the feedback. We have the SVD and perhaps it could be modified to use an USB interface rather than using RAM.

 http://sebhc.lesbird.com/storage/storage.html#SEMI-VIRTUAL_DISK

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/565365FB.9030905%40earthlink.net.

[Bill Sudbrink]

Lee Hart wrote:
> Is the goal to replace an old unreliable mechanical
> disk drive with something more modern and reliable
> (like an SD-card or USB thumb drive)? And the computer
> already has a working disk controller card (of any
> type or format, be it 5.25", 8", hard-sector, soft-sector,
> etc.)? Is that correct?

That's been my take on it. The one additional benefit
would be that collectors could exchange data (boot disks,
etc.) without having to exchange physical media. As I
saw it, the only setting on the unit (or in the virtual
floppy file in it) would be the index pulse pattern and
repeat rate. Maybe a max track number if you want to
faithfully simulate banging the head against the stop.
You would even have to format a "blank" virtual diskette
file before you could use it.

> If so, maybe it's not necessary to decode, or even to
> understand the format of the serial data that's written
> to the disk.

It has to be synchronized with the index pulse (pulses)
and a "track counter" but otherwise, yes.

I started on something like this to support OSI computers a
long time ago. Unfortunately, I got side tracked and never
got back to it.

Bill S.

[Bill Sudbrink]

SVD is still interpreted data, not raw I/O.

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7227 / Virus Database: 4457/10948 - Release Date: 11/04/15
Internal Virus Database is out of date.

--
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/20151123122817.1321cca37f09b4ab87c5049afdc8ceaa.9091e39960.wbe%40email09.secureserver.net.

[Steven Hirsch]

On 11/23/2015 02:28 PM, Norberto Collado wrote:
> Lee,
>
> Thanks for the feedback. We have the SVD and perhaps it could be modified to use
> an USB interface rather than using RAM.
>
> http://sebhc.lesbird.com/storage/storage.html#SEMI-VIRTUAL_DISK

If the SVD hardware can be ported to a device that can handle larger emulated
disks, it would be a fine solution. I think memory on the microcontroller was
the issue.

[Norberto Collado]

I have the Z67-IDE+ design with two high capacity CF cards. At one time, I
was thinking on adding the floppy interface, to emulate 4 floppy drives to
support the hard and soft sector extended format floppy drives. Will that
work?

Norberto

[Steven Hirsch]

On 11/27/2015 02:36 AM, Norberto Collado wrote:
> I have the Z67-IDE+ design with two high capacity CF cards. At one time, I
> was thinking on adding the floppy interface, to emulate 4 floppy drives to
> support the hard and soft sector extended format floppy drives. Will that
> work?

It would be great for use with the H89, but I have other systems (Northstar
Horizon and Advantage) with hard-sector controllers. Ideally I'd like an SVD
with capacity to emulate up to 1.44MB hard-sector diskettes.

[Norberto Collado]

I like Lee proposal and the Z67-IDE+ will be ideal to test such concept:

"Why not program a micro to simply read/write the serial data coming from the disk controller chip, and blindly record/play it back from the digital media? On read, It works like a tape recorder -- make no attempt to understand the data format; just record it, and play it back as-is. Let the disk controller chip and software in the target computer handle the data encoding and decoding."

As I have the SVD and the Z67-IDE+, I can combined the two boards on the bench to develop the code to support the Heath Floppy Hard Sectored and the Heath Soft Sectored media. I will need to rely on this group to get help as needed.

Also as the target is to support four floppy drives, then have two 34 pin connectors, one for the H17 and one for the H37, and have each one controller drive two soft floppy media along with a single physical floppy drive attach to each. I can assigned one CF card to the H17 controller and the second CF card to the H37 controller for backup purposes. We can use the soft BCD switches to select any soft floppy media on the fly. Also be able to select 300/360 RPM's. Once we get a working stable code, then we can expand to support other systems.

This is thinking at a high level concept. 

Norberto

-------- Original Message --------
Subject: Re: [sebhc] Re: Floppy emulator

[Herbert Johnson]

On Friday, November 27, 2015 at 7:28:43 PM UTC-5, Norby wrote:

I like Lee proposal and the Z67-IDE+ will be ideal to test such concept:

"Why not program a micro to simply read/write the serial data coming from the disk controller chip, and blindly record/play it back from the digital media? ..."

As I have the SVD and the Z67-IDE+, I can combined the two boards on the bench to develop the code to support the Heath Floppy Hard Sectored and the Heath Soft Sectored media. I will need to rely on this group to get help as needed......Also be able to select 300/360 RPM's. Once we get a working stable code, then we can expand to support other systems.

This is thinking at a high level concept. 

Norberto

----------------------

Also thinking at a high level....once such a product is created, you'll end up with a bunch of "imaged" disk files on your flash media. Those will be unique disk images to your product only, and to the target computer (H8, H89). Only your hardware can reinterpret the images; and only the controller in use on that target can operate the product to process those images. Right? And so the collective set of those images, become a common archive, of H8 and H89, etc, software. And various private archives and backups of course.

So what happens to the larger universe of H89 and H8 owners without that hardware? They can't use the images, can't contribute to or extract from that archive. Likewise, all those other file archives, of all those other disks which were "imaged" by various means - those can't be "converted" into your product's format, unless you "import" them on a target computer by whatever means; and them "export" them from the target computer back to your product. Who is gonna do that for hundreds of images?

The alternative to that, might be to 1) design the product to create a relatively transparent and documented disk image format and 2) design some conversion software, to interpret the images into other, relatively common disk image formats; and to read those formats into the product's "imaged" format. Then 3) others can read the docs and look at the conversion code, and produce other conversion tools in the future. Maybe, a future where that hardware product is not available.

I'd call this a "high level view" too.

Point 1) about "transparent and documented", means that there's plenty of information included in the so-called "tape recording", so that some conversion program (or human being) can read that information and figure out where and what that imaged disk was about. This is more important when thinking about use on "other" systems, supported by people with zero involvement in the original product development; or people who simply don't or can't obtain the hardware.

Point 2) about "conversion", means (pardon me) this new imaging scheme is not an orphan, like many other disk imaging schemes which come and go, that only one set of people with one set of hardware can use.

An example of a "transparent and document" imaging scheme, and some conversion tools,  is Dave Dunfield's "imagedsk" format. He uses a conventional FDC chip as a basis for his format- that produces track and sector information, and he has descriptors for other schemes as well, including hard-sectored formats. His imaged disks have been around for decades, and he provides tools for import and export, and there's some documentation too. And, most of the disks imaged were via very available 20th century PC hardware and MS-DOS, so that avoids some of the "I don't have that hardware" issue.

A counter example (my apologies) is the Catweasel series of ISA and PCI controllers. They  make binary sampled images of diskettes of various sorts. While it has been somewhat successful and has been around, there's multiple sets of utilities by various individuals, to convert the bit-sampled disk images into actual, useful files outside the Catweasel universe. It was unique for its time, and solved problems with very odd formats (M2FM encoding, look it up), but suffered (in my opinion) from the limitations I'm trying very hard to describe in this post. But it's an example of my point 3), because the developers of the Catweasel hardware did not write most of these in-use tools.

So I suggest Dunfield's "product" has been very successful, and the Catweasel of limited success, in the very same problem domain as discussed - imaging old disks. Why not learn lessons from these? Why not plan for use outside of owners of this hardware - and when it's no longer available? These are not comfortable responses, I know that.

Here's why I bring up these uncomfortable subjects.  In my support of vintage microcomputing over the years, I have some documents and notes about magnetic media (mostly floppies) on my Web site. So  I'm contacted by any number of vintage computer owners, who are desperately looking for software in "native" physical formats, or trying to read software in those formats. They  don't have the hardware, or they do and it doesn't work, and it's not well documented, and there's physical problems beyond fixing it with capacitors and some TTL IC's. Available solutions to their problems, just don't work, because they were custom to some other system. And, most of them no longer exist.

That's why I have this "high level" view and why I'm making these suggestions early on.

Herb Johnson
retrotechnology.com

[Norberto Collado]

Hello Herb,

My approach is to try to design something simple that acts like a floppy media (raw data) and nothing else. As I have the hardware in place I can do proof of concept to evaluate if the current hardware can deliver or not. Anything beyond that is out of my scope at this time. It takes time, energy, and funding to at least be able to provide a solution for the H8/H89 owners. 

Hopefully someone in this group can develop an alternative that can meet your expectations.

Thanks,

Norberto

-------- Original Message --------
Subject: Re: [sebhc] Re: Floppy emulator

--
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/63c1e7b6-1a4a-4187-aad1-9aa85b2c3916%40googlegroups.com.

[Lee Hart]

Norberto Collado wrote:
> My approach is to try to design something simple that acts like a floppy
> media (raw data) and nothing else. As I have the hardware in place I can
> do proof of concept to evaluate if the current hardware can deliver or
> not. Anything beyond that is out of my scope at this time. It takes
> time, energy, and funding to at least be able to provide a solution for
> the H8/H89 owners.

That is my feeling as well. Just build something that replaces a
mechanical disk drive and floppy disk with a flash drive or SD-card. It
doesn't have to interpret the data; it only has to record and play back
the same bitstream. This should work with *any* computer that works with
a real disk drive. It eliminates the reliability headaches of trying to
get rusty old disk drives and moldy floppy disks to work.

Once the raw data is on the flash drive, it can also be read on a PC.
The PC won't understand the data; but that's not vital. As long as the
image on the flash drive looks like a file, the PC can copy, ZIP, store,
and email it to others who need that "disk" for the same computer.

This isn't intended to replace all the disk imaging systems and software
that *do* understand the data format of the target system's floppy
disks, or that can actually read/write the real floppy disks of old
computers on a PC.

[Bill Sudbrink]

Have you looked at the Raspberry Pi Zero?  Five dollars US.  Looks like just the thing to build a virtual universal floppy on.

 

From: se...@googlegroups.com [mailto:se...@googlegroups.com] On Behalf Of Norberto Collado
Sent: Monday, November 30, 2015 9:16 PM
To: se...@googlegroups.com
Subject: RE: [sebhc] Re: Floppy emulator

 

Hello Herb,

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7227 / Virus Database: 4457/10948 - Release Date: 11/04/15
Internal Virus Database is out of date.

--

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/20151130191556.1321cca37f09b4ab87c5049afdc8ceaa.e8901a4d17.wbe%40email09.secureserver.net.

[John Toscano]

I can see situations where it *WOULD* be helpful if the pc could  understand the data, in the event that the disks contained text files, programming source code, etc. Although I liquidated all of my H-89 hardware when I sold my MN home and bought a home in TX, I kept some of the floppy diskettes thinking I might someday want something from them. But I am probably an outlier in that regard...

--
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/565DDFD7.2080300%40earthlink.net.

[Glenn Roberts]

The pi zero is amazing.  I love the things this group has done to marry old and new.  Like the Z67 IDE+ with my H8.  But think about marrying an H8/89 with a pi zero (or two!).  these are essentially unix workstations on a chip.  the mind boggles!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/565de5e2.4884810a.bc7ab.1710SMTPIN_ADDED_BROKEN%40gmr-mx.google.com.

[Mark Garlanger]

Hey John,

  If you ever need anything transferred, just let me know. I have the DeviceSide FC5025 all setup to image hard-sectored disks.  You can drive up here, and we can get them imaged in no time.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAD9POuZY-LK9LGb6t3i9unpGw3qrdxKs%2Bi%3D4eKuBd7DfV%2B_Szg%40mail.gmail.com.

[Steven Hirsch]

On 12/01/2015 07:01 PM, Glenn Roberts wrote:

> The pi zero is amazing. I love the things this group has done to marry old
> and new. Like the Z67 IDE+ with my H8. But think about marrying an H8/89
> with a pi zero (or two!). these are essentially unix workstations on a
> chip. the mind boggles!

Unless the Pi Zero has auxiliary processors on board, I suspect that such an
environment could not handle the hard real-time aspects of disk read or
emulation. The devices I've seen that perform this type of function rely on
assembly code running on the metal.

David Gesswein's MFM hard disk emulator is actually something to look at
before launching into the design. He uses a Beaglebone Black running Linux to
provide the overall smarts, user interface and storage management. All code
dealing with transition analysis and generation runs on a pair of integrated
programmable real-time units. PRUs are essentially little RISC processors
that provide precise timing guarantees. At a nominal 200Mhz clock (1 tick per
instruction) they are fast enough to handle hard disk MFM data rates (~5MB /
sec), so no problem doing floppy emulation.

Since the MFM emulator already has the necessary tools to convert between raw
transition files, emulation files and data images this might be worth a look
before reinventing any wheels.

Just my $0.02.

[Mark Garlanger]

Hey Herb,

  I didn't see any information about hard-sectored disks in Dave's IMD format, is there something different that covers it? I couldn't find anything on his site about it. Can you point me to where he's covered it?

Thanks,

 Mark

[Lee Hart]

Glenn Roberts wrote:
> The pi zero is amazing. I love the things this group has done to marry
> old and new. Like the Z67 IDE+ with my H8. But think about marrying an
> H8/89 with a pi zero (or two!). these are essentially unix workstations
> on a chip. the mind boggles!

The RaspPi Zero is a really cute little computer. But what features does
it have that suit it to this sort of real-time problem? Is it the right
"hammer" for this "nail"?

I don't even know what I'd do with the regular Raspberry Pi. It runs
linux... but I don't use linux. You program it it C... but I don't know
C. I know half a dozen people with Pi's, and all of them admit they
don't use it for anything. It was just an interesting toy to play with.

[Norberto Collado]

Lee,

The Z67-IDE was based on a software SASI controller. I had to use certain instructions set to maintain the proper timing to boot at 2/4 MHz. Any code change require re-tuning to ensure proper timing and that was a lot of effort to support. That is why I moved to the Z67-IDE+ to have the hardware do the job and forget about the software timing issue and the re-tuning involved. 

On the floppy emulator, I will like to rely on the hardware to create the proper floppy timing and not on the software again. Reviewing the data specs of the WD279x floppy controller, I should be able to use the circuit that deals with the write/read data for proper timing (use the WD279x backwards). What do you think and any recommendations?

Norberto

[Lee Hart]

Norberto Collado wrote:
> On the floppy emulator, I will like to rely on the hardware to create
> the proper floppy timing and not on the software again. Reviewing the
> data specs of the WD279x floppy controller, I should be able to use the
> circuit that deals with the write/read data for proper timing (use the
> WD279x backwards). What do you think and any recommendations?

That's an interesting idea! If I understand it, you would use a pair of
FDC chips that talk to each other. The H89's WD1797 FDC would talk to
your WD279x FDC, instead of to a physical disk drive.

It seems like it would work for standard disk formats. For that case,
you can re-use most of the software already written on the CP/M or HDOS
side to talk to the controller chip. In fact, you might be able to test
this idea by connecting *two* H89's by their 34-pin disk cables. You'd
ahve to cross the read and write data and control lines, sort of like a
null-modem cable. But it should allow you to develop software on the 2nd
H89 to make it imitate a physical disk drive.

The main drawback to this technique is that you'd be limited to disk
formats that the FDC chip can handle. That means no hard-sector, for
example.

I was thinking more along the lines of a *universal* floppy disk drive
emulator. It would know *nothing* about the data format; and so could be
used to replace a drive in anything; H89 hard-sector, Northstar, Apple
II... formats that no normal soft-sector PC-based device can handle.

You're right that software timing loops can be tricky. But your device
would have a fixed clock speed, so you should only have to write that
code once. The sort of thing I imagine is a simple, fast micro that's
easy to write software timing loops (PIC, etc.) People are bit-banging
video with these things! Floppy disk data rates are an order of
magnitude slower, and timing is not as critical as video. That should
make the coding easier.

Thinking out loud... To "write to disk", the H89 is going to send a
sector's worth of data. The code would need to read the serial bit
stream. The software would loop, looking for transitions on the Write
Data line:

- If no transition,
increment counter.
- If a transition,
write counter value to flash drive buffer
reset counter

This would produce a series of numbers representing the times between
each transition on the serial bit-stream to be written to a "disk".
There would be a sector's worth of data, or roughly 10k bytes for a 1k
disk sector.

The actual write to the flash drive would be done at the end of the
sector write. There's lots of idle time while the H89 is waiting for the
"disk" to revolve for the next sector.

Most of the time numbers will be small. Let's say they are in
microseconds, and range from 1-100. Then numbers over 100 could encode
status information, like sector holes, track, etc.

Reading a "disk" (playing this back) is very straightforward. The micro
would watch the control lines coming from the H89's disk controller to
see what track/sector is being requested. It reads that sector's
bitstream from the flash drive. Then it generates transitions on the
Read Data line according to the timings given by each byte. Large
numbers corresponding to control lines will generate the appropriate
signals, for the index hole, etc.

Anyway, I hope this is enough so you can see where I'm going.
--
Humanity is acquiring all the right technology for all the wrong
reasons. -- R. Buckminster Fuller

[Norberto Collado]

I still like your proposal. From your feedback I can put together a flowchart to provide some direction for the "Universal" floppy controller before I start any coding to ensure that I move forward without any issues. 

Thanks,

Norberto

-------- Original Message --------
Subject: Re: [sebhc] Re: Floppy emulator

--
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/565F51E3.8050206%40earthlink.net.

[Gregg Chandler]

The task, though not difficult, is somewhat more difficult than described
below. In a hard sectored system such as the H17, there are no sector
numbers or track numbers in "control lines" from the disk controller to the
disk drive. My memory is that there really aren't any in the soft sectored
system either. I don't recall any such control lines for 8" floppies for
that matter.

First, one would need to simulate stepping in/out to keep track of a track.
This would require monitoring of control line(s). Second, to read data, one
would need to stream all of the track data and sector hole data so that the
H17 firmware/software could wait for the sector that it wants. On the
writing of data, one would need to use the emulated track, count sector
holes, look for data at the right time, etc. Clearly not difficult, but not
as trivial as this post implies.

In the H47 one could watch the protocol looking for logical sector numbers,
but then one would need to emulate the entire Remex disk protocol as used by
the drivers. That would be a totally different beast, with totally
different algorithms. One could emulate a dumb 8" drive, but one of the H47
drives had an integrated microprocessor to execute the protocol.

As all of this has been done before, it is all clearly possible. However,
the quest for a "universal" tool may be a bit mis-guided. Saving the
logical blocks of data rather than bit transitions really addresses the
lion's share, if not more, of an emulator's needs. I don't really recall
any copy protection schemes in the H17 days that would require something
more complicated. (The IBM PC was a different story.) One could generate
the bit stream of H17 data from the blocks of data if it was really
necessary.

[Herbert Johnson]

 Mark Garlanger wrote:

Hey Herb,

  I didn't see any information about hard-sectored disks in Dave's IMD format, is there something different that covers it? I couldn't find anything on his site about it. Can you point me to where he's covered it?

 http://www.classiccmp.org/dunfield/img/index.htm

has a number of "transfer utilities". One set deals with Northstar Horizons, which are hard-sectored. As I said, Dunfield's tool set uses an IBM-PC and MS-DOS tools and connected floppy drives. For computers without soft-sectored controllers, he has utilities for serial transfer of disk images to and from the native computer (like the Northstar). The native computer recreates or reads the disks, and transfers serially to the MS-DOS host.

Otherwise, I think my point in talking about Dunfield was missed.

I brought him up, because his toolset provides means to access the images his tools create. Why? To support emulators, to support people who just want the files, unimaged,  and not to recreate physical disks. And, to add support for imagedisk images, to other disk-image-related software, or to support additional computers. All of that has occurred, I'm not making this up. 

And I'm not sure if I have to explain again the following notion. Any user or group of users who use "the widget", will eventually end up with archives of those images. Now, what if someone else later, doesn't have "the widget", but wants to run the supported system with "real" disks or something else? Or they had the widget (or old computer) but now don't, and they just want to recover old files?

My point - again - was that if there's not much supporting documentation, or supporting software, for making sense of those images; then they will be hard to use at a future time or place. If that is a lot of work for the designer  to consider (as was said), then at least leave a trail, and maybe make simpler or more transparent design choices - for someone else to deconstruct the images. That kind of reverse engineering, happens all the time in vintage computing. I cover that on my Web site, people have made now-unique digital recordings, and have been in these circumstances.

Why am I saying this now? It's easier to make these considerations before a design is started, than to figure it out or debate it after the design is done. My apologies for repeating myself, but this is a subject familiar to me, I hope my remarks have some merit. Thank you.

herb johnson
retrotechnology.com

[Norberto Collado]

Herb,

I highly value your feedback and leadership in keeping the vintage computer alive. I really enjoyed reading all the material you had accumulated on your website and I used it as a reference when working on new ideas, and lately on the following link: http://www.retrotechnology.com/herbs_stuff/s_drives_howto.html. Thank you for leading this effort.

I fully agree with your assessment.  If someone wants to boot a floppy media using the real drives, there should be a path to enable them to be able to download thru the serial port (common device in any PC) into the floppy drive to get into the OS (we do have the means to do this with the H8/H89 systems.) I did go thru this path when I unpacked my H8 after 20 years of storage and it was a very rocky, frustrating, and painful adventure. Then once I had my CP/M or HDOS working with the help of this team, the second challenge was on how to download files that I had in my PC into the H8 floppy drives. That is when Ken provided the Communications Applications to be able to accomplished this task, but how to get the communication application into the H8 floppy media was another challenge. That triggered the idea to have a USB solution for both systems, which I supported, to be able to exchange files between the PC and the H8/H89 system. The next challenge was to get my old 10MB hard drive working but if was not feasible. I bought two hard drives from EBay and they lasted about 6 months before they die. This issue motivated me to develop the Z67-IDE &+ hard drive controller to be able to do the same I did back in 1994 with the MFM 10MB hard drive. Then my floppies drives started to fail as well. I did spend a lot of money buying floppy drives (5.25") to see them failed after normal use due to aging. Buying new 5.25" hard sectored floppy media was very expensive as well. Replacing the floppies with the 3.5" drives help me in having a more reliable system. The next issue was with HDOS and the 3.5" media with the Hard sector controller. That is when Chris provided the HSFE controller to enable the 3.5" floppy drives with the H17 controller. 

As described above relying on old hard drives and old floppy drives is not reliable anymore and there was a need to develop new boards using the new technologies available to ensure an stable hardware operation. My two H8's are working reliable after the new changes and I enjoyed using them. Having an unstable system is not a good experience and that is why I try to help this team in enabling their hardware to avoid such frustration and sleepless nights.

Les and I posted the Gerber files into our respective web servers of all the boards that we designed along with basic documentation for anyone to build their own boards if needed. So getting the hardware replicated is not an issue.

I do have images in the koyado.com web-server that Ken provided to enable both Compact Flash in booting HDOS and CPM. It is up to someone to create a utility to read/write from/to them in the PC or emulator because it is out of my scope. How to extract such images? As you mentioned, the user will need to have such controllers and upload thru the serial port using the communications application provide within the image or use the H8/H89 USB solution and then read into the PC. Or someone to write a PC application to do so to recover files.

The team invested a lot of time in enabling HDOS with the Z67-IDE+ solution. After acquiring a QuikData hard drive for about $65.00, it came with the QuikData HDOS OS. I immediately saved all the hard drive information into our USB solution to preserved such valuable work that done back them. Now this team is enjoying this new addition because of the USB solution.

The only thing that I have in my H8/H89 that is not solid state are the mechanical 5.25" and the 3.5" floppy drives. I will love to transform the Z67-IDE+ controller to react as a floppy drive, so that I can have a solid state solution that is more reliable that can boot HDOS or CP/M from the H17 and/or H37 controllers, and to be able to transfer files between them and the solid state hard drive solution. I'm brainstorming/scoping this idea as I have the Z67-IDE+ and the SVD controller on the bench and there is no need to buy any hardware to work on this idea; just the time to read the H17/H37 floppy communication specs and to attempt to write the proper code to do the same. This is how I visualized such idea as the H17 supports three drives and the H37 supports four drives. So the new solid state controller can support 7 drives as needed. I will eventually need guidance from this team in enabling such idea as it matures. 

Concept:

H17 Controller ------------>H17/H37-IDE-Floppy Controller ->2x CF cards (one for the H17 controller and the second one for the H37 controller).

                                   ^

H37 controller -------------|

 

Do you have an H89 system with the H89-Z37 controller? I'm asking as I have the means to enable your system to benefit from the Z67-IDE+ controller experience and we can work offline to enable your system.

Thanks for all your support and direction and I will be asking for your valuable feedback once I take on this project idea.

Best Regards,

Norberto

-------- Original Message --------
Subject: Re: [sebhc] Re: Floppy emulator

--
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/2e2e24e5-c008-43b0-b683-1b343a0fdd52%40googlegroups.com.

[Norberto Collado]

Chris,

I have been reviewing/studying the timing for the the Hard-Sectored format and came across the same concept as your HSFE for the Heathkit and other computers. It uses a 9V battery to do the job. Schematics and source code are provided at the website.

Link: http://deramp.com/vsg.htm

It is called "Virtual Sector Generator for 5.25" Hard-Sectored Controller for the  North Star, Heathkit, Micropolis, Vector Graphic, and MITS/Altair systems.

If I take on the Solid State Floppy Emulator for the H8/H89, it makes sense to use the HSFE as we do today and just focus in creating a 1.44Mb floppy solid state drive with the CF cards to support both controllers (H17/H37) at the same time.

Norberto

[Chris Elmquist]

yes... I corresponded with Mike while he was putting that together. It is a derivative of his FDC+ board which is an S-100 floppy interface for the Altair. He has invested considerable effort in a more complex timing algorithm for synthesizing the sector pulses that should work better with 5.25" belt driven drives which the HSFE was not intended to support.

I would probably dispute that the 9V battery does the job... but it most certainly is a participant :-)

The role that the HSFE plays is very minor and nowhere near the greatest challenge in building a solid-state floppy emulation so I would think that once those other hurdles are crossed, supporting hard sector should be easy to put into your main processor.

On the other hand, I am always a fan of simplifying the software if you can do so by distributing to additional low cost processors. Perhaps I've been tainted by a life in supercomputing where one system has 10's of thousands of processors :-)

IMO, your greatest problem is going to be how to support writing to this emulated floppy. A real floppy can be in read mode (ie, the write gate is false) for any portion of a track at which point suddenly the write gate goes active for one sector, new data over-writes that sector and then it returns to reading the next sector.

You now need to commit that data to the backing store and be ready to serve it out before that sector comes around again in your simulated rotation.

Most of the emulators already done are recording the transitions on the floppy data line at 8 or 10 times the actual transition rate so that they can very accurately reproduce the edges and their timing relationships. So, something on the order of 2 Mbps for a 250 KHz MFM floppy. Suddenly you are looking at committing a lot more data for every sector to your backing store, which is some kind of flash, and has a non-zero time to write that data. These rates and write times are what add up to a difficult problem in order to maintain a fully functional equivalent to a floppy or hard drive. It is the reason that something like a Beaglebone with dedicated 200 MIPS RISC i/o processor (aka, PRU) gets involved.

You can't just "record" to something like an SD card or CF card because these devices have no such streaming capability. They are sectorized access with some protocol and command overhead to address and access each sector. You then have to block and deblock the data stream you get one bit at a time to and from the floppy controller, putting the over-sampled bit stream to this array of sectors in the backing store all fast enough to not miss a beat as far as the host controller is concerned.

Definitely not an impossible mission but it is not easy and why there are not a lot of choices to solve this problem universally and cheaply I am afraid.

cje

Chris Elmquist

[Lee Hart]

Chris Elmquist wrote:
> The role that the HSFE plays is very minor and nowhere near the greatest
> challenge in building a solid-state floppy emulation so I would think
> that once those other hurdles are crossed, supporting hard sector should
> be easy to put into your main processor.

I agree; simulating the 10 hard-sector holes should be fairly simple. I
recall a purely hardware version of the HSFE. It let the Heath
hard-sector controller read and write to 1-hole soft-sector disks. The
hardware was a phase-locked loop IC that read the sector hole,
multiplied it by 10 to create 10 more pulses, and added them into the
sector signal bit-stream that the controller saw.

Conversely, CDR has a circuit on their soft-sector board that *removes*
the 10 sector hole pulses from a hard-sector disk. So their controller
can read/write soft-sector format to a physically hard-sector disk. This
was advertised as a way to re-use your old hard-sector floppies. (Now
*there's* a disk that was truly unreadable on any other machine!)

> IMO, your greatest problem is going to be how to support writing to this
> emulated floppy.

Yes, it does sound like the most challenging part. The closer I look,
the more "gotchas" there could be.

The destination media (SD-card, USB thumb drive, etc.) takes time to
write. Since the FDC could switch to write at any instant, the data
being written has to go into a buffer in RAM. The RAM buffer then needs
to be written to the physical media later, when there's time.

> Most of the emulators already done are recording the transitions on the
> floppy data line at 8 or 10 times the actual transition rate so that
> they can very accurately reproduce the edges and their timing
> relationships. So, something on the order of 2 Mbps for a 250 KHz MFM
> floppy. Suddenly you are looking at committing a lot more data for every
> sector to your backing store

Indeed, that's why I was thinking you could measure the time between
each transition, and storing that as a single byte. Modern micros can
run fast enough to poll a bit at 2 MHz. Or, a hardware timer could be
used (on-chip or external).

> It is the reason that something like a Beaglebone with dedicated
> 200 MIPS RISC i/o processor (aka, PRU) gets involved.

It certainly has the raw horsepower! But I'm clueless on how you would
program one to do any kind of real-time job like this. But I can see how
to program a simpler CPU in assembler to do it.

> You can't just "record" to something like an SD card or CF card because
> these devices have no such streaming capability. They are sectorized
> access with some protocol and command overhead to address and access
> each sector. You then have to block and deblock the data stream you get
> one bit at a time to and from the floppy controller, putting the
> over-sampled bit stream to this array of sectors in the backing store
> all fast enough to not miss a beat as far as the host controller is
> concerned.

This also suggests some kind of compression, so the time for each
transition is encoded.

> Definitely not an impossible mission but it is not easy and why there
> are not a lot of choices to solve this problem universally and cheaply I
> am afraid.

Indeed, it's a problem that looks simple from a distance, and get
progressively more complicated the closer you look. It's like looking at
a mountain from a distance. It's easy to say "there it is"! But when you
get close and are climbing it, the mountain is lost in the complexity of
the local landscape.

[Steven Hirsch]

On 12/05/2015 02:04 PM, Lee Hart wrote:

> Conversely, CDR has a circuit on their soft-sector board that *removes* the 10
> sector hole pulses from a hard-sector disk. So their controller can read/write
> soft-sector format to a physically hard-sector disk. This was advertised as a
> way to re-use your old hard-sector floppies. (Now *there's* a disk that was
> truly unreadable on any other machine!)

Not completely true. I repurposed a bunch of hard-sector floppies for use
with an Apple 2 since their disk controller pays no attention to index pulses.
I believe the C64 is similar in this respect.

>> It is the reason that something like a Beaglebone with dedicated
>> 200 MIPS RISC i/o processor (aka, PRU) gets involved.

> It certainly has the raw horsepower! But I'm clueless on how you would program
> one to do any kind of real-time job like this. But I can see how to program a
> simpler CPU in assembler to do it.

There is plenty of documentation and example code for leveraging the PRUs. The
instruction set is very regular and relatively easy to grasp. One could also
build on David Gesswein's work, which is freely available and under an open
source license - as is the hardware. David has solved a lot of the
fundamental issues that are either obscure or undocumented (e.g. changing PRU
clock rate, using DMA for transfer between PRU memory and CPU memory, etc.)

It sounds like Norberto is off and running with a new hardware design, which I
applaud and look forward to. But, if it were me I'd start with David's work
and transform it to cover floppy formats.

Emulating a disk drive is simple, except for all the practical details that
have been alluded to. It's not quite as simple as "..just record the flux
changes and play them back". The MFM emulator has been under intense
development for almost two years and new "gotchas" are still being encountered
on a regular basis. The emulation logic must be able to handle a large number
of orderings and combinations of control line and data line changes. There
are all sorts of shortcuts and assumptions made by disk controller software
that "just work" with the real hardware while presenting real hair-puller
problems for software emulation. My TechTools logic analyzer has had quite a
workout trying to get a handle on some.

Not trying to be a naysayer, but it's a lot of work to get this right.

[Norberto Collado]

Yeap! I realized after reading more into,  that I will need to stream the data using 512KBx8 RAM IC’s. For a single 1.44MB floppy I will need three and to support two floppy devices, six will be needed for a price around $120.00. I will not longer pursue this idea and will maybe buy from Ebay:

http://www.ebay.com/itm/Neueste-Version-HxC-SD-Floppy-Emulator-Rev-F-mit-Gehause-schwarz-/381477619532?hash=item58d1d6874c:g:nFMAAOSwT5tWMIQK

I love the idea of distributing the work/software across some cheap microcontrollers, so that data flows seamless between the hardware and the controller, rather than putting everything into a single microcontroller.

Thanks for the feedback,
Norberto

-------- Original Message --------
Subject: RE: [sebhc] Re: Floppy emulator
From: Chris Elmquist <chr...@pobox.com>
Date: Fri, December 04, 2015 8:50 pm
To: se...@googlegroups.com,Norberto Collado
<norberto...@koyado.com>

yes... I corresponded with Mike while he was putting that together. It is a derivative of his FDC+ board which is an S-100 floppy interface for the Altair. He has invested considerable effort in a more complex timing algorithm for synthesizing the sector pulses that should work better with 5.25" belt driven drives which the HSFE was not intended to support.

I would probably dispute that the 9V battery does the job... but it most certainly is a participant :-)

The role that the HSFE plays is very minor and nowhere near the greatest challenge in building a solid-state floppy emulation so I would think that once those other hurdles are crossed, supporting hard sector should be easy to put into your main processor.

On the other hand, I am always a fan of simplifying the software if you can do so by distributing to additional low cost processors. Perhaps I've been tainted by a life in supercomputing where one system has 10's of thousands of processors :-)

IMO, your greatest problem is going to be how to support writing to this emulated floppy. A real floppy can be in read mode (ie, the write gate is false) for any portion of a track at which point suddenly the write gate goes active for one sector, new data over-writes that sector and then it returns to reading the next sector.

You now need to commit that data to the backing store and be ready to serve it out before that sector comes around again in your simulated rotation.

Most of the emulators already done are recording the transitions on the floppy data line at 8 or 10 times the actual transition rate so that they can very accurately reproduce the edges and their timing relationships. So, something on the order of 2 Mbps for a 250 KHz MFM floppy. Suddenly you are looking at committing a lot more data for every sector to your backing store, which is some kind of flash, and has a non-zero time to write that data. These rates and write times are what add up to a difficult problem in order to maintain a fully functional equivalent to a floppy or hard drive. It is the reason that something like a Beaglebone with dedicated 200 MIPS RISC i/o processor (aka, PRU) gets involved.

You can't just "record" to something like an SD card or CF card because these devices have no such streaming capability. They are sectorized access with some protocol and command overhead to address and access each sector. You then have to block and deblock the data stream you get one bit at a time to and from the floppy controller, putting the over-sampled bit stream to this array of sectors in the backing store all fast enough to not miss a beat as far as the host controller is concerned.

Definitely not an impossible mission but it is not easy and why there are not a lot of choices to solve this problem universally and cheaply I am afraid.

cje

On December 4, 2015 9:50:36 PM CST, Norberto Collado <norberto...@koyado.com> wrote:

Chris,

I have been reviewing/studying the timing for the the Hard-Sectored format and came across the same concept as your HSFE for the Heathkit and other computers. It uses a 9V battery to do the job. Schematics and source code are provided at the website.

Link: http://deramp.com/vsg.htm

It is called "Virtual Sector Generator for 5.25" Hard-Sectored Controller for the  North Star, Heathkit, Micropolis, Vector Graphic, and MITS/Altair systems.

If I take on the Solid State Floppy Emulator for the H8/H89, it makes sense to use the HSFE as we do today and just focus in creating a 1.44Mb floppy solid state drive with the CF cards to support both controllers (H17/H37) at the same time.

Norberto

Chris Elmquist

--
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/F6974D88-8F9E-40D2-80AD-E3404510A220%40pobox.com.

[Steven Hirsch]

On 12/05/2015 03:19 PM, Norberto Collado wrote:
> Yeap! I realized after reading more into, that I will need to stream the data
> using 512KBx8 RAM IC’s. For a single 1.44MB floppy I will need three and to
> support two floppy devices, six will be needed for a price around $120.00. I
> will not longer pursue this idea and will maybe buy from Ebay:
>

> _http://www.ebay.com/itm/Neueste-Version-HxC-SD-Floppy-Emulator-Rev-F-mit-Gehause-schwarz-/381477619532?hash=item58d1d6874c:g:nFMAAOSwT5tWMIQK

If you want to work with HxC, I would suggest picking up one of the Gotek
emulators ($18 on eBay if you have a month to wait for delivery from China, or
$39 from Amazon and get it in a week). The HxC firmware for it is available
for 10 Euros.

FWIW, ALL the folks selling the cheap Gotek units on eBay are either in China
or lying about being here. Just had a run-in with "Mayunstore" who listed the
item as being in Chino, CA with a delivery by Dec. 1 (ordered 11/23). Turns
out to be shipped from China using "Economy" class, which in my experience
means 30-45 days - if it ever arrives at all.

The schematic for the Gotek unit is readily available and it's possible to
write your own code using the STM tools.

[John Toscano]

I've done some programming on STM32F4xx processors. Is their source code available to use as a starting point?

--
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/56635A94.5050107%40gmail.com.

[Chris Elmquist]

Ya. I didn't want to be a naysayer either but I've also noodled over this
problem for almost 10 yrs now. My conclusion, at least for machines like
Heath and others where we have access to the operating system source and
can develop device drivers for new interfaces, is to build new, efficient
interfaces to modern media and write the device drivers to support them.

This is why I was advocating (and indeed built a prototype) for a USB
interface to the H89 so that an emulation of a disk could be done across
that channel to a modern computer where the disk image actually lives.

I've also advocated a brain dead simple ethernet interface for these
systems (with no TCP stack, no protocol ability other than to send raw
packets) that can also be used as a "fat pipe" to a modern host computer
to serve disk images. This is how a SAN (storage area network) works.

For systems where you cannot write new device drivers and are locked
into only a legacy disk interface (floppy or HD) then you have to
pursue these emulations at the disk interface level. But for systems
like Heath H8 and H89, we have the luxury of being able to implement a
modern and efficient new storage subsystem because everything we need
(hardware and software) is totally revealed.

cje

> --
> 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/56635A94.5050107%40gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--
Chris Elmquist

[Steven Hirsch]

On 12/05/2015 06:13 PM, John Toscano wrote:
> I've done some programming on STM32F4xx processors. Is their source code
> available to use as a starting point?

Not that I'm aware of. I doubt that the HxC developer will open this up
(although might be willing to work with folks privately if approached). There
is at least one other party who wrote an Amiga image handler as free-ware and
might be a better bet for collaboration.

I asked Jean-François del Nero (HxC author) about hard-sector support and he
said he had no system to test on. I offered to help and received no reply.
Still might be worth a polite offer if you have background in the STM.

[Norberto Collado]

If Gregg Chandler is available, then we may be able to enable the H8/H89 Ethernet Interface idea again with the W5300 interface which I still have available. I'm very interested in being able to connect to an iSCSI server of the network if this matures.

Norberto

-------- Original Message --------
Subject: Re: [sebhc] Re: Floppy emulator
From: Chris Elmquist <chr...@pobox.com>

[Herbert Johnson]

 I'm replying to Norbert's response to my (Herbert's) posts.

Norberto, thank you for your considerations of my comments and my feedback, and posting a thoughtful reply. So I'll also respond thoughtfully and in kind,
and that's the end of my discussion, because I'm just repeating myself, and because I have no specific contributions to the hardware design process.
I'll explain the difference between your interests and assumptions, and mine; and follow that with specific requests. OK? That takes some effort and lots of
words. If that's too much or too repetative, then "goto" the paragraph starting at "Here's the bottom line..." for what I request. Thank you.

----------------------------------

My interests are not about replacing floppy drives and media with modern hardware. It's not about how that is done, or why magnetic media and drives
should be replaced. I don't argue about the need. I have nothing to contribute to that design process, you have more than adequate talent and resources
in hand.

My contribution was as you noted - to document and reference how magnetic media *was* designed and operated. Thanks for your appreciation.

And it's not about my particular uses of Heath hardware; I appreciate offers to help me with my own systems. I'm just another potential user in that regard
at best, one of many, no better than any.

Here's my THIRD re-statement of my interests. "How does someone access the accumulated archive of Heath/Zenith software, which this proposed device will
produce, as encoded files on modern media, modern computers, modern Web sites; if - and please pay attention to this "if" condition - if they don't have the hardware previously used to generate the images, or even "run" the original files and run your device?" Thanks for your replies which have helped me refine the question.

I've said why I have that interest, I've said why I've stated it now and not some other time.

Norberto, you acknowledged this issue, when you described the "painful adventure" of restoring H8 software to your unpacked H8 system. Thank you. You posed *your view* of the problem, quoting you: "If someone wants to boot a floppy media using the real drives, there should be a path to enable them to be
able to download thru the serial port (common device in any PC) into the floppy drive to get into the OS."

I would put my concerns in this way, parallel to yours: "If someone wants to make use of specific files, from the images your device will create, there should be
a path to enable them to be able to extract them through software (common programs in any PC) into their PC environment, to get the files into their use." I am trying to follow your same logic, but to a different place, under different assumptions.

Your reply responds to my concerns as follows:  "It is up to someone [else] to create a utility to read/write from/to them in the PC or emulator because it is out of my scope. How to extract such images? As you mentioned, the user will need to have such controllers and upload thru the serial port using the communications application provide within the image or use the H8/H89 USB solution and then read into the PC. Or someone to write a PC application to do so to recover files."

I disagree with that description, as to how someone might wish to access "the image". Your view and your reply makes assumptions; I disagree with those
assumptions, note my statement above starting with "Here's my THIRD re-statement of my interests." I am surprised I have to explain alternative circumstances in detail, here they are:

First - suppose an H89 user of your device, archives all their old H89 physical disks, and runs their H89 for some time with your device. Time passes. They stop using the H89, your device dies, the H89 is scrapped. Now - oops! They need to extract a file about something they wrote. Some bit of software they liked to use. Some game. So what do they do, 15 years from now, with a PC backup of the images they used? Or suppose it's an estate, and some relative  wants or needs that file? (I've had requests to convert disks, I've processed 8-inch disks 35 years old from an estate, etc.) 

Are they going to rebuild your device from Gerber files and PC board houses, and find IC's from 15 years ago, and obtain an H89, and make that all work? My apologies, but no, no, and no.

Second - there's the emulator interests you mentioned. People wanna run old programs and games from old computers. Emulators let them do that "for free". Most users simply won't spend money and time on archives that aren't readable anymore. Emulators and their developers and users simply are part of vintage computing. I'm approached often by emulator developers: "can you please dump the ROM from (some device I show on my Web site) so we can better
emulate that device in (some popular emulator)?"

Third - there's people interested in various specific programs, or in files or information, that may happen to have also been in use in the H8 or H89 world. Example: an academic studying the history of Spacewar gaming (I've had that inquiry). Someone preserving  various implementations of Ron Cain's "small c" (I've contributed to that archive via OCR and tedious editing from paper documents).

In short, I strongly suggest you cannot dismiss the likely use of your imaged files, in a future time when the encoding/decoding hardware and even the Heath systems are unavailable, unbuildable, and/or not intended for use anyway.

Here's the bottom line, and my last word:

I want to spare someone a decade or two from now, from their  own "painful adventure" of trying to decode some collection of imaged (encoded) software your proposed device will produce. As far as I'm concerned, your solution of rebuilding boards and obtaining chips, even another H8 or H89, just to be able  to extract some files another day, is, with my apologies, another "painful adventure". I'm not trying to be mean, I'm trying to be clear.

And if providing software tools to extract files is "out of your scope", it's IN your scope to 1) document your file format and methods, so someone else can write those tools; 2) consider in your design, if possible, how you might make it easier for someone to decode your imaged files with *software only*.

For instance: since you are encoding bits, and decoding bits, in hardware and with a microcontroller, you can state the algorithm used in that hardware. Do not do something like "here's the TK/TCL program I wrote, to create the bit-mapped table, that decodes the binary data stream". Make choices that clarify and simplify, not "here's a clever use of the shift-left instruction to save five bytes".

I'm sorry, but that challenges the assumption of "it's just a tape recorder, we don't care what the bits look like, as long as what comes in today can go out tomorrow, whatever that bit-data is". And it challenges the assumption that only H8 and H89 current owners will want access to the resulting images.

And I'm not going to be the judge for those choices, to be the "quality control" or "noodge" for what's simpler or clearer. Without discussion, it's simply an unpopular task. If I as a user will trust you engineers to make a useful device, I'll also have to trust you to provide for future means to recover files, even if you can't provide those tools yourself.

I - am - done. Any questions or confusion will have to be resolved from our discussion and maybe any closing comments from others and Norberto. Good luck with your designs, thanks for acknowledging whatever support you've gleaned from my Web site. Thanks for this final opportunity for my particular part in this design discussion.

Herb Johnson
retrotechnology.com

[Norberto Collado]

Thanks Herbert for the feedback! This triggered that I need on the Z67-IDE+ better document in detail on how the HDOS/CP/M sectors are captured within the CF card so that the information can be extracted in the near future from the images. 

Best Regards,

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/eb45039e-a8f8-41d4-8204-fb96abfb088a%40googlegroups.com.

[Gregg Chandler]

I agree with the sentiments expressed here.  To preserve my history, I created an emulator that runs on Windows.  I virtualized device access much as VMware does.  I uploaded disk images from my H89 to my emulator.  The emulator boots my images, and can copy the files to/from the virtual drives that are actually Windows folders or uploaded image files.  I haven’t powered up my H89 since uploading the diskette images.  By building the emulator the correct way, the only utilities that I had to write are the upload/download ones.  I never bothered to write the download one.  I chose not to emulate every transistor in an H89.  I chose to let the OS provide all of the conversion functionality.  Oh, and did I mention that I did all of this because I contacted someone in this group trying to get the disk emulator hardware, and they never responded.  As long as Windows lives, my history lives.

retrotechnology.com <http://retrotechnology.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/eb45039e-a8f8-41d4-8204-fb96abfb088a%40googlegroups.com <https://groups.google.com/d/msgid/sebhc/eb45039e-a8f8-41d4-8204-fb96abfb088a%40googlegroups.com?utm_medium=email&amp;utm_source=footer> .