[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IIe double modes
Jonathan Schattke wrote:
>
> Mike Pfaiffer wrote:
> >
> > Jonathan Schattke wrote:
> > >
<snip>
> > > The following anomalies occurred:
> > >
> > > If I turn on AN3 with poke-16290,0 and have the machine in 40-column
> > > mode, Lo-Res mode is 40x40, but the colors are as if the screen was
> > > directly mapped to hi-res.
> >
> > As I recall it you should activate the 80 column card first. If the
> > card is active you can switch back and forth between 40 and 80 columns.
> > This will correspond to a 40 or 80 column grahics screen. If the 80
> > column card is inactive you should only be able at access a 40x40 lores
> > screen.
>
> You should. I was misbehaving, and knew it. It is called "Hacking".
> The wonder came when I did the odd, though :)
In a sense there is no real harm done. If the programs are written on
an actual Apple they will behave normally because this is what they've
been designed to do. If the program was written under AppleWin then the
programmer should not make assumptions as to which mode they are in.
Still when writing an emulator it is always a good idea to insure 100%
compatible functionality.
> > > If I then turn on 80-column mode, the lores is 80x40, but the colors for
> > > the aux bank pixels are mixed up, 0,8,1,9,2,10,3,11,4,12,5,13,6,14,7,15
> > > corresponding to 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,and 15.
> >
> > Without checking out everything it looks like the colour values are
> > rotated right by one pixel. Since each byte controls two pixels try
> > doing a direct poke into the text page and see what happens. This way
> > you can see what's up.
>
> Can you see why from the dicussion below?
Sorry, I should have said one bit. It sounds as though double-lores is
being emulated with DHGR...
> > > Also, I seem to get slightly different colors in DHR mode: 32 of them (I
> > > guess this is because a DHR pixel is half a pixel).
>
> > For DHGR the process is similar in as much as the storage of pixels in
> > monochrome mode are identical. The exception is the first set of pixels
> > is stored in the AUX bank where as the next byte takes place in the MAIN
> > bank.
> >
> > Colour DHGR is interesting. Each pixel is made up of four bits stored
> > almost as you would expect. Here is what I mean with the first byte in
> > the AUX bank and the second byte in the MAIN bank. P111 0000 P332 2221.
> > Assuming the pallet bit remains the same the result should be sixteen
> > colours. Here is the REALLY interesting bit... Are the colours the same
> > if you change the pallet? If so, you could end up with 30 colours (black
> > and white would remain the same for each pallet).
>
> Not quite. DHR starts a color as soon as it hits a pixel.
Oddly enough I knew this in the back of my mind. It didn't occur to me
until you mentioned it. ;-) Then the pattern 0001 1110 would produce a
white pixel rather than two pixels of differing colour... Very annoying.
> The pallette
> bit is ignored.
This is the theory. A friend tried it and came up with some different
colours depending on the value he was using.
> The position of the pixel determines what color it
> starts displaying, i.e. if the position would be even, it will be green,
> if even +1/2, orange, if odd, purple, if odd+1/2 blue.
>
> Now, if additional pixels are on, the system will modify the color burst
> accordingly. The lores colors are supposed to be evidenced when the
> pixel pattern matches that of a lores color (which, conveniently, are
> not mapped).
> But, starting with a '1', there are 8 binary patterns less than 16. And
> when you consider that these patterns can start in any of 4 collumns,
> you get the 32 displayed colors. much of this is fringe effect: a
> solid pattern will drop into one of the 15 lores colors.
> 1000 - 1/2 pixel, dim dot of color (dk grn, brown, purple, dk blu)
> 1100 - 1 pixel, hires color (green, orange, purple, blue)
> 1110 - 1 1/2 pixel, brighter hires color (Lt Grn, yellow, Pink, Lt Blue)
> 1111 - 2 pixels, white (fringed)
> 1010 - 1/2 pixel then 1/2 pixel -one of the greys (this gives us the 15
> LoRes)
> now the weirder stuff:
> 1001 - 1/2 pixel, then mix in 1/2 pixel
> 1101 - pixel then 1/2 pixel
> 1011 - 1/2 pixel, then pixel
> These will settle into being the above patterns, after the initial
> burst.
>
> > > Do these anomalies happen with a IIc or enhanced IIe?
> >
> > It should...
>
> Could you check for me?
I'm using a GS and Second Sight card. I may get different results.
> > > I'd really like AppleWin to be 100% accurate.
> >
> > What is AppleWin?
>
> It emulates an Apple //e under Windows - hence the name, AppleWin. It's
> too bad that the IBM PC floppy drive has a layer between the bus and the
> floppy drive, but I guess that's what you give up to have DMA floppies.
> As it is, I have to settle on disk images.
>
> You can download AppleWin 1.11.B from
> <http://pages.ripco.com:8080/~wizwom/applewin/applewin_dist.zip>
>
> Just extract it into it's own directory, and run "Apple for Windows.exe"
>
> I have not quite got the AN3 on lores mod done, although it's simple
> enough.
> Also there is a minor calibration bug - on extremely fast machines,
> calibration takes a very long time.
I'll have to look at it later. Just a bit busy at the moment...
Later
Mike
--
+------------------------------------------------------------------------+
|Lifes the same I'm moving in stereo. Lifes the same except for my
shoes.|
| -The Cars 1978 |
+------------------------------------------------------------------------+
| http://www.mbnet.mb.ca/~pfaiffer = Mike Pfaiffer (B.A., B.Sc.)
|
| See my web page before you think about spamming me. I charge cash.
|
+------------------------------------------------------------------------+