Retro II - An Apple II Compatible 6502 Computer

13»

Comments

  • potatoheadpotatohead Posts: 10,093
    edited 2020-09-16 - 05:34:54
    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.





    3024 x 4032 - 5M
    392 x 354 - 41K
    612 x 482 - 93K
  • potatoheadpotatohead Posts: 10,093
    edited 2020-09-16 - 05:58:08
    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."



    3024 x 4032 - 4M
  • 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)
  • Cluso99Cluso99 Posts: 16,570
    edited 2020-09-16 - 10:10:10
    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 :smile: . 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.
  • Couldn't you have a rule that if you have two adjacent pixels set to 1, you would just show them as white, and forget about the fringe effect?

    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.
  • potatoheadpotatohead Posts: 10,093
    edited 2020-09-16 - 16:22:28
    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.

    On P2, this all gets sorted in the LUT.





  • All things considered I'm really happy with how it came out.
    You should be! Very cool project.

    How much room do you have on your Propeller that is doing the display? Any left?

  • 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 :smiley: ). 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.

  • potatohead wrote: »
    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?
  • potatoheadpotatohead Posts: 10,093
    edited 2020-09-16 - 17:08:45
    How are you doing the display right now? Is it copied to a VGA display buffer, or?

    Composite will take a few pins. And people like VGA anyway.




  • Wuerfel_21Wuerfel_21 Posts: 878
    edited 2020-09-16 - 17:17:29
    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...
    potatohead wrote: »
    And people like VGA anyway.
    Not me :smile:, at least on the P1. The RGB222 palette sucks. Especially compared to how nice the NTSC colors are.

  • I like NTSC / PAL composite myself, and for similar reasons.
  • potatohead wrote: »
    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
    
  • Wuerfel_21Wuerfel_21 Posts: 878
    edited 2020-09-16 - 19:44:25
    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).
  • Wuerfel_21 wrote: »
    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?
  • Jon_ThomassonJon_Thomasson Posts: 44
    edited 2020-09-16 - 23:21:59
    potatohead wrote: »
    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.
  • potatoheadpotatohead Posts: 10,093
    edited 2020-09-16 - 23:24:45
    I had asked about COGS free. You said there was.
    Just musing about an easy way to do the more accurate display.
  • potatohead wrote: »
    Do you have a COG free?

    Yes I believe so. At least one, maybe even two cogs free.
Sign In or Register to comment.