Search results

Apple had a lot more volume than workstations/servers vendors using SCSI. Once the connector was introduced with the Plus in '86, device manufacturers started using the DB25 for Mac-oriented products - cheaper cable! Once those were available, some other consumer-focused manufacturers unrelated...

Blame Apple for a cost-cutting decision there... SCSI wasn't using DB25 ; it was using much larger 50 pins Centronics connector with physical lock (e.g. such as this) or even larger DB50 (e.g. this). Later SCSI-2 switched to a much denser 50-pins connector (e.g. this). They all have 50 pins...

As @Phipli said, it's mostly a performance issue. All emulation layers have a overheads, and needs additional space in the D and I cache to be able to do their job. Ideally, they can be full resident as close as possible to the core (basically, L1), plus extra space to actually usefully cache...

Very useful to bootstrap examination of the ROM and in particular stuff like the MMU setup. Seems on the '040, unlike on the '030, Apple is using the transparent translation registers instead of using pass-through mapping for the I/O areas. Thanks for sharing this!

It is, the Q800 emulation in QEmu was instrumental for me in implementing the Declaration Rom for the *FPGA, and developing/compiling the associated INITs (for acceleration and hdmi-audio support). In fact, I suspect QEmu has actually been my primary Mac 68k machine for a while :-) Is that...

vpPackSize is a word in the documentation (DCDMF3 Table 9-2), but a long in my own (known to work!) DeclROM. It's also a long in the sample ROM of DCDMF3 (page 548 a.k.a. 589 in the PDF), which I used as a reference as the beginning of my work. I guess someone didn't proofread Table 9-2...

Mmmm, that looks suspicious to me. The values for vpCmpCount, vpCmpSize and vpPlaneBytes are really weird. Also, you're missing an entry for vpPixelSize immediately after vpPixelType - so maybe the end of that is not well decoded. vpPackSize is also missing after vpPackType, but maybe the two...

Not really, just put 1 if in doubt that's always legit :-) Originally I suppose the intent was double-buffering or other optimizations - each "page" can hold the entire framebuffer and can be used as the source of data to display, so you can switch what is displayed very efficiently. Can be...

You also need to patch vpRowBytes for the stride between lines (depth times horizontal resolution is the minimum, exact value depends on how the HW behave...). If all resolutions in the DeclRom uses the minimum value, it's easier, the HW can do anything just use 1600 (if you're in 8-bits). If...

Mmm, you are right. It's not in Control, but in Status. And from my comments and the implementation (just an illegal instruction...), it's never called in any of the Systems I've tried. ... which also means the current DeclRom for the NuBusFPGA might not be compatible with A/UX, if A/UX does...

I agree that it's (emphatically) not a practical possibility, but the culprit would be the software IMHO (as it almost always is). Xilinx has both PCI and PCIe root port available for their FPGA, and there is bridge chip available both ways. Hardware-wise, mapping a PCIe root port in the slot...

I don't think there's a selector to read back from the CLUT - just to set it. So reading back from the CLUT isn't needed. Only the framebuffer memory is used directly by quickdraw, in whatever format the driver has specified (8-bits indirect, 146bits direct, ...). Everything else is purely...

On the commercial side, there would have been no point contemplating more than 8 MiB of memory in a machine introduced in 1984 (the original Mac). The odds of memory becoming affordable enough to justify putting that much memory in the lifetime of the machine were pretty much zero, and the CPU...

Indeed, standard XGA is only 65 MHz. In fact, standard 1280x1024 (60 Hz) only requires a 108 MHz clock. Assuming lower depth (probably no more than 16 colors/4 bits) to fit in the available VRAM, it might be within reach. Even it the HW can't reliably do 108 MHz, it might be possible to lower...

I don't know the SE/30 - an angle might be necessary I suppose? The second DIN connector would have to be right-angle, not straight, same as the first, unlike in the IIsi adapter; of course. Signal propagation in a PCB is very roughly half the speed of light, so you need about 15cm (half a...

Perhaps you could just add a passive PDS adapter so the card would sit in a slightly difference place? Just need to figure out where it needs to be and do a very simple PCB with a pair of DIN connectors. Basically a simplified version of the IIsi adapter; you can find an example in my github...

Quite. Starting with scrolling, which are simply fb-to-fb copies if not double-buffered (I'm talking 7/8 here, likely older as well, dunno 9 but I'd expect similar). That's where acceleration is the most useful, as it avoid doing slow read-then-write over the bus (twice), the acceleration egine...

It can be greater (or lower! at low depth), it's the number of bytes a row occupies - including potential padding if the hardware has some specific requirements. No, but at least 640. For 640x480x1, minimum would be 80 - each byte contains 8 pixels. Yes, that's the idea. While pure 'dumb'...

NuBus is a 'true' bus, so pretty much all the pins/signals are common through all the slots. The exceptions are the ID pins (which are either floating or tied to ground on the motherboard) and the NMRQ pins (non-master request, a.k.a. interrupt, one per slot). So odds are, if one slot fails...

The Slot Manager view of the system, which is limited to a bunch of 'slot manager resources'. Structured data describing the hardware, coming straight from the Declaration ROMs. Slot 0 is conceptually the host itself, NuBus & PDS live at $9 to $E. That's not good. IIci should have slot $C, $D...