DHGR Video Riddle Solved!!!
Arkain
all of the features of the IIe, including the ones that were not properly
documented. Some of those features included the DOUBLE HIRES display
mode(s). Most of you were under the impression that the system only carried
1 DHGR mode that was 140x192x16 on a color monitor and 560x192x2 on a
monochrome monitor. I was under the impression that there were 3 distinct
modes always available, the 2 modes listed above and a third that mixes the
2 above.
As it turned out... I was right... to a point. The reason that the modes
were clearly visible to me and not to the vast majority of you was that I
had an Extended 80 Column AppleColor Card with an AppleColor RGB monitor.
That setup provided graphics that were free of the color-bleeding that comes
with composite displays.
While my old system is long-since gone, I have acquired a new one and tested
various programs on it. This is the how and why of the DHGR video display
(as best as I can figure).
There are indeed 3 modes of display for the DHGR graphics. Mode 1 is 560x192
monochrome, but due to the composite display system and the fact that the
color signal is actually on in this mode, each dot on the screen experiences
color bleeding similar to that of the HIRES display and precisely identical
to the color bleeding that occurs on the 4 lines of 80 column text below a
HIRES mixed-mode display. Why the color signal is on in this mode is still a
mystery to me. I will do some more experimenting to determine the exact
nature of this. To properly set up this mode, run this code:
STA $CO52 ;Full Screen
STA $C057 ;HIRES
STA $C050 ;Graphics
STA $C00C ;80 Columns OFF
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C00D ;80 Columns ON
STA $C05E ;AN3 OFF
-------
Mode 2 is 140x192 16 color. This is the mode most commonly associated with
DHGR. It is already well documented. To properly set up this mode, run this
code:
STA $CO52 ;Full Screen
STA $C057 ;HIRES
STA $C050 ;Graphics
STA $C00C ;80 Columns OFF
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C00D ;80 Columns ON
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C05E ;AN3 OFF
-------
Mode 3 is a mix of modes 1 & 2. The last time I mentioned this mode, someone
asked me how the system would know when to display dots and when to display
colored blocks. The answer is that if bit 7 of a byte is set then the
contents of that byte are displayed in mode 1. I havent figured out what the
effect is on surrounding color blocks that use bits from that byte yet, but
I will. To properly set up this mode, run this code:
STA $CO52 ;Full Screen
STA $C057 ;HIRES
STA $C050 ;Graphics
STA $C00C ;80 Columns OFF
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C00D ;80 Columns ON
STA $C05E ;AN3 OFF
STA $C05F ;AN3 ON
STA $C05E ;AN3 OFF
-------
Note that to get to B & W mode you just turn off AN3 after truning on 80
columns; to get to mixed you toggle the switch an extra time; to get to full
color mode you toggle the switch once more. Why modes 2 & 3 were numbered
backwards is beyond me.
AN3 also has a peculiar effect on other graphic modes. In LORES mode, AN3
causes the display to double the same way that it does in hires mode if
80COL is on. In HIRES mode, if 80COL is off AN3 causes a polarity shift that
reverses the normal effect of the high bit.
I would appreciate it if someone else would take a little time to verify
these findings. I know that these aren't the effect of the Extended 80
Column AppleColor card & monitor since I no-longer have those devices.
BTW, does anyone know where I can find an RGB card & monitor for the IIe? I
miss the crisp display!
Matt Jenkins
Are you sure there are actually 3 distinct modes ? I was under
the impression that it was only the high order bits being set
that triggered color mode on or off.
Cheers,
Matt
--
Matt(hew) Jenkins. Computer Science (RMIT Bundoora)
email: m...@cs.rmit.edu.au
-- Site of the Month --
http://www.gnustep.org/
Arkain
"Jeff Blakeney" <CUTbl...@home.com> wrote in message
news:39b7d929....@24.9.0.17...
> On Wed, 6 Sep 2000 17:05:33 -0500, "Arkain" <rwk...@no.usa.spam.net>
> wrote:
>
> Well, I just tried all three of your programs on my IIgs, which has an
> RGB monitor so is free of colour bleeding, and all three programs
> produced a colour display and I could only get colour pixels
> regardless of whether the high bit of a byte was set or not.
The IIgs, as far as I know, only uses mode 2. This is not surprising since
that's the only mode documented in the IIe technical reference manual.
> Whether this is a difference between the IIgs and the IIe, I don't
> know. If you want I can set up a IIe on the weekend and try those
> programs on it with my AE Ramworks II card as my extended 80 column
> card but I still don't see how it can possibly work. There is no way
> for software to turn off the colour burst crystal on the composite
> output of a IIe so I don't understand how a IIe could possibly output
> any kind of monochrome image without special hardware.
Like I said before: The color burst signal is never turned off in DHGR
mode... at least not on a composite monitor. This leaves the screen with 560
color-bleeding horizontal dots. Depending on the position of the dot, it
seems you'll still get some subset of the 14 colors, but in a dot that's 1/4
the size of the normal DHGR pixel. This means that it will normally appear
that the screen is still in full color mode when it's not.
> By the way, I'm only aware of one DHR mode. 560x192. The number of
> colours you get depends on whether you view it on a colour or
> monochrome monitor. If viewed on a colour monitor, you will get 16
> colours but if you view it on a monochrome monitor, those 16 colours
> appear as different dot patterns and you can see all 560 horizontal
> dots.
The easiest way to tell the difference is to populate the screen with 80
column bit-mapped text. Each block, 1 byte wide & 8 rows tall, should be
used to make a character. In mode 1 you'll be able to read whatever text you
put on the screen, but you won't be able to predict the colors using the
mode 2 method. In mode 2, the text will be harder to read, but the colors
will be just what you expected.
As for mode 3, the proof of it is in the fact that games like Test Drive
display text clearly on a IIe, but blur the text with extra color blocks on
a IIgs. If the mode were strictly mode 2, then the text would always show
with color on the edges.
Arkain
Matt Jenkins
> By the way, I'm only aware of one DHR mode. 560x192. The number of
> colours you get depends on whether you view it on a colour or
> monochrome monitor. If viewed on a colour monitor, you will get 16
> colours but if you view it on a monochrome monitor, those 16 colours
> appear as different dot patterns and you can see all 560 horizontal
> dots.
That's not correct. There is indeed *two* modes of DHR, 560x192 BW and
140x192 16 color. Whether a byte in the video area is interpreted as
color pixels or BW pixels is dependant on the high order bit of that byte.
This is different from standard hires which uses the high order byte to
'shift' the pixels by a half pixel...
Matt Jenkins
> As for mode 3, the proof of it is in the fact that games like Test Drive
> display text clearly on a IIe, but blur the text with extra color blocks on
> a IIgs. If the mode were strictly mode 2, then the text would always show
> with color on the edges.
Actually, this doesn't prove anything. The IIgs does a really poor job of
displaying Double HiRes, worse than the IIe, at least on its RGB output
anyway, and that would explain the difference observed. Most DHR games
look better on a Color equipped //e than they do on a IIgs..
Arkain
do an excellent job of emulating mode 2. You'll get the same color
abberation that I mentioned before.
Arkain
Matt Jenkins" <m...@bilby.cs.rmit.edu.au> wrote in message
news:39b8...@naylor.cs.rmit.edu.au...
> In comp.sys.apple2 Arkain <rwk...@usa.nospam.net> wrote:
>
> > As for mode 3, the proof of it is in the fact that games like Test Drive
> > display text clearly on a IIe, but blur the text with extra color blocks
on
> > a IIgs. If the mode were strictly mode 2, then the text would always
show
> > with color on the edges.
>
> Actually, this doesn't prove anything. The IIgs does a really poor job of
> displaying Double HiRes, worse than the IIe, at least on its RGB output
> anyway, and that would explain the difference observed. Most DHR games
> look better on a Color equipped file://e than they do on a IIgs..
David Wilson
>In comp.sys.apple2 Jeff Blakeney <CUTbl...@home.com> wrote:
>> By the way, I'm only aware of one DHR mode. 560x192. The number of
>> colours you get depends on whether you view it on a colour or
>> monochrome monitor. If viewed on a colour monitor, you will get 16
>> colours but if you view it on a monochrome monitor, those 16 colours
>> appear as different dot patterns and you can see all 560 horizontal
>> dots.
>That's not correct. There is indeed *two* modes of DHR, 560x192 BW and
>140x192 16 color. Whether a byte in the video area is interpreted as
>color pixels or BW pixels is dependant on the high order bit of that byte.
But only if you have an RGB card. If you use composite video on a //e bit 7
is ignored in DHR mode.
--
David Wilson School of IT & CS, Uni of Wollongong, Australia
Holger Picker
> Date: 10 Sep 2000 11:24:02 +1100
> From: David Wilson <da...@uow.edu.au>
> Newsgroups: comp.sys.apple2, comp.emulators.apple2
> Subject: Re: DHGR Video Riddle Solved!!!
Hello,
(Uh, this is my very first posting to a newsgroup. Please have patience with me and my poor English.)
If I understood this thread right, there seems to have been the question whether the high-bit in double-hiresmode influences the output of the screen, either monochrome, colour or something inbetween. To find proof of such a behaviour I've programmed my emulator in such a way that it tells me the value of the high-bit. Then I took a look at some well-known programmes whether they keep the high-bit on or off.
Here are my findings:
Text = Characters (should typically use monochrome mode for higher resolution)
Graphic = Pictures, shapes etc (should typically use coulor mode)
BW = black characters on white background
WB = white characters on black background
Text Graphic
Airheart off off
Battlechess off off
California Games off off
Dragon Wars BW on off
WB off
Maniac Mansion off on
every fourth column off(?)
Might&Magic 2 off off
every fourth column on(?)
Neuromancer BW on background on
WB off shapes off
Pirates on on
Rampage on on
Testdrive off off
three bright columns on the car-select page
have the high-bit set. Reason unknown.
Transylvania off on
Conclusion:
As you can see from this table, there doesn't seem to be any evidence of a systematic usage of the high-bit as a switch between different resolutions. Even if it was built into the hardware it was definitely not used by the programmers. 'Neuromancer' and 'Dragon Wars' show that the setting of the high-bit was rather influenced by the character set, not the resolution.
In addition, 'Neuromancer', 'Maniac Mansion', 'Might&Magic 2' and especially 'Testdrive' show that programmers even mixed both high-bit on and high-bit off within the same picture but without any relation to the actual content of the picture, only perhaps as a result of some programming algorithm (e.g. shapes).
Cheers
Holger
Matt Jenkins
> But only if you have an RGB card. If you use composite video on a //e bit 7
> is ignored in DHR mode.
Sure? On my Composite color equipped //e programs like Publish It, or
Multiscribe/Beaglewrite still manage to remaine black and white when the
monitor is in 'color' mode, granted things are hard to read and fringy, but
on-off raster patterns don't suddenly change into colors.
Phoenyx
accessed in a 28 bit fashion IE 4 bytes. These bits are then used by
the hardware to display color sequences. There was more info on this
related to the Apex system which included support for DHR and even used
some GS fonts for text. Sadly, the text width was limited to about 20
columns or so. Many of the Apex functions use this 28 bit method, even
the SCRN routine which required a little manipulation to get the exact
bit required. As mentioned, the DHR on my //c is better than the GS'
output. This surprised me since the author used a GS for developing it.
Perhaps he used a composite monitor. Apex also offered a method to put
the system into a 'mono' mode. This also didn't work on my //c but does
work on my GS. This allows that it is possible to toggle the mono bit
but I don't know how this was done.
As for the 'other' DHR mode. It may be pointless since it will only be
available on the IIe. The GS, as mentioned won't support it and the //c
won't either because it has no user accessible annunciators.
--
Thank you for your time and interest. I hope it was helpful
or at least interesting.
Phoenyx,
Apple2 user since March 1984
Links to Phoenyx's pages:
preferred..... http://zip.to/Phoenyx_A2
alternate..... http://www.tinyangeldesigns.com/Apple2
David Wilson
>In comp.sys.apple2 David Wilson <da...@uow.edu.au> wrote:
>> But only if you have an RGB card. If you use composite video on a //e bit 7
>> is ignored in DHR mode.
>Sure? On my Composite color equipped //e programs like Publish It, or
>Multiscribe/Beaglewrite still manage to remaine black and white when the
>monitor is in 'color' mode, granted things are hard to read and fringy, but
>on-off raster patterns don't suddenly change into colors.
Yes, I have the //e Tech Reference Manual and Jim Sather's "Understanding the
Apple IIe". In HiRes mode bit 7 determines the color set by causing a 1/2
pixel shift in the output bitstream. In Double HiRes you are putting pixels
out at 14MHz already so no shifting can take place. You only have 560 pixels
to display and that is 7x80.
With composite video you effectively always have a line of 560 pixels of
black or white. The color burst tells the monitor to interpret this as color.
With RGB cards the otherwise unused bit 7 in DHR can be used to modify
how the color is generated by the RGB card.
Roger Johnstone
----------
In article <39BC49F0...@dcnet2000.com>, Phoenyx <qua...@dcnet2000.com>
wrote:
>Apex also offered a method to put
>the system into a 'mono' mode. This also didn't work on my //c but does
>work on my GS. This allows that it is possible to toggle the mono bit
>but I don't know how this was done.
On the IIgs only, if you go into the control panel you can set the display
to monochrome. If you have an RGB display it will then display mono in DHR
mode, colour in all other modes. For a composite display I think it switches
all modes to mono ouput. Some programs check if they're running on a IIgs
and will override the setting when they want to display DHR text. They then
switch back when the program quits.
Roger Johnstone, Invercargill, New Zealand
Apple II - Future Cop:LAPD - Warcraft II
http://homepages.ihug.co.nz/~rojaws
------------------------------------------
There are two ways to write error-free programs. Only the third one works.
Arkain
There are 14 edges in the clock pulse before the Video Phase signal falls.
In 40 column mode, the rising edges of these pulses are used to both
generate a 7MHz clock and load data bits onto the video bus. In B&W mode,
the rising edges of the 7MHz signal are used to shift the bits out onto the
video display. In color mode a 3.5MHz burst causes the bits to be shifted
out on the falling dges instead.
In 80 column mode, the only difference is that no 7MHz signal is generated.
The rising edges of the 14MHz signal is used to shift the data onto the
display. Once again, a 3.5MHz color-burst signal causes the bits to shift on
the falling edges of the clock in color mode.
Even in 80 column mode, you get a 1/2 pixel shift. This is why 80 column
text in mixed mode under a hires display is prone to color-bleeding on
composite displays. The 1/2 pixel shift is better described as a phase
shift.
As it turns out, there is a color generator table in the character ROM that
the system uses to display colorized blocks on the screen. It seems that in
DHGR mode, if bit 7 of the byte read is clear, then the color table is
accessed to grab a color pattern. If the bit is high then the data is
displayed in the same way as the HGR display. It seems that only the even
byte Aux Memory bit 7 actually matters, but I'm still testing this... I came
to this conclusion from using tests at the Monitor, but since the Monitor
plays with soft-switches itself, it may have been corrupting my results. I'm
writing a pixel-level driver in assembly to do further testing.
Arkain
David Wilson <da...@uow.edu.au> wrote in message
news:39bc35eb$1...@news.uow.edu.au...
> Matt Jenkins <m...@bilby.cs.rmit.edu.au> writes:
>
> Yes, I have the file://e Tech Reference Manual and Jim Sather's
Arkain
annunicators. If it didn't, you wouldn't be able to do DHGR graphics on it
at all!
DHGR graphics do seem to be a 28 bit block. It seems that the only bit that
changes the graphics from color to B&W is bit 7 from the 1st aux byte in
each 4 byte column. If it's on then you get B&W dots(phase shifted of
course) otherwise you get color blocks.
APEX was probably limited in text width due to that it used the 140 color
blocks instead of the 560 B&W dots. Since it takes a horizontal minimum of 6
character dots + 1 space dot to display reasonably clear text...
Arkain
Phoenyx <qua...@dcnet2000.com> wrote in message
news:39BC49F0...@dcnet2000.com...
> I think you will find this because the DHR memory is supposed to be
> accessed in a 28 bit fashion IE 4 bytes. These bits are then used by
> the hardware to display color sequences. There was more info on this
> related to the Apex system which included support for DHR and even used
> some GS fonts for text. Sadly, the text width was limited to about 20
> columns or so. Many of the Apex functions use this 28 bit method, even
> the SCRN routine which required a little manipulation to get the exact
> bit required. As mentioned, the DHR on my file://c is better than the GS'
> output. This surprised me since the author used a GS for developing it.
> Perhaps he used a composite monitor. Apex also offered a method to put
> the system into a 'mono' mode. This also didn't work on my file://c but
does
> work on my GS. This allows that it is possible to toggle the mono bit
> but I don't know how this was done.
>
> As for the 'other' DHR mode. It may be pointless since it will only be
> available on the IIe. The GS, as mentioned won't support it and the
file://c
Jeff Blakeney
wrote:
>Even in 80 column mode, you get a 1/2 pixel shift. This is why 80 column
>text in mixed mode under a hires display is prone to color-bleeding on
>composite displays. The 1/2 pixel shift is better described as a phase
>shift.
I don't know the exact details of how everything works but I have
never seen a half pixel shift in 80 column or DHR mode. If you can
get a half pixel shift, then it should be possible to write a program
that will display 1120 pixels across the screen (just like you can get
560 pixels on a regular HR screen). This requires using a monochrome
monitor, though.
The reason you get colour fringes on text in mixed graphics/text mode
is because the colour burst signal is on. When you are in text only
mode, the colour burst signal is turned off so you don't see any
colour fringes. However, there is no way to control the colour burst
using software. It is done automatically by the hardware.
+------------------------------------------------------------------------+
| Jeff Blakeney - Dean of the Apple II University in A2Pro on Delphi |
| Delphi Apple II Forums Web Pages |
| A2: http://www.delphi.com/apple2 A2Pro: http://www.delphi.com/a2pro |
+------------------------------------------------------------------------+
Jeff Blakeney
wrote:
>The IIgs, as far as I know, only uses mode 2. This is not surprising since
>that's the only mode documented in the IIe technical reference manual.
It isn't surprising to me either as that is the way I've always heard
that it worked. The IIgs added an address that software could modify
to switch between colour and monochrome modes but none of the other
models of Apple II have this feature built in. It would have to be
added by an expansion card.
If these modes can't be reproduced on a 128k IIe, a IIc, a IIc+ or a
IIgs, then they are not Apple II modes and therefore must be the
result of special hardware.
The Laser 128s have two modes that don't exist on any Apple IIs.
280x384 and 560x384 but I wouldn't call either of them Apple II
display modes even if there is some software that will take advantage
of the special hardware it is being run on.
>Like I said before: The color burst signal is never turned off in DHGR
>mode... at least not on a composite monitor. This leaves the screen with 560
>color-bleeding horizontal dots. Depending on the position of the dot, it
>seems you'll still get some subset of the 14 colors, but in a dot that's 1/4
>the size of the normal DHGR pixel. This means that it will normally appear
>that the screen is still in full color mode when it's not.
In 140x192 mode, each pixel is made up of a pattern of 4 pixels. The
display hardware simply takes these patterns of pixels and displays
them as colours. For example, using a 0 to mean the pixel is turned
off and 1 to mean the pixel is turned on, 1111 gives you a white 140
mode pixel, 0000 gives you a black 140 mode pixel and 0101 gives you a
grey 140 mode pixel.
The 140x192 mode is a logical mode. It is used to make dealing with
colour easier. However, the bit pattern of a 140 mode pixel adjacent
to another 140 mode pixel can affect the resulting colours that get
displayed in those two 140 mode pixels due to the way the colours are
produced so this mode isn't really the best way to think about the
display either.
>The easiest way to tell the difference is to populate the screen with 80
>column bit-mapped text. Each block, 1 byte wide & 8 rows tall, should be
>used to make a character. In mode 1 you'll be able to read whatever text you
>put on the screen, but you won't be able to predict the colors using the
>mode 2 method. In mode 2, the text will be harder to read, but the colors
>will be just what you expected.
When I get a chance I will do more testing but I really don't think I
will get any different results than I am currently getting.
>As for mode 3, the proof of it is in the fact that games like Test Drive
>display text clearly on a IIe, but blur the text with extra color blocks on
>a IIgs. If the mode were strictly mode 2, then the text would always show
>with color on the edges.
I'd have to check that out but I think my Test Drive disk died on me
ages ago (I think my little brother killed it). However, I still see
no way for graphic text to be displayed without colouring fringing
without special hardware (something other that the Extended 80 Column
Card) or by having the characters designed and placed in such a way
that no colour fringing will occur.
Arkain
>
> I don't know the exact details of how everything works but I have
> never seen a half pixel shift in 80 column or DHR mode. If you can
> get a half pixel shift, then it should be possible to write a program
> that will display 1120 pixels across the screen (just like you can get
> 560 pixels on a regular HR screen). This requires using a monochrome
> monitor, though.
1120 pixels? Not possible since all 560 pixels are shifted. There is simply
no place to draw any more pixels, not to mention no data to associate with
them. Remember, this is a phase shift(a delay in the timing) not a move to
new discrete set of 1/2 pixels. Not to mention that the display would have
to be driven by at least a 28MHz clock!
> The reason you get colour fringes on text in mixed graphics/text mode
> is because the colour burst signal is on.
Correct. The color burst signal produces timing delays in the pixels that
are shifted onto the screen. These shifts are what produces the colors. The
140x192 mode of DHGR fetches it's pixel data from character ROM based on the
patterns stored in the data stream. This is why both aux and main memory
bytes are fetched simultaneously. This allows 140x192 to use the same color
tables that 40x48 uses, and thus produce the same colors.
> When you are in text only
> mode, the colour burst signal is turned off so you don't see any
> colour fringes. However, there is no way to control the colour burst
> using software. It is done automatically by the hardware.
Also correct. Now here's the fun part. Although the 140x192 is called
"double high-resolultion" because it is effectively 140x192x16 where hires
is only effectively 140x192x6(or 8) it actually acts more like a Super LoRes
because it runs using the same output method as 40x48 lores graphics. When
bit 7 of the aux byte in an even column is turned on, the display switches
from using the lores display method to using the hires display method. This
560x192 mode acts just like hires with the exception that the PAL unit
always receives a 0 for data bit 7 so you can only expect either purple or
blue fringes, if any at all.
Why only bit 7 from an even byte? This is mostly speculation from the tests
I've done but...
Since using the lores color data in character ROM requires it to fetch a
different pattern depending on the address of the byte(even or odd), the low
bit of the address A0 is used to signify which pattern block to fetch the
color pattern from. On the way to the block, A0 is used to latch aux bit 7
if A0 is low. The contents of the latch go on to select the lores hardware
if the latch bit is low or the hires hardware if the latch bit is high.
This is hte only model I can think of that is cheap, fast, and produces the
effects I have been seeing on my TV screen.
Arkain
Phoenyx
didn't say there weren't any, only that they can't be accessed by user
software. I'm quite sure the hardware has the means to deal with this.
BTW, this comes straight from the 2c technical manual and my experience
with testing this fact.
I'm sure there could be another mode just as it is possible to put text
in various areas of the lores screen. My understanding of this is based
on Apple Inc info and others.
BTW, I'm not being sarcastic, I remember reading a technique for putting
text on a lores screen.
Arkain
difference.
If AN3 isn't user accessible, then how does one enable DHGR in software on a
IIc? If you can't toggle AN3 in software, then the PAL will continue to
force all graphics to be shifted out at 7MHz, i.e. no DHGR. So how exactlly
does it work if AN3 isn't user accessible?
Arkain
"Phoenyx" <qua...@dcnet2000.com> wrote in message
news:39BDADDA...@dcnet2000.com...
Phoenyx
> on a IIc? If you can't toggle AN3 in software, then the PAL will
> continue to force all graphics to be shifted out at 7MHz, i.e. no DHGR.
> So how exactlly does it work if AN3 isn't user accessible?
AFAIK, it is done in the hardware. I have researched some of this since
it didn't make sense. Dhires has always been a bit of a mystery to me
even with all the reading I have done on it. I have a basic understanding
of how the bitmaps work on the screen, just not at the hardware level.
IIRC, DHR mode is turned on by the soft switches in the $c000+ area I
forget the exact switches though.
I was also under the impression that your method of turning on the DHR
mode was not sanctioned by Apple Inc due to hardware issues. This may
also be why the capabilities of an extra screen mode was never mentioned.
It would not be compatible across the 8 bit systems.
Arkain
> > If AN3 isn't user accessible, then how does one enable DHGR in software
> > on a IIc? If you can't toggle AN3 in software, then the PAL will
> > continue to force all graphics to be shifted out at 7MHz, i.e. no DHGR.
> > So how exactlly does it work if AN3 isn't user accessible?
>
> AFAIK, it is done in the hardware. I have researched some of this since
> it didn't make sense. Dhires has always been a bit of a mystery to me
> even with all the reading I have done on it. I have a basic understanding
> of how the bitmaps work on the screen, just not at the hardware level.
> IIRC, DHR mode is turned on by the soft switches in the $c000+ area I
> forget the exact switches though.
$C00D ->Turn On 80 Columns
$C050 ->Turn Graphics On
$C057 ->Make It Hires
$C05E ->Turn off AN3
This sequence works on a IIc and a IIe, but if AN3 isn't user accessible
then $C05E, $C05F & $C07F bit7 must all be connected to some other circuit
to enable DHGR mode. If not then IIe DHGR games shouldn't work on a IIc, but
they do.
> I was also under the impression that your method of turning on the DHR
> mode was not sanctioned by Apple Inc due to hardware issues. This may
> also be why the capabilities of an extra screen mode was never mentioned.
> It would not be compatible across the 8 bit systems.
I am left to wonder about that. If the method I'm using wasn't "sanctioned
by Apple" then why did they write a DHGR ampersand driver that they bundled
with the Ex. 80Col. AppleColor card? Why would their manual list an
un-sanctioned method as the "proper way" to enable the various modes?
Seems that the only way to get a clean answer to these questions is to
contact Walt Broedner. If he doesn't remember, then we'll probably be left
guessing about this one.
Arkain
David Wilson
>$C00D ->Turn On 80 Columns
>$C050 ->Turn Graphics On
>$C057 ->Make It Hires
>$C05E ->Turn off AN3
These are all documented on pages 95-96 of the Apple IIc Technical Reference
Manual. The only proviso is that to access the DHiRes switch (AN3) at $C05E/F
the IOUDis switch must be on (IOUDis On = write to $C07E, IOUDis Off = write
to $C07F, IOUDis status = read $C07E bit 7 (1 = off) [it should have been
called IOUEnable and on/off swapped in my opinion].
The IOUDis switch controls access to locations $C058..C05F.
On page 97 there is a table listing all the softswitch combinations required
to display all possible modes (all 15 of them). As an example they give the
following code to switch into mixed 80 column and double-high-resolution mode
display page 1:
STA $C00D ; turns on 80Col, firmware turns on 80Store
LDA $C054 ; turns off Page2 (STA would have worked as well)
STA $C050 ; turns off text (turns on graphics)
STA $C053 ; turns on MIXED (works now that TEXT is off)
STA $C057 ; Turns on HIRES (ditto)
STA $C07E ; Makes sure IOUDis is on so that DHiRes access ok
LDA $C05E ; turns on DHiRes (works now that IOUDis is on)