Minimig (Amiga) core discussion

[Sorgelig]

i'm not quite understand the problem.
Is it just 256K/512K/1M size of rom? Then it can be autodetected at core side.

[R4MS]

The boot rom is only around 8k. So i definitely need to adjust UploadKickstart(), because currently it only loads files that are 256k, 512k or 1M long. But you are right, the core can indeed detect the length of the OSD upload. Therefore no new OSD_CMD is needed.

[Sorgelig]

Yeah, probably you just need to tweak the HPS code to allow to upload any KS size up to maximum. And then let the core to decide what to do with different KS sizes.

[R4MS]

OK. Done.

If the Kickstartfile selected is 8192 bytes long (or 8203 when Amiga forever encrypted), the MiSTer binary loads the file to $f80000. Moreover it clears $fc0000 to invalidate Kickroms which could already be loaded from before.

Every time the OSD writes to $f80000, the core is set to bootrom mode. When OSD writes to $fe0000, which it always does when loading a Kickrom, bootrom mode is turned off. During that time Minimig is in halt mode, so it only sees the final result of that procedure.

Now bootrom mode does pretty much what an A1000 would do. On reset, $fc-$ff is write enabled and the bootrom is visible at $f8 (direct access to memory as usual). On the first write access to any address from $f8-$fb, $fc-$ff gets write protected and mirrored to $f8-$fb. This does not interfere with any other settings. You can boot a 256K Kickstart disk on A1200 hardware settings this way.

And I deleted the "hrtmon is not compatible with fastram" message from menu.cpp.

I'll do some tests and upload it by tomorrow, if I don't find any bugs.

[Sorgelig]

May be you can try to fix this problem:
https://github.com/mist-devel/mist-board/issues/109
It's also actual for MiSTer. Since release of WB3.1.4 many users stuck with this problem.

[R4MS]

OK, I promise, I won't spend more time on useless features. I did do quite some Kickstart mods using this feature in the old times and it was quite interesting to see things from the other side.

Personal todo list:

* IDEfix bug
* 3.1.4 MMU.lib bug
* Mount filesystem as hd

I'll order 3.1.4 today. I guess, we should only support the A1200 version, which is the one I'll be getting. They sell five different versions, which differ in the rom image. Bug reports therefore should always include the rom version used.

[Sorgelig]

A1200 should be the best.

[BBond007]

Personal todo list:

* IDEfix bug
* 3.1.4 MMU.lib bug
* Mount filesystem as hd

Thanks, I really appreciate you looking at the IDEFix bug. Mounting the fileSys as HD sounds really awesome too...

I'll order 3.1.4 today. I guess, we should only support the A1200 version, which is the one I'll be getting. They sell five different versions, which differ in the rom image. Bug reports therefore should always include the rom version used.

I absolutely hate the way the way Hyperion Entertainment is packaging/selling this AmigaOS 3.1.4 thing

Not only that, even the web-server for that company is currently in disarray with the Chrome browser giving me a stern warning I must [x] acknowledge before proceeding...

Still, I'm interested in hearing if it a worthwhile upgrade over 3.1 + BetterWB or ClassicWB...

If there is anything compelling then I'd probably proceed by buying it from a trusted Amiga vendor with physical ROM which I could install in my A1200 with blizzard 1260.

[kolla]

* 3.1.4 MMU.lib bug

This is not really a 3.1.4 bug, as 680x0/mmu.library is not part of OS 3.1.4, but is included on "BestWB".
I would expect the same bug to appear with old 3.1, a newer SetPatch and the mmulib package installed...

http://aminet.net/package/util/libs/MMULib
http://aminet.net/package/util/boot/SetPatch_43.6b

(though, perhaps only the 3.1.4 SetPatch care about 68020/68030.library)

Anyways, this is most likely an issue with the 020 implementation of TG68 (MikeJ says to have fixed this, but he _clearly_ don't grasp the "release early, release often" mantra of open source development), so I wish you good luck

Regarding TG68... does it have what's needed to add an FPU? A cool experiment could be 68882 emulator running on the ARM... but then again, maybe it is easier to move the entire CPU to software emulation

[R4MS]

I do not see the need for a FPU. I guess nobody wants to do numerical calculations on those old machines. I find MMUs much more interesting.

[Sorgelig]

I also think FPU is quite useless in Minimig. It needed by only few very specific apps. It's something that could be implemented when has nothing else to do.
MMU is more important for Amiga.

But that MMULib problem is not about implementing MMU. It's just some instruction bug. MMULib shoudn't crash but just silently "sitting" useless.

[MartinW]

...

[Sorgelig]

Using FPU in demos is cheating! Real demos don't use FPU.

[kolla]

I asked if tg68 has what it takes to add an FPU. How useful an FPU is depends entirely on what kind of software the user intends to run on the system. An MMU has even less use-cases with Minimig. The "mmulib" problem is, as far as I understand, not related to MMU, nor mmu.library, but to the 68020.library in the same package. It tries (from what I understand) to rectify minor known issues with the 68020 from Motorola... and not tg68/020.

[Sorgelig]

MMU is useful at least for WHDLoad.

[R4MS]

A MMU is fun. It is the basis for memory isolation of processes and therefore essential for modern operating systems.

[kolla]

Right, so we can run Linux/68k or NetBSD on the FPGA in addition to the ARM, hehe.

WHDLoad only supports MMU of 030, 040 and 060, and not 68020+68851, so good luck

http://www.whdload.de/docs/en/mmu.html

Anyways, I was just suggesting something that might be a stepstone in the direction of hybrid emulation that was discussed earlier.

[R4MS]

Has anyone noticed issues with IDEFix?
The mouse still works and workbench windows can be moved, but they don't redraw and the system is basically dead...

I probably found an easier way to trigger this bug. Immediately after booting BestWB1.1 (Kick/WB3.1.4), "lha x" a file on a floppy to the harddrive reliably produces the same kind of symptoms. After exercising the system for a while, the same command does no longer produce that crash.

Perhaps some kind of race condition when using to different devices simultaneously.

P.S. WinUAE does not crash in this scenario. Couldn't test on my A1200, because it is scheduled for recap surgery.

[kolla]

So what max transfer rate and blocksize have you set for the filesystem? Note that IDEFix replaces the OS scsi.device entirely, so OS 3.1.4's "fixed" scsi.device is not used, while UAE by default uses uaehf.device and not scsi.device, so for UAE you have to specify that you wish to fully emulate gayle style IDE controller for which scsi.device and hence IDEFix will be used. Phew.

[R4MS]

I did some tests with 3.1.4, and some things do not look good. Just using the original 3.1.4 distribution, I found

* HDToolBox does not work correctly. When adding a drive type, "Read Configuration" results very incorrect settings (size of 256TB instead of 20MB). Several other things do not work as expected.
* often crashes (in the same way as described in case of IDEFix) when formatting a partition.
* Sometimes crashes in the same way when transfering data from fd to hd

Maybe things are smoother when the partitions are not made by HDToolBox on MiSTer. But still, I guess we do have a bigger problem there than just the IDEFix crash.

P.S. 3.1 seems to be fine. Did not test extensively, but HDToolBox worked as expected and the system did not crash.

[BBond007]

I been setting MaxTransfer to 0x1FE00 and have noticed HDInstTools does a better job of properly detecting drive size than HDToolBox.

[R4MS]

At least a problem with the MMULib is, that tg68k does not implement the (68010) instruction RTD. But that should be an easy one. It moves the content of the stack to PC and adds some immediate value to SP.

[BBond007]

Many of the sequences in the new De Profundis demo don't properly display on HDMI or VGA with vga_scaler=1. For example, the very first sequence with the clock/key thing does not display for me. I asked in the scaler thread:

I have tested that demo, there is a regression in Minimig between version 2019_03_09 and 2019_05_01, with the same scaler. Ask Minimig maintainers...

Although I'm having the same issue with 2019_03_09. Also when running this demo I get no OSD on the analog VGA.

Thanks

De Profundis --> http://www.pouet.net/prod.php?which=81081

[R4MS]

Works fine here with HDMI. I used 68020, Turbo: Both, ECS, Kick 2.04, Chip 1M, Fast 4M, Slow 1.5M... that should be a good setting for an ECS demo.

There has been a memory mapping error in 20190501, which was fixed in the current release 0502 (or so). But that should only do damage if a program uses a lot of fast ram.

[killersquirel]

I'm having problems with Minimig after the last update or so for the MiSTer. My configuration loads, but when I try to use Xbench to load up some games it crashes and doesn't allow me to get to the menu to choose the game. Any idea how to fix this? Thanks in advance.