Page 2 of 5

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 9:13 am
by wongck
Great to see more people get on the Mint Bandwagon. :D
Hopefully it will spur more software usage and software development for Mint. :megaphone:

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 9:23 am
by joska
BlankVector wrote:Wow! I just tried the 040 version on WinUAE + EmuTOS, it worked out of the box :cheers:
Of course, only monochrome ST-High is supported, as usual.


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

BlankVector wrote: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.

BlankVector wrote: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 :)

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 1:50 pm
by trecool
joska wrote:
trecool wrote: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...

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 3:32 pm
by BlankVector
joska wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 6:10 pm
by joska
BlankVector wrote: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?

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 6:46 pm
by 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.

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 7:03 pm
by 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.

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 8:03 pm
by 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?

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 8:15 pm
by joska
It works with TOS VDI in mono.

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 10:22 pm
by BlankVector
Eero Tamminen wrote:Neither EmuTOS nor Hatari supports TT SCC.

EmuTOS supports it.

Eero Tamminen wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 10:40 pm
by mikro
BlankVector wrote:
joska wrote: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.

BlankVector wrote: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! :)

Re: VanillaMiNT has finally been updated

Posted: Sun Mar 26, 2017 11:11 pm
by BlankVector
mikro wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Mon Mar 27, 2017 10:35 pm
by Eero Tamminen
BlankVector wrote:
Eero Tamminen wrote:Neither EmuTOS nor Hatari supports TT SCC.

EmuTOS supports it.

Eero Tamminen wrote: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'.

Re: VanillaMiNT has finally been updated

Posted: Tue Mar 28, 2017 9:24 am
by BlankVector
Eero Tamminen wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Tue Mar 28, 2017 9:39 pm
by Eero Tamminen
BlankVector wrote: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)?

Re: VanillaMiNT has finally been updated

Posted: Tue Mar 28, 2017 9:49 pm
by BlankVector
Eero Tamminen wrote: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...

Re: VanillaMiNT has finally been updated

Posted: Sun Apr 02, 2017 9:35 pm
by Eero Tamminen
BlankVector wrote:
Eero Tamminen wrote: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.


Eero Tamminen wrote:
BlankVector wrote:
Eero Tamminen wrote: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]

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 5:04 am
by 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!

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 6:32 am
by joska
BlankVector wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 6:36 am
by joska
trecool wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 7:45 am
by 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

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 8:26 am
by joska
mikro wrote: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.

mikro wrote:- 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.

mikro wrote:- 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.

mikro wrote:- 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.

mikro wrote:- 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.

mikro wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 10:21 am
by mikro
joska wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 5:41 pm
by trecool
joska wrote:
trecool wrote: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.

Re: VanillaMiNT has finally been updated

Posted: Fri Apr 07, 2017 10:10 pm
by joska
trecool wrote:I would never imagine that it was the boot monitor mode.


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