3 ms·

Back in the day, one of IBM's early databases worked by storing memory into the graphics buffer, outside the field of view of the monitor, because writing direc

by shakna 2y ago

Back in the day, one of IBM's early databases worked by storing memory into the graphics buffer, outside the field of view of the monitor, because writing directly to that memory space was faster on the hardware than anywhere else. (My dad wrote it when working for National Mutual). Tricks like these, intentionally causing overflows, used to be the norm. You've got a tiny bit of hardware, which makes it easier to reason about overall behaviour (until the inevitable BSOD). You can generally tell when its safe to blow up your whole stack. And that kind of thing is fine to do.

bitwize 2y ago
The TI-99/4A came with 256 bytes of system RAM. Everything in TI BASIC had to be stored in video RAM -- program code, variables, etc. -- which was not directly accessible to the CPU and had to be accessed through register reads/writes to the video chip. This process was slow, and so TI BASIC was slow. The TMS9900 was a fast (for 1979) 16-bit CPU, however, and some fast routines could be tucked away in those 256 bytes of RAM to achieve some interesting effects (for example smooth horizontal scrolling in Parsec, on a machine with no scrolling registers).
- classichasclass 2y ago
  Though at least part of the slowness was TI's decision to write BASIC in GPL (an interpreted middle-level language, for those unfamiliar) instead of directly in 9900 assembly, which made it even worse.
  - bitwize 2y ago
    And another part was due to the fact that the CPU couldn't access video memory during scanout -- it went into a wait state -- so your program only actually ran during hblank and vblank!
  - shakna 2y ago
    Graphic Programming Language [0] for the curious. FMT Enter sub-interpreter HTEX 'Hello, world' Displays horizontal text FEND Exits sub-interpreter [0] http://unige.ch/medecine/nouspikel/ti99/gpl.htm http://unige.ch/medecine/nouspikel/ti99/gpl.htm
- vikingerik 2y ago
  And on the Atari 2600, the fastest way to write to consecutive video registers is to set the stack pointer to its address and do push instructions. You take advantage of getting the stack pointer decremented for free on each push. The stack pointer can be hijacked for this since the machine has no interrupts. The 2600 can also run self-modifying code in RAM, which I did: http://www.dos486.com/atari/ http://www.dos486.com/atari/
MortyWaves 2y ago
I’ve always wondered what your first paragraph would look like, if it was shifted into the actual visible address space. I’m imagining a bit like white noise static but with colour? Anyone tried it and had a screenshot?
- saagarjha 2y ago
  Kind of, ASCII isn't really random. You can give it a try yourself in your terminal: $ text="Back in the day, one of IBM's early databases worked by storing memory into the graphics buffer, outside the field of view of the monitor, because writing directly to that memory space was faster on the hardware than anywhere else. (My dad wrote it when working for National Mutual)." && printf "P6\n$((${#text} / 3)) 1\n255\n$text" > test.ppm The result is kind of dim because none of the characters are greater than 0x80. You can brighten it by changing the 255 to, say, 127. The resulting file should open in most image viewing programs, though somewhat amusingly while writing this I messed up the format accidentally found a denial-of-service in Apple's ImageIO NetPBM parser :P
- shakna 2y ago
  There's a lot of 0s for preallocated space. And all-0 bitmap is just white. So mostly like white snow, with pickles of random colours in short blocks here and there, for headers.
- weinzierl 2y ago
  The effect of seeing a program run in visible video RAM was actually pretty common on the C64. Memory was really tight and every byte was valuable. Also external memory was slow. Programs were often loaded in a compressed form and then uncompressed. Since the uncompressed version filled the available memory to the last byte it raised the question where to put the unpackers code. A natural choice was to run it from video ram, which would be overwritten when the game started and the unpacker was not needed anymore. As slow as the C64 was, you could clearly identify the unpackers loop counters. I have also heard the story that this trick was especially popular for pirated games. The crackers used to add their intros and they had to fit in somewhere into already filled to the brim memory. So they used compression to squeeze their intros in.

by shakna 2y ago

bitwize 2y ago

The TI-99/4A came with 256 bytes of system RAM. Everything in TI BASIC had to be stored in video RAM -- program code, variables, etc. -- which was not directly accessible to the CPU and had to be accessed through register reads/writes to the video chip. This process was slow, and so TI BASIC was slow. The TMS9900 was a fast (for 1979) 16-bit CPU, however, and some fast routines could be tucked away in those 256 bytes of RAM to achieve some interesting effects (for example smooth horizontal scrolling in Parsec, on a machine with no scrolling registers).

classichasclass 2y ago
Though at least part of the slowness was TI's decision to write BASIC in GPL (an interpreted middle-level language, for those unfamiliar) instead of directly in 9900 assembly, which made it even worse.
- bitwize 2y ago
  And another part was due to the fact that the CPU couldn't access video memory during scanout -- it went into a wait state -- so your program only actually ran during hblank and vblank!
- shakna 2y ago
  Graphic Programming Language [0] for the curious. FMT Enter sub-interpreter HTEX 'Hello, world' Displays horizontal text FEND Exits sub-interpreter [0] http://unige.ch/medecine/nouspikel/ti99/gpl.htm http://unige.ch/medecine/nouspikel/ti99/gpl.htm
vikingerik 2y ago
And on the Atari 2600, the fastest way to write to consecutive video registers is to set the stack pointer to its address and do push instructions. You take advantage of getting the stack pointer decremented for free on each push. The stack pointer can be hijacked for this since the machine has no interrupts. The 2600 can also run self-modifying code in RAM, which I did: http://www.dos486.com/atari/ http://www.dos486.com/atari/

MortyWaves 2y ago

I’ve always wondered what your first paragraph would look like, if it was shifted into the actual visible address space. I’m imagining a bit like white noise static but with colour? Anyone tried it and had a screenshot?

saagarjha 2y ago
Kind of, ASCII isn't really random. You can give it a try yourself in your terminal: $ text="Back in the day, one of IBM's early databases worked by storing memory into the graphics buffer, outside the field of view of the monitor, because writing directly to that memory space was faster on the hardware than anywhere else. (My dad wrote it when working for National Mutual)." && printf "P6\n$((${#text} / 3)) 1\n255\n$text" > test.ppm The result is kind of dim because none of the characters are greater than 0x80. You can brighten it by changing the 255 to, say, 127. The resulting file should open in most image viewing programs, though somewhat amusingly while writing this I messed up the format accidentally found a denial-of-service in Apple's ImageIO NetPBM parser :P
shakna 2y ago
There's a lot of 0s for preallocated space. And all-0 bitmap is just white. So mostly like white snow, with pickles of random colours in short blocks here and there, for headers.
weinzierl 2y ago
The effect of seeing a program run in visible video RAM was actually pretty common on the C64. Memory was really tight and every byte was valuable. Also external memory was slow. Programs were often loaded in a compressed form and then uncompressed. Since the uncompressed version filled the available memory to the last byte it raised the question where to put the unpackers code. A natural choice was to run it from video ram, which would be overwritten when the game started and the unpacker was not needed anymore. As slow as the C64 was, you could clearly identify the unpackers loop counters. I have also heard the story that this trick was especially popular for pirated games. The crackers used to add their intros and they had to fit in somewhere into already filled to the brim memory. So they used compression to squeeze their intros in.