Page 2 of 6

Re: Modified TOS to remove resolutions limitation

Posted: 01 Mar 2020 11:50
by Cyprian
Smonson wrote: 01 Mar 2020 07:01 I've patched TOS 1.4 UK to allow selecting any resolution from the Desktop Preferences.

This is probably only useful with the HDMI mod at this stage, since a monitor cable can only either be connected to the RGB lines or the mono-out pin at a time.

This screencast shows it running under Hatari, but neither Hatari or Steem can display the low-res modes properly when set up to present a high-res monitor to the machine, so the display is bitplane'd. But it seems to be working. Excuse the flashing lights on the right side, apparently it's a problem with my Nvidia drivers.

I have no way to program the ROM image into a real machine yet. Should work fine, though.

tos14uk-res-mod.gif
nice feature,

can you describe what was patched? (VBL and the Desktop)

Re: Modified TOS to remove resolutions limitation

Posted: 01 Mar 2020 12:11
by Smonson
exxos wrote: 01 Mar 2020 11:32 I thought the mono_det pin had to be used as it resets the machine. I don't think its possible to simply change resolution as the VDI has to be restarted. I assume that pin forces TOS to reboot. The only way I thought it could work is to enable high res in the menu, then have it flip a bit in a register to set the mono_det pin to simulate the mono monitor being plugged in. In may be wrong, but that's how I think it works.
Almost entirely right, apart from the "had to". Anytime TOS changes the resolution, the machine reboots at the next vertical blank to enable the new setting. And if mono-detect changes, TOS changes the resolution. It also checks mono-detect at boot. I took both of those checks out (or I think I did - no way to test the former in the emulator).

Mono detect doesn't have any hardware control over the machine rebooting, it's done manually in the code.

The FPGA shifter in the HDMI mod doesn't have a seperate mono-out pin, it uses the same RGB lines when generating mono, so it doesn't need any extra support for generating mono, just the shifter's resolution register.

So now, once the resolution is set in Desktop Preferences, the machine reboots (same as the original low/medium switch), and when it comes back up VDI is initialised to the new resolution as it initialises.
Cyprian wrote: 01 Mar 2020 11:50 nice feature,

can you describe what was patched? (VBL and the Desktop)
Thanks Cyprian. As above, plus added more code to the desktop preferences dialog handler to support setting "high" resolution which normally does nothing. I may have also taken out a check to prohibit changing between colour and mono - but I can't remember if I needed to leave that in at the end. I can check that tomorrow if you like.

Re: Modified TOS to remove resolutions limitation

Posted: 01 Mar 2020 12:34
by Cyprian
would be cool
thanks

Re: Modified TOS to remove resolutions limitation

Posted: 02 Mar 2020 10:31
by Smonson
There's clearly a problem with this modification, but I wasn't able to resolve it tonight in the time I had. Sorry, Cyprian. I'll have to give you a raincheck on the details. I'll let you know when I make some progress.

Re: Modified TOS to remove resolutions limitation

Posted: 02 Mar 2020 10:57
by Cyprian
no hurry Smonson

Re: Modified TOS to remove resolutions limitation

Posted: 02 Mar 2020 13:32
by thorsten.otto
Smonson wrote: 02 Mar 2020 10:31 There's clearly a problem with this modification,
if you just want to prevent a reboot on monochrome monitor change detection, you could change

Code: Select all

[00fc0414] 2b7c 00fc 0030 046e       move.l    #$00FC0030,1134(a5)
to

Code: Select all

[00fc0414] 2b7c 00fc 0652 046e       move.l    #$00FC0652,1134(a5)
Also note that recent versions of EmuTOS also contain a monochrome monitor change detection now (not yet in any official releases, but in snapshot versions).

Re: Modified TOS to remove resolutions limitation

Posted: 03 Mar 2020 10:37
by Smonson
thorsten.otto wrote: 02 Mar 2020 13:32 if you just want to prevent a reboot on monochrome monitor change detection, you could change
I think that would prevent rebooting, but if my reading of the code is right (can't test with hatari) then the shifter mode register and sshiftmod would still be modified.

I skipped the check by changing

Code: Select all

fc06f2:	662e           	bnes 0xfc0722
and
fc0706:	671a           	beqs 0xfc0722
into

Code: Select all

fc06f2:       602e            bras 0xfc0722
and
fc0706:       601a            bras 0xfc0722
That's not the problem I'm investigating now though. I think, as exxos stated, that I'm not getting it to properly reinitialise VDI after Setscreen() when switching to and from the high res mode. It's doing something - but not the right thing. The enemy's my lack of free time to look into it.

Re: Modified TOS to remove resolutions limitation

Posted: 06 Mar 2020 01:03
by Smonson
I'm still tapping away at it, but the weird thing is that as soon as I add support for changing from low res to mode 4 (high) in _FindDevice(), the machine will no longer boot (it goes into an infinite reset loop) into low res mode - it does boot in hi-res. I'm working my way through v_openwk() which calls _FindDevice(), hopefully I'll get a chunk of time over the weekend to get to the bottom of that.

Re: Modified TOS to remove resolutions limitation

Posted: 06 Mar 2020 08:25
by thorsten.otto
If it helps, in https://github.com/emutos/emutos/blob/6 ... 1080-L1181 you will find the C-Code that correponds to the monitor-change detection in TOS.

Re: Modified TOS to remove resolutions limitation

Posted: 06 Mar 2020 09:35
by Smonson
Thanks Thorsten. This rebooting problem only occurs when booting up in low res - it seems unrelated to the monitor-change detection.

If you want to see the problem it's here:

_FindDevice() is called inside v_opnwk() and basically checks that a resolution change is a valid one, and then if it is, it calls Setscreen(-1, -1, x) to switch to it. Originally it allows the following switches from low-res (in a convoluted way):
  • Low to mode 1 (doesn't call Setscreen), returns 1
  • Low to mode 3 - calls Setscreen(-1, -1, 1), returns 2
  • Low to any other mode (doesn't call Setscreen), returns 1
If the 4th option is added to that list, the machine won't boot anymore:
  • Low to mode 4 - calls Setscreen(-1, -1, 2), returns 3
It's also necessary to modify desk_pref() to stop greying out the buttons; the code isn't the same in 3.06, but for 1.04UK you would find three #8s at fd86a0, fd86ae, and fd86ba that just need to be #0s.

The "modes" to go TO are actually VDI handle IDs or something like that (mentioned in comments in desk_pref). The return values are the same as the TOS video modes with 1 added. That code is in ./vdi/allgem.S in your codebase.

Setscreen() itself is simple and appears to handle all three resolutions fine. :shrug: