Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
it's Iiyama ProLite x2472hd.
So looked that up. Documenation of this monitor specifies vertical as 55-70Hz. So indeed 800x600@72hz you tried is outside the supported range. The only VGA modes supported are 640x350 and 720x400. So this monitor is very limited what it accepts as input. It seems to lack support of many common VESA modes and only 60 Hz versions can be used.
Yeah thanks for the positive feedback!
My only suggestion at this point would be to somehow detect on first power on, if the selected output resolution (and refresh rate) is within the display's specs, if EDID is indeed available.
I can see your point, but problem with this approach is that the startup resolution (probably 640x256), doesn't have to match the workbench resolution. So even if we did this at poweron the moment the workbench gets loaded it could still lose the picture again. Which means it would have to check the EDID on every resolution change, but we decided that all that parsing complexity is put in the config tool and not the hardware, you know to keep the costs reasonable.
Ok, found the reason for the "pixel eating bug" visible only on 640x480 resolutions.
The fix will be included in the next firmware release. Thanx for reporting.
I will take a closer look at the logic.
It looks like the "scaler" (if you can really call it that) is eating pixels when set to 1.5x for horizontal (that is only used for 640x480).
Not sure why, the scaler logic hasn't been changed, probably a case of "only worked by accident and now doesn't", because... reasons.
Yes by setting OSDSec value to zero in the Adjustments screen of the configuration tool.
Are you logged in to the shop or browsing as a guest? You need to be logged in to be able to order software items.
"that specific screen" is rather ehh unspecific? I guess you are looking at a window with the label "Select and Edit VGA mode"?
There is only one slider on there. I think the others like F porch and sync are are referred to as "spin controls" at least that is what they are called in windows. Please look again the pixel clock slider is at the top of this window above all the other controls you named.
there you go, firmware 20201014 for indi aga mk3
However, the little yellow line on the right is not great.
This issue has been solved in the firmware (20201014) included with the configtool version 1.7
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.
Pressing 'X' in live mode cycles through all compatible modes for that specific screen mode. So you could define a config for a specific game and put it at the end of the list so it isn't selected by default and then use the X in live mode to cycle to it when needed.
That didn't quite work, the image was much too narrow. But for some reason that I don't understand 960 does work:
Yes 1920 / 1080 = 1.777
And 960 / 540 = 1.777
So 960 does indeed gives you square pixels. Maybe not or not exactly matching the Amiga aspect ratio, which can be all over the place depending which mode you use. PAL vs NTSC while both 4:3 modes but will have different pixel "squareness" as one has 512 and the other only 400 active scanlines on the screen.
However, the little yellow line on the right is not great.
Yeah that is on my todo list to fix (or automatically hide at least). Not sure yet if the Amiga is really generating that yellow pixel or if it is a bug in the scaler logic.
Another slight annoyance is that the background color (if not black) is much wider on the left than on the right.
Yeah well that is what the Amiga is generating. Hard to tell all the game developers retroactively to center their picture better.
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.
Well the fact that a utility like borderblank even exists, kinda shows this is not easy to solve on the "monitor/display" side. The danger of introducing something like a cropping feature (adding artificial blackness) that users will start complaining about missing pixels in their games. As about none of the games will exactly match whatever WB is setup as all games and demos just do basically whatever they want position wise (within the hardware limits).
Timm, if you read this, please know that "Is live, but wouldn't be applied" is an insane status message. The config program should never just shrug it's shoulders to the user and say "according to the configuration, this mode should not be the one active right now, but it is anyway". Why is that even a possible situation that can occur?
I can see one scenario where that could happen, with the live edit mode you can select a different compatible mode by pressing 'X'. So in that case the current mode that is live doesn't have to be the mode that would be selected by the software.
Other scenario is editing the configuration in the tool and changing Min and Max Lines for a mode that is current live. After the edit it will not be the one that would be picked, but it is still active currently and you could end up with that same message.
Not suggesting that is what happened in your case, just to chime in this is a valid situation that the config tool should be able handle (and does even if the message seems a little weird).
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.
If you want that you set the Amiga number of pixels to 1350 in the config tool.
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.
Some of the pixels on the side will be background color. Further away it will be black. The PAL screen isn't really 640 wide, that is just the number of pixels that have graphics, that actual screen is more like 720-ish with part of it background color.
You could try enabling "doublebuffer" mode in the advanced settings of the config tool in some cases that can help, but in other cases it makes it worse as you half the update rate of the screen. Pinball in interlace? Yeah I can image how that looks converted to progressive scan, doing that conversion correctly requires a huge amount of video processing. Basically you need to estimate the movement between frames and interpolate that movement across frames. Definitely something outside the scope of the Indivision products.
Something that looks like if it is drawn every other line.
Yes, because that is exactly what an interlaced screen means, it is drawn in two passes. First all even lines and then all odd lines. So for moving items you get these "hair comb" effects.
You can test the keyboard with the "hardware test core". This will flash both LEDs and it shows the 8 bits of the last received scancode when you press or release keys (located above the 8x8 C64 keyboard matrix on the hardware testcore screen).
Hi,
Thanks very much for the core update, please may I ask what kinds of changes/improvements you have made, what differences you might expect us to see, and if there is anything in particular you'd like us to test?
I've just flashed the new firmware and after a reboot all seems fine so far.
Only improvement is stability, no functional changes. No more random black screens once every minute, while sitting idle on the workbench or when moving the mouse. And no OSD popping up without any apparent reason, or random things like that. If you didn't have seen that happen with the previous firmware there should be no difference/change for you. Nothing particular to test, just use the Amiga, unless these problem did happen for you in specific cases, they should no longer happen in those same specific cases 
I don't think you can put 2 Mbyte chipmem in the trapdoor, not without additional support hardware at least. There are cards that can provide up to 1.8 Mbytes in the trapdoor, but those can't be used as chipmem. Only the processor can access those. For chipmem the trapdoor can only provide 512k together with the 512k on the mainboard for 1 Mbyte total (when using the correct Agnus ofc).
I'm not familiar with the vampire hardware, so can't tell you if that offers all the features you are asking for.
If I upgrade to a 8372A + 512kB extra trap door memory and do needed modifications to get 1MB chipmem will the system be:
- upgraded to full ECS? ECS Agnus and ECS Denise?
- Will I get more resolutions available for workbench? i.e. 800x600?
With the ACA500plus you don't need modifications to use the trapdoor as additional chipmem, you can enable this in the menu system.
Yes you do need an ECS Agnus to have higher graphic modes like 800x600. You don't need a different Denise as the ECS v2 replaces this chip. In the config tool of the ECS v2 you can enable ECS mode.
If I also upgrade with a ACA1221lc will I get:
- possibility to increase chipmem to maybe 2MB and run AGA games?
- Increase workbench resolution even more?
No an accelerator doesn't increase chipmem. The extra memory on accelerators is fastmem that can't do DMA or graphics, but is faster for running programs as it isn't slowed down by the DMA fetches (for graphics and sound). AGA is a different chipset, not available on a A500. The A500 is restricted to either OCS (what you appear to have now) or ECS chipsets (that you can upgrade to).
