Has the Apple IIe video format ever been emulated with the prop?
cbmeeks
Posts: 634
Has anyone ever attempted to emulate the strange NTSC video format of the Apple IIe?
From what I read, it was basically a monochrome signal that are combined in quadrature with the colorburst signal (whatever that means...lol).
(loose quote ripped from WikiPedia).
Anyway, basically if you take 2 bits per colorburst cycle, you can get two colors (one bit on, one off), black (none on) or white (both on). Then by shifting the bits 90 degrees, you could get other colors.
So I was wondering if anyone ever tackled this.
Just thinking out-loud here, but what would it take to make the Propeddle computer a fully working Apple IIe clone? :-D (day dreaming a little...lol).
From what I read, it was basically a monochrome signal that are combined in quadrature with the colorburst signal (whatever that means...lol).
(loose quote ripped from WikiPedia).
Anyway, basically if you take 2 bits per colorburst cycle, you can get two colors (one bit on, one off), black (none on) or white (both on). Then by shifting the bits 90 degrees, you could get other colors.
So I was wondering if anyone ever tackled this.
Just thinking out-loud here, but what would it take to make the Propeddle computer a fully working Apple IIe clone? :-D (day dreaming a little...lol).
Comments
I'll have to go looking for it. I think it is NTSC 4x2 or something like that.
Because Apples use artifact color, colorburst needed to be in software to be consiatent. The Prop color generator can't be used.
The Nyan Cat driver also has the right signal, but will need to be hacked on to do it more like the Apple computers.
I don't remember the details about the 7 bits though. What's that about?
In the double high resolution mode they are just ignored.
The 7 pixels makes substitutes hard as color bit patterns cross byte boundaries.
Even bytes deliver one set of colors per bit pattern, odd bytes do another.
Artifacts are generally 2 bit patterns across the scanline.
https://en.m.wikipedia.org/wiki/Apple_II_graphics
The Apple ][ Hi-Res mode is pretty funky, starting with the X,Y to address mapping (which created the "Venetian blind" effect):
Address = BaseAddress + (Y & $07)<<10 + (Y & $38)<<4 + (Y & $40) + (Y & $C0)>>2 + (Y & $C0) >> 4 + X/7
Pixels are displayed MSB first with the MSB adding a phase shift. I believe the signal generation is fairly simple, but I can't recall offhand how it works.
I suspect you could create a Apple ][ hires graphics driver for the Propeller although it probably would require multiple cogs. One cog to fetch the bytes from memory in A2 order and translate the bytes to pixels and a second cog which would push the pixels out the WAITVID.
I was brainstorming some ideas and I was thinking something like this:
https://gist.github.com/cbmeeks/6482001471cf74573621
That would take all 8 cogs which I would be OK with (another propeller would be for audio)
The II family never had sprites but in my "vision" of an emulated IIe, it would be able to run legacy software (with near perfect video emulation...a pipe dream maybe...) and have some upgrades like a few sprites, re-definable colors, etc.
Each bit is shifted out at 2x colorburst (7.159MHz). If the MSB is set, the bit is delayed by 1/4 colorburst and the whole output is delayed by 1/8 colorburst. The Propeller video generator should be able to generate the same output - just use VGA mode at 8x colorburst.
And isn't that screen memory layout nuts??
Good point on the 560x192. I was readying that basically you have 560 pixel positions per scanline in HIRES mode. And with B/W and 7 pixel wide fonts gives you your 80 column display. Pretty slick.
But yeah, that color scheme is bizarre. So basically you have 280 "slots" per scanline and a color pixel can take up an entire slot or half of two slots (overlap). And that positions determines the color.
The more I read that book on the Apple IIe the more respect I have for the machine.
My NTSC 4x driver could probably handle the output duties with some minor tweaks (i.e. only outputting 28 bits/pixels per long to make the memory byte to output bit conversion easier), and converting it to a line-RAM rather than full bitmap.
Converting the Apple ][ bytes to pixels could be mostly handled via a lookup table (i.e. 0abcdefg -> ggffeeddccbbaa & 1abcdefg -> gffeeddccbba0). The only quirk is MSB=1 means the first bit/pixel is the same as the last bit/pixel from the previous byte.