Posts by iljitsch

After the 1.6 update it looks like the EDID readings are different. I retried with one monitor, but still the same result. However, that's a DVI monitor and although I selected no audio output, I want to make sure that that's actually what's being used so I want to do some more checking, and also with the other monitor. However, as I'm currently doing surgery on my A3000, this will have to wait a bit.

(It would of course be ideal if the audio can be disabled automatically for DVI monitors.)

There was certainly some kind of change between 1.5 and 1.6. This is with 1.5:

And this with 1.6:

So now the horizontal frequency matches the 67.5 kHz listed in the monitor's manual and it's also exactly 60 Hz vertical rather than 60.0228.

(By the way, I wouldn't mind having the pixel clock in kHz rather than Hz to get rid of some zeros.)

Yes, I tried that, and I also confirmed the PRE mode is the same as the EDID mode for all monitors.

I do find it curious that those EDID and PRE modes are all the same for monitors from 2011, 2015 and 2018. At the same time, the 2011 monitor (which doesn't work) and the 2015 one (which does work) say horizontal 67.5 kHz and pixel clock 148.5 MHz. The 2018 one (which doesn't work) also says 67.5 kHz but doesn't mention the pixel clock in the manual.

The 67.5 kHz doesn't match the EDID info, which makes me suspect that the EDID info the setup tool shows is somehow different from the info the monitors send. It would be very strange that three monitors from two different makers send the same wrong info, especially if using that info doesn't work for two of the three. (Not impossible of course, but certainly not the obvious explanation.)

I'm having an issue with the Indivision AGA MK3 where two of my monitors say the timing for the 1920x1080@60 resolution is out of range. One is a Dell U2312HM (1920x1080 native resolution) from 2011 and the other an HP Z27 (3840x2160 native resolution) that I got new this year. A Dell P2415Q from 2015 doesn't have the issue.

The super weird thing is that these are actually one of the monitors' EDID resolutions. They all report this in EDID, which also matches the 1920x1080@60 preset:

I checked the Z27's manual, and it says 1920x1080@60 should have a horizontal frequency of 67.5 kHz, so that's slightly different than these timings.

Could it be that the EDID data is changed from what the monitor reported at some point?

Also note that the above doesn't match any of the 1920x1080@60 timings from the Video Timings Calculator. I couldn't try the CVT timings because those require a pixel clock of 173 MHz, but I did try the CVT-RB timings and those also didn't work.

Strangely, both do monitors work with the exact same settings except a 125 MHz pixel clock so the vertical refresh rate becomes 50 Hz (to be more compatible with Amiga PAL modes).

I tried some stuff some weeks ago when I got the MK3 and don't remember seeing this issue on these monitors or my 4K TV. I think I tried 1920x1080@60 then but I can't be sure. Since then I've only been using the P2415Q monitor which doesn't have the issue, until today.

I tried restoring the August 24 firmware but that didn't change anything.

Just in case you guys aren't seeing it: I encounter a bug in the config tool where when there are two mappings for an Amiga mode, one for SHires and one for not SHires, when making changes then the other one is applied. So I'm in SHires, make changes, then the non-SHires mode is activated.

A reboot clears this up, but now that I know about the X for cycling modes in live config mode I use that to get back to the right mapping.

Quote from Jens

According to André (author of HighGFX) there's not many monitor type IDs free on top of what he created, and I suggest to not just occupy one. He has something planned for the remaining one or two IDs that might be what you need.

Interestingly, André uploaded and updated version of HighGFX to Aminet yesterday!

I'd say all of these problems are solvable. But at what cost?

It would probably be a better solution to make it possible to run RTG graphics directly on the Indivision, circumventing the AGA chipset. That would be cleaner and faster, especially for those of us with fast accelerators.

(I have no idea about how the Indivision gets data from the CPU or memory directly, though. Perhaps there are significant limitations here as well. But certainly there will be enough bandwidth for smooth mouse pointer movement. )

As thing are now, I'll live with the mouse pointer issues. In interlace the mouse pointer wasn't great either, and at least in 30p scrolling of text and graphics looks a lot better.

Well, it seems that MonSpecsMUI already does that, it allows changing very many monitor driver settings. I just don't know what most of them mean or do. Perhaps there is documentation for this, but I suspect there isn't.

With the changes I made to Euro36 I get 960x540@30, which is half of 1920x1080x60 for each of the three variables, I think we get a very good result considering the limitations of the Amiga and the fact that the Amiga predates the start of the shrinking pixels where ultimately individual pixels would become invisible to tell apart. (I.e., "retina" displays.)

For this mode, I'm using very close to the minimum number of scanlines that still works and I reduced the number of pixels per line (in the form of TOTCLK) a bit to hit 30 Hz. This actually leaves something like 20% of the available scanline pixels unused. I also think it should be possible to reduce the horizontal sync and blanking, but clicking around in MonSpecsMUI didn't give me any results.

However, in my opinion, it's not a great idea to go for the maximum number of pixels the Amiga can show by shortening all the sync and blanking periods, because that way, screen output uses up much more chip memory bandwidth so less is left for the blitter and the CPU so redrawing all those pixels will become extremely slow, especially in 32 - 128 color modes and double especially in 256 colors.

Now if only somehow the mouse pointer could be made to look nice and move smoothly. I guess if you guys are taking feature requests that could be done with a sprite on the Indivision hardware at the full HDMI/VGA resolution overlaid on the Amiga image and making the Amiga mouse pointer sprite invisible.

I've tried looking for the source fo a monitor driver, but there doesn't seem to be any available, and building one from scratch looks very complicated.

But I've been able to get the overscan issue solved: the MonSpecsMUI tool that I used to change the Euro36 monitor comes with an extra program that reads the tool types that MonSpecsMUI writes to the monitor driver .info file and sets up the right overscan settings. Running this program from my s:user-startup makes everything work.

The advantage of this solution is that it can be done by anyone through MonSpecsGUI. I doubt anyone is using the Euro36 driver in its original form, and this way no new IDs are used up and settings related to Euro36 don't have any impact on settings for other modes.

I'll do a writeup for my blog (where I already posted a review of the MK3) and I think I'll upload the modified Euro36 monitor file to Aminet the next few days.

Only remaining problem: the mouse pointer looks low resolution horizontally and high resolution vertically. But I can solve that to a reasonable degree by drawing a taller mouse pointer.

Annoyingly, the reset of the overscan limitations only happens under AmigaOS 3.1.0, not under 3.0. Copying over the (larger) 3.0 monitor file doesn't help, and trying to patch the monitor file doesn't work either. So these overscan limits must be coming from somewhere else, but I have no idea where.

Quote from Jens

According to André (author of HighGFX) there's not many monitor type IDs free on top of what he created, and I suggest to not just occupy one. He has something planned for the remaining one or two IDs that might be what you need.

Don't worry.

What I did is take the Euro36 monitor driver and change the number of scan lines ((TOTROW) to ~ 565 and reduce the TOTCLK to 211. This allows for a 960x540 @ 30 Hz resolution in SHires. So no more interlacing artifacts, although quick mouse movements make the mouse pointer move in a choppy way.

However, there's one issue I haven't been able to solve: the Euro36 non-interlaced resolution has an overscan graphics size of 654x200 and a maximum size of 764x200. So although the Amiga has no trouble displaying the 480x540 resolution (ignoring SHires for a moment), it thinks that everything beyond line 200 is off-screen so you can't put the mouse pointer beyond line 200. If you try that, the image scrolls.

It is possible to solve this with the MonSpecsMUI program that I used to change the settings (= tool types) of the Euro36 monitor driver, but for some reason these settings don't survive a reboot.

So if anyone has a tip on what to do to make this work across reboots that would be really helpful.

(Of course this only works for Workbench programs and programs that let you select a screenmode, not games that use PAL or NTSC.)

I understand. A solution to the artifacting I've been thinking about is making a monitor file that lets the Amiga to use a lower framerate progressive scan mode such as 25p/30p/36p or something. I'll let you guys know if I have any success.

Ah, that's super awesome!

I guess now my biggest remaining issue is that I'm starting to hit the limit of 31 (I think) mode presets that are possible.

Is it possible to output interlaced modes over HDMI? That way, it would be possible to leave the deinterlacing to the display. Some TVs have pretty good deinterlacers these days.

It does look like the extra pixel happens somewhere in the MK3 as the Amiga's native RGB output doesn't show it:

This is a closeup of the RGB output:

And the MK3 HDMI output:

You can also see that the MK3 shows a lot more overscan on the left, and all of the gray is usable, the maximum overscan I can get is 724 pixels.

(Oh, and did I mention how much I love the sharpness of the MK3 but with the scanline effect so games look the way they should? The second closeup is so much better than the first.)

Yes, it is true that it's not easy to set up a mapping that shows everything you want to see and show nothing you don't want to see even for all these games doing their own thing.

What I've tried to do is set things up such that with no overscan settings, the actual image is centered with the same amount of border on both sides. Unfortunately, that setting reduces the maximum amount of overscan you can use. But fortunately you can use modes that provide 960x540 or 1280x720 all the way to the edges of the screen.

And if only a few titles do weird stuff it's easy enough to adjust using the live edit mode. Too bad though that this won't let you select a different preset on the fly.

Quote from iljitsch

I got my Indivision AGA MK3 last week, and I really like it. However, there is one missing feature that really makes it harder to work with the MK3 than I think it needs to be.

Quote from pwsoft

If you want that you set the Amiga number of pixels to 1350 in the config tool.

That didn't quite work, the image was much too narrow. But for some reason that I don't understand 960 does work:

(This is with 1920x1080@50.)

However, the little yellow line on the right is not great. When using the Workbench it's hidden by borderblank, but when playing games it's visible. Another slight annoyance is that the background color (if not black) is much wider on the left than on the right.

I would still really appreciate a way to make all of this easier to set up and make look nice even when not using borderblank.

I got my Indivision AGA MK3 last week, and I really like it. However, there is one missing feature that really makes it harder to work with the MK3 than I think it needs to be.

That feature is the ability use a regular Amiga resolution such as PAL or NTSC with the native or common resolutions of today's widescreen monitors, for example 1920x1080 without the image looking stretched.

Currently, the MK3 will always fill the selected monitor resolution with the selected part of the Amiga resolution. For PAL, that means a resolution of 640x512 will be stretched to fit in 1920x1080. However, that doesn't look right because the Amiga uses a (roughly) 4:3 aspect ratio and the monitor a 16:9 aspect ratio.

My feature request is to add a setting that makes sure that the image is scaled to the same degree in the X and Y directions. So with 640x512 -> 1920x1080, that means the Amiga's 512 lines are scaled by a factor 2.11 to fit the 1080 lines of the monitor, and then the horizontal scaling is also a factor 2.11 so 1350. That means 1920 - 1350 = 570 pixels per line aren't used, so 285 pixel wide black bars are added to the left and the right of the Amiga's picture.

(Of course the black bars could also be above and below the Amiga's image, for instance NTSC 640x400 on 1280x1024 would be 1280x800 + 112 line black bars above and below.)

It would be even better to fill the bars with the Amiga's border color or perhaps a user-definable color, but letterboxing/pillarboxing is normally done with black bars so black only is totally fine.

Quote from Jens

You may be able to reduce or even completely remove the glitches by shifting sync length and porch length against each other. I don't know exactly where audio is transferred, but it may be only during sync periods and not the porches, so you may need to give it more sync time in order to gain enough data transfer time for audio.

Hm, that does make sense but then again, I'm using the same sync and porches in both the SHires and the regular PAL modes, and for SHires these are EDID so I would assume those allow for sufficient audio bandwidth.

I'll do some experimentation when I have the time. (For now I'm having big problems moving my installation from one CF card to another and soft-kicking OS 3.1.4.)

An update on HDMI audio:

When I run in PAL shires lace 960x540 32 or 64 colors -> 1920x1080@50, there are a lot of audio glitches at all sampling frequencies with my Dell P2415Q.

When I run in PAL hires lace or lores -> 1408x1080@50 at 96 kHz, the audio is perfect.

Non-CRT TVs tend to have good deinterlacers that will use the full resolution on static images but make a full frame out of each half frame when there is action. This of course adds blur but our brains expect to see motion blur on movement anyway, so usually this is not a problem.

These are complex algorithms, however, so it would be difficult to impossible to implement this in real time in the Indivision.