New Project: Prodigy 040/060 Card

[Oliver_A]

There's already bootloaders et al for NetBSD/Linux from a Mac platform so that piece is already covered if it comes up as a Mac. This way you get the hardware initialization done by the ROM/Toolbox as those kernels don't know how to bring up the hardware from scratch. I just need to get around to adding 060 support from the amiga/mvme targets of netbsd to the mac68k one as it rather sensibly doesn't expect an 060. Shouldn't be complicated, I've just put off getting a build environment set up.

Sounds great, I was also thinking about whether adding MAC as an m68k platform would make sense for Linux Bootloaders such as UBOOT.
Gathering from the MEMC(jr) description and source code, setting up the memory and display shouldnt be complicated.

I was actually thinking of doing this for the low-level bootrom code on all my cards, sharing the same code base. So if you hit a key on both MAC or Amiga, you get the basic monitor on-screen.

Local memory would be much more relevant to the earlier 030 based macintoshes, the IIci and related platforms, for the reasons you mention. It's amusing putting an 040 in these systems, but even a cache can't hide 16 cycle @ 16mhz accesses for a 40+mhz CPU, nevermind slow framebuffers and other IO.

Also, many 030<>040 bus translators can not do bursts / line requests, which additionally hurts performance.

I find myself poking at the 060 ROM stuff from time to time as it's relevant to my interests but in all honesty I can't promise serious continued efforts as I technically reached my goal and there's some very grotty issues remaining for Mac ever supporting 060 fully. I would otherwise be interested in doing some testing but just wished to be fully transparent.

As I said, if you like the challenge of getting Linux/NetBSD running on Mac in a fast 040/060 environment, my card could also be something for you. I'd also love to have a look at NeXT machines, but from where I come, these things are truly unicorns... ;-)

I've been using the ATF15xx series of CPLDs, a superset of the Max7xxx family. Nice capable chips and 5v native, however all code paths are married to the atmel fitter for place and route and it's a tempermental buggy piece of crap. I keep a running list of bugs titled "Reasons to hate the atmel fitter.txt". You can technically develop with altera tools, but then all the added functionality is inacessible and some of that like losing the additional clocks hurts.

It's exactly the reason why I am refraining on using these chips.

Is your FPGA 5V tolerant? Or do you plan to use a 68040V (did they make that in PGA?) for bring up?

Nope, I'm using the MAX10 series from Altera. They scale well from 2K-50K LE's, and are well suited to be used as glue/logic , memory controller. I have also developed a PCMCIA graphics card using these chips, driving directly an HDMI display at Full HD.

So you can see on the PCB that I have placed quite a lot of bus drivers there, but I think it's okay, in the case of the Prodigy, it's not adding that much complexity or board space. On my A1200 card, which is way more complex, I only support 68060 since I can not fit the bus drivers for the 040 anymore (which is a shame). But I also intend to use the same design for an Amiga 2000 and Amiga 3000/4000 card, where I do have the space again.

Here is a status update (this time Raytraced):



Making very good progress, I think the design will be finished by the end of the week!

 

[croissantking]

Sounds great, I was also thinking about whether adding MAC as an m68k platform would make sense for Linux Bootloaders such as UBOOT.
Gathering from the MEMC(jr) description and source code, setting up the memory and display shouldnt be complicated.

I was actually thinking of doing this for the low-level bootrom code on all my cards, sharing the same code base. So if you hit a key on both MAC or Amiga, you get the basic monitor on-screen.



Also, many 030<>040 bus translators can not do bursts / line requests, which additionally hurts performance.



As I said, if you like the challenge of getting Linux/NetBSD running on Mac in a fast 040/060 environment, my card could also be something for you. I'd also love to have a look at NeXT machines, but from where I come, these things are truly unicorns... ;-)



It's exactly the reason why I am refraining on using these chips.



Nope, I'm using the MAX10 series from Altera. They scale well from 2K-50K LE's, and are well suited to be used as glue/logic , memory controller. I have also developed a PCMCIA graphics card using these chips, driving directly an HDMI display at Full HD.

So you can see on the PCB that I have placed quite a lot of bus drivers there, but I think it's okay, in the case of the Prodigy, it's not adding that much complexity or board space. On my A1200 card, which is way more complex, I only support 68060 since I can not fit the bus drivers for the 040 anymore (which is a shame). But I also intend to use the same design for an Amiga 2000 and Amiga 3000/4000 card, where I do have the space again.

Here is a status update (this time Raytraced):

View attachment 94070

Making very good progress, I think the design will be finished by the end of the week!

This is very cool - following with interest.

Have you thought about fitment in the LC475 and other models you may want to make it available to? The PCB may foul other components depending on orientation.

 

[SinclairSoftware]

This is beyond awesome Oliver, thank you for everything you do. I am super hype for this.

 

[absurd_engineering]

Sounds great, I was also thinking about whether adding MAC as an m68k platform would make sense for Linux Bootloaders such as UBOOT.
Gathering from the MEMC(jr) description and source code, setting up the memory and display shouldnt be complicated.

I was actually thinking of doing this for the low-level bootrom code on all my cards, sharing the same code base. So if you hit a key on both MAC or Amiga, you get the basic monitor on-screen.



Also, many 030<>040 bus translators can not do bursts / line requests, which additionally hurts performance.



As I said, if you like the challenge of getting Linux/NetBSD running on Mac in a fast 040/060 environment, my card could also be something for you. I'd also love to have a look at NeXT machines, but from where I come, these things are truly unicorns... ;-)



It's exactly the reason why I am refraining on using these chips.



Nope, I'm using the MAX10 series from Altera. They scale well from 2K-50K LE's, and are well suited to be used as glue/logic , memory controller. I have also developed a PCMCIA graphics card using these chips, driving directly an HDMI display at Full HD.

So you can see on the PCB that I have placed quite a lot of bus drivers there, but I think it's okay, in the case of the Prodigy, it's not adding that much complexity or board space. On my A1200 card, which is way more complex, I only support 68060 since I can not fit the bus drivers for the 040 anymore (which is a shame). But I also intend to use the same design for an Amiga 2000 and Amiga 3000/4000 card, where I do have the space again.

Here is a status update (this time Raytraced):

View attachment 94070

Making very good progress, I think the design will be finished by the end of the week!

Very, very cool.

Let me know if you really are interested in extending it to NeXT, I would gladly send you a NeXTstation for development purposes.

 

[zigzagjoe]

NeXT support for local memory is, by my judgement, not practical. I took a look (as this question was asked of me) while I've been working on my own NeXT designs. Some further discussion here, though I no longer post at that forum.

NeXT would require its own hardware design as it uses the multiplexed bus mode of the 040. Not a major issue as it can be faked up fairly easily with an extra set of buffers and this is what I did on my Hyperdrive prototype. Several major/insurmountable issues past that point however.

Big one: There is no way to quiesce the memory controller, and everything uses DMA to/from main memory. Regions of memory are not cache inhibited for DMA activity, instead DMA buffers can be located anywhere and they are invalidated form internal caches prior to DMA activity. Later kernels will do that for L2 cache also but only on the prototype Nitro accelerator. On top of that the DMA is "private" on the early chipsets which are the ones most in need of local RAM so there's no way to snoop bus activity to maintain coherency that way. Since you can't avoid using main memory in some capacity I think you would be forced to architect the local memory as a huge write-back cache, doable, but complex....

Aside from that, the maximum RAM limitations would remain as those are enforced by the address map on the early machines which have the most to gain from more/faster RAM. It's less urgent on turbo chipset machines as they have a faster much flexible chipset and support 128MB (also address map limited) using common 72 pin SIMMs. Those machines at least have "public" DMA with strobes so it'd be possible to support a snooping approach there.

If we put aside local memory then the 060 part of the equation is more practical, as long as your adapter handles the multiplexed bus behavior (4x buffer 4x transciever + PLD). I did not investigate if the bootrom is 060-friendly but the kernel would need to be hacked to incorporate the ISP/FPSP. I think it is probably a simpler problem than Macintosh; from what I've seen I'm thinking NeXT is less cavilier about futzing with vectors and less feral in general. However, there's less documentation/source available to support these efforts.

Some kernel sources are floating around but I think it's only the older 2.x kernel, that may be enough to shed light on the critical parts (vector table handling). I suspect the floating point stackframes won't be a problem either, though I don't know if the NeXT kernel makes use of the extra supervisor stack pointer or not.

 

[Oliver_A]

Very, very cool.

Let me know if you really are interested in extending it to NeXT, I would gladly send you a NeXTstation for development purposes.

Absolutely. As @zigzagjoe said, I can't promise whether a similar approach as the MAC card will work on NeXT, but I am definetely interested to, at least, contribute in reverse engineering the design, as I can trace all CPU activity on my card, which is a feature I can also use on the NeXT machine. And then see what makes sense from a design POV.

Considering what you are telling me, the NeXT computer was actually designed to be the most powerful m68k platform.

If you like to support this effort, PM me and I can give you my address.



So actually, I have lied to you all, because the Prodigy design is complete now!





I'm doing now the small adaptor board which sits beneath the Prodigy and then, well, let's see how far I can get with this design.


I also got myself now a Quadra 650 to have, at least, another machine type for testing.

 

[Renegade]

@Oliver_A
I am following your project with interest, but I am remaining silent as I have no relevant technical knowledge in this area.

That said, you did not specify where in the world you live. Depending on that, the community could potentially organize to lend you one or another Mac Quadra model to facilitate your testing.

 

[Oliver_A]

I'm living in Germany, but I got the Quadra 650 for cheap, so no issues here. The biggest challenge here is clearly to get the 68060 supported as best as it can be, and for that, I will somehow need help from the community. Eventually, I think I can also do this by myself, but it will take longer. If anybody wants to level-up and seriously tackle this challenge, I'm all open for sendin a prototype to this person.

What I will develop myself, at least, is the low-level boot rom which I specifically will design to facilitate quick turn-around cycles to test code.

The boot rom will actually:

* Detect the type of machine the card sits in (and yes, this also includes Amiga) ;-)
* Sets-up display, keyboard, serial I/O, memory controller
* Provide a set of debugger commands to upload and execute code, poke into memory/register addresses, configure the CPU (i.e. disabling the 68060 FPU by writing to the PSR, etc.)
* Flash the ROM, store attributes which are used during cold/warmstart (reset vector, 2nd level boot code which includes the patches, etc.)

This is going to be fun!

And thank you all for being so supportive here. This really fuels also my motivation to get this done as best as possible. The code and datasheets you provided me already make me very confident that I can do this low-level boot rom in a relatively short time.

 

[AlpineRaven]

Wow awesome project!!! I'd be keen in one board if youre going to sell.
Cheers
AP

 

[Oliver_A]

So, hardware is complete, including adaptor board. ;-)





I guess it's now ordering time for PCB and parts.

 

[terrier]

Before you order PCBs, have you checked enclosure/component/slot (e.g. SIMM, Nubus) clearances on your targeted platforms? (LC475/Q605, 650/800?)

 

[croissantking]

Before you order PCBs, have you checked enclosure/component/slot (e.g. SIMM, Nubus) clearances on your targeted platforms? (LC475/Q605, 650/800?)

That’s what I tried to warn OP above. The current design will foul the RAM slots on LC475 and Quadra 650/800, and a Nubus slot on the latter.

 

[Melkhior]

Considering what you are telling me, the NeXT computer was actually designed to be the most powerful m68k platform.

All the 80s 68k workstations were built to be the fastest 68k machines. The personal computers (Mac, Amiga, ST, QL, whatever) were the ones built to be cheap. Workstation vendors were all looking for low latency memory, DMA everywhere, etc. My personal favorite, Sun, did have a 0-latency MMU for the '020 (using untranslated bits for row access and translated bits for columns so the delay would be masked), DMA for ethernet, SCSI (and used to initiate refresh as well), provision in the system control memory space for external cache (needed for slower VME memory, not for local DRAMs) and block copies. Of course many of those vendors switched to their own RISC design before the '040...

The on high-performance feature few bothered with was SMP. The early CPU ('010, '020, '030 - the '040 only has a broken documentation...) have a not easily shared bus, some of the later ones ('030, '040) have insufficient cache coherency support ('030 data cache need disabling, '040 data cache must be set to write-through). It was done, but was never mainstream. I didn't find an issue with the '060 for SMP, other than the cost of the CPU.

 

[croissantking]

Potential fitment issues

LC475/Q605:



Q650/800:

 

[zefrenchtoon]

As Renegade, I silently follow this thread.

Maybe the goal of its StepUp Board is to go over the 475 RAM ?
In a similar way @Bolle did on its Diimo 040 cache

Of course, this will not be ok with the NuBus slot on 650/800. :-/

 

[Oliver_A]

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. ;-)

For the Quadra, I completely need to flip the orientation of the card, so it either requires a different layout, or it can be solved via the adaptor socket.

I guess you simply can not do a "one size fits it all" design. It's called "Revision 0" for a reason. ;-)

 

[zigzagjoe]

Absolutely. As @zigzagjoe said, I can't promise whether a similar approach as the MAC card will work on NeXT, but I am definetely interested to, at least, contribute in reverse engineering the design, as I can trace all CPU activity on my card, which is a feature I can also use on the NeXT machine. And then see what makes sense from a design POV.

Considering what you are telling me, the NeXT computer was actually designed to be the most powerful m68k platform.

If you like to support this effort, PM me and I can give you my address.

So actually, I have lied to you all, because the Prodigy design is complete now!

I'm doing now the small adaptor board which sits beneath the Prodigy and then, well, let's see how far I can get with this design.


I also got myself now a Quadra 650 to have, at least, another machine type for testing.

Just to be really clear, do not put an accelerator designed for another system into a NeXT, it won't work and you may damage your accelerator. Address and Data lines are shorted together (by design) on the NeXT motherboard due to use of the multiplexed bus function of the 68040.

 

[Oliver_A]

It's all a matter of when the FPGA drives the Data lines for the SDRAM buffer ICs. Everything else should be fine, as the whole address bus goes through a series of 74LCX244 level shifters. So I just need to sample the addresses and data at different points in time.

Now you really got my curiosity, as I have never seen a design which uses the 68040 in such a way!

 

[Melkhior]

Address and Data lines are shorted together (by design) on the NeXT motherboard due to use of the multiplexed bus function of the 68040.

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

 

[Oliver_A]

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.