[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian/Linux on Atari TT



Hi,

On tiistai 22 tammikuu 2013, Thorsten Glaser wrote:
> Eero Tamminen dixit:
> >I was reading the m68k Debian mailing list archive and noticed
> >your mails about getting Debian/Linux running on TT.
> 
> OK, but you should probably direct this to the mailing list.
> If you want, I can bounce your original mail and this my reply
> to it, then please reply in positive.

That's ok for me, but I'm not myself subscribed to the list.


> I’m mostly the guy who notices it doesn’t work, especially at
> this stage, and for kernel issues. (I did do some bugfixing by
> myself, but not like that.)
> 
> >Have you considered trying it in the Hatari emulator?
> 
> I was only aware of its existence. The documentation doesn’t
> really state clearly whether it has got an MMU or not,

Only the WinUAE CPU core supports MMU, not the default "old" UAE
CPU core.  CPU core can be selected only at build time.


> and I’m *absolutely* *not* compiling *anything* using cmake by myself,

After one has installed Hatari build-deps, building newer
Hatari versions is easy.

There's even shell script wrapper for CMake so that all you
need to do is:
	./configure --enable-winuae-cpu
	make


> but there appears to be a version packaged in Debian… if that’s
> suitable, I could give it a go.

One could start with that, but after the latest release there have been
significant fixes to the MMU code (coming from "Previous" NeXT emulator 
project, which is based on Hatari code).

However, AFAIK it's still missing "correct" handling of the 68030's Special
Status Word (SSW) and AFAIK that's needed for to recover from MMU
exceptions.  However, I'm not sure what "correct" in this context means,
how much is missing in this respect.  (I'll ask for clarification)


> Having a more accurate emulator can only help – but then, with
> only 14 MiB ST-RAM and no TT-RAM, no real work can be done.

Why?

14MB (of ST-RAM) should be plenty of memory for command line usage,
at least if swap works.  Or are there some processes in the bootup
process which would like to *physically* [1] use more?

[1] I assume your config hasn't disabled overcommit.


> Worse, our current problems occur on machines with 4 MiB ST-RAM,
> which do require some amount of TT-RAM to even boot to single
> user.

I was thinking that Hatari could be used e.g. to test and
streamline the installation process.


> >Hatari has also very extensive debugger for finding issues
> >in emulated system:
> >http://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-
> >file/tip/doc/manual.html#The_debugger
> 
> Interesting. But, as I said, I’m not the person who would be
> tracking this down, even if the RAM and other issues could
> be solved.
> 
> Thanks anyway for your interest and offer to help!

It wasn't completely altruistic, Hatari MMU code also
needs more testing.  I.e. this kind of work would most
likely require some co-operation with the developer(s)
looking after Hatari MMU emulation.

(Atari's MiNT uses MMU just for memory protection, not
paging and there aren't many other Atari programs utilizing
the MMU.)


	- Eero


Reply to: