New Project: Prodigy 040/060 Card

[Oliver_A]

Thanks for your considered comments, I understand we have to start somewhere and the more learnt the better. We're lucky to have you on board here!

Thank you for your understanding. I actually know Claude personally, and he is a very nice and capable person, who does it with the same passion and motivation as us all.

Speaking of.... The bootrom starts now to show a sign of life!



I'm currently developing this on WinUAE Amiga Emulator, since this is the platform I am obviously most familiar with.

Once the code works completely, I will write the machine detection and I/O driver routines for the Macintosh. I have looked at the MAME source code, and I think that it is indeed possible to distinguish between most late generation 68040 MACs by probing the register and memory map.

I will also try to use MAME as a development platform before the card is finished, since I have the impression that it is the only Mac Emulator which actually attempts to emulate the real custom chip hardware. If somebody has a better recommendation, then I would be glad to consider this as an alternative ption, since MAME is a bit clunky to handle.

Once i get at least the serial console to work on the MAC, I can basically start to "conquer" the system by directly writing to registers and memory.

 

[dgp]

I don't want to tell you want to do.. but maybe instead of writing a bootrom from scratch you could add just the needed parts to u-boot to get it to boot baremetal before the machine's own ROM?

And I'm not just saying this off the top of my head. I have ported u-boot to work on a bunch of 680x0 machines including 68000. With u-boot you get lots of stuff just working like memory inspection, loading over serial, and we can get Linux booting. Someone else is pretty close to getting some of this into mainline u-boot..

If the CPU card CPLD (I guess it's a CPLD) is big enough to include a basic timer and uart we could get u-boot running without using any of the machine hardware and I think that'd help with bringing the card up as you can see if it's working or not hardware-wise without having to struggle with what the machines ROM is trying to do.

 

[Oliver_A]

I don't want to tell you want to do.. but maybe instead of writing a bootrom from scratch you could add just the needed parts to u-boot to get it to boot baremetal before the machine's own ROM?

No problem, feedback is always welcome.

What my boot rom is can be called a "BL0" loader. Modern SoCs have it often embedded in their mask rom on the silicon die, my card has it on-board to ensure that, no matter what extrinsic conditions apply, there is always a piece of code where you can, at least, set-up the system, like flashing the ROM for things like.... right, UBOOT (as I mentioned earlier in this thread).

Remember, the card really is supposed to be a plug-in solution for different systems. Put it in a MAC - works. Put it in an Amiga -works. And apply system-specific code to start-up the system, based also on what kind of boot parameters the user writes into the flash.

* Start the monitor?
* Start the machine's own ROM, and apply patches?
* Kick off an alternative boot process based on what contents have been flashed?

And I'm not just saying this off the top of my head. I have ported u-boot to work on a bunch of 680x0 machines including 68000. With u-boot you get lots of stuff just working like memory inspection, loading over serial, and we can get Linux booting. Someone else is pretty close to getting some of this into mainline u-boot..

And all of this will be possible, so don't worry. My software is my contibution that my card is always working, no matter what "someone else" is doing.

If the CPU card CPLD (I guess it's a CPLD) is big enough to include a basic timer and uart we could get u-boot running without using any of the machine hardware and I think that'd help with bringing the card up as you can see if it's working or not hardware-wise without having to struggle with what the machines ROM is trying to do.

No struggle at all, basic I/O is working on Amiga, the MAC part is next.

I also keep it as a CPU and not a system extension card, which, btw., I don't think is necessary at all. There is no magic behind to operate at least a serial UART.

And as I mentioned earlier, I'm using an FPGA. There are small FPGAs which are great to implement high-speed I/O - memory controller bridges.

 

[absurd_engineering]

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.

I have an '040 NeXTstation I would be willing to send you for the project, if we can work out shipping. It needs a video/keyboard/mouse breakout box to be useful without the original Megapixel display, however, and I don't have one.

 

[shirsch]

@Oliver_A - Where are you located?

 

[Arbee]

@Oliver_A Right, MAME is currently it for '030/'040 machines as far as emulating the actual hardware. That said, your best bet for identifying a machine is to start with the 32-bit ROM ID at $40800000. https://wiki.mamedev.org/index.php?title=Driver:Mac_68K:Tech_Info:ROMs lists all of the known ROMs - the ROM ID is what that page calls the "Apple checksum".

As far as clunkiness, if you aren't on a very fast machine for compiling (an Apple M-series Pro or Max or a recent high-end Ryzen with at least 32 GB of RAM) you can greatly reduce compile times by building only the Mac support.

 

[adespoton]

@Oliver_A Right, MAME is currently it for '030/'040 machines as far as emulating the actual hardware. That said, your best bet for identifying a machine is to start with the 32-bit ROM ID at $40800000. https://wiki.mamedev.org/index.php?title=Driver:Mac_68K:Tech_Info:ROMs lists all of the known ROMs - the ROM ID is what that page calls the "Apple checksum".

As far as clunkiness, if you aren't on a very fast machine for compiling (an Apple M-series Pro or Max or a recent high-end Ryzen with at least 32 GB of RAM) you can greatly reduce compile times by building only the Mac support.

@Arbee I somehow missed that page when doing https://docs.google.com/spreadsheets/d/1wB2HnysPp63fezUzfgpk0JX_b7bXvmAg6-Dk7QDyKPY/ -- I should probably add in your build dates and version numbers.

And you're right, the ROM ID is a much better place to start than the Gestalt ID -- the ROM ID will be authoritative as far as hardware capabilities and ROM offsets for toolbox traps, whereas there seem to be a few places where Apple messed up with the Gestalt IDs.

 

[Oliver_A]

So, the bootrom is now taking shape, and I can now successfully run it on real hardware, which in this case, is a tiny small Amiga 600 (and YES, it has a 68040 CPU )



It will be probably a week or two until the parts for the card arrive, so in the meantime, I am actually thinking about how I can actually "jump start" the ROM on my LC475 by loading and executing it from RAM (which is what I am also actually doing on the Amiga).

Can anyone give me a hint on, which type of low-level Debuggers exist on the MAC which allow me to:

* Load a binary at an absolute memory address
* Set the CPU into Supervisor state and directly jump to the ROM location
* Possibly disable MMU-related protection mechanisms?

My first attempt would be to have a look at Codewarrior. I might have to use it later when I write the card software for MacOS, which allows to flash and configure the card.

So, the BootRom is called "DeMon", and it is the first piece of code which is executed on power-up and after the CPU was getting an external reset.

DeMon is especially intended to help during debugging and development. When you power-on the card with an 68060 installed, it is the very first piece of software which actually runs on the MAC, and allows to create an environment which will successfully boot an operating system.

In the 2MB flash, my intention is that you can store multiple "firmware files", which will get loaded and executed by "DeMon" if a valid firmware table structure is found in the ROM. The very least you can do with DeMon without a, yet, not running operating system on the 68060 is:

* Load, flash and execute a firmware program
* Install an exception handler, which will redirect any exceptions to jump back into DeMon
* Modify, load and upload memory via serial cable to a different host (modern MAC or PC)
* Set breakpoints to trace the execution flow of the software
* Disassemble memory locations and examine the code

As I said earlier, when nothing is pre-set before running the card, DeMon is attempting to automatically detect the type of host system, and will install a basic I/O and exception handler to have a working debugging environment.

Anything else, be it MacOS, AmigaOS, U-boot, Linux, can be booted in a subsequent step when a firmware file has been flashed and installed on the card.

A firmware file can be a loader, a full operating system, or an "intermediate" rom, which applies patches to the ROM operating system of the machine.

I personally really love the idea to enable a "multi boot" set-up, where, within a single key stroke, you can decide which operating system loads.

Again, thanks a lot for your encouraging and helpful comments, I am very sure that we can get this baby on the road running, and that a Macintosh can, actually be, also among the fastest 68k machines. ;-)