Running SE/30 with Video ROM removed?

[Trash80toHP_Mini]

I'll have a PDS VidCard in there to run TattleTech in order to see if removing the ROM disables the Video implementation at PseudoSlot $E such that it disappears in terms of the Slot Manager's hardware polling.

WILL I BLOW ANYTHING UP IN THE PROCESS OF TRYING IT????? 8-o

 

[unity]

Every time you boot an SE/30 with no video ROM, a kitten dies.

 

[blitter]

That is the question.

 

[Themk]

I accidentally booted my SE/30 without its video ROM after my recap. Nothing happened. Well, other than there was no internal video on the periscope

(Oh and this happened only about two hours ago too. Can't believe I forgot to reinsert the EPROM)

 

[techknight]

Even with the ROM removed, your still going to get bus contention because the GLU/PALS are still there, and it will still attempt to drive the bus when $E is called during a read/write cycle, so your expansion card and internal card will try and drive the bus at the same time... Not good. 

 

[Themk]

I didn't have an expansion card installed at the time, so I didn't ever have a problem, but yeah I could see where that might lead to bus errors.

 

[Trash80toHP_Mini]

 SE/30 survived, scratch two kittens.

I was right, removal of the Video ROM disables the SE/30 video subsystem implemented at PseudoSlot $E so that to TattleTech and the Slot manager it ceases to exist. Same deal as with IIsi Vampire Video when no monitor is detected on the video connector at startup.

The Radius Color Pivot worked perfectly and as a bonus, I got the same type of, if not identical video gobbledegook on the SE/30's screen with the Video ROM disabled as I did in some other ludicrous test routine I documented somewhere. Pretty sure it was when I had the IIsi's NuBus Adapter hooked up to the PDS  .  .  .  curiouser and curiouser.

At any rate it looks good for testing a passive PowerCache adapter in the SE/30 with the Video ROM removed. It should work just fine as there would be no addressing conflicts with the SE/30's video subsystem in that configuration.

 

[Trash80toHP_Mini]

Even with the ROM removed, your still going to get bus contention because the GLU/PALS are still there, and it will still attempt to drive the bus when $E is called during a read/write cycle, so your expansion card and internal card will try and drive the bus at the same time... Not good. 

Dunno about that, the SE/30 is a IIcx and I just told it thatno card is located in Slot $E, so there's no reason for the system to address what remains of the video subsystem in that pretend slot at all, so where's the bus contention coming from? The GLU/PALs aren't being driven to do anything in that state, so they can't contend for the bus on their own?

 

[Trash80toHP_Mini]

Followup questions/observations for clarification:

Wouldn't the enable lines of components in the video subsystem need to be asserted for them to mess with the system bus?

The IIsi is a bit of a special case, it seems to me that Apple must have learned something about the evils of vampire video in the interval between it's development and that of the earlier IIci. Onboard memory of the IIsi is buffered from access by its video subsystem in the case that no monitor sense line encoding is detected on the DA-15 at startup.

There's dedicated VRAM on the SE/30 board, so that should act as a buffer from system memory by virtue of physical implementation?

From the behavior observed, it appears to me that the socketed Video ROM in the SE/30 would be a Declaration ROM for PseudoSlot $E whose drivers could be upgraded for compatibility with future system upgrades.That would be the same situation as in VidCard, other expansion card type DeclROMs and accelerator ROM upgrades that were eventually required for System 7 compatibility.

The DuoDock would be an interesting parallel to this SE/30 behavior. The Dock's logic board is a multipurpose expansion card on the PDS of the Duo, don't recall which slot ID that occupies offhand. That would make its ROM a Declaration ROM. Its removal disables all functions of the logic board that aren't hardwired passthru signals such as ADB or the independent NuBus chipset, which implements slots $C & $D. When the Dock's DeclROM is removed (interestingly, it was socketed on the Dock II for future upgrades) or disabled, the Video functions disappear and the LCD remains active, haven't thought that one through, but it poses an interesting question:

Since I'm planning on doing reassignments of the Gemini NuBus (upside down) riser card of the DuoDock for mucking about on the IIsi system bus, looks like I'll have to leave the interboard connector intact on my first passes at borking the IIsi. Reassigning one of the NuBus Slots of the DuoDock to the Dock's own ID could prove to be very interesting. h34r:

Please excuse the rambling, caffeine content in bloodstream has been wildly in flux, my eyes aren't quite fully open as of these final edits.

 

[Themk]

Nice finds! I wonder what sorts of hacks we could pull off with a modified SE/30 internal video DeclROM...

 

[techknight]

Dunno about that, the SE/30 is a IIcx and I just told it thatno card is located in Slot $E, so there's no reason for the system to address what remains of the video subsystem in that pretend slot at all, so where's the bus contention coming from? The GLU/PALs aren't being driven to do anything in that state, so they can't contend for the bus on their own?

Depends on how the logic on the board itself is designed. if the video driver has to load a register in the GLU to enable the select lines, then removing the ROM will work. 

If its hard-logic, then removing the ROM will have no affect on bus assertion because the GLU itself will decode the address for $E and try to select the video hardware onboard. But if there is a special register that must be enabled for the GLU to do that, then it wont. 

 

[Trash80toHP_Mini]

Hrm? I'm guessing the former, only the System RAM is buffered in the IIsi with the balance of the video sub-system remaining on the bus.

Running my proposed Prototype Passive PowerCache adapter will be easier than delving into the Greek morass of the SE/30 board schematic for me. It'll work or it won't, but it's academic. The reason for testing the unimplemented GAL state of the upgrade ready passive adapter is confirmation of my theory that Cache/Video addressing conflict is the reason active adaptation is necessary on most Macs.

 

[Trash80toHP_Mini]

Nice finds! I wonder what sorts of hacks we could pull off with a modified SE/30 internal video DeclROM...

Dunno, the second thing that pops up in my noggin' would be updating the Driver in the existing ROM. If that driver is the impediment, maybe we can push the maximum OS install up a notch or two past 8.1? Stupid OS tricks! [}] ]'>

The first is removal of the DeclROM entirely and clocking the schiznit out of the MoBo beyond the point of Video and FDD disabling to just shy of the point of disabling SCSI for the HDD and an external Zip used in lieu of the borked FDD controller. Higher Clock = faster RAM access = enhanced accelerator performance. IIsi ready VidCards and NICs should work just fine. Damn the periscopes, full speed ahead! [}] ]'>

< /Farragut >

 

[Trash80toHP_Mini]

Depends on how the logic on the board itself is designed. if the video driver has to load a register in the GLU to enable the select lines, then removing the ROM will work.

Not awake yet, but general info the docs indicate pretty strongly that this will prove to be the case.

Took a look at GttMFH2e and the IIci Devnote. In the latter I found Table 1.1 in the "History of the Macintosh II Family" section. It lists the architecture of the II/IIx/IIcx as GluChip/NuChip. So GLU was developed for the Mac II along with Slot Manager for handling all six NuBus slots. The SE/30's PseudoSlot "Video Card" is based on NuBus Slot $E and handled in the same manner as a NuBus VidCard.

I'll try to check Macintosh Family Hardware Reference (bound paper DevNotes for Mac II and SE) later after I finish my coffee. IIRC, the Slot Manager checks machine state for Declaration ROM reports from the six slots at startup. Pretty sure it tweaks the memory map based based on that hardware state. It stands to reason that this would include setting registers in GLU to reflect that state. Doing so should save a lot clock cycles during any given session by skipping over interrupt polling for empty slots?

 

[Trash80toHP_Mini]

http://www.mactech.com/articles/develop/issue_06/p72-79_Mac_Q_A.html

Q What's wrong with having VBL (Vertical Blanking) tasks make calls to the Macintosh Memory Manager, either directly or indirectly?

A The problem is that the Memory Manager could be moving memory around when an interrupt occurs. If the VBL task also moves memory, the heap could be destroyed. VBL tasks are intended to provide a method of time-syncing to the video beam of the display. (On slotted Macintosh models you'd use SlotVInstall.) They're also used to get periodic time for short tasks, although the Time Manager is better for this. VBL tasks should minimize execution time. The best use of a VBL task is to do a short condition check and set a flag for the main process to indicate that it's now a good time to do something.

Technical Note HW520 - NuBus Expansion Interface Q&As

The specific functions of the Slot Manager are as follows:

• Locate and list the cards with configuration ROMs (also known as declaration
• ROMs);
• Impose a uniform structure on the information in the declaration ROM and provide a set of library routines to access the information. One major advantage of this is that once certain sets of data structures are defined and made public, host applications may use information contained in the structures on any card regardless of vendor; Provide routines to allow host applications to transparently access information in the ROMs without regard to NuBus or byte lanes;
• Provide a mechanism for cards to have initialization code run on the host CPU during the host's startup sequence;
• Allow cards to have drivers in their declaration ROMs loaded into the host CPU; Initialize and manipulate the parameter RAM on the host CPU for the card in the slot during startup,

"initialization code run on the host CPU during the host's startup sequence" sounds a ot like like setting registers in GLU for any individual slot in the I/O structure to me. Someone would probably have to check Inside Macintosh or the Developer CD docs to confirm, but that's my WAG and I'm sticking to it.

Marginally related, but Interesting SE to SE/30 comparisons: Technical Note HW14 - Macintosh SE/30 Info

PDF fishing expeditions are more easily done while half asleep than opening a book pulled off a shelf that's within easy reach from the KBD.  :blink:    zzzzzzzzzzzzzzzzzzzzzzzzzzz 

 

[techknight]

My brain is automatically thinking this: 

two video cards plugged in at the same time, both set for Slot $E (jumpers) and one has ROM removed, one doesnt. 

what would happen? 

Thats the same scenario with the SE/30. 

But I know with a REAL nubus interface, you have the nuchip which does automatic enumeration, etc...

the SE/30 doesnt have this. So who knows? Plug in a IIsi radius card (the ones we were using in the SE/30 hack thread), and set it for Slot $E with the ROM removed from the SE/30. 

if it works we can lay it to rest. 

 

[Trash80toHP_Mini]

Hrmmm. Interesting notion, never thought about it because $E (probably?) isn't an available option, only $0-$A-$B are configurable on 030 PDS cards. :-/

At first pass, the NuBus test  wouldn't really be possible (maybe not even meaningful?) as NuChip handles the Slot ID lines hardwired into the MoBo and communicates with NuChip. But I'll have to look at Slot ID encoding research results I got for the DuoDock's Gemini Nubus "riser" for the two NuBus slots in a IIsi hack for $E reassignment possibilities. Withing limits, that board's easily hacked.The Dock's Slot ID is also $E and I've got a power line cutout hack for its DeclROM for other testing.

Maybe I can figure out how the jumpers on PDS Cards operate in the same manner? Then again, maybe it's finally time to place the Cap/Connector order so I can just go ahead and build the PowerCache adapter prototype to start testing the real deal?

 

[olePigeon]

That would pretty cool if the $E trick worked.  Then it would presumably think the Radius card is the onboard video.

 

[Trash80toHP_Mini]

That's how the system works, it rummages about in the I/O setup looking for something to use as the main display. With the Video ROM removed, the RCP/030 was tapped for main screen duty for the SE/30.

It's too bad the PowerCache messes with memory mapped to $E, or it might be possible to run a card set up for Slot ID $E along with $9, $A & $B. I may have to try that in the Rocketized SuperIIsi at some point. It'd be a real hack job because the signals for that slot aren't present on the PDS for either system.