Re: idea for a universal disk interface
Interesting, what kind of ESDI controllers do you have? They got advanced features like cache, ordered seeks, and burst mode/block mode DMA? C On 4/18/2022 6:09 PM, Douglas Taylor via cctech wrote: Because of this I'm holding on to my DEC Qbus ESDI controllers!!! You never know Doug On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote: I chose ESDI and SMD fundamentally because the interface is 100% digital (e.g. the data/clock separator is in the drive itself). So I don't need to do any oversampling. TTFN - Guy On 4/17/22 11:12, Paul Koning via cctalk wrote: On Apr 17, 2022, at 1:28 PM, shad via cctalk wrote: hello, there's much discussion about the right method to transfer data in and out. Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. For reading a disk, an attractive approach is to do a high speed analog capture of the waveforms. That way you don't need a priori knowledge of the encoding, and it also allows you to use sophisticated algorithms (DSP, digital filtering, etc.) to recover marginal media. A number of old tape recovery projects have used this approach. For disk you have to go faster if you use an existing drive, but the numbers are perfectly manageable with modern hardware. If you use this technique, you do generate a whole lot more data than the formatted capacity of the drive; 10x to 100x or so. Throw in another order of magnitude if you step across the surface in small increments to avoid having to identify the track centerline in advance -- again, somewhat like the tape recovery machines that use a 36 track head to read 7 or 9 or 10 track tapes. Fred mentioned how life gets hard if you don't have a drive. I'm wondering how difficult it would be to build a useable "spin table", basically an accurate spindle that will accept the pack to be recovered and that will rotate at a modest speed, with a head positioner that can accurately position a read head along the surface. One head would suffice, RAMAC fashion. For slow rotation you'd want an MR head, and perhaps supplied air to float the head off the surface. Perhaps a scheme like this with slow rotation could allow for recovery much of the data on a platter that suffered a head crash, because you could spin it slowly enough that either the head doesn't touch the scratched areas, or touches it slowly enough that no further damage results. paul
Re: IMSAI SIO2 cable part number
Bill, Let me know right quick if you'll be at VCF East and I'll make you a pair, I have both kinds of IDC ends. I'm heading out first thing tomorrow morning though as I have work in the northeast before VCF East. Thanks, Jonathan --- Original Message --- On Monday, April 18th, 2022 at 15:03, Bill Degnan via cctech wrote: > > > Hi all... > What is the cable partnumber for the IMSAI SIO2? I need to order a > set of cables. I thought in all of my boxes and boxes of cables I > might have one...but nope. > > Here is a picture: > > https://deramp.com/downloads/mfe_archive/010-S100 Computers and > Boards/00-Imsai/10-Imsai S100 Boards/Imsai SIO-2 dual serial IO/SIO with > cables.JPG > > Thanks in advance. > > BIll
Re: idea for a universal disk interface
Which is more generic. ESDI, SMD or SCSI. In my opinion, SCSI is as close are you are going to get to a universal interface. As for reading raw data from a drive. The newer the drive, the higher the bit density and lower the strength of the magnetic fields and hence the lower the flying height. You have to deal with linear (or horizontal) recording, perpendicular recording, Heat assisted magnetic recording, microwave assisted magnetic recording. The latest technologies are approaching 1TB (yes that's TB) per square inch. If you spin the platters too slowly you will not be able to distinguish individual magnetic fluctuations from noise. What do you propose as your maximum data density (in BPI) and what is the minimum speed you will need to accurately decode it. Also once you get into newer drives the sectoring information may be stored in EEPROM or ROM and not on the disk at all, that would make decoding the data even more complicated as you don't know where a given sector starts. In addition to handling any number of encoding techniques (FM, MFM, GCR, RLL, MAMR, HAMR, PMR, etc.) news drives also do bad sector mapping so you would need to be able to handle that as well. Some kind of programmable data separator (possibly and external DSP) might be able to handle the high aerial densities. The GreaseWeazle does this for floppies. That architecture might be a good starting point to ramp up for hard drives. Well, that's my 2 cents. On 4/18/2022 5:09 PM, Douglas Taylor via cctech wrote: Because of this I'm holding on to my DEC Qbus ESDI controllers!!! You never know Doug On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote: I chose ESDI and SMD fundamentally because the interface is 100% digital (e.g. the data/clock separator is in the drive itself). So I don't need to do any oversampling. TTFN - Guy On 4/17/22 11:12, Paul Koning via cctalk wrote: On Apr 17, 2022, at 1:28 PM, shad via cctalk wrote: hello, there's much discussion about the right method to transfer data in and out. Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. For reading a disk, an attractive approach is to do a high speed analog capture of the waveforms. That way you don't need a priori knowledge of the encoding, and it also allows you to use sophisticated algorithms (DSP, digital filtering, etc.) to recover marginal media. A number of old tape recovery projects have used this approach. For disk you have to go faster if you use an existing drive, but the numbers are perfectly manageable with modern hardware. If you use this technique, you do generate a whole lot more data than the formatted capacity of the drive; 10x to 100x or so. Throw in another order of magnitude if you step across the surface in small increments to avoid having to identify the track centerline in advance -- again, somewhat like the tape recovery machines that use a 36 track head to read 7 or 9 or 10 track tapes. Fred mentioned how life gets hard if you don't have a drive. I'm wondering how difficult it would be to build a useable "spin table", basically an accurate spindle that will accept the pack to be recovered and that will rotate at a modest speed, with a head positioner that can accurately position a read head along the surface. One head would suffice, RAMAC fashion. For slow rotation you'd want an MR head, and perhaps supplied air to float the head off the surface. Perhaps a scheme like this with slow rotation could allow for recovery much of the data on a platter that suffered a head crash, because you could spin it slowly enough that either the head doesn't touch the scratched areas, or touches it slowly enough that no further damage results. paul
Re: idea for a universal disk interface
Because of this I'm holding on to my DEC Qbus ESDI controllers!!! You never know Doug On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote: I chose ESDI and SMD fundamentally because the interface is 100% digital (e.g. the data/clock separator is in the drive itself). So I don't need to do any oversampling. TTFN - Guy On 4/17/22 11:12, Paul Koning via cctalk wrote: On Apr 17, 2022, at 1:28 PM, shad via cctalk wrote: hello, there's much discussion about the right method to transfer data in and out. Of course there are several methods, the right one must be carefully chosen after some review of all the disk interfaces that must be supported. The idea of having a copy of the whole disk in RAM is OK, assuming that a maximum size of around 512MB is required, as the RAM is also needed for the OS, and for Zynq maximum is 1GB. For reading a disk, an attractive approach is to do a high speed analog capture of the waveforms. That way you don't need a priori knowledge of the encoding, and it also allows you to use sophisticated algorithms (DSP, digital filtering, etc.) to recover marginal media. A number of old tape recovery projects have used this approach. For disk you have to go faster if you use an existing drive, but the numbers are perfectly manageable with modern hardware. If you use this technique, you do generate a whole lot more data than the formatted capacity of the drive; 10x to 100x or so. Throw in another order of magnitude if you step across the surface in small increments to avoid having to identify the track centerline in advance -- again, somewhat like the tape recovery machines that use a 36 track head to read 7 or 9 or 10 track tapes. Fred mentioned how life gets hard if you don't have a drive. I'm wondering how difficult it would be to build a useable "spin table", basically an accurate spindle that will accept the pack to be recovered and that will rotate at a modest speed, with a head positioner that can accurately position a read head along the surface. One head would suffice, RAMAC fashion. For slow rotation you'd want an MR head, and perhaps supplied air to float the head off the surface. Perhaps a scheme like this with slow rotation could allow for recovery much of the data on a platter that suffered a head crash, because you could spin it slowly enough that either the head doesn't touch the scratched areas, or touches it slowly enough that no further damage results. paul
Felt pads for RX50
Anyone know of a source for the felt pads that go on the non-head side of an RX50? Missing at least one here. C
Re: IMSAI SIO2 cable part number
Standard 100mil (.1 inch center) edge connectors are still very common and available from most electronic parts distributors. For example: https://www.mouser.com/c/connectors/card-edge-connectors/ On 4/18/2022 5:48 PM, Jon Elson via cctalk wrote: On 4/18/22 14:03, Bill Degnan via cctalk wrote: Hi all... What is the cable partnumber for the IMSAI SIO2? I need to order a set of cables. I thought in all of my boxes and boxes of cables I might have one...but nope. Here is a picture: https://deramp.com/downloads/mfe_archive/010-S100%20Computers%20and%20Boards/00-Imsai/10-Imsai%20S100%20Boards/Imsai%20SIO-2%20dual%20serial%20IO/SIO%20with%20cables.JPG You can buy the DB-25 IDC connectors, and most likely you can buy the card edge connectors, too. Jon
Re: IMSAI SIO2 cable part number
On 4/18/22 14:03, Bill Degnan via cctalk wrote: Hi all... What is the cable partnumber for the IMSAI SIO2? I need to order a set of cables. I thought in all of my boxes and boxes of cables I might have one...but nope. Here is a picture: https://deramp.com/downloads/mfe_archive/010-S100%20Computers%20and%20Boards/00-Imsai/10-Imsai%20S100%20Boards/Imsai%20SIO-2%20dual%20serial%20IO/SIO%20with%20cables.JPG You can buy the DB-25 IDC connectors, and most likely you can buy the card edge connectors, too. Jon
Re: Replacement BOT/EOT markers for 1/2" tape
On 4/18/22 11:59, Bjoren Davis via cctalk wrote: Hello Retrofolks, I have a 1/2" 9-track magtape which is missing a BOT marker. Does anyone have a recommendation for a reflective tape to use to replace the BOT marker? I was looking at https://www.amazon.com/Metalized-Polyester-Adhesive-Multiple-Available/dp/B07TXN8TD8, but I have no idea if it's too stiff/thick/not sticky enough/etc. I have some of this material on a roll. It is "Scotch" brand 650 sensing markers "for magnetic computer tape used on digital transports". I could send you some if you are in the US. Jon
IMSAI SIO2 cable part number
Hi all... What is the cable partnumber for the IMSAI SIO2? I need to order a set of cables. I thought in all of my boxes and boxes of cables I might have one...but nope. Here is a picture: https://deramp.com/downloads/mfe_archive/010-S100%20Computers%20and%20Boards/00-Imsai/10-Imsai%20S100%20Boards/Imsai%20SIO-2%20dual%20serial%20IO/SIO%20with%20cables.JPG Thanks in advance. BIll
Re: idea for a universal disk interface
Guy, I agree on keeping Linux out of the loop, to allow fast access on head location, selection. However, I'm not convinced on the fact that a whole cylinder must be on blockram to achieve this. Given that ram access is fast (on Zynq with PL working at 200MHz and HP port at 64bits I'm running at around 1200MB/s peak), logic can jump across the whole disk without the software intervention, it's just a matter of being able to calculate conversion from CHS to address and read with sufficient buffer. Probably using Xilinx IP cores could be a severe limit, as these are really full of bugs and inefficient implementations... but are free, so you can't argue. On software side, given that you can go also slow, there's no need for very complex driver development, just an user level UIO driver could make do. About language, I know very well VHDL, and it's a little bit at higher level than Verilog, so development with implementation parameters is maybe a little easier. About interfaces which doesn't have separated clock recovery: these need a sort of oversampling, but you don't need to store every sample, just the ones with state change. Leveraging on IOSERDES you can work at a multiple of internal clock. Please keep in consideration that the idea is to develop a single device that can work both as drive and as interface, so implementation should be reversible. Probably this is not very difficult to obtain, as fast data paths for read and write are already in opposite directions. Andrea > I have proceeded as far as full block diagrams (still have to write all > of the verilog) and basic SW architecture.? This is why I've had this > discussion.? I've thought about this *a lot* and have gone through > several iterations of what will or will not work given timing constraints. > > I have all of the components for putting a prototype together but I just > haven't had the time yet to write the verilog, the Linux device driver > and the "personality board".? That is, there is still a lot to do.? ;-) > > Some requirements that I've put on my design: > > * straight forward SW architecture > * SW is *not* time critical (that is I didn't want SW in the critical > path of keeping the data stream) > * Must be able to emulate any SMD/ESDI drive > * Must be able to match performance of the drive (or better) > * Must be able to work with any controller (ESDI or SMD...depending > upon interface) > > With those in mind, that's how I came up with my design. > > I found that the Zynq has sufficient Block RAM to contain a full > cylinder of 512KB.? I'm keeping a full cylinder because that allows > everything to be done in verilog except for seeks (see SW not being > required to be in the critical path).? If I didn't do that, then SW > would have to be involved in some aspects of head switch, etc and those > can have tight (<< 100us) latencies and I just didn't want to try and > get Linux to handle that.? Yes, I could use some form of RTOS (I'm > actually in the middle of writing one...but that's still a ways away) > but I don't see any that are really up to what I need/want to do for > this project. > > BTW, I'm basing my initial implementation on the Zynq 7020 which has 1GB > of DRAM.? However, I'm also planning on a "bigger/better" one based upon > the Zynq Ultrascale+ which has 4GB of DRAM so that I can support > multiple/larger drives. > > The amount required by Linux doesn't have to be large...I plan on having > the KMD just allocate a really big buffer (e.g. sufficient for > containing the entire drive image).? Linux will run happily in > 128MB-256MB since there won't be any GUI.? It could be significantly > less if I were to strip out everything that isn't needed by the kernel > and only have a basic shell for booting/debug.? My plan is to have the > emulated drive data and the configuration file on the SD card...so > there's no real user interaction necessary (and Linux would not be on > the SD card but on the embedded flash on the Zynq module). > > > I chose ESDI and SMD fundamentally because the interface is 100% digital > (e.g. the data/clock separator is in the drive itself). So I don't need > to do any oversampling.
Re: Replacement BOT/EOT markers for 1/2" tape
On 4/18/22 09:59, Bjoren Davis via cctalk wrote: > Hello Retrofolks, > > I have a 1/2" 9-track magtape which is missing a BOT marker. > > Does anyone have a recommendation for a reflective tape to use to > replace the BOT marker? > > I was looking at > https://www.amazon.com/Metalized-Polyester-Adhesive-Multiple-Available/dp/B07TXN8TD8, > but I have no idea if it's too stiff/thick/not sticky enough/etc. I still have my card of IBM foil strips, but sensing foil for 1/4" audio tape should also work fine. For example: https://www.ebay.com/itm/202810140272?hash=item2f386d2670:g:y4UAAOSw8fdduA74 Many (but not all) audio sensing tapes are reflective; some are conductive-only. TME claims theirs is reflective. --Chuck
RE: idea for a universal disk interface
Actually I am talking about emulating the bit stream, index to index - RLL encoded and containing gaps, marks, headers, data, CRC, ECC, etc. Exactly as the bit stream would come out of a theoretical disk drive, no bit shift, no write splices, no instantaneous speed variation, no long term speed variation. That means the controller will have a very easy time of it. My point is the ESDI/SME bit stream is 15 Mb/sec or lower and the others are lower still while any modern memory can transfer in the Gb/sec range so the track will arrive at the emulator hardware at much higher rate than the controller can absorb and since the track is coming from memory there is negligible latency. You seem to assume that the transfer out of the emulator can't start until the entire track is in the emulator - that's not what I am saying. To use your example, sure it takes 65us to transfer the entire track out of memory but it takes 16.67 msec to transfer it out of the emulator. I suggest transfer out of the emulator hardware can start with the first word into it. Tom -Original Message- From: Guy Sotomayor [mailto:g...@shiresoft.com] Sent: Saturday, April 16, 2022 5:14 PM To: t.gard...@computer.org; cct...@classiccmp.org Subject: Re: idea for a universal disk interface I think the issue is that you're thinking of somehow emulating the formatted data. I'm working on just emulating the bit-stream as then it'll work with any controller and sector/track layout so I won't actually know what a sector really is (unless I do "hard sectoring" which some drives did support). At a 15Mhz clock rate, 30 bytes is 1.us. Not a lot of time. And frankly, that's defined by the controller and not the drive (though usually the drives specify some layout but that's only a recommendation). Dealing with drive speed variations doesn't solve anything because it's actually done via the drive itself (e.g. the drive provides the clock to the controller so any variation is already accounted for). The drive really cares about total bits (e.g. bits-per-inch) that the media supports. If we assume 32KB track at 500MB/s DMA transfer rate, that takes 65us. But as I've said, the spec says that the time between a head select and read is 15us or so, you can see that you can't just transfer a track and still meet the minimum timings. I will agree that you can probably take longer but I'm trying to have a design that can meet all of the minimum timings so I can emulate any drive/controller combination with at least the same performance as a real drive (and in many cases I can provide *much* higher performance). By keeping a full cylinder in the FPGA Block RAM I can keep the head select time < 1us (it's basically just selecting the high order address bits going to the block RAM). By keeping the entire disk image in DRAM, I can emulate any drive (that fits in the DRAM) with identical (or faster) performance. If I wanted to do something simpler (not much though) I could have a smaller DRAM (but since the Zynq modules I'm using have 1GB or 4GB of DRAM there isn't much motivation) but then any seek would be limited by access to the backing store. Also remember, in the worst case you have to write the previous track out if it was written to so that will slow things down as well. With the full image maintained in DRAM, any writes can be performed in a lazy manner in the background so that won't impact the performance of the emulated drive. TTFN - Guy On 4/16/22 14:32, Tom Gardner wrote: > -Original Message- > From: Guy Sotomayor [mailto:g...@shiresoft.com] > Sent: Friday, April 15, 2022 3:25 PM > To: t.gard...@computer.org; cct...@classiccmp.org > Subject: Re: idea for a universal disk interface > > I'm looking at what the spec says. ;-) The read command delay from the head > set command is 15us (so I was wrong) but still not a lot of time (that is > after a head set, a read command must be at least 15us later). > > > > - > And after the read command is given there is a gap, usually all zeros, at the > end of which is a sync byte which is then followed by the first good data (or > header) byte. In SMD the gaps can be 20 or 30 bytes long so there is quite > a bit of time until good data. > > Tom > > -- TTFN - Guy
Replacement BOT/EOT markers for 1/2" tape
Hello Retrofolks, I have a 1/2" 9-track magtape which is missing a BOT marker. Does anyone have a recommendation for a reflective tape to use to replace the BOT marker? I was looking at https://www.amazon.com/Metalized-Polyester-Adhesive-Multiple-Available/dp/B07TXN8TD8, but I have no idea if it's too stiff/thick/not sticky enough/etc. Thanks. --Bjoren
RE: idea for a universal disk interface
-Original Message- From: ben [mailto:bfranc...@jetnet.ab.ca] Sent: Saturday, April 16, 2022 1:39 PM To: cctalk@classiccmp.org Subject: Re: idea for a universal disk interface On 2022-04-16 1:13 p.m., Tom Gardner via cctalk wrote: > Tom > How do you handle the disk hardware timing, power up, seek and disk RPM?. Ben. Those really shouldn't be any problem. RPM is data rate but unlike the disk drive the RPM and the data rate in an emulator are as precise as the crystal and hardware setting the data rate- no jitter, speed variation etc. Everything is on time The emulator would have to generate a synthetic Index signal (and sectors for hard sectored controllers) to keep the controller happy but that is just counting off a clock. Power up - most drives tell the controller when they are ready but some have a start/stop controls. Regardless, it is pretty easy for the emulator to respond to any commands and present appropriate status. It doesn't have to wait for a disk pack to spin up - as soon as it gets a start command it can present ready status. It would have to generate a home signal but all that means is the data pointer is pointing to the memory location of the first byte of the first track (Track 00 head 00) Seeks are near instantaneous - the controller issues the seek command and after a minimum delay the emulator presents ready status The only thing the emulator really has to worry about is too quick responses breaking the controller
