--------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00001Date: 02/10/98 From: SCOTT MCNAY Time: 12:59am \/To: DARRYL GREGORASH (Read 1 times) Subj: System timer tick counter *** Darryl Gregorash wrote in a message to Robert Fortune: RF> Does anyone know why a doubleword (40:6C thru 40:6F) is RF> reserved in the BIOS Data Area to hold the system timer RF> ticks (18.2xxxx per second), but only uses 3 of the 4 RF> bytes to hold the number of timer ticks? DG> Because a simple "mov DWO PTR sys_time, eax" is far easier DG> than any of the alternatives using only 3 storage bytes. Wrong answer... the BIOS was written before the 386 ever came out, and "eax" is definitely a 386 thingie. --Scott. --- timEd 1.01 * Origin: Wizard's PC Services, BBS=254-554-2146, Pager=903-3097 (1:395/11) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00002Date: 02/09/98 From: ED BEROSET Time: 06:42pm \/To: ALL (Read 1 times) Subj: Re: Directly writing to memor From: Ed Beroset Subject: Re: Directly writing to memor At 13:05 2/7/98, you wrote: > >DG> Setting SP 2 bytes above is something I never thought of, >DG> and would work in all situations.. unless, of course, one is working >DG> with an XT, in which case SP is decremented after the write. > >actually on an XT it's decremented before the write, and the new >value is stored at SS:(SP) I just tested it. > >on my 486 the old (un-decremented) value is stored at the new >(decremented) address. > >in other words... > > start with SP=FFEE , then do push SP > > xt SS:[FFEC] = FFEC > 486 SS:[FFEC] = FFEE > > end with SP=FFEC Thanks for posting that. It's usually clearer to show the numbers in addition to getting the text description. Just for completeness, here's an extract from Intel's Pentium manual which describes that difference: -+--- extract begins 23.2.19.1. PUSH SP The Pentium processor, Intel486, Intel386, and Intel 286 processors push a different value on the stack for a PUSH SP instruction than the 8086 processor. The 32-bit processors push the value of the SP register before it is decremented as part of the push operation; the 8086 processor pushes the value of the SP register after it is decremented. If the value pushed is important, replace PUSH SP instructions with the following three instructions: PUSH BP MOV BP, SP XCHG BP, [BP] This code functions as the 8086 processor PUSH SP instruction on the Pentium processor. -+--- extract ends >Someone said you could initialise SP to 2 bytes _past_ then end of >stack segment and then push a Dword, I don't think that'll work >because the cpu will attempt to write the last 2 bytes of the dword >past the end of the stack segment, (won't that cause a SEGV and >that'll cause a double-fault :) ) If that's what I wrote, I was wrong and you're right. Thanks for the correction! >i think pointing to the first non-stack-segment asddress is the highest you >can go with SP. That's right. What I was attempting to say (perhaps poorly!) was that the initial value for SP can be two bytes beyond the last legal stack address, e.g. the last legal stack address for a 16-bit 64K stack is 0fffeh and two bytes beyond that is 10000h. If one considers the stack to be 32-bit, the last legal stack address is 0fffch, and four bytes beyond that is 10000h. As I'm sure you already know, if we start with that value (10000h) for a 64K stack, it doesn't matter what size value is pushed first. "Pointing to the first non-stack-segment address" is more succinct than how I was saying it. Perhaps it could be stated even more concisely as, "the highest safe value for the stack pointer is one byte beyond the upper bound of the stack segment." Ed -!- --- * Origin: The Circuit! Board * Spokane * (1:346/100) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00003Date: 01/30/98 From: BRYAN SCHWARTZ Time: 08:13am \/To: RYAN BAGUEROS (Read 1 times) Subj: PC clone Can you be a little bit more specific? Do you want to build your own mother board or purchase parts and put them together? Do you want to design your own microprocessor with ICs eg. TTL parts like nand, nor, xnor gates or will you purchase a 80486 or MC68040 and build around it? Or do you just want to put together a cheap clone from used and wholesale cards? And write your own operating system or use OS/9, or MSDos, or CP/M etc. ? These are all important decisions when building a system. It's a great project. Tell us more about what exactly you want to do and you'll probably get the info you need. Otherwise, its a very wide topic. --- QScan/PCB v1.17b / 01-0105 * Origin: 1:348/206 Muddy Waters 204-231-4507 (1:348/206) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00004Date: 02/02/98 From: BRYAN SCHWARTZ Time: 08:58am \/To: PETER MAGNUSSON (Read 2 times) Subj: flat.xx How do i decode your code? Where do you get this 'xx3402' ? eg. xx3402 d flat.xx --- QScan/PCB v1.17b / 01-0105 * Origin: 1:348/206 Muddy Waters 204-231-4507 (1:348/206) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00005Date: 02/09/98 From: JASEN BETTS Time: 04:57pm \/To: FERNANDO ARIEL GONT (Read 1 times) Subj: micro-ops 1/2 FA> the _*micro-ops*_ table... FA> (Do you know where I can get the table I need?) FA> e-mail: FGont@siscor.bibnal.edu.ar It looks like you have internet... Have you tried intel.com :-) --- EzyQwk V1.20 * Origin: CSS Brisbane, Qld, Australia. (61-7-3367-3890) (3:640/350) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00006Date: 02/09/98 From: JASEN BETTS Time: 04:42pm \/To: PETER MAGNUSSON (Read 1 times) Subj: REAL BIG! PM> JB> What is "big real mode" ? is it just protected mode without PM> JB> virtual memory? (I've been away from this echo for too long.) PM> PM> Big real mode, aka flatmode, PM> PM> go into real mode (V86 won't do it) PM> flip around with some things and remove the 64k limit PM> wolla! Big real mode! 4 GB memory accessible in real mode. PM> PM> No more need for XMS and EMS handlers, you can access everything PM> as flat memory... So I guess 16 bit code won't run in flat mode then.... It sounds to me like protected mode with memory management turned off. --- EzyQwk V1.20 * Origin: CSS Brisbane, Qld, Australia. (61-7-3367-3890) (3:640/350) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00007Date: 02/10/98 From: JASEN BETTS Time: 04:55pm \/To: SYLVAIN LAUZON (Read 1 times) Subj: returned char on enter ke SL> Using int 16h/00 function will the returned "ENTER" key be 0D? Or SL> it can be 0A under unix? (emudos) It'll alwaus be ctrl-m for enter (it's a part of the ASCII standard) ... even under unix, --- EzyQwk V1.20 * Origin: CSS Brisbane, Qld, Australia. (61-7-3367-3890) (3:640/350) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00008Date: 02/10/98 From: ROBERT FORTUNE Time: 02:38pm \/To: DARRYL GREGORASH (Read 1 times) Subj: System timer tick counter RF> Does anyone know why a doubleword (40:6C thru 40:6F) is RF> reserved in the BIOS Data Area to hold the system timer RF> ticks (18.2xxxx per second), but only uses 3 of the 4 RF> bytes to hold the number of timer ticks? DG>Because a simple "mov DWO PTR sys_time, eax" is far easier than any of the DG>alternatives using only 3 storage bytes. Thank you. I wondered if I was wrong that only 3 bytes were being used when four were reserved. - Robert * OLX 2.1 TD * "And somebody spoke and I went into a dream." --- PCBoard (R) v15.3/M 10 * Origin: MoonDog BBS Brooklyn,NY 718 692-2498 (1:278/230) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00009Date: 02/10/98 From: BRIAN MCCLOUD Time: 04:05am \/To: FERNANDO ARIEL GONT (Read 1 times) Subj: micro-ops FAG>I really thank you for your help... but the fact is that I'm looking for FAG>the _*micro-ops*_ table... FAG>That means, at least in Pentium II and Pentium Pro, Each instruction is FAG>decoded to "simpler" instructions called micro-ops.... I must admit I hadn't worked enough with Pentium processors to be aware of this. Thank you for clarifying that these "micro-ops" aren't the same as instruction clocks. FAG>The speed with which a program executes depends on the orden in which you FAG>put the instructions of the program (besides a lot of things), because FAG>there are threee decode units, but one of them can handle some instructions FAG>that the others can, so that you must put the instructions in a certain FAG>order so that you keep all decode-units busy all the time... FAG>It's a very simple and not-so-good explanation about Pentium II and Pentium FAG>Pro microarchitecture, but it does to explain you what I am needing, I FAG>think... I'd say the explanation is sufficient... I also wonder if these "micro-ops" would be useful if one were porting from a Pentium to a PowerPC... FAG>Anyway, thank you very much! (Do you know where I can get the table I FAG>need?) I can look for such a table... ((Cloud)) MauveCloud@juno.com * OLX 2.2 * Call The Wrong Number BBS (209/943-1880) - 4nodes @14.4k --- PCBoard (R) v15.3/M 10 * Origin: Next time, Dial The Wrong Number! (209) 943-1880 (1:208/205) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F2F00010Date: 02/09/98 From: DIMITRI SMITS Time: 09:35pm \/To: FERNANDO ARIEL GONT (Read 1 times) Subj: CD-ROM Hi Fernando, first off, I am NOT an expert (in fact, I started on the MSCDEX specs-reading only 3 days ago, because I wanted to code a CD-player under DOS (in Pmode, but DOS nevertheless ;-)) I have to tackle the extra problem that I have to call the function from PMODE and simulate the interrupt, but I am already (finally) past that problem. > I debugged it, and found that when it doesn't work, it > seems that the name > it gets of the driver isn't correct, so when I try to > open the driver as a > file, I get a "file not found" error code. I am just curious, but why do you do your communications directly via the driver? You don't need the driver-handle to communicate with a CD-ROM ... only its drive number :-) since you use the MSCDEX, I think you can look up the function 01510h of int 02Fh ... it does the same thing as providing IOCTL I/O with the driver (amongst other things) ... if you don't have the MSCDEX (2.x) specs, I can send them to you (if you have email) > The name it gets under MS-DOS is different from the > one that it gets under > W'95, but it should work anyway, I think.... I am just guessing (since I don't know much about WIn'95 programming), but I think the driver-name (8 byte field) ie the 'device' name isn't at the same offset when using Win'95 and its 32bit drivers. So that's why the int 21h / Open Existing File or Device doesn't work. > Another fact, all the programs (well, except one from > Tenie Remmel's > snippets that doesn't use this "technique") have the > same "bug" as my > program... don't use int 21h to communicate with the drive. After having detected MSCDEX (int 2fh, fct 1100h, sub 0DADAh) ask for the number of drives and the first drive number (int 2fh, fct 1500h) ... then use a number relative to the first drive (smaller than the number of drives) to acces that CD-ROM via a similar IOCTL-call (with int 2fh, fct 1510h) > I have really no idea about what could be happening... > :( My guess is the above (since I have made a small PASCAL programm that ejects the tray (just to test)), and it worked fine under DOS as well as Win'95 (also when I hadn't loaded MSCDEX.EXE) besides, I suspect that since it is an Progr. Interface (int 2fh, fct 15xxh), it is likely that Win'95 drivers must obey in a same way, with the same interface. So don't call for the handle and then use int 21h fct 44xxh, but instead do the above. ... Here is the PASCAL prog (not really a clean example, since I whipped it up as a RM example and test case for inside W'95) ... sorry to all for pascal-code, but I am not able to make a full asm prog (I only use asm to optimise or in this case: do something in a specific and defined, hence 'do-it-like-that-or-else' way) -*- TYPE transfer = record command : byte; end; reqhdrioctl = record hsize, subunit, command: byte; status : word; reserved : array[0..7] of byte; mediadesc : byte; t : ^transfer; tnr : word; startsect : word; pIDfunc : longint; end; VAR b: reqhdrioclt; t : transfer; CONST eject: byte = 0; drivenr = 4; { change this to the drivenr of your CD-ROM 0 = A:, 1 = B:, 2 = C: ... 25 = Z:} BEGIN b.hsize := 26; b.command := 12; b.subunit := 0; b.t := addr(t); t.command := eject; b.mediadesc := 0; b.tnr := 1; b.startsect := 0; b.pIDfunc := 0; ASM mov ax, ds mov es, ax mov ax, $1510 mov bx, offset b mov cx, drivenr; int 2fh END; END. > e-mail: FGont@siscor.bibnal.edu.ar if you don't have it, drop me a note, and I'll send the specs to this addres via a mime-attached zip-file. Greetz, Da Gongo --- FMail/386 1.02 * Origin: Hiroshima '45, Tsjernobil '86, Windows '95 (2:292/8013.12)