Thread
HD20 Schematics required
Dennis, couldn't be happier that you are taking on this project!
While you're at it, will you see if you can figure out what code Apple used to disable the HD20 under MFS? It can be formatted MFS, but requires by default that the HFS file system be loaded, or present in the case of the 128K ROM or laters. This means it cannot be used on a stock 128K, for which there is otherwise no reason it should not be able to be used, other than if fully loaded would be slow as molasses under MFS as the Finder struggles to keep track of 20MB of data. But it would be a great device to transfer files back and forth between a more accessible compact and the 128K. Even if only a small capacity of it is used, it would eliminate the two floppy drive limitation of the 128K, and vastly increase the storage space of a 128K, the current max of which is 1600K, without swapping floppy disks. I would also be happy to find a way to load HFS on a 128K, just to see how it actually copes with the file system using the added burden of the INIT code to the system heap.
viewtopic.php?f=7&t=1492&hilit=HD20&start=25#p21460
While you're at it, will you see if you can figure out what code Apple used to disable the HD20 under MFS? It can be formatted MFS, but requires by default that the HFS file system be loaded, or present in the case of the 128K ROM or laters. This means it cannot be used on a stock 128K, for which there is otherwise no reason it should not be able to be used, other than if fully loaded would be slow as molasses under MFS as the Finder struggles to keep track of 20MB of data. But it would be a great device to transfer files back and forth between a more accessible compact and the 128K. Even if only a small capacity of it is used, it would eliminate the two floppy drive limitation of the 128K, and vastly increase the storage space of a 128K, the current max of which is 1600K, without swapping floppy disks. I would also be happy to find a way to load HFS on a 128K, just to see how it actually copes with the file system using the added burden of the INIT code to the system heap.
viewtopic.php?f=7&t=1492&hilit=HD20&start=25#p21460
Replicating a "black box" and actually understanding it well enough to make a major functional change, like using a different filesystem, are two very different things. I believe that I can replicate the original functionality, or at least document it well enough to be extremely helpful. I don't know enough details at this point to tell exactly what modifications are feasible; a lot of things will probably end up remaining unknown and just repeated from observations. It seems to me that if there is a 20MB volume limit with this interface, and a limit of 2 HD20s, at least some attempts to provide an emulated second HD20 should be worth investigating.
I have a Willem ROM programmer that supposedly can dump the 2764 ROM chip inside of the HD 20. Given that it's only 8 kilobytes, disassembly should at least be somewhat feasible and should shed some light on the Rodime and floppy interfaces. Once dumped, I shall certainly share the 8k file for others to poke around in. Theoretically, we can determine where the Z8 starts execution and disassemble from that point. From there we can determine what register is what, which ports correspond with what hardware, and form up all sorts of cool theories.
If we crack the external disk drive interface, we can build a new board that converts those signals directly to flash. If we crack the Rodime interface, we can build a new board that converts THAT to flash. Both have advantages and disadvantages.
Cracking the Rodime interface allows us to continue using the original controller board and its daisy chain port, the most authentic solution, and maybe the easiest. Cracking the disk drive interface allows ANYBODY with a ROM burner and a soldering iron to build an external disk drive port hard drive with a few affordable parts, but replaces the original HD20 interface board. More hacking is required to provide the daisy chain port, and in all honesty, that part is likely to be skipped in all of the excitement unless it's fairly straightforward. I suspect that the complete replacement version is low-power enough to be powered off of the floppy port.
We have to disassemble the HD20 a bit before we really know which direction to go with this. I imagine that I will have the drive in a week or so. My favorite microcontroller board is loaned out at the moment, so it may take a bit to analyze signals. Stay tuned!
I have a Willem ROM programmer that supposedly can dump the 2764 ROM chip inside of the HD 20. Given that it's only 8 kilobytes, disassembly should at least be somewhat feasible and should shed some light on the Rodime and floppy interfaces. Once dumped, I shall certainly share the 8k file for others to poke around in. Theoretically, we can determine where the Z8 starts execution and disassemble from that point. From there we can determine what register is what, which ports correspond with what hardware, and form up all sorts of cool theories.
If we crack the external disk drive interface, we can build a new board that converts those signals directly to flash. If we crack the Rodime interface, we can build a new board that converts THAT to flash. Both have advantages and disadvantages.
Cracking the Rodime interface allows us to continue using the original controller board and its daisy chain port, the most authentic solution, and maybe the easiest. Cracking the disk drive interface allows ANYBODY with a ROM burner and a soldering iron to build an external disk drive port hard drive with a few affordable parts, but replaces the original HD20 interface board. More hacking is required to provide the daisy chain port, and in all honesty, that part is likely to be skipped in all of the excitement unless it's fairly straightforward. I suspect that the complete replacement version is low-power enough to be powered off of the floppy port.
We have to disassemble the HD20 a bit before we really know which direction to go with this. I imagine that I will have the drive in a week or so. My favorite microcontroller board is loaned out at the moment, so it may take a bit to analyze signals. Stay tuned!
OK, my HD20 with the butchered data cable arrived, and all I've been able to do is take a few photos which are over on RetroMacCast (http://retromaccast.ning.com/photo/hd20-close-up-of-cut-cable?context=user). Haven't been able to get out the spare 400k drive to "borrow" the cable as we are in the process of adopting the neighbour's 3 cats and are getting the downstairs ready for their arrival. Inside the HD20 is dusty and will need a good brush and blast before I do any work with it.
That doesn't look like the original cable anyway. It looks like a 400k drive cable. Compare to some of the other pictures posted here. Very interesting.
I'd pull the internal connector before powering it on in case the chopped cable has created short circuits. But you should be safe to turn it on and have a listen once that's removed.
I'd pull the internal connector before powering it on in case the chopped cable has created short circuits. But you should be safe to turn it on and have a listen once that's removed.
Its hard to say exactly what the limits are with the HD20. Its entirely possible the HD20 could support a larger drive, but Apple didn't offer it based on System limitations, or merely price point. Look at their first SCSI drive, it only offered 20MB for many months, yet the case is capable of supporting any size drive you can fit into it, and supported by the system. So the HD20 may well support a greater than 20MB limit.
Also, the HD20 only officially supports one additional daisy-chained drive, but others have reported no problems with three and up to six daisy chained. Hard to say why such limitations were invoked by Apple, maybe to force the consumer to buy more than one Macintosh? But, as you say the onboard ROM dump will divulge much.
The HD20 is also designed to hold a 5.25" full height drive. The original Macintosh ROM contains a driver for the Apple Widget drive per Inside Macintosh, which drive was a full height 5.25" drive. So it's entirely possible the original HD20 drive was intended to be Apple's own Widget, until that too was discontinued along with the Lisa in early 1985. This may in part explain why the HD20 was announced during the 2nd quarter 1985, but not actually delivered until the 4th quarter, as they retooled it for the Rodime.
And yup, that's the 400K drive cable alright ... so if any damage was done, then there's no reason not to try a replacement 400K cable.
Also, the HD20 only officially supports one additional daisy-chained drive, but others have reported no problems with three and up to six daisy chained. Hard to say why such limitations were invoked by Apple, maybe to force the consumer to buy more than one Macintosh? But, as you say the onboard ROM dump will divulge much.
The HD20 is also designed to hold a 5.25" full height drive. The original Macintosh ROM contains a driver for the Apple Widget drive per Inside Macintosh, which drive was a full height 5.25" drive. So it's entirely possible the original HD20 drive was intended to be Apple's own Widget, until that too was discontinued along with the Lisa in early 1985. This may in part explain why the HD20 was announced during the 2nd quarter 1985, but not actually delivered until the 4th quarter, as they retooled it for the Rodime.
And yup, that's the 400K drive cable alright ... so if any damage was done, then there's no reason not to try a replacement 400K cable.
That's very good to know!
Curiouser and curiouser, thanks for the quick ID on the remnants of the cable gentlemen. When I get the chance I'll clean the dust out, remove the butchered cable and give it a power-up test, then try the 400k's cable.Post by Dennis Nedry » 29 Nov 2010, 08:15That doesn't look like the original cable anyway. It looks like a 400k drive cable. Compare to some of the other pictures posted here. Very interesting.
I'd pull the internal connector before powering it on in case the chopped cable has created short circuits. But you should be safe to turn it on and have a listen once that's removed.
I'll let you know how it goes.
Well, well, well...
http://cgi.ebay.com/Rare-Macintosh-Hard-Disk-20-drive-software-case-/290506026430?pt=PCC_Drives_Storage_Internal&hash=item43a3822dbe#ht_3225wt_1141
Interesting how fast these "rare" HD20 drives pop up on EBAY, one after another. And this one has its cable intact too, as do most I've seen on EBAY. Which makes me ponder the definition of "rare" a bit... Ahah! So that is the definition of a "rare HD20"!!! An HD20 with its cable hacked off! A cable-less HD20, my friends, is indeed "rare." But the one on EBAY at the moment, is not.
http://cgi.ebay.com/Rare-Macintosh-Hard-Disk-20-drive-software-case-/290506026430?pt=PCC_Drives_Storage_Internal&hash=item43a3822dbe#ht_3225wt_1141
Interesting how fast these "rare" HD20 drives pop up on EBAY, one after another. And this one has its cable intact too, as do most I've seen on EBAY. Which makes me ponder the definition of "rare" a bit... Ahah! So that is the definition of a "rare HD20"!!! An HD20 with its cable hacked off! A cable-less HD20, my friends, is indeed "rare." But the one on EBAY at the moment, is not.
Yeah, it goes without saying that the US is a treasure trove of Apple stuff. But here in Australia, we can't just snap our fingers or wait for a few weeks for something to come up. I have been looking for the past 6 months, and one has never popped up. There has been no 128Ks and only one 512K. A TAM, forget about it. So, you may have it easy but we are not in the same boat as you - hence rare.
for years i bought items on ebay
even the ones with: 'Shipping to: United States'
if you realy want an item,
ask sellers if they would send the item to your place
ask the amount for handling and shipping...
you have nothing to lose
even the ones with: 'Shipping to: United States'
if you realy want an item,
ask sellers if they would send the item to your place
ask the amount for handling and shipping...
you have nothing to lose
It's not really that interesting, but that floppy disk for the HD20 is probably worth more than the unit itself.
Yep, done that, and sometimes they oblige, and sometimes not. What the killer is is the cost of shipping from the USA to Australia. I just don't understand it. Asia to Austrla is cheap - understandably, UK/Europe is not too bad, Canada is not bad either, but for some reason shipping from the good ol' USA is down right criminal at times.
Recently I acquired copies of MS Word and MS Basic Interpreter for 128/512k Macs and it cost US$50 (ish) each to sent to the land down under, but nix, and next to nix for domestic. Similar size and weight packages from the UK only put me back the equivalent of US$20 for it to be sent by Her Majesty's Royal Mail.
Yep, the USA is a treasure trove of ye olde computer goodies, but be prepared to pay heavily for it to be sent down to this end of the planet.
And cursed be USPS for that. They used to offer Ocean shipping, but no longer. I am so thankful I purchase my compact Macs off EBAY when I did. I would have never even considered bidding on them, had USPS killed off Ocean shipping and I had been stuck with outrageous AIR mail as the only option. I also blame Americans too since they didn't make a stink about it and allowed USPS to do it (and as an American, I have every right to say that too).
Thankfully, Japan Post has retained its sanity, and I can ship virtually anything, anywhere by "reasonably priced" Ocean shipping. Sure it takes a month, but the cost savings is incredible.
Actually it is sort of interesting that once a topic becomes hot on this forum, suddenly the item in question begins turning up in spades.
As for the floppy disk, hardly rare. I see at least a dozen or so per year circulating on eBay with and without the drives. Mostly worthless in my opinion, as the drivers are freely available on the web, and more often than not, these floppies have been updated with the latest Systems the user was running at the time they discontinued use, assuming they even work, thus negating their collectability, to thextent they have any such value. I've seen disks, which didn't even have the HD20 software on it - the disk recycled once they stopped using the HD20. And for the record I've never seen an HD20 disk sell for more than a working drive. Nor have I seen a manual sell for more either.
There's rare stuff on eBay, but it is few and far between. Nothing discussed here is rare, and I hate this forum helping to perpetrate this myth in any way.
Out of curiosity, where does it say that in "Inside Macintosh"? I have searched my PDF copy of volumes I-III and the only reference to a "Hard disk driver" is in reference to the soft-loaded ROM used in the *Macintosh XL* (Aka, the factory Hax0r-ed Lisa), not the "real" 64k ROM in the 128/512k. The Widget connected via an 8 bit parallel port rather than a crazy Rube-Goldberg floppy-UART nightmare thus I'd expect that any similarity between it and the HD-20 on a low-level driver level would be completely coincidental... although I do slightly wonder if the HD-20 software driver reuses the "Hard Disk" device identifier defined for the Macintosh XL Profile/Widget driver when it's loaded. (Apple says in the "writing device drivers" section never to reuse an identifier, but software companies that write the OS regularly break their own rules.)
I really hate to be a skeptical buzzkill, but a number of people have promised at various times to build mass-storage devices to work on the original Mac, and it seems like they lose focus or get in over their heads pretty rapidly.
As I've unfortunately bad-tempered-ly expounded on before the problem with all these schemes people have is that no one seems to actually want to glue their butt to a chair, read *all* the relevant sections of "Inside Macintosh" over and over again until they understand it, and fire up a compiler/assembler capable of producing "period-suitable" balls of code to write a device driver capable of emulating a hard-disk-ish like device through, say, a null-modem cable before running off and playing with the TinkerToys. Sure, disassembling the ROM containing the Z8 code might shed light on a few questions, like explaining in more detail how exactly Apple managed to use the IWM as a UART, and if you *really* want to try reverse-engineering the proprietary Rodime hard-drive connector instead of the IWM interface delving into it might reveal some details on how command flags were sent to the drive and how data was serialized/deserialized. However, well... if you think you're up to groking a disassembler listing *why not read a disassembly of the HD-20 driver*? It just took me all of five minutes to get semi-commented disassemblies of the Mac 128k and Plus ROMs thanks to this pre-assembled kit of tools, so getting that code is a lot less work than actually tearing something apart.
(Of course, I am not a 68000 assembly programmer, and the driver is mixed in with, well, the entire contents of the Mac ROM but... it does appear based on my ignorant reading that the ".sony" floppy driver in the Plus has been extensively modified to support the HD-20 based on a comparison of the 64k ROM. If someone knowledgeable were to spend the time grokking this information they could probably determine exactly how the driver twiddles the bits on the IWM to figure out if an HD-20 is present and how data is transferred to it. Disassembling the stand-alone HD-20 init might also help. My guess is that the INIT probably just replaces the whole of the 64k's .sony driver with one similar to the Plus-es, but even if that's the case it would point out exactly what needs to be patched to replace the floppy driver and add HFS support.
Oh, and BTW, since this has come up in other discussions about making some mass-storage widget that would fit internally via the 68000 socket a disassembly should to answer the question of whether the ROM is extensible. I don't know about *general-case* extensibility, but one of the first things the Mac does on power-up is check a certain memory location to see if it contains a signature indicating "test software", and if so it jumps to an address... it's on the first page of the assembly listing. I would hazard a guess that devices like the Hyperdrive leveraged that hook to hijack the startup process unless finer-grained overrides exist within the individual initialization/boot code blocks.)
Anyway, good luck with your endeavors to be sure, but my position at this point is unless someone were willing to actually spend the time learning how a mass storage device for the Mac *works*, interface details aside, before jumping in they're seriously putting the cart before the horse. You can spend as many man hours as you like logging and oscilloscope-ing the interface to your heart's content, but unless you understand *what it's doing* before you try to figure out how it does it you'll be muddling around in the dark. It seems to me that the entire thought process behind these endeavors is that it's *impossible* for anyone to understand the Mac well enough to write a device driver for it and it would somehow be easier to reverse-engineer some antique and undocumented mass storage device perfectly enough that an existing driver could "just work" with your new hardware. "Wham, bam, thank you Ma'am, I just made myself a flash drive for my 64K ROM Mac without ever having to touch or understand 68k assembly or the Mac system software! Yay, that was easy!"
Color me unconvinced. If the HD-20 wasn't such a "black box" I'd consider it doable, but if the plan is to just haphazardly diddle with it and try to see a pattern in the bits without having the slightest idea what to expect I definitely wouldn't hold my breath waiting for success.
I understand your mentality Gorgonops. It's very hard to say how complicated this thing is. We have several tools at our disposal:
- A ROM dump that can be disassembled fairly easily (small in size, performs a dedicated task, simple CPU, much less complicated than a Mac ROM)
- Existing documentation of floppy drives
- Observable signals
- Very very old and presumably not way too complicated
Any of these things may be impossible to use on their own, but combining them and observing correlations is basically what needs to be done. There could be things that we don't understand, for example spin-up procedures and diagnostics, but by simply replicating what we see and telling the Mac what it wants to hear, we can make the Mac think the drive is okay and proceed as normal. This is what I was referring to with the black box. There will be a lot of details that WILL need to be figured out to make any sense of the commands and data.
I feel pretty good about it. I don't promise an immediate solution, but we will definitely make significant progress. There are things that I know that I can do with this drive that haven't been done yet.
The guy who just sold me an HD 20 has another cheap one for sale if anyone's interested, and apparently it works:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=170572138162
I sort of have to take issue with that statement, because you're making the assumption that something "old" and "simple" won't be "complicated". Minimal and "elegant" hardware designs are often some of the *hardest* to wrap your mind around because they offload much of their complexity into the software driver, leaving the hardware as a minimal pile of gates and latches that completely depends on split-second timing and oddball encodings.
I'd also say that looking at a disassembly of the Z8 *may* be less informative than you'd actually like... don't get me wrong, it will undoubtedly provide some insight about how the floppy interface works, but... the thing to keep in mind is it's perfectly possible that the HD-20 itself is a relatively "dumb" device, with the Z8 essentially fully occupied driving the IWM and arbitrating communication with the Mac, while commands actually targeted to the drive mechanism and its associated controller might just pass fairly transparently through it. (IE, the Z8 gets a data byte off the wire and all it does is decode it and based on a header either shoves it into the HD controller as a "step head" command or whatever or shoves the data into the read-write buffer to await a "flush" command.) If that's the case then a disassembly will tell you a lot less about what sort of responses the Mac will be waiting for from it then decoding the Mac driver will.
(Or it may be a very intelligent device and a disassembly will reveal all. Just don't make any assumptions, here.)
Again, I wish you luck, but I also caution that if you intend to follow through with this it behooves you to learn as *much about the high-level operation of this thing as you can*. I could be completely wrong, but it sort of strikes me at times that you're a little fuzzy about what you should expect to see out the floppy port when it's speaking to a floppy drive, let alone how it might go about encapsulating data for the HD-20.
I hate to bring this up again, since people seem allergic to admitting that it *is* possible to write low-level storage drivers for the Mac, but... Basilisk II has ROM patches that replace the .sony driver. And, from sony.cpp:
Code:
* SEE ALSO
* Inside Macintosh: Devices, chapter 1 "Device Manager"
* Technote DV 05: "Drive Queue Elements"
* Technote DV 07: "Forcing Floppy Disk Size to be Either 400K or 800K"
* Technote DV 17: "Sony Driver: What Your Sony Drives For You"
* Technote DV 23: "Driver Education"
* Technote FL 24: "Don't Look at ioPosOffset for Devices"That means at some point during initialization *a high-level call is made to the HD-20 requesting an icon bitmap*. There's something you could focus on. If you can find that icon in the HD-20's ROM and figure out what is sent to trigger the drive to spit it out that could crack a good portion of how the command interface works in one blow...
But, eh, that's just how I might do it if I cared enough. If you want to bootstrap it up from bare bits go for it.
From everything I can tell, the page of calls that you linked to are operating system calls. Generic disk icons are stored in the System File, not in a disk drive's hardware, or on each disk! It even mentions that control calls are "opcodes" which seems to refer to A-Line traps, which are strictly 68k OS calls. These would not be passed directly to any hardware. That is the purpose of Mac OS and the Sony driver, to reside in the Mac, use the Mac's processor and memory, receive these OS calls, and finally the sony driver sends low-level controls to the IWM. The IWM then does the appropriate hardware logical functions to disk drives. These are things like stepping the head, writing data, reading data, spinning the disk, checking the write-protect switch, etc. Disk drives are really really stupid, basically more analog than digital.
I appreciate your perspective and your constructive criticism. Because the HD 20 must cleverly use the signals from an IWM, and we know a bit about IWM, this is where my confidence comes from.
I appreciate your perspective and your constructive criticism. Because the HD 20 must cleverly use the signals from an IWM, and we know a bit about IWM, this is where my confidence comes from.
Oooo I see what you mean now:
That's one of those things that can be figured out by disassembling the HD20's ROM or by just replicating the signals. Whatever command it sends to fetch the icon, followed by a return of the icon data, we don't necessarily even need to know what's happening to pipe it right back through. It could have been resolved with the black box sort of thing. It's very good to be aware of that sort of thing though.
That could be tricky.
That's one of those things that can be figured out by disassembling the HD20's ROM or by just replicating the signals. Whatever command it sends to fetch the icon, followed by a return of the icon data, we don't necessarily even need to know what's happening to pipe it right back through. It could have been resolved with the black box sort of thing. It's very good to be aware of that sort of thing though.
I was about to post a snippy response to this, but I think you've figured out that I wasn't talking out of my arse. ;^b Much of the Mac's OS *is* in the ROM.. and if you look through a Mac Plus ROM disassembly I think you can actually see where the generic "Mac Floppy" icon is stored. (It's near the end of the block of code under the "P_Sony_RdData:" heading, and I suspect one of the unnamed subroutines within that section is what responds to the documented "Return Physical Drive Icon" system call. Only "known", IE, reverse engineered by the author of vMac for the most part, sections of the code are actually denoted with human-readable labels.)
Anyway, the technote document points to there being some routine buried in there that says "Hello Mr. HD-20, please send me a pretty picture, kthxbye!", and all I was doing was suggesting that it *seems* like an example of a code path that might be relatively easy to find on both ends and which would enlighten how the IWM-as-a-UART things works in a vacuum without the complication of tracing a transfer of real data or looking for hard drive control codes which may not be obvious from a dissection of the Z8 code. (A lot of that depends on how "intelligent" the Rodime drive/host controller combo really is. We just don't know that definitively. The drive has its own Z8 on it after all, and the operating description in the patent application may not cover everything, particularly the possibility that the drive might have some Apple-specific firmware on it.) There may be other tidbits like that scattered around, just waiting to be found....
Which of course, the point I was really trying to make. There's a lot to be learned by reading all the documentation you can find for clues before just diving in. If you really want to tackle this from a low level "Disk drives are really really stupid, basically more analog than digital" (your words) point of view I'd honestly strongly suggest not starting with the HD-20 and instead concentrating on replicating a 400/800k floppy drive. Those *are* (mostly) dumb devices. The HD-20 is not, so starting straight with it leaves you having to figure out both the subtleties of the physical interface (IE, voltage levels, peak-to-peak variances, how to extract syncing/clocking information, how to convert the GCR nibble-encoding back into bytes, etc, etc.) *and* trying to reverse-engineer the high-level commands sent over that interface. (Another hint from that technote suggests that the HD-20 *may* be fairly "smart". The section about "formatting" suggests that the HD-20 uses linear addressing for its 38-thousand-something sectors rather than accepting explicit head/cylinder commands, for instance. It wouldn't surprise me if from a high level it ends up looking fairly SCSI-ish.) What you seem to be planning comes across as being akin to trying to learn how to read and write fancily-formatted ANSI text to/from terminal at the same time you're trying to reverse-engineer the modem it's connected via by tapping the tones on the phone line. If that's where you're starting it might behoove you to concentrate on making the modem first, and only after you have it reliably converting white noise to a serial bitstream *then* you can try sniffing the terminal protocols. (And even then you still might want to look up as much data as you can... starting at *least* with an ASCII chart?)
(I'd also suggest it might be a good idea to state straight-out which interface it is you're trying to crack here. Is it the Rodime interface or the HD-20 floppy interface you're after? If it's the former, forget everything I've said. Read the patent document, hope it's correct, hope there's enough high-level code in the HD-20 Z8 to grok out what commands it responds to, and hope that the ASIC-thing that makes up the host controller isn't particularly intelligent. Everything I'd suggested is with reference to making a device which can emulate an entire HD-20 via the floppy interface. Emulating the Rodime might actually be "easier" electrically, but you're totally on your own when it comes to docs. Which... may be what you want?)
Anyway, just saying that learning to walk before trying to learn to fly might not be a terrible idea. But I'll admit I don't have any formal education in electronics and I'm all thumbs with a soldering iron so perhaps I have *completely* the wrong idea, and with a dead HD-20 in hand it might *totally* be as easy as pie to reverse engineer the whole shebang at once. Keep everyone posted and all.
I was not referring to the thread. Most threads on the Compact Mac forum are interesting, hence why I read/post most often here.
Interesting. One would figure with age/degradation of the floppies they would become more rare as most are rendered useless.
Wasn't trying to go in that direction. I realize how irritating it can be when someone posts something as "rare" online when it fact it is not. Regardless of this "inconsistency," collectors still go bananas on eBay.
I honestly do not understand why people get so worked up on this forum. I'm a member of several similar sites and they are able to keep everything polite, but here you get a smack across the chops for even mentioning something. Come on, let's try to help, not upset. We all have a common goal, and that is an interest in older computers, especially those made by Apple.
I agree, but all in all, the "Compact Mac" forum here is definitely my favourite! This thread in particular has drawn out more information than I could have imagined, unfortunately not what I was after when I started this thread, but very education none the less.
If anything comes of it, great! If not, it has been enjoyable, and thanks!
I'm interested in the Compact Macs because of the impact they had on me when they appeared on the scene bay in '84, even though I stayed with the Apple2 camp for the programming that I was doing after university. I have little to no interest in the desktop Macs that came after the SE, until the arrival of the iMac of '98. I regret that I don't have any skills to offer in the endeavor to get the HD20 nutted out, but I'll support the process (project?) in whatever other ways that I can.
So everybody, let's keep the discussion strong and fruitful, and enjoy the ride.
Michael
If anything comes of it, great! If not, it has been enjoyable, and thanks!
I'm interested in the Compact Macs because of the impact they had on me when they appeared on the scene bay in '84, even though I stayed with the Apple2 camp for the programming that I was doing after university. I have little to no interest in the desktop Macs that came after the SE, until the arrival of the iMac of '98. I regret that I don't have any skills to offer in the endeavor to get the HD20 nutted out, but I'll support the process (project?) in whatever other ways that I can.
So everybody, let's keep the discussion strong and fruitful, and enjoy the ride.
Michael
Well, I'm not going to be discouraged. I'll do what I can with the knowledge I have and we'll just go from there. There are other engineers among us to help where I fall short.
I'm not upset, JS, or worked up. I just replied to a thread. No vulgarity, nothing. Can't I speak anymore? :-/
Although the Amigas during the early-Mac era were far more superior (OK, now bash me for turning to the Dark Side).
Definitely the best forum for my interests. I love when people just want to help and pass on their knowledge, and hate it when a handful of people react negatively to everything and expect us to all be experts. We are here to learn from those who know, everyone has to start from somewhere.
Nothing personal Concorde, I just keep seeing negativity and the like, which detracts a little from what is a great website. Now just felt like the time to bring it up, so don't read into it too much.
It must be the effect of the silicon fumes rising from our Macs. :beige:
Or maybe the site is full of crotchety old Apple engineers who are sick of telling the youngins' how to fix a computer.
Don't forget us wannabe old Apple engineers, we demand the right to be crotchety as well :-/