PIV SD64 P96 v3.0 gfx and/or gfx swap memory being overwritten?

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.
  • Hello, a4000t csppc060 PicassoIV p96 v3.0 and a4000cr desktop csmk2 060 3.9 PiccoloSD64 p96 v3.0 On both systems the p96 V3.0 release may introduce gfx artifacts, which can be described as a static 'snow' or 'star' pattern, ontop previously opened p96 screens. In the case of the SD64 equipped system, this issue has been seen on the screen opened by the system commodity blanker as well. In any event, the gfx areas being trashed with the dots will be restored, when apps, windows and screens are being refreshed. In the case of the blanker, the blanker animation will eventually refresh and restore all of the black blanker background. I have not yet found a way to reproduce this reliably, and on each system the operations needed seems different. No crashes or software failures has happened in ralation to this issue. Prior to V3.0 this issue has not been seen on either system. best regards -gandalf

  • This appears more like a hardware problem, as the Cirrus-control part did not change with P96 V3.0. Only screen dragging has been added.

    Please try to reduce the pixel clock - this might be caused by memory speeds being exceeded. Note that it may either be the Cirrus chip that can't deal with the pixel clock you're requesting (add a heat sink, check power supply ripple), or that the memory chips have aged: Yes, memory chips are prone to ageing, and the one thing that changes is the access speed. Since you did not mention the output screen mode that you're using, I can only guess, but especially your description of "pixeled areas get properly restored when parts of the screen are refreshed" is a clear indication for a hardware problem.

  • My thoroughly edited reply seems to have been a victim for the forum login timeout, so here is the short version.

    I will re-test and return with more information, reproduceable if possible.

    best regards


  • My thoroughly edited reply seems to have been a victim for the forum login timeout,

    The forum software usually makes backups of previous edits and restores them for you if you log in next time - a really nice convenience feature of this forum software which I am probably not the only one to having taken advantage of.

    What happened here is that we had to reboot the server - not just the VM, but the "mother ship" that runs all the VMs for Wiki, Forum, shop system and mail server. The reboot took over 20 minutes - sorry for the inconvenience caused.

  • V3.01 of P96 has improved memory handling on the P-IV hardware. In detail, if the P-IV requires board memory for the flicker fixer, this will now throw other screens off-board to ensure that there is sufficient memory available for the native screen(s). This may or may not be related to what you're reporting here.

  • Thank you for your responses and latest update. Here is my promised followup.

    P96 display modes, mostly 1024x768 8bit and 16bit, and with the PicassoIV also 1280x1024 8bit for wb and the native Pal through the PIV FF for a few applications.
    Never used overclocking with my computers or gfx cards.
    P96 display databases deleted and set up anew, now using lowest taxing default recommended and correct vesa modes with the connected monitors. Pixel clocks should not be at the limits.

    On my setup with OS3.1.4.1 and PicassoIV, after having applied the 3.0.1 update rtg.library 42.557, it seems the gfx glitching issue might in fact have changed behaviour on this setup, as you mentioned above. At the moment I am not able to reproduce reliably, however, since I can still roll back to v2.4.3 (rtg.library 41.14), use the same display modes, applications, and then have no gfx glitches, I will continue monitor this system, and report back if I find any useful information.

    For the setup with OS3.9 and PiccoloSD64 I have managed to dig out some old backups. With the current setup but an old circa y2000 backup, (zorro cards have changed this year, currently gvp i/o-ext, Bigram+, PiccoloSD64 and Xsurf100/RR), I am still able to easily reproduce by using the os3.9 blanker commodity. Your view on hardware aging and possible degradation, without doubt this is certainly very probable, however I consider pulling the system apart to try verify system/zorroboards compatibility, preferably when 3.2 kickstart roms will be available.

    I will try attach a picture presenting the blanker induced gfx glitch, just in case anyone might observe similar. This glitch is very dominant if IBrowse is at the front, using a 16bit/hicolor mui screen specifically.

    best regards


  • This picture looks like "moving thing and starfield in the background" to me. Or are these white pixels the "unwanted" part?

  • Yes, the 'starfield' part of the screenshot is what I consider the unwanted gfx noise. Other 16bit depth screens can end up being 'dot'ed' as well, but with the system blanker commodity, the issue is especially dominant and ofcourse easy to see.

    As I mentioned above, I will eventually have a more thorough look at the hardware, zorro expansion board power supply voltages included.

    best regards,


  • In addition to voltages, please also measure ripple. You'll need an oscilloscope for that - and maybe help from someone who knows how to measure ripple. Remember to use the 20MHz bandwidth limitation.

  • A followup on my two systems mentioned above.

    The 4000T with PicassoIV, the issue when using >=P96V3, having spent quite some test time, with the current setup I have not yet observed any apps to responsible, but it is relatively easy to reproduce, by simply using the PIV builtin pal/ntsc scandoubler/flickerfixer, while having some p96 screens already in card memory. Are there any tools to see the actual internal memory management of P96?

    Solution is to retreat to P96 V2.4.3 which, after a prolonged testing period does not show any gfx issues at all, everything works ok with v2.4.3 with same screenmodes and all. This is the latest release archive I have, prior to the V3 releases. The 4000T is always-on and in daily use, re-cap is on the todo-list. When OS3.2 arrives I will test P96V3+ again.

    The other system.
    The 4000 desktop (4000cr model) with PiccoloSD64, this has been recap'ed, system board and psu inclusive. The axial cap's on the bus daughterboard are still the originals. Caps on SD64 are tantal type.

    Recently I pulled the expansion cards in order to get to the xsurf100 bracket alu rivets to drill them out, changing the bracket position for having the card better line up with the zorro connector. During this operation I could have a better look at the SD64 card, and operate it without the xsurf, the gvp i/o-ext and the bigram+.
    This gfx card only test, also changing zorro slot position, showed no change for the better.

    However, it seems this SD64 card has been oddly fitted with two types of dram socketed chips for the 2MB expansion. The original soldered-on 2MB are TI ones, but the socketed 2MB are 3x Hitachi and one Micron Technology. The Hitachi's seems to not having the HR mode, but no idea if this is used by this card?
    Switching the card to forced slow Z2 mode and keeping 4MB set, solves the problems.
    Keeping the faster Z3 mode but switching to 2MB mode also solves.
    I will try source 4 of these rare SO-package dram chips. For now z3 mode with just 2MB works without any issues.



  • but the socketed 2MB are 3x Hitachi and one Micron Technology. The Hitachi's seems to not having the HR mode, but no idea if this is used by this card?

    Micron was notorious for violating their own specs back in the days. I'd exchange that for a TI type and see if it works better.

    For further investigation, we should separate between PIV and Piccolo. So far, we've worked on the memory handling of the PIV card, but haven't gone deeper to check anything Piccolo-related. What you now wrote is purely Piccolo-related and I can't make out any hook where I would say "this is a software thing".

    With your observations of reduced memory size and reduced bus speed, it's likely that you will fix it all by replacing that single Micron chip. Out of these older D-Rams, I'd always use TI, Siemens, Toshiba and Samsung. Micron started to become good with SD-Ram.

  • The factory soldered TI TMS45160DZ's 256x16 SOJ package seems difficult to source, but I will try see what options I can find.

    I agree this thread has become hardware related, please close it, and any further P96 issues with the PicassoIV system memory handling, possible differences to the older P96 releases, for this I can write a new post in this forum if need be.

    If any P96 updates related to my PIV observations needs testing, let me know.



  • Regarding the PiccoloSD64 issue,

    With your observations of reduced memory size and reduced bus speed, it's likely that you will fix it all by replacing that single Micron chip.

    You were correct.

    I managed to source 4 compatible NEC chips from a polish industrial components dealer, but swapped only the Micron chip out. After having done a long term test, I am sure this particular problem is now solved.

    Thankyou for your assistance.

    Regarding the PIV issue, I will test again as soon as OS3.2 arrives, and when time permits. Eventual findings will be opened in a new thread.



  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.