Posts by gandalf

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.

    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 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.



    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.



    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,


    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


    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

    Hello, a4000t w. csppc060 PicassoIV p96 v3.0 Native pal/ntsc screens are occasionally not being switched through to the monitor output when opened. Mouse pointer disappears, and kb/mouse input works fully on the now in the background opened but hidden native screen. Rolling through all opened screens, the hidden native screen remains invisible. If more native screens are opened, these are not switched through either. Looking at the figure reported by AvailP96, this issue seems to only happen when p96 is relatively low on card memory, perhaps around the 500k free figure and lower. Opening/closing another p96 screen, which makes p96 swap card memory to fastram, and with the now higher amount of available free card memory, the issue goes away. Even native screens already open in the background, which could not be brought properly to the front/monitor, they are now being switched through properly. Prior to v3.O the PicassoIV switching to and from native screenmodes has always been solid. If indeed not just a local v3 problem on my setup, I hope this report can be helpful for keeping PicassoIV compatibility with future p96 updates. best regards -gandalf

    Hello, first many thanks for releasing P96 updates and adding to the functionality, much appreciated. I have been recommended to add my v3.0 issues into this forum. a4000t w. csppc060 PicassoIV p96 v3.0 mouse pointer is not blanked when the os supplied blanker commodity is active. Rolling back to p96 v2.4.3 this issue is not seen. The issue only happens on p96 screenmodes, not on native pal/ntsc modes switched through the PicassoIV. (on another system, a4000cr desktop w. csmk2 060 3.9 SD64 p96 v3.0 the mouse pointer is blanked properly). no big deal but I thought I'd mention it. best regards -gandalf