
Hopefully it will spur more software usage and software development for Mint.

Moderators: Mug UK, Zorro 2, Moderator Team
BlankVector wrote: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.
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).
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.
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?
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.
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).
Eero Tamminen wrote:Neither EmuTOS nor Hatari supports TT SCC.
Eero Tamminen wrote:I think this is MiNT driver bug, it doesn't handle SCC (non-)existence properly
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.
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.
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!
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.
Code: Select all
M68000 Bus Error reading at address $ffff8c85 PC=$25680.
Code: Select all
WARNING: xconout character has unknown high byte bits: 0x606a 'j'.
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.
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.
Eero Tamminen wrote:Any idea why I get CNF file problems only with TT emulation (= ACSI), not with Falcon (=IDE)?
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...
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.
Code: Select all
pid 3 (AESSYS): block_IO [C]: sleeping in bio_unit_wait [1191, 1024]
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.
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...
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.
mikro wrote:- fscheck.prg is not found
mikro wrote:- xaloader.prg should be in GEM= not INIT=
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
mikro wrote:- some keyboard filenames are too long and unzip.ttp complains about them
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:
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.
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.
trecool wrote:I would never imagine that it was the boot monitor mode.
Users browsing this forum: davemacblack, mikro and 2 guests