I thought I had it figured out, but for some reason purple and green
are flipped around. Does anyone have a good algorithm for converting
HGR to DHGR, accounting for half-pixels and other funky behaviors of
the video scanner?
JACE DHGR renderer is great and now lores and dhgr look spot-on (well,
maybe not as spot-on as open emulator, but well enough for me).
However, HGR has the frindge and NTSC artifacts correct but the low-
order colors need help. I really don't want to have to hack an
alternate palette for green/purple. Suggestions?
On Tue, 17 Jan 2012, BLuRry wrote:
> Does anyone have a good algorithm for converting HGR to DHGR, accounting > for half-pixels and other funky behaviors of the video scanner?
Yes, it's actually dead simple - render always in DHGR.
Text and LORES - double each bit.
HIRES - double each bit. If HGR byte has bit7=1 then shift the result one bit and append bit #6 from last HGR byte (not doubled). This is what the hardware does - delaying for one 14 MHz clock. For the leftmost HGR bytes on screen you can assume last latched bit #6 was zero if you don't want to simulate the video scanner address generation.
Here's how HIRES looks in my emulator RA2:
v = T_HLSB[p->dl & 0x7F];
if (p->dl & 0x80)
v = (v << 1) | p->dl6;
T_HLSB[128] is a bit-doubling table (7 bits -> 14 bits).
'v' is 14-bit result
'dl' is data latch, i.e. current HGR byte
'dl6' is bit #6 from last scanned HGR byte
> On Tue, 17 Jan 2012, BLuRry wrote:
> > Does anyone have a good algorithm for converting HGR to DHGR, accounting
> > for half-pixels and other funky behaviors of the video scanner?
> Yes, it's actually dead simple - render always in DHGR.
> Text and LORES - double each bit.
> HIRES - double each bit. If HGR byte has bit7=1 then shift the result one
> bit and append bit #6 from last HGR byte (not doubled). This is what the
> hardware does - delaying for one 14 MHz clock. For the leftmost HGR bytes
> on screen you can assume last latched bit #6 was zero if you don't want to
> simulate the video scanner address generation.
> Here's how HIRES looks in my emulator RA2:
> v = T_HLSB[p->dl & 0x7F];
> if (p->dl & 0x80)
> v = (v << 1) | p->dl6;
> T_HLSB[128] is a bit-doubling table (7 bits -> 14 bits).
> 'v' is 14-bit result
> 'dl' is data latch, i.e. current HGR byte
> 'dl6' is bit #6 from last scanned HGR byte
> On Tue, 17 Jan 2012, BLuRry wrote:
> > Does anyone have a good algorithm for converting HGR to DHGR, accounting
> > for half-pixels and other funky behaviors of the video scanner?
> Yes, it's actually dead simple - render always in DHGR.
> Text and LORES - double each bit.
> HIRES - double each bit. If HGR byte has bit7=1 then shift the result one
> bit and append bit #6 from last HGR byte (not doubled). This is what the
> hardware does - delaying for one 14 MHz clock. For the leftmost HGR bytes
> on screen you can assume last latched bit #6 was zero if you don't want to
> simulate the video scanner address generation.
> Here's how HIRES looks in my emulator RA2:
> v = T_HLSB[p->dl & 0x7F];
> if (p->dl & 0x80)
> v = (v << 1) | p->dl6;
> T_HLSB[128] is a bit-doubling table (7 bits -> 14 bits).
> 'v' is 14-bit result
> 'dl' is data latch, i.e. current HGR byte
> 'dl6' is bit #6 from last scanned HGR byte
> Hope that helps,
> -- Vlad
This is the strange part, when I do it that way then the hires palette
is totally flipped around, e.g. orange and blue appear as low-order
colors. When I correct my color lookup (invert the nibble values),
HGR looks OK but then DHGR and Lo-res have completely shuffled
palettes. I totally get what you're saying though. I think my color
mixup was because I was shifting for low-order to conform to the
palette and the bug is in there somewhere. It's tricky to implement
because I'm doing this as a table-lookup where the table represents
two consecutive bytes of HGR data and the resulting 28 bits of DHGR
that maps to it. Anyway, I'll work on the assumption that DHGR and Lo-
res rendering were at fault and go from there.
On Tue, 17 Jan 2012, BLuRry wrote:
> This is the strange part, when I do it that way then the hires palette
> is totally flipped around, e.g. orange and blue appear as low-order
> colors. When I correct my color lookup (invert the nibble values),
> HGR looks OK but then DHGR and Lo-res have completely shuffled
> palettes.
Check for MSB-LSB ordering? The code snippet I posted reverses the HGR bit positions through the table and then assumes MSB on left and LSB on right of screen for further processing.
> It's tricky to implement because I'm doing this as a table-lookup where > the table represents two consecutive bytes of HGR data
For the part of the table that has MSB=1 there is reliance on the previous byte. In other words you'd better index a table by [bit6_of_prev_byte, cur_byte] pairs and produce only 14 bits of output. This is 512-entry lookup table.
I'd suggest do it the slow way with the 'if' on a stream of bytes first, then go optimizing.
> On Tue, 17 Jan 2012, BLuRry wrote:
> > This is the strange part, when I do it that way then the hires palette
> > is totally flipped around, e.g. orange and blue appear as low-order
> > colors. When I correct my color lookup (invert the nibble values),
> > HGR looks OK but then DHGR and Lo-res have completely shuffled
> > palettes.
> Check for MSB-LSB ordering? The code snippet I posted reverses the HGR bit
> positions through the table and then assumes MSB on left and LSB on right
> of screen for further processing.
> > It's tricky to implement because I'm doing this as a table-lookup where
> > the table represents two consecutive bytes of HGR data
> For the part of the table that has MSB=1 there is reliance on the previous
> byte. In other words you'd better index a table by [bit6_of_prev_byte,
> cur_byte] pairs and produce only 14 bits of output. This is 512-entry
> lookup table.
> I'd suggest do it the slow way with the 'if' on a stream of bytes first,
> then go optimizing.
When I look @ the bit patterns for the hires colors, I can see what
you mean. Flipping bits so that LSB is on the left is how the
hardware does it. And I was pretty sure that most of my conversion
logic worked that way, but for some reason it isn't flipping it around
in a few places. Very strange. Guess I'll need to put in some junit
tests to sort this out since I know what assertions should be
correct. **scratches head**
> On Jan 18, 3:17 am, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote:
> > On Tue, 17 Jan 2012, BLuRry wrote:
> > > This is the strange part, when I do it that way then the hires palette
> > > is totally flipped around, e.g. orange and blue appear as low-order
> > > colors. When I correct my color lookup (invert the nibble values),
> > > HGR looks OK but then DHGR and Lo-res have completely shuffled
> > > palettes.
> > Check for MSB-LSB ordering? The code snippet I posted reverses the HGR bit
> > positions through the table and then assumes MSB on left and LSB on right
> > of screen for further processing.
> > > It's tricky to implement because I'm doing this as a table-lookup where
> > > the table represents two consecutive bytes of HGR data
> > For the part of the table that has MSB=1 there is reliance on the previous
> > byte. In other words you'd better index a table by [bit6_of_prev_byte,
> > cur_byte] pairs and produce only 14 bits of output. This is 512-entry
> > lookup table.
> > I'd suggest do it the slow way with the 'if' on a stream of bytes first,
> > then go optimizing.
> When I look @ the bit patterns for the hires colors, I can see what
> you mean. Flipping bits so that LSB is on the left is how the
> hardware does it. And I was pretty sure that most of my conversion
> logic worked that way, but for some reason it isn't flipping it around
> in a few places. Very strange. Guess I'll need to put in some junit
> tests to sort this out since I know what assertions should be
> correct. **scratches head**
> -Brendan
Ok -- Turns out there was one behavior of the video scanner I wasn't
aware of. The difference between HGR and DHGR wasn't a conversion
problem. I had the right algorithm. Well, I wound up writing
something more efficient after rewriting it over and over. When I
took my scanline renderer and had it shift the hires screen a half-bit
from the DHGR (or rather I should say that DHGR is shifted 1 bit right
compared to HGR) then everything works for both HGR and DHGR as it
should have in the first place -- no other hacks or workarounds
necessary.
1 bit shift for DHGR though?? I need to read Sather again I think.
I'm just glad the darn thing is working! After I clean up my messy
coding hacks I'll check it in and issue an official build.
Vladimir Ivanov <vlad...@XXXyahooXXX.com> writes:
> On Wed, 18 Jan 2012, BLuRry wrote:
>> 1 bit shift for DHGR though??
> Not likely. If you have setup with color monitor just try it.
80-column mode, and DHGR actually starts seven bits (14.318180 MHz
periods) sooner (one 80-column character width) than 40-column mode,
which explains the shift in colors if either you don't do the shift to
compensate, or you don't simulate the whole dot stream coming out of the
shift registers.
Try this on a IIe or IIc to see the effect:
1 D = 500
2 PR# 3: PRINT " "
5 GOTO 100
10 PRINT CHR$ (17);
20 FOR X = 1 to D: NEXT
30 PRINT CHR$ (18);
40 FOR X = 1 to D: NEXT
50 GOTO 10
100 HGR : POKE 49246,0
101 DATA 160,0,132,0,162,32,134,1,141,84,192,177,0,141,85,192,145,0,200
,208,243,230,1,202,208,238,96
102 FOR A = 768 TO 794: READ X: POKE A,X: NEXT
110 HCOLOR= 3: HPLOT 0,0: CALL 62454
120 GOTO 10
You will see the left and right borders moving left and right a bit as
the display switches from 80 columns to 40 columns and back.
On Sat, 21 Jan 2012, Jerry wrote:
> 80-column mode, and DHGR actually starts seven bits (14.318180 MHz
> periods) sooner (one 80-column character width) than 40-column mode,
> which explains the shift in colors if either you don't do the shift to
> compensate, or you don't simulate the whole dot stream coming out of the
> shift registers.
I see what you mean - what I forgot was that the aux page video data is displayed first. Thanks!
Jerry <awande...@yahoo.ca> wrote:
> 80-column mode, and DHGR actually starts seven bits (14.318180 MHz periods)
> sooner (one 80-column character width) than 40-column mode, which explains
> the shift in colors if either you don't do the shift to compensate, or you
> don't simulate the whole dot stream coming out of the shift registers.
I wanted to see how the IIgs does this, and of course it's different. I used a
different program, but it still switches between 40 and 80 column modes. Text
page 1 in main ram contains 'X' characters, while text page 1 in aux ram
contains 'O' characters. Here are the results:
On Jan 17, 9:32 am, BLuRry <brendan.rob...@gmail.com> wrote:
> I thought I had it figured out, but for some reason purple and green
> are flipped around. Does anyone have a good algorithm for converting
> HGR to DHGR, accounting for half-pixels and other funky behaviors of
> the video scanner?
> JACE DHGR renderer is great and now lores and dhgr look spot-on (well,
> maybe not as spot-on as open emulator, but well enough for me).
> However, HGR has the frindge and NTSC artifacts correct but the low-
> order colors need help. I really don't want to have to hack an
> alternate palette for green/purple. Suggestions?
> -Brendan
If still interested, I have 3 programs for converting HGR to DHGR.
One that does not take color into account, best for B/W
One that shows color correctly but only displays on half of the DHGR
screen
And the last one shows color correctly and fills the whole DHGR screen
