by the way there was a early drive by iss also called 2888... this isll not work on 2000 was for early 3000 only... more explain... 2884 was a 2883 without a controller gate for the most part. ed sharpe ----- Original Message ----- From: Frank McConnell <fmc(a)reanimators.org> To: <cctalk(a)classiccmp.org> Sent: Sunday, November 23, 2003 6:07 PM Subject: Re: Grandfather system RTE6/VM? What the

Peter C. Wallace wrote: <snip Given an ATA drive, its much simpler to emulate the controller to CPU interface than it is to emulate the controller to disk interface. This is especially true for the MAC-series drives, but totally untrue for the 7900 (which uses a pair of generic TTL-level I/O boards). If the controller is well emulated, the software again sees no difference and runs normally with a much smaller investement of design effort.

(Problems with a mailserver earlier this week, outgoing mail was lost, so I'm re-sending. My apologies if this is a duplicate.) My suggestion (worth every cent you paid for it) is to use a whole damn computer on the other side of the HD controller. Construct an electrical interface of the simplest possible hardware to get the job done (electrical interface, buss termination as required, etc) and do the whole job in C or even Perl. Simulating the block structure of the disk would be trivial in software. The hardware handshake and DMA junk would be where the work is -- regardless of the level simulation abstraction, but with say two EPP parallel port cards you could have the handshake nicely defined in (more readable than yelling schematics) code. A mediocre gigaHz cpu has gotta keep up with all but the fastest disk controller of yore. And then later when EIDE and serial ATA are as obsolete as core, your simulator is more likely to port to whatever the crapyp hardware of 2020 is. (The assumption is that translating C, perl, whatever will be easier than soldering.)

On Fri, 2003-12-05 at 14:28, Jules Richardson wrote: As you point out, it can be a case-of-beer's-worth of computer, for many simulated devices. I take it ST506 has analog data for a controller-side separator; this makes it harder, but as others point out, it could be 'tricked' or probably simulated with an 8-bit flash converter, and/or use Duell's idea for an analog sector recorder! Disk size being what it is today, you could probably record each "sector" as AtoD'd analog data in a userland program. (My LGP-21's rotating memory probably contains interesting data, so I'm probably going to copy the tracks (32 physical) to disk with an opamp on the head windings driving a sound card, and post-process the NRZ data later. I'll likely take multiple copies of each track for safety.) I'm guessing that for slow interfaces, SASI or maybe ST506, you could make a semi-generic hardware interface that had a dozen latched output bits, some input bits, an 8-bit DAC and ADC, and with only enough hardware drivers to talk to it, do the rest of the simulator in software. DMA-speed interfaces like SMD would require hardware buffering, and delays could generate timing issues in the controller. But I bet a lot of machines could use a slow interface.

A non-text attachment was scrubbed... Name: not available Type: text Size: 2442 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20031205/10cc7c9a/at…

Hello all. I am doing a hobbyist research about the origins of Arpanet, and for my surprise the original Arpanet protocol (represented in the STD39 document) was declared historic in 2001, retired from the STD list and substituted for one reference to BBN to obtain the document. I've contacted them and... they can't provide me the document, named BBN Report 1822 inside the company. Can someone helps me, please ? I should agree too other providings of Internet RFCs or STDs retired of the official list. Thanks and Greetings Sergio

And thusly Witchy spake: ? But isn't the PET an elegant "solution"? The computer does the computing working and the disk drive(s) do the disk work.. Or am I missing the point completely?! Cheers, Bryan Pope

A non-text attachment was scrubbed... Name: not available Type: text Size: 2766 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20031206/8b2574d1/at…

On Sat, 6 Dec 2003, Tony Duell wrote: Are you assuming that the host is able to read that much data in the span of one disc revolution? Something tells me that it would require multiple passes for an old 286/12 to read an entire 2MB track from a hard disc, not to mention the other limitations of bus speed, interface width, etc. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

A non-text attachment was scrubbed... Name: not available Type: text Size: 7752 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20031207/dba8190f/at…

On Sunday 07 December 2003 13:47, Tony Duell wrote: Here's an idea. You DON'T need to transfer that much in the 'cylinder change' time. First, you can double the size of the original buffer (to 4MB), and have two separate buffers. When you switch heads, all you have to do is "swap" buffers (preferally by updating a memory pointer, or using by bank switching it - not by copying it). Now all you have to do is have time to read one buffer (2MB) in during the 'cylinder change' time, which halves your necessary data transfer rate. You can then write out the other buffer "in the background" to the disk, which has only to take less time than the drive spends lingering on the current cylinder. Step two. Add a 'dirty' word to each cylinder that has one bit per cylinder. Clear these before reading in the new cylinder, and set them only if the host asserts its write gate signal. In the common case, this will greatly reduce the amount of data you need to write back to disk. In addition, if no dirty bits are set, you can just 'junk' the data in memory, and NOT write it to disk. This keeps you from having to flush out the data you need to write to disk when the controller is just stepping the drive through cylinders. However, you have to be careful to wait for the 'to be written' data in the background buffer to be completely written before allowing the cylinder change to finish if you have any dirty bits set. Step three (version 1). While the head can switch tracks at any time, the disk does _rotate_ linearly. So, if you store the bits on the real disk in a manner like this: (assuimg 4 heads) Block #: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... Cylinder: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... Head: 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 ... Sector: 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 ... You can start reading this data when you're told to switch tracks, and assert the 'seek complete' line when you're ready to read the block correlating to head 0, sector 1. As long as you can read the data from disk into memory fast enough to keep ahead of the memory position from which you're sending data to the old controller, you're set. Also, it's important to selectively write, using the dirty bit scheme. If you've written to a track, make sure you have the *entire* track read into memory before you step to a new track and write data out, or you'll lose data... Step three-B. Don't write your background/output buffer while reading new data in, make sure you do this either before or after reading (after reading should improve speed). Step three (version 2). Add two more buffers to store data (up to 8MB). You can at most move one track at a time. After you've written your data for the previous (dirty) cylinders to disk, prefetch data into a buffer for the next two possible cylinder choices - moving forward one and moving back one. Also, don't allow a track switch to finish until you've completely 1) written out the dirty buffers 2) and read in the cylinder that's going to be switched to. If you get the signal to switch cylinders before reading both cylinders, stop reading the one that's not getting switched to, and only read the one that is getting switched to. Once you're done reading that, assert the 'seek complete' signal, and bank-switch the correct buffer into memory. For version 2, the worst case scenerio will be writing to an entire cylinder, and then seeking more than one track immediately afterwards, and will require the full 4MB of data to be moved in the time of two drive seeks. Version 1 would be faster, but would be more error/bug prone, and you need to ensure that you can read your data in from disk at least (#tracks) times faster than you need to output it to the original host controller. There's still the issue of what to do when the host powers down... you could perhaps have a timer that automatically writes any changed data out to disk if the cylinder hasn't changed in the past, say, 500ms, and clears the dirty bits after it has written the data. Then it's just a matter of making sure the operator waits at least a few seconds before powering off the machine, after halting it. Now, if I could just use things like this email to satify course requirements at Purdue... Pat -- Purdue University ITAP/RCS Information Technology at Purdue Research Computing and Storage http://www.itap.purdue.edu/rcs/

On Sun, 2003-12-07 at 10:47, Tony Duell wrote: I had forgotten this about ST506! But hell, RAM costs being what they are, the whole disk image could be kept in memory, with a dirty bit and/or timer to write changes to permanent store to avoid data loss, in the simulator. Hmm... how about a hardware simulator, with a USB port on the back side that connects to a host computer. You load the "ST506" image into the simulator, copy it back out for safe keeping when you're done.

Available for free to anyone willing to pay shipping: 6 DEC Storageworks BA350 enclosures, tested and working $15 Each shipping or take them all for $70 shipping. 2 DEC Power Distribution units, 220V 20a circuits input, they have 28 110V standard power plugs to plug into any device such as pc's, drive array's, networking gear, etc.... These are VERY heavy, the power cabled alone must weigh about 20lbs !!! Shipping is $40 UPS each anywhere in the US You pay the shipping, they are yours, will offer these for 1 week, then they are off to recycling. Curt

A non-text attachment was scrubbed... Name: not available Type: text Size: 3738 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20031210/180f82fc/at…

The part of the ST-506 disk emulation that's of most concern to me is whether anything needs to be done about write precompensation. The controller shifts the pulses on write to compensate for the peak shifts that happen on magnetic media when flux changes are recorded close together. If the emulated drive does not emulate the peak shift, the read data timing will be further from the nominal timings that that the controller expects. This will affect the controller's data separator PLL. I'm guessing that it won't be enough to cause reads to fail MOST of the time, but it will reduce the timing margins enough to that it could potentially cause occasional soft errors.

--On Tuesday, December 09, 2003 22:16:54 -0500 John Lawson &lt;jpl15(a)panix.com&gt; wrote: Some drives don't need the controller to do write precomp -- presumably it's done by the drive electronics. In such cases, you typically program the controller to apply precomp at a cylinder number equal to the number of cylinders the drive has. Some drives do need the precomp done, and then you program the controller to apply it to the data for every cylinder above a certain value, and it gets applied before the data reaches the drive interface. I think Eric's concern is that the emulator would receive write-precompensated data, record it verbatim, and play it back verbatim for a read. The precomp has the effect of shifting some of the data transitions by a fraction of a bit cell. This would result in the timing between some bits being wrong. There's no signal on an ST506/412 interface to tell that write-precomp is being applied, so the emulator won't know. My solution would be to program the emulator with the cylinder number (if any) above which to do the opposite bit shift, and undo it. I wouldn't try to decode the bitstream, only look at the sequence of bits in the same simplistic way a controller does when it turns on its internal EARLY/LATE signals. I think that you'd want to be able to program certain of the drive characteristics into the emulator anyway. Some controllers try to guess which "supported" drive is connected by doing things like seeing what happens if they select certain heads, step past a certain cylinder, etc. Therefore you'd possibly want to be able to tell the emulator to behave as if it had a certain number of heads and cylinders, -- Pete Turnbull Network Manager University of York, UK

I wrote: John Lawson wrote: The controller does write precomp, and the drive emulator can't easily tell on which cylinders the controller is doing it, vs. on which it is not. In fact, the controller could use varying amounts of precomp on various ranges of cylinders, e.g., 25 ns on cylinders 0-199, 30 ns on cylinders 200-299, 35 ns on cylinder 300-399, etc. In practice every controller I've dealt with has a fixed amount of precomp that is used on a (possibly configurable) range of cylinders. Anyhow, the point is that when the controller performs write precomp on a cylinder, it is trying to compensate for the magnetic characteristics of the drive, and expects the data to come back when read *without* much if any of the precomp-introduced shifting intact. If the drive emulator does not emulate the precomp behavior of the real drive, the read data pulses will be out of their nominal timing by the precomp amount, which increases the probability of read errors.

--On Tuesday, December 09, 2003 20:45:45 -0800 "Peter C. Wallace" &lt;pcw(a)mesanet.com&gt; wrote: [...] But then you need to know what the bitstream is, which goes against what we've been saying. And what about different encoding methods: what happens when someone wants to emulate a drive on a system you've not thought of? Actually, I don't think you need to know the encoding scheme at all. I believe the precomp (if/when applied) depends only on the sequence of transitions in the data. -- Pete Turnbull Network Manager University of York, UK

On Wednesday 10 December 2003 10:47, Peter C. Wallace wrote: "Knowing the encoding scheme" prevents this from being a "universal" interface. You'd need to make different version for, say, your PC/XT, your PDP-11 with an RQDXn, and TeleVideo TS816. (Or shouse I say "my" as those are all system I have that'd benefit from this). At most, (I think) you'd need a different cable set for all three of these if you didn't claim to "know" the encoding. Also, with at least two of these examples, you probably *don't* know the encoding method... as mentioned earlier, the RQDX(1) isn't based on any 'standard' controller IC. Also, the TeleVideo's controller is based upon an 8X300 microprocessor, and may not be RLL/MFM/FM. Pat -- Purdue University ITAP/RCS Information Technology at Purdue Research Computing and Storage http://www.itap.purdue.edu/rcs/

On Wednesday 10 December 2003 11:27, Peter C. Wallace wrote: Not being an 'expert' in data encoding schemes for hard drives, I can't claim with 100% certainty... but I'm willing to bet there's systems out there that use things such as GCR (similar to the Apple ][ and Commodore floppy disk encoding schemes). Also, you'd have to take into account in your scheme that the data rate for different controllers may not match. For example, recording data on the 8" hard drive in the Televideo TS816 probably isn't the same 'data rate' as a common ST506 interface drive, even though the interfaces are similar. To me, it's pointless to create a design that's arbitrarily limited to just one encoding scheme if you don't have to. When you can simplify the design *and* make it more universal, why not? Pat -- Purdue University ITAP/RCS Information Technology at Purdue Research Computing and Storage http://www.itap.purdue.edu/rcs/

Hi everybody. Question for gurus: Someone knows (or adapted it for yourself) of one 5.25 floppy drive connected with some kind of USB cable or controller ? I want to do image disks of almost 2000 diskettes I have, and I should like to use my laptop to do it. Thanks in advance. Cheers Sergio

On Wed, 10 Dec 2003, Vintage Computer Festival wrote: There are PC laptops with no floppy, that use external USB floppies. Q: do those have, inside them, an "industry standard" (SA400) drive? If so, then cabling to a 1.2M or 360K drive should be trivial. HOWEVER, it seems unlikely that it will support the 300K data transfer rate, so reading 360K disks in a 1.2M drive will require switching drives to a 360K, or some kludges on a "dual speed" drive.

At 12:33 PM 12/10/2003, you wrote: I would love to be able to connect a 5-1/4" external floppie drive via USP to XP PRO or WIN98SE. If anybody can lead me to what I need I would be willing to purchase it. ================================= Gene Ehrich gehrich at tampabay.rr.com

On Wed, 2003-12-10 at 08:42, Patrick Finnegan wrote: To this end, it seems reasonable to have the simulator be given some knowledge of the thing being simulated, for example, the bit transition timestamp (delta-T between transitions) could be a small value, and a DIPswitch (real or virtual) set the granularity (100K/ 1M/ 10M/bits/sec), that sort of thing. Generic-enough variables to handle all or some vast percentage of possible drives.

Do you? I don't think I know the exact details of the encoding scheme for half of my computers, and I have schematics for the lot (and service manuals for quite a lot of them). Only if you really understnad the encoding scheme. And do you really want to have to come up with a new FPGA configuration file for every computer, including ones you've never seen? On the older controllers, precompensation was typically done using a delay line (probably 10ns per tap) and a 74153 4-input mux (of which only 3 inputs were used). The 2 contol inputs to the mux was 'early' and 'late' (both deasserted left the bit at the nominal timing position, asserting one of the signals moved it appropriately). The early/late signals generally came from the controller IC if there was one. Or maybe from a little state machine based on the data bitstream. The PERQ 2T2 DIB (Disk Interface Board) has a PAL for this, but alas all the DIBs I have are for drives that do internal precompenastion, and the PAL never asserts either signal. So I don't have the details of the state machine... Of course the delay line and mux could be replicated in the emulator to move the bits back again (all bits are delayed by the same total time, which doesn't really matter, if the controller makes a bit 'late' then we pick if up of an ealier tap of the delay line in the emulator, and vice versa). -tony

On Thu, 11 Dec 2003, Tony Duell wrote: If its done with a FPGA, the modification is "stiffware only" and does not require new hardware. Plus there are some substantial benefits of decoding the bitstream, one is that now the front end can run much faster (say even 200 MHz) without requiring large and wasteful raw bitstream storage... Since write precomp is in the area of 10-20 ns, if we are worried about undoing write precomp, maybe we should also worry about our recording resolution - preprocessing the input stream makes improving the timing resolution easy... No, but 95% of older ones will be MFM... Other than FM, MFM, RLL and some newer ones what other magnetic disk encoding schemes are there? No, I just need the (programmable) front end to do the MFM --> RZ (or RLL --> RZ or GCR --> RZ) data conversion... As I said in an earlier email, you could undo the write precomp by just measuring the deltaT's Peter Wallace

Andy wrote: RLL 1,7 is also common.

Eric Smith wrote: I don't see how that would make a large difference as you only have 2x increase in data size. Anyhow would not information be saved on a track rather than sector chunk size to ram? While you don't encode data, knowing the data format would help with removing write precom when syncronzing the data to the track bit stream. Ben.

Why so fast? You only need sample at 2x the bandwidth. Andy

Eric Smith wrote: Remember only the leading edge is important so this just digital data. While you need a high clock to reduce jitter, remember too about meta-stable problems. When you think about it you would only need about say 4 bits of information per data clock. 1 bit would be pulse yes/no and the other 3 bits would be phase shift from the master clock. Now do you really need to use a FPGA when a PAL's might be better with external ram.

I wrote: Sellam wrote: 1. Even a 10GB drive is more capacity than is needed, so that's still no reason to cripple the functionality by making the emulator decode a particular dat format. 2. If I were to build one of these for myself (or as a product), I wouldn't want to use some random old disk drive of questionable reliability. In fact, I'd probably want to use *two* new disk drives with mirroring.

On Wed, 2003-12-10 at 23:50, Tony Duell wrote: Oh, that reminds me - I came across another ACW owner last night. Waiting to hear what (if any) docs / software he has for it. That, I think, is a must, compared to having to design something else entirely to read the data off the drive in the first place. And as you say, hopefully it isn't too complex to achieve. Presumably there's nothing to stop data being compressed/decompressed at the 'new' hard drive level, providing the emulator is fast enough to do this. Unless your ST506 (for the sake of argument) drive contained a single huge compressed file originally, compression level should be reasonably good. Fair call. The shorter cable lengths of IDE *might* be a problem with mounting in some machines I suppose, but it isn't a biggie. Getting something that works for the first version is better than nothing :-) Absolutely. That's how I back up some of my classics with SCSI drives at the moment :) It, presumably, would not be difficult to stick a serial port on this thing for some sort of rudimentary control; there are likely parameters which it would be handy to be able to set up remotely without delving inside the classic machine hosting the emulator anyway. Transferring 2-3GB across a serial line isn't really viable (serveral days to transfer!) but for the more common classic drives in the 10-30MB range I imagine it's viable. cheers Jules

This does, however increase the hardware complexity considerably.... I am not he sort of person who likes using excessive amounts of memory (I have no problems writing micorocontroller programs in 256 bytes or whatever). But I think in this case it makes sense to just buffer the uncompressed data for each cylinder. You can compress it when storing it on the modern hard disk if you like (it becomes a trade-off between data transfer time and compression/decompression time. The actual space taken up on the modern disk is irrelevant, as just about any modern hard disk is large enough to store any ST506 image, even without compression.) True. This is a good reason for not compressing the data in the sector buffer. Err, hang on... You now want to have a pointer associated with every data word in the RAM (at least 16 bits long, presumably). The compression looks a lot less atractive! You also have the problem of setting up the pointers -- OK, when you start a write you can change the last pointer before the changed block to point to some unused area of RAM, then start storing the new values, but what do you do at the end. You have to point back to the old values that correspond to transistions after the changed region, but how do you find those quicky. And then you have to flag the old area of memory as unused. And you may end up with fragmented gaps in the memory after a number of writes, so you then have to search for unused spavce, again in real time. Personally, I'll just use 2M of RAM (which is not that many chips nowadays...) Cheaper, maybe (but the cost of the development tools and the computer to run them is not zero). Easier to do, not for me. More flexible, it doesn't matter, since provided the emulator works with all ST506 controllers that's all that matters. Easier to debug, no way. I've designed with FPGAs, and I've designed with simple logic chips. I know which is easier to debug. You have to be _very_ careful modifying an FPGA design to include debugging pins, etc, sinve re-routing the chip will change the propagation delays (this has bitten me once, and the simulator didn't realise it either!!!) Buildable into the future, no. FPGAs seem to get replaced with new versions far too frequently. On the other hand I have no problems getting simple logic chips. You have to be careful which logic chips you use (anyone desinging with a 7443, for example, is crazy), but simple gates, D-tpyes, JKs, shift registers, etc are not hard to find. Pereformace, it only has to be good enough to replace the ST506 drive. More reliable, Hmmm... I've had a lot more LSI devices fail for no good reason that TTL. I think my TTL-based minicomputers actuallly have the fewest repairs of all the machines I own. I've never changed a TTL chip in a PERQ (I have replaced RAM and the floppy disk data separator. You've been very lucky. THat's all I can say.... Either that, or you've not seriously tested the simulator, you've just trusted it. I have a number of circuits I throw at simulators to see what they make of them... As I said above, you have to be careful doing this.. I've done that many times. It's not that hard if you know how to terminate the signals, how to route them, etc. And use twised-pair wire-wrap wire (hint : 3 twists per inch has a characteristic impedance of 100 ohms, or thereabouts). The suppliers over here stock them. Anyway, what's so hard about SMD? That depends o nthe FPGA family, I think. Some of them are programmed internally. As I mentioned above, that's not enough :-). A PIC (16C84, it was at the time, now the 16F84) is trivial to program from a parallel port. But hobbyists wouldn't try it... Alas, often porting to a new FPGA _is_ a complete redesign... Anyway, I've not had any problems finding 'classic' chips. Finding last year's FPGAs, PLDs, or microcontrollers on the other hand.... -tony

Peter Wallace wrote: The slowest SDRAM you can buy now is fast enough that page crossings are not a problem. You could actually completely avoid use of page mode, in which case the data rate from the SDRAM is constant. However, since FPGAs give you small FIFOs at zero incremental cost, there's no reason to try to avoid them. Of course, some people don't want to use FPGAs.

I wrote: I should clarify that I'm assuming that the host uses buffered seek and properly uses the -SEEK COMPLETE signal from the drive. If the drive does not use buffered seek, it is necessary to transfer a new cylinder's data into the buffer RAM in less than the seek time. As far as I know, the highest capacity 5.25-inch Winchester drives that did not use buffered seek had no more than four heads, 615 cylinders, and no less than 20 ms seek time, so the maximum transfer rate needed to transfer data to and from the backing disk is about 33 MB/s. This would require RAM with a 30 ns cycle time. More practically, the buffer RAM could have a x16 or x32 organization, stretching the cycle time requirement to 60 ns or 120 ns. I think a disk emulator would still be a useful product if it ONLY supported emulation of drives with buffered seek capability. Perhaps a different model could be used for drives without buffered seek; such a model might simply buffer the entire drive contents (about 205 MB). Eric

A non-text attachment was scrubbed... Name: not available Type: text Size: 1316 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20031210/3703d231/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 2129 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20031210/fd2726e7/at…

I woulld agree... No, I think 512K SRAM chips are now easy to obtain and cheap. Certainly 128K ones are, and it's only 16 of those (which is not excessive). I'd want to organise the RAM as at least 16 bits wide, maybe 32 (to simplifiy the timing problems in the rest of the hardware), so larger RAM chips wouldn't be a big help. I think it partially depends on what drivers and receivers are used, and how well the cables are terminated. I've probably broken all the rules, but I have sent ST506 signals down a couple of feet of cable without problems.... Just don't have the classic one one side of the room and the PC-with-the-emualtor on the other.... I was hoping to do that (although I was also thinking of a full-height bay.... The simplest hardware would seem to take 2-3Gbytes for a maximum-size ST506 image. Most will be a lot smaller than that. I think 20-40Gbyte IDE drives are pretty cheap now.... I don't have either 'spare'. It really comes down to which makes the hardware interface easier. I'd like to try DMA (see the other message) -- this is not too hard on a SCSI drive, I think it's OK on most modern-ish IDE drives. A really kludgy way to do this is to pull the drive from the emulator, cable it up to a PC, and copy the image over using dd or something. Not elegant, but it'll work (remember the data on the modern drive is stored in normal sectors on said drive, so a PC can read it, even if it can't make sense of it). -tony

On Fri, 5 Dec 2003, Tony Duell wrote: I don't see it that way at all. As Jules alluded to, it's an excellent re-use of old hardware that's not collectible anyway. Why invent the wheel each time you want to do a project? If you're going to mass produce a bunch of ST-506 emulation interfaces then a custom designed board is certainly the way to go. But if you want to design a project that can be built by nearly anyone with minimal electronic skills and old PCs laying around (just about everyone here) then using old PC hardware is a perfect solution. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

On Sun, 2003-12-07 at 10:39, Tony Duell wrote: I think you're missing the point here, the idea was that using "current pc tech" you could use current-standard software environment and hardware interfaces, using the "pee cee" as an interchangable black box. Software program inside, standard interface outside, everything else purely blackboxed.

On Fri, 5 Dec 2003, Tom Jennings wrote: Also assuming ECP parallel ports will be resident on the crappy hardware of the future. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

I'm looking for a Hayes Smartmodem 300 to add to my collection of Hayes Stack components. A Working unit with a power supply would be great. :) It should also handle the morse output command (AT C I think). Please reply off list. Thanks! g.

A non-text attachment was scrubbed... Name: not available Type: text Size: 1020 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20031209/7c83a92b/at…

On Mon, 2003-12-01 at 16:32, Andreas Holz wrote: Agreed. Or given the capacity of modern (ish) IDE/SCSI drives versus old hardware, being able to host several virtual drives on one physical one would be interesting, not waste drive space, and make it trivial to back systems up. Several machines' drive controllers could be interfaced across a network to one host. The "black-boxes" would talk ST506 on one side and ethernet on the other, say. Interesting idea anyway... but given the nature of ST506 is it feasible? Doesn't ST506 have analogue elements to the interface, and a tight relationship to the host controller with which the drive was formatted? cheers Jules

On 1 Dec 2003, Jules Richardson wrote: No, there are no analog elements other than timing, and that can be simulated digitally with sufficient resolution to fool the controller. MFM drives and many earlier types should be pretty easy to emulate. Think of the emulator (one track at a time) as just a big shift register clocked at ~16X the drive data rate... Peter Wallace

On Mon, 1 Dec 2003, Tony Duell wrote: This is what I was trying to suggest, with the added feature of slight data compression by counting the clocks between data transitions, that way a 16X clock (80 MHz for MFM data recording) doesn't use 16 bits per data bit, only 4... Peter Wallace