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.
-
-
Additionally, I've noticed that when I cycle through the audio/DVI modes on the Advanced options modal window in quick succession, the Indivision Tool sometimes seems to get itself into a state where it thinks it has already saved/synced changes I’ve made, when it has not. I have to quit out of it and redo them when this happens.
Bugs in this regard are certainly possible, but I cannot reproduce it.
In any case, it would be hard to imagine that something like this would have something to do with multitasking and CPU speed.
-
This blank space can be filled by changing the scaling values. However, the "PRE" modes are protected from being changed - all the fields become really adjustable after you've made a copy of the mode and applied that to the "current" screen mode.
You are right that "dangerous" settings are protected in the 'Preset' modes, but position and scaling are always adjustable.
-
In regards to it not sensing resolution, I am still confused in one regard.
Upon first installing, default settings, I had no idea what profile was being used for games. As I mentioned, I found out it was using the 800x600 profile as default for games (by looking at the OSD). This part I do not understand, could you elaborate? How did it choose 800x600 profile, why was this the chosen profile. Understanding this fact will help me understand the entire system and how it works (I have read the docs)
The point that is needed for understanding: On a mode switch, the mode list is evaluated from top to bottom. The first mode that matches the criteria will be used. The criteria are (mainly) the number of lines on the screen, and secondarily the 'Select on' criterion. The reason why 'Pre 800x600 PAL' is selected in the defaults is simply that there are no other modes enabled in the list above that match its line number and 'Select on' criterion. As you can see, PAL has 313 lines on the screen. So the mode matcher falls through the whole list until it reaches the last entry.
Our idea was that there should be robust catch-all PAL and NTSC modes, as they are supposedly needed most often. We further assumed that people would like to overlay the robust defaults (mainly for PAL) with more specialized modes that we cannot guarantee to function on the wide variety of monitors. So we sorted some mode presets ('Pre 640x512 PAL', 'Pre 720x548 PAL', 'Pre PAL Auto+VSync', 'Pre 736x548 PAL VSync') to the top of the list, but disabled them. So the user can rely on the default, but additionally select and try these modes using 'Test/Adjust' in order to see if they work for them, and then enable more specialized modes that are to their liking - because when enabled, they match earlier in the list.
-
Yes, screenshots are needed in the documentation!
I need to install a tool that handles the pull down menus asynchronously, so that I can take screenshots from them...
-
Thank you for your suggestions, they are duly noted.
Please prefer the GUI, not the shell method, it's so much easier and less error-prone to flash the Firmware from the Pull-Down menu. Also when you click the "Flash" button in the GUI dialogue, the current configuration is automatically written back after flashing the firmware. When flashing using the commandline tool, a power cycle is likely needed and the configuration still needs to get written back.
You can already save a configuration using the menu item 'Project/Save As...' and load it later using 'Project/Open...'.
You can see the FPGA version in the OSD. For example, select a different Indivision mode and click 'Test/Adjust' to see it.
(Ok, it might be a good idea to produce the OSD always on entering the Test/Adjust screen.)
-
Here are my test results from a BenQ BL702a.
Default settings work with both PAL and HiGfx (1024x768). On HiGfx the screen was off by one pixel to the right. Pressed the Auto Adjust button on the monitor. Then I corrected it by pressing the cursor left key once on the Test/Adjust screen. Then I invoked 'Pick VGA Mode from Display Data', which gave me 'EDID 1280x1024@60', which tested Ok. Then I applied this VGA mode to all Indivision modes.
Finally I tried Test/Adjust on '(Pre PAL Auto+VSync)', which gave "Out of Range" on the monitor. Then I tried Test/Adjust on '(Pre PAL 736x548 PAL VSync)', which tested Ok, so I enabled this mode. For HiGfx (1024x768) I later picked the VGA mode 'Pre 1024x768 60Hz XGA', because it looked better. The highest resolution and an ultra-crisp display in 1:1 pixel resolution I get on PAL SHires Interlaced. But PAL SHires Interlaced has some glitches on my A1200, therefore I selected the 'CCKLine Pull-Up" option in the Advanced Options window, which stops the glitches immediately on this machine. Then I saved the configuration.
So, with a BenQ 702a, I get both: Crisp high resolution Workbench and VSync/50Hz for games and demos.
-
It's more complicated than that.
The flashtool reports its own version, which is not necessarily in sync with the config tool's version.
Also it reports the flash chip's Id and version, this version is currently 1.0. So we have four versions:
- 'IndivisionAGAmk3' config tool: version is currently 1.x
- flashtool: version is also 1.x, similar, but not necessarily the same as the config tool
- FPGA firmware: version is in ISO-date format, e.g. 20200812
- flash: this version is currently always 1.0.
-
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:
-
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:
-
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:
-
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.
-
This here is the right version 1.14 for the Buddha 20years anniversary edition:
-
You can get a command overview with
# flashtool ?
To set the maximum wait time, use
# flashtool maxwait <n> persist
For persisting a setting, the flash must be in unprotected mode (hold right mouse button at power-up)
-
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.
-
The reboot on MAPROM has been removed since version 2.1.
-
Is there a way of obtaining the config from the Indivision without loading the config tool?
There is no such way.
