Shop OBEX P1 Docs P2 Docs Learn Events
Is an 80x25 text display possible on the Prop using 2,000 bytes of hub RAM? — Parallax Forums

Is an 80x25 text display possible on the Prop using 2,000 bytes of hub RAM?

Dave HeinDave Hein Posts: 6,347
edited 2012-05-09 19:21 in Propeller 1
Has anybody done an 80x25 text display on the Prop that uses a 2,000-byte array to store the text? This would require either using the ROM font, or the font would have to reside in cog memory. 2-colors is fine for my application. It would be great if it could fit in one cog, but 2 cogs would be OK also. Ideally, it should be on a VGA display, but TV might be OK if it's just black and white.

I'm just wondering if this is possible to do on the Prop.

Comments

  • potatoheadpotatohead Posts: 10,261
    edited 2012-05-09 13:32
    It's possible.

    Do you care how many characters are included? One option we've got is stuffing characters into the TV COG. It's reasonable to do 96-128 of them that way, keeping the HUB memory clean, but for the text screen buffer.

    I've got a TV one that works that way somewhere. It's 64 cols @ 80Mhz, 80Cols at 96Mhz. Cluso has done a text in cog driver too.

    Do you need redefinable characters?
  • pedwardpedward Posts: 1,642
    edited 2012-05-09 14:08
    If you packed bits with 6 bits per char, you would only have 121 longs to do the actual display, then you need code to process requests from other COGs to update the framebuffer. I think it would be better to pack bits in hub memory and leave most of the design the way it is.
  • potatoheadpotatohead Posts: 10,261
    edited 2012-05-09 14:42
    Oh, I didn't mean to put the frame buffer in the COG, just the character pixel definitions.

    Basically, put the video driver and the character definitions into one 2K memory segment and start it. Then use where it was in the HUB for the video display, avoiding the use of the ROM characters, which are very tall vertically.
  • pedwardpedward Posts: 1,642
    edited 2012-05-09 15:02
    If you did a 6x8 character cell, it would take 768 bytes, if you only supported 128 characters. The data would be stored column first, 6 columns per character. That would give you a 5x7 character, which is what hitachi LCD displays use.
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-05-09 15:21
    I only need the basic 96-character set. 80x24 is OK if it's easier than 80x25. It should work for 80 MHz and above. It would be nice to have a character cell of 8x12, but a smaller character cell is probably OK. I prefer using a VGA monitor versus a TV monitor.
  • pedwardpedward Posts: 1,642
    edited 2012-05-09 15:25
    I don't know off hand how much space the tiled text driver (I think that's the right description) takes, but I know there is already a text driver that takes user defined fonts.
  • localrogerlocalroger Posts: 3,452
    edited 2012-05-09 16:16
    You could do this with the ROM font in monochrome NTSC by using the same 3-cog technique I used for the 40 column ROM font VGA driver. Basically two cogs unpack alternate lines and reduce them to bit patterns which a third cog farms out to WAITVID. You would have to use monochrome because the color subcarrier doesn't have enough bandwidth to resolve 80 column text. Monochrome does and will display OK on most monitors. You could also drive an analog RGB monitor that uses NTSC timing through the VGA resistor array, but I'm not sure if anyone has done the groundwork on that before.
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-05-09 17:56
    See my 1pin TV driver on the obex (its under debug 1pin TV and keyboard).
    It reuses the hub code space for the 2K buffer. The font is in the cog, and it has a limited VT100 command set.
    The TV is actually driven by the VGA counters and is monochrome. Its not all my work (see the code for attributions).
  • potatoheadpotatohead Posts: 10,261
    edited 2012-05-09 19:21
    That's the driver I was thinking of. Thanks Cluso. Was looking today and couldn't remember, but I knew one of us stuffed the character pixel defs into the COG.

    Been thinking on the drive home, and if a VGA is preferred, it might take two COGs to do this using the ROM font. There is the WHOP method pioneered by Kuroenko, and his drivers, which I've not really explored much. The VGA sweeps are 2X what the TV sweeps are, and the ROM font is 16 pixels too. That's basically a 1280 pixel display!! Chip did it with 5 COGS, but it would do more than text too.

    So, TV is easy, but it's TV. I assume it's monochrome, due to the 2K text screen buffer. On VGA that would mean 2 colors. On TV, it means monochrome as there are few color combinations that really look good without a lot of fussing, and a good TV. S-video will display very nicely --even with more color combinations. Is that an option? S-video monochrome will look great on many TV devices, and it's more or less pixel perfect on most capture cards.

    May I ask what the display need is? For example, is it for debug? Is it to be mounted somewhere? Can a capture card be used, etc...?

    I'm not sure about character cell sizes. 8x8 is super easy, just a byte, and the char defs fit into the COG nicely. 8x12 could round up to 16 bits, also fits into the COG, but not so many characters are possible... Would need 1.5K or so for defs @ 96 chars. Probably would need two COGS, loaded sequentially to hit the 2K HUB RAM goal. The second "text" cog won't take much code, so I think that's possible. Some new code has to be authored for that. We have existing pixel routines for 8x8, the ROM font. I don't think I've seen a 12 implemented yet. Anyone know?

    (goes off to look at Cluso's driver)
Sign In or Register to comment.