--------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00009Date: 03/19/97 From: IAN MOOTE Time: 08:38am \/To: KURT WISMER (Read 2 times) Subj: Gs -> NC> FidoNet is free. -> -> free for the user, but not necessarily so for the sysop... there are -> plenty of systems out there that have to pay ld charges at the very -> least just to pick up packets from a reliable node... they in turn -> distribute that cost to local systems that get the packets from -> them... ECRP. $60 a year in my area for Point systems. Must be nice to live in an area where you can set yourself up as a full node and not have to pay any ECRP costs at all. Don't think I've ever heard of that, myself. His hubmeister must have a heart of gold. Other than air, sunlight, and bad manners it's hard to find >anything< that's truly free anymore. How ya bin, Kurt? Long tyme no tipe! [;) Take care and TTYL. ** Defining oneself is like trying to bite your own teeth. --- PCBoard (R) v15.3/M 5 * Origin: The GameBoard BBS - 9056893982/9409 - BurlingtonONCANADA (1:244/506) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00010Date: 03/18/97 From: GLEN MCNABB Time: 06:55pm \/To: NICK COONS (Read 2 times) Subj: Extra Space. Hi Nick, Several topics.... On <17 Mar, 15:36>, Nick Coons wrote to Eric Nadeau : NC> > and everything should be ok. BTW, using 'normal' memory is faster than NC> > using the one on your video card... NC> I don't know of any other place (within the first meg) that I can NC> write to (consistantly) without overwriting something of importance. Assuming your using dos... consistant memory can be found in several mannors depending on several factors.... Default setting for memory allocation is first come first serve.... On a COM program it is allocated ALL memory and has to resize before requesting a block of memory from the pool. The only thing that resides at the end segment of "conventional memory" is the transient portion of COMMAND.COM You can check the amount of memory after the COM segment (only one) if you look at PSP:0002 will give you the top of memory in paragraphs. (blocks of 16 bytes) EXE memory allocations are somewhat easier because, you don't have to resize your programs memory usage (as in a com program) before requesting a block from DOS. In other operating systems, the rules differ. They don't allocate the ENTIRE memory pool to any program. They can't. This doesn't mention XMS memory, which, by the way, when in use, does happen within the 1st meg of memory. The memory window for XMS is located there. Usually it's in the E000:0000 to FFFF segment. If not, then it's in the D000:0000 to FFFF segment. You can request from XMS driver the address of that segment. Lastly, I viewed a TSR source code that grabbed an interupt and a block of memory and returned to dos. It's function was to serve as a memory block for programs to exchange data via an interupt. It would be great for multitasking programs that do such exchanges. If your using a EGA/VGA card, why bother with B800:whatever? These cards also have memory in A000:0000 to FFFF that is unused during the CGA "type" video displays. A full 64k to play with that most memory managers don't touch. (unless told to) Glen... --- ProBoard v2.15 [Reg] * Origin: Bucolic Fair, Pasco WA 1-509-545-5031 (1:3407/25) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00011Date: 03/18/97 From: GLEN MCNABB Time: 07:20pm \/To: NICK COONS (Read 2 times) Subj: NOP and clocks... Hi Nick, I have been reading several messages about NOP nmenonic. Here's my two cents. (less rebates :) NOP instruction for any better term is equivalent to XCHG AL, AL. There are several XCHG instructions that vary from which register to register size. IE: byte vs. word vs. etc.... The whole point of an NOP nmenonic is to create a delay. The accuracy of the delay depends on the microprocessor and the operating system. An NOP instruction will be faster (time wise) on a 500mhz ZORBO micro than a 1mhz ZORBO. Generally to make an NOP a more accurate timer you must sample the nmenonic against a reference. The timer is a good one. Determine in software the "average" number of NOP instructions that can be executed between timer ticks by using a hook into the timer interupt and a loop of NOP's. This can be used to determine the specific number of NOP's for specific time delays and the micro's speed as well. I would write you up a sample but I am saving myself for some heavy coding tonight.... Glen.. --- ProBoard v2.15 [Reg] * Origin: Bucolic Fair, Pasco WA 1-509-545-5031 (1:3407/25) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00012Date: 03/17/97 From: JOHN GARDENIERS Time: 11:20pm \/To: ALL (Read 2 times) Subj: Version 7 nodelist * Crossposted in ECPROG * Crossposted in 80XXX * Crossposted in C_ECHO Hi All, Can anyone help me with a source of information regarding the version 7 nodelist (compiled)? I need enough information to be able to write a nodelist lookup utility. I have information on the raw nodelist but nothing on the compiled list. ttyl, >>> Fuse >>> --- GoldED 3.00.Alpha2+ * Origin: The Cubby House, assembled by the C (3:632/360.70) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00013Date: 03/19/97 From: FLEMMING SONDERGAARD Time: 09:14am \/To: NICK COONS (Read 2 times) Subj: MOV using same register. Cool! This is like... mail or something! Once upon a time (Monday, March 17, 1997 to be precise), Nick Coons wrote a letter to All about "MOV using same register."... NC> Would using the following instruction: NC> mov bx, [bx] NC> ...actually do what it looks like it would do? That is, move the NC> contents of the memory location pointed to by ds:bx into bx? Yes it would. NC> Can I use a segment override here (es)? Indeed you can. You can even use: mov es,es:[bx] In other words, there is very little you can not do with this type of instruction. Except moving from memory to memory ;-). ___,/| \ o_O| - Flemming Sondergaard =(_|_)= U --- Terminate 4.00/Pro * Origin: Nuke the Whales! (2:237/45.15) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00014Date: 03/19/97 From: FLEMMING SONDERGAARD Time: 09:24am \/To: BRIAN MCCLOUD (Read 2 times) Subj: Extra Space. Cool! This is like... mail or something! Once upon a time (Sunday, March 16, 1997 to be precise), Brian McCloud wrote letter to Nick Coons about "Extra Space."... [..] NC>> mov [es:bx], [di] NC>> ...and NC>> mov [es:di], [bx] NC>> ...it says that I cannot use the segment override. Is there a way NC>> around that? BM> first of all, if you're using MASM or a compatible assembler, the orrect BM> way of doing a segment override is like this: BM> mov es:[di], [bx] I'm pretty sure it would accept [es:di]. BM> second of all, why aren't you doing these as REP MOVSW instructions? It's slower than moving the data "manually". But I'm also pretty sure that's not the problem :). It seems as if Nick has previously programmed on an Amiga or a similar machine where memory-to-memory operations are supported. That's not the case on the PC. You _need_ to move the data through a register. Yes, the 80x86 has got to be the most worthless piece of silicone the world has ever seen :-\. ("`-/")_.-'"``-._ O O `; -._ )-;-,_`) =(_~_)= _ )`-.\ ``-' - Flemming Sondergaard _.-~_..-_/ / ((,' ((,.-' ((,/ --- Terminate 4.00/Pro * Origin: Ecky Ecky Ecky pTANG Bing whing prrn zhrrn-wuP (Ni!) (2:237/45.15) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00015Date: 03/19/97 From: HANS LUNSING Time: 08:52pm \/To: NICK COONS (Read 2 times) Subj: MOV using same register. Hello Nick On Monday, 17 March 1997 16:57:00, you wrote to All: NC> Would using the following instruction: NC> mov bx, [bx] NC> ...actually do what it looks like it would do? That is, move NC> the contents of the memory location pointed to by ds:bx into bx? Sure, it does. NC> Can I use a segment override here (es)? Yes, you can. Friendly greeting you, Hans Lunsing, Fido : 2:281/607.214 Internet : jlunsing@doge.nl --- Terminate 4.00/Pro * Origin: The Animal Farm For BASIC Programmers! ++31793512523 (2:281/607.214) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00016Date: 03/19/97 From: ANTON TOKAR Time: 05:37pm \/To: PETER VAN HERTUM (Read 2 times) Subj: Re: scrolling Hi Peter On 10.03.97, Peter Van Hertum wrote to Anton Tokar about Re: scrolling following: PVH> animated objects in games, do they just redraw them with REP MOVSW PVH> ? In the most cases, yes. But there are some other methods like DMA (the old one) and the FPU. Bye. Yours, Anton Tokar aka Spiceman -=[*eMail*: tokar@pegasus.dvz.fh-aachen.de ]=- --- CrossPoint v3.11 * Origin: Windows 95 - Native Plug & Pray (2:2433/619.14) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00017Date: 03/17/97 From: JOSH FISHER Time: 02:14pm \/To: IAN MOOTE (Read 2 times) Subj: NASM -=> Quoting Ian Moote to Josh Fisher on 12 Mar 97 <=- JF> Sorry. The post I replied to discussed MASM compatibility. It is a JF> valid issue for those with alot of MASM or TASM source code they JF> would rather not have to translate. IM> I don't believe that's true (that it's really a valid issue). Firstly, IM> how often does the average hobbyist change assemblers? You're right, it's not a valid issue at all for the hobbyist. Only the professional programmer would care very much. That is the reason for MASM compatibility in TASM, and also the reason NASM ignores other assemblers altogether. IM> Basically what I'm saying is that if you've written a lot of software IM> under Tasm, for example, and you specifically want Tasm compatibility, IM> why on Earth would you switch >from< Tasm to something else!? I've IM> never understood this "issue". You wouldn't. That is why TASM started out with MASM compatibility. :) Simply because MASM preceded it, and it was the only way to get anyone to switch. (Along with an initially low price.) --- --- Joshua Fisher --- Cincinnati, Ohio USA --- jfisher@your-net.com --- *SignIt 1.6* Signed on 03-17-1997 --- Blue Wave/386 v2.30 * Origin: StarNet Development Mason, Ohio USA (1:108/550) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E3P00018Date: 03/19/97 From: NICK COONS Time: 03:37pm \/To: TED MENKS (Read 2 times) Subj: 486 MOV. Hi Ted! > > > if THaT's what It takes to gather knowledge... > NC> I probably would if it was one of my priority interests right now. > You dare say that it is NOT important to you? Not even when *I* ask you > to do so? Shame on me! ;-) Yes, sorry M'Lord... :-). Nick Coons nick.coons@juno.com Dynamic Computer Systems --- FMail/386 1.02 * Origin: Dynamic Computer Systems (1:114/404)