pilgrim@daimi.aau.dk (Jakob G}rdsted) (06/03/91)
OK. I got the source code for WBPic by fridhjof Siebert
(it's in modula-2).
WBPic and SimGen does practically the same thing - they put
a 2-4 colour iff pic in the background, as colour 0.
WBPic does it by making a 8-16 colour pic(using the bit-
planes from both and making a new palette). Maybe SimGen
does it the same way, I don't know.
(We are now closing in on the subject...)
I use a PAL a500. Both of these programs fail on one type
of pictures. That is, interlaced, 4colour overscan pictures.
It seems like, when one tries this, that the machine acts like
the display is NTSC.
In the description of WBPic, it says noninterlaced pictures,
but it seems to work just fine. It works if the pictures are
2colour, but does the above error, if 4colour.
I've looked through the source code for wbpic, and see no
limitations in it(it is simple, and easy to understand; I
can mail it to you if you're interested or would look at
it). Although he uses a Ifflibrary of some sort, forgot its
name. But SimGen fails also ,so I suspect this isn't the
problem.
I don't understand what goes wrong(why does it work with
2 colours). The overscan workbench is a result of a
'mutant' system-configuration; I haven't edited the numbers
myself, so it should be okay.
I believe NTSC users to have no problems(as it seems like
using NTSC overscan with the 4colour pictures).
I hope some people get curious at this, because I have
almost given up.
--
From the notorious
Jakob Gaardsted, Computer Science Department
Bed og arbejd ! University of Aarhus, Jylland (!)
(Pray and work!) AMIGA! pilgrim@daimi.aau.dk | I'd rather play Moria.chem194@csc.canterbury.ac.nz (John Davis) (06/03/91)
In article <1991Jun2.183144.22881@daimi.aau.dk>, pilgrim@daimi.aau.dk (Jakob G}rdsted) writes: > I use a PAL a500. Both of these programs fail on one type > of pictures. That is, interlaced, 4colour overscan pictures. > It seems like, when one tries this, that the machine acts like > the display is NTSC. If you mean that the display actually _truncates_ around the 400 line mark on the screen (i.e. ALL windows disappear beneath there, as opposed to only the backdrop picture being chopped off, with windows etc lower down the screen still visible) then it could be the reasonably well known bug relating to overscaned, 16 colour hires PAL screens. To find out, while the screen is truncated, load preferences and use the centering control in prefs to slowly move the screen left - you should find that at some point the screen will suddenly start displaying full depth again (I got caught with this running extreme overscan and Jrcomm in 16 colour mode). The solution is to leave your preferences set with the screen far enough to the left that the chop-off doesn't happen... ----------------------------------------------------------- | o John Davis - CHEM194@csc.canterbury.ac.nz o | | o (Depart)mental Programmer,Chemistry Department o | | o University of Canterbury, Christchurch, New Zealand o |
pilgrim@daimi.aau.dk (Jakob G}rdsted) (06/05/91)
chem194@csc.canterbury.ac.nz (John Davis) writes: >In article <1991Jun2.183144.22881@daimi.aau.dk>, pilgrim@daimi.aau.dk (Jakob G}rdsted) writes: >> I use a PAL a500. Both of these programs fail on one type >> of pictures. That is, interlaced, 4colour overscan pictures. >> It seems like, when one tries this, that the machine acts like >> the display is NTSC. >If you mean that the display actually _truncates_ around the 400 line >mark on the screen (i.e. ALL windows disappear beneath there, as opposed to Yes, this is what happens. The screen goes "NTSC", but the contents of the screen stays what they should be. It looks like someone put tape across the bottom of the display, so one cannot see what is going on down there. >the screen still visible) then it could be the reasonably well known >bug relating to overscaned, 16 colour hires PAL screens. To find out, >while the screen is truncated, load preferences and use the centering I'll try this in a few hours from now. >The solution is to leave your preferences set with the screen far enough >to the left that the chop-off doesn't happen... And that is the only solution? And whose "fault" is it, i.e. is it a hardware or software bug, is it OS dependant(= fixed in 2.0) ? or what? I'm glad to hear it was not me going mad, it has driven me crazy( :-) for the last 2 years. -- From the notorious Jakob Gaardsted, Computer Science Department Bed og arbejd ! University of Aarhus, Jylland (!) (Pray and work!) AMIGA! pilgrim@daimi.aau.dk | I'd rather play Moria.
rhialto@cs.kun.nl (Olaf'Rhialto'Seibert) (06/06/91)
In article <1991Jun4.175631.20446@daimi.aau.dk> pilgrim@daimi.aau.dk (Jakob G}rdsted) writes: >>In article <1991Jun2.183144.22881@daimi.aau.dk>, pilgrim@daimi.aau.dk (Jakob G}rdsted) writes: >>> I use a PAL a500. Both of these programs fail on one type >>> of pictures. That is, interlaced, 4colour overscan pictures. >>> It seems like, when one tries this, that the machine acts like >>> the display is NTSC. >And that is the only solution? And whose "fault" is it, i.e. is it >a hardware or software bug, is it OS dependant(= fixed in 2.0) ? or >what? I'm glad to hear it was not me going mad, it has driven me >crazy( :-) for the last 2 years. It is a software fault. Comparing different cases, analyzing the copper lists that are generated, made this clear. The relevant factors are 1. >= 640+32 (= 672) pixels wide (hires) 2. > 216 lines high (in non-interlace mode) 3. 4 bitplanes If you drag such a truncated screen below line 216 (if I remember that number correctly) the area below reappears again. -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
pilgrim@daimi.aau.dk (Jakob G}rdsted) (06/14/91)
rhialto@cs.kun.nl (Olaf'Rhialto'Seibert) writes: >>>In article <1991Jun2.183144.22881@daimi.aau.dk>, pilgrim@daimi.aau.dk (Jakob G}rdsted) writes: >>>> I use a PAL a500. Both of these programs fail on one type >>>> of pictures. That is, interlaced, 4colour overscan pictures. >>>> It seems like, when one tries this, that the machine acts like >>>> the display is NTSC. >>And that is the only solution? And whose "fault" is it, i.e. is it >>a hardware or software bug, is it OS dependant(= fixed in 2.0) ? or >>what? I'm glad to hear it was not me going mad, it has driven me >>crazy( :-) for the last 2 years. >It is a software fault. Comparing different cases, analyzing the copper Yes, I know that moving the screen sufficiently to the left(below 216) makes the problem disapper. But why does it go NTSC(?) at >The relevant factors are >1. >= 640+32 (= 672) pixels wide (hires) >2. > 216 lines high (in non-interlace mode) >3. 4 bitplanes the conjunction of these factors? It works with 3 bitplanes, but not with four; I would expect it to be hardware limitations then. The reason I am still interested in this is, that I have had to move my screen much more to the left than previously, to be able to view 16 colour pictures. As a result of this, the horizontal position pin on my monitor had to be adjusted a lot to the right, to put the picture back on the screen. And this has given me a rim of light in the right side of the screen; it seems like turning the screen to the extreme right makes the scan lines "reflect back" on the screen again(does this make sense?). To avoid it, I instead have to use smaller overscan screens, and this was not what I wanted... On the same note, I remember having read several places, that overscan was not "part of the system"/not supported; the effect of this being that you should only hope for overscan to work, but not rely on it, i.e. future changes to hardware may or may not support it. Could anybody with some knowledge date this information and tell, how "true" this is - what is the "legal" state of overscan for the time being, as well as for the future? -- From the notorious Jakob Gaardsted, Computer Science Department Bed og arbejd ! University of Aarhus, Jylland (!) (Pray and work!) AMIGA! pilgrim@daimi.aau.dk | I'd rather play Moria.