• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Dream peripherals (the return)

It wouldn't be hard at all to make an IDE or even SATA NuBus card... ACARD makes SCSI-IDE and SCSI-SATA chips that support more than one device. Take a blank NuBus card, throw together the easiest 53c80 SCSI card possible, hotwire it to the ACARD SCSI-IDE chip, and break it out into two IDE or four SATA ports.

I mean, most of us dont' have the gear at home to do that tomorrow, but the drivers and circuit design are already done, which makes it a lot easier to throw together than these more exotic plans are.

 
I think a bootable IDE interface for eg. LC PDS or NuBus would be almost commercially viable. As more and more 50 pin SCSI hard drives fail...

 
and IDE drives are quieter. you could make a LC webserver taht actually would be useable and could run 24/7 without keeping me awake with the noisy HD ;)

 
ACARD makes SCSI-IDE and SCSI-SATA chips / Take a blank NuBus card {&c}
First up, Nubus is an intelligent protocol and it requires a Nubus controller IC on each card. So you've either got to find those (hah!) or reverse engineer one, then build something to emulate it. It's hardly a "throw together", and there's been plenty of discussion around these parts as to why not.

Second, can these ACARD chips be bought on the open market as bare chips, in small enough quantities and cheap enough to make it viable? IE, quite a lot cheaper than buying the complete SCSI-IDE converter

Thirdly are you sure it's just a single chip and not a combination of chips on the SCSIDE boards that do the magic, including say a proprietary ASIC that ACARD is unlikely to want to sell or just hand out the design? Seeing as they have this profitable line in converter cards we want to undercut.

All of the above being good reasons to go for a fresh PDS design. Yes, I agree it would be best if it -pretended- to be a known SCSI device so we can use existing drivers. How about the fast SCSI PDS controller from the WGS95?

 
First up, Nubus is an intelligent protocol and it requires a Nubus controller IC on each card. So you've either got to find those (hah!) or reverse engineer one, then build something to emulate it. It's hardly a "throw together", and there's been plenty of discussion around these parts as to why not.
The NuBus card requires a little logic to handle arbitration properly, but it's really not very complex from a logic design point of view. It's the kind of thing which will easily fit into a handful (or less) of cheap PLDs now days.

Second, can these ACARD chips be bought on the open market as bare chips, in small enough quantities and cheap enough to make it viable? IE, quite a lot cheaper than buying the complete SCSI-IDE converter
Don't know about that, but if they can, you probably must buy thousands at a time. I doubt that the market is much above hundreds.

Thridly are you sure it's just a single chip and not a combination of chips on the SCSIDE boards that do the magic, including say a proprietary ASIC that ACARD is unlikely to want to sell or just hand out the design? Seeing as they have this profitable line in converter cards we want to undercut.
Just two chips. The bridge chip and a Flash ROM to hold the configuration code.

All of the above being good reasons to go for a fresh PDS design.
Economics, economics, economics...

The SCSI-IDE converter requires one chip per device. So, if you want the equivalent of two ATA channels, you would have to put four SCSI-IDE chips on your card. On the other hand, there's not that much room for drives in most of the machines, so two SCSI-IDE chips would probably be sufficient.

A single FPGA large enough to do the job (two or more ATA channels, with two drives each) would cost less than $30 bought one at a time. But someone must do the skull sweat to make it work.

Performance: A SCSI interface based on the 53C80 is going to be sloooooowwww. Plus the 53C80 isn't exactly cheap any more. It's moved into the realm of "legacy" parts. If you use a 53C80 as the root of your device, you're going to be taking 40 MB/s NuBus and feeding it through 3 - 5 MB/s SCSI to reach a 20 - 60 MB/s (large dependencies on generation of IDE drive used) hard drive.

An FPGA based solution offers potentially cheaper implementation and much much faster performance. Especially if one builds it as a PDS card rather than a NuBus card, where the data and address busses are not multiplexed and the bus speed is faster.

In fairness to the originator of the 53C80=>SCSI-IDE idea, I think he was just thinking of something we could build now, without investing a lot of time in design. He wasn't optimizing at all for cost or performance.

But at that point, I think you may as well just get one or more Acard AEC-7720Us. I still have a few at $39 + ship. There is an outfit on Ebay with hundreds of them for $30, but they don't include the power cable, nor the instructions and their inflated shipping makes their price comparable to mine.

Yes, I agree it would be best if it -pretended- to be a known SCSI device so we can use existing drivers. How about the fast SCSI PDS controller from the WGS95?
This is about the only way to do it, but on machines pre-660AV and 840AV (IOW, every 680x0 machine except those two) one must basically rewrite the SCSI Manager 4.3 support and add it to the device's firmware. This is probably not trivial.

 
There were a bunch of people posting their desire to see a universal NUBUS adapter, one that allowed the connection of many modern peripherals such as usb flash drives, parallel port devices, CF cards, ect. I had a wild idea when I took inventory of all the IC's I have lying around. What if you constructed a card that flowed like this:

LCIII PDS (for example)

|

(x2)Ethernet LAN controller (one to an external port)

|

DOS-based PC-on-chip/single board PC, this device would be capable of translating attached devices so that they appear to be network-shared devices. The Mac would not need usb mass-storage drivers, as it would see the flash drive as mapped network drive, same with CF cards, cd-roms, and other peripherals

|

USB, ATA, Serial (COM), etc controllers. The PC-translator would make these appear as standard device types, a USB scanner would appear to be a SCSI scanner. ie. The mac sends a command to a SCSI scanner, the PC chip translates that command to what a USB scanner would understand, and vice-versa.

I would love to build this thing, but I do not have the EE expertise to pull it off. I can design simple things, but nothing like this.

 
A processor upgrade for the dual 1.42ghz FW800 MDD G4. That's all I want.
I think there's a web site where some fellow took his MDD dual up close to 1.6 GHz. Since you won't get much bettter than 1.8 GHz from upgrades (IIRC) that's pretty good.
The MDD machine I am typing on now is a dual 1.83 Ghz PowerPC, i bought as a stock upgrade. Boots Mac OS fine (the reason i got it) (9.2.2) . Uses both cpus in os9. i do not have proper cooling to play timing boost games.

Its a Encore MDD MDX Duet for xServe or MDD

Sadly I lose the third level of cache (L3 cache) with this card, but it has a much larger L2 cache so i do not miss Apple's L3 cache.

In all benchmarks I am more than pleased. It was a ton of money, but in a few months it might be impossible to find, as all things are if you wait forever. The other reason I did it was that I had only one CPU in this web browser/gaming machine. So for me the ton of money was worth it, because I need os 9.

I built a 4 cpu hackintosh for dirt cheap i use for development on (Apple requires x86 for iphone development, unless you use the third party non-apple iphone compiler and hacks) : Hackintosh = 10.5.2 = Kalyway + iATKOS

The engineer from Newer Technology that figured out how to put ANY cpu into almost every mac product on earth, left the business about 3 years back or so. That is one reason we have no G5s in our g3 and g4 machines. His name is Ben M. He works for the main competitor of Scientific Atlanta now doing all sorts of hacks for older cable boxes to squeeze new firmware code remotely into old existing boxes.

 
I finally read this thread.

I have written many award winning scsi drivers, as well as designed SCSI host bus adapters (HBA) for the macintosh. In fact I an a main author of what was used by 18 different companies such as Club Mac and APS and Atto and many more (Apollyonics SCSI Director allowed rebranding), and I wrote every line of cd products such as FWB's CD-Rom Toolkit 1 and v2. I also rewrote the USB Mass storage class for OS9, and did a dual port dual 2 gigabit FibreChannel card for OS9. I've done RAID, SATA, ATAPI, Ultra DMA, firewire, and done many many more than those things for I/O hardware. I own the copyright in many cases, and could leverage code if needed to such a ide/sata I/O product.

Adding a SCSI Manager 4.3 "XPT layer" (for ancient machines) is not impossible or hard. FWB did it (loaded a clone of a fake SCSI Manager 4.3 on non 4.3 compatible macs). So many macs allow SCSI Manager 4.3, except for a couple powerc laptops, with system 7.5, that such a "dream nubus card" would not be too restrictive if limited to machines that run 7.5 and had a standard NCR 53C96 SCSI controller chip.

But running ide drives on old mac hardware, whether Nubus or PDS is not what I care about in this dream peripheral thread ...

All I want is someone to figure out how to add a real genuine existing Motorola 333 MHz 68060 chip (V5 core) into a 840AV or other AV. With dual execution pipelines and a larger branch cache, this next-generation core provides a 2x performance increase compared to a 220 MHz MCF5407 device, a V4-based standard product

The chip was announced at Oct. 19, 2002 many years ago !

Because of issues of incompatibility with 68060 though, even though there are royalty-free and price-free software library tricks to make it work, a 68040 emulator is needed, and that is how Amiga people get the 220 MHz MCF5407 device to run their 68030 code.

here are raw diffs, without software exception handling :

http://www.microapl.co.uk/Porting/ColdFire/cf_68k_diffs.html

Think of the chip as a 610 Mhz chip conceptually though, not a 333, because of its internal design. It gets 610 MIPs in benchmarks.

 
Adding a SCSI Manager 4.3 "XPT layer" (for ancient machines) is not impossible or hard. FWB did it (loaded a clone of a fake SCSI Manager 4.3 on non 4.3 compatible macs). So many macs allow SCSI Manager 4.3, except for a couple powerc laptops, with system 7.5, that such a "dream nubus card" would not be too restrictive if limited to machines that run 7.5 and had a standard NCR 53C96 SCSI controller chip.
Would you provide additional information on how one modifies SCSI Manager and puts it into firmware in a way where it can take over the SCSI Manager function? I know FWB did it on their JackHammer, but I have no idea how the did it.

The JackHammer works on 53C80 based machines too. I don't think the 53C96 is really a requirement. If one limits an expansion cards to machines with a 53C96, one eliminates all but the Quadras (and later).

 
Driverguru: There's a couple of 68060 threads here that discuss issues and possible approaches. They're possibly worth your time to peruse.

I'm curious about this:

MDD / Uses both cpus in os9.
Everything I've heard to date says that's impossible, with the exception of Photoshop with the necessary plugins.
 
Everything I've heard to date says that's impossible, with the exception of Photoshop with the necessary plugins.
Logic is MP aware too, but yeah, you're not going to get the Finder to use a separate CPU for a separate window... you need BeOS for that..

 
traq,

I do not know if your response was in regards to my written words, but my written words precisely were :

"Adding a SCSI Manager 4.3 "XPT layer" (for ancient machines) is not impossible or hard. FWB did it (loaded a clone of a fake SCSI Manager 4.3 on non 4.3 compatible macs).

So many macs allow SCSI Manager 4.3, except for a couple powerc laptops, with system 7.5, that SUCH A "dream nubus card" WOULD NOT BE TOO RESTRICTED if limited to machines that run 7.5 and had a standard NCR 53C96 SCSI controller chip. "

The above sentence takes the time to point out that FWB (jackhammer) adds scsi manager 4.3 on non 4.3 systems, but also that if a system did not have native 4.3, i do not mind so much because many do.

OF COURSE you do not need a host scsi chip or a particular host scsi chip or ANY scsi manager (none) to support installing hand made 4.3 scsi manager on a mac. In fact, the jackhammer by FWB did.

As to how, its not magical. There is a single trap for SCSI manager 4.3 that you must check to see if it is present in all programs written, and a person merely installs the trap when their library is loaded, no modifications to any firmware or code or even old scsi manager is needed. Check_Trap_Available(0xA089) _SCSIAtomic trap = 0xA089

SCSI Manager 4.3 is actually not an apple technology. It is an open standard (SCSI CAM) that , once again, mainly apple used. It is a great new way to do scsi but lacks many critical features allowed in the old SCSI manager, but also provides many more new ones. Missing features include microsecond accurate timeout specification (or millisecond for that matter), and no way to specify a RAID scatter gather span loop in a couple integers, (you had to construct a huge giant list of every scatter gather span for no reason except idiocy on EVERY single large IO even if the striping was uniform and predictable.

FWB installed hacks into their SCSI manager 4.3 to allow scatter gather to not have to be anally specified like that for speed, and FWB also allowed short timeouts, and eventually, I think Apple did too, by honoring top bit as flag for high precision timeout, i think.

SCSI Manager 4.3 is the open standard of "CAM" Common Access Method

described here in a short tutorial for unix

http://www.rcnp.osaka-u.ac.jp/unix/DOCUMENTATION/HTML/AA-PS3GD-TET1_html/camosf2.html

Adaptec bought and CANCELLED all scsi card companies that had CAM and shut CAM down on Windows 100%.

Adaptec bought over 9 competitors.

Writing a SCI Manger 4.3 layer is semi trivial in one regard, it is merely the XPT layer. A thin layer, with lots and lots of apple specific information calls.

Allowing a Macintosh boot device control panel to select a CAM based (Scsi manager 4.3 device) provided early in boot time, is covered briefly in : http://developer.apple.com/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/PCI_BOOK.23f.html

SCI Manger 4.3 is way cool in these two properties :

1> it is not polled with any apple hacks, it runs entirely under interrupts, except when interrupt are all turned off, and you are in a low level debugger (Macsbug, T/MON) and the debugger is feeding it using the pool feeder so data can be logged to disk while debugging, similar to the poll feed of a etehrnet card debugger nub

2> Thousands of pending I/Os can be issued at the same time (I have done 7,000) all with callbacks too. I think SCSI callbacks can be provoked to trigger and interrupt the macintosh for high speed honoring completion NO MATTER IF ALL THE USER ACCESSIBLE INTERRUPTS ARE TURNED OFF. It can even interrupt in the MIDDLE of a memory page fault handler already running. It is a breathtaking spectacular design of efficiency, that makes ATA, Firewire, USB, etc all look like sick crap. Mainly on the issuance and transfer side of the operation. (good programmers avoid using completion tasks in any I/O design needs).

(To specify a general purpose high speed timer callback to be able to do that same trick (interrupt in the MIDDLE of a memory page fault handler already handling a page fault) you do the following undocumented trick using the magic value in a field normally filled with 0 : ) timer_Data.qLink = (QElemPtr) 0x65616461 )

if you search Google for : 65616461 apple … you will get 0 hits (except maybe this page you are reading now), but 65616461 is safe, system wide, legal, and works. I think apple mentioned it in writing eventually once. If not… ooopsie.

Apple uses magic values in their OS for their own engineering uses in other places too. One for PowerPC machines is passing Gary Davidian’s birthday in a register from user-code land sent to the real PowerPC Kernel.

Ohhh, by the way, the reason some engineers (not me) play fast and loose with honoring a millisecond precise timeout in a SCSI CAM call, (SCSI Manager 4.3) is because the design has a glaring defect, and uses SECONDS (yes seconds !!!!!!!!!) as the minimum resolution for bus timing measurements or other events). FWB and Apple both refused to honor that in their own versions of CAM. Proof ? This --> "From the Common Access Method (CAM)

10.1.23 Timeout value

This field contains the maximum period in seconds that an issued SCSI command request can remain outstanding."

Idiocy amazes me sometimes. Polled Firewire and Polled USB do not, though, they are the product of the type of engineers apple hired.

HURRAY FOR CLEAN PURE PERFECT SCSI !

 
I'm curious about this:

MDD / Uses both cpus in os9.
Everything I've heard to date says that's impossible, with the exception of Photoshop with the necessary plugins.
Not true,

There was a MP version of the 9500 in the 1990's!

Umax made a MP 3rd party model too! (I wrote a driver they sold with each Umax))

Apple has had various official MP (multiprocessor) libraries for years for people writing vertical market solutions to PROPERLY share multiple cpus on a mac. Even mass market software uses MP under os 9 :

Premiere, DeBabelizer, iMovie2 and SoundJam MP Plus 2.5.1, Adobe Photoshop 6.0.1(Gaussian Blur, Unsharp, Resize, Rotate Canvas, Render Lighting effects, etc etc)

Parts of QuickTime are MP-aware

"Impossible" is a powerful and absolute word. Luckily it has a concrete meaning. In this case the it is shown that IT IS NOT IMPOSSIBLE.

Unless you are referring to my brand of card somehow being defective under OS 9's MP library from apple. I did not remove Apple's MP plugins and assume it is working fine.

 
No, I assumed that by "under OS 9" you meant that the OS was capable of using both CPUs itself. I had a hunch there were other MP aware programs apart from Photoshop, but they weren't coming to mind at the time.

 
Thank you DriverGuru. I don't have time to digest your detailed post right now, but I appreciate you taking the time to share all that information. It really sheds light on some things which are still rather opaque after reading Inside Macintosh.

 
^-- hear hear. I'm reading and attempting to digest, too, although trag's probably going to digest more of it than I :)

 
The c't journal has a column c't-lab. It provides the complete know how to make a computer controllable multi purpose instrument for measuring and signal generation, a programmable source/sink and other components that are required for research and development of electronic hardware hacks. Communication is possible using a port and software/system of your choice (RS232/USB/Ethernet, use just HyperCard, LabVIEW or even a simple terminal programme).The required PCBs and microcontrollers can be obtained separately (I would strongly recommend the kit-supplier Segor in Berlin), if you do not want to etch the PCBs and to program the controllers to customize them for the given purpose. The author Carsten Meyer sometimes tends to design things a little better than required. In the issue #16/2008 he provides blueprints for some module announced as a frequency counter. In fact it turns out to be a full fledged FPGA module to make anything you can think of using 400000 gates at a rate of 50 MHz or more (Xilinx XC3S400). With help of some knowledgeable fellow of the 68kMLA even strange things might be possible, like this Asteroids emulator with an old oscilloscope tube as a display :-) The c't lab project might be a good start to learn anything you would need to make your personal dream peripheral. Any of the c't-lab modules can be used stand alone, no need to manufacture a multimeter, when you already have one.

Caveats: you will need some basic knowledge of German language, soldering gear for electronics, a few bucks and plenty of time.

 
What do people think of the Natami project ?

http://www.natami.net

Its an Amiga clone, but could it be modified for Mac ?

The new developer boards will be available end September 08.

Motorola 68060 cpu @ 90 MHZ

16 MB, 5ns SRAM

256 MB RAM

FPGA based gfx, SuperAGA @ 150 MHZ, 24bit (PS2 performance)

FPGA based Audio

2x PCI,VGA,IDE

The new N68070 cpu is designed from scratch and will be like a 68040 @ 200 MHZ. With highly optimized instruction set, it will replace the hardware cpu and put into FPGA.

http://www.natami.net/68070.htm

I believe, without too much work, a good machine can be built and being FPGA based, can be upgraded at will.

What do people think ?

Just thought you should know, before these high demand boards go into production.

 
Interesting, in that

The goal of our new advanced 68K CPU is to provide a higher compatibility to 68000 games than the 68040 and 68060 CPUs / to exceed the speed of an original 68040 clocked at 200Mhz for normal applications and / 600 Mhz for multimedia applications. /

ColdFire is 68k compatible, but / patching of Kickstart and Workbench will be mandatory.

By going for our own N68070 design we will save any patching and time.

/

when our 68k FPGA CPU is finished the Natami60 board could install it into their FPGA with a simple firmware upgrade.
but vaporware, and not immediately useful to us. The AGA implementation for example is useless to us.
 
Back
Top