Minimig Review completed!

[freqmax]

I think it's possible to make the FPGA update the PIC, provided that the MCLR and some other pins can be used for this.
However, there's currenly hardly ANY i/o pins available. I would suggest to use a XC3S500-PQ208 for the next version.

[HenryCase]

freqmax wrote:
I think it's possible to make the FPGA update the PIC, provided that the MCLR and some other pins can be used for this.

Excellent! :-)

freqmax wrote:
However, there's currenly hardly ANY i/o pins available. I would suggest to use a XC3S500-PQ208 for the next version.

Not going to be an issue. I'm not proposing the PIC programming code be built into the standard Minimig FPGA core, it would be a separate core, written for the sole purpose of updating the PIC, so you'd have all FPGA pins at your disposal.

Bigger FPGA in the next Minimig version is desirable, but it's not necessary for adding PIC updating functionality.

[freqmax]

No I/O available, change fpga or no room for this.
(maybe there is but it will be REALLY tight)

[HenryCase]

freqmax wrote:
No I/O available, change fpga or no room for this.
(maybe there is but it will be REALLY tight)

I looked into this matter, here's what I found...

According to the Minimig v1.1 schematics (found here: http://home.hetnet.nl/~weeren001/downloads/minimig11_schematics.pdf), the following pins of the PIC and FPGA are linked:

Code: [Select]

Link name PIC pin FPGA pin
FPGA_SEL0 3  93
PROG_B  4       207
INIT_B  5  83
CCLK  7  104
SPI_CLK  14  90
SPI_DOUT  15  19
SPI_DIN  16  85
RXD  18  185
DONE  24  103
FPGA_SEL1 26  86
FPGA_SEL2 27  87
DIN  28  92

According to this page, http://home.earthlink.net/~davesullins/software/pic18f.html, the pins you need to reprogram a PIC (18F series) are: SDATA/RB7, SCLK/RB6, PGM/RB5, Vpp/MCLR. On the PIC in Minimig v1.1 these are:

Code: [Select]

PIC pin name  PIC pin number
SDATA/RB7     28
SCLK/RB6      27
PGM/RB5       26
Vpp/MCLR      1

In other words, three of the four pins we need are already linked to the FPGA. The last one, pin 1, is linked to a 'programmers button' according to the Minimig schematics. As far as I can tell, pin 1 isn't a data line, so as long as you hold down this button you will be able to reprogram the PIC using the FPGA.

So why do we need these extra pins again? :-P

[yester64]

First off, amazing.
i am really impressed with that board. i don't even mind that it does not come in a casing. for hardcore fan's will create their own anyway.
sadly, it does not have hdd support right now. so you really looking into disk only operation.
but for just playing games its alright.
since i don't have an amiga at all (still regret to sold my previous ones) that might be an option.
is there a software list, what is supportet and what not? i read that there are some games that do not run.

[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]

[freqmax]

@HenryCase:
Now you got to check:
1) Does using these pins "the wrong way" interfere with anything else?
2) How to handle the MCLR.

I assume the PIC18 is 3.3V or we have another issue aswell.

I suspect with a special HDL-code and the user holding down the PROG button. One can reprogram the PIC18.
Provided power glitches doesn't happen and certain bits aren't set which requires highvoltage reprogramming.

[TobiFlex]

Piru wrote:

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]

You are right. "movec d1,vbr" is the Instruction to detect the 68010 and this is also illegal on the 68sec000. So the 68sec000 is detected right to 68000.

Yesterday i make a test with the TG68 Core. For the test I change the mode for the "Move from SR" Instruction to use in supervisor mode only. All Kickroms starts also fine.

But what is then the TheDaddys Problem?

TheDaddy wrote:

Well...I have tried renaming kickstart 2.04 and 3.0 to KICK.ROM and all I get is a red screen and nothing else.

It seems only to work with 1.3 (512K).

I was going to test the failing games with 2.04 but it won't boot (just red screen).

 

 :-?

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

[TheDaddy]

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

But those roms (amiga forever ones) work fine with WinUAE or this doesn't matter?

Do you think that the failing games fail because of the encrypted  roms? Even if this is the case it would be a pain to have to rename 2.04 rom (KICK.ROM) for example to play some games and then put the 1.3 back in to play some others...

I have also used the 1.3 from amiga forever cd and that works fine.

What do you think?

 :-)

[TheDaddy]

>>is there a software list, what is supportet and what not? i read that there are some games that do not run

www.loriano.pwp.blueyonder.co.uk

have a look :-)

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

[TheDaddy]

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

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

[straycat]

TheDaddy wrote:
Do you think that the failing games fail because of the encrypted  roms? Even if this is the case it would be a pain to have to rename 2.04 rom (KICK.ROM) for example to play some games and then put the 1.3 back in to play some others...
 :-)

When you've figured how to get Kickstart 2.04/3.0 working I wonder if you might be able to use an ADF of Relokick to revert the Minimig to 1.3 for some games? This might solve your problem of needing to rename the Kickstart for certain games.

[amazing]

if u use this list then u know what kickstart u need

http://www.opencircuits.com/Minimig_Software_compatibility