Jump to content
  • Posts

    • On my IIfx and Q950, the 'Serial Switch' control panel will enable a 'Faster' setting and a 'Compatible' setting in Mac OS. It could still be an over-simplistic method of engaging the IOPs, similarly to how the A/ROSE methodology allowed for complex co-processing, but in reality was only really implemented with memory move operations to reduce the number of interrupts the 030 directly deals with. There's still a dramatic difference when the 030 is under load while A/ROSE is utilized, despite this simplified implementation. Similarly, perhaps when data is relayed to the IOPs, the 030 is able to move to the next instruction faster than if it needed to control the serial directly.   I know A/UX is absolutely required to make use of the SCSI DMA onboard the IIfx and available with the WGS95 Pisces card, so it would make sense if A/UX also gave the IOPs more thorough attention.
    • I've been trying to get a Daystar P33 accelerator (50MHz 68030) working in an SE/30 with one of @Bolle's amazing adapters -- in this case the model from the early 2020, short form factor with Asante ethernet card underneath.   The P33 itself is faulty in some odd ways which I'm trying to figure out. Thanks to @james_w we've been able to make comparisons between this P33 and another known-good P33, and also between my Bolle-adapter and the earlier "tall" type Bolle-adapter that James has.   The SE/30 runs with the P33 inserted, but it locks solid when you try to open the Power Central control panel in the Finder. Loading Power Central at boot also locks the machine if and only if the P33 cache is enabled. (To test this I would remove the P33, change the settings, and reboot with P33 inserted again.) Other symptoms are that the floppy drive (including Floppy Emu) doesn't work with the P33 inserted (shows "disk unreadable"), and that a Radius Color Pivot card in the passthrough slot doesn't work, although it works fine without the P33 and Bolle-adapter.   I spent a lot of hours with MacsBug and eventually traced the freeze down to an instruction which reads memory address $52070000. I can open a debugger, type DM 5207000 and it locks. This address appears to be some kind of register on the P33 card. Other addresses accessed in the Power Central control panel include $520F0000, $52050000 and $52040000. None of these lock the system.   James's known-good P33 does not exhibit this lockup problem, so there's clearly a problem with the card (maybe faulty cache RAM?). But here's where it gets weird:   If we put the bad P33 in his Bolle-adapter, the floppy works and the Radius card works.    If we put the good P33 in my Bolle-adapter, the floppy works and the Radius card works.   So it's only the combination of my Bolle-adapter and the bad P33 that produces the other symptoms. Any ideas what might be different between models of this board? Any other thoughts on what to look at on the P33?  
    • My understanding is that on the Mac OS, Apple never took advantage of the IOPs in the IIfx, and just put them in pass-through mode so that operations to the 53C80 and 85C30 were just like on any other macintosh, except that the signals happened to pass through those microcontrollers.   Reportedly, A/UX did make use of the IOPs.   Does the Mac OS make use of the IOPs on the Q900/Q950?      Were they some kind of 7805 variant?
    • Nice work.  I am enjoying reading about it.  
    • Newer Xilinx FPGAs typically have dedicated DDR2 controller cells built in.  For example, the Xilinx chips in the Pano Logic systems have four DDR2 controllers on board, although only two of them may be pinned out to the package.   The DDR2 buses on those chips are 16 bits wide.   DDR2 chips are available in capacities up to 2Gb (256MB).  A single 1Gb DDR2 chip would give 128MB of memory, albeit, only 16 bits wide, but at DDR2 speeds, one could handily string two operations together for every 32 bit access, although that would add a bit of logic.    Alternatively, two DDR2 controllers could be used, each 16bits wide to yield a 32 bit wide bus, but the controllers are physically separated on the FPGA, so splitting the 32 bit operations, to essentially stripe them across the two DDRs might be a bit tricky and/or create performance/timing issues.   Xilinx has/had a memory configuration tool that could create a DDR2 controller out of generic logic.  That tool was capable of creating (IIRC) arbitrary bit width controllers, but certainly, up to 64 bits wide to access a standard DIMM.   That might be a better option, but using the dedicated hardware, if present is more economical of logic.