Some observations.

[therealfumbles]

Hi. Just pointing out a few issues I've noticed so far in case there might be a chance of getting them fixed.

1. Only EFS formatted CDROMs seem to work. ISO9660 do not (they do in MAME).

2. The display is offset. This is a MAME issue too so perhaps it's been inherited from there. It's ok during boot but when the display re-inits as the login window appears, it gets shifted two pixels to the right.

With MAME, a screendump from the emulator is 1288x1024 and can be cropped to display correctly. However with IRIS the 2 pixels from the right of the screen are lost (using scrsave internally or xwd externally).

3. hinv reports the CPU at 80MHz. Occasionally I've seen 66MHz too. But never 100MHz. Possible bug?

[techomancer]

1. the emulator does not care about cdrom image format is is just bunch of blocks no matter what the fs is. are you sure irix you are using supports iso fs format? iris does not support playing audio from cd.
2. it is not, IRIS snaps to 1024 or 1280 pixels wide framebuffer depending on VC2 timing program. it displays all 1024 or 1280 pixels. mame displays more because vc2 timings are actually slightly larger but there is nothing rendered in memory (it is all scissored) beyond 1024/1280. hence mame displays garbage on the right very often.
3. there is no bug. ide, prom hinv and irix hinv have different methods of determining cpu speed which involve a timing loop and 8254 PIT timer or RTC. they will display whatever they decide is measured cpu speed which depends on many factors, including your actual host cpu clock at the time measurement is taken. irix tends to snap to "known" CPU clocks/bus speeds and then use that for programming IP7 compare register. prom and ide are more open minded about what the cpu clock is. initial versions of iris on my threadripper would show 16MHz in prom.
   mame pretends the system runs at 100mhz and timers are not showing real time. start xclock in mame ;-)
   the cpu clock in hinv does not matter much.
   iris timers, pit8254 and ip7 timer run at realtime. the system will have correct time (unless it slows down a lot under huge bus load like in my fillrate test, but i am going to figure it out). the actual cpu speed in iris fluctuates and depends on multiple factors (host cpu clock/boost, host and emulated cache use and decoded instruction reuse, io use that hits locks and such). irix is a multiuser system that is interrupt driven and actual cpu speed does not have to be precisely emulated because it varies somewhat on a real system as well, especially if the system hits the bus a lot or on cache misses.

[therealfumbles]

Thanks for getting back.

I wasn't sure if the reported clock speed might be a bug or just more accurate reporting. Seems it's the latter. Good to know!

For the other two:

1. ISO9660 discs mount and work correctly in MAME. For IRIS I'm using the same install of IRIX 6.5.22, just converted from chd. The CDROM icon on the desktop shows a disc is inserted but it can't identify the type.

2. The display does shift 2 pixels after the initial boot. From power on up to the login screen it is correct (MAME has 8 pixels of garbage on the right). When the display reloads at the login screen it shifts 2 pixels to the right (MAME has 2px of garbage on the left and 6px on the right). It's clearly visible in a screen shot, even those taken inside IRIX. Or just look closely at the bottom left of the screen. You'll notice the left edge of the desktop doesn't align with the emulator status bar at the bottom.

Here's the bottom left when the system is starting up:

And at the login screen:

(I've resized both images 3x)

With MAME it's a minor inconvenience as I can just crop the garbage away. But with IRIS the shift means the two pixels to the right of the desktop are lost.

[techomancer]

yes, but that is how rendering is set up on irix desktop, there is a black vertical strip in memory there. i have noticed it too.
i will double check the scissor implementation but i think this is how it should be rendered in memory. i dont think this shows up like that in stuff like fullscreen screensavers, but i will check.

the cdrom thing is weird. iris presents cdrom as 512 byte block removable media (cdroms are technically 2048 bytes but for irix we need 512b jumper on all of them ;-) . installing irix 6.5 and 5.3 from cds works just fine. there is no different behavior for iso vs efs cds as far as the hw is concerned. its all the same type of block device. have you tried forcing fs type when mounting manually? maybe irix expects some specific data from cdrom to be able to automount iso fs? i will investigate but i have no idea why it would be different.

[techomancer]

re 2 pixels (scsissors are 4096 pixels biased, but you can see here the smask1x during rendering is 1002 = so starting at pixel 2. and to pixel 1281. so it is definitely by design. unless this gets somehow compensated by vc2 timings or in DID settings this seems like it should be 2 pixels shifted?
CLIPMODE : 00001e03 (ensmask=00011 cidmatch=1111)
SMASK0X : 05600d5f SMASK0Y : 05600d5f
SMASK1X : 10021501 SMASK1Y : 100013ff
SMASK2X : 00000000 SMASK2Y : 00000000
SMASK3X : 00000000 SMASK3Y : 00000000
SMASK4X : 00000000 SMASK4Y : 00000000

[techomancer]

well fwiw, mame also has 2 blank pixels on the left.

i have dumped and decoded the vc2 timing program and nothing obvious pops up.
i will try just hardcoding 2px offset for videomemory+did fetch and see how it looks.

[techomancer]

well, it looks like some fixes to DID decode to not clip beyond screenwidth, and shifting the display by 2px does the job. it looks better both in X11 and prom. the loading screen in between has 2px black strip on the right though ;(
5251b24

[therealfumbles]

Thanks for digging into this. I don't know the innards as well as you do, I just work with what I can see.

Presumably this is why MAME's screenshots are 1288px wide. They include the garbage so as not to lose any of the screen data due to the display shifting.

Looking at some monitor output...

Rex3: Resolution changed to 1280x1024 cursor_x_adjust=7
BT445: Sync-on-Green (IOG) DISABLED
BT445: Sync-on-Green (IOG) ENABLED
MC: GIO Timeout at 1f46a07c
MC: GIO Timeout at 1f46a07c
BT445: Sync-on-Green (IOG) DISABLED <--IRIX starts booting
BT445: Sync-on-Green (IOG) ENABLED
MC: CPU Error at 1fb001c0
MC: CPU Error at 1fb02000
MC: GIO Timeout at 1f400000
MC: GIO Timeout at 1f600000
MC: CPU Error at 1fb5d000
MC: CPU Error at 1fb00010
MC: GIO Timeout at 1f400000
MC: GIO Timeout at 1f600000
MC: CPU Error at 1fb001c3
MC: GIO Timeout at 1f400000
MC: GIO Timeout at 1f600000
MC: CPU Error at 1fb02000
BT445: Sync-on-Green (IOG) DISABLED <- login window appears
BT445: Sync-on-Green (IOG) ENABLED

Is there a way to somehow delay applying the 2px offset until the display inits for the login window? That would avoid cropping the boot screen.

For the CDROM, if you try to mount any iso9660 image you should see what I'm seeing. Only EFS-formatted CDs automount. Also, a minor related issue, if I don't specify a iso there's no CDROM device in the emulated machine.

I'll build the latest version now so I can have a look at the changes. And check out the new screenshot function. Thanks for adding that.

[therealfumbles]

Screenshot function works great!

It's nice to have the desktop complete now. Ideally this wouldn't come at the cost of cropping the boot screen but if it can't be helped I assume having the desktop render completely is preferred.

[techomancer]

b39aaf5 should help with iso cdrom images.
it is not perfect though. mixed efs/iso like Hot Mix 19 didnt work with mediad but it can be mounted manually.

[therealfumbles]

Thanks for fixing the iso9660 support. IIRC those later HyCD/HFS-formatted Hot Mix discs didn't automount in MAME either.

I have another couple of suggestions for the CD support. Should I post them here or would you prefer I start a new issue so you can close this one? You've addressed all of the initial issues, unless you think there might be a way to un-crop the boot screen.

[techomancer]

its better to do one thing per issue so they can be tracked and closed as things are fixed.

[therealfumbles]

Yep, makes sense. I've posted my thoughts as a new issue.