Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.apple2.programmer > #5294 > unrolled thread

Double Lo-Res Broken on the IIe card (Macintosh)?

Started byPaul MacMillan <paul.s.macmillan@gmail.com>
First post2019-10-13 08:09 -0700
Last post2019-10-13 19:33 -0400
Articles 10 — 7 participants

Back to article view | Back to comp.sys.apple2.programmer


Contents

  Double Lo-Res Broken on the IIe card (Macintosh)? Paul MacMillan <paul.s.macmillan@gmail.com> - 2019-10-13 08:09 -0700
    Double Lo-Res Broken on the IIe card (Macintosh)? Antoine Vignau <antoine.vignau@laposte.net> - 2019-10-13 08:41 -0700
      Re: Double Lo-Res Broken on the IIe card (Macintosh)? Paul MacMillan <paul.s.macmillan@gmail.com> - 2019-10-13 09:13 -0700
        Re: Double Lo-Res Broken on the IIe card (Macintosh)? Paul MacMillan <paul.s.macmillan@gmail.com> - 2019-10-13 10:09 -0700
          Re: Double Lo-Res Broken on the IIe card (Macintosh)? inexorabletash@gmail.com - 2019-10-13 14:11 -0700
          Re: Double Lo-Res Broken on the IIe card (Macintosh)? Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2019-10-14 02:15 -0500
            Re: Double Lo-Res Broken on the IIe card (Macintosh)? Steve Nickolas <usotsuki@buric.co> - 2019-10-15 15:20 -0400
              Re: Double Lo-Res Broken on the IIe card (Macintosh)? Andy McFadden <thefadden@gmail.com> - 2019-10-15 14:39 -0700
                Re: Double Lo-Res Broken on the IIe card (Macintosh)? MG <mg@zlink.us> - 2019-10-16 11:15 -0700
    Re: Double Lo-Res Broken on the IIe card (Macintosh)? Steve Nickolas <usotsuki@buric.co> - 2019-10-13 19:33 -0400

#5294 — Double Lo-Res Broken on the IIe card (Macintosh)?

FromPaul MacMillan <paul.s.macmillan@gmail.com>
Date2019-10-13 08:09 -0700
SubjectDouble Lo-Res Broken on the IIe card (Macintosh)?
Message-ID<f1005596-d20e-4d0b-8a45-044628e5dc73@googlegroups.com>
Is there a known issue with Double Lo-Res graphics on the (Macintosh) IIe card? I have a card in my LCIII and tried my own DGR library on it and it seems that every other column (the AUX mem columns perhaps?) display the wrong color.

I figured there was a flaw in my DGR code that was only exposed when running on the IIe card (it worked fine on a IIGS and IIC+) so I got a copy of Beagle Graphics and used their DGR and saw the same issue.

Here is the sample code I use, to print 16 color bars on the screen. Looks great everywhere except the IIe card. DGR is from Beagle Graphics.

]list

 10 D$ =  CHR$ (4): PRINT D$"-DGR": PRINT D$"PR#3"
 20  &  GR 2
 30  FOR COLR = 0 TO 15: &  COLOR= COLR
 40  FOR J = 0 TO 4
 60  &  VLIN 0,47 AT (COLR * 5) + J
 70  NEXT J
 80  NEXT COLR
 90  VTAB 24 : GET C$
 100  &  TEXT : HOME : PRINT : VTAB 24

]









[toc] | [next] | [standalone]


#5295

FromAntoine Vignau <antoine.vignau@laposte.net>
Date2019-10-13 08:41 -0700
Message-ID<c4e21a89-7d70-4947-abf3-c2b4595705e3@googlegroups.com>
In reply to#5294
I read something somewhere that says that dgr colors on even columns, ie. aux mem, are wrong ones,
av

[toc] | [prev] | [next] | [standalone]


#5296

FromPaul MacMillan <paul.s.macmillan@gmail.com>
Date2019-10-13 09:13 -0700
Message-ID<bb1a0933-ce82-4604-b559-8c4446333bb1@googlegroups.com>
In reply to#5295
On Sunday, October 13, 2019 at 8:41:38 AM UTC-7, Antoine Vignau wrote:
> I read something somewhere that says that dgr colors on even columns, ie. aux mem, are wrong ones,
> av

Yes, thanks, you are correct and that is expected (see for example Gary Little's Inside the Apple IIe p.259), one codes to handle that as did Beagle Bros. The sample app above works in IIe emulators (Virtual ][ for example), and real IIc, just not in my IIe card (Macintosh). I don't have a real IIe to test with.... anybody?

[toc] | [prev] | [next] | [standalone]


#5298

FromPaul MacMillan <paul.s.macmillan@gmail.com>
Date2019-10-13 10:09 -0700
Message-ID<0e920ea3-5aa0-4516-9bc6-f071f33d4040@googlegroups.com>
In reply to#5296
So that was a clue! I rewrote my DGR library to NOT do the alt-color lookup for even columns.  Now it looks fine on a IIe card (but will look wrong everywhere else I guess)

So now the remaining questions --

why this difference? I guess in a "real" IIe there are timing differences between the main and aux memories, so the colors appear differently -- and this timing difference may not be there in the IIe card?

But then many other games or anything that uses Double-res graphics (low or high?) will look wrong on the IIe card.  

Also is there way to identify running on a IIe card (vs a real IIe or emulated real IIe?)


[toc] | [prev] | [next] | [standalone]


#5299

Frominexorabletash@gmail.com
Date2019-10-13 14:11 -0700
Message-ID<17af11fe-8160-43c4-9ad0-fd3be67e3921@googlegroups.com>
In reply to#5298
Detecting:

http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.07.html

My uneducated guess is that the behavior is just a bug/oversight/missing feature in the IIe card's video emulation, given the lack of DGR software to test against (compared to the text and hires modes). 

[toc] | [prev] | [next] | [standalone]


#5301

FromBrian Patrie <bpatrie@bellsouth.spamisicky.net>
Date2019-10-14 02:15 -0500
Message-ID<qo179t$1ic5$1@gioia.aioe.org>
In reply to#5298
On 13/10/2019 12.09, Paul MacMillan wrote:
 > why this difference? I guess in a "real" IIe there are timing
 > differences between the main and aux memories, so the colors appear
 > differently -- and this timing difference may not be there in the
 > IIe card?

In a sense.  If you look at the DGR output of a IIe in monochrome (or 
one of AppleWin's monochrome monitor modes), you'll see that each colour 
is made up of a pattern of monochrome sub-pixels, horizontally.  There 
are 7 of these sub-pixels for for each horizontal DGR pixel (as opposed 
to 14 for single-GR).  Since 7 is an odd number, if you write the same 
value to adjacent DGR pixels, the sub-pixel pattern will in a different 
phase, so it will be interpreted by a colour monitor as a different 
colour.  So it has to be adjusted to be the same colour.  (This is also 
true of DHGR, since only 7 bits per byte are displayed; if you write the 
same value to adjacent screen bytes (aux,main), you'll get a different 
colour pattern.)

I gather that the IIe card software just interprets the DGR colours and 
puts that on the Mac screen, but has a bug in that it fails to interpret 
them differently for the auxmem pixels.  I seem to recall talk of 
patching it.  (I could be talking out my ass for this paragraph, though.)

Given this situation, it would be good if there's a way for a programme 
to tell if it's running on the IIe card, and further to tell if it's 
running with fixed software.

[toc] | [prev] | [next] | [standalone]


#5302

FromSteve Nickolas <usotsuki@buric.co>
Date2019-10-15 15:20 -0400
Message-ID<alpine.BSF.2.02.1910151516080.70020@frieza.hoshinet.org>
In reply to#5301
On Mon, 14 Oct 2019, Brian Patrie wrote:

> On 13/10/2019 12.09, Paul MacMillan wrote:
>> why this difference? I guess in a "real" IIe there are timing
>> differences between the main and aux memories, so the colors appear
>> differently -- and this timing difference may not be there in the
>> IIe card?
>
> In a sense.  If you look at the DGR output of a IIe in monochrome (or one of 
> AppleWin's monochrome monitor modes), you'll see that each colour is made up 
> of a pattern of monochrome sub-pixels, horizontally.  There are 7 of these 
> sub-pixels for for each horizontal DGR pixel (as opposed to 14 for 
> single-GR).  Since 7 is an odd number, if you write the same value to 
> adjacent DGR pixels, the sub-pixel pattern will in a different phase, so it 
> will be interpreted by a colour monitor as a different colour.  So it has to 
> be adjusted to be the same colour.  (This is also true of DHGR, since only 7 
> bits per byte are displayed; if you write the same value to adjacent screen 
> bytes (aux,main), you'll get a different colour pattern.)
>
> I gather that the IIe card software just interprets the DGR colours and puts 
> that on the Mac screen, but has a bug in that it fails to interpret them 
> differently for the auxmem pixels.  I seem to recall talk of patching it.  (I 
> could be talking out my ass for this paragraph, though.)
>
> Given this situation, it would be good if there's a way for a programme to 
> tell if it's running on the IIe card, and further to tell if it's running 
> with fixed software.
>

The first check for a //e or later is, of course, $06 at $FBB3.

It looks like if you find $02 at $FBDD and $00 at $FBBE that you've got a 
Macintosh.  Double-check this maybe - I'm looking at code of mine I 
haven't checked in about 10 years.

-uso.

[toc] | [prev] | [next] | [standalone]


#5303

FromAndy McFadden <thefadden@gmail.com>
Date2019-10-15 14:39 -0700
Message-ID<f10f1a78-2289-4726-bd94-901b3c52f075@googlegroups.com>
In reply to#5302
On Tuesday, October 15, 2019 at 12:20:22 PM UTC-7, Steve Nickolas wrote:
> It looks like if you find $02 at $FBDD and $00 at $FBBE that you've got a 
> Macintosh.  Double-check this maybe - I'm looking at code of mine I 
> haven't checked in about 10 years.

https://retrocomputing.stackexchange.com/a/366/56

[toc] | [prev] | [next] | [standalone]


#5304

FromMG <mg@zlink.us>
Date2019-10-16 11:15 -0700
Message-ID<ck4c9o.5a1.19.1@news.alt.net>
In reply to#5303
On 2019-10-15 21:39:53 +0000, Andy McFadden said:

> On Tuesday, October 15, 2019 at 12:20:22 PM UTC-7, Steve Nickolas wrote:
>> It looks like if you find $02 at $FBDD and $00 at $FBBE that you've got a
>> Macintosh.  Double-check this maybe - I'm looking at code of mine I
>> haven't checked in about 10 years.
> 
> https://retrocomputing.stackexchange.com/a/366/56

If you check for $00 at $FBBE you will miss all but the first version 
of the "IIe Startup" application.

Note the technote says:  Location "$FBBE is the version byte for the 
Apple IIe Card (just as $FBBF is the version byte for the Apple IIc 
family) and is $00 for the first release of the Apple IIe Card."

An additional caveat is that the old M68K/PPC emulator "IIe" also has 
$02 at $FBDD, but the authors didn't know *why* that value is there in 
the IIe Card's firmware.  The reason it's there is to trap the BELL 
routine to play the sound configured in the IIe startup application.  
Though perhaps there aren't many users of "IIe," it can be ruled out by 
checking $FBDE, which in the IIe Card is always $01, whereas "IIe" is 
something else.

The palettes used by the IIe Card are resources in the "IIe Startup" 
application.  I don't recall if there are two pallettes for DGR, but 
more than likely the problem is in the screen emulation code and not 
the palettes.

MG

P.S. All of my notes on the IIe Card are here: 
http://apple2.guidero.us/doku.php/mg_notes/iie_card/start

[toc] | [prev] | [next] | [standalone]


#5300

FromSteve Nickolas <usotsuki@buric.co>
Date2019-10-13 19:33 -0400
Message-ID<alpine.BSF.2.02.1910131930090.15130@frieza.hoshinet.org>
In reply to#5294
On Sun, 13 Oct 2019, Paul MacMillan wrote:

> Is there a known issue with Double Lo-Res graphics on the (Macintosh) 
> IIe card? I have a card in my LCIII and tried my own DGR library on it 
> and it seems that every other column (the AUX mem columns perhaps?) 
> display the wrong color.

I've demonstrated it.

Metal:
https://i.imgur.com/l4hkCGv.jpg
https://i.imgur.com/cftxvwP.jpg

AppleWin:
https://i.imgur.com/mZOfYLO.png
https://i.imgur.com/wVyUiGf.png

-uso.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.sys.apple2.programmer


csiph-web