From: "Gordon Hogenson" Date: Sat, 16 Apr 1994 23:37:52 -0700 To: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Fatal DOS Memory error using _go32_simulate_int Ok, in response to DJ's comments (thanks, DJ!), I'm using the transfer buffer to transfer to DOS memory, setting and reading the palette. Now I've gone on to tackle another BIOS call, the "load custom character font" call. Unfortunately, using *either* the transfer buffer method, or the _go32_dpmi_allocate_dos_memory method, the system self-reboots when I run my program. If I single step through the program (under edebug32) I can get all the way through! But, as soon as I exit from the debugger (it says my program has terminated normally), I get an error from 4DOS: 4DOS server error -- Memory allocation error. Fatal error--please reboot. Humph! So I ask, what should I be watching for in the debugger assembly code that could cause a 'memory allocation error'. Am I not using the go32 functions correctly? ------------------------------------------------------------------- /* buf is a ptr to k 32-byte blocks, representing characters. * this procedure writes k characters into the char table starting * at offset */ write_char_gen(unsigned char* buf, unsigned short k, unsigned short offset) { _go32_dpmi_registers r; unsigned long xfer_buf_addr = _go32_info_block. linear_address_of_transfer_buffer; unsigned short xfer_buf_offset = xfer_buf_addr % 16; unsigned short xfer_buf_seg = xfer_buf_addr / 16; dosmemput(buf, k*32, xfer_buf_addr); r.x.es = xfer_buf_seg; r.x.bp = xfer_buf_offset; r.h.ah = 0x11; /* Load Character Generator */ r.h.al = 0; /* 0x10 if you want timing recomputed */ r.x.cx = k; r.x.dx = offset; r.h.bh = 16; /* number of bytes per char : VGA=16 */ r.h.bl = 0; /* which char set (0-7) */ _go32_dpmi_simulate_int(0x10, &r); } int main() { unsigned char buf[32]; memset(buf, 0xFF, 16); memset(buf+16, 0x00, 16); write_char_gen(buf, 1, 65); /* should replace 'A' with a solid block */ } This is run from 80x25 mode. Since the custom character set is stored in plane 2 of display memory, is there something wrong with having the BIOS modify that memory from a protected mode program?? Or am I missing something obvious? Gordon -- ---------------------------------------------------------------- Gordon J. Hogenson Tel. (206) 522-5664 home email: ghogenso AT u DOT washington DOT edu (206) 685-2951 work finger: gordon AT yrd DOT chem DOT washington DOT edu FAX: (206) 685-8665