In article <394F1D43.833D0DFD@dcnet2000.com>, Phoenyx wrote: >I didn't realize you needed info for DHR. Here's what I have >from my 2c (Apple version) reference. As you know, the DHR mode >is activated vi soft switches. Like wise, it uses data banks >from main ram and aux ram, and follows the HGR mapping method. >One half of the data is stored in aux ram. The screen size is >560x192. [ Good overall summary snipped ... ] >The GS DHR colors are a little different to the 2c and 2e. You >can see the effect of this by comparing a 2e screen to a GS >screen. I remember the GS has extra soft switches that modifies >the graphics. As far as I can find out this is a GS feature. I >know this, 'cause I used to beta test for the author. He had a >GS and a Lazier, so the Lazier may be able to handle this color >variance. The best test for this is the freeware APEX system. >It has several graphics program. I wasn't aware of any color differences between a //gs and a //e or //c. Do you know any more details on this? >Here comes the more technical stuff. :-) >The bytes in the main memory and aux memory pages are displayed >in the same manner as the 80 column text mode. Of each pair of >identical addresses, the aux memory is displayed first. Unlike >normal hi-res, DHR has no restrictions on which colors can be >adjacent. Color is determined by any 4 adjacent dots. Ah, there's the rub. Color is not determined by "any" 4 adjacent dots. Simple experiment: Load memory with all 0's, and then stick a 1 in memory in the middle of the screen such that you think you're going to get dark gray: >GS color values (bits for color) This chart is based on info >from the Apex system. > >black 0000 >drk gray 0001 >brown 0010 >purple 0011 >blue 0100 >drk green 0101 >orange 0110 >red 0111 >pink 1000 >yellow 1001 >green 1010 >lt blue 1011 >drk blue 1100 >lt green 1101 >lt gray 1110 >white 1111 There are two ways to interpret the "4 adjacent dots" phrase. One interpretation is that the DHR color screen is really 140 independent colorizable positions, each 4 pixels wide (where lets assume you always have 560 pixels across). In that case, we should see a dark gray patch 4 pixels wide. We do not. What you actually see is a dark gray dot 1 pixel wide. The bit pattern matters for the coloring! Another interpretation is to view the screen as 560 groups of 4 pixels each. Color each pixel according to it's surrounding group of pixels. What this means for my example is for the 4 pixels around my one bit which I've set, I'd get (in order): Dark Gray, Brown, Blue, and then Pink. (since the '1' is shifting through those values). Again, that's not what you get either. Again, I'm looking into emulating a GS here, and I think it's a little different than a //e (but not too much). What I see happening is basically a "same as before" circuitry that does think colors should start on the 140 colorizable position boundaries. But if it thinks the first few bits of the next position are just the same color as the previous position, it colors those pixels the same as the last color. When it sees a bit which shows that it's wrong, it changes colors. This algorithm gets the single dark gray dot right. However, if it were that simple, I'd have implemented it already. But the above algorithm gets some cases wrong, and I don't have my notes handy. So I'm looking for input from anyone who has figured out the DHR coloring scheme. I have figured out that pixels more than 4 away do not affect the color. So KEGS implements DHR using a lookup table--using a 12-bit index, it returns 4 correct pixel values (the 4 in the middle) to write into display memory. This way, I can make the algorithm for determining the colors as slow as I want and not slow KEGS down any. >As for the hires, there is no yellow or brown colors. The >primary colors are black (2), white (2), blue, orange, green, >purple. Although not in that order. All other colors were a >combination of different colors, dithered I guess. You can get more colors (one pixel-wide) at the byte boundary if the hi-order bit differs between the two bytes. There was a discussion on this from Jonathan Schattke on Mar 4, 2000 in comp.sys.apple2 which explained it very well. I'll have KEGS implement that, too. It turns out you can get 12 of the 16 lo-res colors (I didn't know you could get so many). I also don't know of any real program which uses this (but many real programs take advantage of the DHR coloring scheme to make readable text on the DHR screen). >Thanks again for a really great GS emulator. I am always >telling people about it's advantages. At least one of which >allows you to manipulate files on SCSI drives which can be be >used by an Apple II. I have verified this in the main NG. From >a couple of people. Thanks. I've got some small fixes that I did a while ago that I should release (mostly compatability stuff). It's been hectic around here lately. >Thank you for your time and interest. I hope it was helpful >or at least interesting. It's always good to spread Apple // info. >Phoenyx, > >Apple2 user since March 1984 Kent Dickey kentd@cup.hp.com Sorry. I've been out-of-town. I just got a chance to check the boards again today. I've been reading through my manuals again, and it appears that I was mistaken. It seems that DHGR modes 2&3 may have been AppleColor specific after all. On page 5 of the Extended 80 Column Text/AppleColor Adapter Card(long name, isn't it?) manual it states: "The Extended 80 Column Text/AppleColor Card, unlike the Extended 80 Column Text Card, also provides the following new display format options for RGB type monitors: * Mode 1: 560 pixels X 192 pixels with monochrome only * Mode 2: 140 pixels X 192 pixels with full 16 color capability * Mode 3: mix 560x192 pixels and 140x192 pixels anywhere on screen" From page 58, these are the steps to enable the various modes from the monitor: Mode 1: B&W 560x192 C00C:0 C05E C05F C05E C05F C00D:0 C05E Mode 2: Color 140x192 C00D:0 C05E C05F C05E C05F C05E Mode 3: (Mixed Mode) C00C:0 C05E C05F C00D:0 C05E C05F C05E At least in the //e the color mode is simple. It basically looks like this x20: | AUX | MAIN | AUX | MAIN | 6 5 4 3 2 1 0 6 5 4 3 2 1 0 6 5 4 3 2 1 0 6 5 4 3 2 1 0 \pixel 0/\pixel 1/\pixel 2/\pixel 3/\pixel 4/\pixel 5/\pixel 6/ I had even written a mediocre driver to verify this. It worked like a charm. Too bad it died with my Apple2 :-( As for the IIgs... I dunno. I've never had the fortune of owning a IIgs, but from the way you described the mode it seems like the SuperHires display circuitry is interfering with the DHGR color mode... but that's only a guess. As far as documenting all of the details that I have available, I'll consider that *AFTER* I finish my emulator. About that 1/4 track idea... I've never seen or tripped over any details that stated that the disk state logic was able to handle quarter steps. Where did you find that info? About the new disk format... for that I will release the specs when it's settled and before my emulator is done. I think think the Apple2 emulator community could use a single standard-like format capable of properly handling all Apple2 software.