--------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00000Date: 01/06/98 From: DARRYL GREGORASH Time: 03:57pm \/To: ALL (Read 1 times) Subj: What? Did I miss something? I'm not ignoring anyone, I'm just way too caught up in the current election for zone 1 ZEC.. as Glenn McNabb can attest to :) --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00001Date: 01/06/98 From: DARRYL GREGORASH Time: 03:58pm \/To: NATHAN MALYON (Read 1 times) Subj: pure Hex Programming Replying to a message of Nathan Malyon to Darryl Gregorash: DG>> It does exist, and I think it might still be in production DG>> today. It never made NM> it wouldn't be, intel wont build anything slower than an NM> pentium 166 now and most other companies want to cut down NM> on losses by selling high rnge fast mass-produced chips What processor were we talking about here? If it is the 80186, then it is still listed, I believe, in the "embedded controllers" sections on Intel's website. It was the last time I checked, then again the 486 was still listed at that time in the CPU section, but has since disappeared :) --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00002Date: 01/06/98 From: DARRYL GREGORASH Time: 04:04pm \/To: SCOTT MCNAY (Read 1 times) Subj: pure Hex Programming Replying to a message of Scott McNay to Glen McNabb: SM> On the 808x, PUSHA is interpreted as JMP $+2 (effectively a SM> NOP). On the V20/V30/80x8x chips, it's a PUSHA. That's because PUSHA/POPA aren't in the 808x instruction set, but are in the 8018x instruction set, and the V20/30 are modelled after the 8018x. Not a bug, but a distinguishing characteristic perhaps? --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00003Date: 01/06/98 From: DARRYL GREGORASH Time: 04:07pm \/To: MODERATOR (Read 1 times) Subj: 80XXX, eh? Replying to a message of Moderator to Thomas Habets: >> Maybe *someone* should think about doing *something* about >> the name of this area. Or is it just me who is sick of the >> XXX confucion? M> It gets bandied about quite often- the problem has always M> been maintaining links.... but with the low traffic these M> days.... hmm.. How about we start a new echo called 80X86 M> or something? Didn't we suggest the same thing about 5 years ago, and nothing came of it? --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00004Date: 01/06/98 From: DARRYL GREGORASH Time: 04:12pm \/To: GLEN MCNABB (Read 1 times) Subj: pure Hex Programming Replying to a message of Glen McNabb to Scott McNay: SM>> The 808x and 8018x have the PUSH SP bug, where the wrong SM>> value of SP is pushed. SM>> PUSH SP SM>> POP AX SM>> CMP AX,SP SM>> JNE Bug GM> Really... Seems to me the SP changes value in a push. Which GM> is what it's supposed to do. If would seem to me, to be GM> asking for a problem. All Intel processors starting with the 80286 place the PUSHed value on the stack before decrementing SP; that is common practice, but the 808x/8018x did it the other way around: decrement SP and then write the PUSHed value to the stack. In the above code fragment, the 808x will thus do this (assume top of stack, SP=0FFFFh at the beginning): PUSH SP 1) SP <- 0FFFDh 2) write value of SP to stack, ie. OFFFDh POP AX 1) AX <- 0FFFDh 2) SP <- 0FFFFh This code sequence *should* be functionally equivalent to MOV AX,SP, but on the 86/186, it is not. --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00005Date: 01/06/98 From: DARRYL GREGORASH Time: 04:24pm \/To: PETER MAGNUSSON (Read 1 times) Subj: pure Hex Programming Replying to a message of Peter Magnusson to Darryl Gregorash: DG>> Think for a moment what will happen if you execute POP CS.. DG>> the IP remains unchanged... PM> But, you mean they actually did have such an insruction? I doubt it; any POP to the CS should result in an illegal opcode. However, it is possible to achieve the same thing with a MOV CS, .. that should also be an illegal instruction, but I guess something got messed up somewhere :) --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00006Date: 01/06/98 From: DARRYL GREGORASH Time: 04:30pm \/To: PETER LOUWEN (Read 1 times) Subj: Coitus interruptus Replying to a message of Peter Louwen to Jeremy Stroud: PL> This echo is dedicated to the extremely boring and PL> completely erection-less topic of programming in assembly PL> language on microprocessors of the 80XXX family. Yawnsville PL> or wot ? What? You don't get an erection reading assembler code??? What is the world coming to? :) --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00007Date: 01/06/98 From: DARRYL GREGORASH Time: 04:34pm \/To: TOM TORFS (Read 1 times) Subj: getting pixel color... Replying to a message of Tom Torfs to Darryl Gregorash: RG>> ... get the color of a pixel in 1024x768 256 color mode.... DG>> INT 10 - VIDEO - READ GRAPHICS PIXEL TT> This BIOS function is horribly slow, and I'm not sure if it TT> will support these high-resolution modes. You're better off TT> with a library written specifically for this purpose. Any VESA compliant card should support that for the modes it supports, right? I don't know about getting the pixel value for anything higher than 256 colour modes, but it should be OK up to 256 colours. Are generic libraries available which are not completely hardware-dependent? If so, then I agree, that is the best way to go. --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00008Date: 01/06/98 From: DARRYL GREGORASH Time: 04:36pm \/To: CHRIS BERKHOUT (Read 1 times) Subj: Memory Allocation Replying to a message of Chris Berkhout to Darryl Gregorash: CB>> Well behaved programs will resize themselves CB>> I guess that with .EXE's there is some kind of compiler CB>> directive .... DG>> Linker directive actually; the code to resize allocated DG>> memory is placed in the .exe loader, which is written at DG>> link time. (As someone pointed out to me via netmail, I did mean "header" there, not "loader") CB> So the code for that is run after the .EXE is CB> started, rather than DOS doing it during loading based on CB> values from the header ? Exactly; DOS merely assigns all available memory in one block to any program it loads, and it is then up to the application to manage what it has been given. In this case, we wish to give up some of that memeory so we can request memory for a different purpose. In a .exe, you can achieve that with linker directives, in a .com you must write the code yourself. --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: F1B00009Date: 01/06/98 From: DARRYL GREGORASH Time: 04:51pm \/To: SCOTT MCNAY (Read 1 times) Subj: Device driver books? Replying to a message of Scott McNay to Alex Walker: SM> Two others that I have but which I've never read (they were SM> given to me about a year ago) are Writing DOS Device SM> Drivers in C and Writing MS-DOS Device Drivers. If you don't really want those books.... :) --- FleetStreet 1.21 NR * Origin: BIG BANG Burger Bar: Regina SK Canada (1:140/86)