This reminds me of the good old homecomputer days, where a similar effect could be observed regularly - but back then it was completely a side effect and unintentional.
Back in the day memory was very limited. CPU was slow too, but I'd even say memory was the main limitation. So, programs, and games in particular, used every single byte of the RAM. This of course left the crackers, who wanted to add their intros to the games, with a problem.
The solution was to compress the game to make room for the intro. After decompression it would still fill the available RAM 100%, so where to put the decompressor? You'd put it and ran it in the video RAM, which wasn't needed during decompression. It would be overwritten when the game started, but then the decompressor wasn't needed anymore. The only side effect was that you literally could see the decompressor run on your screen.
The colorful stripes are more likely the decompression routine hammering dff180 (the background color) as a "busy signal" for the user. The Amiga has "chip RAM", which on many unexpanded machines is also the only type of RAM; there are no pre-reserved regions in chip ram; everything (code,data,framebuffers) can be anywhere the programmer wants.
I think OP is (probably?) referring to 8-bit C64 era technology, where framebuffers/video ram are at a fixed location in memory?
Love it! It reminds me of a utility on my old Amiga 1000 that allowed you to view the entire contents of RAM as a large scrollable bitmap.
If you ran a game such as Marble Madness, rebooted the machine, then started the viewer program, very frequently you'd find corrupted remnants of the game assets such as sprites and backdrops as you scrolled.
I was young and absolutely amazed by it. Unfortunately I can't remember the name, only that it came on a disk with 'The Alliance Anti-Virus Collection' hand-written on the label. It had many other cool utilities, some which hijacked the "Insert Workbench" screen to play chiptunes and display scrolling text
I wrote such a tool on A500 called "Aspro" with visual memory scanning so one could spot bitmaps and adjust step, save/load files, 68K disassembler and other things I can't remember. It could be invoked with hotkeys during games or demos. Too bad I lost it. Fun times.
Argh, I just tried googling "The Alliance Anti-Virus Collection" and got seriously wet-fished by the tip-of-tongue variant of https://xkcd.com/979/. Minor whiplash incoming :(
So, variations on that string eventually find three results:
- This HN thread (Google be fast)
- Someone describing the same disk using very similar terms and with from a similar location ⁽ʰᶦ ᶠʳᵒᵐ ˢʸᵈⁿᵉʸ ᵇᵗʷ⁾, which I'd be surprised (to say the least) to learn is not you: https://forum.amiga.org/index.php?topic=73527.15#msg838909
- ThIs InFuRiAtInG dEaD-eNd PoSt FrOm 2006 ("MoSt ReCeNt UsEr AcTiViTy SeP 2007"): https://eab.abime.net/showthread.php?p=1332424#td_post_28845... - the attachment (which Google indexed) contains... "Alliance Anti-Virus Collection v8.00 (19xx)(The Alliance).zip"... D: D: D': ... and the username "jjsmith" doesn't really turn up anywhere else...
- Further extrapolation finds (via the miracle of working OCR and then "where on earth is that in the actual magazine"): https://archive.org/details/Australian_Commodore_and_Amiga_R... - at the bottom of the leftmost column ("Killing the IRQ virus"): "To check for the IRQ Virus, use Jon Potter's program POPDIR in Mega-disc 10, or pick version 7.0 of the Alliance Anti-Virus Pack from Prime Artifax on (02) 817-0011." Wow, a 7-digit phone number. I only very very vaguely remember those.
So, why on earth post this given that it's a giant dead end?
Well, this is Amiga. Way I look at it, based on the data available, I think it's promisingly likely that repeated pokings at the woodwork over time may actually make something nice fall out, maybe even sooner rather than later. It's a small community nowadays, IIUC. So maybe keep knocking?
I wonder what would happen if you poked around on EAB.
> Someone describing the same disk using very similar terms and with from a similar location ⁽ʰᶦ ᶠʳᵒᵐ ˢʸᵈⁿᵉʸ ᵇᵗʷ⁾, which I'd be surprised (to say the least) to learn is not you: https://forum.amiga.org/index.php?topic=73527.15#msg838909
Christ, that's embarrassing, you've found me! Seems I'm stuck repeating the same thing every decade without even realizing it! Excellent sleuth work :-)
I'm tempted to try my luck messaging 'jjsmith' on the abime.net forums, and might just pull on the Prime Artifax route... Thanks for your help with this
This is totally awesome and hopefully "mainstream debuggers" will learn from this.
Here's another example how memory visualization is useful, this time in an 8-bit home computer emulator (where such things are very trivial to do in realtime, because the performance difference between an 80's home computer and a modern machine is so big).
You can see how a visual effect in a scene demo works by looking at the memory access "heat map":
I also found the "execution heatmap" very useful for debugging, this just "paints the map" where the instruction pointer is reading memory, with the current location extra highlighted. One can understand a lot of things about a given program by just watching execution jump around in memory (such as, where are the "hot loops" versus what is one-time code, what memory regions are code, and what are data, etc...
Stuff like this makes computing FUN. It helps to create the wonder and whimsy we all felt the first time we saw such things.
I wish there were more things like this out there that showed something at least SLIGHTLY useful versus the obligatory "matrix rain" everyone uses to show off their terminals on /unixporn
Sometime in the first half of the 1980s I had a TI99/4a, my first computer.
I started programming in BASIC and it was interesting but I felt I was missing a lot in my understanding of what was really going on.
At some point I found a program called "picoprocessor" that was along these lines, but vastly simpler of course. It created on the display an operator panel for a 4-bit computer, it had maybe 2 registers and only a few operations but it was enough to get the light bulb glowing in my head about how computers worked at the assembly language/machine code level.
Seeing the state changes visually on the "panel" as the program ran was so helpful to my understanding that I still remember the experience quite clearly some 40 years later.
My dad also commented about the computers in the lab where he worked, that had operator panels with toggle switches and LEDs. He could tell what loop the program was running by the pattern of lights on the panel.
Neat project. Reminds me of the concept of streaming a log file through some kind of tokenizer -> tone generator (probably doesn't work for really busy programs) so that you can listen to the program execution and pick out things like errors from jarring notes. Don't remember where I came across that concept though :(
You can listen to any file in Audacity with Import > Raw Data, where it assigns each byte in the file one "point" in the audio waveform (depending on which format you select).
Would be interesting to make it more human "readable" though by extracting out tokens and assigning tones to them. Did you mean that something like that exists already?
I heard someone on HN say that back in the day when computers were big and noisy you could tell from the sound whether or not your algorithm was working properly, had gotten in an infinite loop etc...
I know I've come across the concept before, but I don't know if it was an actual product/bit of software. I think the Audacity approach would just sound like static; though without trying it, that's just idle speculation.
For Glog formatted logs, you could probably just extract the first letter (E/I/V/etc) and play tones for those. For anything else.. well, I suppose the idea is not "make music" but "expose patterns", so if you can derive the patterns for the log entries, then you could assign tones to each pattern (instead of each token in the line).
> "Watching this program execute (c / ctrl-c) at adjustable speed (ctrl-t / alt-t) it becomes clearer that the process of printing an image is basically a pipeline that goes: IDCT → Y′CbCr to RGB → decimate → sharpen → block render. Thanks to Blinkenlights we can also see that the RGB conversion is going slower than it should, because code isn't benefiting from SSE register vectorization. Many other common issues concerning micro-optimization, such as register spillage, become super apparent as well."
Could anyone ELI5 how this information is obvious?
It is possible to guess that from symbol names (e.g. stbi__YCbCr_to_RGB_row function represents the second step) and currently running instructions (e.g. you don't see many SSE instructions during that step). But to be honest, Justine wrote the program in question (printimage) so that information should be obvious to its author ;-)
Interesting work, I'm wondering if it has any relation to a tool with the same name that is designed to automate Adobe InDesign workflows. Our company is in the publishing business and we use it heavily.
As a child, I remember telnetting into an instance of blinkenlights to watch a fairly faithful ASCII rendition of Star Wars Episode IV. I never really looked into what sort of software blinkenlights was. Very interesting!
If I recall correctly, the command was:
"Telnet towel.blinkenlights.nl"
I thought this was related to the LED art projects with Blinkenlights branding, and I’m glad I clicked anyway: great breakdown, a hands-on perspective (which I always appreciate), and a stellar tool. Makes me want to blinken all my regular tools.
Back in the day memory was very limited. CPU was slow too, but I'd even say memory was the main limitation. So, programs, and games in particular, used every single byte of the RAM. This of course left the crackers, who wanted to add their intros to the games, with a problem.
The solution was to compress the game to make room for the intro. After decompression it would still fill the available RAM 100%, so where to put the decompressor? You'd put it and ran it in the video RAM, which wasn't needed during decompression. It would be overwritten when the game started, but then the decompressor wasn't needed anymore. The only side effect was that you literally could see the decompressor run on your screen.