News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

charset rom adr???

Started by daydreamer, February 09, 2005, 06:14:34 PM

Previous topic - Next topic

daydreamer

cant find anything on charset rom adr, especially interested in the extended ascii chars
and what compability issues running it under win v86 mode?

MichaelW

I'm not sure I understand your question, but...

AFAIK the locations of the ROM character fonts are not standardized. You can obtain the addresses by calling Interrupt 10h, Function 1130h.

For information on the BIOS functions, try Ralf Brown's Interrupt list.

An HTML version is here:

http://www.ctyme.com/rbrown.htm

And the download version here:

http://www-2.cs.cmu.edu/~ralf/files.html

AFAIK you should have no compatibility problems under Windows. I have tested these functions under Windows 9x and Windows 2000, but I'm not sure about Windows XP.
eschew obfuscation

Tedd

BIOS stores the address in the vector for int 43h, which is accessible at real address 0000h:010Ch
(ie. you don't call it, you just use the address stored at this location)

Alternatively, you can poke around the CRTC registers - which is what bios actually does to set it; but it's not for the faint-hearted.

As for compatibility, I haven't tried, but I'm pretty sure the win v86 vm will set it up fine, since it gets used as standard.
No snowflake in an avalanche feels responsible.

daydreamer

testrendered in mode 12 and interrupt worked and got lots of symbols or characters
thanks

MichaelW

The address stored in the interrupt 43h vector, and in some cases the interrupt 1Fh vector, is a pointer to character set that the VGA BIOS uses for graphics modes. This character can be the default ROM character set selected by the VGA BIOS, or a ROM or other character set selected by the user. The function I referenced returns the contents of these two vectors, as well as the addresses of the ROM character sets.

I forgot to add that the 14 scan line character sets have been eliminated in some VGA implementations.

Regarding accessing the ROM character sets, I'm not sure that the format and order of the bit patterns is standardized. Although I don't recall why I made the decision, when I was trying to work with the ROM character sets from a QuickBASIC program I decided that reading them from the ROM would be too difficult. Instead, I implemented a workaround that involved reading the font bit patterns directly from bit plane 2.  This is a QuickBASIC sub, but translating it to ASM should be a fairly easy task.

SUB GetFontBlock (block%, bytesPerCharacter%, bitPatterns%()) STATIC

    ' REDIM's <bitPatterns%()> to (1 to <bytesPerCharacter%> * 256)
    ' and loads the elements with the character font bit patterns
    ' for the entire 256-character character font block specified by
    ' <block%>.
    '
    ' Note that <bitPatterns%()> must be dimensioned as a DYNAMIC array.
    '
    ' Note that the value in <bytesPerCharacter%> should be >= the
    ' number of bytes per character for the font.
    '
    ' This procedure reads the bit patterns directly from bit plane 2.
    ' To avoid problems with the odd/even address shuffle that the
    ' VGA performs for all text modes, this procedure temporarily
    ' changes to graphics mode 11h. This mode was selected because
    ' read operations access only a single bit plane. This allows us
    ' to avoid having to filter the data to extract the relevant bits.
    '
    ' This procedure loads a block translation array on the first call.
    ' The element numbers for this array correspond to the character
    ' font block numbers for the VGA BIOS functions and the VGA hardware
    ' registers, and the value loaded into each element is the block in
    ' bit plane 2 that the VGA maps to the character font block number.
    '
    ' Note that there is some uncertainty as to what the "standard"
    ' mapping is. Several of the available references specify that the
    ' standard mapping is 0.0, 1.4, 2.1, 3.5, 4.2, 5.6, 6.3, 7.7, and
    ' one that the standard mapping is 0.0, 1.2, 2.4, 3.6, 4.1, 5.3,
    ' 6.5, 7.7. This procedure uses the latter because it duplicates
    ' the mapping implemented in all but one of the VGA adapters that
    ' were tested.
    '
    ' Refer to the LoadBitPattern procedure for more information.
    '
    ' All mode sets are performed without clearing the display memory.
    '
    ' This procedure requires that the active display adapter be VGA
    ' compatible and operating in text mode.

    DIM regX AS RegTypeX

    IF block < 0 OR block > 7 THEN
        LogError "VGA.BAS", "GetFontBlock", "block < 0 OR block > 7"
        ERROR cErrorIllegalFunctionCall
    END IF
    IF bytesPerCharacter < 8 OR bytesPerCharacter > 32 THEN
        LogError "VGA.BAS", "GetFontBlock", "bytesPerCharacter < 8 OR bytesPerCharacter > 32"
        ERROR cErrorIllegalFunctionCall
    END IF

    REDIM bitPatterns(1 TO bytesPerCharacter * 256)

    ' Save the current video mode so we can restore it.
    vMode = VideoMode

    ' Simulate a run-time error if the current
    ' mode is one of the graphics modes.
    IF vMode > 3 AND vMode <> 7 THEN
        LogError "VGA.BAS", "GetFontBlock", "current video mode is graphics"
        ERROR cErrorIllegalFunctionCall
    END IF

    IF NOT fInitialized THEN
        DIM bitPlane2Block(0 TO 7)
        bitPlane2Block(1) = 2
        bitPlane2Block(2) = 4
        bitPlane2Block(3) = 6
        bitPlane2Block(4) = 1
        bitPlane2Block(5) = 3
        bitPlane2Block(6) = 5
        bitPlane2Block(7) = 7
        fInitialized = cTrue
    END IF

    ' Save the value from the Graphics Controller Read Map Select
    ' Register (index = 4). The Graphics Controller Address Register
    ' is at I/O port 3CEh and the Data Register at I/O port 3CFh.
    OUT &H3CE, 4
    rms = INP(&H3CF)

    ' Change to mode 11h. Set bit 7 of AL to specify
    ' that the display memory should not be cleared.
    regX.ax = &H11 OR &H80
    InterruptX &H10, regX, regX

    ' Set the Read Map Select Register so the next
    ' read operation will access bit plane 2.
    OUT &H3CE, 4
    OUT &H3CF, 2

    ' This segment address of the buffer is A000h for all graphics modes.
    segment& = &HA000&

    FOR charCode = 0 TO 255

        ' The blocks are 8 KB each and the bit
        ' patterns occupy 32 bytes per character.
        offset& = bitPlane2Block(block) * &H2000& + charCode * 32

        FOR i = 1 TO bytesPerCharacter
            bitPatterns(charCode * bytesPerCharacter + i) = MemByte(segment&, offset& + i - 1)
        NEXT
    NEXT

    ' Restore the original video mode without
    ' clearing the display memory.
    regX.ax = vMode OR &H80
    InterruptX &H10, regX, regX

    ' Restore the Read Map Select Register.
    OUT &H3CE, 4
    OUT &H3CF, rms

END SUB


The bytesPerCharacter value corresponds to the character height in scan lines (8, 14, or 16 for the ROM character sets).

eschew obfuscation

Dinosaur

#5
Michael

On a related issue, I am trying to print Big characters on the screen using pds7.1
Tried using existing char's, but it usually ends up looking chunky.
I thought I could re-assign the bit masks for certain characters so that I can create a smooth
large print.

Did you ever do any work on re-assigning bit masks to existing char or extended char set ?
What are the steps involved. (if at all possible) ?

Edited:
Sorry should have said for screen mode 0 Text mode.

Regards
Dinosaur

MichaelW

Hello Dinosaur,

I did a VGA test app (QuickBASIC 4.5) that among other things demonstrated some 18x16 double-byte characters. I assigned the bit patterns manually, and it took some time to do just three characters, but the results were reasonably OK. You can get the source code from the 2002 ABC Packet, available here:

http://uolang.org/sourcecode/abc/abcpacks.html?

It's under MISC.ABC, 200 qbtools. You will need a compatible reader to extract the zip file from the packet. IIRC one set of MAK files is missing (either the ones for the Quick library, or the ones for the individual modules), but the relevant source files should be there (VGA.BAS and VGATEST.BAS).

Or you can PM me with an e-mail address and I will send you the test app along with all of the files necessary to build it.
eschew obfuscation

Dinosaur

MichaelW

Sorry to take so long to respond,but, would love to see a way to improve what I have done sofar.
My email is jvp at Compu-Weigh dot com dot au.(including the hyphen)

Some of the asm code you have helped with in the past is now running
day & night on some of my machines.
Appreciate your contributions.

Regards
Dinosaur

Dinosaur

MichaelW

Got it,Many Thanks.

Regards
Dinosaur

MichaelW

No problem.

It didn't occur to me until moments after I had emailed the VGATEST components that I had another QuickBASIC app that could be useful: a text mode dialog-based program that displays the bit patterns for the ROM fonts. The code is somewhat unusual in that it uses user-defined characters (to represent the pixel blocks) and two full character sets (512 characters total), simultaneously enabled. The compiled app and all of the components necessary to build it with QB4.5 fit into a 137KB ZIP file. Let me know if you are interested.
eschew obfuscation

Dinosaur

Sorry, been travelling again.

Attached a bitmap example of what is the temp fix.
Because it is using standard char's , I can print this quite fast.
This image is 5 char hi x 3 char wide.
Couldn't work out how to insert a bitmap into this post.

Was hoping to make solid filled LCD type segments. Then I would only need to make 1 horizontal, 1 full vertical and 1 half vertical.

So, yes interested in anything that will help me achieve that final goal.

Many thanks.
Regards
Dinosaur


[attachment deleted by admin]

MichaelW

Your LCD type segment idea could save a lot of work, but I'm not sure that a 7-segment character would be optimum. AFAIK to insert a bitmap you would need to provide the url.

The attachment includes the compiled FONTVIEW app and all of the components necessary to build it with QB4.5. Note that the 8x14 fonts are not present in some VGA implementations, and for systems where this is so, the 8x14 selection will not work correctly with the 9x16 fonts that those systems substitute. Some of the modules may contain code in the TEST CODE section that may not work (after I played with it).



[attachment deleted by admin]
eschew obfuscation