Some additional tests

This commit is contained in:
Jeff Parsons 2015-05-19 15:51:48 -07:00 committed by jeffpar
commit 35c9648f6d
3 changed files with 60 additions and 19 deletions

View file

@ -34,7 +34,7 @@
"scale": true,
"charCols": 80,
"charRows": 25,
"fontROM": "/devices/pc/video/ibm-mda-cga.json",
"fontROM": "/devices/pc/video/ibm/mda/ibm-mda.json",
"screenColor": "black",
"touchScreen": false
}
@ -78,7 +78,7 @@
"debugger": {
"id": "pc386.debugger",
"name": "",
"commands": "bp F000:8271;g",
"commands": "",
"messages": ""
}
}

View file

@ -2774,29 +2774,23 @@ Video.prototype.onLoadSetFonts = function(sFontFile, sFontData, nErrorCode)
*
* Called by copyROM() whenever a ROM with a 'notify' attribute set to our component ID has been loaded.
*
* For IBM EGA cards, we assume the associated ROM is the original IBM EGA ROM, which stores its 8x14 font
* data at 0x2230 (and unlike the MDA/CGA character generator ROM, which splits the first 8 rows and
* For IBM EGA cards, we assume the associated ROM is the original IBM EGA ROM, which stores its 8x14
* font data at 0x2230 (and unlike the MDA/CGA character generator ROM, which splits the first 8 rows and
* remaining 6 rows of each character across separate 2K chunks, the bytes for all the EGA character rows
* are contiguous); the total size of the 8x14 font is 0xE00 bytes.
*
* At 0x3030, there is an "ALPHA SUPPLEMENT" table, which contains 15 bytes per row instead of 14,
* because each row is preceded by one byte containing the corresponding ASCII code; there are 20 entries
* in the "ALPHA SUPPLEMENT" table, for a total size of 0x12C bytes.
* in the supplemental table, for a total size of 0x12C bytes.
*
* Finally, at 0x3160, we have the 8x8 font data (also known as the thicker "double dot" CGA font);
* the total size of the 8x8 font is 0x800 bytes. No other font data is present in the EGA ROM;
* the thin 5x7 "single dot" CGA font is notably absent, which is fine, because we never loaded it for
* the MDA/CGA either.
*
* TODO: Determine how the "ALPHA SUPPLEMENT" table is used and whether we need to add some "run-time"
* font generation to support it (as opposed to "init-time" generation, which is all we do now). There's
* probably a similar need for user-defined fonts; for now, they're just not supported.
*
* IBM VGA NOTES: The IBM VGA "ALPHA SUPPLEMENT" table appears at the same delta (+0x0E00) as the IBM EGA
* table (ie, 0x3f8d + 0x0e00 = 0x4d8d). If we assume the same length for the supplement table (20 chars,
* 15 bytes per char, for a total of 0x12c bytes, rounded up to 0x130), that would put the 8x8 data at
* offset 0x4ebd. I suspect the data ends at around 0x5eb9, meaning it's organized as 16 bytes per char
* instead of 8.
* TODO: Determine how the supplemental table is used and whether we need to add some "run-time"
* font generation to support it (as opposed to "init-time" generation, which is all we do now).
* There's probably a similar need for user-defined fonts; for now, they're simply not supported.
*
* @this {Video}
* @param {Array.<number>} abROM
@ -2813,7 +2807,12 @@ Video.prototype.onROMLoad = function(abROM)
}
else if (this.nCard == Video.CARD.VGA) {
if (DEBUG) this.printMessage("onROMLoad(): VGA fonts loaded");
this.setFontData(abROM, [0x3f8d, 0x0000], 8);
/*
* The IBM VGA contains an 8x14 font at 0x3F8D (and corresponding supplemental table at 0x4D8D)
* and an 8x8 font at 0x378D; however, it also contains an 8x16 font at 0x4EBA (and corresponding
* supplemental table at 0x5EBA). See our reconstructed source code in ibm-vga.nasm.
*/
this.setFontData(abROM, [0x3f8d, 0x378d], 8);
}
this.setReady();
};

View file

@ -72,6 +72,7 @@ CSEG_PROT16 equ 0x0008
CSEG_PROT32 equ 0x0010
DSEG_PROT16 equ 0x0018
DSEG_PROT32 equ 0x0020
SSEG_PROT32 equ 0x0028
;
; The "defDesc" macro defines a descriptor, given a name (%1), base (%2), limit (%3), type (%4), and ext (%5)
@ -162,6 +163,7 @@ myGDT: defDesc NULL,0 ; the first descriptor in any descriptor table is always
defDesc CSEG_PROT32,0x000f0000,0x0000ffff,ACC_TYPE_CODE_READABLE,EXT_BIG
defDesc DSEG_PROT16,0x00000000,0x000fffff,ACC_TYPE_DATA_WRITABLE,EXT_NONE
defDesc DSEG_PROT32,0x00000000,0x000fffff,ACC_TYPE_DATA_WRITABLE,EXT_BIG
defDesc SSEG_PROT32,0x00010000,0x000effff,ACC_TYPE_DATA_WRITABLE,EXT_BIG
myGDTEnd:
initGDT:
@ -174,8 +176,9 @@ initGDT:
shl eax,4
setDesc CSEG_PROT16,eax,0x0000ffff,ACC_TYPE_CODE_READABLE,EXT_NONE
setDesc CSEG_PROT32,eax,0x0000ffff,ACC_TYPE_CODE_READABLE,EXT_BIG
setDesc DSEG_PROT16,0x0,0x000fffff,ACC_TYPE_DATA_WRITABLE,EXT_NONE
setDesc DSEG_PROT32,0x0,0x000fffff,ACC_TYPE_DATA_WRITABLE,EXT_BIG
setDesc DSEG_PROT16,0x00000000,0x000fffff,ACC_TYPE_DATA_WRITABLE,EXT_NONE
setDesc DSEG_PROT32,0x00000000,0x000fffff,ACC_TYPE_DATA_WRITABLE,EXT_BIG
setDesc SSEG_PROT32,0x00010000,0x000effff,ACC_TYPE_DATA_WRITABLE,EXT_BIG
sub edi,RAM_GDT
dec edi
mov [RAM_GDTR],di
@ -365,13 +368,13 @@ testROM:
;
movsx eax,byte [0xfffff]
cmp eax,0xffffff80
jne error
jne near error
;
; Test moving a word to a 32-bit register with sign-extension
;
movsx eax,word [0xffffe]
cmp eax,0xffff80fc
jne error
jne near error
;
; Test moving a byte to a 32-bit register with zero-extension
;
@ -384,6 +387,45 @@ testROM:
movzx eax,word [0xffffe]
cmp eax,0x000080fc
jne error
;
; Test assorted 32-bit addressing modes
;
mov ax,SSEG_PROT32 ; we're not going to use the stack, but we want SS != DS for the next tests
mov ss,ax
sub esp,esp
mov edx,[0x40000] ; save word at scratch address 0x40000
mov eax,0x11223344
mov [0x40000],eax ; store a known word at the scratch address
mov ecx,0x40000 ; now access that scratch address using various addressing modes
cmp [ecx],eax
jne error
add ecx,64
cmp [ecx-64],eax
jne error
sub ecx,64
shr ecx,1
cmp [ecx+0x20000],eax
jne error
cmp [ecx+ecx],eax
jne error
shr ecx,1
cmp [ecx+ecx*2+0x10000],eax
jne error
cmp [ecx*4],eax
jne error
mov ebp,ecx
cmp [ebp+ecx*2+0x10000],eax
je error ; since SS != DS, this better be a mismatch
mov [0x40000],edx ; restore word at scratch address 0x40000
jmp doneProt
error: nop