HDD alternatives?

[James1095]

As the supply of 50 pin SCSI HDDs dwindles, there has been a fair amount of focus on bridges to attach various more modern storage devices to the SCSI bus. Has anyone seriously looked into bypassing SCSI entirely and interfacing directly to the PDS or NuBus? There has been success in modifying the ROM to implement a ROM disk which I've now got running in an SE/30. This is somewhat limited though as the ROM slot can not address more than 8MB and there is no provision for write enable, but it solves the boot issue and means that the primary storage does not necessarily have to be bootable.

Could the IDE interface used in some of the later 68k Macs be duplicated on an expansion board? Perhaps a simple SD card interface? Other options?

 

[bbraun]

Short version is: there's an abundance of people that want this or have ideas on how it could/should be done, and a shortage of people doing something about it. It doesn't help that every time someone does do something, someone else helpfully says you should have used an FPGA and then doesn't offer to actually help make it happen.

Long version: I've made a super rudimentary hand-soldered 030 PDS card that only has a declrom, and wrote a valid stub of a declrom for it. It's too much of a rats nest to really do anything more with it. My next step would be creating a PCB based on the hand soldered board with some breakouts for experimenting with attaching other devices. But I'm not willing to do PCB layout. I started and it's not for me. tt did a bunch of work on this for which I am eternally grateful, but there's still some routing to be done. Anyone working from my rudimentary design will quickly find that more complex address decoding logic is necessary, which means more chips or cpld or fpga, and all the associated development and layout issues.

Nubus is significantly more involved than PDS, and no one seems to be able to pull off a PDS card.

Another option: I've written a Serial Disk device driver, which you can use in conjunction with the ROM disk to get more (slow) storage. Not perfect but the advantage over most other options is it actually exists. There's some talk of a standalone serial to SD card device by techknight or landonf.

I've made some efforts trying to put the serial disk driver into the IIsi ROM, but it hasn't gone that well. Maybe someday.

Summary: It's entirely possible to do and there's plenty of documentation available. If you're interested, go for it.

 

[Trash80toHP_Mini]

ISTR that there's an IDE HardCard for the Apple II expansion slot, is this true? If so, would there be any crossover between that project and Mac PDS?

 

[Gorgonops]

Short version is: there's an abundance of people that want this or have ideas on how it could/should be done, and a shortage of people doing something about it. It doesn't help that every time someone does do something, someone else helpfully says you should have used an FPGA and then doesn't offer to actually help make it happen.

Hey, I resemble that remark!

(Actually, no, I rarely suggest that FPGA are the way to go.)

Another option: I've written a Serial Disk device driver.. (snip) I've made some efforts trying to put the serial disk driver into the IIsi ROM, but it hasn't gone that well. Maybe someday.

One of the useless gadfly suggestions I've tossed out there from time to time when someone complains about the lack of storage options for the original (pre-Plus) machines is that someone write a Macintosh driver for those extremely simple 68000-socket piggyback IDE ports that the Amiga and Atari ST people seem to churn out in vast quantities. If you ever succeed in your IIsi ROM hacking... if anyone on this board is qualified it's probably you.

Anyway, I wish I could do that sort of thing myself, but:

A: I have barely enough hobby time to wrap my moldering old brain around the software complexities of my Commodore PETs. The Mac toolbox is just a big scary blur to me.

B: My oldest Mac is a B&W, and I'm probably going to pitch that in the recycle bin one of these days. Toaster Macs just ain't my fight.

I do know just enough about hardware to tentatively say that doing the hardware for a 68000 Mac should be something doable at the hobbyist level. '030 and faster PDS and Nubus? That's pretty hard stuff.

 

[bbraun]

Huh, I hadn't seen those before. Is this what you're describing?

I'm trying to sort out some of the details of the interface.

It'll probably need some changes to show up in the right place for the Mac's address space.

Still, very interesting, thanks for the pointer. I'll read some more about that.

 

[Trash80toHP_Mini]

Very interesting . . .

< . . . immediately speculates about opportunities for the Luggable and PowerBook 100 . . . [}] ]'> >

 

[bbraun]

Some semi-focus notes on the subject of peripherals:

The SE makes a pretty decent prototyping machine. It has a connector for ease of accessing the signals, it's slow, but most important, the entire 24bit address space is valid (the peripheral bus is only 24 address lines). For all Nubus and PDS slots, the official Slot address space is only mapped in if a valid declrom is found. Which kind of means you have to have the declrom present and correct before you can do any further hardware prototyping. There is space in the 030 PDS set aside for non-Slot Manager based cards (presumably accelerators), which should be mapped in with no declrom. But, one ease-of-use advantage the SE's 68000 bus has over the 030 PDS is the SE's memory controller will automatically acknowledge accesses, so you don't have to ack anything yourself.

It looks to me like you can just throw something on the SE's bus, particularly in the 0xE00000-0xFFFFFF range (it automatically generates /VPA or Valid Peripheral Address), key off of /AS (Address Strobe), decode the address to see if you should respond, and either respond or not. Looking at /RW as appropriate

68k takes 4 cycles to perform a read or a write operation. The SE is 8MHz. IMO, using TTL to do address decoding which goes to an interrupt on a microprocessor isn't completely crazy. The SE's data bus is 16bits wide. If you can put the address bits, data bits, and /RW into a single register of the microprocessor, so much the better since it can read all the relevant information with a single operation.

Anyway, just some thoughts.

 

[tlc630]

Sorry, but why bother with 50 pin drives at all? Where I am located (S.F. Bay) I can buy large, server grade (10k or 15k rpm) SCSI drives for peanuts and get a 80->50 or 68->50 pin adapter on ebay for a couple of bucks.

 

[James1095]

Server drives tend to be very noisy. There is an appeal to a silent or nearly so machine, and a 15K drive whining away inside a compact Mac a couple feet from my head is not my idea of a good time. The benefit of going with IDE or other modern interface is the abundance of cheap SSD options. A 1GB SD card can be had for a few dollars and is more than enough space for most of these machines that originally came with <100MB drives. Not only that, CF, SD, and IDE drives are easily plugged into all manner of modern systems for data transfer.

I'm perfectly willing to contribute to projects but I'm primarily a hardware guy, the software/firmware side is over my head once it gets beyond 8 bit microcontrollers. I'm quite proficient at laying out PCBs so if there are projects awaiting that side of things I'd be happy to help out as time permits.

Does anyone know offhand what the IDE interface on the later 68k Macs looks like? Is it built out of commodity chips, or integrated into a big custom chip?

Also while I'm generally a fan of FPGAs, the more I look at the dual-AVR SCSI to PCMCIA/CF bridge, the more tempted I am to try it. The AVRs are cheap and expensive transceivers he used are not necessary for SE SCSI, it would be cheaper to use the discrete logic as used in the SCSI RAM disk. Too many projects and too little time.

 

[Trash80toHP_Mini]

Unfortunately, that'd be a really lame ASIC until the Beige G3, AFAIK, even worse than the Mac's SCSI implementation.

@tlc630 Got linkage for those 68-50 pin adapters? I only have one, but it's active termination so it's great for a single drive Mac.

I have a nice pair of 68 pin, terminated end, internal cables with four connectors.

I've got a nice four bay hot swap bay with a single 68 pin internal connector. Would the adapters you use work for hooking that up to an internal 50 pin cable?

 

[Gorgonops]

Huh, I hadn't seen those before. Is this what you're describing?I'm trying to sort out some of the details of the interface.

It'll probably need some changes to show up in the right place for the Mac's address space.

Yeah, that's a good example. (I've also seen ones targeted at Atari STs, but more often interfaces for that machine tag onto its ASCI port, which is basically just a general purpose parallel port.)

IDE in theory should be a pretty low-hanging fruit. As this page detailing the construction of an 8 bit IDE interface for a Z-80 based computer lays out it's a fairly forgiving interface which can be driven by simple polling if you want to ignore the interrupt and DMA features. (Using it that way is fairly slow, but it's basically on par with the early Mac's SCSI implementations.) Decoding the entire 68000 bus "from scratch" to lay out an IDE port shouldn't take more than around... half a dozen 74HC-series chips, give or take. Possibly less if you find some way to be "clever". (IE, take advantage of some existing decoding/chip selects.) Most of those "parasite" designs compress some of the logic into PAL/GAL/CPLDs to shrink the board size, but if programming them is off the table it's still reasonable to ponder doing it entirely in discrete logic.

So, tossing *this* out there: for the original 68000 machines (128k/512k at least) in addition to the "68000 parasite" route of getting the needed signals there were expansion boards which sat in the ROM sockets. Apparently on those early machines the ROMs are not isolated behind a one-way buffer so you can "see" writes on the data lines through said sockets. So... for instance, as discussed on this forum a while back, there were SCSI controllers that were stuck in the ROM sockets. I have a copy of the .PDF that's the topic of that thread, and the interface between the ROM sockets and the NCR 5380 SCSI chip used only two 74LS10s as decoding glue. Comparing that schematic to the minimal requirements necessary for an IDE interface it *appears* to me you could wire up an IDE drive almost as simply.*

(* For details, the Bass-SCSI leverages some of the very sloppy decoding logic Apple used in the original Macs, which resulted in the 64/128k of ROM occupying 4MB of space but actually only "present" in parts of it. I can't tell for sure why Apple did this without more detailed schematics, but it appears that the output enable/chip enable lines on the ROMs are connected in such a way that OE is selected for the entire 4MB block but CE is tied to A20, so that the ROM will only be active every other megabyte. The Bass-SCSI thus sets itself up so it's selected whenever OE is *and* whenever the ROM is not, so it's visible at 0x5000xx vs 0x40xxxx for the ROMs. Since there is no read/write lines present at the ROM sockets it leverages a sort of ugly hack using the A4 address line to map out the 8 registers on the SCSI chips so to read a register you address it at one location, to write it you touch it 8 locations away. Further, for writes a flying wire to pin 7 on the 68000 is used to determine if the 68000 is actually writing something on the bus.

Also worth noting is that the 5380 SCSI chip is only 8 bits wide, so this interface only tapped the data lines from one socket.)

To convert this to IDE in principle you could grab the other 8 bits from the other ROM socket, wire up the IDE address lines just like the SCSI chip's port address lines, and... perhaps use one more address line to generate the chip select signal that lets you hit the top 8 of the 16 IDE registers. You'd probably also want to tie the RESET line to some appropriate pin inside the Mac. Now of course this is ignoring some possibly important details, like whether you'll need some additional flip-flops or buffers to ensure the signals are sufficiently "valid" when doing I/O. (That 8-bit IDE page calls out some gotchyas in that area.) But... even then you're probably still in the "half a dozen chips" ballpark. From that point it should all be software.

Of course, this all said there might be easier hardware solutions than IDE. For instance, implementing an SPI bus to talk to an SD card would in theory only require 4 I/O pins you can bitbang. (Along with suitable voltage level conversion.) For something like that I sort of wonder if you could piggyback another VIA on top of one of the existing ones in the Mac and trivially decode it to give you a couple 8 bit ports to play with. Then you could either bitbang SPI directly, or use a port to talk to an AVR which acts as your disk controller. The resulting setup would probably manage to be at least somewhat faster than something connected via serial.

Anyway, blawblaw, dumb ideas.

 

[Gorgonops]

One reply to myself, above... ^

Thinking about it, an IDE port decoded as simply as the John Bass ROM-SCSI controller would probably conflict with the Mac Plus' SCSI controller. Most of the I/O in an "original" Mac is located above 0x800000, but for some crackerjack reason Apple stuck the Plus' SCSI into the ROM area as well. (Assuming the info in this regarding its memory mapping is accurate, that is. I only have "Inside Macintosh 1-3 handy, not the supplement that covers the Plus additions.) It's not a deal breaker per-se... one workaround would be to also use A14 or A15 in addition to the others for the IDE select. That would put its I/O well clear of the addresses documented for SCSI on the Plus... although whether that's actually true depends on how fully decoded the Plus' hardware is.

 

[James1095]

Even if this proves to be largely impractical, it would still be cool to see some workable hacks materialize. I'd never have expected the ROM hacks we have to come about, but they work very well. It's totally cool to be able to boot system software straight from ROM. All I need now is to set up a basic system with some disk tools and such in the image.

 

[Gorgonops]

Just tossing this out there too:

There is a really skanky technique available that would allow you to map a peripheral into a ROM socket that doesn't "see" write attempts. The idea is that you decode an address that when read, usually multiple times in order to act as a key so a "normal" read cycle doesn't trigger the peripheral inadvertently, unlocks a port for reading or writing. (The old Dallas "No Slot Clock" chips did this, allowing them to reside under a computer's BIOS chip.) Reading happens the usual way, over the data lines at a selected address. (You of course need circuitry to disable the ROM chip which shares the mapping's output.) To *write* a value, one technique I've seen (on a TRS-80 graphics board, I believe...) is to define a range of 256 contiguous addresses and use the location of a *read* inside that range to write the byte.

(The contents of a latch connected to the bottom 8 address lines would be used as the data value. Psuedocode write to such a device would look roughly like this:

WriteByte(WriteVal) {

BaseAddr=0x500100; # arbitrary start address of the block

PrepWrite(); # Call a routine which tells the hardware to expect a byte

WriteAddr=BaseAddr+WriteVal;

return Peek(WriteAddr) ; The return value is unimportant, although in theory you could design the hardware to return a status code.

} # End writebyte

If you want to write 16 bit words then obviously you'll need 64k's worth of contiguous address space for your address/data latch, which might get a little unwieldy.)

Thus, in theory, if you have the ability to churn out custom ROM SIMMs you might with a little work be able to embed the hardware to talk to an SD card or other storage device onto a *very* custom ROM SIMM. If said ROM SIMMs do indeed allow for a whole 8MB addressing range then you could dispense with the need to overlay this hardware over an active portion of the ROM, since no 68k Mac needs more than 1MB. (Well, okay, some of the Powerbooks have more.) Granted I haven't looked at what speed constraints we're looking at here, it may be even less forgiving than the PDS slots.

 

[bbraun]

Thanks for the information Gorgonops. I'm going to mull this over a bit. I'll be picking up a mixed lot of 20 compacts in the 512ke/Plus vintage tomorrow and will try experimenting with software for that era of machines. System6 changed a lot of the interfaces and possibilities, and I'll have to mess around and get a feel for what subset is available on earlier OS', ROMs, and address spaces.

I've eyed some CPLD dev boards and whatnot, the problem I have is assuming I make the time investment and come up with some workable hardware, the project basically dies at the layout stage, which is where I stop. Playing around with a development system is fun and all, but from a practical perspective it's not that useful if it is inaccessible to others. If we could use the Amiga guys' hardware and just reprogram the CPLD, that'd be pretty good I think.

 

[dougg3]

There is a really skanky technique available that would allow you to map a peripheral into a ROM socket that doesn't "see" write attempts.

This technique you described is exactly what I was proposing in the IIci ROM hack thread. It's very sneaky. I think it would work perfectly, but as you said there are speed constraints. If you wire something to the PDS, I believe there is a signal that allows you to acknowledge when you have finally put some data onto the bus after a request (correct me if I'm wrong on this). With that technique, I think a microcontroller could handle it. If you go through the ROM SIMM socket, though, the IIci's glue logic is creating that acknowledge signal and there's no way to override it that I know of. It creates a hard time constraint that you *have* to meet.

GttMFH says the IIci has a ROM access rate of 20 MB/sec, and the IIfx has a ROM access rate of 64 MB/sec. That's a great number to have but it doesn't really specify how quickly a chip has to reply with data after the output enable pin goes low--it just specifies the entire cycle time. Either way, my calculation puts the cycle time in the low hundreds of nanoseconds (20 MB/sec --> 20971520 MHz, but four bytes are read in parallel on each access, so really 5242880 MHz --> ~191 nS). So I think the actual time until data is good would have to be quicker than that. Unless my calculation is wrong and they mean 20 MB/sec per chip, in which case it would have to be even *faster*.

I just don't know if a microcontroller can respond that quickly. *Maybe* with an interrupt handler that is *never* disabled and *always* responds quickly, along with software on the Mac side that constantly polls until the data is ready?

Or, I hate to be the guy who says it, an FPGA? ;-) (You'd still need the polling logic in the software on the Mac side)

 

[Unknown_K]

You cans till find 50 pin working SCSI drives cheaper then the cost of any 3rd party interface could be made for, so why bother? I get the feeling most of the people asking are too cheap to shell out $20 for a functional 50 pin SCSI drive and therefore would not bother spending more for an IDE interface let alone pay somebody to design/sell one with a profit.

 

[techknight]

For the record, Even though an Atmel AVR probably really isnt suited for this task, I do have libraries that turn an AVR into an IDE controller, So you can hook CF or CDROM/HDDs directly to the atmel via IDE cable and talk to it. The fastest 8-bit AVR thats around i think is 20mhz. Most I/O instructions take 2 clocks. all internal instructions are single clock, few are 2. So any operation on the I/O ports of the AVR take 2 machine cycles. So the timing constraints would have to be within that window.

I played with this long ago and it actually worked ok, was able to read/write files directly on the HDD, via the AVR and issuing commands to the AVR from hyperterm, listing the directory structure, etc. (also had a FAT library loaded on the AVR as well). People made HDD based MP3 players back in the day using the same libraries, with the arduino around that probably has evolved, I dont know. But I dont use C or arduino anyway.

But the trick from that point is addressing the AVR on the bus of course, but then having a driver.

Thought ponder:

If I were to build hardware, I would find an empty address space in map it, Basically i would map a few bytes for control and signal commands for the peripheral MCU. Then the 512bytes that follow that would be the databuffer for reads/writes.

That would be all the address decoder would have to handle in that regard. So if i perform a write to the control/command bytes, it tells the AVR to write to what LBA location, or read from what LBA location. etc.. Then the following bytes would be your 24bit/32bit LBA addy, then the sector data.

Of course you would have to provision a fetch for max LBA Size or CMS which ever way you chose, so the driver would know the drive's capacity. Fetching Sector 0 from after that would tell the system the partitioning scheme, etc.. but you could just patch around the SCSI manager maybe? feed the sector data where the SCSI data would normally be so the MAC could boot from the drive, or handle raw drives instead of dealing with just image files.

I think you would need polling too, so the driver would know when the instruction to the AVR has completed, or data is available, etc... So toss a vector in the VBI. But first I want to make some free time and get the serial hardware done first to make sure it works. Then deal with this project.

Something to throw out there and let simmer for now I guess. But I am almost finished with this major R&D project for a display company, then ill get free time again on the weekends to work on this stuff. Its been killin me, projects backed up and no time :-(

 

[Gorgonops]

This technique you described is exactly what I was proposing in the IIci ROM hack thread. It's very sneaky.

Hah! I haven't really been following that thread so I hadn't seen it. Great (diseased?) minds think alike, or something.

Yeah, the lack of any sort of wait/handshaking signal on the memory bus does put a lot of onus on whatever you hang there to be able to respond in a timely manner...

Or, I hate to be the guy who says it, an FPGA? ;-) (You'd still need the polling logic in the software on the Mac side)

Well, I think you *could* probably get away with using a couple of fast latches between your decoded bus port (assuming here you're using a microcontroller to handle the SD card and just using the SIMM-port for message passing) and the microcontroller. Basically, what I'm thinking is a couple of 8 bit latches, one for reads and the other for writes, and a little bit of "glue" so:

A: For a read, the Mac would write the byte (via the address line trick) into the latch. Doing so would raise a bit on a status register (which is also "wire speed" from the Mac's perspective) indicating that a byte is waiting is waiting in the buffer, so the Mac has to wait. (that of course implies a polling loop.) Meanwhile, the microcontroller at its own pace can get around to reading the latch. Once it's done so it'll reset the status register, so the Mac can write another byte.

B: Likewise, for reads, the microcontroller writes a byte into the read latch and sets a flag indicating that valid data is ready. The Mac, stuck in its polling loop reading the flag register address, sees the latch is ready, snatches the value, and resets the "valid data" flag. (With a little cleverness presumably you could reset the flag automatically when the Mac addresses the read port.)

Looking at the data sheet for the 74HCT259 8 bit latch (which *might* be an appropriate part for both data latches) the propagation delay is in the 60ns ballpark. That might just do it.