Posts by nuttie

Weird, maybe it's another bug/defect in my particular Lisa chip (along with the glitching I see whenever I first power the Amiga on from cold when in DblPAL). yay. *sob*...

My Workbench preference settings are (in case it's a particular sub-setting that causes it)...

Pointer:

High res

ScreenMode:

DblPAL: High Res No Flicker, 64 colours.

Overscan:
Current Position : (0 ,20)

Current Szie: 704 x 512

When I open up the overscan preferences tool with these settings active, and move the mouse pointer to the far right of the screen, past the right border and the drag handles, the mouse pointer doubles in height. If I then set the overscan preference to wider than 704 pixels, the same thing then happens on the Workbench screen too.

At present I have my Indi Mk3 running in 1920x1080@50Hz, I tried changing this to different modes, 1920x1080@60, 1280x1024@60, 1024x768@60, 1280x720@50, 1280x720@60 but it did not seem to affect the behaviour in any way.

If anyone else feels like trying to see if this behaviour also happens for them, that would be great. I guess at least then I'd know if it's something to do just with my A1200.

Cheers!

Hiya,

Jens said to write this into a thread on it's own as I found it earlier today and had mentioned it in a different thread, so here goes in case it's worthy of investigation at some point...

I was playing about with the overscan and resolutions on my A1200 which is fitted with an Indivision AGA Mk3 to see if either made any difference to some flickering I was experiencing (it didn't seem to), and I noticed that if I set the overscan to greater than 704 pixels in DblPAL progressive and laced, and then move the pointer sprite to the far right of the screen, the pointer sprite doubles in height. The same also seems to happen in DblNTSC prog and interlaced too. I don't have an analogue multisync monitor to check if the Amiga's normal video out does the same thing.

Hope this is useful, cheers!

Hi,

Just an update, I added extra 10uF 16V, 1206 10% Murata caps (they're quite big for smt and only just fit between the motherboard and the shield!) to both the C2X and C2B, piggy-backing them on top of (or is it underneath? of the existing ones. Unfortunately this doesn't seem to have changed the behaviour for me. I still get the flicker on cold boot if the CCK pull-up is not enabled and then flicker after an hour if the CCK pull-up is turned on. Not to worry, it was worth a try!

Probably not related directly to this but while I was playing about with the overscan and resolutions to see if either made any difference to the flickering (it didn't seem to), I noticed that if I set the overscan to greater than 704 pixels in DblPAL progressive and laced, and then move the pointer sprite to the far right of the screen, the pointer doubles in height. The same seems to happen in DblNTSC prog too. I don't have an analogue multisync monitor to test if Amiga's normal video out to see if that does the same thing. If I find extra stuff like this, would you like me to put it into a different thread to stop the topic from wandering?

Cheers!

Hi Jens,

Thank you for the information and advice, I've been too busy with work to try the extra capacitor but I should have time over the weekend, so I'll report back once I've fitted it and tested things.

Quote from Jens

So if the pull-up/down resistors and CCK capacitor don't work, you need to dig deeper - my first guess would be the VBB capacitor C2X under Lisa (which I'd always top up with another 10µF), but I'd also measure if there's some noise on the 5V line - maybe from the spectrum of the noise, you can deduct what the source is (I'd look for mechanical harddrives, floppy or CD drives first).

When I checked the pcb layout it shows the C2X capacitor to be on the reverse of the motherboard underneath where Alice is located, is that correct one (I'm a little worried I'll put the new one in the wrong place if I don't double check)? Is it better to replace the 330nF at C2X with the 10uF one, or to piggy-back the 10uf on top or to the side of the original? Also, do you think it might it be worth adding an extra capacitor at the C2B location as well? It looks from the schematic that this is the main decoupling cap for the VCC connection to Alice.

I tried to read up on the VBB pin and why it is coupled to ground via a capacitor, so I hopefully could better understand why it helps to add extra capacitance but my web search skills weren't up to the task, does it maintain a reference voltage to part of the chip?

Cheers and sorry for asking more questions, I'm just trying to learn!

My response about my PSU was because it is a CA-PSU from yourselves at Individual. I have two of them, and they've fixed every other issue I was having with both my machines which might have been power related. I was just saying I didn't think my issue could be related to the PSU as it's one of yours, and not a flaky old one, or a wretched MeanWell hack. I'm not daft enough to challenge you on whether Amiga problems are likely power related, I'm pretty certain you know what you're talking about more than I do!

If I had to guess on the cause of my problem it'd be my flaky, nearly 30 years old, Lisa chip. I'm not complaining about it not working how I'd like, I'm actually just reporting it and hoping you guys can somehow work out a fix via the Indivision, to somehow compensate for Commodore's less-than-stellar chip processes and the age of my Amiga.

To be fair to Commodore, I don't suppose they designed their things to last forever, or expected people to be running their graphics chips at 4x-8x the pixel count of a standard TV either but it's fun to push the envelope a bit.

I think a lot of folks like me are pushing the resolution because we don't (yet) have the ability to easily get hold of an RTG card - I don't think I'd even be trying to use DBLPAL or higher if I had one of those. I'm just hoping you manage to release something before the oh-so-stupid-Brexit (please remember about half of us didn't vote for it) finally completes and I have to pay an additional 20% VAT on imports. Whatever the price is, it'll most likely be more than worth it to me though.

I don't think my case can be psu related, at least I'd hope not as the behaviour is the same with both of the Individual CA-PSU's I have.

Hi,

I am also getting same artifacts when my Amiga is first powered from cold. I've been waiting to see if a firmware update might improve things before reporting this but since others are having a similar issue, I thought I'd better report it at the same time.

The glitching on my Amiga starts a few seconds after booting and looks exactley the same as it does in the pictures provided by wolfa. If I activate the CCKLine pull-up they disappear completely but once the Amiga has been running for an hour or so the glitching starts again, and then I have to deactivate the CCKLine pull-up to stop them - after that the Amiga behaves fine all day. Activating the CCKLine capacitance does not seem to improve the glitching, and causes occasional pixel mis-read on my Amiga if active, so I leave that switched off. Changing the PCLK setting doesn't seem to make any difference to the glitching at all.

I know this isn't the Mk3's fault, it's my Amiga that's causing the issue, and it mostly only happens in DPLPAL mode or higher on my Amiga. I've tested all firmwares and indivision tool versions up to and lncluding the v1.6. and so far whilst none have made things any worse, they haven't completely removed the issue either.

My Amiga is a 1d4 A1200 with a CA-PSU, and a I believe its got a CBM Lisa in it, in case that helps.

Just out of interest may I ask what you folks at Individual suspect is the likely cause of these glitches? Is it likely the phase or duty cycle of the CCK shifting over time and getting out step compared to another clock line, or is likely just the Amiga's CCK signal is a noisy mess, and the Mk3 has trouble locking onto it?

Cheers!

No worries, I'll do my best to be of help, apologies in advance if I get something wrong! All of this is definitely in the original post I linked to in the German section of the forum, I can really recommend just checking with that, (via Google Translate if you need to of course), in case I missed something.

I believe what you need to do is the following:

In your WHDLoad.prefs file, remove the semi-colons from the start of the following lines, changing...

...to...

...and then WHDLoad should run those script files each time a game is started up and shutdown.

The NoNetwork line that you've uncommented doesn't stop the Amiga's network, I don't think, I believe it just stops WHDLoad from doing a network check to see if the game you are trying to load has an updated loader:

I think it's safe to put the semi-colon back in front this to disable it again, it won't stop you from stopping the network connection while a game runs, and WHDLoad will kindly tell you if there's a new loader before shutting the network down, so you can go and grab it from the WHDLoad website if you want to.

Also, I don't think these two lines matter, almost any of the time. I guess the NoAutoVec might in certain circumstances but the PAL one will probably just crash any NTSC games that rely on any specific timings. Unless you have a particular problem, I'd re-insert the semi-colons in front of them and disable them until you know you need them...

Next, you need to change the following line in your WHDLoad-Startup from...

...to...

...in order to tell AmiTCP to shut down the connection on your x-surf-500-plus, (just to double check... this is the device you have installed and are trying to disable, right?). The zero is just the unit number of that type of device in case you have more than one connected (but I don't believe you can for an x-surf-500-plus). People who have a different type of network device, they have to change this to match whatever device they have, and also have set it up previously in AmiTCP but for you, it should already be done by iComp's installer.

Lastly you need to change the following line in your WHDLoad-Cleanup from...

...to...

...so that it starts your x-surf-500-plus device back up again after the game is shutdown.

If this is all working okay, you might well have a window pop open when a game starts or shuts down that says something like "AmiTCP is put offline", and "AmiTCP is put back online" - I can't remember the exact wording but it pops up whenever I run a game on my ACA500+ machine.

Hope this helps and isn't too full of errors, let me know how you get on.

Happy trails!

Hehe, you're Google skills are no match for the dark side!

How okay are you with AmigaDOS scripts and running stuff form the command line (cli)? I'm a bit rusty still after so many years of using Windows and Linux but it's not too hard to figure out usually...

So I believe it's trying to tell you that one of the commands you enabled (or added) in the file that's being run at ExectueStartup (which will be the WHDLoad-Startup file by default, unless you changed it to something else?), is returning a code 10 and an error of 0. So the good news is: It sounds like the WHDLoad.prefs file is okay, and is trying to run the startup script, and it's just something in the WHDLoad-Startup file itself which is not quite right.

You can figure out which command it is by opening a CLI and entering the commands in the file until one of them throws an error - it will almost certainly be something on one of the lines which you have changed, and so you should be able to ignore any lines in the file which you haven't modified.

If you copy the contents of the WHDLoad-Startup file on here, I'll try and take a look but I probably don't have quite the same setup as you, so I might not be able to see anything, (no promises of an insta-fix!). It's probably just a path to a command that's not quite right or a typo, so don't get stressed - it'll be really obvious once we figure it out and fix it. Then you'll know what it is and won't have to deal with it ever again. Considering how old AmigaOS is, it is suprisingly robust and capable of dealing with expansions and addon hardware. Windows and Linux have 1000s of times more resource and people working on them and are still a dogs dinner even now.

This is not something I'd personally expect Jens or anyone at iComp to sort out for us, because we're using a completely unrelated peice of software (WHDLoad), to load games (of at best questionable source), from a place most were never supposed to run (a harddrive). Even if they had an army of suport people answering such questions, the universe would end before they sorted them all out.

I found the original post in the German part of the forum...

X-Surf 500 und whdload Probleme

Evening mate,

That's normal. The hardware/drivers for ethernet generate interrupts which can mess with WHDLoad I think, it's the same if you use a USB ethernet adapter too. Some games will work fine but a lot will freeze or crash if the ethernet is left enabled.

The WHDLoad-Startup and WHDLoad-Cleanup files (which are in your S: directory) have lines in them to stop and restart ethernet, you just need to edit the files and enable the commands in them by removing the semi-colons at the start of the line, and then edit your WHDLoad.prefs file to enable WHDLoad to run the WHDLoad-Startup and WHDLoad-Cleanup files each time any game is loaded, which you can aso do by just removing the semi-colon in front of the lines in that file.

If you unsure how to do that, just do a search on Google or read the WHDLoad docs, it's all in there I think - at least that's how I figured out how to do it. There is also a post in the German part of this forum on how to do it which is quite detailed, just use Google Translate it if you don't speak German

Hope that helps a little.

Hi,

Thanks very much for the core update, please may I ask what kinds of changes/improvements you have made, what differences you might expect us to see, and if there is anything in particular you'd like us to test?

I've just flashed the new firmware and after a reboot all seems fine so far.

I've just sat through Phenomena's Enigma demo, Anarchy's Hardcore, and LSD's Jesus on E's (in full, I now have a headache - I can't believe I used to go to raves every weekend!), all runnng from HDD via WHDLoad.

Enigma seems to run 100% fine, with no display or audio dropouts at all.

Hardcore seemed to run 100% fine also.

Jesus on E's runs fine until the last bit of the demo (which I think is the credits?). I didn't see any screen blackouts, or audio dropouts during the main demo part which lasts 30 or so mins. I did see a couple of times when the animations messed up a little but I think was just timings from running on a 030 at 50MHz and the HDD, the little fist logo in the bottom right corner never blinked out at all, nor did the TV lose sync. At the very end of the demo, when a different. non-rave audio track starts, then the screen stayed black but the music was faultless and didn't stutter, and my HDTV didn't report a loss of signal or anything.

For info purposes, my A1200 is a 1d4, recently recapped but with no timing fixes yet, powered by a CA-PSU from IComp. The Indivision AGA Mk3 is set to output 1920x1080@50Hz but with the VSync and Auto-Res both off, as either or both cause my display to fail to detect a signal. Audio is set to 96kHz, and only the CCKPull up resistance is active. It is connected to an HDTV via digital, and I am using the v1.5 Indivision tool.

The ACA1233n is set to 55MHz, pio mode 4+, vbr on and maprom off via the ACATool v2.4. MuFastROM and MuFastZero from the MMULib tools are running via the UserStartup. I don't know if this is optimal at all, it's just what it's set to at the moment in case it matters.

I can try the demos too if it helps, as I also have a 1233n. Which specific versions of which demos do you need testing out?

I've managed to recreate the yellow screen with the help of the scummVM 030 1.5.0 from Aminet and the Discworld 2 game, which bombs out scummVM and the Amiga when I try to launch the game. The error is intermittent but repeatable. Is it possible it's just a fail in the MMULib? I haven't so far seen a RAM error when I run the memory scan in Amiga Test Kit but I am leaving it runnning for a while again to try and check.

Thanks for replying and for the advice - so far today the Amiga has been stable apart from some minor gfx glitches. I think I need more data to be at all confident about what's going on, so I'll keep things as they are for the next few days and just monitor, unless something horrible starts to happen again.

I've just realised that I did change additional things yesterday, after the boot failures happened. I tried removing MAPROM and VBRON from the acatool startup script, and re-ran the MMUlib installer which put MuFastRom and MuFastZero into the User-Startup - I'm wondering if I might have had both the ACATool and the MMULib both active previously, if that might cause the lack of stability? I understand conceptually how MMUs work but I'm not really sure how best to setup the software for one on an Amiga as it's not something I've had to do before. I know MMULib is not your software but do you know if any sort of idiot-proof guide exists to set it up along with an ACA1233n, sort of an "out of the box"?

As the Amiga has been stable all day, I've been trying out more games on floppy versus HDD to see if I could find anything new with the experimental audio feature - There's definitely improvements to audio when some games are run from floppy instead of via WHDLoad. I do think there's a significant difference, though I don't know what it is. Not all games have better audio when loaded form floppy but I've not yet found any that are worse.

In each case where the audio is improved but not perfect, there do not seem to be any individual missing notes, or parts of a sample. The audio runs continuously until a boundary event, such as a fade out between levels, or a title screen and in the games where the audio returns after a fail, it almost always does so (apart from in Megalomania) at another boundary such as the next level or the game over screen. It made me wonder if it was a specifc type of event being missed like a global volume change or similar.

It's a bit beyond my skills to trace exactly what is going on but if someone who's good with a debug monitor and/or an oscillascope takes a look to see what's different between the two versions, might there be a single fix possible for a lot of titles?

Anyhow, I hope some of this is useful to someone, and thanks again for all your help.

Cheers and have a great weekend!

Evening All,

I had time to investigate a few things further this week - I've spent the last few days trying to stabilise my A1200 with a new ACA1233n in place of my ACA1221lc, and have discovered a couple of things along the way which might be of use to others.

The first is related to the to the Mk3 audio....

When I was testing the games last week, I forgot to mention I was loading them from HDD via WHDLoad. The games I found to have partial audio with only 2 working channel, such as Dune, Another World, Frontier, Indy Jones 4 etc. all still behave the same when launched from the HDD, regardless of which accelerator is installed or if the MMU is active on the ACA1233n, as you'd expect. However, if they are launched from floppy/gotek, the audio works fully and properly. I know this is not a massive revelation but it is curious as I doubt the games will have had their audio routines re-written massively to run from HDD, so maybe they are just running from a different place in memory? I know this is nothing concrete but I thought maybe it might help with any investigations.

Next, the new accelerator card (or something I did when I fitted it) appears to have changed the behaviour of the previously mentioned on-screen multi-pixel and line corruption, and also the flickering palette colours – all have disappeared which is great but… now I have a glitching mouse pointer – and this is a really weird one because it’s not just flickering or corrupting graphically – it’s actually jumpy across the screen – always to the left, and if I am clicking an icon when it happens it drops the icon on the left of the screen too when the mouse moves, as if the OS thinks the mouse pointer is travelling 600+ pixels in a single step.

This new glitching only happens during the first few minutes after the Amiga is switched on from a cold boot, and it only seems to happen when I move the mouse. It will jump across the screen to the far left and then return to where it was, as I move the mouse pixel by pixel – it’s not on a timer, and doesn’t snap back if I keep the mouse still and wait. It’s as if the move causes the OS to read the mouse position and it gets zeroed by a bad read and then I move it again and it reads good and returns to where it was. Has anyone seen that behaviour before?

I ran the Amiga Test Kit's memory scan a few times (it takes a while with ~130MB of RAM), but it didn't find anything so far. I also totally flattened the HDD and reinstalled OS 3.1.4, ACATool, the MMULib etc. from scratch yesterday thinking it had to be software related somehow but it still happened again this morning for about the first 5 minutes after I switched the Amiga on.

The machine also locked up about 5-10 minutes into use this morning, and then failed to boot after that when power cycled. I turned it off, counted to 15, turned it back on, the ca-psu LED was green, the Indivision logo popped up on-screen, the Amiga power LED lit up, and the floppy emulator’s LED screen came on but no drive click, no HDD/FDD activity LED, just a black screen on both the digital and the analogue video out. I tried again, and the same thing occurred. On the third attempt the screen came up yellow (CPU error?), and I was like - woah, so I left it for 1-2 minutes... and then, on the fourth attempt it booted normally and has been fine all day since, including several power cycles, with no on-screen glitching, or software crashes, nothing bad at all, it has worked perfectly all day since - and I've been hammering it, re-installing a whole bunch of WHDLoad LHA archives, playing games and listening to music.

Something similar happened yesterday also, so I tried re-seating the accelerator card and the Indivision before I tried rebuilding the software. I will try again in the morning, once the Amiga has had a nice night’s rest and see if the pattern repeats. I will also try cleaning the edge connector again tomorrow, and will check if those pesky E123C and E125C are still in place underneath (and remove them if they are) – as I didn’t get chance to check that in the week, I was too keen to try out the new accelerator – which is awesome once I can get the darned Amiga to switch on!

Any ideas what else I might try, or if the E123C E1235C fix might help? I don’t think the problem is mechanical, like a loose connector or anything, I think it must be either thermal and/or electrical but I’m obviously not an expert like you folks are, and I haven’t seen enough wobbly Amigas to know if this is common. Any advice or ideas you might have would be very welcome, your educated guess will be far more likely to work than my attempts.

Thanks very much in advance!

No problem, thank you for looking. The problem was intermitent and has not happened for the last day or so - I will try to give better details to recreate it if it happens again. Maybe it was related to a setting leftover in flash from the previous firmware version or something.

Hi,

In case it's useful for comparison purposes, I plugged a Pi4 in to capture the EDID block from one of the HDTVs, and got it to report what it thinks the HDTVs capabilities were, and what mode it thought it was in. I also put the EDID capture through parse-edid and edid-decode on my PC. I've attached the captured EDID data block and the parse logs from the Pi and PC so you can see the details.

The information from the Pi seems to indicate that I've got my manual 50Hz settings correct, as they're identical to those the Pi is saying it is outputting. In theory I think the VSync/Auto-resolution/both should work but for some reason they don't seem to. The EDID info also indicates that the HDTV can handle a wider set of audio bitrates than seems to work from the Indivision too - I'm not sure if the command is giving the audio bitrate per channel or for the audio stream as a whole but it seems to suggest 44.1kHz or 88.2kHz streams should work and they don't, only the 96kHz setting produces any actual sound from the HDTV. It also says something about supporting over and under scan and I'm wondering if this could be related to the scaling I'm seeing in non-DVI mode maybe? I don't seem to have a way of changing the setting to see if it produces the same effect I see on the Indivision in non-DVI mode. I can't quite work out why things are working differently for the Indivision compared to the Pi apart from that as the settings all looks the same.

Hopefully this is not completely useless info but apologies if it is. The EDID parse commands on my PC did give some proper front porch, sync, back porch numbers that I can enter into the Indivision and work nicely at 50Hz though, so quite a useful exercise!

After some more experimentation, here are some pictures I managed to capture of the on-screen flickering in case it helps anyone else.

So on this occasion today, turning off the CCKLine pull up cleared the interference, which is the exact opposite of what normally happens. It didn’t seem to matter whether the PCLK was off, set to pull-up or pull-down... There is no pattern to this I can see other than switch on the Amiga, and when the flickering starts, toggle CCKLine mode from whatever it was to the opposite, and the problem goes away. Is it likely that my Amiga 1200 is just a steaming pile of 30 year old failure? I honestly don't know how you guys mange to design such reliable (and your stuff is very reliable) expansions for these temperamental $*%& machines! I have just one and it’s driving me nuts.