Minimig Review completed!

[Piru]

@Dennis

I think the "move.w $0128(A6),D0" is wrongly disassembled and should actually be the Move from SR instruction. As this instruction is priviliged the code for 68010/68020 will be executed.

Nope. That sequence is

Code: [Select]

move.w AttnFlags(a6),d0 ; a6 = sysbase
btst   #AFB_68010,d0, and it is correctly disassembled.

This is not the CPU detection, it's done earlier, at FC02A8. Here a subroutine FC0546 is called. At FC0564 it does "movec d1,vbr", which is illegal instruction on real 68000 (at least). Apparently it is not illegal for 68sec000(?), and thus the processor is considered a 68010. [EDIT] It is illegal on sec000, too, see below for update [/EDIT]

Now, some have said that the 68sec000 would use the 68000 stack frames. But if this was the case, then the OS would not work at all: Any call to SuperState or Supervisor would nuke the system, aswell as any bus error or address error.

So assuming the 68sec000 CPU really is detected as a 68010, and the KS ROM works unmodified, then it actually means the CPU uses 68010 compatible stack frames. Ohwell, I guess I could just consult the pdf.. :-)

[EDIT]

Ok I read the docs now. The CPU is detected as 68000 just fine. The problem is that "move.w sr,EA" is privileged on 68EC000 and 68SEC000. Thus exec/GetCC() (in user mode) will nuke, aswell as any old application/game/demo using "move sr,EA" (in user mode). IMHO MiniMig should be made to scan the KS ROM for the "move.w sr,EA" bit pattern and patch those to "move.w ccr,EA" (it's 1 bit change, the instructions are almost identical). Obviously the KS checksum should be fixed after the change. That would take care of exec/GetCC().

That would not fix games/demos/apps using the instruction directly, however.

If it would be possible to somehow "hijack" the privilege violation exception vector transparently, then that would be the perfect solution. The exception handler would read the instruction word, determine which EA to write the result to, and then fetch stackframe SR and store it to the correct location (for data registers the lower 16bits), and finally skip the original instruction. That'd basically emulate the "move sr,EA" transparently.

The trouble here is that to function effectively it'd need to do this without relying on the exception vector table which is poked by KS ROM, games and demos directly...

[/EDIT]

[Piru]

Well, if TheDaddy is using the

ones from my Amiga Forever cd

, then this might be his problem (the Amiga Forever images are encrypted).

To use them you need to start the emulation and use some tool to grab the KS ROM just like from real amiga.

[Piru]

But those roms (amiga forever ones) work fine with WinUAE

WinUAE has decryption support for the Amiga Forever encrypted images. As far as I know MiniMig does not.

The Amiga Forever encrypted images are of size 524299. Unencrypted ones are 524288 bytes.

[Piru]

What about the fact that the 1.3 rom from the Amiga Forever cd works fine?

That file is 262155 bytes. AFAIK MiniMig requires 524288 byte file, that is the original (decrypted) 1.x image put to a file twice.

[Piru]

MiniMig works with A500/A2000 KS ROMs, 1.x, 2.0 and 3.1 at least.

The file must be 524288 bytes (so KS 1.x must include the 256KB ROM twice).

As far as I know you must use the vanilla KS ROM Image, not any Amiga Forever encrypted one (the encrypted have size 262155 and 524299).

[Piru]

Let me try to explain again.

The files on the Amiga Forever are encrypted. WinUAE decrypts them at loadtime, and when the emulation is running the KS ROM are available in memory.

You must use some program to grab the KS ROM from within the emulation, with for example SaveROM program in BlizKick archive.

For 256KB KS ROMs you need to merge the file with itself so that you get 512KB file (for example "join kick13.rom kick13.rom to kick13_512k.rom").

[Piru]

@TheDaddy

So basically you are saying that the kickstart roms from Amiga Forever cd don't work?

They do not. As I've stated many times already, they're encrypted, and MiniMig requires vanilla unencrypted images.

[Piru]

@freqmax

In the case of a 256kB rom you can simple pad the rest so that it becomes 512kB. It doesn't matter.

Oh, interesting. Typically most implementations that require 512KB ROM will place the whole 512KB at address 0xf80000, in which case with 256KB ROMs the 2nd 256KB will actually be used as the ROM (0xfc0000).

If it manually handles the mirroring then it IMO could have directly supported 256KB files, too.

[Piru]

Missing sprites and such glitches are due to chipset implementation and should be possible to fix easily.

68ec000/68sec000 only causes trouble with games/demos/apps that use "move from sr" in user mode, or call GetCC() [as long as GetCC is not patched].

I'd estimate most trouble are from the chipset emulation issues, rather than "move from sr".

[Piru]

@TheDaddy

How do you explain my minimig working with the rom from amiga forever cd?

Well, I checked with AF6. At least that CD only has encrypted KS 1.3 ROM.

What is the location and size of the file on the CD? And which AF version is it?

[Piru]

MiniMig does not support decrypting the image so the keyfile won't help.

AF/WinUAE uses that key to decrypt the other files. As said before, you can save the decrypted files from within emulation...

[Piru]

Just a clatification: AF kickstart roms are 100% identical to the "original" ones, after you save the decrypted version.

[Piru]

@denli

No need to use tinyurl. Just use:
{url=fullurlhere}description{/url}

and replace {} with [].

[Piru]

EC000UM.pdf indeed suggests it would be ok from user state. This wouldn't be the first time the motorola/freescale documentation is wrong.

If it indeed works in from user mode then the CPU should be pretty  much fully compatible. That'd be nice indeed.

[EIDT]
But hmm that pdf looks like SCM68000 manual. How very confusing.
[/EDIT]

[Piru]

@TobiFlex

What about "Move from CCR"? It is illegal on the 68000.

It is.