[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DHGR Correction for KEGS32 & AppleWin
- Subject: Re: DHGR Correction for KEGS32 & AppleWin
- From: "mdj" <mdj.mdj@gmail.com>
- Date: 15 May 2006 06:19:04 -0700
- Complaints-to: groups-abuse@google.com
- In-reply-to: <g0e9g.71769$F_3.25386@newssvr29.news.prodigy.net>
- Injection-info: j33g2000cwa.googlegroups.com; posting-host=220.237.91.208; posting-account=W_jMEA0AAAAZdNaersJnc-7Hjv-SIC8Q
- Newsgroups: comp.sys.apple2
- Organization: http://groups.google.com
- References: <g0e9g.71769$F_3.25386@newssvr29.news.prodigy.net>
- User-agent: G2/0.2
- Xref: g2news2.google.com comp.sys.apple2:7639
Bryan,
I'm unsure of what it is you're trying to achieve here. Do you feel
that most emulators get the mapping wrong? I highly doubt that this is
the case. How did you determine that the emulators mismatch the
colours? By subjectively comparing an emulator on one monitor to a real
IIGS on another? Surely not!
If the emulators appear to be mapping the colours incorrectly, I'd
venture that it's because the emulators choose to more closely mimic
the composite video signals produced by all Apple II's. Remember, the
IIGS's RGB output is only an approximation of the quasi-NTSC signal
produced by the composite video out. You are probably correct that the
IIGS approximation is 'wrong', it is after all only 4 bits of
resolution per colour channel.
I'm sure if you think about it, you'll realise there are more creative
ways of figuring out which exact value the IIGS uses for each DHGR
colour, using only the documentation and some software. And considering
the IIGS's overscan video border, you might find the path you're
heading down to be somewhat harder that it first seems.
Matt