ST536 STE EDITION

[dml]

A typical behaviour for an upgraded CPU boot sequence is something like this:

cold boot:
- detect installed RAM types
- test the installed RAM areas
- optionally shadow ROM to RAM
- install MMU pagetables making the RAM & shadowed ROM areas available with the correct cache flags etc.
- mess with the warm-reset vector so all this doesn't need repeated on a warm boot
- MAYBE perform a warm-reset so every 'real' journey to the desktop is exactly the same (i.e. always via a warm boot, even from a cold boot)

warm boot:
- find the FastRAM from state detected/stored somewhere on the cold boot
- put the MMU table registers back (already set up)
- coast onwards to the usual boot sequence

[exxos]

My current build of 206 now runs DOTT ! BUT I've "lost" TTram now. Likely one of the PAK patches turned it on. So need to fix that next.

The current problem is as was before, Hatari seems to ignore TTram with 206 for some reason. So hard to test the fixes without burning a ROM.. every..single.. time...

[Badwolf]

My current build of 206 now runs DOTT ! BUT I've "lost" TTram now. Likely one of the PAK patches turned it on. So need to fix that next.

The current problem is as was before, Hatari seems to ignore TTram with 206 for some reason. So hard to test the fixes without burning a ROM.. every..single.. time...

You don't have '24 bit addressing' turned on, do you? and Stock 2.06 doesn't do any TT-RAM detection, obviously.

I saw you mention grabbing the latest EmuTOS. 1.3 is still the current release although 1.4 is scheduled in the next week or two, I think.

BW

[exxos]

You don't have '24 bit addressing' turned on, do you? and Stock 2.06 doesn't do any TT-RAM detection, obviously.

It seems Hatari turns it on automatically

I saw you mention grabbing the latest EmuTOS. 1.3 is still the current release although 1.4 is scheduled in the next week or two, I think.

Thanks, thought it had moved on a bit since I last did a ROM.

[exxos]

GOT IT!!

*only* 58 PAK patches in the startup file I went though them one by one.. recompiled.. retested.. and with these enabled with my TP_666 patch, DOTT resets! So the fault starts within this routine somewhere..

Ironically someone put "PAK WHY" in there already, but WHY indeed !

Capture.PNG (37.73 KiB) Viewed 95 times

So next I need to go back to my original 206 build and disable that code and see if things still work.. hopefully that will be the only problem..

[Badwolf]

In the bloody mono check routine!

This is suspicious. Mono check getting triggered in EmuTOS -- an unrelated codebase. Mono check getting patched here for an 030 accelerator. Wherefore?

BW

[exxos]

In the bloody mono check routine!

This is suspicious. Mono check getting triggered in EmuTOS -- an unrelated codebase. Mono check getting patched here for an 030 accelerator. Wherefore?

[exxos]

@Badwolf good spot though! My brain only registered "blah blah MFP blah blah"

I copied my original 206 back over and patched that one thing.. DOTT now runs! So 100% that bit of code caused the resetting issues with DOTT with my build of TOS.

For some reason that "patch" was done in the PAK patches

Capture.PNG (398.77 KiB) Viewed 80 times

Next to burn a ROM and see if I get TTram back now..

[exxos]

ROM burned, its not resetting, but the screen just remains black

Rebooted and now running.. still possible something is unstable on the booster though... but this is a HUGE step forward at least!

IMG_3358.JPG (178.6 KiB) Viewed 70 times

IMG_3359.JPG (249.4 KiB) Viewed 70 times

[exxos]

Grok explains

But as it mentions checking monodetect twice, maybe its trying to debounce the signal.. Maybe stems from previous attempts at fixing the mono detect issue which was replaced by the F-series chip on later motherboard revisions.. But even so, a debounce would make sense as a fix.

But still , It doesn't make much sense why the registers seems to get cleaned and ignored with PAK ?!

All this needs someone with more than 2 functioning brain cells to figure out..


Analysis of 68k Atari ST TOS Monochrome Detection Snippet and TP_666 Reset Issue

The provided 68k Atari ST TOS code snippet is a routine for detecting a monochrome monitor by checking the MFP (Multi-Function Peripheral) chip's General Purpose I/O Port (GPIP) and the sound matrix control register (

Code: Select all

sndmactl

). The issue arises when the

Code: Select all

TP_666

flag is set to

Code: Select all

1

, causing resets in a game or system. Below is an analysis of the code and why

Code: Select all

TP_666 = 1

may lead to resets.

Code: Select all

moncheck:
#if TP_666 /* PAK ?why? */
    move.b    #0,d0
#else
    move.b    ((sndmactl)+1).w,d0
#endif
    move.b    (MFP_GPIP).w,d1
    btst      #7,d1
    sne       d1
    move.b    (MFP_GPIP).w,d2
    btst      #7,d2
    sne       d2
    cmp.b     d1,d2
    bne.s     moncheck
#if TP_666 /* PAK ?why? */
    move.b    #0,d0
#else
    cmp.b     ((sndmactl)+1).w,d0
#endif
    bne.s     moncheck
    move.w    (a7)+,sr
    btst      #0,d0
    beq.s     nomoncheck
    not.b     d1
nomoncheck:

Code Breakdown

1. Initial Check and Conditional Code:

Code: Select all

   #if TP_666
       move.b    #0,d0
   #else
       move.b    ((sndmactl)+1).w,d0
   #endif
   

- When

Code: Select all

TP_666 = 1

,

Code: Select all

d0

is set to

Code: Select all

0

.
- Otherwise, it reads the second byte of

Code: Select all

sndmactl

into

Code: Select all

d0

, which may reflect monitor or sound chip settings.

2. Monochrome Detection Loop:

Code: Select all

   move.b    (MFP_GPIP).w,d1
   btst      #7,d1
   sne       d1
   move.b    (MFP_GPIP).w,d2
   btst      #7,d2
   sne       d2
   cmp.b     d1,d2
   bne.s     moncheck
   

- Reads the MFP’s GPIP bit 7 (monochrome detect) into

Code: Select all

d1

and

Code: Select all

d2

. The

Code: Select all

sne

instruction sets

Code: Select all

0xFF

(monochrome) or

Code: Select all

0x00

(color).
- Loops back to

Code: Select all

moncheck

if readings are inconsistent, ensuring a stable signal.

3. Second Conditional Check:

Code: Select all

   #if TP_666
       move.b    #0,d0
   #else
       cmp.b     ((sndmactl)+1).w,d0
   #endif
   bne.s     moncheck
   

- If

Code: Select all

TP_666 = 1

,

Code: Select all

d0

is set to

Code: Select all

0

, skipping the

Code: Select all

sndmactl

comparison.
- Otherwise, it checks if

Code: Select all

sndmactl+1

matches

Code: Select all

d0

, looping back if not.

4. Final Steps:

Code: Select all

   move.w    (a7)+,sr
   btst      #0,d0
   beq.s     nomoncheck
   not.b     d1
nomoncheck:
   

- Restores the status register (

Code: Select all

sr

), indicating an interrupt or privileged mode.
- If bit 0 of

Code: Select all

d0

is set, inverts

Code: Select all

d1

(monitor type). If

Code: Select all

TP_666 = 1

,

Code: Select all

d0 = 0

, so

Code: Select all

d1

is never inverted.

Why TP_666 = 1 Causes Resets

When

Code: Select all

TP_666 = 1

, the code forces

Code: Select all

d0 = 0

, bypassing

Code: Select all

sndmactl

checks. This can cause issues:

1. Bypassing Hardware Checks:
- Skipping

Code: Select all

sndmactl

checks may allow incorrect monitor detection, leading to incompatible video mode settings (e.g., color mode on a monochrome monitor), which can crash or reset the system.

2. Impact on d0 and Logic:
- With

Code: Select all

d0 = 0

, the

Code: Select all

btst #0,d0

check always skips inverting

Code: Select all

d1

. If the game expects inversion for correct monitor detection, this could lead to wrong video mode initialization.

3. Potential Infinite Loop:
- The

Code: Select all

bne.s moncheck

loop ensures stable GPIP readings. Bypassing

Code: Select all

sndmactl

checks might allow premature exit with incorrect data, causing downstream issues.

4. Game-Specific Assumptions:
- The

Code: Select all

TP_666

flag (noted as "PAK ?why?") seems like a debug hack. It may break game assumptions about monitor type, leading to crashes.

5. System Reset Triggers:
- Incorrect video mode settings or invalid hardware accesses (e.g., to the Shifter or sound chip) can trigger resets on the Atari ST, especially in interrupt contexts.

Debugging Suggestions

- Trace Video Initialization: Check how

Code: Select all

d1

is used to set video modes. Look for conflicts with the Shifter chip.
- Monitor Hardware Accesses: Inspect code accessing video/sound registers post-routine.
- Test Monitors: Try with monochrome and color monitors, toggling

Code: Select all

TP_666

.
- Check sndmactl: Verify its role in your ST model for monitor or sound settings.
- Patch TP_666: Set

Code: Select all

TP_666 = 0

to restore normal checks.
b]Emulator Debugging[/b]: Use Hatari to step through code, monitoring

Code: Select all

d0

,

Code: Select all

d1

,

Code: Select all

d2

, and video registers.

Conclusion

The

Code: Select all

TP_666 = 1

setting likely causes resets by bypassing

Code: Select all

sndmactl

checks, leading to incorrect monitor detection and video mode mismatches. This can crash the game or system. Debugging with an emulator or testing monitor setups can help. If you have more code (e.g., video initialization), I can dig deeper!