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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 13/06/2024 à 22:47, Nicolas Pomarède a écrit :
> I need to finish some cleanup in the new SCU code and I will commit it 
> soon to main tree.

Hi

SCU support was committed to main source tree.
All registers in $FF8E01 - $FF8E0F are supported and as discussed it 
should help Linux / System V to work in TT mode.

I also tested in MegaSTE mode some games / demos that are known to work 
in STE, to ensure interrupt are correctly working now that they go 
through the SCU. No problem seen so far.

some notes :

- routing interrupt to SCU itself doesn't use much host cpu for 
emulation, so SCU will always be enabled for MegaSTE and TT. As such, I 
removed the "--vme" option that could be "none" or "dummy". Variable 
ConfigureParams.System.nVMEType was also removed

- so far Hatari doesn't emulate the VME bus, so bits in vme mask are not 
used at the moment (except for bits 5 and 6 which are common to the main 
board to mask SCC and MFP interruputs)

- similarly bit 0 in $FF8E07 has no effect at the moment (it should 
trigger a level 3 interrupt on the VME bus)

- as described in "Atari TT030 Hardware reference Manual" the registers
$FF8E01 - $FF8E0F are related to the SCU chip and not really to VME 
itself. To ease reading / maintainability the following were changed :

  - traces for SCU should now use "--trace scu", the "vme" trace level 
was removed (it could be added back if we ever add real support for VME bus)
  - source file was renamed from vme.c to scu_vme.c

- some cleanups were also made in ioMem.c to use common functions to set 
read/write handlers for IO registers.


As we saw the Linux m68k kernel has a bug due to wrong SCU settings.

While waiting for a fix upstream, people who want to boot Linux m68k 
anyway should uncomment the line "SCU.SysIntMask = 0;" in 
"SCU_SysIntMask_WriteByte()".
But this should be done only to use Linux, else system won't boot with 
TOS / EmuTOS :)


Nicolas