Posts by gandalf

Hello,

the supplied beta file solved this issue.

Thx, rgds,

-gandalf

ok np, then I must have misunderstood the situation, and it could be the ageing hardware or something. I can use p96 v2.4.3 if need be, as this seem to not show the issue.

rgds,

-gandalf

If an overlay window from Paloma-TV module is opened as per the icon tooltype, there is initially some refresh distortion visible in the window gfx. It is not possible to sgrab this, so it somehow seems to affect vram output only. Any refresh thereafter will re-render the window correctly. Suposedly there is a beta/fix for testing this? Shop Order: 109833 rgds, -gandalf

Good news indeed, as nuttie already wrote, with rtg.library v42.1216 (09/02/22) the double/multiscan modes issue seems solved.

-gandalf

here is the most recent: 109833

-gandalf

>push<

-gandalf

I dont think it is just you, no.

Here using A4000 desktop csmk2 PiccoloSD64 os3.2 I see something similar after having updated to P96 v3.2.3.

The system grinds to a halt, floppy even stops the no disk inserted seeking, when testing dbl and multiscan modes in the systems screenmode prefs app.

Reverting to P96 v3.2.2 solves the issue.

-gandalf

> V4.4 fixes problems..

Older file to be replaced is v4.5 (14.10.14) from current Poseidon v4.5 main archive, and the suposedly updated file being v4.4 (13.2.10), is this the correct hid.class update?

rgds,

-gandalf

Regarding the PiccoloSD64 issue,

Quote from Jens

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.

rgds,

-gandalf

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.

rgds,

-gandalf

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.

rgds

-gandalf

Thx, I have an oscilloscope and will check this as well.

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,

-gandalf

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

-gandalf

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

-gandalf

a4000t w. csppc060 3.1.4.1 PicassoIV rtglib 42.557

After last night having tested with the provided beta2, this specific issue seems to have been solved, thanks.

best regards

-gandalf

a4000t w. csppc060 3.1.4.1 PicassoIV rtglib 42.557

After last night having tested with the provided beta2, this specific issue seems to have been solved, thanks.

best regards

-gandalf

Hello, a4000t csppc060 3.1.4.1 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,

I have sent you a forum personal message,

best regards

-gandalf

Hello, a4000t w. csppc060 3.1.4.1 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