mdj wrote:
Michael J. Mahon wrote:Jorge ChB wrote:Linards Ticmanis <ticmanis@gmx.de> wrote:Jorge ChB wrote:, windowed pixels that span 4 bits among consecutive 7 bits "bytes" that happen to alternate between main and aux memory banksI'd just like to add that these don't exist as such. Bits 113-114-115-116 on a line are no more (or less) of a pixel than bits 114-115-116-117 or bits 115-116-117-118.Linards, I'm not so sure... I believe that the "pixels" shouldn't be sitting across the boundaries of a single cycle of the color reference unless you want odd things to start happening. For example, that the color of your "pixel" becomes a function of the colors of the adjacent "pixels", an odd behavior for a (color) "picture element"... and the reason why the "pixels" should in this particular case (Apple II DHGR) better be conceptually grouped by 4 and starting from the first bit, not from the 2nd nor the 3rd nor the 4th. The RGB video output generated by a IIgs may well be against your theory too : I bet that the patterns below won't show on the screen a single white "pixel" moving from left to right, as would be the case if any 4 bits could be a single pixel: 1.- 11110000 -> 1 pixel, white 2.- 01111000 -> 2 pixels, 1st yellow, 2nd dark blue 3.- 00111100 -> 2 pixels, 1st orange, 2nd medium blue 4.- 00011110 -> 2 pixels, 1st magenta, 2nd aqua 5.- 00001111 -> 1 pixel, white Instead you'll get a single white pixel for patterns 1&5, and *two* adjacent pixels for patterns 2,3 and 4, of varying colors.On an NTSC monitor it will show up as a 4-pixel white block, shifting by one pixel. If it doesn't look that way on a IIgs, then the IIgs is not faithfully emulating NTSC (not too surprising, since most RGB cards didn't do it very well, either). Actually, an analog NTSC monitor will show some soft pastel transitions to white and back to black on the edges, but that's because of bandwidth limiting in the color circuits. (And it's why I suggest using a wider- than-4-bit sliding window for color mapping.)What exactly is the goal here? If the idea is to provide VGA compatible output to an 8 bit Apple II, then I'm not sure that figuring out how the IIgs does it is worthwhile - it really does to a very poor job of emulating the composite output. I would imagine that the better approach would actually to be do the colour decoding in the analog domain. This will get a much more faithful representation of composite colour than any form of digital domain decoding will. The lack of digital resolution is a real limitation in this regard (IMHO) How you go about it depends a great deal on what display you want to drive. If the goal is to drive modern digital panels, then of course the approach taken would be rather different.
Actually, the "sliding window" approach, with 8 or 12 bits, would do a fine job of creating accurate artifacts. This should be particularly easy to try in an emulator, but it could also be used with a hardware VGA adapter. There would only be as many horizontal pixels as there are on an Apple II, so if you wanted to fill the screen, you'd have to scale it up, of course (integer multiples are easy). I'd just like to see a good RGB/VGA emulation of a composite display, so that many more things would look as they were designed to look. -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."