Hot answers tagged

224

Short explation The Windows NT 3.1 kernel is incompatible with enhanced 486 processors. Specifically, it is incompatible with 486 processors providing the CPUID instructions. Kernel debugging works fine with the 486DX-33 that was originally installed in the machine, and with the older non-enhanced core in a write-through Am486DX4-NV8T without SMM. If your ...


83

I am unsure about what made it so crash prone To start with, it wasn't. Windows ME was not much different from 98SE and on its own as stable as its predecessor. The only plausible thing I could read about it was that it was forked from Windows 95 instead of Windows 98 but how could that be a possibility as it doesn't really make much sense in the end? ...


53

Coding in assembly is brutal. Rogue pointers Assembly languages rely even more on pointers (through address registers) so you can't even rely on the compiler or static analyzing tools to warn you about such memory corruptions / buffer overruns as opposed to C. For instance in C, a good compiler may issue a warning there: char x[10]; x[20] = 'c'; That's ...


39

The problem is simple. At initialisation, Nibbles measures the time it takes to perform 1000 empty iterations of a FOR loop with a DOUBLE counter in order to determine how many such iterations are required to produce a ½ ms delay. Back when this code was written, CPUs were pretty slow (and FPUs even more so, if they were available at all), so it was ...


36

DOSBox, with the default CPU speed of 3000 cycles on this Linux box, runs nibbles.bas without problems.


24

I spent most of my career writing assembler, solo, small teams and large teams (Cray, SGI, Sun, Oracle). I worked on embedded systems, OS, VMs, and bootstrap loaders. Memory corruption was seldom if ever a problem. We hired sharp people, and the ones that failed were managed into different jobs more appropriate to their skills. We also tested fanatically - ...


23

I cannot speak about Pokémon in particular, but as a programmer for ~30 years, I'll answer thus: either laziness, incorrect assumption, or surprise. Laziness After an operation that overflows, you need to write extra code to check for the overflow, and then decide what to do about it. That's extra time, and extra work. Incorrect assumption (Often ...


22

Overflow doesn't mean what you think. That flag exposes the internal ALU carry from bit 6 -> bit 7. It's needed when you are handling the most significant byte of a 2-complement number, because you can't use the carry for that purpose here: it's jumbled by the MSB sign bit. When you don't add or subtract 2-complement numbers (MSB isn't meant as sign bit but ...


19

Simple idiotic errors abound in assembly, no matter how careful you are. It turns out that even stupid compilers for poorly-defined high level languages (like C) constrain a huge range of possible errors as semantically or syntactically invalid. A mistake with a single extra or forgotten keystroke is far more likely to refuse to compile than it is to ...


16

Software can identify those early steppings on the 386 by checking whether the XBTS and/or IBTS instruction can be executed, since these instructions were dropped in later chip revisions. Software must, however, first check whether the CPU is really an 80386 and not 486, because the some early steppings of the 486 temporarily re-used the opcodes of these two ...


14

I wrote the original garbage collector for MDL, a Lisp like language, back in 1971-72. It was quite a challenge for me back then. It was written in MIDAS, an assembler for the PDP-10 running ITS. Avoiding memory corruption was the name of the game in that project. The entire team had dread of a successful demo crashing and burning when the garbage ...


14

I posted this question because I had those thoughts, and then spent ages going through multiple dead ends until I finally found it (my Google-fu is on the fritz). So that I don't have to go through that again... According to an article by Marty Goodman in the July 1983 issue of Hot CoCo: The Head-Banger Bug You may have noticed that just after power up or ...


14

The ISO 7185 Pascal standard, section 6.4.3.5 "File-types", says (my emphasis): There shall be a file-type that is denoted by the required structured-type-identifier text. The structure of the type denoted by text shall define an additional sequence-type whose values shall be designated lines. A line shall be a sequence cs ~S(end-of-line), where ...


13

I think your premise is wrong. Firstly "overflow" in most cases doesn't mean pure arithmetic overflow, it means overflow of some other limit, checking said limits would require more than a single extra instruction. Secondly in many of the glitches involving overflow the overflow is a secondary part of the glitch. Using a rare candy on a level 255 pokemon ...


10

In the Pentium® II Processor Specification Update Release Date: October 1998 errata for the Intel documentation, the entry for A62 states: Plans - Errata NoFix - SYSENTER/SYSEXIT instructions can implicitly load “null segment selector” to SS and CS registers SYSENTER would set wrong selectors, but that was okay, because you were still in kernel memory, but ...


8

Electronic Gaming Monthly no. 124 from 1999 notes that the original Japanese Pokemon games had a long, difficult development process. The source code was so bad that when it came to doing the western versions the original Pokemon Red game was recreated using the newer Pokemon Green code, but even that was not an easy task. When you have poor quality source ...


7

Well, there's a fifth one: A sequence issue not really considered relevant when first published. The underlaying issue is that sprites are not moved during scrolling the background, prior to (re)drawing the screen. While this is rather obvious with large sharp screens, it will be perceived less of an issue on original Game Boy hardware due the small screen ...


7

Memory corruption bugs have always been a common problem in large C programs [...] But there was a time when large programs, including operating systems, were written in assembly, not C. You're aware that there are other languages that were quite common already early on? Like COBOL, FORTRAN or PL/1? Was memory corruption bugs a common problem in large ...


6

I have written OS mods in assembly on CDC G-21, Univac 1108, DECSystem-10, DECSystem-20, all 36 bit systems, plus 2 IBM 1401 assemblers. "Memory corruption" existed, mostly as an entry on a "Things Not To Do" list. On a Univac 1108 I found a hardware error where the first half-word fetch (the interrupt handler address) after a hardware ...


5

You are comparing apples and pears. High level languages were invented because programs reached a size which was unmanageable with assembler. Example: "V1 had 4,501 lines of assembly code for its kernel, initialisation and shell. Of those, 3,976 account for the kernel, and 374 for the shell." (From this answer.) The. V1. Shell. Had. 347. Lines. Of. ...


4

Lacking meaningful research avenues, I started surveying YouTube videos, and I think I managed to mine some insights even from that scant evidence. Here is what I found out: The issue is apparently just barely visible, if at all, on the original Game Boy; it probably cannot be noticed on a real handheld unless one is specifically looking for it, as LCD ...


4

I don't think memory corruption is generally more of a problem in assembly language than in any other language which uses unchecked array-subscripting operations, when comparing programs that perform similar tasks. While writing correct assembly code may require attention to details beyond those that would be relevant in a language like C, some aspects of ...


4

My experience with ME was on a new build I made (1 GHz!) and I found it be the best build yet of Windows... However, I think I know what was wrong with it for others' uses. The memory handling was seriously flawed. I ran a little 'extra' called RAM something, and I could have it free up memory before running anything 'intensive' - or at any time really - as ...


3

For the cracked version the problem was identified long ago: I have heard that it is only the cracked version of Karateka which has a problem. The problem is that on every disk access, Karateka takes a copy of the ROM from the Disk II controller card and patches it. It then uses the patched copy to do the disk I/O. The resulting code crashes ...


3

As mentioned by Justin Time, WDM and VXD drivers had a tendency to conflict. This introduced a fairly strong "whether you remember WinME as great or garbage depends on the hardware you ran it on" element to people's recollections of it. I didn't use it myself but the impression I got from people who did was that the rule of thumb was "If you'...


3

Assembler requires more intimate knowledge of the hardware you're using than other languages like C or Java. The truth is, though, assembler has been in use in almost everything from the first computerized cars, early video game systems up through the 1990's, up to the Internet-of-Things devices we use today. While C offered type safety, it still didn't ...


2

It can be tested by performing various multiplication operations and verifying the result. List of such code that performs ten tests with various memory and register based operands is available for example at pcjs.org, but as others have already pointed out, the problem may only manifest under certain conditions and can depend on e.g. CPU supply voltage, so ...


2

I did a few years of assembler programming, followed by decades of C. Assembler programs did not seem to have more bad pointer bugs than C, but a significant reason for that was that assembler programming is comparatively slow work. The teams I was in wanted to test their work every time they'd written an increment of functionality, which was typically every ...


2

It was a very common problem. IBM's FORTRAN compiler for the 1130 had quite a few: the ones I remember involved cases of incorrect syntax that weren't detected. Moving to machine-near higher level languages didn't obviously help: early Multics systems written in PL/I crashed frequently. I think that programming culture and technique had more to do with ...


1

On the modern CPU the FOR loop executes so quickly that the difference in the TIMER before and after is zero. Hence the line: speed = speed * .5 / (stopTime# - startTime#) gives a divide by zero error, because (stopTime# - startTime#) equals zero. The simplest solution would simply be to set the speed variable manually, until you find something that gives a ...


Only top voted, non community-wiki answers of a minimum length are eligible