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

 

[adespoton]

First step is always MACSBug, which even lets you load in custom additions to automate whatever you want. If the learning curve is too steep there, Jasik's Debugger is a good secondary debugger that has all the bells and whistles. The Codewarrior debugger is mostly limited to processes with symbols embedded; I've never found it all that useful for kernel/system level debugging, but I *think* some people have used it via serial out from a secondary device for this sort of thing. Others will have to weigh in here though, as I've never used it in that mode.

 

[Oliver_A]

Sorry, didn't have much time yesterday.

@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".

Thanks a lot, that will probably help me tremendously to implement a more organised method to probe the hardware. On the Amiga, I have to rely on the location and ID values of certain custom chips and memory addresses, but I realize that the MAC was insofar a "fixed" system as you can rely on the built-in ROM to identify the machine.

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.

Sorry, didn't want to criticise your work. Contrary to more "high level emulators", I think that MAME/MESS is not only an emulator, but contributes tremendously in preserving and documenting classic vintage hardware. If I need to find out how an obscure device is working internally, I usually refer to the MAME/MESS source code first.

@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.

Wow, now THAT is what I call an elaborate list!

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.

I have seen that ASICs, like MEMC(jr) do have a hardware register which could be probed, but according to the MAME/MESS source, not every MAC has that feature. So this is highly appreciated and will facilitate a lot of things.

Yeah, I know, some people will roll their eyes at my questions now, but hey, I'm learning as I'm going along.

First step is always MACSBug, which even lets you load in custom additions to automate whatever you want. If the learning curve is too steep there, Jasik's Debugger is a good secondary debugger that has all the bells and whistles. The Codewarrior debugger is mostly limited to processes with symbols embedded; I've never found it all that useful for kernel/system level debugging, but I *think* some people have used it via serial out from a secondary device for this sort of thing. Others will have to weigh in here though, as I've never used it in that mode.

Now THAT is something that looks very promising. Thanks, will give it a try and see if I can get my code running.

@Oliver_A - Where are you located?

In Germany.

 

[Melkhior]

I have seen that ASICs, like MEMC(jr) do have a hardware register which could be probed, but according to the MAME/MESS source, not every MAC has that feature. So this is highly appreciated and will facilitate a lot of things.

One document that can be enlightening is the "Guide to the Macintosh® Family Hardware, Second Edition", which is available from vintageapple.com ; it describes a lot of the pre-'040 hardware. Alongside it is "Designing Cards and Drivers for the Macintosh Family, 3rd Edition"; with both of them you get a very good picture of how Mac works. '040 hardware is less varied as Apple didn't build as many different systems (debatable now that I create a list: LC475/Q605, Q610/Q650/Q800, Q660AV/Q840AV [were they identical?)], LC630/Q630, plus all the laptops...) Finally, most/all Macintosh had a machine-specific devnote such as for the LC475.

 

[joevt]

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".

The subversion column is not applicable to some earlier ROMs.
The table is missing additional checksums.
The shown checksums of 4 MB ROMs only cover the first 3 MB.

The attached excludes the subversion from where it doesn't apply. It also includes all the other checksums.
For the 3 MB part, there's 4 extra checksums - one for each byte lane (or 2 extra checksums - one for each 16 bit lane).
The other checksums cover the entire 4MB. 1 for each of 8 byte lanes, plus a 64-bit checksum that covers all 8 byte lanes.
√ = checksum matches calculated checksum.
x = checksum doesn't match calculated checksum.

 

[Apollonia]

First step is always MACSBug, which even lets you load in custom additions to automate whatever you want. If the learning curve is too steep there, Jasik's Debugger is a good secondary debugger that has all the bells and whistles.

Probably worth a look at TMON as well (though Jasik’s has the advantage of still being maintained).

 

[Arbee]

The subversion column is not applicable to some earlier ROMs.
The table is missing additional checksums.
The shown checksums of 4 MB ROMs only cover the first 3 MB.

Good to know for if I can ever get my hands on real hardware risu data.