VanillaMiNT has finally been updated

All about the serious stuff.

Moderators: Mug UK, Zorro 2, Moderator Team

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12007
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: VanillaMiNT has finally been updated

Postby wongck » Sun Mar 26, 2017 9:13 am

Great to see more people get on the Mint Bandwagon. :D
Hopefully it will spur more software usage and software development for Mint. :megaphone:
My Stuff: FB/Falcon CT63+CTPCI_ATI_RTL8139 14+512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

joska
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Sun Mar 26, 2017 9:23 am

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 :)
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
trecool
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 127
Joined: Sat Jun 04, 2016 2:49 pm
Location: Greece

Re: VanillaMiNT has finally been updated

Postby trecool » Sun Mar 26, 2017 1:50 pm

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

BlankVector
Captain Atari
Captain Atari
Posts: 409
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: VanillaMiNT has finally been updated

Postby BlankVector » Sun Mar 26, 2017 3:32 pm

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.

joska
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Sun Mar 26, 2017 6:10 pm

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?
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

BlankVector
Captain Atari
Captain Atari
Posts: 409
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: VanillaMiNT has finally been updated

Postby BlankVector » Sun Mar 26, 2017 6:46 pm

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.
Last edited by BlankVector on Sun Mar 26, 2017 10:58 pm, edited 1 time in total.

joska
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Sun Mar 26, 2017 7:03 pm

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.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: VanillaMiNT has finally been updated

Postby Eero Tamminen » Sun Mar 26, 2017 8:03 pm

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
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Sun Mar 26, 2017 8:15 pm

It works with TOS VDI in mono.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

BlankVector
Captain Atari
Captain Atari
Posts: 409
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: VanillaMiNT has finally been updated

Postby BlankVector » Sun Mar 26, 2017 10:22 pm

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.

mikro
Atari God
Atari God
Posts: 1308
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: VanillaMiNT has finally been updated

Postby mikro » Sun Mar 26, 2017 10:40 pm

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

BlankVector
Captain Atari
Captain Atari
Posts: 409
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: VanillaMiNT has finally been updated

Postby BlankVector » Sun Mar 26, 2017 11:11 pm

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.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: VanillaMiNT has finally been updated

Postby Eero Tamminen » Mon Mar 27, 2017 10:35 pm

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

BlankVector
Captain Atari
Captain Atari
Posts: 409
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: VanillaMiNT has finally been updated

Postby BlankVector » Tue Mar 28, 2017 9:24 am

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.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: VanillaMiNT has finally been updated

Postby Eero Tamminen » Tue Mar 28, 2017 9:39 pm

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)?

BlankVector
Captain Atari
Captain Atari
Posts: 409
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: VanillaMiNT has finally been updated

Postby BlankVector » Tue Mar 28, 2017 9:49 pm

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

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: VanillaMiNT has finally been updated

Postby Eero Tamminen » Sun Apr 02, 2017 9:35 pm

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]

User avatar
Gaiyan
Captain Atari
Captain Atari
Posts: 218
Joined: Tue Jun 29, 2004 3:39 pm
Contact:

Re: VanillaMiNT has finally been updated

Postby Gaiyan » Fri Apr 07, 2017 5:04 am

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!
Image

joska
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Fri Apr 07, 2017 6:32 am

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.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

joska
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Fri Apr 07, 2017 6:36 am

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.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1308
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: VanillaMiNT has finally been updated

Postby mikro » Fri Apr 07, 2017 7:45 am

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
You do not have the required permissions to view the files attached to this post.

joska
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Fri Apr 07, 2017 8:26 am

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.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1308
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: VanillaMiNT has finally been updated

Postby mikro » Fri Apr 07, 2017 10:21 am

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.

User avatar
trecool
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 127
Joined: Sat Jun 04, 2016 2:49 pm
Location: Greece

Re: VanillaMiNT has finally been updated

Postby trecool » Fri Apr 07, 2017 5:41 pm

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.

joska
Hardware Guru
Hardware Guru
Posts: 3695
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: VanillaMiNT has finally been updated

Postby joska » Fri Apr 07, 2017 10:10 pm

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.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64


Social Media

     

Return to “Applications”

Who is online

Users browsing this forum: No registered users and 4 guests

cron