--------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00011Date: 07/15/97 From: JON GENTIL Time: 01:22pm \/To: JAMES VAHN (Read 1 times) Subj: to ALL? Replying to a message from James Vahn to Jon Gentil, About to ALL?, On Mon, Jul 14, 1997 > He knows, but you see, on the Internet, there are no TO: fields, so it > is impossible for him to post to anyone BUT "ALL". JV> Jon, this might be a strange question, but.. how does this one JV> look? Is there any hint that it is not a traditional Fido message? Your message? It looks just fine to me. Here's a copy of it: Area : 80xxx Assembly Date : Mon Jul 14, 21:37 rcv From : James Vahn 1:346/15.1 To : Jon Gentil Subj : to ALL? > He knows, but you see, on the Internet, there are no TO: fields, so it > is impossible for him to post to anyone BUT "ALL". Jon, this might be a strange question, but.. how does this one look? Is there any hint that it is not a traditional Fido message? ... The Moon is Waxing Gibbous (72% of Full) --- FMail/386 1.22a+ * Origin: 300 miles East of Seattle, WA (1:346/15.1) Jon Gentil - jon.gentil@magi.station-1.com - [PGP KeyId:0x3EB376B5] --- * Origin: MagiGate MultiHub - Pekin, IL - FidoSpine Hub (1:232/211) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00012Date: 07/14/97 From: JON GENTIL Time: 10:30pm \/To: "EDWARD BEROSET" (Read 1 times) Subj: What's wrong with this??? Replying to a message from "Edward Beroset" to All, About What's wrong with this???, On Mon, Jul 14, 1997 "B> The only thing wrong with the code as far as I can see is that it "B> doesn't have the AA55h signature at location 01FEh. On some "B> systems the BIOS will load it anyway, but the BIOS would be "B> correct to reject it. FWIW, I converted it to TASM, assembled it "B> and loaded it onto the boot sector of a floppy which already had a "B> stub loaded onto sector 2 and everything worked just fine. Hmm... That's strange. Maybe it's my disk. :) I might format it for DOS and load it up. I might have a bad Sector 2 now. (eek!) "B> If you put a different header in your code and changed the starting "B> location of the code (from sector 2), you could have the diskette "B> compatible with DOS and still do the same thing. Right now, as "B> you probably already know, sector 2 is going to be on top of the "B> start of the FAT and by not including the BIOS parameter block at "B> the beginning of sector 0, you render the disk unreadable to DOS. "B> It may not be of any concern to you once you get the thing up and "B> running, but it might be handy to make the minor changes required "B> so that troubleshooting is made a bit easier. I assume that you "B> must be using some flavor of DOS because you say you're using A86. Yeah, I had it originally starting at Sector 16, with it being DOS ompatable. Now, what's the offset on Sector 1 that you can start putting code without overwriting the BIOS Param block? Thanks! Jon Gentil - jon.gentil@magi.station-1.com - [PGP KeyId:0x3EB376B5] [] Religion: myth-information. --- FMail/386 1.22a+ * Origin: MagiGate MultiHub - Pekin, IL - FidoSpine Hub (1:232/211) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00013Date: 07/15/97 From: JON GENTIL Time: 01:07am \/To: "EDWARD BEROSET" (Read 1 times) Subj: What's wrong with this??? Following up on a message from Jon Gentil to "Edward Beroset" , About What's wrong with this???, On Mon, Jul 14, 1997 "B> The only thing wrong with the code as far as I can see is that it "B> doesn't have the AA55h signature at location 01FEh. On some "B> systems the BIOS will load it anyway, but the BIOS would be "B> correct to reject it. FWIW, I converted it to TASM, assembled it "B> and loaded it onto the boot sector of a floppy which already had a "B> stub loaded onto sector 2 and everything worked just fine. JG> Hmm... That's strange. Maybe it's my disk. :) I might format it JG> for DOS and load it up. I might have a bad Sector 2 now. (eek!) It's fine, now. :) (wasn't either of the problems mentioned though) Now, it's THIS code that's a bad: org 0000h Start: Mov AX, 0EAAh ;Test with TTY. It's ok here. Mov BX, 0007h Int 010h Mov AX, CS Mov SS, AX Mov DS, AX Mov SP, 0FFF0h Mov AX, 0000h Mov ES, AX CLI Mov AX, Offset WRITESTR Mov ES:0084h, AL Mov ES:0085h, AH Mov AX, CS Mov ES:0086h, AL Mov ES:0087h, AH STI PUSHA Mov AX, 0EAAh ;Test again. It never makes it here, AFAIK. Mov BX, 0007h Int 010h POPA Mov SI, Offset Loaded Int 021h Mov AX, 0003h ;test. It never makes it here. Int 010h ALOOP: JMP SHORT ALOOP NOP WRITESTR: ;Interrupt Procedure. ;Works fine alone. :-/ PUSHA PUSHF Xor BX, BX ;Pre-Condition: Point SI to Offset String Mov AH, 09h ;Post-Condition: Most registers destroyed Mov CX, 01h L1: LodSB Cmp AL, 00h Je L4 Cmp AL, 01h ;Use 00 for stop byte and 01 for attrib Jne L2 ;change. :) LodSB ;Use 02 for CR/LF Mov BL, AL Jmp Short L1 L2: Cmp AL, 02h Jne L3 PushA Mov AH, 03h Int 010h Inc DH Mov DL, 0 Mov AH, 02h Int 010h PopA Jmp Short L1 L3: Int 010h PushA Mov AH, 03h Int 010h Inc DL Mov AH, 02h Int 010h PopA Jmp Short L1 POPF POPA L4: IRet Loaded DB 'Testing Interrupt 021h',00h ;note that I took ;the color codes out ;on purpose. :) Jon Gentil - jon.gentil@magi.station-1.com - [PGP KeyId:0x3EB376B5] [] Dammit! WORK! ARGH!!!!! --- FMail/386 1.22a+ * Origin: MagiGate MultiHub - Pekin, IL - FidoSpine Hub (1:232/211) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00014Date: 07/14/97 From: AUKE REITSMA Time: 09:43pm \/To: JON GENTIL (Read 1 times) Subj: protetion mode Hi Jon, On 13 Jul 97, 19:06, you wrote to Auke Reitsma PW>> The DPMI specs don't make protected mode. The 386 does. AR>> Correct! DPMI is just a standardized way to access it ... JG> Not if you don't have DOS. :) Of course. I said "a standardized way", and NOT "the standard way" ... There is a difference ;-) Greetings from _____ /_|__| Auke Reitsma, Delft, The Netherlands. / | \ -------------------------------------- --- GEcho 1.00 * Origin: Home by the C (Auke.Reitsma@net.hcc.nl) (2:281/400.20) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00015Date: 07/15/97 From: PETER LOUWEN Time: 05:12pm \/To: KURT WISMER (Read 1 times) Subj: Re: sex -=> Quoting Kurt Wismer to Gidon Lev <=- KW> but this is an assembly language echo whose main focus is the 80xxx KW> line of intel microcomputers.. Which, as we all know, IS sex. With knobs on. KW> i wonder if such ambiguities would be avoided if the the name were KW> changed to 80x86... They'd probably think (always assuming said capacity, of course) it was a math echo: after all, it does contain the multiplication symbol. Why not call it the AsmProg echo ? Peter ... It's starting to rain, .SQZ the animals into the .ARC! --- GEcho 1.11+ * Origin: Nouveau BBS: ++31-36-5302153/5302156 (X75) (2:283/502) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00016Date: 07/15/97 From: CAMERON CLARK Time: 05:00pm \/To: MERVYN BALDWIN (Read 1 times) Subj: Re: 03050000 instruction MB> *03 ea ADD reg32,Ed (ea=source and destination operands) MB> MB> *05 data32 ADD EAX,data32 MB> MB> The * means that what follows is: MB> "a 32-bit instruction that operates on 16-bit quantities when preceded MB> with the OPSIZ:instruction prefix. For real mode, V86mode, and MB> 286-compatible code segments, the behaviour is reversed; that is, the MB> instructions operate on 16-bit operands unless preceded with the MB> OPSIZ:prefix." I've since learned the difference. Depending on mode, the processor decodes by assumption. Like said above (real mode, virtual 86 mode) assumes 16 bit instructions. --- GEcho 1.00 * Origin: Digital OnLine Magazine! - (409)839-8237 (1:3811/350) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00017Date: 07/16/97 From: HERMAN SCHONFELD Time: 03:26pm \/To: MARC MELVIN (Read 1 times) Subj: Re: 640x480 VGA MM>Hello Herman Schonfeld, >MM>Hey everyone... I am a born QB/Pascal/C programmer... well, I have >MM>just got into ASM, almost by accident, actually... when I was MM>messing >MM>with Pascal, I started seeing programs with ASM built-in... well, >MM>anyway, I need help with 640x480 mode. I have messed with 320x200 >MM>and understand it perfectly... I found that on my programs that >MM>wrote a tiny bit of info to the screen at a time was okay if I just >MM>put the information directly into $A000... well, now I can't seem to >MM>do that with 640x480, and it seems as though I have to use this 30 >MM>line code to just draw a pixel... well, I would appreciate it if >MM>someone could help me out here... assigning $A000:0000 to 255 MM>doesn't >MM>work with 640x480... yipes... :) > >Thats because you can't just address the whole "640x480x8bit" memory MM>area using >your conventional offset resolution. > >In a SVGA mode the video access memory is segmented into 64kb MM>paragraphs and it >is only possible to resolve a physical offset in these paragraphs (also MM>refered >to as "banks"). > >ie, VBE mode 101h (640x480x8), you can have each bank holding 64K MM>(65536) >bytes. So the bank is computed as: > >short bank = (short)((640*y + x) >> 16); > >Once you resolve which bank your offset lies on, you must switch this MM>bank. > > (Source Snipped) > MM>Well, thanks man. I understand what you are saying and appreciate the MM>answer MM>so quickly. I did get the problem solved before reading your reply, MM>however, MM>and have since then created a unit for 320x200 and 640x480 mode for MM>CGA,EGA, MM>and VGA monitors. I have tested each one, and am happy to say it is MM>working MM>great. Also added mouse commands to it as a touch-up. Everything custom MM>made MM>without ripping... it feels good to have actually made it... What language was it in? btw, the code i posted followed the basic vesa interrupt standard, if you are after speedups you could probably get a faster working version without using the int10! ... How does Michael Jackson pick his nose? From a catalog! --- Ezycom V1.48g0 01fd016b * Origin: Fox's Lair BBS Bris Aus +61-7-38033908 V34+ Node 2 (3:640/238) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBK00018Date: 07/16/97 From: HERMAN SCHONFELD Time: 03:29pm \/To: GINNY BAAS (Rcvd) (Read 3 times) Subj: ORIGINS OF STRUCTURE HS>GB>The Origins of Structure GB>... HS>GB>know, the hard-core stuff, like fractal compression, a-life, GB>nueral HS>GB>nets, ect. The stuff that questions the true identity of 'order' GB>as HS>GB>know it. Complexity vs. simplicity, chaos vs. order. If anyone GB>is i HS>GB>this stuff, please reply. If you know of a message area that GB>would b HS>GB>more on-topic to this, please reply also. Thanks. HS>GB> "Nietchze is dead." -God HS>I used to do alot of that. Julia fractals, fractal mapping, even GB>fractal HS>compression which is pretty crap if you ask me. It's not a very nice GB>fie HS>work one would like to be in. HS>... Computers all wait at the same speed! GB>Actually, Windows 95 computers wait very slowly compared to others. GB>What is crap about fractal compression? Why is it not a nice field? To GB>complex? What is the general algorithm for fractal compression? I GB>myself haven't much experience in the field, I've mostly worked GB>independantly w/self-modifying-code & abstract data structures. GB>Although my SMC is rather casual. I don't know of any dedicated use for GB>it. GB> -Chaos is needed to sustain order. Fractal compression is crap because it is an extremely lossy-method to compress your image. You can't expect much of an image that is compressed into mere bits! (per unit that is). It is not a nice field because there is no support for it, the bug-list remains endless when you are dealing with complex-recursions and it takes too long to test out the programs. ... Condense soup, not books! --- Ezycom V1.48g0 01fd016b * Origin: Fox's Lair BBS Bris Aus +61-7-38033908 V34+ Node 2 (3:640/238) --------------- ** A related thread FOLLOWS this message. FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: EBM02281Date: 07/18/97 From: GINNY BAAS Time: 12:38am \/To: HERMAN SCHONFELD (Read 1 times) Subj: R: ORIGINS OF STRUCTURE HS>Fractal compression is crap because it is an extremely lossy-method to HS>compress your image. You can't expect much of an image that is compresse HS>into mere bits! (per unit that is). HS>It is not a nice field because there is no support for it, the bug-list HS>remains endless when you are dealing with complex-recursions and it take HS>long to test out the programs. HS>... Condense soup, not books! I see your point. Images that are fractally compressed to a reasonable depth don't seem excessively lossy. I've got a fractal image format demo. It's in french or somethin, but it's pretty impressive. the images are compressed 1:50. A big advantage w/fractal compression, is you can actually view it in a higher resolution than you recorded it in, w/out having it look blurred or blocky. I'm sure when it's stablized and thouroghly explored, fractal compression will be very usefull and impressive. I do see how it would be hard and frustrating to program something like that. I like challenges. Maybe I'm not ready for that kind of challenge, but it's only a matter of time. Thanks for your input. It has been and will be very usefull. -Connection is when two motions, once thought to be infinitely & mutually exclusive, meet in a single moment. (-James Douglass Morrison)