NuBus IDE Controller Card Project!?! =8-O

[Trash80toHP_Mini]

I just found this very tasty tidbit:

http://www.freeinfosociety.com/electronics/schemview.php?id=1475

The ole' wooden cogs betwixt the ears began to smokin' . . .

. . . so I whipped out my trusty, special ordered waaaaayyyyy back in the day, copy of DCaDftMF AKA: Designing Cards and Drivers for the Macintosh Family. And found the SCSI-NuBus Test Card design example I remembered, fully documented therein!

I quote: DCaDftMF p. 231 "The SCSI-NuBus Test Card is an example of how a simple 8-bit I/O chip may be supported over NuBus."

What better example of an (intelligent/programmable) 8-bit I/O chip is there than the Z80 family, a PIC emulating a Z80 maybe?

Question: can the modern Z80 family support throughput from a modern IDE HDD or SATA HDD/IDE Bridge combo that would compare favorably with yesteryear's Fast/Wide SCSI HDDs or RAIDs on a JackHammer NuBus Card?

From what I gather, it's not all that hard to swamp NuBus I/O, especially so with a pre-NuBus '90 design, I would think. Unfortunately, the design examples in this 1992 tome were prepared before the NuBus '90 specification. Were the Fast/Wide SCSI 2 NuBus cards vanilla NuBus or NuBus '90?

Food for thought . . . [}] ]'>

This kinda stuff is waaayyyyy over my head! :

 

[johnklos]

Z80s are nice processors for what they are, but considering the memory bus and instruction timing, you'd be lucky to get 6.6 MB/sec total memory throughput on a Z80 at 20 MHz, assuming completely artificial conditions (3 t-states per memory access, 20 million t-states per second). To do anything which is actually meaningful, that number would be a fraction of that (1/3 or so) because you're talking about reading one thing, writing another, and dealing with interrupts and the overhead of fetching and running instructions. An eZ80 or an embed-intended MIPS or StrongARM would be much better suited.

Then again, 1 MB/sec on many m68k machines isn't too shabby. It wouldn't compare with a decent SCSI drive on the motherboard SCSI, but it wouldn't feel THAT much slower... But compared with wide and/or Ultra SCSI, it wouldn't come close.

NuBus on earlier Macs was stuck at 10 MHz and was updated to 20 MHz on the AV machines and PowerPC machines, so the maximum speed was 20 MB/sec, although speeds between 10 and 20 are more reasonable to expect. From what I remember, all Quadras support the NuBus90 standard, but can only talk at 20 MHz between two cards; everything to and from the system was at 10 MHz.

 

[Trash80toHP_Mini]

Thanks, John, I was thinking that I'd hear back something along those lines, which explains why a home-brewed IDE card for the Apple II was fine, but no NuBus card was ever attempted. My noggin' was running in circles so I took a nap . . .

. . . woke up wondering about using several processors in parallel to cram 2, 4 or 8 bits apiece on a card, based on these two schematics, to get the IDE data stream onto the 32 bit NuBus just a tad faster? :?:

 

[johnklos]

There's no real sense in having a processor, 8 bit or otherwise, do the work of transferring data since MacOS doesn't do anything but busy wait on disk access.

When I used to run MacOS on ShapeShifter on my Amiga, I could easily tell how much the MacOS environment was busy waiting by comparing direct access with access through AmigaDOS. Direct access let MacOS treat a disk as its own SCSI device, and the system would stay busy whenever disk activity happened. Going through AmigaDOS, though, was completely different - MacOS would pause while waiting for data (and therefore idle and give up the CPU) and the data would be transferred by AmigaDOS using real DMA (I had a very nice and speedy DMA SCSI interface), so the system would essentially be idle for other processes while MacOS was waiting and DMA was handing disk activity in the background.

ATA PIO mode 0 can run up to 3.3 MB/sec and mode 2 can do up to 8 MB/sec which would probably be more than a Quadra could handle anyway, so using the CPU to do PIO would probably be just as efficient as any sort of DMA modes or offloaded work.

Ironically, the Amiga 1200 and 4000 had a CPU-intensive IDE interface built in when they were some of the few personal computers at the time which could truly take advantage of DMA. Goes to show how ass-backwards Commodore was.

 

[Trash80toHP_Mini]

Somehow, I think EVERYTHING was bass-ackwards back in the day . . . and I haven't noticed all that much improvement since then either! :-/

Actually, I'm interested in getting Video Capture Data across NuBus from my Radius VideoVisionStudio Card to Disk w/o the Mac's CPU getting in the way. This would be similar to the way several Rockets worked in parallel, with or without the Mac CPU, under AppleTalk running across NuBus, at NuBus speeds, under RocketShare.

Rockets and RocketShare topped out at the OS 7.0.1 Tune-up. It seems that Apple changed the AppleTalk protocols for 7.1 in order to cut Radius off at the knees, for the first time, way back when! Apple finally realized that they'd licensed the Mac ROM for use as uploaded copies on each and every Rocket in a HUGE parallel processing RIP . . .

. . . headed by something as lowly as a single SE/30! 8-o

This realization did NOT make Apple happy! :

Apple cut Radius off at the knees, for the second time, not all that long after they announced Radius as the VERY FIRST Mac Clone licensee!

With partners like Apple . . . who needs enemies? :?:

}

 

[trag]

As with all these projects, the tricky part would be getting the software support written. I posted a message a while back (years?) probably in one of the 68060 or Coldfire threads about the elegant way (broad outline, no actual useful instructions) to do this. I happened to have a copy of Inside Macintosh open in front of me when I wrote that post.

The Device Manager has some kind of structure of shims and pems. Or lems and pims. Or some such. SCSI Manager 4.3 is one of these things. Anyway, to add support for an IDE card, one would need to write at least one of each of these components for the operating system and figure out how to install them from the IDE card's ROM.

Or one could plan on the host machine always having SCSI Manager 4.3 available and make the IDE card look like a SCSI card. However, if SCSI Manager 4.3 isn't in the ROMs, then the IDE card devices won't be bootable.

FWB got around this, so I've read, by including a copy of SCSI Manager 4.3 in the JackHammer's firmware/ROM. Which is why it conflicts with the Daystar Turbo601 which also has SCSI Manager 4.3 in the ROMs (PM6100 ROMs, apparently). But then FWB provided a fix whereby the loading of SCSI Manager 4.3 from the JackHammer could be disabled, thus granting compatibility with the Turbo601.

Similar software issues with building a USB card.

The early Device Manager just wasn't that extensible. That's why, for example, the Quadra 950 appears to only have one Logical SCSI bus evne though it has two separate physical SCSI busses (two 53C96 chips). The hardware is there, but the firmware and OS is only written to admit the existence of a single SCSI bus.

So, anyway, getting the hardware going probably wouldn't be so hard, but getting the firmware and OS to recognize the attached hardware, that would be the trick.

 

[Trash80toHP_Mini]

The SCSI-NuBus Test Card also has some RAM on board for the testing of DeclROM images to boot the Mac OS from an attached SCSI Drive.

"In addition, the card provides a small RAM, which is accessible in super slot space for the testing of 32-bit address mode switching.

The ROM is really a RAM that can write to in the assigned ROM address space. The RAM chip may be replaced with a real ROM when desired."

This leads me to believe that the IDE HDD might be addressable as Virtual Memory in the super slot address space. If this is the case, could some kind of HDD controller IC be addressed as if it were one big block of VM or a BIG@$$ RAM Disk to get around the programming needed for treating it as Hard Disk? Regular toolbox routines ought to cover the VM angle and much of the programming would then be toolbox calls . . . or not.

All the source code and equations for the three PALs on the SCSI card are included in Appendix E. Chapter 9 offers information and NuBus specific notes about NuBus card drivers to supplement the General Guidelines for writing drivers in the Device Manager information in Inside Macintosh.

Unfortunately, the Firmware Sample in Appendix B and the Driver Example in Appendix C are both for the Video Card Design, not the NuBus SCSI Card. :-/

Like I said, this is waaaayyyyyy over my head! I can make connections that lead to over the top suggestions, but implementing anything in software is NOT my thing . . . maybe a little PCB prototyping would be OK! }

 

[techknight]

I only know BASIC/VB and AVR ASM. I dont know C, or the 68K ASM either so i cant write a mac driver if i began to try.

As i dont think i can use realbasic to write a driver. LOL. Another thing is the apple books and development notes always refer to alot of mnemonics, i just wish i knew where the mnemonic to address mapping was located! lol.

 

[trag]

Yes. The process seems to be something like:

1) First learn Pascal. Got that? Good, that wasn't so hard.

2) Now become familiar with all of "Inside Macintosh" Volumes I - VI. Done that? Great.

3) Okay, now you can understand the stuff in "Designing Cards and Drivers" and how it applies and connects to the hooks and sockets in the Mac OS. Except, we won't actually tell you anything about what a SCSI card or video card actually does. You'll have to already know that by being an experienced computer hardware designer.

4) Realize there's about three college level courses worth of information to absorb. It might be worth the effort, but you don't really have the time at the moment. Maybe next year.

5) Drink beer.

 

[Trash80toHP_Mini]

Is that all? 8-o

I could maybe handle step 5 . . . if my Pshrink would let me drink it . . . :-/

I think I'll stick to putzing around with Simple Hardware Hackage . . .

. . . stuff like "generic" ROM & RAM SIMMs & DIMMs! :I

 

[Gorgonops]

Yes. The process seems to be something like:
1) First learn Pascal. Got that? Good, that wasn't so hard.

2) Now become familiar with all of "Inside Macintosh" Volumes I - VI. Done that? Great.

...(snip)

I spent a few days once futzing around with some sample Ramdisk driver code in MPW and... yes, writing a Mac driver is intimidating, there's no denying it.

The dirty little secret about the old Mac OS is it hardly really qualifies as an "operating system" by modern standards. (It's almost just a random collection of bare APIs and it's up to your program to string them together and essentially act like it were the OS while it's in the foreground.) Worse, when you start poking around at a low level you'll see not only how "bare metal" the interfaces are you'll also be struck by just how *weird* it is by modern standards. Like the whole Pascal thing. Apparently large parts of the Mac ROM were hand-translated from Pascal prototypes into Assembly to speed them up and cut down on ROM usage but they retain Pascal conventions for their interfaces. So yes, even if you want to program in Assembly or C you need at least a nodding familiarity with Lisa Pascal datatypes if you're going to go all the way down the rabbit hole...

Anyway, that said... I do wonder how difficult it might be to lift the IDE driver from the Quadra/Performa 630's ROM and embed it into a NuBus card. The Developer Note for the Q630 series describes the hard disk device driver and ATA Manager as if they were modular add-ons to the "standard" Macintosh ROM, including describing what reference numbers the driver uses and what calls it needs to support. If you were a really skilled hacker it might be possible to lift the required bits off and embed them on an extension ROM assuming one were to build a NuBus card which could ape the IDE controller of a Q630. (Whether that would actually be easier than writing the whole driver from scratch is an exercise for the hacker. I dunno nothing 'bout birthin' no babies.)

 

[Trash80toHP_Mini]

ROTFLMAO!!!!!!!!!!!!!!! :lol:

EudiG, if there were EVER a worse example of the implementation of an IDE interface (single device/HDD ONLY) than the patch on a hack on a freakin' kluge Apple inflicted upon the Q630 . . .

. . . and ALL of its offspring, including the TAM . . . I'd just LOVE to hear about it! :

 

[Gorgonops]

*snicker* Ironically if you look all the way back to how the SCSI port is implemented on the Mac Plus you'll see that the Q630's IDE interface is pretty much par for the course. I still get a little amused when reading old pro-Mac polemics ragging on aspects of PC clone hardware that are ugly kludges. If you're comparing pre-1998-ish hardware it's a *serious* case of the pot calling the kettle black. ;^)

Anyway, I have to admit I'm a little confused by some of the technicalities of what you're asking for... which seems to be a magic disk interface that offloads file system operations in such a way that a Nubus video capture device can stream data straight to it rather than depending on the host CPU to moderate. Were there SCSI/Nubus video board set combinations that actually did that on the Mac platform? With the classic Mac's weak/nonexistent support for DMA and busmastering it seems to me that such a combination would require some pretty specific things be embedded into the CPUs on the capture and SCSI card respectively. If you can point to a combination that actually did that as opposed to a SCSI controller that merely provided a faster interface than the built-in one (and perhaps some onboard caching) but was otherwise treated the same way there might be a point of reference to work from.

 

[trag]

The thing is. The thing is.... if one were to learn the ins and outs of pims/sims/lems or whatever they're called in the Device Manager, and write one's own implementation, it would be usable for every storage device one wished to build. This is a software necessity (unless one wants to kludge around it) for both an IDE card and a USB card (and a Firewire card if such a thing were desired).

IIRC, there are two levels of component needed. One is a replacement for one of Apple's higher level components which would allow the use/existence of multiple lower level components. Before SCSI Manager 4.3 the upper level component only supported one lower level component.

So first one writes the upper level component which support multiple lower level components. Then one writes a lower level component for IDE/ATA and another one for USB.

That or install SCSI Manager 4.3 in the boot ROM of your card, however that's done and then deal with the fact that it's going to cause problems on machines that have 4.3 in the ROM already. Which isn't a terrible solution, but it might limit you to seven devices on your USB card. Or maybe 15 in which case, who cares?

There was some discussion here with a fellow who turned up for a while and seemed quite knowledgeable who explained in a general way how one modifies SCSI Manager 4.3 to be something that goes in the boot ROM. I don't remember the thread, but searching on my old posts would probably turn it up eventually. I think Bunsen also participated in the thread.

 

[Bunsen]

Driverguru. He apparently lost interest and hasn't been seen since.

 

[Bunsen]

I don't remember the thread

Dream peripherals?

viewtopic.php?f=16&t=527

Starts getting relevant about page 2-3

With the classic Mac's weak/nonexistent support for DMA and busmastering

Didn't Nubus 90 improve things a little afa card-card communication? 20MHz card-card but still only 10MHz card-host?

1) First learn Pascal. Got that? Good, that wasn't so hard.

I lolled

 

[Bunsen]

I posted a message a while back (years?) probably in one of the 68060 or Coldfire threads

viewtopic.php?f=16&t=393

This one?

 

[Bunsen]

With the usual disclaimer about being in way over my head, but noting the horror stories above about driver development, how about this approach:

• Clone the Jackhammer or similar fast Nubus SCSI card, using its ROM and drivers, but
  
• Leave the SCSI controller & sockets off the board.
  
• optional:
  Bring their pinouts to a daughterboard connector.
  
• Build one daughterboard with the original SCSI chip & connectors for testing the host card.

[*]Add a Propeller/ARM/FPGA/whatever (daughterboard) to emulate the original SCSI controller (or at least its I/O to the host board) and translate to IDE/USB/RAMdisk/flash/whatever.





The hardware development task is reduced to (mostly) reverse engineering and re-routing an existing design, and the software development task is boosted out of the hideously Byzantine sounding low-level Mac 68k world, into the world of modern tools and languages, documented interfaces, and shared, open code.

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.