Shop OBEX P1 Docs P2 Docs Learn Events
ZX Spectrum TV driver — Parallax Forums

ZX Spectrum TV driver

jlcebrianjlcebrian Posts: 2
edited 2007-05-13 10:38 in Propeller 1
Hi! I've been a new Hydra user for the last few days smile.gif

I would like to congratulate Andre for all the good work. Even with my rusty assembler skills, hacking the Hydra is awesome. Nowadays it seems like programming is just a matter of swimming around gigantic sourcecode repositories and memorizing hundreds of interfaces and APIs. However, programming the metal is where the real fun is [noparse]:)[/noparse]

Anyway, the first thing I wanted to do is to create a few video drivers. Since I have fond memories of my Spectrum days, my first one here is a Spectrum NTSC TV driver.

The Spectrum used a 256x192 pixels screen with 16 different colors. Since full 4-bit color would need a huge ammount of memory (24K!), a clever trick was used: the actual screen is only a two-color bitmap (6K) with 768 bytes of extra 'character attributes' that can be used to choose two different colors for each 8x8 'character' cell. Even with this limitation, people managed to get some impressive results.

I've attached my first version of the driver to this message. It's heavily commented in order to be useful to other people (and to myself in the future!). The driver itself uses one cog, outputs a NTSC signal, and can fully emulate the spectrum graphics layout to the point that you can load a SCR file from the World of Spectrum archive and show it on TV.

Since this has been a learning experience for me, it seems I'm not getting the NTSC format 100% right. There are some timing problems (evident on my LCD) that seem to be related to the NTSC half-line I output after each frame. Removing this half-line fixes the problem, but then the colors look a bit messed up. I've look at the Hydra book and other references but I've still not figured how to output a stable NTSC image with good color resolution. Any help here would be appreciated.

In any case it looks right on my CRT TV, so I'm releasing the code. By the way, consider it in the public domain. Use it in any way you want. I heavily dislike looking at code that I can't use, copy or modify.

Comments

  • BaggersBaggers Posts: 3,019
    edited 2007-05-12 15:13
    Looks good so far, but I see what you mean about viewing on LCD's.
    I was going to convert CardboardGuru's TV driver to do a spectrum bitmap, ( but you've beaten me to it. ) but instead, I thought it might be easier doing ManicMiner's characters this way, and using sprites, that way, if I wanted to I could spruce up Manic Miner to be 4 colour paletted, instead of just two, and updating characters in Spin would be faster than accessing the bitmap.
    Either way, what you've done so far is looking good, I might swap over to that one later on, for other projects.
    Keep up the good work.
    I'd have a look to see if I can help stablise it, but I want to get the sprites on the screen first.

    Edit!

    Just change
    ······· _CLKMODE··············· = xtal2 + pll8x
    to
    ······· _CLKMODE··············· = xtal1 + pll8x

    works fine on both my LCD's now [noparse]:)[/noparse]
  • CardboardGuruCardboardGuru Posts: 443
    edited 2007-05-12 16:08
    Good stuff jlcebrian!

    On my CRT TV, it displays in both interlaced and non-interlaced mode. But up at the top of the screen above the user data area, the vertical edges of the scan has a bend in it. It's noticeable on my TV because it's wide-screen displaying in narrow mode. This suggested to me that there was something wrong in the timing of the vsync lines. SimpleNTSC seems to display solidly, so I took the vsync code and associated constants out of that and put them in your driver. But rather than fix the problem, the screen just endlessly rolls. Perhaps the timing of your data lines doesn't match the timing of SimpleNTSC vsync lines. But they should be interchangeable.

    BTW, your source code is really well documented and incredibly neat. I particularly line the use of lines to show what bits do what. I really must tidy up the Donkey Kong source... I might steal your formatting style.
  • jlcebrianjlcebrian Posts: 2
    edited 2007-05-12 17:35
    CardboardGuru:

    Hey, feel free to steal any formatting wink.gif I always used to comment assembler code as much as I could. I'm not look at figuring out what a bunch of assembler does, and without lots of comments I would be at a loss. About the timing problems, it definitively seems to be a vsync problem. I'm going to take a look at the SimpleNTSC code trying to spot the differences.

    Baggers:

    Thanks for the tip! Unfortunately, the CLKMODE change didn't make any change in my LCD :-(
    Maybe there is something more going on, but this is definitively a good catch.
  • AndreLAndreL Posts: 1,004
    edited 2007-05-13 10:38
    Very cool, yes, good use of palette attributes. NES uses the same trick. Once the sram is out then everyone can have 8-bit color 256x192 no problem, so that will be nice for this stuff.

    Andre'
Sign In or Register to comment.