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.
That's an interesting one - VLSI! This may be the cause of the whole trouble, as the phase shift of the output Pixel clock of this Lisa may be totally different than the three other versions that I know of.
I need to dig through my stock of A1200 boards to see if I even have one of these. It might enable us to reproduce the problem and find a fix.
If you could do noe more test and switch off the PCLK pull-up resistor? That should at least change the behaviour.
That's an interesting one - VLSI! This may be the cause of the whole trouble, as the phase shift of the output Pixel clock of this Lisa may be totally different than the three other versions that I know of.
I need to dig through my stock of A1200 boards to see if I even have one of these. It might enable us to reproduce the problem and find a fix.
If you could do noe more test and switch off the PCLK pull-up resistor? That should at least change the behaviour.
Jens I tried with and without "PCLK pull-up resistor" option and didn't notice any obvious changes while in standard PAL mode. Normally I do use "PCLK pull-up resistor" as I get occasional horizontal noise while in "DblPAL high res no flicker" mode if it isn't checked.
I was trying out recording the MK3 HDMI output on my Mac with Quicktime and a Cam Link 4K HDMI capture device.
When I first tried this the audio didn't work. I had set up an 48 kHz sampling rate on the Indivision and Quicktime also showed 48 kHz. But there were just a few blips every second or so. But on my HDMI monitors for the most part the HDMI audio worked great. (I had some weird effects in NTSC or when changing screen modes during playback.)
Just now I tried different sampling rates, and what do you know: at 96 kHz it works just fine. Even though Quicktime still reports 48 kHz.
So get ready for some super high quality long play videos, Youtube! (Well, not really, as I'm a terrible gamer.)
Jens I've uploaded some videos:
Also I've removed E123C and E125C caps as they were present - this made no difference.
As for Workbench, I still need to use either "PCLK pull-up resistor" or "PCLK capacitance" to remove horizontal workbench glitches. The options chosen makes no difference while running the Enigma demo, before or after capacitor removal.
It's a ferrite bead, size 0603, part number BLM18PG121SN1D. This is a MuRata number, but you can use pretty much any other chip inductor with similar data. There's not much current flowing through it, so the rated current of 2A can be reduced. The 120R at 100MHz is a "good rule of thumb", and the unit passed CE with it, so I didn't bother to look for anything else
Just wanted to report back that my Indie is now working well. Thanks again 
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.
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.
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.)
Is this issue being addressed in the background please?
Yes, we have a core that addresses timing shifts caused by accelerators, and there's some bug fixes in the config tool being tested. Some more testing to be done, as "XTREME" modes appear to trigger a bug when switching back to standard PAL resolution. Whatever the state of that bug is, we'll publish something before the weekend.
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.
I remember seeing a note in the internal changelog that this bug is already fixed (SHires and interlace bits were swapped),
👍🏻
Yes, we have a core that addresses timing shifts caused by accelerators, and there's some bug fixes in the config tool being tested. Some more testing to be done, as "XTREME" modes appear to trigger a bug when switching back to standard PAL resolution. Whatever the state of that bug is, we'll publish something before the weekend.
Config tool V1.6 available for download in the Wiki. This one addresses the timing problems and a number of small bugs of the config tool itself. Please test and report back!
Config tool V1.6 available for download in the Wiki. This one addresses the timing problems and a number of small bugs of the config tool itself. Please test and report back!
I have flashed to the latest V1.6 and am happy to say that the problems I had before (wrong detection of SHires modes while in PAL or NTSC) are gone now. Also no more bumps in the picture. OK, time will tell if there is eventually any problem in some game or demo but from what I have seen so far, all is good. Seems that after V1.6, my Indivision works happy with my Blizard 1230 IV. Great work so far, thank you.
Config tool V1.6 available for download in the Wiki. This one addresses the timing problems and a number of small bugs of the config tool itself. Please test and report back!
Boom! All issues appear to be gone!
Great work iComp team 
Config tool V1.6 available for download in the Wiki. This one addresses the timing problems and a number of small bugs of the config tool itself. Please test and report back!
On my 1d1 board it works perfect. Didnt test it on my 1d4 since i dont like to swap hardware to much on 30 year als hardware..
Works great! Until 1.5 I had issues with flickering pixels/lines. All magically disappeared with 1.6!
Four positive reports in a row, thanks a lot. That makes me confident that we've finally found the root cause of the temperature-related timing problems. So we can now turn the more cosmetic things, such as the yellow vertical line at the far right of the screen...
worst:
- i thing there is a "copy error" with creating rescue disk in 1.7.1
tested 3 times good diskietes and after boot got this error flashtool - file is not executable
after manual copy files from IndiMk3 dir all works fine.
- another problem 171 dont always save a configuration to device (scalines for examples) - 16 all ok
better:
- yellow vertical line at the far right of the screen - fixed
The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.
