Skip to main content
Home▸ Forums▸ 68kMLA▸ SuperIIsiHack™ AKA SE/30's BANE . . . — #15
Post #15 by bbraun
Source Forum68kMLA
CategoryHardware
Post DateSat, 18 Feb 2012 - 18:48
Original URLhttps://68kmla.org/bb/threads/superiisihacktm-aka-se-30s-bane.24674/
Post
Yeah, the Nubus/PDS report seems about right, since that's what is physically present (from a certain point of view...). I haven't seen anything obvious that would let me probe from software the presence of a slot, particularly if it is empty. I might just be missing something, my knowledge of the area is woefully incomplete. But, I've done a fair bit of reading on the subject and haven't come across anything obvious, so continuing on that line of thought, if there isn't a way to probe the presence of a PDS slot, only the presence of devices on the bus (which may be present through a PDS slot, we don't really have any way of knowing), then that one PDS slot/no nubus report is based on inferred information. Such as knowing you're on a IIsi and IIsi's have a single 030 PDS slot.

What I'd really be interested in is if you have an 030 PDS card that uses a pseudoslot, and you can configure it for slot C or D. Most should only be configurable for slot 9-B since at least on an SE/30, those are the only fully functional pseudo-slot IDs, since there are only interrupts for those slots. The Asante MacCon card should allow configuring in 9, A, B, and I think E (but SE/30's video uses E, not sure about IIsi). You might be able to do some hackery to get it into C or D... If you somehow managed to get something into slot C or D, without an interrupt line (we don't want it inadvertently using a different slot's interrupt line), it would be interesting to see if the decl rom is present and if any decl rom driver is loaded. Any such driver might not actually work since there's no interrupt line, but the presence of the decl rom and driver would indicate the slots are being mapped properly (I haven't seen any indication they aren't, but a real world check is good). If the driver's Open routine fails (possibly due to missing IRQ line, who knows), it may stay loaded in the unit table, but be unavailable to higher level software. If it stays loaded in the table, that's smoking gun evidence that the decl rom was found, parsed, and driver loaded.

Ever since my first shot at that memory disk driver, I've been working on and off on a tool to examine drivers present in the unit table. That tool would be useful for determining whether the driver. You can traverse the unit table with macsbug, but it's not pretty.

I also seem to recall some of the early developer cdroms from Apple had declrom utilities to aid in the development of cards. One of those might be helpful. The MESS guys also had a tool for dumping declroms, I haven't run it, but that might also be helpful.