Indivision AGA MK3 for A1200

im not sure what you mean

This is my settings Curent Position:(8,8), Current size 664x264

if not that point my on right place

Quote from BlackTiger78

Curent Position:(8,8)

X-position can be divided by 8 without remainder - correct.

If that doesn't do the trick, something is wrong with your version of Nemac IV. You've seen other Graffiti software work, so it's not Indivision. Although.. can you check what screen mode Indivision finds when Nemac IV is started? Maybe it's just a false detection, and it's switching to a mode where you don't have Graffiti enabled? Try putting the OSD on a long timeout, so it shows you what type of screen it finds. I'll look at it tomorrow (about to leave the office now).

So about Graffiti was i was able to check

- viever ok will test more

- tech demos (from your link) - ok

- Nemac IV - errors, wrong colours see prev screens, tested 2 versions

its black and white sometimes green and blue (dont know its important) look at atached OSD resolution

- Shapeshifter - on Graffiti 030MMU got errors with overscan see 2.jpg when set overscan Curent Position: (8,8) got this error 4.jpg

(shapeshifter works fine without selected graffiti mode)

About MK3:

1. I can't read monitor (Could not read Display Information) data from my 27" Acer XB271HU (via HDMI)

2. can read on NEC 20WGX2 (via HDMI-DVI)

checked 3 cables all works, same cables works with MK2cr

3. Sometimes in few games and when workbench starts I have vertical yelow line always on right side see 3.jpg

4. CIA adapter is too close to keyboard connector cant disconect kb without removing CIA

Amiga 1200 ,ACA1233 MMU 40MHz, Your PSU, CF 4GB,

Quote from BlackTiger78

- Shapeshifter - on Graffiti 030MMU got errors with overscan see 2.jpg when set overscan Curent Position: (8,8) got this error 4.jpg

The error requester gives a valuable hint: For SHires, it appears like you have a different overscan setting than for Hires. The driver sees that you have an X-offset of 36, and it even makes a suggestion for a corrected value (didn't remember that we added this check to the drivers - it's been 24 years!). Please find that incorrect setting first - it may fix Nemac IV as well.

Quote from BlackTiger78

CIA adapter is too close to keyboard connector cant disconect kb without removing CIA

..hence the hint in the manual not to remove the keyboard, but to carefully set it to the back of the computer for installing. There's really not much we can do about this, as the distance between CIA chip and keyboard connector is really tight. Our goal was to make a product that does not requrie you to drill a hole into a classic computer's case (for example for an additional button or other control). Adding another step to a possible "keyboard removal" procedure is an acceptable price to pay for reaching this goal.

Quote from BlackTiger78

Sometimes in few games and when workbench starts I have vertical yelow line always on right side see 3.jpg

That may be a leftover from a previous screen - obviously a bug, as either the output entity is showing one pixel too much, or the input entity is storing too few pixels, not overwriting the previous screen.

After few days of test have a big problem now, MK3 stoped working after reset.

Screen starts flashing lines and wb bars on botom after reset Hardware not found,

A1200 work signal on rgb out.

I let her rest no changes, removed and instaled MK3 again no changes,

when i want to load the Config Tool from the provided ADF 1.4 it shows

first "couldn't open asl.library" and then second "IndivisionAGAmk3 Hardware not found"

then suspend/reboot

and my recovery disc got bad sectors

Is booting 1.4 adf without ss and

flashtool flash firmware

will help ?

Update: DONE flash do its work

But what caused the crash ?

Quote from pwsoft

Did you try it with "auto resolution" enabled? As just vsync has the problem that the VGA/HDMI output and the Amiga input will not contain the same number of total pixels. So there is a jumpy line at the bottom of the screen, which might confuse the HDMI input on the monitor. With auto-resolution enabled the output is forced to have the exact same number of pixels and lines (or twice that) as the Amiga input. Although it will limit the choice of output resolution and for some monitors it only works when setting the mode to SuperHires (even though the games are hires). As this will force a doubling of the Amiga pixel clock as bases for the HDMI. The default 28.x Mhz is often too low for HDMI/DVI monitors (but often works on VGA). But when it works it gives a very good vsync result.

Just tried it again.

When i'm using HIGHGFX:Super hires laces (1024x768) and i use EDID 1440x900@60Hz with VSYNC and auto resolution then sometimes i have a stable image, realy rock solid and sometimes i have a wobling screen (like an interlaced screen on a 1084).

So the same result as when i put in the values as calculated for my own screenmodes : 1472x800@50Hz (gives best image with VGA, nice 100% fill without scaling) , 720x576@50Hz and 1920x1080@50Hz

With this same mode (EDID 1440x900@60Hz) with, and without shires and or auto resolution i have always this issue with the standard amiga modes (lowres, hires interlaced on/off).

All the other detected modes (just 4, all 60Hz) only give image without vsync and autoresolution

I have the same results on 2 freesync gaming monitors(iiyama and lc-power). Didnt retest on my tv's yet

Dont know if its relevant : When connected one of the monitors to my PC i can select 50hz modes and when i turn on vsync, it locks to 50 frames.

Quote from mbruines197703

When i'm using HIGHGFX:Super hires laces (1024x768) and i use EDID 1440x900@60Hz with VSYNC and auto resolution then sometimes i have a stable image, realy rock solid and sometimes i have a wobling screen (like an interlaced screen on a 1084).

For HighGFX, it does not make sense to try VSync, as the HighGFX driver is reducing the Amiga's frame rate to a minimum - the XTREME drivers even reduce it to less than 40Hz. Trying to VSync to that will probably make every monitor lose the signal. The same applies to "auto" and HighGFX: Simply doubling the pixel clock does not do the trick, as HighGFX is so far off any standard (both Amiga and VGA modes).

VSync is desirable for PAL and NTSC screen modes, which are mostly used for games with lots of moving things on the screen.

For HighGFX and the weird AGA modes, I would not expect VSync or Auto resolution to work.

Quote from Jens

For HighGFX and the weird AGA modes, I would not expect VSync or Auto resolution to work.

Yes, i realize that, but while testing forgot to change the test mode, and at the first try the image was very good, second try a no go. Some attempts later stable image.. Thats why i mentioned it, maybe it gives some clue

For the standard modes, its in every attempt no stable image over. its moving up/down by about one pixel

Note that this issue is only on HDMI, VGA is working like a charme.

Quote from mbruines197703

For the standard modes, its in every attempt no stable image over. its moving up/down by about one pixel

Note that this issue is only on HDMI, VGA is working like a charme.

As explained earlier, the "jumping up and down" is a result of VSync inserting blank lines in order to do the output VSync at the same time as the host computer. To get around that, we have added the "auto resolution" modes, which avoid inserting extra line, as input and output pixel clocks are perfectly syncronized.

Quote from Jens

As explained earlier, the "jumping up and down" is a result of VSync inserting blank lines in order to do the output VSync at the same time as the host computer. To get around that, we have added the "auto resolution" modes, which avoid inserting extra line, as input and output pixel clocks are perfectly syncronized.

Yes, and this is turned on. Tried to make a video, but doesnt show to well on my phone camera, cant upload it anyway., shires is also turned on.

Quote from Jens

As explained earlier, the "jumping up and down" is a result of VSync inserting blank lines in order to do the output VSync at the same time as the host computer. To get around that, we have added the "auto resolution" modes, which avoid inserting extra line, as input and output pixel clocks are perfectly syncronized.

.... or do i need to turnof vsync, and only the auto resolution .. if true, i didnt find this in the manual, but it seems to work this way since sidescrolling is smooth now.

I was playing Ruff and Tumble and notices that the screen turns black some times (HDMI, autoresolution), As far i can tell there is no change of screen mode since the OSD isnt popping up.

This is some times during gamplay, but most after finisching a level during count of collected items and fading out. Mostly this starts at the end of the second level / during the second level.

Also had this while playing brian the lion and during some demo's (technical death, same screenmode)

Didnt notice this on VGA, but on HDMI this happens on both my monitors. Using DVI mode gives the same.

can anyone confirm if hdmi audio stops working in alien breed 3d 2 tkg. Music in team17 ocean intro works but no audio in the game its self. Using firmware from 1.4 archive.

Quote from Jurassicc

can anyone confirm if hdmi audio stops working in alien breed 3d 2 tkg. Music in team17 ocean intro works but no audio in the game its self. Using firmware from 1.4 archive.

Yes, it also stops with turrican III and some other games and demo's. But still its a nice extra, and for most games it works.

I tried on a different TV to reproduce 'black screens'. With Ruf and tumble it again showed up at the and of almost each level and sometimes while playing.

With Brian the lion its not consistent (happend 1 time).

With demo's it is more common, Hardwired is a good example, it happens in the middle of some demo parts (shadebob part before the twist scrolller) where the screen mode isnt changing only now the OSD of the indi shows up after a black screen. Happens quite a lot to.

In this demo the white text (saying crionics and the text after that) is flickering. Dont see this flickering and blackscreens on my IndiECSv2.

Quote from mbruines197703

I was playing Ruff and Tumble and notices that the screen turns black some times (HDMI, autoresolution), As far i can tell there is no change of screen mode since the OSD isnt popping up.

The OSD is only popping up if there is a significant amount of difference between the number of lines from one frame to another.

However, Auto resolution needs to compensate each and every change and adjust the output parameters according to what the Amiga produces. What you're describing is a result of copperlist changes from scene to screne, and that may result in a VBlank coming at the "totally wrong spot", resulting in at least two frames being totally out of sync for the monitor.

The old 1084 monitor will just react with a short flicker that you probably don't even notice, as the screen is black during that time. You also don't notice this without auto-resolution, as the output frequencies would be totally static.

I wouldn't have any idea how to work around this - after all, it's a software fault to change copperlists without syncing that action with the current beam position. It's especially annoying with the demo "state of the art" (TP91 winner demo).

Quote from Jens

What you're describing is a result of copperlist changes from scene to screne, and that may result in a VBlank coming at the "totally wrong spot", resulting in at least two frames being totally out of sync for the monitor.

Well, we have VGA as well , didnt notice this when using VGA. And Ruff and Tumble is not exactly a smooth scroller compared to others.

Quote from Jens

I wouldn't have any idea how to work around this - after all, it's a software fault to change copperlists without syncing that action with the current beam position. It's especially annoying with the demo "state of the art" (TP91 winner demo).

Hmm, i just wached "State of the art" twice till the end, and no blackscreens. However, minimizing DirOpus (version 4.0, was by exident clicking at the wrong spot) gave me black screens. When trying to reproduce it , it didnt, later on it did it again. It isnt consequent. My best gues is it does matter where the 'beam' is on the screen. As far as i remember, the copperlist isnt changed when minimizing a window in WorkBench.

The black screens are also happening sometimes when doing nothing at all, just having the workbench screen open seems to be enough too.

It happens more regular when using Menu's, closing windows, minimizing windows.

Trying to reproduce is most of the time unsuccesfull,but when it happens its more likely to get the same result over and over again doing the same thing what caused it (in this case minimizing/maximizing DOpus).

I managed to make one image while using the minimize gadged of DOpus 4. Afcource after the blackscreen showing the OSD

I have the feeling its happening (more often) with a 'cold' computer then after using it for some hours

Used setup:

Rev 1d4 board (Recapped)

ACA1233n@40Mhz with IDE speeder at full speed

Rapidroad USB (Nothing attached at the moment),

Realtime clock on clockport (icomp),

32Gb CF as harddrive,

Allready put back the stock Drive since saterday to rule out Gotek drive.

PCMCIA network card (happens when disconnected to)

Sitecom PCMCIA CF adapter (almost never connected)

Icomp CA-PSU

Afcourse the Indivision MKIII

Running OS 3.1.4 afcource with the original roms installed, but mapped to fastram, used screenmode PAL Hires Interlaced in 256 colors.

DVI mode is tuned on, but doesnt seem to be neccecary. All other advanced settings are at the default.

Also tried a stock 3.1 installation with only WHDLoad, DirOpus and personal paint installed since i have some WB enhanchers installed on my normal CF card (ToolsDeamon, click to frond).

We now have reports from a few customers about these screen-dropouts. I'm trying to find what the host computers have in common - you already mentioned your board revision, but that's not enough to really compare the boards. If you can, please list the chip revisions, or even better: Take a picture of the motherboard, ideally from both sides, so we can also see if there are timing mods done on the bottom side of the board.

Please see if the "CCK pull-up" and/or "CCK capacitance" options in the "advanced" menu changes this behaviour. The current theory is that a register access is not working as it should, and access timing is counted along the CCK clock.