Posts by Timm

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.

Don't Panic. Please wash hands.

    The Mk3 doesn't seem to read/calculate the EDID info 100% correctly, and I guess it could be the TVs giving out the wrong information. When the Mk3 checks the EDID info it adds only 3 modes to the list, but I think the TVs are capable of a lot more because I've seen them do it when connected to PCs, Raspberry Pis and game consoles. It looks (at least to my not-expert eyes) like the Mk3 is getting most of the information correct for the resolutions it lists, but not the back porch setting, and then because of that, the frequencies are wrong which results in no picture. Below is what the Indivision tool returns, I've highlighted the fields I think are incorrect.

    You are correct, I can confirm a bug in the EDID mode evaluation. Thank you for your clear and useful presentation.

    It is also correct in that there are more modes that could be added from evaluating more EDID info from some devices where some of the more interesting "TV modes" are located. First we need to get this bug corrected per an update to the config tool.

    BTW, is the 'X' key thing an undocumented feature of the "Live-edit" mode? It is not mentioned anywhere in the manual, AFAIK… ;)

    Yes, the 'x' key thing is still undocumented, along with a few other keys.

    Since firmware 20200812 it works as intended. It will cycle through different active Indivision modes with the same match criteria; for example, it can allow you to switch between 640x512 PAL and 736x548 PAL VSync.


    Config tool 1.3 with firmware 20200812 is now available:

    http://wiki.icomp.de/wiki/Indivision_AGA_MK3/doc

    BTW, is the 'X' key thing an undocumented feature of the "Live-edit" mode? It is not mentioned anywhere in the manual, AFAIK… ;)

    Yes, the 'x' key thing is still undocumented, along with a few other keys.

    Since firmware 20200812 it works as intended. It will cycle through different active Indivision modes with the same match criteria; for example, it can allow you to switch between 640x512 PAL and 736x548 PAL VSync.


    Config tool 1.3 with firmware 20200812 is now available:

    http://wiki.icomp.de/wiki/Indivision_AGA_MK3/doc

    Oh boy - so the Vampire guys didn't learn a tiny bit about compatibility? Timm, can you please confirm in public that you're using the exact chip register mirrors that were "the solution" for Indivision ECS V2? I don't want to jump to conclusions (just yet). The error might as well be on our side, but that's for Timm to verify/falsify.

    I'm sorry. We did not use the Vampire workaround chipbase in all places. This should be corrected now in Version 1.1:

    http://wiki.icomp.de/wiki/Indivision_AGA_MK3/doc

    The tool works fine without accel, with 020 and with 030 accelerators. Granted, it's currently not yet been tested with 040/060 CPUs, but that should not cause any trouble. To fix any bugs (if any), there is a debug version that outputs a lot of additional information through the serial port - Timm can send that (or upload it to the Wiki).

    I think that would be beside the point, as the problems on Cego's machine seem to run deeper than what can be covered with some serial debug output. We can do this, but this might just add to the confusion. The config tool is not supposed to throw random GURU requesters, to cause division by zero, etc. A start would be to run the tool with just the IndivisionAGAmk3 installed and all other expansions, accelerators, etc. removed, from a freshly booted standard Workbench. In a shell, please invoke "stack 100000", then "showconfig" (and post the output here), and then run the config tool.

    The CacheCDFS archive contains only a program that goes to SYS:Prefs/ and a handler that goes to L:. To the best of my knowledge, a handler doesn't need the execute flag. Setting the "execute" protection bit on the prefs program in the command line would look like this:

    # protect sys:prefs/cachecdfs e add

    I'd rather not remove the line from the startup-sequence. If the ROM is 3.1.4 and the OS installation is 3.1.4.1, then it may still make sense (for OS3.1.4.1) that ROM updates are being installed.

    What's pointless is to map the ROM into fastmem when it's being mapped again immediately thereafter.

    If you were running OS3.1.4 without a 3.1.4 ROM, it can make sense to use ACATool to load and map the 3.1.4 ROM file. But if it's immediately mapped again in the startup procedure, this task is better left to the OS3.1.4.x.

    If you boot OS3.1.4 and do not have a 3.1.4 ROM, then MapROM in ACATool is pointless.

    The reset is then caused by C:LoadModule ROMUPDATE from the OS3.1.4 startup procedure.

    You can choose which one does the reset; it's either ACATool 2.1 (when an OS3.1.4 ROM file is specified), or the 3.1.4 startup procedure.

    It's in the presets, but overwritten by your current configuration. You can get it by "Restore to Defaults" (and switch back using "Last Saved" if need be. Also remember that you can save your current configuration to a file for later reference). Sorry for the new presets are not automatically merged into your configuration. But the new defaults come with slightly changed positions, so it's probably better to start from the new defaults.

    Selecting a 1280x1024 VGA mode should not truncate an Indivision 640x512 mode, and you should get a requester to notify you in that case. Please let me know if this can be reproduced with the new version.