All FreeMiNT builds again available and more!

[lp]

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 )

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

[ThorstenOtto]

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

[TheNameOfTheGame]

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 )

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.

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

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

[lp]

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.

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.

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.

[Kroll]

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 ?

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

[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

[Eero Tamminen]

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]

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.

[Eero Tamminen]

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]

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.