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 ...
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?
Coding in assembly is brutal.
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:
x = 'c';
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 ...
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 - ...
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.
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.
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 ...
This is a consequence of a buggy overflow check.
Internally, MS-DOS uses logical block addressing to access file systems. Since version 4.0, MS-DOS uses 32 bits for sector addresses in order to support disks larger than 32 MiB (i.e. than 65536 sectors). To ensure all sectors are addressable with 32 bits, MS-DOS tries to compute the address of the last ...
It’s good ol’ buffer overflow.
I diagnosed this in VICE. It turns out that supercat’s hunch that this is caused by clobbering a register of the CIA chip is mostly correct (they only got the register wrong), though the cause is relatively easily discovered even without that hint.
Since the primary symptom is the keyboard becoming unresponsive, I decided to ...
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 ...
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 ...
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 ...
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 ...
The ISO 7185 Pascal standard, section 126.96.36.199 "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 ...
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 ...
If the compilers you have were based on the P-series, then I believe that there was indeed a bug.
In the P-series compilers after P2, the destination of an assignment is determined by a routine named selector, which branches on the klass field of fcp, a variable that holds information about a relevant identifier. When the klass is func, i.e., when the ...
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
SYSENTER would set wrong selectors, but that was okay, because you were still in kernel memory, but ...
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 ...
That fact is explicitly mentioned in the (Russian) book Ошибки-ловушки при программировании на фортране, 1987 (Errors and pitfalls in FORTRAN programming), page 88.
One of the puzzles was to make the sequence of operators
1 FORMAT(' J = ',I1)
The provided solution was
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 ...
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 ...
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 ...
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. ...
In the 1990s, I worked for a UK company (Polyhedron Software) that produced a suite of code analysis and refactoring tools for Fortran, marketed as PlusFort.
The GXCHK module performed static analysis of Fortran code to look for common errors, including:
Subprogram argument mismatch or misuse (e.g. constant actual argument
is illegally modified by ...
I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.
Check out this example at https://godbolt.org/z/GKadP9rov (feel free to ...
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 ...
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'...
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 ...
Using an emulated IBM 1130 running DM2, I can confirm Leo B.'s example. It took a little modification to run on the 1130:
*LIST SOURCE PROGRAM
*ONE WORD INTEGERS
K = 0
*STORE WS UA ZERO
*ONE WORD INTEGERS
J = 1