MonitorType and RISC OS 3

chat about arc/risc pc gaming & RISC OS software here (NOT the core OS!)Related forum: adventures


Post Reply
hubersn
Posts: 85
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

MonitorType and RISC OS 3

Post by hubersn » Thu Jul 19, 2018 7:31 pm

Imagine the following: you have a virtual Archimedes system with RISC OS 3.10 or 3.11. CMOS writing is not supported. It starts automatically with MonitorType 4 and works fine with a VGA screen. Now you want to connect a real 15kHz screen or a true multiscan that can handle both VGA and 15 kHz to get rid of letterboxing.

How can you change the MonitorType without rebooting? Holding down keys on the numeric keypad during reboot also does not work.

Before you ask, this is the MIST Archie core situation as far as I understand it at the moment.

So what are the options to switch to a 15kHz mode? Things I could possibly imagine:
  • use a module to softload PAL/15kHz timing modes (how does RISC OS handle the letterboxing in VGA/SVGA monitortype? Is it changing modes on-the-fly?)
  • somehow force RISC OS into a different monitortype at runtime to switch to 15kHz on next mode change (or is the screen mode data only initialized once at startup?)
  • somehow change the RISC OS ROM image to provide a different monitortype on startup (how does RISC OS decide?)
If someone could shed some light on the RISC OS monitor type and screen mode situation...

Thanks in advance
hubersn

Phlamethrower
Posts: 72
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: MonitorType and RISC OS 3

Post by Phlamethrower » Thu Jul 19, 2018 8:18 pm

How can you change the MonitorType without rebooting?
*Configure MonitorType changes both the CMOS setting and the live value that's used by the OS. The next mode change will use the mode definitions for the new monitor type.
how does RISC OS handle the letterboxing in VGA/SVGA monitortype? Is it changing modes on-the-fly?
Yes.
somehow change the RISC OS ROM image to provide a different monitortype on startup (how does RISC OS decide?)
If you use *Configure MonitorType Auto then the OS will probe the 'ID lines' to try and determine what monitor type to use (see the PRMs, or the ROOL wiki). So if the startup CMOS could be changed to use the Auto type then possibly some way could be added to the MIST core to allow the values of the ID lines to be overridden by the user (or it could sense the real values from the VGA connector). But if you're allowing the user to pass in config data then it would probably more worthwhile to allow the full CMOS contents to be provided.

hubersn
Posts: 85
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: MonitorType and RISC OS 3

Post by hubersn » Thu Jul 19, 2018 8:36 pm

Phlamethrower wrote:
Thu Jul 19, 2018 8:18 pm
How can you change the MonitorType without rebooting?
*Configure MonitorType changes both the CMOS setting and the live value that's used by the OS. The next mode change will use the mode definitions for the new monitor type.
Oops - are you absolutely sure? I tried that (using both *configure and !Configure to switch to Multiscan monitortype (1)), and then doing a WimpMode 12 ended up letterboxed.

I will re-try on real hardware ASAP so I can rule out strange interactions between MIST, the core and RISC OS (I am not at all sure how the Archie core actually handles the whole I2C CMOS stuff).

Thanks
hubersn

Phlamethrower
Posts: 72
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: MonitorType and RISC OS 3

Post by Phlamethrower » Thu Jul 19, 2018 8:47 pm

hubersn wrote:
Thu Jul 19, 2018 8:36 pm
Phlamethrower wrote:
Thu Jul 19, 2018 8:18 pm
How can you change the MonitorType without rebooting?
*Configure MonitorType changes both the CMOS setting and the live value that's used by the OS. The next mode change will use the mode definitions for the new monitor type.
Oops - are you absolutely sure? I tried that (using both *configure and !Configure to switch to Multiscan monitortype (1)), and then doing a WimpMode 12 ended up letterboxed.
I think so.

Code: Select all

*BASIC
>*Configure MonitorType 0
>MODE 18
>PRINT MODE
    0
>*Configure MonitorType 1
>MODE 18
>PRINT MODE
    18
Mode 18 isn't available for monitor type 0, so the OS falls back to mode 0.

Admittedly this is testing under ArcEm rather than on real hardware, but I'm fairly certain that whenever you change mode all the VIDC registers get reprogrammed using the settings for the selected mode + monitor type.

steve3000
Posts: 1874
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: MonitorType and RISC OS 3

Post by steve3000 » Thu Jul 19, 2018 10:56 pm

The above (*configure changing the 'live' screen mode set) is real hardware behaviour, I used it frequently in the past when developing LCDGameModes.

hubersn
Posts: 85
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: MonitorType and RISC OS 3

Post by hubersn » Fri Jul 20, 2018 10:11 am

OK, thanks a lot guys, when THE two experts on that topic agree, I am inclined to take it as fact :D

I will hopefully get this to work with the MIST, too!

hubersn

hubersn
Posts: 85
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: MonitorType and RISC OS 3

Post by hubersn » Fri Jul 20, 2018 10:20 am

Phlamethrower wrote:
Thu Jul 19, 2018 8:18 pm
somehow change the RISC OS ROM image to provide a different monitortype on startup (how does RISC OS decide?)
If you use *Configure MonitorType Auto then the OS will probe the 'ID lines' to try and determine what monitor type to use (see the PRMs, or the ROOL wiki). So if the startup CMOS could be changed to use the Auto type then possibly some way could be added to the MIST core to allow the values of the ID lines to be overridden by the user (or it could sense the real values from the VGA connector). But if you're allowing the user to pass in config data then it would probably more worthwhile to allow the full CMOS contents to be provided.
I understand how I could get MonitorType Auto to possibly work better with the MIST (on the other hand, MIST has a general setting for "scandoubling enabled", so it would probably be better to then use Type 4 if scandoubler is enabled or Type 1 if scandoubler is disabled). Whenever I get the time to dive into that FPGA development stuff, I will have a go...(probably never, but you never know).

What I still don't understand in detail is RISC OS' behaviour wrt to "default" monitortype seen at startup. I don't know how CMOS is implemented in the MIST core - or if the whole IIC stuff is implemented at all. All I know is that it starts up with MonitorType 4 with no way to change it. I always thought that, after a full CMOS reset (who decides which values are written to CMOS on such a reset?), MonitorType 0 is active.

What does RISC OS 3.1 do if it does not detect the RTC/CMOS chip on the IIC bus?

Thanks again
hubersn

Phlamethrower
Posts: 72
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: MonitorType and RISC OS 3

Post by Phlamethrower » Fri Jul 20, 2018 12:45 pm

hubersn wrote:
Fri Jul 20, 2018 10:20 am
What does RISC OS 3.1 do if it does not detect the RTC/CMOS chip on the IIC bus?
App note 255 suggests that it should refuse to boot with a POST error flashed out on the floppy LED. So, there's a good chance that the MIST is providing some form of RTC+CMOS emulation - but perhaps not one that provides persistent storage.

I'm not sure what the behaviour is if the CMOS chip is there but the checksum is invalid. On modern machines I'm fairly certain it resets the CMOS (or some of it, at least) automatically. retro-kit suggest that an invalid checksum should cause a POST failure, but that's not listed in app note 255 (maybe it was replaced with the "CMOS/RTC read error" status).

In any case, the default CMOS settings are dictated by the kernel. On RISC OS 3.5+ it defaults to Auto monitor type. I'm fairly certain older OS versions will default to that as well - otherwise the problem with EDID-supporting monitors confusing the auto-detection in Archimedes machines wouldn't have been so widespread (although I can't find many references to this problem on the internet - maybe it was just the short-lived DDC1 standard that caused most of the problems?)
Last edited by Phlamethrower on Fri Jul 20, 2018 12:45 pm, edited 1 time in total.

hubersn
Posts: 85
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: MonitorType and RISC OS 3

Post by hubersn » Fri Jul 20, 2018 12:51 pm

Phlamethrower wrote:
Fri Jul 20, 2018 12:45 pm
In any case, the default CMOS settings are dictated by the kernel. On RISC OS 3.5+ it defaults to Auto monitor type. I'm fairly certain older OS versions will default to that as well - otherwise the problem with EDID-supporting monitors confusing the auto-detection in Archimedes machines wouldn't have been so widespread (although I can't find many references to this problem on the internet - maybe it was just the short-lived DDC1 standard that caused most of the problems?)
Was there ever auto detection on Archimedes (A3xx, A4xx, A3000) machines? Wasn't that only added in the later machines with the "native" 15pin VGA connector instead of the old 9pin RGB? In 9pin world, I think there are no ID pins specified.

Maybe RO3.1 behaves differently on those different machines - after all, it needs to somehow also detect if it is the old or the new serial/parallel/floppy world etc.

Thanks so far
hubersn

Phlamethrower
Posts: 72
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: MonitorType and RISC OS 3

Post by Phlamethrower » Fri Jul 20, 2018 1:04 pm

hubersn wrote:
Fri Jul 20, 2018 12:51 pm
Was there ever auto detection on Archimedes (A3xx, A4xx, A3000) machines? Wasn't that only added in the later machines with the "native" 15pin VGA connector instead of the old 9pin RGB? In 9pin world, I think there are no ID pins specified.
Very true, it's only some of the machines which supported it.

The PRMs say the following (wrt Service_MonitorLeadTranslation):
This service call is not issued by RISC OS 2. Furthermore, older machines such as the A300 and A400 series, and the A3000, cannot detect the sense of the monitor lead IDs.
So whether it'll work or not will probably depend upon whether the MIST is emulating a machine with a 9-pin video connector or one with a proper VGA connector (and whether the emulated VGA goes straight to the VGA connector or whether there's something fancy going on like the built-in scan doubler)

retro-kit has a handy Acorn document which goes into detail on the different connectors that were used on (most of) the different Archimedes machines, and to what extent monitor detection was supported:

https://www.retro-kit.co.uk/user/custom ... eoSpec.pdf
Last edited by Phlamethrower on Fri Jul 20, 2018 1:05 pm, edited 1 time in total.

User avatar
hoglet
Posts: 7361
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MonitorType and RISC OS 3

Post by hoglet » Fri Jul 20, 2018 1:28 pm

It looks to me like the Archie core in MIST is implementing the RTC/CMOS chip as a RAM block:
https://github.com/mist-devel/mist-boar ... nterface.v

This is initialized on power up with values defined in a file called cmos.mif
https://github.com/mist-devel/mist-boar ... e/cmos.mif

The cmos.mif file is processed at the time the FPGA Core is compiled, and the data ends up in the FPGA bitstream.

So you could change the default monitor type value, and rebuild the core.

I would expect *configure to work and the new values be visible with *status. They just wouldn't survive a power cycle.

Dave
Last edited by hoglet on Fri Jul 20, 2018 1:29 pm, edited 1 time in total.

hubersn
Posts: 85
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: MonitorType and RISC OS 3

Post by hubersn » Fri Jul 20, 2018 1:44 pm

Phlamethrower wrote:
Fri Jul 20, 2018 1:04 pm
So whether it'll work or not will probably depend upon whether the MIST is emulating a machine with a 9-pin video connector or one with a proper VGA connector (and whether the emulated VGA goes straight to the VGA connector or whether there's something fancy going on like the built-in scan doubler)
Docs say it implements an A3000 with an additional A3010-style Joystick interface.
retro-kit has a handy Acorn document which goes into detail on the different connectors that were used on (most of) the different Archimedes machines, and to what extent monitor detection was supported:

https://www.retro-kit.co.uk/user/custom ... eoSpec.pdf
Very nice! Never saw that before. Saved and archived :D

Thanks again
hubersn

hubersn
Posts: 85
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: MonitorType and RISC OS 3

Post by hubersn » Fri Jul 20, 2018 2:49 pm

hoglet wrote:
Fri Jul 20, 2018 1:28 pm
It looks to me like the Archie core in MIST is implementing the RTC/CMOS chip as a RAM block:
https://github.com/mist-devel/mist-boar ... nterface.v

This is initialized on power up with values defined in a file called cmos.mif
https://github.com/mist-devel/mist-boar ... e/cmos.mif

The cmos.mif file is processed at the time the FPGA Core is compiled, and the data ends up in the FPGA bitstream.
Thanks a lot for that pointer, I now understand things much better.

Have fun
hubersn

Post Reply