VanillaMiNT has finally been updated

[wongck]

Great to see more people get on the Mint Bandwagon.
Hopefully it will spur more software usage and software development for Mint.

[joska]

Wow! I just tried the 040 version on WinUAE + EmuTOS, it worked out of the box
Of course, only monochrome ST-High is supported, as usual.

Thanks for testing, I never did that myself but assumed it would work...

I also tried it on real Amiga + Vampire V2. It worked equally well, but before that I had to rename xaaes040.km to xaaes060.km. Ideally, the Apollo 68080 should be detected as 68040, but due to the presence of PCR register is it currently detected as 68060. So xaloader.prg tries to load the wrong module. This is a known issue, I plan to provide a patch for proper Apollo 68080 detection as 68040 in FreeMiNT (already done in EmuTOS).

I'm going to go for another solution - compile everything except the kernel itself for 020-060. That way it would work in both 030 and 060 mode on the CT60 by just booting the correct kernel. But yes, MiNT should detect the correct CPU type here.

Note about mouse drivers: inside the xaaes folder, only one of moose.adi or moose_w.adi should be present. I think that only keeping moose_w.adi should be safe for everyone.

Thanks for spotting that. Corrected

[trecool]

In other words, for some strange reason, xaaes didnt choose the default mode when video config file is missing...

That's strange. Is your NVRAM OK? Is there a newdesk.inf present?

Newdesk.inf is there and nvram (standard chip, modded external battery) seems to work since it keep date/time and settings...

[BlankVector]

I'm going to go for another solution - compile everything except the kernel itself for 020-060. That way it would work in both 030 and 060 mode on the CT60 by just booting the correct kernel.

Maybe not a good idea. Remember that currently, executables (such as xaloader.prg) compiled with -m68020-60 require an FPU, so they can't work on FPU-less Falcon (as well as current Apollo 68080). I have opened an issue on GitHub about that. This does not affect kernel modules, as they don't use the MiNTLib.

[joska]

Remember that currently, executables (such as xaloader.prg) compiled with -m68020-60 require an FPU, so they can't work on FPU-less Falcon (as well as current Apollo 68080).

Doesn't that apply to -m68030 as well?

[BlankVector]

Standard GCC 4 settings:
-m68020-60 requires FPU (-mhard-float is implied)
-m68030 does not require FPU (-msoft-float is implied) EDIT: THIS IS WRONG
And m68k-atari-mint-gcc follows this standard.
The MiNTLib startup code checks the _FPU cookie. If compiled for FPU (even if the program doesn't actually use the FPU) and the FPU is not present, the program displays an explicit error message and refuses to run.

[joska]

Hmm... I was trying to avoid to compile all the tools for a specific CPU. Maybe just use 68000 like the standard MiNT build does and only compile the kernel and kernel modules for the target CPU.

[Eero Tamminen]

I tried this in Hatari with latest EmuTOS snapshot (as EmuTOS works without HD driver), but I'm running into problems:

On TT emulation:
* If I either enable MMU, or 32-bit addressing & TT-RAM, I get bus error & EmuTOS panic after "realloc_region: reg is NULL"
* If I don't enable MMU, things get further, but die now after SCC init. Neither EmuTOS nor Hatari supports TT SCC. I think this is MiNT driver bug, it doesn't handle SCC (non-)existence properly

On Falcon emulation:
* I have only v2.5 NVDI and that doesn't have driver for Falcon

Is there fVDI setup that works with VanillaMiNT?

[joska]

It works with TOS VDI in mono.

[BlankVector]

Neither EmuTOS nor Hatari supports TT SCC.

EmuTOS supports it.

I think this is MiNT driver bug, it doesn't handle SCC (non-)existence properly

If you don't have SCC, then just go to \mint\1-19-cur and remove scc.xdd.

[mikro]

I'm going to go for another solution - compile everything except the kernel itself for 020-060. That way it would work in both 030 and 060 mode on the CT60 by just booting the correct kernel.

Maybe not a good idea. Remember that currently, executables (such as xaloader.prg) compiled with -m68020-60 require an FPU, so they can't work on FPU-less Falcon (as well as current Apollo 68080). I have opened an issue on GitHub about that. This does not affect kernel modules, as they don't use the MiNTLib.

There's also my pull request for FreeMiNT to make something like that by default: https://github.com/freemint/freemint/pull/20 ... i.e. you'd have only 000/020-60/v4e builds but unfortunately Alan seems to be from the 'hardcore camp' who wants all CPUs supported separately even if it leads to maintenance hell and confusion for normal users.

And about the -m68020-60 problem, you're safe Jo -- there's no single float/double in the whole FreeMiNT repository. :-) Another thing is, and I think it's mentioned in that issue that Vincent has linked, that yes, if you're on a FPU-less Falcon you'll get an error even if running the binary is perfectly safe. My proposal was to issue a warning instead of error but of course, it's not perfect.

This is even more frustrating because xaloader (usbloader, mintloader, ...) do not use mintlib at all, so their startup code can be changed. And perhaps it should.

EDIT: OK, I should have looked before post -- xaloader does not contain the FPU detection code. So you're free to compile it with -m68020-60.

Standard GCC 4 settings:
-m68020-60 requires FPU (-mhard-float is implied)
-m68030 does not require FPU (-msoft-float is implied)
And m68k-atari-mint-gcc follows this standard.

Holy crap! I've been using gcc4 for how long, 10 years? And I would bet anything that -m68030 is equivalent to -m68020-60 when it comes to libc path and now I see it is not! :)

[BlankVector]

Holy crap! I've been using gcc4 for how long, 10 years? And I would bet anything that -m68030 is equivalent to -m68020-60 when it comes to libc path and now I see it is not!

You are right! I wrote a mistake! (time to sleep)
In GCC 4 patch, I willingly configured -m68030 as an alias for -m68020-60. So both require FPU.
Things need to be completely reworked, if we decide to do so.

[Eero Tamminen]

Neither EmuTOS nor Hatari supports TT SCC.

EmuTOS supports it.

I think this is MiNT driver bug, it doesn't handle SCC (non-)existence properly

If you don't have SCC, then just go to \mint\1-19-cur and remove scc.xdd.

Ah right, I should have though that. After that Hatari TT emulation + EmuTOS continues...

There seems to be something very weird happening with mint.cnf parsing. Depending on how much comment or echo lines there are after INIT= line, MiNT either parses, or doesn't parse the INIT line.

Now it crashes after INIT line parsing to:

Code: Select all

M68000 Bus Error reading at address $ffff8c85 PC=$25680.

With Falcon emulation MiNT & XaAES & Teradesk start fine, both in mono & color (though NVDI v2.5 complains about "Kann NVDIDRV|.SYS nich finden!" in both), both with and without MMU emulation.

With TT-RAM & 32-bit addressing, the setup will crash after Teradesk has booted.

Bootup crashes with mint.cnf handling & MMU enabled happen only with TT-emulation. I wonder whether former is something related to ACSI as under Falcon, I used IDE interface for the harddisk image.

Btw. There's something weird with MiNT console output, I get huge amount of these warnings from Hatari, with and without xconout.xdd:

Code: Select all

WARNING: xconout character has unknown high byte bits: 0x606a 'j'.

[BlankVector]

There seems to be something very weird happening with mint.cnf parsing. Depending on how much comment or echo lines there are after INIT= line, MiNT either parses, or doesn't parse the INIT line.

Yes, this has been recently discussed on the MiNT Mailing List. MiNT has fun when loading CNF files by passing odd (non-even) buffers to the disk API. Even if this questionable, we are going to fix EmuTOS to support that on plain 68000. Currently, the EmuTOS IDE driver crashes with illegal address in such case.

[Eero Tamminen]

MiNT has fun when loading CNF files by passing odd (non-even) buffers to the disk API. Even if this questionable, we are going to fix EmuTOS to support that on plain 68000. Currently, the EmuTOS IDE driver crashes with illegal address in such case.

Any idea why I get CNF file problems only with TT emulation (= ACSI), not with Falcon (=IDE)?

[BlankVector]

Any idea why I get CNF file problems only with TT emulation (= ACSI), not with Falcon (=IDE)?

This problem should only be present with 68000 ans IDE...

[Eero Tamminen]

There seems to be something very weird happening with mint.cnf parsing. Depending on how much comment or echo lines there are after INIT= line, MiNT either parses, or doesn't parse the INIT line.

Any idea why I get CNF file problems only with TT emulation (= ACSI), not with Falcon (=IDE)?

This problem should only be present with 68000 ans IDE...

According to EmuTOS list, Roger fixed unaligned access issue also for ACSI and then CNF file seems to work fine.

I think this is MiNT driver bug, it doesn't handle SCC (non-)existence properly

If you don't have SCC, then just go to \mint\1-19-cur and remove scc.xdd.

Ah right, I should have though that. After that Hatari TT emulation + EmuTOS continues...

Now it crashes after INIT line parsing to:

Code: Select all

M68000 Bus Error reading at address $ffff8c85 PC=$25680.

Which is SCC register access. I.e. MiNT does SCC accesses on TT even when SCC.XDD has been removed.

After changing Hatari to ignore SCC register accesses, VanillaMiNT startup gets further also on TT.

Now XaAES starts, but freezes after this message is shown:

Code: Select all

pid 3 (AESSYS): block_IO [C]: sleeping in bio_unit_wait [1191, 1024]

[Gaiyan]

Finally got around to installing VanillaMiNT on my TT after receiving the PARCP-USB. Whoa! It's awesome. Glad to be using MiNT again. Great job, Joska!

[joska]

In GCC 4 patch, I willingly configured -m68030 as an alias for -m68020-60. So both require FPU.
Things need to be completely reworked, if we decide to do so.

So basically you have to compile for 68000 if you want to create binaries for FPU-less Falcons using gcc? I guess this explains why Frank did exactly that when he restructured the sources in 1.15. Everything - except the kernel and XaAES kernel module - is compiled for 68000.

[joska]

I had to manually set the video mode in xaaes.cnf.
After that system boot to desktop. Then I set the screen using your tool and the video.cnf file created, I put back the include line and now works.

In other words, for some strange reason, xaaes didnt choose the default mode when video config file is missing...

I got my CT60 up and running last night, and when installing VanillaMiNT I ran into the same problem as you. It turns out that the CT60 use a TV/RGB boot mode by default, even if I have a VGA monitor connected. This made XaAES crash when opening the VDI workstation. As soon as I changed the bootmode to a VGA mode everything worked.

I will add a note about this in the VanillaMiNT installation guide.

[mikro]

Pure coincidence, I can report the same. HOWEVER. It does crash on RGB, too. So I'd say the issue is a bit deeper.

Then only some minor notes:

- fscheck.prg is not found
- xaloader.prg should be in GEM= not INIT=
- readme says " Unpack/copy to the root of your boot partition, usually c:" -- this sounds like I have an option but all configuration files refer to C:\ as a hardcoded drive so it's not possible to boot from F: for instance
- some keyboard filenames are too long and unzip.ttp complains about them

EDIT: Damn it, so I'm not able to make it running in RGB at all. If I hardcode "video = 267", this is what I get:

IMG_20170407_180649.jpg

[joska]

Pure coincidence, I can report the same. HOWEVER. It does crash on RGB, too. So I'd say the issue is a bit deeper.

Yes, that sounds like a problem in XaAES. I don't have an RGB monitor available right now (too small mancave!) but will look at this when I do.

- fscheck.prg is not found

Correct, it has been removed but apparently I forgot to remove this from the template mint.cnf too. Will fix.

- xaloader.prg should be in GEM= not INIT=

There was a reason for doing this but I can't remember exactly what I'll take a look in my notes.

- readme says " Unpack/copy to the root of your boot partition, usually c:" -- this sounds like I have an option but all configuration files refer to C:\ as a hardcoded drive so it's not possible to boot from F: for instance

That's true. I have not had success in using only relative paths in mint.cnf and xaaes.cnf. Also, there are absolute paths in various configuration files outside of MiNT itself (cops.inf, teradesk.inf). I will change the wording in the readme.

- some keyboard filenames are too long and unzip.ttp complains about them

Yes. It's very unfortunate that the MiNT repository use long filenames for files that are supposed to be on the boot partition. There are also readme files with long filenames.

EDIT: Damn it, so I'm not able to make it running in RGB at all. If I hardcode "video = 267", this is what I get:

That's odd... The previous (original) VanillaMiNT was actually developed on an RGB monitor. I also tested the screenmode selector in RGB. But there has been some changes to XaAES since then.

[mikro]

That's odd... The previous (original) VanillaMiNT was actually developed on an RGB monitor. I also tested the screenmode selector in RGB. But there has been some changes to XaAES since then.

Yeah, it's strange. If I changed "267" for "27" and boot on VGA, everything is fine.

[trecool]

I had to manually set the video mode in xaaes.cnf.
After that system boot to desktop. Then I set the screen using your tool and the video.cnf file created, I put back the include line and now works.

In other words, for some strange reason, xaaes didnt choose the default mode when video config file is missing...

I got my CT60 up and running last night, and when installing VanillaMiNT I ran into the same problem as you. It turns out that the CT60 use a TV/RGB boot mode by default, even if I have a VGA monitor connected. This made XaAES crash when opening the VDI workstation. As soon as I changed the bootmode to a VGA mode everything worked.

Ok thanks! No more mystery!
I would never imagine that it was the boot monitor mode.

[joska]

I would never imagine that it was the boot monitor mode.

It also caused XBoot to bomb out when run from the autofolder.