Recent content by Melkhior

The "Claude" thing is creeping me out. The fake familiarity, the 'we', everything in the way it expresses itself... starting to read it, it made my skin crawl. It seems to be right in the uncanny valley for the written word. I don't know how you can deal with that thing. To each their own, I...

OK, I'll confess: I've recently bought IDT79RV4700-150GH - 64-bits, 3.3V, 150MHz MIPS R4000-class CPU in PGA179 package (same as the MC68040). They were dirt cheap, and they would fit my FPGA-based homebrew project... I've betrayed both 68k and SPARC... ... but my last received CPUs were...

No need to polute the thread any more than I've already done; I've ranted about my opinion time and time and again :-) My point exactly. Then backward compatibility is nigh impossible, and the future of the platform is bleak (darn, I'm doing it again :-/ )

Apple was surprisingly prescient in some of their design choices. MMU were not an obvious choice for personal computers when they introduced the II (which had a slot for a MC68851 and an even poorer substitute by default) and later IIx and SE/30, At the time it was mostly an expensive feature of...

And look where it got the Amiga platform... You could also hack memory expansion in some (most?) older systems (8-bits era). Turns out, the future was to not do that due to closer and closer integration of the memory controllers with the CPU. They eventually became built-in to the CPU in the...

I think the usual path for optimization and acceleration would work, in our case: (a) identify the hot spots - where the the most time is spent in QD calls under normal use. That's what should be targeted first. No need to accelerate something that takes no time! Internal trap _BitBlt I've done...

For QD acceleration, at the moment real estate cost would be fairly low. The *FPGA uses a RISC-V core and some firmware to implement acceleration, not custom hardware - much less area-efficient but easier to implement. The only cost would be additional registers where the Mac can put parameters...

And to Rodin, concerning his statues: "Without the chisel wouldn't have been able to do this unless you actually sat down and learned how marble is removed. This is not yours. It's the chisel's" Curious; in your opinion, does refactoring in IDE also count as "not yours"? How about...

Yes, the ROM does it via the TT registers; I assume the system does the same later on when it takes over. No, it was never planned for or supported; the DeclRom were designed for NuBus and so only for devices, not memory. All Macs assume the only memory controller in the system is the built-in...

Those two are sort of linked. I don't think the MC68030 will do burst to non-cacheable pages, which is how the framebuffer is set up (and the Quadra cheats, as the internal framebuffer is set to non-serialized while any PDS device is set to serialized, but that's off-topic). If you don't intend...

Thinking about it, not sure DMA is possible with a mutiplexed design. If the memory controller doesn't register the address signals (and with a '020/'030 it has no reason to), then you need both the address and data at the same time on the bus. I think.

Not that I know of, but the PDS slot in the LC475 is using the interface from the MC68030, it's identical to that in the LCIII and backward compatible to the shorter, less capable slot in the LC and LCII. There is a modern Ethernet card for the SE/30, the SEthernet/30. I have reworked my own...

If you need a level switcher (the IRQ will be pulled up to 5V), then you can use a silicon switch as a shifter and a physical switch to control the silicon switch (or if you don't mind the extra noise on the signal, just send the IRQ through the physical switch!). Just one FPGA pin but 2 or 3...

Unsupported :-) In practice, stackable cards tend to have switches to choose the slot/irq. It's not very clean nor macintosh-like, but it worked. Apple only ever intended for one card to be used; I suspect in the SE/30 the idea was that a single card could have multiple functions in multiple...

The older systems are not very well protected or architectured, so ultimately you can do almost anything... but it's a lot easier and safer (in terms of SW compatibility) to stick to Apple's rules. The "normal" way is to use the memory range(s) and associated IRQ, as were originally defined for...