Jump to content

Andrew Davie

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Andrew Davie

  1. For the sake of completeness, I had to see what the SECAM version would look like.

    The algorithm is remarkably robust, given it's just got 8 colours (no shades) to choose from.

    Unfortunately YouTube feeds this at 30 Hz, but it does look much better at 60 Hz.



    • Like 5

  2. Unfortunately for those of us in PAL-land, the range of colours is quite limited, and reds in particular are wanting.

    The results aren't nearly as good, although with movement/animation it's OK. Not great, but OK.









    • Like 1

  3. I thought this would be an excellent contemporary song, with a challenge to render because of the colours.

    IMHO it came out great!



    Edit:  I just noticed that YouTube is showing this at 30 Hz.

    The original is better - see the screenshots below...








    • Like 4

  4. 2 hours ago, ZeroPage Homebrew said:

    I'm really loving the Atari 8-bit computer platform and I'm definitely going to be sticking to Atari systems, there may be one offs here and there of other systems but my focus will be the 2600/5200/7800/8-bit Family. 🙂


    I could technically add in the NES and probably a few washing machines if my only requirement is the 6502 chip! Hahah.


    It may be time to change the tag line, Atari 8-bit computer games are here to stay on the show!


    - James

    I'm a die-hard who only wants to see '2600 stuff on the show.

    I have zero interest in the others, and if these show up on the show I switch off, so to speak.


    • Like 1

  5. 6 hours ago, benjonesn said:

    Some of you "old timers" might recognise my handle. If not, no worries. Never the less, here is my speel...


    Allright gang, the time has finally come for me to retire from my crazy Atari obsession. As much as I still feel the urge to pull the trigger on an item I might be missing from my collection, I really must face the reality that I need to pass my items on to ya'll, fellow collectors who truly appreciate the nostalgia of an era that sparked the entire video game revolution. It's sad for me to let this stuff go, but seriously, keeping all this stuff in moving boxes makes no sense either. It's gonna take me some time to go through all this stuff, but eventually I'll have a authentic Pepsi Invaders available. 


    Don't forget to add "no lowball offers, I know what I have!"


    • Like 1
    • Haha 3

  6. 4 minutes ago, rbairos said:




    Amazing improvement in quality; well done.

    I would not have thought the left one possible, yet alone the right one!

    What a huge difference, though.



    • Like 3

  7. There's gonna be a market for screen overlays to mask out those left/right edges :). Like the Odyssey overlays -- different sizes for your CRT size.


    • Haha 2

  8. 2 hours ago, rbairos said:

    Okay false alarm. I was experimenting with alpha in the node viewers, and a default grey checkerboard pattern was seeping through.
    Nothing to do with the encoder.
    Back to breathing again..




    • Like 2

  9. Here's the latest. I've played with saturation and tweaked a few other things. Perhaps too bright.

    But I have to say I never thought I'd see this sort of quality on the '2600 for video.  It's astounding.



    As an aside: YouTube detected a copyright claim/breach on the Thin Lizzy song "Boys are Back in Town" so I guess that says a bit about the audio quality - at least recognisable to an algorithm :)


    • Like 6

  10. 1 minute ago, rbairos said:

    I'll have to see how your specific file is now set up.
    I had set it up to open only one performance window.
    PM me for details.

    Will PM, but it's *always* done this for me.  I use the little white "STOP" square on the main window to launch it. Perhaps that's the issue.


  11. 1 hour ago, rbairos said:

    That's cool.
    If you want to play with the saturation in realtime during the encoding, add a 'HSV Adjust' node in the chain.
    The 'Saturation Multiplier' will do it.

    That worked well, TY.

    Why does the tool open two identical windows when I start it?  See image...

    I close the top one, the one underneath keeps going.  Seems redundant.




  12. Here's the original clip showing the tendency towards grey. I know the colour is subtle here, but I think the colour choice might be able to be improved slightly with a better matching algorithm. In any case, you can clearly see the differences when saturation is increased!


  13. Use the "CLEAN_START" macro on startup.

    It does everything to set the machine into a "clean" state in only 8 bytes or so.


    Many addresses are write-only, so I guess you'd effectively get randomness (whatever is on the data bus) when trying to read them.

    Look into Stella "developer mode" for assistance in finding these sort of hard-to-find bugs.


  14. 9 minutes ago, rbairos said:

    Also, I think I'm going to change the flicker/fill pattern from two alternating checkerboards to two alternating columns, to free up more cycles.

    Yeah, I think this is a terrible idea!!  It's going to be so totally noticeable it will hurt my eyes :P


  15. 12 minutes ago, rbairos said:

    Really enjoying all the exploration you're doing.
    What are you using to play with the saturation? There are endless ways to manipulate the color in the existing software.

    I ran the original through iMovie first. I don't know enough about the tool/existing software to use it competently.


    12 minutes ago, rbairos said:

    Its interesting that it picks the greys instead of light greens.
    This suggests that my color-distance function isn't optimal in that case.
    Right now it just takes minimum euclidean distance, weighted by .6/.3/.1 for R/G/B

    I've just added a HSL conversion (which isn't functioning 100% yet - tomorow, though...) so that I can do a nearest-colour based on weightings on hue, saturation, lightness... rather than RGB.  Results tomorrow, hopefully.



  16. Continuing with the experiments, I noticed that the algorithm prefers to select greys/whites instead of colours very similar to these. That is, would choose a grey instead of a pale green. So, I knocked out all the whites/greys from the palette to see how it would do. Also, I super-saturated the colours of the source before converting this one. I wanted to really enhance the variety of colours chosen. Finally, I chose this particular clip mostly because it has dinosaurs fighting, but also because it's incredibly messy/busy and should be very difficult to render well.



    The results are pretty good, considering. The super-saturation is a bit of overkill, and perhaps the brightness should be down a bit. But the removal of the white/grey colours seem to be working well. I'll do another version with the original palette and without colour super-saturation just to show the difference. That will take a few hours to finish, though.


    • Like 3

  17. 41 minutes ago, gorgh said:

    thank you for your answer, if I may I have some more questions...
    If there's immediate start of a new frame after the VSYNC change then what happens with the electron beam gun of the TV display? As far as I know it takes some time for the beam to return to its original start position.


    Have a look at some sample kernel code for the exact process on the '2600.

    At the bottom of the screen, after you've drawn your scanlines (say, 200 of them), then the electron beam is turned off (via VBLANK) and you have a fairly hefty delay (the vertical blank). When that delay is done, then you toggle VSYNC (it's a 3 scanline-long toggle) that starts the new frame. You'll need to verify this next bit; but as I understand it, at that point you are at the top of the screen and effectively drawing stuff.  From the Stella Programming Manual...


    "All horizontal timing is taken care of by hardware, but the microprocessor must “manually” control vertical timing to signal the start of the next frame. When the last line of the previous frame is detected, the microprocessor must generate 3 lines of VSYNC, 37 lines of VBLANK, 192 lines of actual TV picture, and 30 lines of overscan. "


    I'd say the vertical retrace of the beam happens at the start of the VSYNC, but someone may very well correct me on this one.




  18. 4 hours ago, gorgh said:

    thanks for the answers. My question was about something else, though. I spoke with my friend and he told me that setting D1 of VSYNC for 3 scanlines force TV display to wait for vertical synchronisation, which means that it synchronises with a frame, could you confirm that? What about the situation where my program has let's say 260 or 258 scanlines?

    Well, you're still not quite getting it.

    The TV has no internal concept of "a frame". It simply responds to electrical signals of the TV signal.

    When you write VSYNC, you effectively adjust the signal that the TV sees, which causes an *immediate* start of new frame.

    There's no "waiting" by the TV, because the TV doesn't have some sort of "state" or concept of how long a frame it. It just response, as I mentioned, to the signal that it is fed. You can, therefore, send all sorts of weird stuff to it.  So "what about ...260/258" -- well, most TVs will display this happily. At a higher frame rate because you are sending less scanlines per second, so your frame rate increases proportionally. The TV doesn't *know*... it is simply responding to the signal that you effectively send it by writing registers on the '2600. Again, there is no concept of the TV "waiting" for vertical synchronisation.

  19. I'm now up-and-running with the TouchDesigner and moviecart software on my MacBook Pro (2013)

    It's an interesting environment. Strange, and slightly odd in places... will be fun to play with.

    Anyway, I've contributed zero to this, but thought I'd show a rendering from the software. It is pretty cool...



    • Like 3

  20. As Thomas says, YOU are effectively the graphics hardware that creates the correct signals that tell the TV what a frame is.

    The VBLANK tells the TV to reset the electron beam to the top of the screen and begin scanning.  The actual timing and generation of the rest of the frame is what your code does. The simplest way is to start a timer (look at TIM64T) and wait for it to expire. Then you send the appropriate "end of frame" stuff (overscan).  You can/should replace the "wait for stuff" with your code that sets the registers for playfield/sprites on each and every scanline. By adjusting the timer, you can adjust the total number of scanlines the "wait" encompasses. By adjusting the number of scanlines, you adjust the frame frequency.  PAL uses 312 scanlines and is 50Hz.  NTSC uses 262 scanlines and is close to 60Hz. So a typical frame you generate might be...   do VBLANK, set TIM64T, do some blank scanlines, do about 200 scanlines of content, wait for timer to expire, do the overscan stuff, repeat.

  • Create New...