Looks like you can emulate the ANS500/700 with MacOS roms even now https://github.com/pappadf/granny-smith/pull/120
Apple Network Server MacOS based ROMs found
- Thread starter eric
- Start date
Yes, in principle it's possible to boot Mac OS with the "prototype" rom in the emulator (I've tested with system 7.6). However, let me add some voice overlay to manage expectations:
First of all, a small disclaimer: an emulator is of course not real hw, so no result here transfers directly to the real thing. The emulator may be more "forgiving" than real hw, or simply deviate from what the hw actually does.
The system that managed to boot to the finder had two "hacks" that are not fully reflected in the final PR:
First of all a small hack for the VBL interrupt. Out-of-the-box, mac os booting on ANS weren't reciving VBL interrupts properly. Based on available documentation, my understanding is that the graphics adapter (cirrus logic) has no interrupt line at all, so I'm not sure how this should work on real hardware. I did a small hack to drive with with the via.
Second, a "nudge" for the scsi bus scan. The native scsi mgr hangs on every empty-target probe of the two fast/wide 825 buses. The ANS has a lot of potential scsi targets, so the scan effectively never completes without help (or at least take a very long time). This one may very well be a bug in my 825 model; it deserves further investigation, as I've seen similar things under AIX.
Bringing up mac os was just a side activity here, to add some more test coverage to the emulator. The real goal was AIX. However, it turned out to be a very healty excrsise that actually surfaced a number of other underlying emulator bugs.
So in short, yes, in theory it's possible to run Mac os on emulated ANS
---
An additional disclaimer: AI tools were used extensively in this work - not only for coding, but also for debugging and reverse engineering. I know that is a red flag for some, and I fully respect that.
Last edited:
Trying it out. I uploaded multiple ROMs.
1995-05-18 - 9630C68B - 2.26B6 ANS 300 & 500 & 700.ROM
1998-01-14 - 49B2BE8F - 2.0 ANS 300 & 500 & 700.ROM
1995-08-21 - 962F6C13 - 1.1.20.1 ANS 300 & 500 & 700.ROM
1995-08-21 - 962F6C13 - 1.1.22 ANS 300 & 500 & 700.ROM
1995-08-21 - 962F6C13 - 2.26NT ANS 300 & 500 & 700.ROM
But I had to move them manually from the upload folder to the rom folder. I think this should be automatic.
It does not accept both 1.1.20.1 and 1.1.22. Is it just using the 3 MiB 32-bit checksum? The 4 MiB ROMs also have a 64-bit checksum that covers the entire ROM. See DingusPPC romidentity.cpp and
MachineFactory::machine_name_from_rom.If I upload a ROM named "962F6C13", then delete it, and upload one of the 3 ROMs above, then it shows the name as "962F6C13" instead of "1995-08-21 - 962F6C13 - 1.1.20.1 ANS 300 & 500 & 700.ROM". Are the ROMs cached? Can they be renamed?
I have 5 ANS ROMs, but the UI only lets me select 1.1.22, 2.0, and another 1.1.22 (a duplicate?).
The "ROM Image" menu for creating a new machine does not indicate which ROM image file it is using. This info should be in the ROM Image menu or in the ROM list.
Is there a way to show the LCD or serial port output?
Do you know how to skip POST tests during boot? Is it a NVRAM setting or a key switch setting? For example, the DRAM tests for 512 MB take a long time. The testing should appear on the LCD or serial port.
Regarding the 512 MB limit. I wonder if that can be increased by patching the ROM. For example, in DingusPPC, I can patch the Power Mac 9600 ROM to detect 3.25 GiB of RAM. With more effort, maybe I can get that up to 3.75 GB. Mac OS 9 shows the RAM, but I don't know how to test that it is actually usable since Mac OS 9 limits itself to 1.5 GiB. I haven't tried booting Mac OS X (using XPostFacto) yet.
The Open Firmware console doesn't scroll correctly if I open the lcd device.
" lcd" select-dev " hello" write drop. Probably a bug in Open Firmware?Restart doesn't clear the screen.
The
DingusPPC doesn't emulate the built-in graphics controller yet, so I can't compare. Someone with a real ANS could try it.
In the Granny Smith emulation, this causes the display to go white but no text is output.
There's no reset (NMI) button or reboot button?
Regarding the scrolling not working correctly after doing
The screen device can't be opened again? Could be a Open Firmware bug. Or it could be a bug in the graphics controller emulation.
DingusPPC doesn't emulate the built-in graphics controller yet, so I can't compare. Someone with a real ANS could try it.
" screen" outputIn the Granny Smith emulation, this causes the display to go white but no text is output.
There's no reset (NMI) button or reboot button?
Regarding the scrolling not working correctly after doing
" lcd" select-dev. I think it's because the LCD device sets the number of rows/columns to 4/20." screen" select-dev fixes that.A big thank you for taking the time both to try it out, and also to write down a lot of good and valuable feedback! It is much appreciated!
I will answer in another thread, https://tinkerdifferent.com/threads/the-granny-smith-emulator.5587/, as this will be a bit of a side track vs. this thread (and the original topic of this thread), and I don't want anyone to feel that I hijacking the thread - hope that it is ok that I keep this separate.
Welp... I kind of got this far:
Keep in mind, this is with a serial interface and back and forth for the last two weeks with AI tools and a TON of patching.
So if anyone would like to help me continue or look at the work we have put in so far and say "WTF AI hallucination are you doing" I'm all for it. This is state and code to get there that I've been using so far.
The machine state was:
1. 64 MB parity RAM
2. Open Firmware 2.26 ROM
3. normal key mode
4. cd removed after each boot until we got to a prompt (if we reboot with the cd it changed the firmware’s boot/device behavior)
5. VENEER.EXE moved from floppy to rear hard drive.
(Explained = We can launch VENEER.EXE directly from the Windows NT CD, and in fact that was how we originally got the ANS into the NT-specific Open Firmware configuration. But direct CD boot immediately enters VENEER and resets/re-enters the firmware, which gave us very little control over the failing stages. We therefore copied the exact VENEER.EXE to a rear SCSI hard drive and manually loaded it into RAM. That let us verify the image, stop before execution, patch and instrument it, while leaving the CD drive free to serve as the actual NT installation device. The HDD is therefore a debugging/bootstrap mechanism, not something NT fundamentally requires.
A basic summary of the work on real hardware with a AI tools and serial interface
"Using the 2.26 NT-oriented Open Firmware ROM, we established the correct NT firmware state, worked around the SYSTEM PARAMETER BLOCK and RESTART BLOCK allocation problems, corrected VENEER’s loader and memory handling, and traced its broken CD device-path construction. Once that CD path was repaired, SETUPLDR successfully read the NT CD’s ISO-9660 filesystem, recognized the CD001 volume descriptor, and reached the actual Windows NT Setup text screen on real ANS 700 hardware. The current remaining blocker is later in SETUPLDR’s file/path handling, not basic CD readability or PE loading."
@PappaDF also thank you for your work on Granny Smith.
A basic summary of the work with Granny Smith
"With Granny Smith, we were able to continue investigating past the point where the real ANS became impractical to instrument, but it has not actually booted NT farther than the physical machine’s Windows NT Setup screen. The emulator let us trace VENEER’s Cuda reset and ROM re-entry at instruction level, identify the live ROM scanner at FF808A14, and compare the VENEER reset path directly against a known-working AIX reset. That comparison exposed a concrete emulator-side divergence: VENEER comes back with a different SDR1/MMU mapping and scanner target than AIX, pointing to retained-memory or MMU initialization during the reset rather than the earlier CD-read or memory-claim theories. We’ve now traced the live node walker through multiple ROM nodes without patching the guest, so Granny Smith is giving us visibility into why the post-VENEER reset behaves differently, even though the real ANS still holds the furthest actual Windows NT execution milestone"
Code:
Windows NT Setup
The file multi(0)scsi(0)cdrom(0)fdisk(0)partition(1) is corrupted.
Press any key to continue.Keep in mind, this is with a serial interface and back and forth for the last two weeks with AI tools and a TON of patching.
So if anyone would like to help me continue or look at the work we have put in so far and say "WTF AI hallucination are you doing" I'm all for it. This is state and code to get there that I've been using so far.
The machine state was:
1. 64 MB parity RAM
2. Open Firmware 2.26 ROM
3. normal key mode
4. cd removed after each boot until we got to a prompt (if we reboot with the cd it changed the firmware’s boot/device behavior)
5. VENEER.EXE moved from floppy to rear hard drive.
(Explained = We can launch VENEER.EXE directly from the Windows NT CD, and in fact that was how we originally got the ANS into the NT-specific Open Firmware configuration. But direct CD boot immediately enters VENEER and resets/re-enters the firmware, which gave us very little control over the failing stages. We therefore copied the exact VENEER.EXE to a rear SCSI hard drive and manually loaded it into RAM. That let us verify the image, stop before execution, patch and instrument it, while leaving the CD drive free to serve as the actual NT installation device. The HDD is therefore a debugging/bootstrap mechanism, not something NT fundamentally requires.
Code:
dev /packages/pe-loader
3D00000 27800 map-space
dev /
0 value diskih
" /bandit/53c825@12/sd@0,0" open-dev to diskih
diskih .
3D00000 800 20 " read-blocks" diskih $call-method .
3D04000 820 20 " read-blocks" diskih $call-method .
3D08000 840 20 " read-blocks" diskih $call-method .
3D0C000 860 20 " read-blocks" diskih $call-method .
3D10000 880 20 " read-blocks" diskih $call-method .
3D14000 8A0 20 " read-blocks" diskih $call-method .
3D18000 8C0 20 " read-blocks" diskih $call-method .
3D1C000 8E0 20 " read-blocks" diskih $call-method .
3D20000 900 20 " read-blocks" diskih $call-method .
3D24000 920 1C " read-blocks" diskih $call-method .
diskih close-dev
3D00000 20 dump
3D04000 20 dump
3D11C3C 20 dump
.s
dev /packages/pe-loader
3E00000 27800 map-space
dev /
3D00000 3E00000 27800 move
27800 to loadsize
init-program
dev /packages/pe-loader
4000 1000 map-space
dev /
4000 do-translate .s
drop drop drop
4000 20 dump
51E3C 8 dump
514E0 8 dump
5CD20 30 dump
53DA8 20 dump
.s
00 51E3C c!
00 51E3D c!
00 51E3E c!
60 51E3F c!
00 514E0 c!
00 514E1 c!
00 514E2 c!
60 514E3 c!
5C 5CD30 c!
50 5CD31 c!
50 5CD32 c!
43 5CD33 c!
5C 5CD34 c!
53 5CD35 c!
45 5CD36 c!
54 5CD37 c!
55 5CD38 c!
50 5CD39 c!
4C 5CD3A c!
44 5CD3B c!
52 5CD3C c!
5CD3D A 0 fill
00 53DB0 c!
00 53DB1 c!
40 53DB2 c!
39 53DB3 c!
51E3C 8 dump
514E0 8 dump
5CD20 30 dump
53DA8 20 dump
.s
goA basic summary of the work on real hardware with a AI tools and serial interface
"Using the 2.26 NT-oriented Open Firmware ROM, we established the correct NT firmware state, worked around the SYSTEM PARAMETER BLOCK and RESTART BLOCK allocation problems, corrected VENEER’s loader and memory handling, and traced its broken CD device-path construction. Once that CD path was repaired, SETUPLDR successfully read the NT CD’s ISO-9660 filesystem, recognized the CD001 volume descriptor, and reached the actual Windows NT Setup text screen on real ANS 700 hardware. The current remaining blocker is later in SETUPLDR’s file/path handling, not basic CD readability or PE loading."
@PappaDF also thank you for your work on Granny Smith.
A basic summary of the work with Granny Smith
"With Granny Smith, we were able to continue investigating past the point where the real ANS became impractical to instrument, but it has not actually booted NT farther than the physical machine’s Windows NT Setup screen. The emulator let us trace VENEER’s Cuda reset and ROM re-entry at instruction level, identify the live ROM scanner at FF808A14, and compare the VENEER reset path directly against a known-working AIX reset. That comparison exposed a concrete emulator-side divergence: VENEER comes back with a different SDR1/MMU mapping and scanner target than AIX, pointing to retained-memory or MMU initialization during the reset rather than the earlier CD-read or memory-claim theories. We’ve now traced the live node walker through multiple ROM nodes without patching the guest, so Granny Smith is giving us visibility into why the post-VENEER reset behaves differently, even though the real ANS still holds the furthest actual Windows NT execution milestone"
Interesting. The transcript is very helpful and it's impressive it got that far, even though it's (as expected for an AI thrashing around on the data set) a bit prolific. Thank you for posting it.
I think the next step is to create a patched VENEER with what the AI did (and also to catalogue the differences). I might attack some part of that when I'm done with the ANS extension pack; just some polishing left to do.
I think the next step is to create a patched VENEER with what the AI did (and also to catalogue the differences). I might attack some part of that when I'm done with the ANS extension pack; just some polishing left to do.
I assume that one hard stop here is lack of little endian support. I guess that OF would make the switch to LE somewhere?
Agreed. I totally understand that Ai was going crazy in there but some of it was progress.
The good news is, my account just got access to the new Astra model. I'm going to let it hack at it for a bit to see if it can find anything else
Thanks @PappaDF for looking at this!