P96 3.0.0 (and later) news and support

[Michael]

OctaMEDSoundStudio 1.03c/d graphics corruption issue with P96


The problem area is intuition drawn scopes, very odd,
but it fails under current P96 (3.4.1) and PicassoIV driver
it could be nothing or random pixel mess

Works fine under CGX and Native displays

[Thomas Richter]

Octamed pokes directly into the chunky bitmap created by P96 without testing whether it is planar or chunky. That, of course, does not work. The bitmap is allocated as a friend of its screen bitmap, and if that is chunky, the scope bitmap also becomes chunky. If they had the friend pointer left alone, it would have become a planar bitmap and things would work better. This is a programming defect, not a P96 defect (otherwise, P96 would have to allocate all its bitmaps as planar, which is not desirable).

Resolution: Either run P96 on a planar mode, or do not use the scope.

[hexaae]

There's a workaround for OctaMedSS:
1) use ModePro http://m68k.aminet.net/package/util/cdity/ModePro with option "Force planar" (the best software of its kind)...
2) ... and set OctaMedSS to 8bit screenmode

This way also bars will work fine



HINT: remember to set variable ENV:Picasso96/AmigaVideo containing text "31kHz" to be able to play 56kHz+ sounds and songs at correct speed (e.g. loading in OctaMedSS mods like Second_Reality.s3m)

[Michael]

Thanks for the hint, the planar screen flag does the job nicely.

Oddly enough SS offers non-planar screen flag in misc/prefs,
but it only effects the main tracker editor window and not the scopes.

I guess SS has some logic for CGX, since there it works fine in chunky without the need to patch.

[Thomas Richter]

Originally Posted by Michael

I guess SS has some logic for CGX, since there it works fine in chunky without the need to patch.

CGfx always keeps allocated bitmaps in planar, except for the bitmaps allocated as backing store for layers (smart refresh layers) where it has some mega-patch applied to layers to identify exactly those calls that attempt to allocate the bitmaps of cliprects. That is also the reason why cgfx does not work very well with any layers.library beyond v40 - it assumes the logic of the v40 layers.library, which had many issues itself. Frank was contacted in a friendly and informal manner well before publication of 3.1.4, but declared the 68K series of CGfx dead. What else do I need to add?

[klx300r]

Att: VA2000 & VA2000cx users using latest P96 VA2000 driver

I'm getting sporadic horizontal banding on many games but most noticeable when playing AmiBird and AquaByss.

Can someone please post settings for the new driver and/or cx board

[Thomas Richter]

Sorry, unclear what you mean by "horizontal banding", a picture would be helpful. Note that you can always adjust the modes manually - some of the modes unfortunately have to use an excessively large front porch to reduce the horizontal frequency into a useful range, this is because the VA2000 only offers two pixel clocks, and this may possibly not go well with all monitors. Thus, tweaking the mode might be a solution - try to decrease the frame size, thus increase the horizontal frequency - to the liking of your monitor.

[klx300r]

@ Thomas Richter


here's a quick vid that shows what I'm referring to:
[ Show youtube player ]

[Thomas Richter]

Thanks, which mode is this, and does it help to disable the blitter? The timing of the FPGA is really quite tight, and if the blitter and the CPU hog the bus to the video memory, it can happen that there are insufficient free cycles for the video refresh. Note that the new driver uses the blitter in a couple of extra cases the original code did not.

[klx300r]

Originally Posted by Thomas Richter

Thanks, which mode is this, and does it help to disable the blitter? The timing of the FPGA is really quite tight, and if the blitter and the CPU hog the bus to the video memory, it can happen that there are insufficient free cycles for the video refresh. Note that the new driver uses the blitter in a couple of extra cases the original code did not.

this occurs in both native and RTG modes though more noticeable in native modes

[Thomas Richter]

Not quite my question - which resolution, and which bitdepth?

What are native modes? Modes where you use the flicker fixer of the board?

[klx300r]

I’d say AmiBird is 240x320 (native) and my Workbench is 1280x1024 (RTG) …will have to check depth when back home…though as noted above those horizontal glitches seem to be happening on mostly all screen modes both native and RTG

update: -1280x1024- 16 bit

[Thomas Richter]

The configuration of the flicker fixer is not different from the configuration the official driver uses. All I can offer is possibly a tool to configure the prefetch register of the fpga.

[klx300r]

Originally Posted by Thomas Richter

The configuration of the flicker fixer is not different from the configuration the official driver uses. All I can offer is possibly a tool to configure the prefetch register of the fpga.

sure that would be great and also if there's any other settings in the P96 prefs that might help I'd be happy to try too

[klx300r]

good news! seems I had the blitter on when I thought it was off...messing with other options in P96 prefs didn't help my issue but as soon as I set Blitter off problem is 95% better now

There's still a minimal amount of that horizontal glitching and also noticed some artifacts on demos are gone too

[Thomas Richter]

Thanks - though now the performance is down the drain. This was only a test to understand where the problems are coming from, and my suspicion was apparently correct. We can play a little bit with the prefetch.

[klx300r]

Originally Posted by Thomas Richter

Thanks - though now the performance is down the drain. This was only a test to understand where the problems are coming from, and my suspicion was apparently correct. We can play a little bit with the prefetch.

yup system is less snappy for sure