Dual Titanium

https://groups.google.com/forum/#!topic/comp.sys.acorn.announce/WVeNQUvRLr4
Yeah! Let’s go for dual 1920×1080 :)

What about:
Aemulor?
Sound quality?
SerialDev driver (needed for PsiFS)?
Boot under Linux from RISC OS (with dual head support, of course)?

Is kernel non zero pain?

I’m using the “SerialHAL” blockdriver on mine to access both ports with !CallerID.

Aemulor?

The Cortex-A15 edition of Aemulor can be downloaded thanks to Adrian Lees.

Sound quality?

The audio codec has 24 bit DACs, though RISC OS currently only feeds them with 16 bit data. The table of sampling rates includes the VIDC/CD/DVD rates and divisors therein (20833, 22050, 24000, 27777, 29400, 32000, 41666, 44100, 48000).

SerialDev driver (needed for PsiFS)?

Both ports and their handshaking lines appear in DeviceFS, so the existing blockdriver will latch onto them.

Boot under Linux from RISC OS (with dual head support, of course)?

U-boot startup is from flash at present, so doesn’t coexist with RISC OS, which is in the same boot flash. There’s no technical reason why it can’t be softloaded, but at present it’s one or the other.

Is kernel non zero pain?

Your choice, the ZIP file includes both high and low vectors versions of the OS ROM. Or, you can have your preferred one in boot flash and softload the other one as needed.

The Cortex-A15 edition of Aemulor can be downloaded thanks to Adrian Lees.
Your choice, the ZIP file includes both high and low vectors versions of the OS ROM.

Yes!

The audio codec has 24 bit DACs

Not the best, but good enough.

22050

Excellent, for old SDL titles.

but at present it’s one or the other.

Arg…

Both ports and their handshaking lines appear in DeviceFS, so the existing blockdriver will latch onto them.

I don’t understand. You provide a SerialHal driver that connects to a DeviceFS one, or you provide a DeviceFS driver and use a third party module called SerialHal? I ask this, because I have a DeviceFS driver for another serial interface, but I can’t use it with PsiFS (because it needs a serial blockdriver).

Anyway the only limits for me was correct 22 kHz sound (solved), dual screen (solved), Sata (solved), serial for PsiFS (solved) and dual boot (to be solved, I hope :) ).

Thanks for all the information.

Existing Titanium owners will be able to try out the update on their machines
straight after the show.

Will there be a new ROM soon? Or how do we get to try dual screens? I’m eager to try! :)

Rob described it as ‘Show grade’ a proper release is some weeks if not months away.

We had 2048 × 1440 on both of our monitors:-)

That sounds great! (Although my screens are only 1920×1200 so not much use for that).

But release is still some way off then. I thought the text in the csaa announcement sounded closer than that. Oh well, I’ll wait :)

Existing Titanium owners will be able to try out the update on their machines
straight after the show.

Will there be a new ROM soon? Or how do we get to try dual screens? I’m eager to try! :)

We’re just writing up a technical note on how to use the module so you know how to use it, aiming to have that ready today. You can then enjoy trying out a monster desktop on Titanium!

a proper release is some weeks if not months away

That’s right – RISC OS currently has no concept of dual head displays, and it gets quite annoying quite quickly when it opens windows across the split line. Modifying the OS to handle this nicely is what will take more time, at which point we’ll change the driver in the ROM rather than loading it off disc.

Will the ‘Titanium’ be able to drive a double input monitor?

We’re just writing up a technical note on how to use the module so you know how to use it, aiming to have that ready today. You can then enjoy trying out a monster desktop on Titanium!

Cool!!

Modifying the OS to handle this nicely is what will take more time

How would that work? Introduce the concept of different screens or something? I suppose it also would be quite interesting to support windows halfway across monitors when the two screens have different colour depths? How does Geminus solve these things?

Will the ‘Titanium’ be able to drive a double input monitor?

Are you meaning one monitor two inputs?

If yes then it is supported as ‘show grade’ and we have monitors with HDMI and DVI input. So you could connect up one output from the Titanium to its HDMI input and the other Titanium output to its DVI input. Not very useful, so I suspect you mean something else!

Really nice! I now have two 1920×1200 screens! :)

Pity they’re the wrong way around, but I won’t complain too hard about that :)

I started out by using my own MDF and creating 1920×1200 dual head variants, and tried that. I got “This screen is not suitable for the desktop” or something like that. Didn’t see anything wrong so ended up trying the provided 1024×768 which worked straight away. Then tried my own MDF again, which now worked fine?!

Took a restart, tried again, but again had to run the original first. Not sure what is happening there… Oh well, I was warned it wasn’t production ready:)

First time I tried it I got 15 seconds of freezing every 30 seconds (Mouse still moved but the !Alarm clock and everything else stopped). !Usage didn’t manage to show me which task was taking its time. Alt-Break seemed to indicate MsgServeS, but after I quit Messenger, Alt-Break blamed ShareFS. But it didn’t repeat itself after reboot, so not sure what that was…

Jan: Yes we found we didn’t seem to be able to go into our double headed modes directly 2×1902×1080, 2×2048×1152 or 2×2048×1440 but if we went to the Elesar defined double headed mode we could then select the modes we had defined.

So I’m not the only one then… :) Oh well.

How well do the higher def modes work? I get a bit of flickering (or what I should call it…) when using 2×1920×1200 and larger areas of the screen get updated. This has been a problem with only one screen as well, and is the reason why I use 1920×1200 at 40Hz. It’s worse at higher refresh rates. It was also worse in the RC1 rom (and was mentioned in the release notes of RC2).

I’ve thought about this as something that gets better in later ROMs, but since it gets pretty bad here at 2×1920×1200 at 60Hz, I would expect demoing it with 2×2048×1440 would show off this “feature” pretty obviously. So I wonder if only I have this problem?

Really nice! I now have two 1920×1200 screens! :) Pity they’re the wrong way around, but I won’t complain too hard about that :)

Plugging the cables in the other way round is the recommended solution!

I started out by using my own MDF and creating 1920×1200 dual head variants, and tried that. I got “This screen is not suitable for the desktop” or something like that. Didn’t see anything wrong so ended up trying the provided 1024×768 which worked straight away. Then tried my own MDF again, which now worked fine?!

Most likely the mode you created wasn’t acceptable (eg. > 2048 pixels) to the single head driver and was therefore rejected, then when the new driver is loaded it becomes acceptable. Switching round the *Wimpmode and *RMLoad commands might solve that.

It’s also possible there’s an out-by-factor-2 bug somewhere, such is the nature of prototype drivers.

I would expect demoing it with 2×2048×1440 would show off this “feature” pretty obviously.

IIRC this was at 43Hz.
2×2048×1440x43 < 2×1920×1200x60

At the moment I boot into either Windows or Linux on my laptop. That said I am interested in a computer that dual boots RISC OS and Linux.

Does the paragraph below mean that you can either run RISC OS or Linux on Titanium at start-up or only one of them? Meaning ultimately that you would have to purchase two motherboards, one to run RISC OS and the other one Linux.

“U-boot startup is from flash at present, so doesn’t coexist with RISC OS, which is in the same boot flash. There’s no technical reason why it can’t be softloaded, but at present it’s one or the other.”

I think you’ve focused on the wrong part of the paragraph.

“U-boot startup is from flash at present, so doesn’t coexist with RISC OS, which is in the same boot flash. There’s no technical reason why it can’t be softloaded, but at present it’s one or the other.”

So currently if you wanted to run both Linux and RISC OS you would have to buy two machines. But if there’s no technical reason why Linux can’t be softloaded (or no technical reason why U-boot can’t be modified to provide a dual boot menu, with the RISC OS ROM stored on the SD card) then there’s a good chance that ultimately someone will develop a softload or dual-boot system. It’s just a question of how long you’re willing to wait for that “ultimately” to arrive :-)

I have no idea how high a priority dual-boot is for Elesar (or whether they’d be willing to accept funding to develop such a system), but there’s no reason why someone else can’t step up to the plate and give it a go. There are Linux bootloaders for the RiscPC, Iyonix and Raspberry Pi, all of which were created by community members rather than by the platform owners.

Best would be a Linux loader under RISC OS. So RISC OS could be used as a first level BIOS for Linux only users.

Dual boot would require either dual drives or a partitioning tool that understands ADFS.

No. We can use part of the disc with ext, and let the beginning free for ADFS. That’s the way we make dual partition (FAT+FileCore) partitions for the Pi.

I know it’s technically possible, but doing it by hand risks overlapping the partitions or wasting space. Is there already a tool that does it? (Perhaps reading the ADFS ‘partition’ size and and making an MBR partition table entry that matches)

Could we have a bounty for this. A dual boot titanium becomes a much more attractive option

Is there already a tool that does it?

SystemDisc? :)

Linux bootloader for Titanium that allows booting Linux from RISC OS. Looks like it’s due to be officially released at Wakefield.

http://www.riscository.com/2016/try-on-a-tux-run-linux-on-titanium/