DLV101@psuvm.psu.edu (Dwaine VanBibber) (11/01/90)
I'm looking for all those neat memory locations and what they do. For example, here are a few: ffff:0 - jump here for warm/cold boot ffff:fffe - machine ID byte 0040:00f0 - Keyboard type (0 older keyboard, 1 extended) ????:???? - keyboard status word (numlock, scroll lock, etc.) ????:???? - stores address of beginning of video memory. Does anyone know where I can find THE definitive list of the? A book or text file that someone has compiled will do fine. Thanks. --Dwaine
sonny@charybdis.harris-atd.com (Bob Davis) (11/01/90)
In article <90304.161727DLV101@psuvm.psu.edu> DLV101@psuvm.psu.edu (Dwaine VanBibber) writes: >I'm looking for all those neat memory locations and what they do. For >example, here are a few: > >ffff:0 - jump here for warm/cold boot >ffff:fffe - machine ID byte >0040:00f0 - Keyboard type (0 older keyboard, 1 extended) >????:???? - keyboard status word (numlock, scroll lock, etc.) >????:???? - stores address of beginning of video memory. > >Does anyone know where I can find THE definitive list of the? A book or >text file that someone has compiled will do fine. Thanks. >--Dwaine Hello, Dwaine, I recommend you fetch from Simtel [26.2.0.74] by anonymous ftp (ways also exist to fetch via E-mail to a server): PD1:<MSDOS.INFO>1216REF2.ARC This Simtel directory, PD1:<MSDOS.INFO>, is, in my opinion, a veritable mother lode of DOS information. You might want to scan across some of its other file descriptions also. Best, ______________________________________________________________________________ Bob Davis, UofALA'66 \\ INTERNET : sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\ UUCP : ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\ AETHER : K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\ VOICE : (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\ FAX : (407) 729-2537 | FOR MYSELF. |_________|
rcollins@altos86.Altos.COM (Robert Collins) (11/02/90)
In article <90304.161727DLV101@psuvm.psu.edu> DLV101@psuvm.psu.edu (Dwaine VanBibber) writes: >I'm looking for all those neat memory locations and what they do. For >example, here are a few: > >ffff:0 - jump here for warm/cold boot F000:FFF0 is preferable to FFFF:0 >ffff:fffe - machine ID byte Probably just a type, but this address is above 1M. Try F000:FFFE. >????:???? - keyboard status word (numlock, scroll lock, etc.) 0040:0017 >????:???? - stores address of beginning of video memory. 0040:004E >Does anyone know where I can find THE definitive list of the? A book or >text file that someone has compiled will do fine. Thanks. Try the IBM "Technical Referance Personal Computer AT" P/N 6280070, I do believe this is the "definitive" list...since it is the source. -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356
bb16@prism.gatech.EDU (Scott Bostater) (11/02/90)
In article <4328@altos86.Altos.COM> rcollins@altos86.UUCP (Robert Collins) writes: >In article <90304.161727DLV101@psuvm.psu.edu> DLV101@psuvm.psu.edu (Dwaine VanBibber) writes: >>I'm looking for all those neat memory locations and what they do. For >>example, here are a few: >> [misc ram location deleted] > >Try the IBM "Technical Referance Personal Computer AT" P/N 6280070, I >do believe this is the "definitive" list...since it is the source. > For those of us who feel that IBM already has enough money... :-) Ralf Brown's interrupt list, inter490.zip (at least that's the version I have) contains a file describing the memory space at 0040:xxxx. I don't know how accurate or complete it is, but you might try it first. >"Worship the Lord your God, and serve him only." Mat. 4:10 "Love the Lord your God with all your heart and with all your soul and with all your mind." Mat 23:37, Deut 6:5 -- Scott Bostater Georgia Tech Research Institute - Radar Systems Analysis "My soul finds rest in God alone; my salvation comes from Him" -Ps 62.1 uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16 Internet: bb16@prism.gatech.edu
wbonner@eecs.wsu.edu (Wim Bonner) (11/02/90)
In article <90304.161727DLV101@psuvm.psu.edu> DLV101@psuvm.psu.edu (Dwaine VanBibber) writes: >I'm looking for all those neat memory locations and what they do. For >example, here are a few: > >ffff:0 - jump here for warm/cold boot >ffff:fffe - machine ID byte >0040:00f0 - Keyboard type (0 older keyboard, 1 extended) >????:???? - keyboard status word (numlock, scroll lock, etc.) >????:???? - stores address of beginning of video memory. > >Does anyone know where I can find THE definitive list of the? A book or >text file that someone has compiled will do fine. Thanks. There is a book out by Microsoft Press called "The Programmers PC Sourcebook" which has all kinds of interesting information in it, including chips on different standard cards and thier port locations. It includes most of what you have asked about here I believe. If you can find it in a bookstore and thumb throuhg it you may find it interesting. It goes up through 1988 as the publish date, so has info on the VGA display cards. Wim. -- wbonner@yoda.eecs.wsu.edu 27313853@wsuvm1.csc.wsu.edu 27313853@Wsuvm1.BITNET 72561.3135@CompuServe.com
ts@uwasa.fi (Timo Salmi) (11/02/90)
In article <16238@hydra.gatech.EDU> bb16@prism.gatech.EDU (Scott Bostater) writes: > >Ralf Brown's interrupt list, inter490.zip (at least that's the version I have) >contains a file describing the memory space at 0040:xxxx. There are two useful lists: /pc/pd2/inter590.zip ^ /pc/pd2/dosref17.zip (buplicates the former in many respects) The wares are available by anonymous ftp from chyde.uwasa.fi, Vaasa, Finland, 128.214.12.3, or by using our mail server (use the latter if, and only if you don't have anonymous ftp). If you are not familiar with anonymous ftp or mail servers, I am prepared send prerecorded instructions on request. (If you don't get the instructions from me within a few days, it will mean that your email address cannot be reached by a simple email reply, and you wouldn't be able to utilize the mail server anyway.) ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
cur022@zodiac.ukc.ac.uk (Bob Eager) (11/05/90)
In article <90304.161727DLV101@psuvm.psu.edu>, DLV101@psuvm.psu.edu (Dwaine VanBibber) writes: > I'm looking for all those neat memory locations and what they do. There is a good book by Phoenix (the BIOS people). Published by Addison Wesley, about $25. Well worth it. In fact, there are three books: XT BIOS - normal BIOS CBIOS - PS/2 compatibility BIOS (superset of above) ABIOS - PS/2 advanced BIOS (multitasking support) I forget the exact title but it's in the AW catalogue. ---------------------+----------------------------------------------------- Bob Eager | University of Kent at Canterbury rde@ukc.ac.uk | +44 227 764000 ext 7589 ---------------------+----------------------------------------------------- *** NB *** Do NOT use the return path in the article header *************** ---------------------------------------------------------------------------
2113av@gmuvax2.gmu.edu (John Porter) (11/10/90)
In article <90304.161727DLV101@psuvm.psu.edu> DLV101@psuvm.psu.edu (Dwaine VanBibber) writes: >I'm looking for all those neat memory locations and what they do. For Please allow me to suggest the following hack, devised by myself, for accessing the BIOS data area in an IBM-PC/compatible computer, from a C program. It works like this: A structure type is defined (NOT ALLOCATED!) to label each byte, word, etc. in the BIOS data area; a pointer is (theoretically) declared to point to a structure of this type; the pointer is initialized to zero (that's numerical 0000:0000, not logical NULL (for you purists (like me))). any dereference of this pointer looks for fields in the actual BIOS data area in low ram, including the interrupt vector table. That's why it starts at zero. I have provided a file, BIOSAREA.H, which does all this; just include it in your C source. Actually, this file does not declare a pointer; that would not be fair. Instead, I made a macro which, when given a field name, takes a ZERO long, casts it to be a pointer to one of these structs, and dereferences to the given field. Works as lvalue, in case you're wondering. Please be aware that this file was made by me, for me. If you don't like the way I've commented it, or other things, change them. If you have any questions, ask me. For example, you may have already defined a type byte, or word. If you don't think it's worth it to define another whole type for something so simple, by god, undo it. MOST IMPORTANT OF ALL!!!!! the compiler directive #pragma pack(1) ABSOLUTELY MUST BE IN EFFECT!!!! I'm sorry I couldn't take the time to comment each field; some of the names aren't very descriptive. If you don't know what a field is for, don't touch it. Generally speaking, any name starting with 'res' meanes that the best info I could find on that field gave no clue as to its purpose. If you find anything not included in this list, please let me know, I'll update this. Thanks. JP /* BIOSAREA.H * Allows easy access to the important data areas in low ram. * Note: the fields in the biosarea struct are in order, and should not * be shuffled. Also important is the pragma directive to align on byte * boundaries. * By John Porter, 1989. */ #ifndef BIOSAREA #define BIOSAREA typedef unsigned char byte; typedef unsigned int word; #pragma pack(1) struct biosarea { void int_vect[0x100]; // 00:00-30:FF word serport[4]; // 40:00-40:07 word ptrport[4]; // 40:08-40:0F word eqlist; // 40:10-40:11 byte POSTstat; // 40:12 NOTE: for PC Convertible only. word usable; // 40:13-40:14 byte res3[2]; // 40:15-40:16 word kbdstat; // 40:17-40:18 byte altkeypad; // 40:19 word kbdhead; // 40:1A-40:1B word kbdtail; // 40:1C-40:1D word kbdbuf[0x10]; // 40:1E-40:3D byte recalstat; // 40:3E byte motorstat; // 40:3F byte motorcount; // 40:40 byte floppyresult; // 40:41 byte floppystat[7]; // 40:42-40:48 byte vidmode; // 40:49 word rowlen; // 40:4A-40:4B word scrnsize; // 40:4C-40:4D word pageofs; // 40:4E-40:4F union { word w; // 40:50-40:5F struct { byte col, row; } b; } cursloc[8]; byte curscan2; // 40:60 byte curscan1; // 40:61 byte pageno; // 40:62 word crtport; // 40:63-40:64 byte crtportmode; // 40:65 // also called 3x8 Register setting byte cgacoloreg; // 40:66 // also called 3x9 Register setting byte tapectl[5]; // 40:67-40:6B // may be instead a far ptr to some reset code. dword masterclock; // 40:6C-40:6F byte midnight; // 40:70 byte ctlbrk; // 40:71 word bootflag; // 40:72-40:73 byte hdiskresult; // 40:74 byte harddisks; // 40:75 byte XThd; // 40:76 // Note: XT only byte XThdport; // 40:77 // " byte ptrtimout[4]; // 40:78-40:7B byte auxtimout[4]; // 40:7C-40:7F word kbdbufstart; // 40:80-40:81 word kbdbufend; // 40:82-40:83 byte scrnrows; // 40:84 word charheight; // 40:85-40:86 word vidstates; // 40:87-40:88 word vidinfo; // 40:89-40:8A byte mediacontrol; // 40:8B byte hdstat; // 40:8C byte hderror; // 40:8D byte hdint; // 40:8E byte res5_1; // 40:8F byte mediastate[2]; // 40:90-40:91 word res5_2; // 40:92-40:93 byte cylinder[2]; // 40:94-40:95 byte kbdflags; // 40:96 byte ledflags; // 40:97 vfp uwcfa; // 40:98-40:9B points to byte: User Wait Complete Flag dword uwaitcount; // 40:9C-40:9F byte waitactive; // 40:A0 byte res6[7]; // 40:A1-40:A7 vfp vidtbl; // 40:A8-40:AB a complex structure byte res7[4]; // 40:AC-40:AF byte res8[0x40]; // 40:B0-40:EF byte ica[0x10]; // 40:F0-40:FF byte int5stat; // 50:00 status of print-screen operation. byte res9[3]; // 50:01-50:03 byte drivemimic; // 50:04 byte resA[11]; // 50:05-50:0F word basicDS; // 50:10-50:11 vfp basiclockhdlr; // 50:12-50:15 in some version of ROM basic. vfp basicbrkhdlr; // 50:16-50:19 vfp basicdiskerrhdlr; // 50:1A-50:1D }; // a macro pseudofunction to reference a field of this structure: #define BA(F) ((*((struct biosarea *)0L)).F) // note that in the case of fields which are arrays, you can place the // square brackets inside OR outside the parens for BA: // BA(cursloc[0]) == BA(cursloc)[0] !!! #endif
2113av@gmuvax2.gmu.edu (John Porter) (11/12/90)
For those of you who may have tried to use my biosarea.h file, or who might in the future, there are some things I would like to point out. There is a third data type used in the struct which I forgot to define at the top (I define it another include file, whose reference I deleted from this file, to keep things clean. I only needed the typedefs.) Namely, vfp. I define this as void far *. You might want to simply replace 'vfp' with 'void far *', or, even better, far * to the actual object type. The best example of this is the field called vidtbl; it is one nasty nested structure. So I left it void. Also, the intvector table, and the various BASIC handlers are far * to functions. The #pragma pack(1) directive is important because the BIOS expects its data in certain places; we must conform. Byte-wise alignment is de rigeur. Equally important is the order in which the fields are defined; again, since we do what BIOS says, rearranging any of these fields results in fubar. Lastly, as some people will no doubt notice, there is no reason why you *can't* declare/allocate a structure of this type. It just won't be the real thing. Possible uses include TOTAL machine context save/restore. I use the biosarea mainly for fast reading of the screen height, width, location, cursor, etc. If you're already doing direct screen writes in your program anyway, you may as well not suffer BIOS speed just to get these data either. Another great use is to directly read the system master clock. This is the number of ticks since midnight. Need a random seed? -- john porter # "Baby...Mother...Hospital...Scissors... # # "Creature...Judgment...Butcher...Engineer" OMD #