|[hatari-devel] Re: [hatari-users] NetBSD on Hatari|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Are you subscribed to hatari-devel? I think this would
more appropriate there.
On maanantai 23 maaliskuu 2015, Emmanuel Kasper wrote:
> Le 22/03/2015 20:34, Eero Tamminen a écrit :
> > On lauantai 21 maaliskuu 2015, Emmanuel Kasper wrote:
> >> Since there is now MMU Emulation, does it mean something like NetBSD
> >> and Linux Atari ports could theoretically work ?
> > Yes. Hatari Mercurial version uses latest WinUAE CPU core
> > and Amiga NetBSD works with WinUAE, so MMU emulation should
> > be good enough for Atari NetBSD too.
> >> Quite curious to see if a NetBSD kernel for Falcon would boot.
> > If you have time to test that, please tell how it went! :-)
> Just had a look at that this t:
> the kernel loader loadbsd.ttp can load a kernel from a floppy but
> exec'ing it hangs the machine:
> Bus error lput at 00bbc2f4
> M68000 Bus Error writing at address $bbc2f4 PC=$1259f6.
> Exception 2 (1259f6) at 1259f6 -> 21ca!
> PTESTW 08,00000000,#7 PC=00002258
> PMOVE MMUSR,00000000 PC=0000225C
I tried latest Hatari from Mercurial.
NetBSD doesn't work (resets) with TT emulation, but starts booting with
Hatari outputs with Falcon:
MMU030 fake prefetched F02B
M68000 Bus Error reading at address $fffa81 PC=$dcd2c.
MMU030 fake prefetched 2079
68030 MMU enabled. Page size = 8192
With TT emulation it additionally outputs:
M68000 Bus Error reading at address $ff8c81 PC=$bea8c.
MMU030 fake prefetched 41FA
CPU reset PC=e00054 (ROM memory)..
Using kernel specifically built for TT, doesn't reset the machine, but it
freezes early doing this:
$001b4c0e : move.b $2b(a0),d0
$001b4c12 : blt.s $1b4c44
$001b4c14 : clr.l d1
$001b4c16 : move.b d0,d1
$001b4c18 : btst #0,d1
$001b4c1c : bne.s $1b4c34
$001b4c34 : moveq #$70,d0
$001b4c36 : and.l d0,d1
$001b4c38 : beq.s $1b4c0e
Kernel fails to vm_fault() when starts looking into SCSI bus unless there's
something attached to IDE. With IDE master, it gets stuck right after that
to "scsibus0: waiting 2 seconds for devices to settle..."
With both IDE master & slave attached, it outputs some disk info after that
before gets stuck, apparently in same way.
Same thing with 5.2.3 and 6.1.5 (= latest release) kernels. Older 3.1.1 and
4.0.1 kernels work even worse.
Kernels needs MMU enabled and 16-color mode, otherwise they fail earlier at
Whether loadbsd.ttp is run from floppy image or GEMDOS HD doesn't matter,
latter is just faster, especially if kernel image is uncompressed.
With EmuTOS, NetBSD screen size is nicer than with TOS4.
To test, do:
$ gunzip netbsd-SMALL030.gz
$ atari-hd-image 32 disk1.img NetBSD
$ hatari -s 14 --machine falcon --dsp none --mmu on --tos etos512k.img --
ide-master disk1.img .
Then just start "loadbsd.ttp" and give netbsd kernel image name as
parameter. With TOS4 you can just drag right kernel to TTP.
> See that screenshot on imgur.
> (don't be fooled by the first kernel netbsd.gz was loaded OK, the loader
> was not exec'ing the kernel that time)
> That was a funny try anyway !
> Docs used:
> falcon-etc/ for the general procedure, and
> for the loadbsd command options