Open unassumingbadger opened 3 years ago
Should still be FSINCOS but on different destination parameter (opmodes 0x30-0x37 are all FSINCOS)
Looks like maclc3 tests the FPU hard enough. If you find anything else please consider edit aggregate your OP message with a task list instead of opening new issues.
Can you point me to a copy of StudioPro?
Why does maclc3
even have and FPU by default? Doesn’t an LC III only have an FPU if you install a PDS card with one on it?
Because you can't slot a driver's main CPU, and defining multiple drivers to change what really should be config options is generally frowned upon.
https://everymac.com/systems/apple/mac_lc/specs/mac_lc_iii.html According to this, the 6882 FPU is an add-on. I'm really more excited about that macqd700. Until there's a working 68040 machine, this will do.
Thanks, how did you get the .sit into a MAME-usable form? I tried using the modern Stuffit Expander for Intel macOS and it opened the archive but refused to unpack it.
Can you PM me a link to the .ISO to save time?
I should also add MacGarden .cdr and .toast can be mounted directly with -cdrom
Really wish I still had access to a 68040 machine. Unsit inside LC III is like watching paint dry.
Got it. What version of StuffIt can open those .sits on the CD? I tried 3.6 and 4.01 that I have and both errored out.
There you go guy. You should be able to mount the .toast image directly.
Cheers, thanks for everything, I have everything I need installed to figure this out.
With https://github.com/mamedev/mame/commit/ff553b2b99de181ac2e2aa0b779e5c38fd0908be you can load StudioPro 1.5.1 and open many of the Shapes examples like the apple. Trying to rotate or render them will hit additional FPU missing instructions, but flipping between wireframe, hidden-surface wireframe, and basic shaded views seems to work.
mame0232-264-g73d97b7dc49
A few more from messing around with it tonight. If there's something else that needs your attention, you've gone above and beyond what my expectations were. Photoshop, Freehand, newer 68k Illustrator, and just getting StudioPro to load. It's looking really nice. Thank all of you for your efforts.
lathe extrude fpgen_rm_reg: unimplemented opmode 1C at 01E86BF6
opening shape teapot fpgen_rm_reg: unimplemented opmode 0A at 01E86794
raytrace fpgen_rm_reg: unimplemented opmode 0A at 01ED8270
skinning poly fpgen_rm_reg: unimplemented opmode 0C at 01E86CB6
AutoCAD for Mac r12 also uses opmode 0A at startup, which seems to be FATAN... Problem is, our softfloat library doesn't seem to support atan?
Notes for testing this: AutoCAD seems to require at least 8 MB of RAM, and 32-bit addressing on, so I just gave the Mac IIvx 16 MB of RAM, and it at least tried to startup before hitting that opcode.
Right. There's an interlocking set of issues here.
1) The best m68k SoftFloat trig implementation is from Previous, which is also in WinUAE. It's GPL, which is not optimal for MAME, and based on SoftFloat 2. 2) Bochs has a BSD-licensed set of trig functions for SoftFloat 2 that are BSD/MIT licensed, but are oriented towards x87 which has a somewhat different ATAN from m68k (it takes 2 arguments instead of 1, and I haven't researched the difference yet). We do already use some Bochs code for sin/cos/tan. 3) We're trying to move from SoftFloat 2 to 3 because SF 2 has a weird licensing situation which is likely neither GPL nor BSD compatible, while SF 3's license is explicitly BSD-compatible.
My current plan is to move to SoftFloat 3 and port the Bochs stuff forward, but in the meantime I'm not against fixing issues based on what we have.
https://www.cpu-world.com/CPUs/68881/index.html
Motorola 68881 (MC68881) is a co-processor used with second generation of Motorola 68K microprocessors - Motorola 68020 and 68030. The 68881 could be theoretically used with earlier 68000/68010 CPUs, but only as a peripheral device.
https://www.cpu-world.com/CPUs/68882/index.html
Motorola 68882 (MC68882) is an enhanced version of 68881 Floating Point Unit. The 68882 is pin- and object-code compatible with the 68881, and, like the 68881, it could work with Motorola 68020 and 68030 microprocessors.
Ideally the user could specify on Mac and Amiga 68030 machines if they want an FPU.
Photoshop takes advantage of FPU if it thinks its there, but it doesn't need one in the first place. https://lowendmac.com/2013/photoshop-for-mac-faq/
Photoshop 1.x requires Mac System 6.0.3, 2 MB of RAM, a 68000 processor, and a floppy drive. Photoshop 2.x requires Mac System 6.0.7, 4 MB of RAM, a 68020 processor, 32-bit QuickDraw, and a floppy drive. Photoshop 3.x requires Mac System 7.0, 16 MB of RAM, a 68020 processor, 25 MB of available hard drive space, and a floppy drive.
I have chosen to represent these systems in their best possible light; the MacOS FPU emulation that these programs would fall back on is extremely slow and these are not fast machines to begin with. (Also, as far as I'm aware, Photoshop works fine, it's other stuff that hits ATAN). If you need to run this software right now for whatever reason, Basilisk will probably do fine for you.
I actually have a branch for implementing FATAN at least, since xeyes on Domain/OS wanted it: https://github.com/NattyNarwhal/mame/tree/implement-68k-fatan
IIRC, it executes, but I'm not sure if the values I get are correct. I also had to backport some chunks of Bochs' SoftFPU for it.
That's great, @NattyNarwhal! I looked over your changes and they seem reasonable, if you'd like to submit a pull request I'll take it.
Right. There's an interlocking set of issues here.
1. The best m68k SoftFloat trig implementation is from Previous, which is also in WinUAE.
I run into unimplemented opmode 10 while trying Speedometer 4.02 on macii machines. So I googled around and found this
https://github.com/captain-amygdala/pistorm/blob/main/m68kfpu.c
But so far I failed to integrate new files into MAME's buildsystem. Just adding dummy cases like this
@@ -1477,6 +1488,29 @@ void m68000_base_device::fpgen_rm_reg(u16 w2) m_icount -= 75; break;
}
+ case 0x10: // FETOX
+ {
+ //m_fpr[dst] = exp(floatx80_to_float64(source));
+ SET_CONDITION_CODES(m_fpr[dst]);
+ m_icount -= 75;
+ break;
+ }
Allow main full test to pass, but guess this mean benchmark does not care about correct results ....
PiStorm has a licensing problem too - the project itself is MIT but the FPU stuff is from Previous and therefore GPL. So unless they have permission to relicense those bits as MIT they've got issues.
mame0232-203-ga141e416778
Got a bit further in Strata StudioPro (1.5.2), but hit another snag.
./mame maclc3 -ramsize 32M -hard1 maclc3.hdv Ignoring MAME exception: fpgen_rm_reg: unimplemented opmode 36 at 01DC617C Fatal error: fpgen_rm_reg: unimplemented opmode 36 at 01DC617C