All FreeMiNT builds again available and more!

Latest news in the Atari world

Moderators: Mug UK, Silver Surfer, Moderator Team

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2511
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: All FreeMiNT builds again available and more!

Post by lp »

TheNameOfTheGame wrote:Yes, I have the same issues as Kroll. I had to switch to Jinnee as the desktop for MiNT on Hades (but I prefer it anyway :D )

SET_MMU.PRG is causing problems with MiNT, I used the default configuration file you refer to and (the only change I made was to adjust the TT RAM line to fit my machine's memory), but after booting MiNT, it boots all the way through (I see all the boot output - black text on a white background), but then ends with losing the video signal to the monitor and it goes to a black screen.

Under TOS, I can boot to the desktop with SET_MMU and sysinfo shows the memory split as it should be,
Not sure which Nova driver you are using as there are many variants, but the Mach64 driver was notorious for having cache problems. I had to put a tiny app in the auto folder before the Nova driver to disabled the cpu caches. This keeps the screen from going black. Then Thing Desktop was setup to auto start another tiny app that turned the cpu caches back on. Sounds silly but that's what solved it for me.

Just prior to my Hades060 passing away I fixed this inside the Nova driver by disassembling it and recompiling it, thus I could boot my Hades060 at full speed. All this work is now halted and stuck on an IDE drive I can't access. However, I think you can find these small apps in the set_mmu archive: cache_of.prg and cache_on.prg
Last edited by lp on Thu Apr 25, 2019 2:04 pm, edited 1 time in total.
ThorstenOtto
Atari God
Atari God
Posts: 1193
Joined: Sun Aug 03, 2014 5:54 pm

Re: All FreeMiNT builds again available and more!

Post by ThorstenOtto »

TheNameOfTheGame wrote:[
SET_MMU.PRG is causing problems with MiNT
That would be strange. IIRC, MiNT does not touch the MMU tables when PMMU is already in use.
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1433
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: All FreeMiNT builds again available and more!

Post by TheNameOfTheGame »

lp wrote:
TheNameOfTheGame wrote:Yes, I have the same issues as Kroll. I had to switch to Jinnee as the desktop for MiNT on Hades (but I prefer it anyway :D )

SET_MMU.PRG is causing problems with MiNT, I used the default configuration file you refer to and (the only change I made was to adjust the TT RAM line to fit my machine's memory), but after booting MiNT, it boots all the way through (I see all the boot output - black text on a white background), but then ends with losing the video signal to the monitor and it goes to a black screen.

Under TOS, I can boot to the desktop with SET_MMU and sysinfo shows the memory split as it should be,
Not sure which Nova driver you are using as there are many variants, but the Mach64 driver was notorious for having cache problems. I had to put a tiny app in the auto folder before the Nova driver to disabled the cpu caches. This keeps the screen from going black. Then Thing Desktop was setup to auto start another tiny app that turned the cpu caches back on. Sounds silly but that's what solved it for me.

Just prior to my Hades060 passing away I fixed this inside the Nova driver by disassembling it and recompiling it, thus I could boot my Hades060 at full speed. All this work is now halted and stuck on an IDE drive I can't access. However, I think you can find these small apps in the set_mmu archive: cache_of.prg and cache_on.prg
Oy, that's unfortunate about the Hades. But for the IDE drive, you could put it in a IDE-to-USB enclosure (or other methods) and image it with DD and then mount the partitions and copy the files over to another filesystem, then you would have access to all the files again. I do this with my Hades (raw backup image of the drive and partition contents copied over to folders on the desktop drive along with DVD images - multiple redundant backups). Just an idea. You've probably already thought of these things anyway. :lol:
mikro
Hardware Guru
Hardware Guru
Posts: 2218
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: All FreeMiNT builds again available and more!

Post by mikro »

@TheNameOfTheGame, @Kroll - try what Lonny suggests, i.e. putting cache_of.prg before your graphics card driver (just to be sure, don't put cache_on.prg anywhere yet). I'm pretty sure this is what causing you the video issues as SET_MMU.PRG, among other things, enables caches (that would be another way to fix your setup - disable cache in mmusetup.cnf and enable them later on).
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1433
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: All FreeMiNT builds again available and more!

Post by TheNameOfTheGame »

Ok, running cacheoff before the video driver causes a hard fault when booting MiNT:
cacheoff.png
So then tried placing cacheon right before mint but same hard fault.

Disabling cacheoff and cacheon and editing MMUSETUP.CNF to disable caches (removed EDC and EIC from the CACR line) gives a successful boot to the desktop.
You do not have the required permissions to view the files attached to this post.
User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2511
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: All FreeMiNT builds again available and more!

Post by lp »

TheNameOfTheGame wrote:Oy, that's unfortunate about the Hades. But for the IDE drive, you could put it in a IDE-to-USB enclosure (or other methods) and image it with DD and then mount the partitions and copy the files over to another filesystem, then you would have access to all the files again. I do this with my Hades (raw backup image of the drive and partition contents copied over to folders on the desktop drive along with DVD images - multiple redundant backups). Just an idea. You've probably already thought of these things anyway. :lol:
Before the Hades became completely unusable the HD was dumped to my SCSI->PCMCIA drive. Should be accessible from my TT030 with the same SCSI->PCMCIA drive, however atm the TT030 is boxed and zero space to setup any Atari gear. Plus the SCSI->PCMCIA drive is still 900 miles away at my dad's place. :lol:

The bottom line is simple, the cache must be off at the moment the Nova driver is started otherwise the screen will go black. FYI, I didn't use memory protection. Maybe try with memory protection disabled.

Does Idek Tramielski supply a fixed/better version of the Mach64 driver? Mine went down before I was aware of his drivers so I never tested them.
User avatar
Kroll
Atari Super Hero
Atari Super Hero
Posts: 533
Joined: Fri Mar 09, 2012 10:07 am

Re: All FreeMiNT builds again available and more!

Post by Kroll »

TheNameOfTheGame wrote:Ok, running cacheoff before the video driver causes a hard fault when booting MiNT:

So then tried placing cacheon right before mint but same hard fault.

Disabling cacheoff and cacheon and editing MMUSETUP.CNF to disable caches (removed EDC and EIC from the CACR line) gives a successful boot to the desktop.
Unfortunately, despite the fact that I have a very similar hardware setup like TheNameOfTheGames and in practically the same configuration when I run MiNT. I set Memory Protection=ON in Mint Setup the system is crashed during boot. Please loook at a photo.
MiNT_hades.jpg
What do you think about it, what else Can I tru to setting or it may be problerm hardware ?
You do not have the required permissions to view the files attached to this post.
mikro
Hardware Guru
Hardware Guru
Posts: 2218
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: All FreeMiNT builds again available and more!

Post by mikro »

Kroll: hard to say. If you really have the same setup (same mmusetup.cnf, same auto folder, ...) one other thing could be pretty obvious and that is your RAM module isn't very healthy. FreeMiNT is much more sensitive for defective memory so if something is not right, strange memory violations are often the first thing to notice (unfortunately, people then tend to blame FreeMiNT than the hardware but the same story goes with the infamous Windows BSOD).
User avatar
Kroll
Atari Super Hero
Atari Super Hero
Posts: 533
Joined: Fri Mar 09, 2012 10:07 am

Re: All FreeMiNT builds again available and more!

Post by Kroll »

@mikro: You are right. I have just test memory modules using YAART test program. Please find a photo. This confirms that there is a memory problem, I will have to check it carefully. In my Hades I have 6 x 32 MB.
YAART_TEST.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2189
Joined: Sun Jul 31, 2011 1:11 pm

Re: All FreeMiNT builds again available and more!

Post by Eero Tamminen »

ThorstenOtto wrote:That might also be a problem of how the GEMDOS emulation in Hatari works. IIRC it caches the DTA pointer for example...
While Hatari caches DTA data, the pointer to emulated code DTA is on every relevant GEMDOS call refreshed from basepage:

Code: Select all

        /* Refresh pDTA pointer (from the current basepage) */
        DTA_Gemdos = STMemory_ReadLong(STMemory_ReadLong(act_pd) + BASEPAGE_OFFSET_DTA);
...
        pDTA = (DTA *)STMemory_STAddrToPointer(DTA_Gemdos);
But I'm not sure whether the address it uses for basepage is valid for MiNT, as it's based on TOS version:

Code: Select all

        /* Get the address of the p_run variable that points to the actual basepage */
        if (TosVersion == 0x100)
        {
                /* We have to use fix addresses on TOS 1.00 :-( */
                if ((STMemory_ReadWord(TosAddress+28)>>1) == 4)
                        act_pd = 0x873c;    /* Spanish TOS is different from others! */
                else
                        act_pd = 0x602c;
        }
        else
        {
                Uint32 osAddress = STMemory_ReadLong(0x4f2);
                act_pd = STMemory_ReadLong(osAddress + 0x28);
        }
mikro
Hardware Guru
Hardware Guru
Posts: 2218
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: All FreeMiNT builds again available and more!

Post by mikro »

mikro wrote:About MFP.XDD: actually, you can read the current state in https://github.com/freemint/freemint/bl ... /ports.txt -- unknown. ;) I erroneously assumed that serial ports in Hades are Atari compatible but they are not: http://www.medusacomputer.com/thes-hades.html. I have disabled it for Hades builds for now. In practice, you wont see the serial ports in u:/dev.

If you have any technical information about the ports (where they are mapped and what circuit they are using), maybe we can do something about it (for the Milan there is a special UART version).
Actually, I have noticed that SCC.XDD is supposed to be compatible with Hades - Hades ESCC chip is on the same address location as TT SCC so it should work out of the box. So SCC.XDD is copied & enabled to hades machine folder in current build.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2189
Joined: Sun Jul 31, 2011 1:11 pm

Re: All FreeMiNT builds again available and more!

Post by Eero Tamminen »

mikro wrote:
ThorstenOtto wrote:That might also be a problem of how the GEMDOS emulation in Hatari works. IIRC it caches the DTA pointer for example... that might not work very well when using mint, and the current process is switched without Hatari noticing. Generally, using anything from the old TOS in MiNT is only a workaround for functionality that isn't implemented in MiNT, but that does not apply to the FAT filesystem, where there is a new (and hopefully better) implementation.

The best solution would be if Hatari could implement the hostfs interface. That will also give access to long filenames for example.
Damn. In that case it would make sense to provide Hatari disk images for every build rather than having a special Hatari kernel build just for (non-working) GEMDOS emulation.

Eero, what do you think?
DTA caching itself shouldn't be a problem. Atari side DTA structure has a field with an ID identifying it as one Hatari cached, and index to Hatari DTA cache, so process switch isn't a problem. But sysbase "p_run" address must not change after boot, otherwise GEMDOS HD emulation cannot find current process basepage.

FYI: there are two problems with MiNT:
* MiNT changes GEMDOS vector (0x0084) after boot. If Hatari one is re-instated after that, GEMDOS HD emulation should work
* Hatari GEMDOS HD emulation covers only TOS specific GEMDOS calls, so it will work only for applications that do NOT use MiNT specific GEMDOS file system calls

If TOSFS doesn't anymore work, it doesn't make sense to have Hatari specific kernel builds.
ThorstenOtto
Atari God
Atari God
Posts: 1193
Joined: Sun Aug 03, 2014 5:54 pm

Re: All FreeMiNT builds again available and more!

Post by ThorstenOtto »

If TOSFS doesn't anymore work, it doesn't make sense to have Hatari specific kernel builds.
But TOSFS does exactly that: call out to ROMs gemdos functions. If that is not built in, GEMDOS isn't called at all (at least not for filesystem related functions), and Hatari won't see the calls.
Post Reply

Return to “News & Announcements”