Bug in Level2 grfdrv.asm

  • Robert Gault

    Robert Gault - 2008-10-31

    There is a reversal of meaning in the grfdrv $FF98 and $FF99 data table regards the variable TV. Here are bits of source.

    * NOTE: Following set has meaning only if 25 text line mode is selected
    TV       set   $00            Set to 1 for 25 line TV res. (200 vs. 225)

    * GIME graphics register values
    *     1st byte goes to $ff98
    *     2nd byte goes to $ff99
    * NOTE: To change to 25 line TV res (200 not 225), change $0475 & $0465 to
    * $033D & $032D respectively (approx $825 in V1.15+)
    *       ifeq MaxLines-25
    L086A.25 fdb   $8034        640x200 2 color
             fdb   $8035        320x200 4 color
             fdb   $803D        640x200 4 color
             fdb   $803E        320x200 16 color
           ifeq TV-1
             fdb   $033D        80x25, 200 line screen
             fdb   $032D        40x25, 200 line screen
             fdb   $0475        80x25, 225 line screen
             fdb   $0465        40x25, 225 line screen

    According to the above, TV=1 means 25 lines of text. However, in the table TV=1 results in 200 lines of text. Either the Set commentary or the table should be changed for consistency.

    This is related to another thread where 225 lines of text in 6809L2 was causing a problem. Yes, 225 lines of text are possible and the current grfdrv is set for 225 lines.

    Actually, I don't see the point of this. Either we permit 225 lines or we don't. That should be based on the /term descriptor not grfdrv. Why does grfdrv force a request for 225 lines to receive 200 lines instead of the default 192? Why does grfdrv force any value?

    If this relates to US vs European TV standards, there should be two versions of grfdrv selectable in the distribution. If this relates to different sized fonts, that applies to graphics not text screens.

    • Gene Heskett

      Gene Heskett - 2008-10-31

      Robert, I'll have to defer to your much superior knowledge of GIME internals re this.  However it seems to me that a 225 scan line screen would almost require the vertical synch rate to drop some.  I'm not getting the right answers from kcalc, or am not entering the right numbers so I'll not offer any obviously wrong answers here.

      But I agree with the code shown, and the premise that grfdrv should not be hard coded, except I'm not sure what the label tv-1 is supposed to represent, not enough surrounding context without my actually reading the file.  And I'm still a quart low on coffee as I just woke up a few minutes ago.  Getting old isn't for wusses, I'm started on my 75th trip around this star now.

      So this reply is basically a waste of your time to read, sorry.

      Cheers, Gene.
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      All men have the right to wait in line.

      • Robert Gault

        Robert Gault - 2008-10-31

        Gene, you may be 10 years ahead of me but that doesn't mean I don't also have senior moments.

        If you assume everything else is equal, then extra text lines would require a change in the vertical sync rate. However, the assumption is not based on any facts that I know of. The main thing here is that I can get 25 lines of text on an RGB monitor. (I don't think I've tried it on a TV.) So, if you accept that it is possible to get 25 text lines, you must believe that either the size of the lines change, or the something else changes so that "everything else is Not equal."

        TV is being used to select the number of lines on the text screen when /term is changed from pag=18, row=18 to pag=19, row=19. That is selecting 25 rather than 24 rows of text. This selection is made in grfdrv by changing the bit values sent to $FF99 where bits 5&6 mean
        LPF1 LPF0        Lines per field
        0       0                 192
        0       1                 200
        1       0                 reserved or maybe 210
        1       1                 225

        24 Text lines at 192 LPF means the character is 8 pixels high and 25 text lines needs 200 LPF. With this size character 225 LPF would be 28.125 lines of text.
        Well this does not happen. There is a single blank line between rows at 25 lines of text for a total height of 9 lines per character; 225/9=25.
        At 24 lines of text per screen there is no vertical space between characters and 192 LPF are needed.
        Here is the 'not everything else equal'!

        Ignoring all of the above, the grfdrv.asm code defines TV=0 as a 200 LPF screen for 25 lines of text but actually uses 225 LPF as
        ifeq TV-1
        is false and the else gives
                 fdb   $0475        80x25, 225 line screen
                 fdb   $0465        40x25, 225 line screen

        Personally I like 225 lines per screen. But in any case, the code needs to be corrected so the definition matches the usage.

    • Gene Heskett

      Gene Heskett - 2008-11-01

      I knew there was a reason I didn't like 24 lines, there is no space between the lines.  And an underscore disappears into the top of the next characyter down.

      I was going at it from the 3.58mhz clock, actually 14something mhz, and kept coming up short of space.  OTOH, there is plenty in the blanking area that can be borrowed as long as the retrace time of the monitor doesn't eat the top line.  Non-interlaced, we have 262 (or 263, since without interlace, we can't have half a line) lines that need to be done (for ntsc) in 1/60th of a second.  A normal vsynch pulse is 3 lines, leaving at least 259.  Then the monitor usually needs a bit of time to wrestle with the inductance of the output transformer and the deflection yoke, so nothing uses things till at least the 12th line.  Said another way, there seems to be room for an active area approaching 240 scan lines and still have time for the monitor to retrace.

      If the GIME is anywhere near as programmable (and I don't think it is, too much seems to be hard coded) as the text only chip in a WP-RS, then there is a register for each of these timings which allows one to move the text, and control how much screen is used.  I was able to make that postcard sized text display in the middle of a 12" amber screen monitor expand to pretty well fill the display's usable area by adjusting some of those values in the co80 module's chip init array.  The idea could well have been expanded for more than 25 lines, but 26 would have overflowed the 2k memory chip the display keeps the text in, so I never expanded the 25 line working screen I had back then. The cost?  Running the monitor at about 18khz h rate, and nearly 70 hz for v rate.  That meant the monitors needed a few inches of air between them to control the display wiggle caused by the leakage fields of the deflection yokes which got into the adjacent display.  As for the overspeed, upwards is _never_ a problem.  The high voltage may sag a bit, and it did in this case, but nothing is being overheated or otherwise stressed by such operation, and it ran that way for at least 10 years.

      Going the other way by running a monitor slower can be quite destructive though.  Most monitors have a working minimum scan rate, and going below that will, if the monitor try's to follow that, cause the scan transformer to have enough on time to saturate the core magnetically.  When that happens, the ferrite can do 2 things, and usually does.  First, its effect on the inductance of the transformer essentially disappears, and the current then rises at a rate defermined by the inductance of the winding when the core has been removed.  Currents can rise at 100 amps per microsecond until such time as the drive transistor is turned off.  They get hard to turn of at that current level, so the turnoff is slower. Between the ohmic effects when on at those current levels, and the kilowatts of heat generated when its a microsecond slower than normal turning off, and the results are very predictable.  It usually fails shorted EBC, and several other parts may be blown as well before the fuse can clear.

      The second effect can show too, but rarely does in the case of scan transformers but I have seen it in switching power supplies.  That can happen if the ferrite goes above its curie point, that point on the rising temperature scale where the ferrite becomes non-magnetic.  If driven magnetically above the curie point, it appears the curie point itself, which in some ferrite's is below 200F, can drop to well below room temps, in which case its never active magentically again unless we send it a polar area of neptune

      Trivia stuffs. :)

      Do you have any GIME info that I don't?

      This may be an area where a full set of docs on the GIME chip might be very illuminating.  Unforch, unless we can get a mole into the fab house that made those, to dig through the document morgue and bring what he can back, I suspect we are screwed.

      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      I have a terrible headache,  I was putting on toilet water and the lid fell.

    • Robert Gault

      Robert Gault - 2008-11-02

      Regards the GIME and any "secrets", I don't put much stock in supposed hidden capabilities. The service manual covers all useful settings. Sure you can set "illegal" video combinations and get weird effects but they aren't really good for anything.

      For some of this weird and maybe useful video stuff, look at John Kowalski's and Nick Marentes' sites
      and the video coco.c source code from MESS.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks