Hehe, very nice job there, Tari. I think I've seen that "Cowardly refusing..." line before; is it from tar and stdout?

But what about once a hack is developed to use the lower half of flash rom as storage or a usb8x is made. Or if Casio ever makes an SD card version of the Prizm?

Then I guess Tari or another one of us will have to change the one line of code necessary to allow larger executables. A USB MSD thing wouldn't really let us run larger programs, though, because unless programs actively swap pieces of themselves on and off the USB drive, you still can't execute a program larger than memory by executing on the USB drive.

I added big-endian support to the bmp file loader tonight, and it builds correctly. Haven't tested but it should work, since the logic is so basic.
Forgot about the bmp file writer, so that'll just spew broken files on big-endian systems, but meh.

Whatever the case, it will allow itself to be built when the target system is big-endian now.. maybe there's someone out there still on a PPC system who will find this useful (or maybe Linux on ARMEB!).

So this means if someone were to make a Prizm SDK for say Android mkg3a would work, nice job there Tari!

Now there's a nifty idea! Considering how many Linux enthusiasts we have, a package that's easy to use to build on Linux (or at least instructions to compile a GCC-based cross-compiler and kludge mkg3a onto it) would be something in which I would be extremely interested.

Well just remove the binaries from my prizm sdk uploads and use http://sourceforge.net/apps/trac/fxsdk/wiki/UsingGCC to build the GCC and you're set.

Excellent. Now I'm going to have to update the HOWTO to talk about the Windows version of your PrizmSDK at the top, the Linux build instructions directly beneath it, and Simon's SDK last.

Thanks to the newly released Emulator I have discovered a bug in mkg3a and in the documentation which for some reason does not show up on add-ins sent to the real calc.

The byte at 0x000E should be the lowbyte of the inverted filesize (0x13) minus 0x41, and 0x0014 should be that same low byte minus 0xB8.

Proof of this can be seen in the code for cfxm's micro-SDK's g3a-builder

Code:


I didn't know he had the code for his g3a creator included when Tari started mkg3a but now mkg3a is even better and the micro-sdk has been taken down from Omnimaga so it matters not. Either way his code and the code for fxsdk's g1awrapper agree on this methodology.

Great catch there, TheStorm! I mentioned my excitement about emulator-based testing in the HOTWO thread.

Time for a new release version, now at 0.1e. Mostly just bugfixes and convenience changes:

• Input file sizes are checked and very large files will not be processed
  
• A few more useful error messages
  
• Updated logic to fill bytes at 0xE and 0x14 correctly
  
• Disabled filling eActivity regions in header since we don't support that
  
• Version automatically derived from VCS revision when building

As usual, the latest static binary for Windows is at http://media.taricorp.net/mkg3a.exe.

Well, on the plus side, this magically made files be accepted by the emulator! No more Copy Protection problems trying to import .g3as from this tool into the emulator. However, when I press an arrow key on the calculator, either via the keypad or my keyboard, the entire emulator, interface and all, totally freezes, and I have to kill it from the Windows task manager. Perhaps the emulator is emulating an SH3, and some SH4a instruction is breaking it?

The processor is probably an upgraded SH3, not an SH4A. The full instruction set of the SH4A isn't implemented

Yeah, but the hardware Prizm runs the program (Obliterate, of course) fine, whereas the emulator chokes and dies.

Well the Prizm uses a different processor than the fx 9860g. My guess is that Casio is borrowing the opcodes from the old emulator and skipping some of the SH4A instructions.

That would certainly make sense, z80man. I suppose one thing to test would be targeting SH3 using the GCC-based PrizmSDK.

That is an easy change, just edit the CFLAGS line of the makefile to say -m3 in place of -m4a-nofpu.

Funnily enough, my Makefile in the PrizmSDK/projects/oblitr8 folder already has -m3, no -m4a-nofpu.

Oh yeah I forgot I changed it to test just that before I uploaded the SDK, so that is clearly not the issue, though libfxcg most likely still is using -m4a-nofpu.

Ah, so is there anything I can do to rebuild libfxcg in /libs/, or would I have to ask you about that?