Shop OBEX P1 Docs P2 Docs Learn Events
Morpheus XGA 1024x768 bitmap driver discussion — Parallax Forums

Morpheus XGA 1024x768 bitmap driver discussion

Bill HenningBill Henning Posts: 6,445
edited 2009-08-03 21:58 in Propeller 1
This thread is for discussing the XGA driver - suggesting improvements to it, extensions, and fixes.

XGA 1024

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2009-08-03 04:05
    Bill, I have not looked at any code you may have published. Are the cogs you are trying to synchronise on the same prop? If so, this is easy as you can pass read the CNT register, add a small number to it (for a delay for all cogs to be ready) and put it in hub for all cogs required to be synchronised to collect. Then each cog does a waitcnt for this cnt and they are then all synchronised !

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
    · Search the Propeller forums (via Google)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-08-03 04:29
    Hi Cluso99,
    Cluso99 said...
    Bill, I have not looked at any code you may have published. Are the cogs you are trying to synchronise on the same prop? If so, this is easy as you can pass read the CNT register, add a small number to it (for a delay for all cogs to be ready) and put it in hub for all cogs required to be synchronised to collect. Then each cog does a waitcnt for this cnt and they are then all synchronised !

    Unfortunately it's a bit more complicated than that.

    The current version of the driver has to synchronize six cogs, in two sets of three. The only place where there is a bit of an issue is in synchronizing the video display circuitry in three cogs.

    Here is my cog usage:

    XMM_DEMO1 - the main test app

    XMM_ADDR - address generation cog
    XMM_READ - burst read cog, one of two
    XMM_READ - second instance, offset by four clock cycles from first one

    XGA_SYNC - video HSYNC and VSYNC generator
    XGA_DISP - displays video even scan line information
    XGA_DISP - second instance, displays odd scan line information

    XMM_PASM - generic XMM read/write server cog, blocks during burst reads

    (I will be merging XMM_ADDR and XMM_SYNC as soon as I have time, saving a cog)

    My video synchronization code is based on Chip's VGA high resolution text driver's code, I tried to use exactly the same code to synchronize the three display generation cogs. I needed to use three as my 256 color VGA capability means that HSYNC and VSYNC have to be driven from a different video circuit as I use all eight bits to generate eight bit color (3R 3G 2B).

    The problem is that some of the time the two XGA_DISP cogs don't synchronize - despite the counters/PLL's being programmed the same, despite allowing time for the PLL's to settle. I am at a loss - I either have had my nose buried in the problem too long, or there is some as yet undetermined reason for the issue.

    I do have two ways of fixing it, as soon as time allows (soon after finishing the Morpheus System Architecture and Developer's Guide)

    1) disable the PLL in the video generator, and stick to 40MHz dot clocks or lower
    2) detect if the two DISP cogs are not sync'ed correctly to the SYNC cog, and keep retrying the sync code until they are perfectly in sync

    Syncing up the memory burst engine was a piece of cake in comparison!

    Driver Theory of Operation

    The display engine is composed of a memory burst read engine, and an XGA display engine that displays the contents of two scan line buffers (even & odd)

    XGA_SYNC generates HSYNC, VSYNC, and requests that XMM_ADDR generate addresses for the screen scan line it specifies
    XMM_ADDR waits for the correct start time, and starts generating interleaved addresses for the two XMM_READ cogs
    XMM_READ (2 cogs) cogs read from the bus, interleaved with each other, and assemble longs for the two scan line buffers
    XMM_DISP (2 cogs) cogs flip between reading from the bus, and displaying a scan line buffer - when even cog reads, odd displays, and vica versa

    The XGA engine therefore currently uses six cogs, but as I said, I will be merging XGA_SYNC and XMM_ADDR

    Currently, XMM_DEMO1 writes bytes to the screen buffer one at a time, and the write blocks whenever the ADDR/READ cogs are active, currently using a very primitive one access per hsync.

    A more detailed explanation is coming in the Developer's Guide [noparse]:)[/noparse]

    That is how I manage to burst read/write my XMM at 20MB/sec!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
    Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
    www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
  • RaymanRayman Posts: 14,844
    edited 2009-08-03 06:49
    I also had some trouble getting 3 cogs to syncronize when I did the 6-bit color VGA driver...

    Chip was pretty adamant that the cogs can syncronize to ~1ns, but I'm not so sure...

    I think perhaps it works well with his drivers because each cog generates the horizontal sync pulse and only one cog outputs at a time.· I think the receiving VGA monitor must compensate somehow for any offsets in line-to-line sync offsets...

    My guess is that your cogs will have to generate sync as well as color info...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • RaymanRayman Posts: 14,844
    edited 2009-08-03 08:05
    Wait a sec...· I just remembered my own counter argument...
    The mouse works in it's own cog and spans multiple horizontal lines and has a clean edge.
    So, somehow the cogs are sync'd.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-08-03 17:21
    I suspect it has something to do with the settling time of the video counter PLL's

    I base this on there being a "window" in randevous times where I get a much higher percentage of correct syncing.

    Fortunately a lot of interesting video modes can be made with a 40MHz dot clock, thus eliminating the need for the video PLL's for some drivers at least.

    In other cases, by having the cogs "compare notes" on cnt values after they should be in sync, they can force a re-sync amongst themselves until they are in sync.

    Both approaches should solve the issue, now I just need enough time to try and debug them [noparse]:)[/noparse]
    Rayman said...
    I also had some trouble getting 3 cogs to syncronize when I did the 6-bit color VGA driver...

    Chip was pretty adamant that the cogs can syncronize to ~1ns, but I'm not so sure...

    I think perhaps it works well with his drivers because each cog generates the horizontal sync pulse and only one cog outputs at a time. I think the receiving VGA monitor must compensate somehow for any offsets in line-to-line sync offsets...

    My guess is that your cogs will have to generate sync as well as color info...
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
    Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
    www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
  • lonesocklonesock Posts: 917
    edited 2009-08-03 17:46
    Is it possible that the cogs themselves are perfectly in sync, but the output pins have variable delays, depending on cog and pin numbers? Here's the text from the datasheet, section 9.5.

    Jonathan
    datasheet said...

    9.5. Cog and I/O Pin Relationship
    The figure below illustrates the physical relationship between the cogs and I/O pins. While there can be a 1 to 1.5 ns propagation delay in output transitions between the shortest and longest paths, the purpose of the figure is to illustrate the length of leads and their associated parasitic capacitance. This capacitance increases the amount of energy required to transition a pin’s state and therefore increases the current draw for toggling a pin. So, the current consumed by Cog 7 toggling P0 at 20 MHz will be greater than Cog 0 toggling P7 at 20 MHz. The amount of current consumed by transitioning a pin’s state is dependent on many factors including: temperature, frequency of transitions, external load, and internal load. As mentioned, the internal load is dependent upon which cog and pin are used. Internal load current for room temperature toggling of a pin at 20 MHz for a Propeller in a DIP package varies on the order of 300 μA.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    lonesock
    Piranha are people too.
    cog_pin_rel.JPG
    630 x 325 - 27K
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-08-03 18:08
    Hi Jonathan,

    The time variance is in the order of +-1....4us, much larger than the potential delay you pointed out. I am sure the problem will be figured out, but even if it is not, there are two possible ways around it, and both should work.

    Worst case: it may take a second or so to achieve "lock" when changing graphics drivers.

    Bill
    lonesock said...
    Is it possible that the cogs themselves are perfectly in sync, but the output pins have variable delays, depending on cog and pin numbers? Here's the text from the datasheet, section 9.5.

    Jonathan
    datasheet said...

    9.5. Cog and I/O Pin Relationship
    The figure below illustrates the physical relationship between the cogs and I/O pins. While there can be a 1 to 1.5 ns propagation delay in output transitions between the shortest and longest paths, the purpose of the figure is to illustrate the length of leads and their associated parasitic capacitance. This capacitance increases the amount of energy required to transition a pin’s state and therefore increases the current draw for toggling a pin. So, the current consumed by Cog 7 toggling P0 at 20 MHz will be greater than Cog 0 toggling P7 at 20 MHz. The amount of current consumed by transitioning a pin’s state is dependent on many factors including: temperature, frequency of transitions, external load, and internal load. As mentioned, the internal load is dependent upon which cog and pin are used. Internal load current for room temperature toggling of a pin at 20 MHz for a Propeller in a DIP package varies on the order of 300 μA.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
    Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
    www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
  • lonesocklonesock Posts: 917
    edited 2009-08-03 18:35
    Bill Henning said...
    Hi Jonathan,

    The time variance is in the order of +-1....4us, much larger than the potential delay you pointed out. I am sure the problem will be figured out, but even if it is not, there are two possible ways around it, and both should work.

    Worst case: it may take a second or so to achieve "lock" when changing graphics drivers.

    Bill

    Hey, I was only off by 3 orders of magnitude (assuming base 10)! [noparse][[/noparse]8^) When I get some free time I'll check out your code, thanks for posting!

    Jonathan

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    lonesock
    Piranha are people too.
  • BaggersBaggers Posts: 3,019
    edited 2009-08-03 19:26
    Won't the cogs be offset by the rd/wr**** round robin delay?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-08-03 21:39
    I accounted for that in my design, so that is not it.

    Thanks for the suggestion though!
    Baggers said...
    Won't the cogs be offset by the rd/wr**** round robin delay?
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
    Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
    www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
  • BaggersBaggers Posts: 3,019
    edited 2009-08-03 21:57
    Ah, ok, no worries, always good to put the idea forward, in case you hadn't thought of it!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-08-03 21:58
    Exactly!
    Baggers said...
    Ah, ok, no worries, always good to put the idea forward, in case you hadn't thought of it!
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
    Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA - PCB, kit, A&T available NOW!
    www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Sign In or Register to comment.