In this one, some single pixel color and double pixel color can be seen. And the CRT I'm using on these is acting goofy. There are some little, smaller pixel artifacts not actually seen on a display operating properly. I have yet to track this down. It may be my //e too. Ignore those. The brighter, pixel sized parts of the image are what the user is supposed to see. I went ahead and captured a monochrome image to help.
The teardrop shape at center is all red pixels, except for a couple, which are blue, each stand alone, about as tall as they are wide. On most other computers from this era that run at 2 bits per pixel, all of those would be wider pixels and a very different look.
I attached another one with the artifacts removed. Man, that display / computer combination is putting a lot of extra stuff on the screen! Project for another day. I mostly don't care and things look fine, for the most part.
One last edit: I attached one from a monochrome NTSC display. It's the PVM display doing weird things. The Apple appears to be doing exactly what it is supposed to.
Ignore the extra artifacts in the other images. That's something to do with that display and its advanced filtering on composite signals.
Finally, this picture is from a modern, "homebrew" game written recently by an Apple 2 enthusiast.
When two pixels are used together, there is color fringing, but for the most part the text comes off as white and very legible.
This picture, when displayed on your current display system, would turn out pretty much as intended.
Some add on RGB / graphics cards did a similar 2bpp conversion with similar artifacts, BTW. It's not like people haven't ran with that sort of display in the past.
I'm only posting these in case there is interest in higher accuracy.
If you double the Propeller 2bpp display resolution, and set the colors for each frame, 7 pixels per frame, you can get the right colors on the right pixels.
But, then the color info isn't there on a simple 1:1 2bpp lookup...
It's a hard display in these ways.
Earlier I mentioned lookup tables. With the resolution doubled, one could look up a byte, in an odd or even byte table containing words that hold the 2bpp pixel values. (These don't account for the byte boundary conditions, but are right otherwise)
Say the Apple byte had this as an even byte: 0_1010110
The 2bpp pixels would be: 01_00_01_00_11_11_00
And if it were this: 0_1010111
The 2bpp pixels would be: 01_00_01_00_11_11_11
But, if it were this: 0_1010101
The 2bpp pixels would be: 01_00_01_00_01_00_01
Two tables in the HUB, one for odd, one for even bytes would do it.
And then the display, instead of being 140x192 would be 280x192.
Edit: That won't even work, because there is the case of a "11" pattern carrying across the even and odd bytes!
Another edit: If the even and odd tables were 256 entries long, you could use the last bit of the previous byte as the high bit in the table and handle that case, meaning two 256 word tables total. Where there are two color "pixels" together, say pattern 0101 and 1010, the table could fill in like this:
0101 = 00_01_00_01 (this is technically accurate and would show the vertical striping my CRT did)
0101 = 01*_01_01_01 (would show a single, wider color pixel, just like the display scheme you have now does, and how lower resolution TV's show it too.) *depending on the state of the bit displayed before, and it may come from the other byte.
Maybe it's better to express it this way:
010_0101 = 00*_10_00_00_01_01_01 (the space between the pixels generally gets the color on many displays depending on how sharp they are)
*depending on bit state displayed prior
But, it would be able to handle this and show a single color pixel:
000100 = 00_00_00_01_00_00
Here is a look at the boundary case:
0_000_0001 0_100_0000 <-- There is a white pixel at the byte boundaries, because in terms of the display, it sees this:
00000011000000
And the color cycle boundaries look like this:
00_00_00_11_00_00_00
The last bit displayed in the byte prior can impact the color of the first one displayed from the next byte. That's impacting some of the text on the display you have right now.
It's a hard display to do simply. Maybe what you have is good enough. Emulator authors ended up modeling the NTSC color burst so pixel color by position happened more or less like it does on a real analog display. The table lookups I described, and running the Propeller at 280x192 will deliver an accurate, and better than CRT display, if you fill in between color pixels as I described above. Not doing that delivers "perfect CRT" look, with vertical banding. Filling in delivers, "70's and 80's era TV look."
Not being a Propeller user, I just looked up pin spacing for Prop 2. Pin spacing of .4mm is way beyond being hand solderable. A major barrier for anyone wanting to assemble their own retro Apple.
So I would ask for a daughterboard with a mounted processor. But then I noticed you can just use Parallax' own evaluation board as a daughter board!
It's bigger than necessary, but you could also take advantage of its existing flash, SD card, and power supply (the design which I understand is critical anyway)
I think you have an old P2 footprint as P2 is 100 pin 0.5mm pitch. Still close but doable but paste and reflow is much easier. The hardest part by hand is the ground pad underneath.
Thanks guys. Thank you @potatohead for the pictures. I only have the Apple Win emulator to go off of, so it's nice to see something that's not emulated. All things considered I'm really happy with how it came out. If I try to emulate all of the specific nuances of the NTSC color burst and old displays, I think I would go crazy. Who knows maybe I'm already there . But for now I'm going to keep it simple and stick to what I have. It could also be that my phone takes crummy pictures, but when I compare my screen to the Apple Win emulator in RGB monitor mode it looks pretty close to me. The P2 with its streamer and ability to feed in a lookup table and more color options might be able to get things a little closer possibly, although even then it's not going to be perfect.
Remember folks when the Woz and Mr. Jobs designed their amazing system, it was only available for delivering NTSC color to a matching Color TV set via an RF gadget, or to a monitor.
The idea that we'd be using VGA or even CGA output then, heck even HDTV display technology, was still a part of science fiction.
That was why when I first saw @"Phil Pilgrim (PhiPi)" Prop BackPack device working I was amazed at it, and the ideas behind it followed those created by Don Lancaster for his TV Typewriter cookbook ideas. That fellow also wrote two books called Cheap Video Cookbook, and Son of Cheap Video Cookbook, and those three ideas were considered amazing then.
Sure could. But is there time for that during a waitvid? (P1 waitvid)
If the whole screen is processed, then a few rules would make sense for sure.
And to be clear, I was not describing the fringe effect. That requires modeling the signal. It was just a pixel accurate display. To do that requires a 280x192, not 149x192 display buffer, or by scanline driver.
Remember folks when the Woz and Mr. Jobs designed their amazing system, it was only available for delivering NTSC color to a matching Color TV set via an RF gadget, or to a monitor.
The idea that we'd be using VGA or even CGA output then, heck even HDTV display technology, was still a part of science fiction.
That was why when I first saw @"Phil Pilgrim (PhiPi)" Prop BackPack device working I was amazed at it, and the ideas behind it followed those created by Don Lancaster for his TV Typewriter cookbook ideas. That fellow also wrote two books called Cheap Video Cookbook, and Son of Cheap Video Cookbook, and those three ideas were considered amazing then.
Wow, just checked out the Prop BackPack. That is cool! Nice compact design and has some neat features.
My gateway into electronics and video was the Hydra. That was also when I first discovered Parallax. Of course, at the time I knew next to nothing about electronics (not much has changed there ). I tried to create my own Hydra on a breadboard, which didn't really end well. I did manage to get it kinda working, but the video portion never really worked very well.
It amazes me that engineers like Woz could think up these complex circuits that had to display video and graphics and synchronize just perfectly with all these other components. I have a hard enough time trying to understand it now with all sorts of manuals and other folks trying to explain it to me.
How much room do you have on your Propeller that is doing the display? Any left?
If I remember correctly I do have some program space left. I have at least two cogs that I can recall. I was thinking it'd be neat to add in a composite output for the next board revision. The problem I'm running into though is that I've run out of pins on the P1. Most everything is being used to interface with my video RAM and the VGA. If I could somehow get one more pin I should be able to generate composite out, right?
If I could somehow get one more pin I should be able to generate composite out, right?
You need to generate at least 3 levels - white, black and sync (in theory also blanking, but that can be neglected). You can kinda jank it on 1 pin (not sure how that works, but there's code for it out there), but i'd use at least two (or 3 to match the standard P1 composite circuit).
To free up pins, you could use an external counter chip to control (some of) the VRAM address pins. That's one more chip though...
How are you doing the display right now? Is it copied to a VGA display buffer, or?
Yes, so I have vcfg set to VGA mode with a 4 color pallet. Then during my hires routine I'm copying out the pixel bytes to a buffer. Then in the active video portion of my VGA driver I have this:
mov pixel_cntr,#20 '40 columns/2 bytes per word
:vid_loop
rdword pixel_values,pixel_ptr1
add pixel_ptr1,#2
'odd byte
'test color write to z flag
test pixel_values, bit8 wz 'if zero then group 1 else group 2
if_z mov vid_colors, group1_vid_colors
if_nz mov vid_colors, group2_vid_colors
mov vscl,vscl_3pixel
waitvid vid_colors,pixel_values 'display 3 pixels of odd byte
'even byte
test pixel_values, bit7 wc 'move bit 7 from odd byte up so we can display it with even byte
muxc pixel_values, bit8
test pixel_values, bit15 wz 'if zero then group 1 else group 2
if_z mov vid_colors, group1_vid_colors
if_nz mov vid_colors, group2_vid_colors
shr pixel_values,#7 'shift out first 3.5 pixels
mov vscl,vscl_4pixel
waitvid vid_colors,pixel_values 'display 4 pixels of even byte
djnz pixel_cntr,#:vid_loop
Here's what I have for my pallet longs:
group1_vid_colors long $1F_0B_17_03 'white/green/magenta/black
group2_vid_colors long $1F_13_0F_03 'white/red(orange)/blue/black
and then for vscl:
vscl_4pixel long $000_02_008
vscl_3pixel long $000_02_006
Another potential approach to freeing some pins: share pins between VGA and composite (you will need to add some diodes to avoid crosstalk) and either manually switch it or autodetect which is connected (there's multiple ways this could be achieved - detecting termination, detecting presence of a VGA monitor's EDID, using an RCA socket with a mechanical switch and probably more).
Another potential approach to freeing some pins: share pins between VGA and composite (you will need to add some diodes to avoid crosstalk) and either manually switch it or autodetect which is connected (there's multiple ways this could be achieved - detecting termination, detecting presence of a VGA monitor's EDID, using an RCA socket with a mechanical switch and probably more).
I like that idea. There's a nice clearing just to the side of my VGA socket where I could probably fit a small RCA plug. A mechanical switch or even just some jumpers might work to route the signals.
So is the whole hi res buffer in the P1 when this code runs?
Yep, it's just continually updating that buffer. I should be able to maybe start a new cog and composite video generator that reads from that same buffer I would think right? Then use Wuerfel_21's idea to switch between the two connectors on the board. That seems like it might work. Maybe I could jerry rig a connector into my board somewhere and try it out.
@Jon_Thomasson said:
I started with the original Apple II schematic and quickly realized that there were going to be a few hurdles. There were several components like the keyboard encoder, DRAM, and 558 timer that were no longer manufactured.
Nice project, Jon. Just getting back into reviewing the last few months of projects. I learned about the Apple ][ with a "black" apple (Bell & Howell's educational version).
Regarding the 558 timer, and other no longer manufactured parts, you can typically find them on ebay or at surplus electronic stores.
Comments
The teardrop shape at center is all red pixels, except for a couple, which are blue, each stand alone, about as tall as they are wide. On most other computers from this era that run at 2 bits per pixel, all of those would be wider pixels and a very different look.
I attached another one with the artifacts removed. Man, that display / computer combination is putting a lot of extra stuff on the screen! Project for another day. I mostly don't care and things look fine, for the most part.
One last edit: I attached one from a monochrome NTSC display. It's the PVM display doing weird things. The Apple appears to be doing exactly what it is supposed to.
Ignore the extra artifacts in the other images. That's something to do with that display and its advanced filtering on composite signals.
When two pixels are used together, there is color fringing, but for the most part the text comes off as white and very legible.
This picture, when displayed on your current display system, would turn out pretty much as intended.
Some add on RGB / graphics cards did a similar 2bpp conversion with similar artifacts, BTW. It's not like people haven't ran with that sort of display in the past.
I'm only posting these in case there is interest in higher accuracy.
If you double the Propeller 2bpp display resolution, and set the colors for each frame, 7 pixels per frame, you can get the right colors on the right pixels.
But, then the color info isn't there on a simple 1:1 2bpp lookup...
It's a hard display in these ways.
Earlier I mentioned lookup tables. With the resolution doubled, one could look up a byte, in an odd or even byte table containing words that hold the 2bpp pixel values. (These don't account for the byte boundary conditions, but are right otherwise)
Say the Apple byte had this as an even byte: 0_1010110
The 2bpp pixels would be: 01_00_01_00_11_11_00
And if it were this: 0_1010111
The 2bpp pixels would be: 01_00_01_00_11_11_11
But, if it were this: 0_1010101
The 2bpp pixels would be: 01_00_01_00_01_00_01
Two tables in the HUB, one for odd, one for even bytes would do it.
And then the display, instead of being 140x192 would be 280x192.
Edit: That won't even work, because there is the case of a "11" pattern carrying across the even and odd bytes!
Another edit: If the even and odd tables were 256 entries long, you could use the last bit of the previous byte as the high bit in the table and handle that case, meaning two 256 word tables total. Where there are two color "pixels" together, say pattern 0101 and 1010, the table could fill in like this:
0101 = 00_01_00_01 (this is technically accurate and would show the vertical striping my CRT did)
0101 = 01*_01_01_01 (would show a single, wider color pixel, just like the display scheme you have now does, and how lower resolution TV's show it too.) *depending on the state of the bit displayed before, and it may come from the other byte.
Maybe it's better to express it this way:
010_0101 = 00*_10_00_00_01_01_01 (the space between the pixels generally gets the color on many displays depending on how sharp they are)
*depending on bit state displayed prior
But, it would be able to handle this and show a single color pixel:
000100 = 00_00_00_01_00_00
Here is a look at the boundary case:
0_000_0001 0_100_0000 <-- There is a white pixel at the byte boundaries, because in terms of the display, it sees this:
00000011000000
And the color cycle boundaries look like this:
00_00_00_11_00_00_00
The last bit displayed in the byte prior can impact the color of the first one displayed from the next byte. That's impacting some of the text on the display you have right now.
It's a hard display to do simply. Maybe what you have is good enough. Emulator authors ended up modeling the NTSC color burst so pixel color by position happened more or less like it does on a real analog display. The table lookups I described, and running the Propeller at 280x192 will deliver an accurate, and better than CRT display, if you fill in between color pixels as I described above. Not doing that delivers "perfect CRT" look, with vertical banding. Filling in delivers, "70's and 80's era TV look."
So I would ask for a daughterboard with a mounted processor. But then I noticed you can just use Parallax' own evaluation board as a daughter board!
It's bigger than necessary, but you could also take advantage of its existing flash, SD card, and power supply (the design which I understand is critical anyway)
The idea that we'd be using VGA or even CGA output then, heck even HDTV display technology, was still a part of science fiction.
That was why when I first saw @"Phil Pilgrim (PhiPi)" Prop BackPack device working I was amazed at it, and the ideas behind it followed those created by Don Lancaster for his TV Typewriter cookbook ideas. That fellow also wrote two books called Cheap Video Cookbook, and Son of Cheap Video Cookbook, and those three ideas were considered amazing then.
These are the possible colors, right?
x_0000000 = black
x_1111111 = white
0_0101010 = color a
0_1010101 = color b
1_0101010 = color c
1_1010101 = color d
Any two adjacent 1's in the lower seven bits would cease to excite the color demodulator in the TV.
If the whole screen is processed, then a few rules would make sense for sure.
And to be clear, I was not describing the fringe effect. That requires modeling the signal. It was just a pixel accurate display. To do that requires a 280x192, not 149x192 display buffer, or by scanline driver.
On P2, this all gets sorted in the LUT.
How much room do you have on your Propeller that is doing the display? Any left?
Wow, just checked out the Prop BackPack. That is cool! Nice compact design and has some neat features.
My gateway into electronics and video was the Hydra. That was also when I first discovered Parallax. Of course, at the time I knew next to nothing about electronics (not much has changed there
It amazes me that engineers like Woz could think up these complex circuits that had to display video and graphics and synchronize just perfectly with all these other components. I have a hard enough time trying to understand it now with all sorts of manuals and other folks trying to explain it to me.
If I remember correctly I do have some program space left. I have at least two cogs that I can recall. I was thinking it'd be neat to add in a composite output for the next board revision. The problem I'm running into though is that I've run out of pins on the P1. Most everything is being used to interface with my video RAM and the VGA. If I could somehow get one more pin I should be able to generate composite out, right?
Composite will take a few pins. And people like VGA anyway.
To free up pins, you could use an external counter chip to control (some of) the VRAM address pins. That's one more chip though...
Not me
Yes, so I have vcfg set to VGA mode with a 4 color pallet. Then during my hires routine I'm copying out the pixel bytes to a buffer. Then in the active video portion of my VGA driver I have this:
mov pixel_cntr,#20 '40 columns/2 bytes per word :vid_loop rdword pixel_values,pixel_ptr1 add pixel_ptr1,#2 'odd byte 'test color write to z flag test pixel_values, bit8 wz 'if zero then group 1 else group 2 if_z mov vid_colors, group1_vid_colors if_nz mov vid_colors, group2_vid_colors mov vscl,vscl_3pixel waitvid vid_colors,pixel_values 'display 3 pixels of odd byte 'even byte test pixel_values, bit7 wc 'move bit 7 from odd byte up so we can display it with even byte muxc pixel_values, bit8 test pixel_values, bit15 wz 'if zero then group 1 else group 2 if_z mov vid_colors, group1_vid_colors if_nz mov vid_colors, group2_vid_colors shr pixel_values,#7 'shift out first 3.5 pixels mov vscl,vscl_4pixel waitvid vid_colors,pixel_values 'display 4 pixels of even byte djnz pixel_cntr,#:vid_loopHere's what I have for my pallet longs:
and then for vscl:
I like that idea. There's a nice clearing just to the side of my VGA socket where I could probably fit a small RCA plug. A mechanical switch or even just some jumpers might work to route the signals.
Yep, it's just continually updating that buffer. I should be able to maybe start a new cog and composite video generator that reads from that same buffer I would think right? Then use Wuerfel_21's idea to switch between the two connectors on the board. That seems like it might work. Maybe I could jerry rig a connector into my board somewhere and try it out.
Just musing about an easy way to do the more accurate display.
Yes I believe so. At least one, maybe even two cogs free.
Now that is interesting. How does the speed compare to a 1MHz 6502? Did you post it somewhere?
What forth did you use on the 6502?
Nice project, Jon. Just getting back into reviewing the last few months of projects. I learned about the Apple ][ with a "black" apple (Bell & Howell's educational version).
Regarding the 558 timer, and other no longer manufactured parts, you can typically find them on ebay or at surplus electronic stores.
-Walter