Re: [hatari-devel] SCU/VME register access?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 11/06/2024 à 20:51, Thomas Huth a écrit :
> > Hi
> >
> > using the linux image you sent me, I ran hatari with :
> >
> > hatari  --machine tt --tos tos306fr.img --dsp off --fpu 68882 --mmu on
> > -s 14 --ttram 64 --addr24 off -c lilo.cfg --lilo "debug=nfcon
> > root=/dev/ram ro init=/init" --trace vme
> >
> > then I see (this is a work in progress version with SCU support)
> >
> > scu write sys_int mask ff8e01=0x10 pc=3aa022
> > scu write vme_int mask ff8e0d=0x60 pc=3aa028
> >
> > writing 0x10 at ff8e01 allows vsync interrupt (but not hsync), but then
> > the linux boot shows lots of line "unexpected interrupt from 112". And
> > 112 is 0x70, which is VBL interrupt.
> >
> > so it's strange that linux allows vsync interrupt but then shows some
> > errors about interrupt 112 (and in the source code at
> > https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/atari/ataints.c#n304
> > it says vbl is enabled for the cursor)
>
> Just a blind guess, but is there maybe something wrong with the VBR
> emulation in Hatari?
>
> Linux sets up the table to a different location in RAM:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/kernel/vectors.c#n61

I will have a look, but this is strange. See my notes below :

1) in 
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/atari/ataints.c#n304
sys_int mask is set to 0x10 to allows vsync int, but no handler is set 
for the level 4 interrupt.
On the contrary for falcon, they set :

             vectors[VEC_INT2] = falcon_hblhandler;
             vectors[VEC_INT4] = falcon_hblhandler;

(this basically does just a RTE after disabling HBL int in SR)

2) m68k_irq_startup_irq can change vectors[] and is called 3 times, but 
only with irq nbr 0xf, 0xc and 0xd (FDC, timerD and timerC), not with 
irq nbr 4 (which would install auto_inthandler for this irq nbr)

3) in trap_init at 
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/kernel/vectors.c#n88 
all vectors are set by default to bad_inthandler. and bad_inthandler is 
called when the VBL triggers :

VBL=69 clock=36875019 e_clock_jitter=1
cpu exception 28 currpc 48cbc buspc 48cb8 newpc 2518 fault_e3 0 op_e3 0 
addr_e3 0 SR 2204
bad_inthandler
cpu video_cyc=   331 331@  0 36875035 : 00002518 42a7 
 clr.l -(a7) == $00369f40 [*00048c4e]

4) Nowhere else in the code do I see  that VEC_INT4 is used to set its 
vector (except in Falcon case). Maybe there's a not so explicit case 
that changes vectors[VEC_INT4], but I don't see it

When VBL occurs we see it calls bad_inthandler that was set in 3), and 
not some random handler, so I think VBR is correctly used.

All in all, it seems that the code enable vsync in TT mode but doesn't 
replace bad_inthandler with another valid handler.

I guess this linux version was tested on real TT by their author, or not 
? (comment at top of arch/m68k/atari/ataints.c mentions the most recent 
changes were about TT SCU)

I think that adding a line in atari/ataints.c would set a correct handler

	if (ATARIHW_PRESENT(SCU)) {
		/* init the SCU if present */
		tt_scu.sys_mask = 0x10;		/* enable VBL (for the cursor) and
									 * disable HSYNC interrupts (who
									 * needs them?)  MFP and SCC are
									 * enabled in VME mask
									 */
		tt_scu.vme_mask = 0x60;		/* enable MFP and SCC ints */
+		vectors[VEC_INT4] = falcon_hblhandler;
	} else {


Of course it could be a (stupid) emulation issue that I don't see, but I 
don't know what I'm missing.

Eero, just in case, could you build an updated kernel with the above 
line added for the SCU part in atari/ataints.c line 302 ? So I could 
test with my new SCU code.


Nicolas