-
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.
ATTO SiliconExpress II - Clone a Fast/Narrow SCSI2 Card?
- Thread starter Trash80toHP_Mini
- Start date
Indeed. The two HY6264A Series parts to their right would be low power, non-volatile SRAM for faster memory on the 68000 subsytem. Is there a trickle charge available on NuBus when asleep or shut down states or would they just be loaded load from ROM at startup?
Difference Between SRAM and DRAM (with Comparison Chart) - Tech Differences
The common difference between SRAM and DRAM is that SRAM uses transistors and latches while in construction while DRAM uses capacitors and transistors.
edit: just how small can the CPU subsection become with current SMT parts, quarter sized? SMT 68000 package is pretty dang small in comparison.
Assuming here that ROM/SRAM packages would be same reduction is size of smaller yet?
Last edited:
Is there any insurmountable problem with excising the entire NuBus interface and doing whatever necessary in order to hook the remainder of the card directly to the 030 PDS? AI playtime commences. 
Methinks @Melkhior might have some interesting things to say about getting around the card's NuBus implementation bottleneck?
68kmla.org
Methinks @Melkhior might have some interesting things to say about getting around the card's NuBus implementation bottleneck?
NuBusFPGA: HDMI on NuBus Macs
Hello, I've mentioned my crazy project of interfacing a FPGA (board) with a NuBus Mac in another thread. I'm opening a new dedicated thread as there is a significant update now: This show the naked PCB on the left, the populated version without the required daughterboard in the middle, and the...
68kmla.org
Last edited:
That is exactly what I'm saying. You excise that controller, which is the nubus interface among other critical functions, the card ceases to function as a coherent whole and the parts that are left are unusable. You would need to 100% replace it with an identical implementation in a FPGA if you wanted to make use of the original code.Is there any insurmountable problem with excising the entire NuBus interface and doing whatever necessary in order to hook the remainder of the card directly to the 030 PDS? AI playtime commences.
Methinks @Melkhior might have some interesting things to say about getting around the card's NuBus implementation bottleneck?
NuBusFPGA: HDMI on NuBus Macs
Hello, I've mentioned my crazy project of interfacing a FPGA (board) with a NuBus Mac in another thread. I'm opening a new dedicated thread as there is a significant update now: This show the naked PCB on the left, the populated version without the required daughterboard in the middle, and the...
Otherwise, you're building a new card from scratch with all that entails.
1. NuBus and PDS devices need quite different driver structures. I designed a horrible, slow RAM card for the NeXT Cube for which the NuBus itself was the bottleneck. The NuBus structure is a fun exercise in waste by segmenting resources with a veneer of civility hiding layers of needless transactional barf.
2. Proposing a project, then being told chip X is mandatory so pivoting to a completely different project while ignoring the new problems that introduces is a bit tiring for those who actually have written extensive drivers. I think ZigZagJoe is one of those people and if he cries uncle you should probably listen to him.
The 53C9X family of SCSI controllers is well understood by various MacOS versions and in this case a DPS 53CF94 gets you fast narrow SCSI. However, the Mac already has this, so implementing it a different way when there's already plenty of good choices available seems to be a distraction from actual boundary-pushing work.
That's about what I thought based upon interactions in previous project threads in the forums as well in the PM SkunkWorks..
I am, but giving up on the impossible dream of Fast SCSI II in my SE/30 is a bit difficult.
Fanciful Stretch Goal's not a serious suggestion, just what I find to be an interesting side note for my topic. I've learned so much from folks over the years by getting shot down just like this. Learning for learning's sake is important to me.
Sorry if you find it tiring, pretty sure this presents a learning experience for many of the non-coding folks lurking about this mess.
However, on that insane NuBus/PDS front, awaiting input from @Melkhior who's put his HDMI Vidcard on both NuBus and 030 PDS. Hope combined with craziness and and idiocy springs eternal.
You get the exact same benefit by replacing Fast SCSI with Wide SCSI.....but giving up on the impossible dream of Fast SCSI II in my SE/30 is a bit difficult.
That said, the 53C94 (8 bit SCSI-1) was used in early NeXTs, and the 53CF94 (8 bit SCSI-2) brought fast SCSI with the exact same driver as the IC auto-negotiates capabilities with the drives transparent to the driver. Other higher members of the 539x family supported fast wide, differential and further while maintaining complete backward register compatibility in many cases. I think the only thing is persuading the 68K to treat the portal as 16 bits instead of 8 and maybe some driver modifications to allow for best strategies to take advantage of larger FIFOs.
Very, very cool stuff, thanks for that explanation.
Glad to see how you and others are so well versed in Paleolithic I/O Architectures. Like I said earlier, I see some tidbit or connection in the collection, posts about this or that here a/o my extensive reference book collection or other. Then I do my best to cast such upon the waters for competent folks like yourself to take a look at when they sometimes make sense.
Glad to see how you and others are so well versed in Paleolithic I/O Architectures. Like I said earlier, I see some tidbit or connection in the collection, posts about this or that here a/o my extensive reference book collection or other. Then I do my best to cast such upon the waters for competent folks like yourself to take a look at when they sometimes make sense.