Shop OBEX P1 Docs P2 Docs Learn Events
JBTVDriver — Parallax Forums

JBTVDriver

BaggersBaggers Posts: 3,019
edited 2015-11-15 12:41 in Propeller 2
Hi all,

I've modified Chip's 256x192 driver to now allow any NTSC resolution ( even X even number ) from 2x2 to 640x480

Updates:-

Update 2:
Added VGA same modes as TV

Update 1:
Added 32BPP version for 320x200, you set the BPP at the top to 8 to 32, then at the bottom of the file there are various 8bpp and 32bpp (24bpp image in 32bpp file) FILE commands.
Also changed R and S to more fit my TV, you may want to turn it back to your own settings or change them for your TV.

Latest
jimbagley.co.uk/NTSC_and_VGA_640x480_Driver.zip

Older versions
jimbagley.co.uk/JBTVDriver.zip

Chip640x400.jpg

I'll add a char map next.
OK, so I added 32BPP next :D char map is definitely next.
«1

Comments

  • ozpropdevozpropdev Posts: 2,792
    Nice work Baggers! :)
  • BaggersBaggers Posts: 3,019
    Cheers ozpropdev :D

    It's still early days with the driver as I'd like to make it variable resolution at runtime, and also PAL or Component or VGA driver all in one, and add text and graphic modes and sprites.
  • rjo__rjo__ Posts: 2,114
    Wow...

    I am using an old RCA... the bmp of Chip and Doom are rock solid. The bubble, batman,trees,sddefault bmps are showing just a hint of flicker in some areas. I drew some 1 pixel red lines on bubble.bmp to highlight it. On my monitor, I get marching ants in some areas.

    Rich
    bmp
    bmp
    bubble.bmp
    301K
  • BaggersBaggers Posts: 3,019
    Cheers Rich,
    Also thanks for feedback too, when doing 640 it's going into overscan so totally understandable that it gets a hint of flicker on some screens, they're all solid on my LG display, I've not tried it on a CRT or anything other than this LG MonitorTV, although it doesn't show full 640x480 for me.
  • potatoheadpotatohead Posts: 10,261
    Excellent! Yeah, we will just keep building, until it's doing all the basics. Nice work JB
  • evanhevanh Posts: 15,915
    I haven't been paying much attention to the video stuff but it just crossed my mind that a palletised screenmode doesn't have a lot of need for transform hardware if the palette contains the native colour out encoding.
  • evanhevanh Posts: 15,915
    edited 2015-11-11 04:54
    Oh, and why are the bitmap files flipped vertically? Let me guess, M$ did it backwards (Typical PC industry) but PNUT doesn't, right?
  • 78rpm78rpm Posts: 264
    evanh wrote: »
    Oh, and why are the bitmap files flipped vertically? Let me guess, M$ did it backwards (Typical PC industry) but PNUT doesn't, right?

    Are they not also flipped left to right?
  • evanhevanh Posts: 15,915
    I started off rotating them to view but the title screen images, with text, are clear cut it's just vertical flip only.
  • TubularTubular Posts: 4,702
    Awesome work JB

    2 video drivers (text/bitmap) in one day. How good is that?
  • 78rpm78rpm Posts: 264
    evanh wrote: »
    I started off rotating them to view but the title screen images, with text, are clear cut it's just vertical flip only.
    Yeah I can see that looking more closely. It is a while since I've seen that BBC 2 Colour Test Card.
  • potatoheadpotatohead Posts: 10,261
    edited 2015-11-11 05:44
    I haven't been paying much attention to the video stuff but it just crossed my mind that a palletised screenmode doesn't have a lot of need for transform hardware if the palette contains the native colour out encoding.

    It does when you want to make those color definitions display portable. "native" color out changes a lot from display type to display type.


  • RaymanRayman Posts: 14,643
    My 15" Coby TV doesn't seem to like this... Image is shaking and top especially is messed up...
  • potatoheadpotatohead Posts: 10,261
    Yes, we need to get the vsync sorted out. It's ok, but not quite right, particularly interlace.

    All the drivers out there so far have the same vsync code.

  • BaggersBaggers Posts: 3,019
    Thanks for the feedback Rayman, like potatohead says we're on it, just need to figure out why interlace is wrong, we need to check the VBlank timings.
  • BaggersBaggers Posts: 3,019
    Updated with 32BPP version which does 320x200 without running out of ram on DE2-115. ( see 1st post )
  • cgraceycgracey Posts: 14,152
    edited 2015-11-13 04:00
    Baggers wrote: »
    Updated with 32BPP version which does 320x200 without running out of ram on DE2-115. ( see 1st post )

    Have you played with that brightness constant that was 84 in my original NTSC demo? The DACs on our early fpga boards were way over 1V peak. I ask because the screen shot you posted looks quite saturated. Lowering that 84 to 60, or so, might help.
  • rjo__rjo__ Posts: 2,114
    Really cool.

    I'm sitting here looking at an absolutely beautiful picture of space... hard to believe it is only 320x200.

    Then I wonder to myself: "self... why do we need a look up table for a 32 bit image?... where did that 8 bit look up table come from anyway?... what kind of discombobulation is this?"

    If you could offer just a few words on this general topic:)

  • cgraceycgracey Posts: 14,152
    rjo__ wrote: »
    Really cool.

    I'm sitting here looking at an absolutely beautiful picture of space... hard to believe it is only 320x200.

    Then I wonder to myself: "self... why do we need a look up table for a 32 bit image?... where did that 8 bit look up table come from anyway?... what kind of discombobulation is this?"

    If you could offer just a few words on this general topic:)

    No palette is needed for 32BPP images, though it could be employed for sync generation.
  • Cluso99Cluso99 Posts: 18,069
    Nice work Jim!
    I can see you rotated the pics for us Ozzies to view ;)
  • potatoheadpotatohead Posts: 10,261
    edited 2015-11-13 06:37
    Rjo, there are modes that lookup colors in the lut. 1, 2, 4, 8, etc... bits per pixel. The value fetched from the screen buffer is an index into the palette.

    There are also modes where that value is used for the color directly. This is the image you are looking at.

    Some modes also take an immediate argument, and for those the color is supplied by the instruction itself, not from a screen buffer, or the LUT.

  • evanhevanh Posts: 15,915
    rjo__ wrote: »
    Then I wonder to myself: "self... why do we need a look up table for a 32 bit image?... where did that 8 bit look up table come from anyway?... what kind of discombobulation is this?"

    The traditional why is both space saving and bandwidth saving. It's an easy form of hardware decompression if you like.
  • evanhevanh Posts: 15,915
    Interlace exists for similar reason.
  • potatoheadpotatohead Posts: 10,261
    edited 2015-11-13 07:01
    As does run length encoding. I've not looked, but Baggers may have incorporated that in this high color driver.

    Variations exist too. We could, if we want to, modify palette entries per scanline. Using all of them may not save much, but deltas often can. Say 16 new entries per scanline can make a very significant difference on some images.

  • evanhevanh Posts: 15,915
    edited 2015-11-13 06:45
    potatohead wrote: »
    As does run length encoding.

    Well ... I figured I'd mention things that aren't normally thought of as a compression scheme.
  • evanhevanh Posts: 15,915
    potatohead wrote: »
    Variations exist too. We could, if we want to, modify palette entries per scanline. Testifying all of them may not save much, but deltas often can. Say 16 new entries per scanline can make a very significant difference on some images.

    Line by line is frustrating. HAM8 mode on the Amiga1200 was the best I've seen of that sort.
  • potatoheadpotatohead Posts: 10,261
    edited 2015-11-13 07:03
    I largely agree. Atari computers were like that. Vertically inclined images work nice. Most other things are crappy.



  • BaggersBaggers Posts: 3,019
    Thanks for the comments guys ;)

    Chip, yeah in this updated driver I reduced the brightness constants as it was too saturated on my TV ;)

    Cheers Rjo_, the 32bpp driver doesn't use a palette, it's only the 8bpp driver part that uses a palette which is why it orgs at $1000-$436 and 32bpp orgs at $1000-$36 as the BMP header is $36 bytes long the $400 bytes after header is palette which is loaded into LUT. Hope this helps.

    Close, BMPs are stored upside down probably when initially writing the save routine it was using the counter for how many lines to save as a y line index too, who knows lol

    Potatohead, there is no RLE in this driver, I just have the 32bpp screens back down to 320x200 ;)
  • evanhevanh Posts: 15,915
    Baggers wrote: »
    ... it's only the 8bpp driver part that uses a palette which is why it orgs at $1000-$436 and 32bpp orgs at $1000-$36 as the BMP header is $36 bytes long the $400 bytes after header is palette which is loaded into LUT. Hope this helps.
    Ah, very much so. I had been puzzling at that subtraction in the sources thinking it must be some sort of second parameter Chip had added to the ORGx directives. Never got round to nutting out the overall program flow.
    Close, BMPs are stored upside down probably when initially writing the save routine it was using the counter for how many lines to save as a y line index too, who knows lol
    Chip's example BMPs are upside down the same. I'm going to assume bitmap data in HubRAM is right-way up. So, either Pnut is flipping the data upright when building the bin file, or the BMP format is normally flipped but isn't for these examples and hence an ordinary picture viewer shows them the wrong way up ...
  • evanhevanh Posts: 15,915
    edited 2015-11-13 10:14
    After all that blather I went did what I should have from the start - googled it! - https://en.wikipedia.org/wiki/BMP_file_format#Pixel_array_.28bitmap_data.29

    And guess what, the default order is upside down, bottom to top. But there is a recognised way of doing top to bottom instead: "... uncompressed Windows bitmaps also can be stored from the top to bottom, when the Image Height value is negative." EDIT: Turns out the negative height trick doesn't work for the smallest header, BITMAPCOREHEADER, which is the one being used for the Prop files. The next longer header, BITMAPINFOHEADER, is 28 bytes more.

    Of course, I doubt any paint package will encode that ... so it would involve a custom edit of the header. :( And I wouldn't be too surprised if some picture viewers choke on a negative height anyway. So Chip has prolly done the best thing.
Sign In or Register to comment.