boomlinde

A typewriter prints the letters exactly as you press the corresponding keys. It doesn't invent bullshit on its own as you do. I can't take the comparison to a typwriter as a serious, good faith argument. If you have any worthwhile ideas, please bring those up instead of poorly considered variations on the usual "it's just a tool" platitudes. The comparison is invalid. You are thoughtless for bringing it up.

In jazz, you also typically do your best to play in time together, but for long sections timing is often made an open-ended problem where the rhythm section doesn't interfere too much with stylistic timing variations that IMO often separate the simply skillful solo from the deeply felt one. The idea of an accent in modern popular music seems largely have practically narrowed to dynamic articulation, but agogic accents are a thing that skilled musicians can perform in a band setting without it seeming like an "imperfection".

I started using the emdash after learning of the compose key feature of X11. Not tuning the emdash dial to 11 or anything, but occasionally. Now I avoid it to spare myself the indignity of someone confusing me for a chatbot. In general I prefer a more vulgar style of writing as a direct response to those chatbot tics.

Of course, that now distinct LLM style was kind of a thing before, too, but if you weren't writing some bullshit on SEO on Medium or congratulating yourself for your achievements on LinkedIn, using elements of that style wasn't such a source of confusion. Now the chatbots will frame everything as though it's an insight on B2B sales strategies that struck them when they tripped on a dog leash while jogging to work.

Perfect for some poolside work.

First, there is no frame buffer (there could be no such thing in that memory space), but there are effectively line buffers for the different sprite types and background. These are not in the 128 bytes of general purpose RAM but memory mapped to the display controller.

Second, it maintains the patterns in these buffers until you change them and will repeat them on the next line unless you do anything to change them. This makes it easy to perform partial update, e.g. only update the background every 8 lines and only update sprite graphics on odd lines or whatever you need to do to save time.

Third, the video controller can be instructed (via a memory mapped register) to halt the CPU until the next horizontal "blanking" interval. This makes synchronizing to the beam position between lines much easier.

Fourth, there are no interrupts (except NMI, only triggered manually with the brk instruction) so timing is easily predictable.

Fifth, there is a hardware timer which makes it easier to keep track of your budget while in the vertical blanking portion of the screen, where you probably want to handle most if not all of your game logic. That way the game logic doesn't need to be strictly timed in the same way the screen is.

I made a game for it (https://text.garden/jupitersumo.html) expecting it to be difficult, but found that the simplicity and predictable timing made it surprisingly easy. On the C64 for example you will often find yourself wanting to synchronize to the beginning of a line or even every line for one reason or another, but doing that while dealing with the complexities of its timing is a whole science unto itself. For the main game screen I ended up using some 16 bytes of state in RAM to represent the stuff I need to keep track of while "racing the beam". The code that handles the display is maybe 150 instructions long and lives in the game ROM. The source code is linked from the page if you're interested in how it works.

Of course, in terms of what it displays, my game is very simple, only showing a background and the player sprites. There are much more complex display routines ("kernels") in the VCS game library. An interesting example is Pitfall II, which is very impressive considering the platform, but uses a coprocessor on the cartridge itself (called the DPC) to help sequence line register updates. From memory, I think it lets you enqueue data in advance, and during the display routine the CPU can just read a single register to get the next byte from a queue.

A description (from https://www.raio.com.tw/en/RA8889.html):

> RA8889 is a low power TFT controller with powerful display functions and build-in internal SDRAM memory. In order to quickly refresh the screen content with the display memory, RA8889 provides not only parallel, 8080/6800 8/16-bit MCU interface, but also 3/4 wire SPI and IIC serial interface. Plenty powerful functions are provides from RA8889, such as multiple display buffers, Picture-in-Picture, transparency control, display with rotation & mirror, and build-in JPEG and AVI decoder.

The article was somewhat difficult to read due to the limited area devoted to the body of the text. I had to scroll on several pages despite the short chapters.

It provides the tools necessary to implement a simpler workflow.

Fun anecdote: I remember seeing a screenshot of a website selling a scented candle called "basic bitch", which was machine translated so that the idiomatic meaning was entirely lost. So the translation ended up meaning something like "foundational female dog".

I don't know about expressing ties. If there really is a tie and the client is just as happy to receive either language of equal Q, then it doesn't matter to the client that one is consistently preferred over another. Perhaps it could matter to the server if e.g. the client indicated that "en" and "zh" are tied, but the "en" content can be served in fewer bytes than it can serve the "zh" content, but it seems like such a niche use case.

edit: RFC 9110 offers an explanation: "Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon. For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also listing them in order of decreasing quality."

I have a hard time figuring out why quality values are even included for Accept-Language. They either have one of the preferred values, or they don't.

But then they have in fact not abandoned society.

> As such it's an empty pursuit.

What do you believe that they are pursuing that you think is empty?

I wondered what the thought process was at Acorn when they decided on the opposite. It looks like they did this on their 8-bit micros as well. I found this explanation: https://retrocomputing.stackexchange.com/questions/29929/why...

I've only looked briefly but it seems there is a snippet of code in the ASCII output routine that expands just CR to LF+CR which is shorter when the bytes are output in that order. If they did CR first and fell through to the output routine for LF it would clobber the A register and you'd need additional code to restore it after outputting it with OSWRCH, which would also preven the fallthrough. So it saves five bytes three bytes of ROM :)

Still leaves out why they didn't expand LF to CR+LF, but I suppose the specific order was a non-consideration at the time.

It ultimately also doesn't really present these files correctly. The last LF is still presented as an empty line at the end of the document. Someone reported that, and they added the option to hide the "trailing newline" to address it, but it effectively only stops displaying it, while you can still navigate to it. I ended up reporting simply that it doesn't handle POSIX text files correctly, describing the problem and the issues with the current attempts at solutions, but it was classified as a feature request and eventually closed due to losing some kind of popularity contest they have for these.

Seemed like such a basic function for a text editor and a dysfunctional response to my report, so quickly gave up on using it.

For one, there are a few different ways to terminate lines. All major operating systems now tend to use just \n, but I have older files that use \r\n (Microsoft), \r (Macintosh) or \n\r (RiscOS).

There are also different opinions on how text files end in different operating systems. In POSIX, all lines are terminated by \n, even the last one. Microsoft software still tends to insist that the last line of a file is special case that doesn't need to be terminated even now that they have otherwise adopted POSIX style line endings. In Microsoft's view, it seems that the line ending sequence separates lines rather than terminate them. Files created according to this view don't play well with tools like cat(1) if your intent is to concatenate the lines of two files, but it seems other Unix clone tools have adapted to the possibility that the last line isn't terminated properly.

Finally there's the encoding problem. I don't know of a good tool that determines the original encoding based on heuristics and re-encodes to UTF-8 but if someone does I'd love to know. If I know that the input language is English for example it shouldn't be too hard to determine what encoding the funny byte used in contractions or the funny bytes used in quotes belong to. Still, in English most of the files that use 8-bit encodings remain quite readable if you just box out the invalid bytes.