DOC PREVIEW
USF CS 630 - Hexadecimal displays

This preview shows page 1-2-22-23 out of 23 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 23 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Viewing 8086 memory-areasHexadecimal displaysOur ‘ax2hex’ procedureA 4-bit left-rotationA bitwise ‘AND’ oprationArray ‘lookup’ operationAlgorithm implementationAlgorithm applicationsDirect-Drawing to VRAMDrawing ‘A’ in top-left cornerOrganization of VRAMWe need more rows for IVTSolutionCode ‘reuse’‘Little endian’ versus ‘Big endian’Example: convert vector 0 to hexSlide 17Tool for exploring 8086 memory‘fileview’ commandsExamplesQuestionBIOS ‘Get MemSize’ functionOur ‘memsize.s’ demoViewing 8086 memory-areasA peek into the video display memory, the real-mode Interrupt Vector Table, and the ROM-BIOS DATA AREAHexadecimal displays•The ability to exhibit computer-data in a form that’s understandable will be vital for exploring (and for debugging) our system•The easiest scheme for doing it will be to show binary values in hexadecimal format•Let’s look at a straightforward algorithm to convert any 16-bit number into a string of (four) hexadecimal numeralsOur ‘ax2hex’ procedure•We create an array of the ascii-codes for the sixteen hexadecimal digit-charactershex: .ascii “0123456789ABCDEF”•Our procedure expects the binary value to be in register AX and the memory-address for the hex-string is in registers DS:DI•Our procedure will preserve the contents of the CPU’s registers (no ‘side-effects’)A 4-bit left-rotation0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 10 1 0 1 0 1 1 0 0 1 1 1 0 1 0 0AX = AX = (Before rotation)(After rotation)Hi-nybbleLo-nybbleA bitwise ‘AND’ opration0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0BX = ? ? ? ? ? ? ? ? 0 1 1 1 0 1 0 0BX = Lo-nybble0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1$0xF = (Before masking)(After masking)(bitmask-value)& & & & & & & & & & & & & & & &= = = = = = = = = = = = = = = =Lo-nybbleBL is copied from ALUnknown bits in BHThus the lo-nybble (4-bits) gets ‘zero-extended’ to its equivalent 16-bit valueArray ‘lookup’ operation‘0’ ‘1’ ‘2’ ‘3’ ‘4’ ‘5’ ‘6’ ‘7’ ‘8’ ‘9’ ‘A’ ‘B’ ‘C’ ‘D’ ‘E’ ‘F’hex:0004BX =hex( %bx ) = ‘4’‘4’buf:&bufDS:DI =‘4’DL =mov hex( %bx ), %dlmov %dl, %ds:( %di ) So the number 4 in BX gets converted to the numeral ‘4’in the ‘buf’ array-cell at DS:DIAlgorithm implementation ax2hex: # converts the word-value in AX to a hex-string at DS:DIpusha # save general registersmov $4, %cx # setup digit-count nxnyb:rol $4, %ax # rotate hi-nybble into ALmov %al, %bl# copy the nybble into BLand $0xF, %bx # isolate the nybble’s bitsmov hex(%bx), %dl # lookup nybble’s ascii-codemov %dl, (%di) # store numeral into bufferinc %di # advance the buffer indexloop nxnyb # generate remaining digitspopa # restore saved registersret # return control to the caller hex: .ascii “0123456789ABCDEF” # array of hex numeralsAlgorithm applications•We can use this binary-to-hex algorithm to view the contents of two memory-regions which ROM-BIOS startup-code initializes:–The table of ‘real-mode’ interrupt vectors–The values in the ROM-BIOS DATA-AREA•Two ‘boot-sector’ demo-programs are named ‘viewivt.s’ and ‘viewrbda.s’•They are on the CS 630 website:<http://cs.usfca.edu/~cruse/cs630>Direct-Drawing to VRAM •Both demo-programs perform their display by writing character-codes directly into the text-mode video-display memory-region (it starts at memory-address 0x000B8000)•Each onscreen character is controlled by a pair of adjacent bytes in the video memoryBackground colorForeground colorASCII character-codeByte at odd-numbered offsetByte at even-numbered offsetDrawing ‘A’ in top-left corner•Here’s a fragment of assembly-language code that draws an uppercase letter ‘A’ in the top-left corner of the screen (using the normal ‘white-on-black’ color-attributes): mov $0xB800, %ax # address VRAM segmentmov %ax, %es # using the ES registerxor %di, %di # point ES:DI at top-left cellmovb $’A’, %es:0(%di) # draw character-code to VRAMmovb $0x07, %es:1(%di) # draw attribute-codes to VRAMOrganization of VRAM•The first 80 byte-pairs in video memory (at offsets 0, 2, 4, …, 158) control the top row (row 0) on the screen (left-to-right order)•Then the next 80 byte-pairs (offsets 160, 162, 164, …, 318) control the next row of text on the screen (i.e., row number 1)•Altogether there are 25 rows of text, with 80 characters per row, when the display is programmed at startup for ‘standard’ text-modeWe need more rows for IVT•The real-mode Interrupt Vector Table has room for 256 ‘pointers’ (each pointer being a doubleword segment-and-offset value)•Not enough cells in the 80x25 text mode to view all 256 of the ‘vectors’ simultaneously•We need 9 characters for each vector (i.e., 8 hex-digits, plus a space for separation), but 256 x 9 is greater than 80 x 25 =2000Solution•We can invoke a ROM-BIOS function that reprograms the display-hardware to show twice as many rows (in smaller-size text)•Here’s a code-fragment to accomplish it:mov $0x0003, %ax # set standard 80x25 textmodeint $0x10 # invoke BIOS video servicemov $0x1112, %ax # load 80x50 character-glyphsint $0x10 # invoke BIOS video serviceCode ‘reuse’•Our earlier ‘ax2hex’ procedure converts a word into a string of hexadecimal digits•But each interrupt-vector is a doubleword!•We could use a new procedure: ‘eax2hex’•But it’s easier if we just call ‘ax2hex’ twice•This requires us to clearly understand the Pentium’s scheme for addressing memory (i.e., the ‘little-endian’ storage convention)‘Little endian’ versus ‘Big endian’0x0369CF25EAX =25CF690301230369CF250123 ‘Little endian’ convention (least-significant byte is at lowest memory-address) ‘Big endian’ convention (most-significant byte is at lowest memory-address) Intel x86 CPU’s use ‘little endian’ storage contentionPower-PC processor uses ‘big-endian’ conventionExample: convert vector 0 to hexbuf: .ascii “xxxxxxxx” # room for 8 hex-digitsVector0:xor %bx, %bx # address bottom of memorymov %bx, %fs # using register-pair FS:BX mov %fs:0(%bx), %ax # fetch vector’s low-wordlea buf+4, %di # point DS:DI to positioncall ax2hex # convert AX to hex-stringmov %fs:2(%bx)m %ax # fetch vector’s high-wordlea buf+0, %di # point DS:DI to positioncall ax2hex # convert AX to hex-string# OK, ‘buf’ now holds the 8-digit hex-string representing vector 0‘Real-Mode’ Memory


View Full Document

USF CS 630 - Hexadecimal displays

Documents in this Course
Load more
Download Hexadecimal displays
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Hexadecimal displays and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Hexadecimal displays 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?