Posts by fnord

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.

    I believe I have solved the problem for me now.

    I tried the palette-trick that nuttie suggested, but that did not change anything. Also, E137R already was a ferrite bead on my board, so I left that unchanged (didn't try to short it, though). So my problem seems to have had a different cause.

    I added a heatsink to Alice, but that did not seem to have much impact - but it probably can't hurt either, so I left it on there.

    Now for the bit that really helped:

    Since I had trouble with enabled pullup on a cold system and without pullup when it had been on for a while, I tried to use a weaker pullup, hoping to find a compromise that would work in both situations. And - to my surprise, tbh - this seems to do the trick.

    My current configuration on the 2B board is:

    ==> XR358: 10k <==

    MK3's pullup/capacitance: always off

    C2X: 33nF+10µF

    I have not been able to reproduce the graphics glitches since. Yay! \o/

    If you have a burst access or in case of the Amiga a dual-cas access, multiple sequential accesses happen within the same machine cycle. For these accesses the A0 changes twice as fast compared to the other address lines. Maybe Commodore engineers decided it could do with a little help because either it is too slow at double the frequency or it has some under/overshoot that is suppressed by the pull-up. My guess is on the "get it faster" reason as often digital pins can pull to ground more strongly compared to driving high. And so a pull-up helps with shortening the rise time (A0 need to rise for the second half of a dual-cas access).

    I see, that makes sense. Thank you!

    I am not sure if the hardware change also mentioned in the link is a good solution, or even if shorting the resistor E127R would be safe to try, so I would appreciate knowing what you guys think, you know a lot more than me about it than I do.

    What would that accomplish? Turn off the low-pass filter on CCK?

    If so, I think it would not damage anything, but seeing that CCK is already a rather dirty signal, it might introduce more instability if you're unlucky. Please don't take my word for it though - I'm a total noob at this. I'd like to hear the experts' opinion, too. :-)

    After a bit of experimenting, I seem to have found the best configuration possible with this board.

    I added the extra 10µF to C2X but removed the pullups from XR358 and DRA0* again. Now I still get glitches, but they are not as frequent and not bad as before. With the MK3's pullup and capacitance disabled, the system is stable until Alice hits approx. 50°C. After that, a little bit of glitching appears. Turning on the pullup fixes this, but keeping it on will cause glitching when Alice is cold. So I think I have two options left to try:

    1. With a bit of luck, a heatsink for Alice will allow me to keep the MK3's pullup off at all time.

    2. If that fails, it should not be too difficult to build a little circuit that measures Alice's temperature and turns on a pullup on CCK when it gets too warm. (Maybe I could just use a thermistor as pullup if I find one with a suitable characterisic? This feels wrong, but it might just work. Maybe worth a try.)

    * can someone explain to me why it would make sense to add a pullup to only one of the address lines?

    ...but did not report the one interesting thing: Are the GFX glitches gone?

    Unfortunately not. Bear in mind though, that the additional 10µF on C2X is still missing.

    The behaviour changed a bit, though. On startup, glitches are present with or without the additional pullup of the MK3, but without it they are a bit worse. Capacitance crashes the system.

    After the system has been on for a while, the glitches seem to be completely gone when the additional pullup is off. Enabling it introduces a slight glitching again. (Before adding the 470R it was the other way around.)
    Turning on the capacitance now does not crash the system anymore, but apparently shifts the whole picture one pixel to the left! I have a hunch that this might be a bad thing. Is someone (Lisa?) recognizing the clock signal too early or too late in one of the two cases?

    Enabling the capacitance now also reduces (but not completely eliminates) the glitches that appear when the additional pullup is on, but that might be less relevant than the pixel-shifting thing.

    CCK is not a nice signal in any Amiga, that's right. However, the bad over/undershoot that you're showing here rings the "probe adjustment bad" or maybe "GND connection bad"-bell.

    Your scope has a square wave output that you can use to adjust the probe - turn the little potentiometer of the probe until you see a true square wave - that's the first thing anyone MUST do on a new scope. Only after that you will be able to get meaningful data from any reading. Look for "Probe comp"- that's what the output is labelled on Agilent scopes.

    Good point - I had not checked this in a while. Using the calibration squarewave of the scope, the probe does look fine, in 1x as well as in 10x mode, but this is at a vastly different time scale. At 100ns scale, I can barely make out the gradient in the signal. :-/


    Well, it's a rather cheap scope (the popular Rigol DS1054Z). So I guess maybe the calibration is worthless for higher frequencies? I don't know. As you can see, I'm just making my first steps into the analog world behind the comfy digital one. I also learned just now that 10x mode gives you a higher bandwidth compared to 1x mode. (That didn't change that much about the signals though.)

    Btw, thank you for taking the time to help me debug this!

    Well, this keeps being interesting.

    I added a 1k Pullup to DRA0 als you suggested.



    Not sure if this is an improvement; the signal looked more square-y before, but the amplitude might have been a bit low. This seems to be the case with the other address lines, too, though.

    Unfortunately, I didn't measure CCK before putting the 470R on, but this is how it looks afterwards:

    Not that good, is it? Is it supposed to look like this?

    The difference with the added pullup from MK3 is visible but small:

    With pullup+cap from MK3:

    turning on the capacitance still crashes the system, even though the signal does not really look worse to me.

    Now I'm curious; I think I'll temporarily remove the 470R again, to see how the signal looks without it.

    No, the pull-up resistor on DRA0 is XR358.

    Huh, are you sure about that? claims that XR358 is connected to CCK, which is consistent with the schematic I found on

    As far as I can see, the only resistor directly connected to DRA_0 is R151J, which is not a pullup, though.

    Am I missing something?

    Revised plan:

    - Replace XR358 with 470R

    - Wait for 1206 ceramic 10µF to arrive in the mail

    There's a pull-up resistor on the DRAM-A0 line of every AGA chipset, which might be worth looking at.

    Do you mean R151* ?
    I checked R151A-J and all are present and 68 Ohm.

    Some more observations about my 2B board:

    It looks like some prior owner has removed XR358. (Is this the one that the Indivision AGA MK3 can optionally add?) Commodore's schematics say this should be a 470 Ohm resistor; some forum posts suggest that 1k might be better, though. (…hreads/39474/#post-656938 )

    I had removed E123C and E125C when I recapped the board, since it is generally suggested to do so. But today I found a forum post by you that suggests that putting one of these back in might be a good idea:…23088/page-85#post-423129

    So, the current status is:

    R151A-J: all present; 68 Ohm

    E121R: 27 Ohm


    E122R: 27 Ohm

    E122C: -

    E123R: 27 Ohm


    E125R: 27 Ohm

    E125C: -

    XR358: -

    C2X: 0.33 µF

    The current plan is:
    - Add 10µF in parallel to C2X

    - Add XR358 with 1k

    Should I also do something about E12*C ?

    So, after a bit of tinkering with my A500, I'm now back to the 1200, and the problems are unfortunately not quite gone yet.

    I tested the Indivision AGA MK 3 with my 1D4 board again (now with the CA-PSU), and here the behaviour is slightly different than on the 2B board.

    For the first 1-3 minutes, graphics glitches appear when CCK pullup and capacitance are off, but when I turn both on, everything looks fine. After a short while, glitches start to appear again - now turning pullup and capacitance off again helps.

    So it looks like maybe there's some temperature-related stuff going on?

    Back on the 2B Board, pullup and capacitance seem to work fine directly after power-up, but the system constantly crashes when it has been on for a few minutes. Turning capacitance off fixes the crashes. (I have to leave the Amiga off for a few minutes so it is stable for long enough to start the config tool.)

    When the system has been powered on for a while, CCK-pullup on and CCK-cap off seems to be a stable setting for this board.

    I'm sorry if my reports appear to be partially contradictory or erratic. I'm also getting quite frustrated by this.

    If you have any more ideas, I'd be grateful.

    I did indeed send my multimeter to the manufacturer for recalibration (below 0.2% in the relevant voltage range), but that was 3 or 4 years ago, so I don't know if that's still worth anything.

    The Amiga has now been on for about an hour and now I'm measuring 5.053V.

    If you're not concerned, I'm neither; I just wanted to make sure it's fine.

    Okay, so my CA-PSU arrived today.

    With the CCK pullup disabled, the problem still occurs, but I haven't been able to reproduce it with the pullup enabled until now, so that's a good sign. The CCK capacitance still locks up the machine, though. (I guess I'll just leave that option off, then. *shrug*)

    I saw your Revision 2020 talk by the way, and found it really interesting.

    Your solution to the prohibitively-expensive-certification problem is rather neat, I think.

    Just out of curiosity, I did some measurements with the power supplies that I have here. All measurements were made when the system was idle, after booting to Workbench. I did not test for different loads, so the results are probably of limited value, but here they are anyway:

    1. PSU Model Voltages[V] Ripple/Noise[mv]
    2. 1 A500 old 5.069 -12.20 12.06 45 48 54
    3. 2 A1200 old 4.989 -12.20 11.84 41 47 78
    4. 3 A1200 new 4.983 -11.65 12.75 62 70 54
    5. 4 Keelogg 4.840 -13.41 12.78 34 57 57
    6. 5 CA-PSU 5.078 -11.94 12.01 42 53 67

    The Keelogg PSU seems to be the worst of the bunch, which is kind of disappointing (but no surprise anymore, at this point).

    It's not only far too low on the 5V line but also exceeds the spec on the -12V line by -210mV, which is a bit unsettling.

    The original Amiga PSUs seem to hold up well for their age (except for the noise on #3). This is of course only for an "idling" load, so they will probably be worse under full load. Under full load, the 5.069V of #1 will probably drop below 5.05V so that would be fine (as long as it does not go below 4.95, which it might...)

    In your Revision 2020 talk, you show that the CA-PSU does not exhibit the usual linear voltage drop with increasing load, which is really nice. But that would mean that the 5.078V that I measured would stay outside the 1% spec, right? Should I be worried about that?

    I never said you could cherry-pick your specs. I work in the optics industry and have had way more discussions about specs and how to interpret them than I care to remember. It goes without saying that all given specs have to be met at the same time. (Unless explicitly noted otherwise, of course.)

    But apparently, the words "initial setting" seem to lead some people to believe that it is just an initial setting, as opposed to a spec that has to be met at all times whenever a nominal load is present.

    Thank you for the clarification.

    I'm looking forward to watching your talk "Designing a better Amiga power supply".

    However, you are making the same mistake as all those amateur-type tinker-PSU vendors who are only looking at the paragraph you're showing. Look a little further, point 2.3.5, "initial setting": The PSU is to be loaded with nominal load (aka "full amperage") and then adjusted to a range between 4.95V and 5.05V - this is 1% precision at full load, and this is what breaks the neck of pretty much any PSU at higher loads.

    Ah, I see; thank you for explaining.

    Let me try to recap to see if I understand it correctly now.

    I had assumed that the worst case regulation specifies what the Amiga must be able to handle under any circumstances (I still think that, but it needs clarification; see below), and the initial setting only describes the optimal setting that is to be calibrated at the factory (but is allowed to get slightly worse over time).

    But that's only half the truth. In reality, the actual current draw (and as a result, also the voltage) obviously varies depending on what the Amiga is currently doing, plus factors like ripple, noise, temperature, etc.. The crucial point that I was missing is: Calibrating the "initial setting" correctly is necessary to ensure that the actual values, (including high frequency noise, ripple and whatnot) never leave the worst case window.

    In addition to that, using 3.3V regulators that need at least 4.85V input voltage at all time effectively tightens this window from Commodore's original 5V +/-5% tolerance down to 5V -3%/+5%.

    Did I get that right?

    Okay, here's a quick update on the situation.

    I have measured the voltages with some of my PSUs and the Keelog is, disappointingly, indeed not that great. While it does stay within the official specifications (+/- 5% for 5V and +/- 10% for +/- 12V), it gets dangerously low on the 5V line (between 4.8 and 4.9), which is probably fine for an unmodified Amiga but not so great if you have any modern extensions. I haven't measured the ripple yet, but I'll let you know how that turns out.

    I am currently using one of my original Amiga PSUs, and interestingly, with the CCK pullup enabled, the graphics glitches are still quite bad for the first minute or so after I power on the machine when it had been off for a while - but after 2 minutes they are completely gone.

    My CA-PSU should arrive tomorrow, so I'm curious to see if that'll improve matters further.

    Just to make sure - the points indicated in the picture are the ones that you recommend for measuring the voltage/ripple, right?

    Hi Jens,

    thanks for the quick reply!

    Good to know that the temperature is not critical. It will certainly increase once I close the case, but probably not up to 80°C.

    Okay, so maybe I just didn't have enough patience for the problem to appear without the Indivision. I will try that again just to make sure. If I understand you correctly, this could also happen on a stock Amiga without any extensions?

    While the CCK pullup shows some improvement, activating the CCK capacitor instantly locks up the Amiga.

    Bummer about the PSU - I really tried to get a good one, but didn't know about your PSU FAQ.

    This one even has a voltage display, and it actually does show different values depending on what is connected:

    5.05V/12.0V/-11.9V with nothing connected

    5.05V/12.6V/-12.7V with the naked 1D4 board

    5.05V/13.0V/-13.2V with the 2B and all the peripherals

    So it seems it does compensate in some way. Suspicious, however, that it compensates the -12V line about as much as the +12V line although the former should have much less load on it than the latter, right? I think I'll try to measure the actual voltages in the Amiga on the weekend.


    I recently received my Indivision AGA MK3, along with an ACA1221lc. Installation went smooth, and at first, everything seemed fine. But I soon noticed a stability issue that manifests in graphics errors (see attached image) and occasional crashes.

    First, a few words about my setup:

    - Amiga 1200 Rev. 2B, recently recapped, with timing fix (E123C and E125C removed; E121C and E122C weren't present in the first place).

    - Indivision AGA MK3

    - ACA1221lc

    - iComp RTC module, installed on the mainboard (not on the ACA1221lc)

    - Internal floppy, external floppy, and external Gotek

    - IDE-CF adapter with 4GB Transcend CF card

    - Allnet ALL0142+ PCMCIA Network card

    - An old Blaupunkt flat TV

    I am using the SuperHighRes Interlaced (1280x512) mode via the digital output. I created two 1920x1080 VGA modes (normal and shres) and disabled all presets in the Indivision configuration tool, so it would always choose one of these two.

    I first noticed problems when I was copying a backup of my Workbench partition to my network drive. I suspected the ACA121lc, so I removed it and tried again, but after a few minutes the problem was back. I then removed the Indivision and tried again. SuperHighRes Interlaced is almost unbearable via SCART, but now the errors did not occur. (With the Indivision present, the same errors were visible over SCART too.)

    I tried this with another mainboard (1.4D, also recently recapped and no timing fix necessary since the offending capacitors had apparently never been populated in the first place) but that did not change anything. I also tried different power supplies: An old heavy A500 power supply, the much lighter black power supply that came with the A1200, and a new Keelog Amiga power supply. This did not seem to make any difference either. What did have a slight effect though was activating the CCKLine Pull-Up in the advanced settings. The graphics errors did not vanish completely but were noticeably reduced.

    I also noticed that the Indivision gets rather hot. Not sure if that is normal or cause for concern.

    I could not (yet?) reproduce the problem in normal HiRes (640x256) mode. I should also note that the problem does not always occur reliably, but it seems that system load (i.E. copying lots of files over the network) increases the likelyhood.

    Any ideas what the cause could be and what I could do to fix this? Please let me know if you need further information and/or measurements. (I have a multimeter and an oscilloscope if that helps, but I would need instructions on what to measure.)