Thread
SCSI for the 512K (or 128?)
JDW raised an interesting point in the HD20 thread.
Using the John Bass design, which presumably uses obsolete technology, a new MacSCSI card might evolve. Using a commercial SCSI<-->CF interface in conjunction with a homebrew SCSI board, a low power solution would be possible. The MacSCSI design has known limitations, however, so I incline towards cloning one of the third party boards which are more reliable/compatible.
A MacIDE card makes sense too; IDE <-->CF interfacing is trivial, and the John Bass code should give a few clues about connecting to a Mac LB. Hats off to the Apple II IDE/CF adapter crew.
The important thing to remember is that there were SCSI interfaces for compact Macs with 64KB ROMs. Do a search in Google groups for "John Bass", MacSCSI, Fastimes. Or just browse through net.micros.mac. MacSCSI was a free SCSI interface with design information published in Dr Dobb's Journal. On the commercial side, a few SCSI card manufacturers made designs that worked with 64KB as well as 128KB ROMs. So homebrew cards inside a compact Mac are not a ridiculous idea.
Using the John Bass design, which presumably uses obsolete technology, a new MacSCSI card might evolve. Using a commercial SCSI<-->CF interface in conjunction with a homebrew SCSI board, a low power solution would be possible. The MacSCSI design has known limitations, however, so I incline towards cloning one of the third party boards which are more reliable/compatible.
A MacIDE card makes sense too; IDE <-->CF interfacing is trivial, and the John Bass code should give a few clues about connecting to a Mac LB. Hats off to the Apple II IDE/CF adapter crew.
This is amazing. So the SCSI adapters for the 64K ROMs would have had to have the SCSI code encoded on an external chip. Or, at least a software driver to take advantage of any internal circuitry added (in which case the 128K probably couldn't load it), like the HD-20 so it couldn't be a boot disk? The Dove MacSnap doesn't need any software, so it relies on the 128K ROMs to drive the new circuity and theoretically could boot from a SCSI device?
I'd love to get my hands on one of those 64K ROM SCSI cards.
I'd love to get my hands on one of those 64K ROM SCSI cards.
Here's a thought. Would it be possible to use the HD20 model for SCSI implementation on 64K ROMs?
The HD20 cannot be used as a startup disk, but can take over once started up with a floppy containing the 128K ROM HFS & disk drivers code loaded into RAM.
Since the MacPlus 128K ROM uses a similar sequence during startup, i.e. looking for drives during startup, couldn't an HD20-like INIT be written that patched the 128K ROM code into the 64K ROM as loaded into RAM, thus making the 64K ROM aware of the SCSI bus? Then one could theoretically use something like the MacSnap SCSI adapter with the original 64K ROMs. After loading from a floppy disk, the Mac would continue scanning for a SCSI bus and mount any drive it finds, the SCSI drive system taking control and ejecting the startup disk like the HD20.
I would be perfectly happy with such an arrangement. Then I could use a Zip drive with my stock 512K.
I actually wonder now how much of the 128K code is loaded into RAM using the HD20 INIT. Is there any possibility that 100% of the additional 64K code is loaded into RAM so that a 512K could actually recognize a SCSI bus if physically attached? Could Apple's engineers have actually been contemplating a SCSI upgrade for the 512K before deciding to go with the whole rear-bucket/logicboard replacement option they ultimately offered and included the remainder of the 128K ROM code in the HD20 INIT? I mean MacSnap's solution was indeed elegant (without changing any of the functionality of the existing case) and with Jobs gone, it would have been an easy and profitable task for dealers and Apple to implement a similar solution.
Though never intended, the HD20 INIT allowed a 512K to use an 800K drive months before they were released for the Mac. Again, something Apple included in the code, but didn't advertise, preferring instead to sell the 800K drive upgrade kits with the new ROMs.
The HD20 cannot be used as a startup disk, but can take over once started up with a floppy containing the 128K ROM HFS & disk drivers code loaded into RAM.
Since the MacPlus 128K ROM uses a similar sequence during startup, i.e. looking for drives during startup, couldn't an HD20-like INIT be written that patched the 128K ROM code into the 64K ROM as loaded into RAM, thus making the 64K ROM aware of the SCSI bus? Then one could theoretically use something like the MacSnap SCSI adapter with the original 64K ROMs. After loading from a floppy disk, the Mac would continue scanning for a SCSI bus and mount any drive it finds, the SCSI drive system taking control and ejecting the startup disk like the HD20.
I would be perfectly happy with such an arrangement. Then I could use a Zip drive with my stock 512K.
I actually wonder now how much of the 128K code is loaded into RAM using the HD20 INIT. Is there any possibility that 100% of the additional 64K code is loaded into RAM so that a 512K could actually recognize a SCSI bus if physically attached? Could Apple's engineers have actually been contemplating a SCSI upgrade for the 512K before deciding to go with the whole rear-bucket/logicboard replacement option they ultimately offered and included the remainder of the 128K ROM code in the HD20 INIT? I mean MacSnap's solution was indeed elegant (without changing any of the functionality of the existing case) and with Jobs gone, it would have been an easy and profitable task for dealers and Apple to implement a similar solution.
Though never intended, the HD20 INIT allowed a 512K to use an 800K drive months before they were released for the Mac. Again, something Apple included in the code, but didn't advertise, preferring instead to sell the 800K drive upgrade kits with the new ROMs.
It's hard to say how much of the 128k ROM was loaded into RAM with the HD20 Int. As crazy as it sounds, I think some of the 128K ROM loaded into RAM on any machine the had it. Many years ago, I had 3 Mac 128k's. One of them was a Mac 128ke! Some previous owner had installed the 128K ROM and 800k Floppy drive upgrade from Apple. This baby still only had 128k of RAM, but could boot the HD20. However....it was very flaky with some apps that ran perfectly fine on my other stock 128k's but crashed on the 128ke. I read somewhere that Mac 128ke's had problems, because the larger ROM loaded some info into RAM, and cut down on available memory to applications. I know that doesn't make sense on the surface, but from what I've personally witnessed, it fits.
When I search for '"John Bass", MacSCSI, Fastimes' in Google, I get one result -- a link to your post in this thread!
When I type "net.micros.mac" in my Safari address bar, I get a server not found error. Please explain.
Don't I know it. And as I posted here, I would certainly appreciate a kind soul in the US to take a stroll through the periodicals section of their local library for us. If I was back in California, I would do it in a heartbeat. But sadly, I just don't have access to old magazines like that here in Japan.
As would I. I don't mind at all using the HD20 INIT with my 64k ROM 512. And I would absolutely love the options SCSI would open up.
So again, I beg you people, please, someone visit your local library for the good of the classic Mac community. I can't imagine that no one on this site has a library card!
The crashing could simply be a result of your running apps that are inherently incompatible with the 128k ROMs. Indeed, that is one reason I still wish to retain the 64k ROMs in my 512.
I would love to read the article that you claim to have read about the ROM being loaded into RAM. Would you mind posting a link to that, or could you PM me so you can send me a scan of the paper article?
I easily searched for every permutation surrounding Charlieman's keywords (as well as some of my own) and think I found all of the information about John Bass & his miraculous SCSI device there is on the net. Nevertheless there was not that much. The net.micros.net forum is probably the best source I found. Odd that Google, one of the biggest search engines in the world, would not discover its own archived forum with the main part of the title as a keyword. http://groups.google.com/group/net.micro.mac/ – actually it looks like a typo on Charlieman's fault. ;-) Once there, you should take the extra effort to search for specific keywords which will produce more intriguing nuggets.
You are aware Dr. Dobbs Journal is still being published and online? It looks like you will need as wellSeptember, October and December issues. Aoresteen said he would be returning home in July, so in the event you want to wait to see what he turns up in his private collection, it won't be long now.
I must admit, it is a fascinating prospect, however, as Charlieman has pointed out, even if the schematics for constructing such an interface exist and are within my abilities to construct, it will need the SCSI driver code necessary for use with it and may only be compatible with one version of Apple's system software since Apple was making broad changes to the code between each release as some of the other articles indicate. His publication is definitely odd timing. It coincides with the release of System 2.1/Finder 5.0 but he most certainly developed it around 2.0/4.1. It only preceded the Mac implementation by 4 months and the old MFS code made obsolete by the simultaneous introduction of HFS with the HD20.
In particular this is fascinating update as it highlights some very real programming problems with respect to individual drives as well as potential System/driver conflicts.
I am sure he actually did read something to this effect as I have seen references to it myself. However, Apple seems to directly contradict this. http://docs.info.apple.com/article.html?artnum=1990
As I mentioned elsewhere, the 128K aware System files do include 128K ROM redundant code to compensate for 64K ROM System file code which had been added to the 128K ROM code, so theoretically as far as 64K ROMs are concerned, nothing has changed except the size of the System file. So unless Apple is wrong (as they so often are) and I think the specificity of this answer makes that unlikely, this is an urban-legend variety misconception.
The library where I work has the Dr Dobbs journal that JDW seeks, but when JDW and I discussed getting hold of a copy, the library looked something like this. Dr Dobbs was (and probably still is) in storage so it wasn't a good time to get hold of a copy. Possible but not convenient.
BTW the empty tables in the photo above are now populated with some nifty PCs. They run XP, alas, and are pretty ugly (the library development team initially requested an even uglier design), but they will be easy to maintain for several years.
The library now looks less like this and opened for service at the beginning of this month. Thus I am more than happy to get hold of the Dr Dobbs copies.
BTW the empty tables in the photo above are now populated with some nifty PCs. They run XP, alas, and are pretty ugly (the library development team initially requested an even uglier design), but they will be easy to maintain for several years.
The library now looks less like this and opened for service at the beginning of this month. Thus I am more than happy to get hold of the Dr Dobbs copies.
Charlieman, whenever you do get a chance, I'd love to review a copy of that Dr. Dobbs magazine article!
Mac128, thank you for the links. The posting from 1986 indicates that the original MacSCSI driver code from John Bass didn't support HFS. If it did, I don't see why Lance K. would have needed to hack/modify the driver as he did.
The 1985 post by John Bass reveals very clearly that it is a true SCSI implementation for the original 64k ROMs (since it mentions that it won't work with the newer 128k ROMs). Bass also mentions that the software driver available at the time of that posting only supported one particular SCSI drive, which he mentions in his post. But Bass then talks about a newer version of the software that would soon become available, supporting other SCSI drives (that were widely sold in that day). So even if one of us was able to acquire that newer driver software, it is highly unlikely that it would work with more modern SCSI drives that came out in subsequent years -- perhaps the only SCSI drives we will be able to find now days.
Since Bass also mentions a schedule to build 50 Fastime MacSCSI units in October 1985, that means some of those units may be out there somewhere. I've never seen one pop up on EBAY though. However, many sellers on EBAY don't often know what they're selling either.
Mac128, thank you for the links. The posting from 1986 indicates that the original MacSCSI driver code from John Bass didn't support HFS. If it did, I don't see why Lance K. would have needed to hack/modify the driver as he did.
The 1985 post by John Bass reveals very clearly that it is a true SCSI implementation for the original 64k ROMs (since it mentions that it won't work with the newer 128k ROMs). Bass also mentions that the software driver available at the time of that posting only supported one particular SCSI drive, which he mentions in his post. But Bass then talks about a newer version of the software that would soon become available, supporting other SCSI drives (that were widely sold in that day). So even if one of us was able to acquire that newer driver software, it is highly unlikely that it would work with more modern SCSI drives that came out in subsequent years -- perhaps the only SCSI drives we will be able to find now days.
Since Bass also mentions a schedule to build 50 Fastime MacSCSI units in October 1985, that means some of those units may be out there somewhere. I've never seen one pop up on EBAY though. However, many sellers on EBAY don't often know what they're selling either.
Ran across this again and thought I would bring it to the discussions. As much as I would love a SCSI solution for use with 64K ROMs, a solution like this would be both welcome and authentic:
http://www.dcresource.com/FlashPath/index.html
Imagine if this device initially loads 400K MFS disk header and boot info, then loads its own driver from the 400K partition to access the rest of the disk. All using the original 400K drive head keeping the machine 100% authentic while using the latest media. I can dream can't I?
http://www.dcresource.com/FlashPath/index.html
Imagine if this device initially loads 400K MFS disk header and boot info, then loads its own driver from the 400K partition to access the rest of the disk. All using the original 400K drive head keeping the machine 100% authentic while using the latest media. I can dream can't I?
I too think FlashPath would be a nifty idea, although not as fast as the "HyperDrive-Flash" that I've long dreamed of (the HyperDrive concept, but based on a flash drive). Since HyperDrive is wired to the CPU, that would theoretically be the fastest implementation. SCSI would be next, followed by FlashPath.
But I also dream of someone other than myself on this site switch on his or her Mac512 (with 64k ROMs) and testing along side me. But alas, it appears that I too must continue dreaming!
But I also dream of someone other than myself on this site switch on his or her Mac512 (with 64k ROMs) and testing along side me. But alas, it appears that I too must continue dreaming!
I don't think that was the case. Those apps ran fine in a Mac Plus with the 128k ROM.
I read that years ago. Sorry, I don't remember where I found it, but it rings true based on my experience!
I collected my photocopy of the John Bass SCSI article from Dr Dobbs this evening. I only had a quick look at it to confirm that they copied the right thing.
The copyright form that I signed said "for personal research" but John Bass deliberately published it as public domain, so I'll make sure that the usual suspects get copies. I would strongly advise against getting too worked up about the design. Later issues of Dr Dobbs included corrections to the ROM code for the SCSI card (which I can't yet obtain for practical reasons), so I recommend that we see the final design before trying to build one.
The copyright form that I signed said "for personal research" but John Bass deliberately published it as public domain, so I'll make sure that the usual suspects get copies. I would strongly advise against getting too worked up about the design. Later issues of Dr Dobbs included corrections to the ROM code for the SCSI card (which I can't yet obtain for practical reasons), so I recommend that we see the final design before trying to build one.
I've got a Sony version of that FlashPath adapter. As I remember, it needed drivers to be used in a 6100. Could be wrong. When it re-emerges from the pile, I'll give it another go. It requires two watch cells to work.
Also:
Also:
How much documentation is available about the HD20 interface itself? Would it be possible to construct a device that plugs directly into the HD20 port, mounts a flash card, and contains a microcontroller for protocol translation? Such that the original HD20 inits are useable.
From Apple, zilch. From other threads over here, we have had some excellent info on how the Rodime mechanism in an HD20 works.
Hmm, interesting, but a different tack to what I'm talking about ...
... which is throwing aside the whole HD20 drive, and plugging a microcontroller into the HD20 port on the back of the Mac. The micro then pretending to be an HD20 drive, when really it's a flash card reader.
Although I can see that the Hyperdrive processor-direct approach would be the optimal one, that looks like a fair chunk of development.
Serial port?
... which is throwing aside the whole HD20 drive, and plugging a microcontroller into the HD20 port on the back of the Mac. The micro then pretending to be an HD20 drive, when really it's a flash card reader.
Although I can see that the Hyperdrive processor-direct approach would be the optimal one, that looks like a fair chunk of development.
Serial port?
I've starteda new thread specifically posting the public domain John Bass article's from Dr. Dobb's Journal which detail both the hardware to build a SCSI adapter for the 64K ROMs as well as the software drivers:
viewtopic.php?f=7&t=9800
I had intended to go back and edit my title and entry to better reflect this thread as well as add a link to this thread as well. Unfortunately new forum rules no longer allow edits. Therefore, I've updated this thread to better help connect them should anyone perform a search or come across this thread first.
viewtopic.php?f=7&t=9800
I had intended to go back and edit my title and entry to better reflect this thread as well as add a link to this thread as well. Unfortunately new forum rules no longer allow edits. Therefore, I've updated this thread to better help connect them should anyone perform a search or come across this thread first.
I wouldn't say that article contridicts my statement. I would say it confirms it. 1.5K lost may not seem like much on a Mac 512K, but on a RAM strapped 128K, it could make the difference between an application working or not. :beige:
isnt the hd20 port the same smartport thing on apple //c and GS, if so it might be half solved as some dude on the apple II group had a smartport jacked into a lpt port on a pc and accessing virtual prodos volumes that way
I wouldn't get too excited about John Bass's SCSI code. He talked and wrote about a lot of things he never actually did. I bought a copy of his driver and built one of the Dr. Dobbs interfaces and never was able to get it to work. I found that Micah was developing a commercial internal SCSI drive for the 512K and Beck-Tech 1 MB upgrades, so I worked with them. Steve Brecher wrote Micah's ROM driver, and it worked pretty well, though Apple pulled the rug out with one system update. Unfortunately, Micah's ROMs only work with the hardware they used, an OMTI 3120 SCSI-to-MFM interface, and a 20MB MFM disk drive. Steve owned the source code, since Micah's financial backer didn't see any need to buy anything other than a license to the object code, so nobody has access to source to modify or learn from it.
There is a very simple source of SCSI boot ROMs. The Apple 128K ROMs. They work. They are compatible with a number of 3rd party SCSI upgrades. They are compatible with most Systems and Finders. They will boot a lot of SCSI drives, but not all. They are genuine Apple. They are readily available from dead Mac Plusses. But I know somehow it's "non-original" to put 128K ROMs in a 512K, but it IS "original" to add somebody else's hacked ROMs. A distinction I find difficult.
That said, if I were attaching a flash drive to a 512K or a Plus, I think I'd look at making an IDE interface that plugs into the Mac's ROM sockets the way Bass's SCSI adapter did. Then I'd need to write a driver for it, which would be easier than writing a SCSI driver AND a driver for a SCSI-IDE adapter. The driver could either be on a floppy, or it could be in ROMs to make the flash drive bootable. That would be cool. And low power cool, too.
There is a very simple source of SCSI boot ROMs. The Apple 128K ROMs. They work. They are compatible with a number of 3rd party SCSI upgrades. They are compatible with most Systems and Finders. They will boot a lot of SCSI drives, but not all. They are genuine Apple. They are readily available from dead Mac Plusses. But I know somehow it's "non-original" to put 128K ROMs in a 512K, but it IS "original" to add somebody else's hacked ROMs. A distinction I find difficult.
That said, if I were attaching a flash drive to a 512K or a Plus, I think I'd look at making an IDE interface that plugs into the Mac's ROM sockets the way Bass's SCSI adapter did. Then I'd need to write a driver for it, which would be easier than writing a SCSI driver AND a driver for a SCSI-IDE adapter. The driver could either be on a floppy, or it could be in ROMs to make the flash drive bootable. That would be cool. And low power cool, too.
Personally, I'm not particularly interested in booting a 128K or 512K from a hard drive. I'm more interested in the expanded storage options it affords, to cut down on disk swaps. I feel like if you're gonna run an original 1984/85 Mac, booting off a floppy is mandatory. I actually kind of like the hand off startup floppy that automatically switches over to the hard drive and then ejects itself. Very elegant, and for me part of the experience. A flash drive that tapped into the ROM would be amazing!
Ditto Mac128's sentiments.
This is where looking at the Outbound Model 125 might come in handy. It used Mac Plus (or SE) ROMs and had an IDE hard drive and there was no SCSI to IDE conversion going on. It does have an on-board EEPROM which contains a bit of extra boot code from Outbound. I wish we could get the source...That said, if I were attaching a flash drive to a 512K or a Plus, I think I'd look at making an IDE interface that plugs into the Mac's ROM sockets the way Bass's SCSI adapter did. Then I'd need to write a driver for it, which would be easier than writing a SCSI driver AND a driver for a SCSI-IDE adapter. The driver could either be on a floppy, or it could be in ROMs to make the flash drive bootable. That would be cool. And low power cool, too.
Anyone know what ever happened to Mike Duffy or Doug Swartz. Of course, even if we could find them, there's a good chance they didn't keep the old code around. Sigh. I would really like the code for the GALs in the floppy and SCSI adapter boxes too...
Isn't *all* the floppy swapping "part of the experience"? If you're looking for an authentic pure-to-Apple's-"vision" early Mac experience that involves a hard drive the only legitimate answers are to use an HD-20 or upgrade to a Plus. ;^b
(It seems to me a schizophrenic set of desires to want to keep the 64k ROMs for "authenticity" yet still want some sort of authenticity-destroying internal hardware add-on to get non-Apple-sanctioned functionality on the system. Isn't that a bit like a car collector *insisting* that their 1908 Model T retain the planetary gearset transmission, wet clutch, starter crank, and all original suspension and brake parts while at the same time scheming on ways to transplant a Chevy V8 engine into it? Besides the obvious technical issues, well... if you want the "authentic" Model T experience you're stuck using it stock, or possibly with period upgrades that preserve the essential factory layout of the car *only*. Anything else puts you in the same category as people who make "T-Bucket" Rat Rods, and at least the people who make those usually have the good sense to upgrade the auxiliary components to units rated to handle the power they've added to the car.)
That snipe aside it seems to me there's zero-hardware solutions to this if someone gets off their rear and fires up the C compiler. John Bass' "vaunted" SCSI code was a hack on example code for a RAMdisk included with his C compiler. He said so in his article. The original Mac has two serial ports, so why not just likewise hack a RAMdisk driver to use one of them to speak to "server" software that dishes up disk images from a modern machine? (A UNIX box, or a Macbook with a USB serial adapter. Was it Porter who said in some earlier post that he'd written just such a driver to use the floppy drive on his DOS machine for Macintosh storage years and years ago?) Using disk images over serial would be "slow", but everything's slow on a Mac 128k, and such a thing could be considered "historically correct". (Serial hard drives like the Tecmar MacDrive did exist for the early Macs.)
If it's acceptable to use an HD-20-esque method of storing the driver on a pre-boot floppy then the hardware hardly matters. Write the driver first for a serial port connected to another computer (the server software would be trivial, and this time I say that meaning that even *I* could probably write the UNIX code for that). Once you have the bugs worked out of that you could instead target a dedicated hardware hack. A microcontroller sitting on a passthrough board snooping the address lines in a ROM slot, ala John Bass, Dove SCSI boards, etc, is an obvious thought. Practically every microcontroller on the market has example code for reading and writing SD cards over SPI in their code library. (Even a powerful one like the Parallax Propeller, which would allow you to write practically the entire program in a semi-high-level language, costs under $10 each. If you went into "mass production" with a printed circuit board you might be able to get a kit price down to under $50 for a printed circuit board and all the parts.)
People really get tunnel vision over thinking "building hardware" is what they need to do, but unless you intend to make a piece of hardware which perfectly emulates a device which is already supported out of the box (Which makes emulating HD-20 the *only* choice if you insist on keeping the 64k ROMs) you're doomed to accomplish *nothing* unless you're willing to get your hands dirty with some system-level programming.
(Well, okay, you could perfectly emulate something else like the Tecmar Macdrive if you had binary drivers for that handy, but to do that you'd need more technical information on it than is likely was every released to build your emulator, the same problem as the HD-20. Really, the only way to practically move forward is to accept the facts as they are and buckle down to write some software. If you don't love your 128K Macintosh enough to do that then why not just seal it in a glass case and be done with it? If no one's writing software for a computer platform then by definition it's "history". Time to move on.)
Why in the heck has nobody ever hacked the HD20 with a logic analyzer? It could not possibly be that complicated of a protocol, it is so unbelievably old.
This deeply confuses me. It seems so obvious and desirable, I do not understand why nobody has cracked it yet. Is there some technical reason that I'm not aware of? I'm sure we even have a pinout of the floppy port at our disposal. I have a Mac 512k and a couple plusses, if someone sells me a cheap HD20 I'd be happy to give it a good crack.
This deeply confuses me. It seems so obvious and desirable, I do not understand why nobody has cracked it yet. Is there some technical reason that I'm not aware of? I'm sure we even have a pinout of the floppy port at our disposal. I have a Mac 512k and a couple plusses, if someone sells me a cheap HD20 I'd be happy to give it a good crack.
The most obvious answer is that no one with the equipment and technical know-how is interested in elderly Macintoshes. Given the user base the machines were aimed at I'm somehow not surprised.
Well, I personally AM surprised in light of the fact that so many seem to have the equipment and technical know-how to get flash onto Apple's even older than Macs!!!!:
http://dreher.net/?s=projects/CFforAppleII&c=projects/CFforAppleII/main.php
http://www.reactivemicro.com/product_info.php?products_id=32
http://sites.google.com/site/idiskapple2/home
No doubt someone will try to argue, "Well, the Mac 128k and 512k didn't have SLOTS you see..." Ah come on! How much harder can it be? Honestly, "where there's a will there's a way" rings true in all this. For whatever reason, there are more Apple II enthusiasts who have that WILL and as a result have found a WAY.
The Apple II's architecture and available documentation allows for such things today, just as it did 30 years ago.
See, I knew it! Dogcow, your post falls into my previous post's statement, "No doubt someone will try to argue..." My mention of "slots" is your "architecture."
But the fact is that those flash drive solutions for the Apple II didn't appear on a magic tree. Someone had to make them, regardless of how "easy it is" versus doing so on the Mac. I stand by my previous post. Where there's a WILL there's a WAY.
But as Gorgonops so pointedly put it, no one has yet "gotten off their rear" and done it. But obviously, someone with programming experience would need to do so. (Someone like those who created those Apple II flash drive solutions.)
But the fact is that those flash drive solutions for the Apple II didn't appear on a magic tree. Someone had to make them, regardless of how "easy it is" versus doing so on the Mac. I stand by my previous post. Where there's a WILL there's a WAY.
But as Gorgonops so pointedly put it, no one has yet "gotten off their rear" and done it. But obviously, someone with programming experience would need to do so. (Someone like those who created those Apple II flash drive solutions.)
ugh
GET OFF YOUR REAR THEN since you seem so passionate about it
no excuses! where there is a will there is a way
I just love non technical people telling "us" that we for some reason need to get passionate about their cause, software people get it too
GET OFF YOUR REAR THEN since you seem so passionate about it
no excuses! where there is a will there is a way
I just love non technical people telling "us" that we for some reason need to get passionate about their cause, software people get it too
I cant program in C, so that rules out my ability to program on the mac. But i develop hardware and write the ASM that drives the hardware all the time. If i had a logic analyzer that would fit in my budget, i would have reversed the stuff long ago. But i dont, and i cant afford a working HD20. so thats kinda out of my way.
However i did pick up a book on the nubus architecture and how to devlope hardware/drivers for it, its an apple book. i read it but that sucker is the most complex buss ive seen. hehe. it aint no 8 bit. thats for sure, and thats the world i came from. 8-bit.
However i did pick up a book on the nubus architecture and how to devlope hardware/drivers for it, its an apple book. i read it but that sucker is the most complex buss ive seen. hehe. it aint no 8 bit. thats for sure, and thats the world i came from. 8-bit.
I recently made a LA out of a 40$ 80mhz pic32 protoboard and a printer cable that is plenty fast enough for the <8mhz cpu clock (it gets crappy around 10 mhz with 16 channels going over usb) ...
will = way
}
will = way
}
I stand amused that my post was provocative enough for you to post in this thread because now it partly has become your cause too.
But my intention was to be provocative enough to get a few people sufficiently steamed about this topic such that someone capable might come along and lay down the law. The people behind those Apple II flash gizmos clearly did just that. Someone pissed them off enough so they one day stood up and said, "Okay, here it is you selfish bastards. Now call me King." And of course, with product in hand everyone in the Apple II community likely did just that, not only with their words but with their cash as well. Whoever puts their WILL to work and finds a WAY deserves to be crowed King.
not even close
but it comes off as I want and I want someone to do it for me!
wow, just wow is that how it works in a community?
the communities that I involve myself with are more into helping each other, both computer and electronics, if all you want is someone to be king then good luck with that, cause nothing comes of it in the long run, as you already see in this topic, once king doesnt give a crap anymore they might as well not existed except for rumor leaving the community out in the dust
I dont bow to kings, kings are worthless, community is forever
here is a little hint, it takes 3 (ok not counting power and ground) wires to hook up a SD card in out and clock, the rest is totally software, find 3 addressable lines in the mac and write a driver, bam done
Folks, there you have it. A recipe so simple that everyone in our "community" merely overlooked it. Thank you for your help, Osgeld.
For the record I only suggested a microcontroller because of the easy availability of SPI and msdos filesystem driver code could much simplify the task if the goal was to parse emulator images on "normally formatted" cards. But, yes, you can bitbang an SD card and read and write raw sectors with practically no hardware. One ic piggybacked onto the mac motherboard would do you. It just makes the mac software no one wants to write a little harder. Certainly still very doable.
ayep, so round and round we go (though you can bitbang file systems too, just increase the level of complexity on your software end)
Certainly. Of course, if you don't care about using emulator images directly by dragging and dropping them on the card parsing msdos filesystems in the macos driver is a pointless complication. Just treat it as a big pile of sectors and use "dd" to copy filesystems onto the card. Limits you to one volume per card unless you choose to support hard disk volume lables or some similar offset scheme but who cares. Keep it as easy-peasy as possible for version one and improve it later. Or don't start at all because it's still too hard, whatever works.
I don't believe Apple ever expressly forbid developers from offering any hardware solution for the Early Mac, as long as they played by their rules. As far as accessing the ROM socket, well, Apple even endorsed third party SCSI ports in their TIL as a solution for early Macs. They even sanctioned the Hyperdrive and used them internally at Apple. So no, the HD20 isn't the only legitimate way to use a hard drive without upgrading to a Plus, or limiting access to a serial port. Also, there were at least a dozen hard drives available for the 128K & 512K over it's lifetime. And Apple sought to eliminate floppy swapping as quickly as they realised how big a problem it was. First with the external floppy drive then more RAM. Yes, if one is trying to recreate the experience of an average user on January 26, 1984, then perhaps your argument has merit. However, I do believe most of us are reasonable enough to include the two year period over which the 128K & 512K were sold during which time numerous storage solutions were sold for the Macintosh, the vast majority of which did not violate any of Apple's warranties. As for a Flash drive, I see nothing "schizophrenic" about using a modern replacement for an original part, which had it been available at the time would have almost certainly been incorporated in 3rd party products, if not Apple's own product line.
The entire design of the Macintosh was predicated on the idea that the box was *sealed*, no user-serviceable parts inside. And the original vision did not include hard disks. It became incredibly obvious what a stupid idea that was shortly after the Macintosh went on sale, but the fact that the machine was so expressly designed *not* to support them is a pretty good argument that adding a mass storage device violates the spirit of experiencing "The Original Macintosh as Designed by Steve Jobs" embodied in the Mac 128k.
(It's an interesting coincidence that Steve Jobs was relieved from his duties as the head of the Macintosh division about the same time the Hyperdrive became widely available. In fact it was not until *after* his departure that Apple publicly agreed to honor the warranties of Macs that had them installed. Undoubtedly Mac developers were using them before they were "officially" sanctioned, as developers do whatever it takes to do their job. That doesn't mean the Macintosh's Daddy liked what they were doing.)
But, hey, if you want to create a modern day version of the Hyperdrive that's a perfectly fine goal. I just wouldn't pretend that it's in the spirit of Steve Jobs' 1984 Macintosh. Something that hangs off the serial port would be a more defensible choice for a device that wouldn't have angered Mad Uncle Steve. That was my only point. The plain fact is that Apple screwed up with the original Mac. They let one man's artistic purity get in the way of reality and produced a product which may of been "perfect" in some abstract sense but flawed and impractical by real-world measures. (And then they overpriced it by a thousand dollars, which certainly didn't help.) It was a wonderfully and exciting sales bomb and Apple had to fix it and fix it fast, first with the HD-20 hack (And there's no denying it's an ugly hack. It's overcomplicated and arse-backwards converting the floppy controller into a high-speed serial port to communicate with a hard disk. The floppy port just happened to be the the fastest "user-accessible" option Steve's minimalistic obsession left them.), and then for real with the Plus...
Hey, looking at it that way I guess if you want to vicariously live the life of a 1985 hacker who likes the GUI vision but not Steve's execution then making your own Hyperdrive could be fun after all. Fight the power, brother! Make that 128k do what it was never meant to! Add a hard disk! Add memory! Make it fly! Just be sure not to ruin the collectors value. ;^b
If you read the trade show reports in InfoWorld and similar from 1984 and 1985, it is quite clear that Apple tolerated third party developers who made serial connected hard drives (Tecmar, Corvus, Davong, Paradise etc). Apple were also generous with the licence terms for system software, allowing third parties to ship modified versions with their hardware. Funnily enough, I have the user manual for the Tecmar MacDrive sitting in a heap of random magazines and books. The manual contains a clear statement that they were licensed distributors of Apple system software.
My notes indicate that hard disk developers were a little peeved when Apple announced the HD20. They felt that they had been sent up a blind alley by developing for the serial port whilst Apple had a ffloppy port model up their sleeve. I have a reference to InfoWorld October 1985 -- I'm afraid I don't have the time to dig out the source at this exact moment, but you may be able to locate it on the Nexus news database from your public library.
I understand that Corvus also developed a floppy port hard disk drive that worked in a similar way to the HD20. Did it ever ship? Was it directly bootable or did it need a boot floppy?
My notes indicate that hard disk developers were a little peeved when Apple announced the HD20. They felt that they had been sent up a blind alley by developing for the serial port whilst Apple had a ffloppy port model up their sleeve. I have a reference to InfoWorld October 1985 -- I'm afraid I don't have the time to dig out the source at this exact moment, but you may be able to locate it on the Nexus news database from your public library.
I understand that Corvus also developed a floppy port hard disk drive that worked in a similar way to the HD20. Did it ever ship? Was it directly bootable or did it need a boot floppy?
The problem is that emulating an HD20 is a blind alley. You could do some work with a logic analyser, and there are also some schematics mentioned in another thread. With a lot of effort, you could determine the protocol that Apple used to talk to a very strange disk made by Rodime, and apply that understanding to a different type of disk.
Not all that slow really. If you hooked up a USB/Serial RS422 adapter to a modern Mac or PC to the serial port on a compact Mac, a disk image would be accessible at something close to LocalTalk speed. It might even be quicker than an HD20.
This Usenet thread may be of interest: MacSCSI and HFS
And here is a thread about MacSCSI: MacSCSI update
Steve Jobs continues that legacy in the Walled Garden approach to iPhone apps, which is good from a security standpoint but bad for many users who want more freedom. A lot of people don't like Steve Jobs or his reasoning, but interestingly we like his products. Hence, even if someone does something with their old Apple device that "Steve wouldn't have done," it really doesn't matter. It's more about making an old Mac do what it originally couldn't do, yet all the while keep it by and large the same Mac it originally was. Most non-permanent add-ons do just that, whether they be Jobsian-endorsed external port add-ons, or Sculley-endorsed internal enhancers.
Again, it's not about swapping the guts of a Mac 128k with a Mac Mini here. That's something I find taboo. But yet, I have no problem in making non-permanent "hacks" to get a system to do something amazing and fun. Heck, that's what vintage Mac computing is all about. It also includes the thrill for us old-timers of buying something for a couple hundred dollars which would have cost thousands (and would have been unaffordable for us) "back in the day."
So I see no reason to poo-poo the ideas presented in this thread or even harp on Mac128 when this talk is actually fun, productive and is not suggesting we damage any Macs or otherwise harm their value by preventing them from being put back in stock condition. So when Mac128 was saying "modern replacement for an original part," I see that as talking about something non-permanent as well.
There are exceptions to this "non-permanent" unspoken rule, of course. For example, new parts to fix a broken down analog board. The analog board is always out of view (in a mostly stock condition machine) and replacement parts would look very similar if not the same as the original electronic components. The new replacement part would be "permanent" but most people would be hard-pressed to notice it, especially since most analog boards were modified in one way or another through the years.
To offer more examples, I would consider paint on the enclosure taboo, but I would accept RetroBright deyellowing since Retrobright is in fact restoring the stock condition. I would consider drilling into the plastic case from the outside taboo, but a small amount of drilling inside the case (not visible from the outside), might be acceptable -- so long as the signatures and most of the EMI spray shield remains intact. For example, I drilled a couple holes in the metal frame of my SE/30 before, but I didn't have a problem with it because there were already factory made holes in the frame, so my holes could not really be viewed as "a fish out of water." And like I said, these changes are inside the case, which is very different from doing them outside.
So you see, it's not centered on "what Jobs would have wanted." It's about an individual vintage Mac collector's personal feelings, really. It's hard to describe one's feelings exactly in words, but for the most part I agree with Mac128's approach to vintage Mac add-ons.
And I apologize for the level of snark. In reality I think tinkering some sort of mass storage device together for a machine that didn't support one is an interesting enterprise. There unfortunately is justst something about the level of "Apple could and never did no wrong, ever" worship (and the accompanying swipes at other companies's efforts) in mac128's posts that set off my "devil's advocate" subroutine. It's a personal problem.
(in this case it was the comment about add-on disk solutions requiring a bootstrap floppy being "elegant" that did it. It's not elegant, it's a kludge in every universe but Apple's. Early IBM PCs shipped with a BIOS that didn't include support for scanning the peripheral expansion space for extension ROMs, meaning that using a hard disk on one required a boot floppy. I doubt ANYONE has ever called that an elegant solution. The correct solution was upgrading the BIOS, which of course what they did, and is why PCs with BIOS versions prior to October 1982 are rare as hen's teeth and considered a holy grail of computer collecting.
Further, despite the fact that Apple "cooperated" with third party *external* drive developers the fact that the Mac shipped with the non-hierarchical MFS filesystem is pretty good evidence they envisioned the machine as a floppy-centric in an era in which hard disks were starting to become a necessity, at least in business environments. They made a bad call, it's okay to admit it now. Sometimes, no matter how much you love something, you just have to admit that flaws in it are FLAWS, not some sort of annoying-yet-character-building positive and elegant feature.)
Oh whatever. I'm the first to point out Apple's and Jobs mistakes. But it doesn't dimish my fascination with the 128K. Jobs was building and had bought into Jef Raskin's easy to use computer appliance for the masses. And in that regard he succeeded wildly. Only Sculley refused to adopt the Mac as a simple consumer machine, and tried to turn it into something it wasn't, not trusting in the Macs ability to make up in volume what it lacked in price and overcharged what the market would support. While Jobs certainly had his missteps, he was definitely right about one thing ... It's the software that's important, not the hardware. If someone wanted to do something on the Mac it was as it is today a simple matter of writing software to do it. Sure it was floppy disk-centric. The novice computer user didn't need more than that really. But it's not like Jobs banned anyone from adding hard drives. Jobs was perfectly happy for people to add anything they wanted as long as they didn't have to open the box. And he was right. There's no need to for the average user. Plenty of external hard drives were created for the 128K in 1984. Some even attached to the floppy port (the Quark QC-10 was such a drive that also connected to the Apple II floppy port), despite Apple suggesting developers not do that. But where Apple went wrong was not supporting Jobs plan to develop UNIX as the underlying platform for their business computers. Instead they ousted him and turned the consumer appliance computer into a hackers dream, charged a fortune for it, and built their entire business model on a platform that had obvious limitations, slapping hack-after-hack on top of it to keep up with professional demand, until they finally were forced to scrap it for OS X. But in their defense Microsoft wasn't doing anything differently with their OS, besides leveraging it to become a monopoly.
OK, when you're all finished arguing about historical "authenticity" like a bunch of RenFaire LARPers...
For $10+ parts, you're sticking 8 CPUs in there, each of which is an order of magnitude more powerful than a 68000. The main restriction for expansion would be the availability of pins.
IIRC, John Bass's "vaunted SCSI hack" used an exisiting step in the boot ROM that checked a certain address for a redirect, and if none was present, continued to boot as normal. The redirect can point to your new boot code. That in itself (if i am recalling the story correctly) opens up a world of possibilities.
Course, for machines beyond the 128K, we have access to other locations such as PDS slots.
I am fully in favour of getting a Prop inside any 68k Mac, by any means necessary. I doubt it would take more than two or three Cogs to read SD/CF/IDE and emulate *something* or other to the Mac (and/or, as Gorgonops suggests, interface to a newly written driver on the Mac side), leaving lots of processor power available for other enabling addons. USB, PS/2, Bluetooth, ethernet, TCP/IP, Wifi and video out come to mind, especially as the Prop does VGA and PAL/NTSC natively.
For $10+ parts, you're sticking 8 CPUs in there, each of which is an order of magnitude more powerful than a 68000. The main restriction for expansion would be the availability of pins.
IIRC, John Bass's "vaunted SCSI hack" used an exisiting step in the boot ROM that checked a certain address for a redirect, and if none was present, continued to boot as normal. The redirect can point to your new boot code. That in itself (if i am recalling the story correctly) opens up a world of possibilities.
Course, for machines beyond the 128K, we have access to other locations such as PDS slots.
For example, here are two projects that use a Propeller as a bridge between a 68k CPU and the outside world:
http://propeller.wikispaces.com/pPropQL
http://propeller.wikispaces.com/pPropQL020
http://propeller.wikispaces.com/pPropQL
http://propeller.wikispaces.com/pPropQL020
On the other hand, seems like you can get ARM Cortexes for under $2 in single quantities these days. Add a handful of bucks for one with lots of built in I/O.
Lots of potentially useful clues in this thread:
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=426250
Lots of potentially useful clues in this thread:
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=426250
um yea, I seem to not be the minority when I say this, but ARM is a big PITA to develop
I would not use a prop either, focusing 1 thing at a time would be the best for the goals, cheap pic or avr has more than enough power (and on a personal note I dont like parallax's high price and propitiatory closed nature)
I would not use a prop either, focusing 1 thing at a time would be the best for the goals, cheap pic or avr has more than enough power (and on a personal note I dont like parallax's high price and propitiatory closed nature)
I still think Captain Kirk could kick Captain Picard's shiny bald arse any day of the week. :^b
The prop is pretty cool, but it's not powerful beyond all human understanding. It's not very good acting as a general-purpose CPU. Ethernet and WiFi is pretty much beyond its abilities... there is apparently some experimental code to make it act as a USB 1.1 host, I guess. It is quite good at bitbanging humbler protocols like PS/2, and if you made an external device it *might* be able to emulate Localtalk (with appropriate voltage-shifting hardware). And I suppose in theory at least if you had one wired up you could use it as a VGA output port, but you'd need to write a Mac driver to render the screen in the prop's Internal RAM, thus limiting you to less than 32k of framebuffer. (which I guess is enough to duplicate the Mac's 21k array.)
The Mac's clock speed is a little high to attempt tricks like wiring the Propeller in parallel with the 68000 to directly snoop and substitute memory contents ala the 6502Prop laptop... the fact that the 68000 has more data and address pins then the Prop has I/O pins puts that in the can right there. Thus A Prop-in-Mac would have to be addressed as a "peripheral", not a "magic translator". The PropQL machines use it that way, substituting the Propeller for custom chips, but using some external decoding and buffering logic. The one thing I suppose you *could* do is map a propeller to the same addresses the Mac Plus uses for its SCSI controller and program the Propeller to emulate *that*+disks. (And possibly do other things, depending on how many free cycles/cogs you had on the Prop. You'd just have to use those things by writing drivers which sent special commands to your "SCSI Port". Of course, if the goal is to retain the 64k ROM emulating the Plus SCSI port doesn't buy you anything.)
John Bass' DDJ article detailed hardware and software which worked using a boot floppy. There was no magic ROM hackery in it whatsover. The real question that I'm not sure anyone knows the answer to is how devices like the Hyperdrive (and other internal boards that enabled diskless booting on the 64k ROMs) *actually* hijacked the boot cycle. This page has a quick summary of what happens when a Mac boots:
Code:
When power is first supplied to the Macintosh, a carefully orchestrated
sequence of events takes place.
First, the processor is held in a wait state while a series of circuits gets
the system ready for operation. The VIA and IWM are initialized, and the
mapping of ROM and RAM are altered temporarily by setting the overlay bit in
VIA data register A. This places the ROM starting at the normal ROM
location $400000, and a duplicate image of the same ROM starting at address
0 (where RAM normally is), while RAM is placed starting at $600000. Under
this mapping, the Macintosh software executes out of the normal ROM
locations above $400000, but the MC68000 can obtain some critical low-memory
vectors from the ROM image it finds at address 0.
Next, a memory test and several other system tests take place. After the
system is fully tested and initialized, the software clears the VIA's
overlay bit, mapping the system RAM back where it belongs, starting at
address 0. Then the disk startup process begins. ..A: Map their *own* code into address 0 at power-on and override part of the Mac ROM's startup routine in order to write pointers to their driver into the mapped-high RAM, so when the memory map is flipped back their code executes before the normal floppy disk tests? or:
B: Does the 64K ROM have specific hooks in it to look for an extension ROM mapped to some known location, and thus all an add-on board maker would have to do is map their own ROM into that space?
It's probably one or the other. Duplicating possibility A: would be the more difficult, if you want to manage a floppy-diskless boot. If someone can find evidence for the "check a certain address for a redirect" code in the Apple documentation ("Inside Macintosh"?) it would answer the question. Otherwise it's hearsay.
I suggested the Prop mostly because I'm noddingly familiar with it (although thanks to a lack of quality time I'm still just working through the tutorial on my Prop demo board) and at about ten dollars for the Prop plus external EEPROM it's still pretty affordable, and I also had the vague idea that you might be able to pretty much wire a slew of its I/O pins up in parallel with one of the Mac ROMs on a daughter board (with some resistors) and cut out some decoding hardware. But further thought made me decide the Mac's probably too fast for that to work, so in truth a Prop would likely need just as much external hardware as anything else.
As said earlier, I think this is *all* cart before the horse until someone demonstrates a willingness to write a software driver, and to do that they could start with something exceedingly brain-dead that works with another computer through a serial port. I've looked at some sample RAMdisk code in MPW and decided that if you locked me in a room for a week or two I might be able to make a "serial disk" driver myself, but the only way I'd have to test it is BasiliskII (the only emulator that can light up a real serial port), and that would restrict me to System 7 or better. But, really, it's not my job, because it's not my obsession. Someone who actually has dev tools suitable for writing System 3-era drivers and actually cares about having them should do it.
Old Kirk or New Kirk? 
Look, I know all of this is sheer speculation until someone extracts the digit and gets on with it. All I'm hoping for here is some constructive speculation to narrow down potentially worthwhile approaches. And, for the porpoises of this discussion, I for one am not even remotely concerned with preserving the "purity" of the original 64k ROM, nor keeping discussion narrowly focused on the original 128K Macintosh.
/ETA/ I also freely acknowledge that I don't reeeeeally know what I'm talking about.
Hence finding the argument in favour of using a cheap ARM that already has those peripherals on-board interesting.
Come to that, could you get away with sampling one line at a time, rather than the whole frame?
Second: external RAM, and clock that out as VRAM to 1-bit VGA?
Look, I know all of this is sheer speculation until someone extracts the digit and gets on with it. All I'm hoping for here is some constructive speculation to narrow down potentially worthwhile approaches. And, for the porpoises of this discussion, I for one am not even remotely concerned with preserving the "purity" of the original 64k ROM, nor keeping discussion narrowly focused on the original 128K Macintosh.
/ETA/ I also freely acknowledge that I don't reeeeeally know what I'm talking about.
I'm not suggesting it is - merely useful.
Sure: I was picturing it more as a peripheral translator, to act as a go-between between the Mac and Ethernet/WiFi/USB chips - either through a new Mac driver, or pretending to be an existing peripheral such as a SCSI-Ethernet converter.
Hence finding the argument in favour of using a cheap ARM that already has those peripherals on-board interesting.
Thoughts: lockstep the Prop [or whatever] to the Mac's oscillator, double or quadruple speed it internally, sample the TTL signals from the Mac's motherboard to the analogue board, leave blank pixels and lines to make up a VGA raster, then squirt that out another Cog using the existing VGA code. A brute force approach to not writing a Mac driver
Come to that, could you get away with sampling one line at a time, rather than the whole frame?
Second: external RAM, and clock that out as VRAM to 1-bit VGA?
Yes, I thought that might be a little ambitious. "Prop as peripheral" was more the approach I was contemplating.
Exactly - and give the Prop [or whatever] an SD card [or whatever] to play with.
Personally I find the 64K ROM obsession rather silly, as there seems to be essentially zero evidence that its presence breaks *any* old Macintosh software. (The one small example that's been pointed to that ran on the original Macs but won't run on a Mac Plus are a few programs that used copy protection systems that are *actually* broken by the 800k drive, not the ROM.) But, eh, whatever.
I suppose the discussion still has to focus on pre-Plus models, so really the "purity" argument is whether or not we want to count a machine upgraded to the 512Ke standard as qualifying in that category. Personally I'd point to the fact that Apple practically gave away the "Macintosh Plus Disk/ROM Upgrade" as evidence that for anyone who actually *used* their original Macintosh, rather than tiring of it and throwing it in the closet, should of ended up with the equivalent of a 512Ke eventually anyway. And logic follows that after that they either got a Plus motherboard swap or the functional equivalent in third-party add-on cards, but at that point the discussion becomes moot.
So what we're concentrating on apparently is an upgrade for those leftover original Macs that the buyers hated, never used productively, and ended up abandoned in the closet for twenty years. Yay. :^b
The Propeller is uniquely suited to the strange niche job of transparently emulating an existing peripheral chip because it's designed specifically to bit-bang and listen to I/O pin states in real time. (It doesn't use interrupts like a normal CPU, it has those eight cores so you can dedicate a few to endlessly polling and switching the I/O lines.) And ARM board is far less well suited to that, because it behaves like a "normal" computer + peripherals. Adding an ARM chip with a bunch of modern I/O ports would be a good way to add those functions to the Mac because you could use the power of the ARM to "dumb down" the modern protocols (for instance, you could offload the TCP/IP stack to the ARM), but what you'd get out of it is the ability to greatly simplify your Mac driver (and make it less resource-intensive). It's not a good route to eliminating Mac driver development entirely.
I suppose you could create some sort of hybrid where you have a Propeller dedicated to aping the interface of, say, the Plus SCSI chip, and then the Propeller communicates via a private bus (SPI, probably) with the ARM board. For just emulating disks that's huge overkill, but if you wanted to use the "SCSI Port" as a gateway to other functions I could see it.
There was a thread about this a while back. Work on that sort of petered out, apparently. In principle it "could" work but I think you'd probably have to dedicate the Propeller solely to it with this approach.Thoughts: lockstep the Prop [or whatever] to the Mac's oscillator, double or quadruple speed it internally, sample the TTL signals from the Mac's motherboard to the analogue board, leave blank pixels and lines to make up a VGA raster, then squirt that out another Cog using the existing VGA code. A brute force approach to not writing a Mac driver
(I did stumble across a discussion on the Parallax forums of people semi-successfully sampling monochrome PAL and NTSC signals, so there would be hope for this idea.)
Another more "elegant" possibility, which I *may* be wrong about, is it at least appeared to me from some light reading on the Mac's video system that it's possible to tell the OS to render the display in some other area of RAM. The original Mac hardware supported two locations for the framebuffer. (technically allowing for double-buffered rendering and animation, but the low amount of RAM pretty much nixed any programs actually taking advantage of that possibility.) If it's possible (and you'd have the look in the technical documentation to confirm it) to tell Quicktime an *arbitrary* location for the framebuffer you could map a block of fast SRAM (or dual-ported VRAM) somewhere higher in the memory map, and with a little extra hardware enable the Propeller to act as a DMA video generator.
(I could describe the additional hardware you'd need, but you'd have to run it past someone with more practical experience than I have to make it actually work.)
Heck, in theory you could be really incredibly skanky and map an ISA VGA card somewhere into the memory map, program its registers to set up an appropriate video mode, and tell Quicktime to render to it. In either case you'd undoubtedly run into some software (games mostly, I imagine) that blindly write to the default location of the framebuffer and thus barf, but there's no helping that.
Frankly, I think that's the only approach to *completely avoiding* writing custom driver software that has a snowflake's chance in heck of working. The NCR SCSI controller is pretty well documented, MESS emulates it well enough to trick the MacOS into working on it so you'd have an existing software model to follow when putting together your emulation... unless the Propeller is just plain too slow to pull off an emulation it should work.
But that deep-sixes the 64k ROM again. :^b