New Project: Prodigy 040/060 Card

[Melkhior]

@Oliver_A NeXT or Mac or most others, the hardest part will always be the software. Amiga didn't use the MMU (that I'm aware), and most of the software people wanted to run was compatible with the MC68000 so didn't use the new instructions in the MC68020 - upgrading to a '060 was "easy" SW-wise (it's all relative ). Mac do use the MMU even if not heavily when virtual memory is disabled, and there was a lot post-Classic, color-only or higher-end software compiled for '020 and later - as noted by those who tried, upgrading a Mac to a '060 is very difficult. For NeXT, it's even worse; they only had '030 and '040, all with the new instructions, so the *SP are going to be used a lot. And you'd need to fix not just the ROM but the kernel as well as the MMU is heavily used by UNIX-like operating systems (the MACH kernel for NeXT). And if it's for running a newer OS like NetBSD, I presume it can be done on '060 Amiga or any other '060 machine just as well... So beware that while both projects are great, getting the software to work is going to be the real problem for both of them.

 

[Oliver_A]

Well, then I better get started on the low-level monitor software then. ;-)

 

[zigzagjoe]

Never realized they had done that - from the '040 timing diagrams, it doesn't seem to cost anything in performance though a lot of external hardware will need to capture the address rather than just use the live version as in non-multiplexed mode... this could add quite a bit of hardware, though the PCB routing would probably be a bit easier (depending where/how many times the address is registered and how many peripherals are connected to each register).
OTOH The NeXT bus is an "improvement" of NuBus (read: faster clock and slightly incompatible), which is also multiplexed, so maybe it made sense for them if it made bridging to the expansion slot easier.

Hehe, now you've made me rethink my entire approach to my homegrown '040 system; the large number of pins required on a FPGA to connect the '040 bus is an issue... removing 31 pins (32 from the fusing of bus, but likely adding one to drive /CDIS to it can be 0 for the multiplexed bus mode during reset and then going back to 1 to de-disable the caches) would help, and capturing 32 bits in a FPGA once and for all isn't costly... I wonder if that multiplexed bus would play less nice with the SMP (lack of) support... maybe NeXT had the right idea after all

It's definitely interesting, and as far as I know it is the only "big" design that used the multiplex mode. IMO Motorola throwing things at the wall and seeing what stuck, as they tended to do. I don't know that it had anything to do with the NeXTBus/Nubus though as that's not used on the mainboard. The multiplex design does make a certain degree of sense if you are using in-house design ASICs and mostly can get away without requiring breaking out large pieces of the address bus for the COTS parts used for SCSI, floppy, etc.

I don't know that it'd work with the snooping mechanisms that seem to be what motorola envisioned as the path forward for SMP on the 040s. Documentation is understandably a bit sparse with not much more than a few timings and a single diagram.

The more I think about it, the more it actually makes really sense to me, and would play highly in favour on the choice of components I already did for this design.

Let me make a proposal: if anybody is willing to send me a working 68040 based NeXT computer, I would be willing to do a dedicated "test card" for it, which explores on how to take advantage of the multiplexed bus mode using FPGA technology.

The multiplexed bus mode is trivial. Just sequencing of your address and data buffers at the mainboard outputs to avoid contention. Simple enough that for development of the HyperDrive I mixed development between NeXT and Macintosh with just a build switch that enables/disables the multiplex driving. Simulation alone was enough to get it working immediately for me, but otherwise you could put 4x transciever 4x buffer and a GAL on a card to test.

@Oliver_A NeXT or Mac or most others, the hardest part will always be the software. Amiga didn't use the MMU (that I'm aware), and most of the software people wanted to run was compatible with the MC68000 so didn't use the new instructions in the MC68020 - upgrading to a '060 was "easy" SW-wise (it's all relative ). Mac do use the MMU even if not heavily when virtual memory is disabled, and there was a lot post-Classic, color-only or higher-end software compiled for '020 and later - as noted by those who tried, upgrading a Mac to a '060 is very difficult. For NeXT, it's even worse; they only had '030 and '040, all with the new instructions, so the *SP are going to be used a lot. And you'd need to fix not just the ROM but the kernel as well as the MMU is heavily used by UNIX-like operating systems (the MACH kernel for NeXT). And if it's for running a newer OS like NetBSD, I presume it can be done on '060 Amiga or any other '060 machine just as well... So beware that while both projects are great, getting the software to work is going to be the real problem for both of them.

Seconded. I suspect the NeXT kernel is probably a little more well behaved compared to Mac in that vectors aren't screwed with willy-nilly, but it does use user/supervisor separation AFAIK and if it makes use of the second supervisor stack pointer that was eliminated in 060 - big problems. That said, by 3.x they would have been thinking about multi-architecture support so they really shouldn't have been doing so.

 

[croissantking]

For the LC475, this is fine, since the accelerator makes the usage of the SIMM slot obsolete. You can see I purposely set the board layout so it doesn't collide witn the SIMM slot brackets and the battery holder, therefore, this is working as intended. ;-)

Right! Makes sense.

 

[Melkhior]

It's definitely interesting, and as far as I know it is the only "big" design that used the multiplex mode.

There might be a reason for that, beyond the fact people with '030 design would not have minded the non-multiplexed bus. Quoting the section 1.1.2 of the '040 UM:

The MC68040V and MC68LC040 do not implement the data latch enable (DLE), multiplexed, or output buffer impedance selection modes of operation.

So any design using the multiplexed mode is stuck with full MC68040 @ 5V - no cheap LC option and no path to low-power static 3.3V version without a full redesign to go back to non-multiplexed.

Too bad, because the MC68040V running at 3.3V is the perfect part to interface with a FPGA (I don't mind the lack of FPU), and removing so many signals would have been a boon ;-(

 

[Byrd]

Enjoying the discussion - however have to ask with 68060 full fat CPU prices being stupid crazy high (and further starving the Amiga crowd if vintage Mac users start to grab) would efforts be better spent on a PiStorm-like solution for the Mac over bare metal upgrades such as these?

 

[Oliver_A]

As I am a semiconductor guy, I would always propose solutions which are in-line with the actual design process of semiconductors. That's how I personally derive my definition of judging what is "real hardware".

But, similar to the Amiga community, there are no uniform standards on how to judge/decide what is still in spirit of the original vintage design, and that is fully okay.

Therefore, see this card as a first step, for me, to understand the actual requirements of the Classic Mac User community, which, as I am already seeing, are quite different in many aspect from the Amiga community. So not every solution coming from the Amiga community, is automatically fit for the Macintosh, including possibly the 68060.

Also, the card will provide a much faster memory interface for 68040-based systems, which is crucial given the fact that the 68040 has smaller caches, but can actually put up a formidable fight against the 68060 once this bottleneck has been removed, obviously until process related limitations like the maximum clock rate kick in.

And you don't have to put in a full Rev6 68060, there is the much cheaper LC variant, which has no FPU, but a fully working MMU, and can also run at 100MHz.

As with all things related to ones hobby, it should first and foremost, be fun for the person doing this actual project. Because this person is doing it (hopefully) out of passion for his hobby. And you can only, really, change things not by talking, but by DOING.

So, maybe someone can open a new thread and discuss a PiStorm related solution here.

 

[Oliver_A]

Speaking of DOING, PCBs are now ordered.