# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 13
# self = https://watcher.sour.is/conv/qu3w7ka
Okay, this is pretty cool. My 8086 toy OS running on my old Pentium from an actual floppy disk. 😍 I just love that sound and the *feeling* of using floppies. This brings back so many memories from my early DOS days.
The cp-unopt program copies a file and intentionally uses small unaligned reads/writes (hopefully triggers more bugs).
The I/O cache works “okay-ish”, I guess. When sha1 runs, it has to do a few reads for the first file and basically none for the second one. Both could have been served entirely from the cache, theoretically. (But even just having an I/O cache in the first place speeds up things dramatically.)
Notice how there’s an EA file. That’s a left-over from OS/2, because I copied some files to the floppy using OS/2. In other words, my FAT12 implementation survives OS/2 writing to it. 🥳 (But I guess it should show up as EA DATA.SF. My current code starts at the left and stops at the first space.)
https://movq.de/v/d4d50d3c74/los86-on-p133-from-floppy-small2.mp4
Okay, this is pretty cool. My 8086 toy OS running on my old Pentium from an actual floppy disk. 😍 I just love that sound and the *feeling* of using floppies. This brings back so many memories from my early DOS days.
The cp-unopt program copies a file and intentionally uses small unaligned reads/writes (hopefully triggers more bugs).
The I/O cache works “okay-ish”, I guess. When sha1 runs, it has to do a few reads for the first file and basically none for the second one. Both could have been served entirely from the cache, theoretically. (But even just having an I/O cache in the first place speeds up things dramatically.)
Notice how there’s an EA file. That’s a left-over from OS/2, because I copied some files to the floppy using OS/2. In other words, my FAT12 implementation survives OS/2 writing to it. 🥳 (But I guess it should show up as EA DATA.SF. My current code starts at the left and stops at the first space.)
https://movq.de/v/d4d50d3c74/los86-on-p133-from-floppy-small2.mp4
Okay, this is pretty cool. My 8086 toy OS running on my old Pentium from an actual floppy disk. 😍 I just love that sound and the *feeling* of using floppies. This brings back so many memories from my early DOS days.
The cp-unopt program copies a file and intentionally uses small unaligned reads/writes (hopefully triggers more bugs).
The I/O cache works “okay-ish”, I guess. When sha1 runs, it has to do a few reads for the first file and basically none for the second one. Both could have been served entirely from the cache, theoretically. (But even just having an I/O cache in the first place speeds up things dramatically.)
Notice how there’s an EA file. That’s a left-over from OS/2, because I copied some files to the floppy using OS/2. In other words, my FAT12 implementation survives OS/2 writing to it. 🥳 (But I guess it should show up as EA DATA.SF. My current code starts at the left and stops at the first space.)
https://movq.de/v/d4d50d3c74/los86-on-p133-from-floppy-small2.mp4
Okay, this is pretty cool. My 8086 toy OS running on my old Pentium from an actual floppy disk. 😍 I just love that sound and the *feeling* of using floppies. This brings back so many memories from my early DOS days.
The cp-unopt program copies a file and intentionally uses small unaligned reads/writes (hopefully triggers more bugs).
The I/O cache works “okay-ish”, I guess. When sha1 runs, it has to do a few reads for the first file and basically none for the second one. Both could have been served entirely from the cache, theoretically. (But even just having an I/O cache in the first place speeds up things dramatically.)
Notice how there’s an EA file. That’s a left-over from OS/2, because I copied some files to the floppy using OS/2. In other words, my FAT12 implementation survives OS/2 writing to it. 🥳 (But I guess it should show up as EA DATA.SF. My current code starts at the left and stops at the first space.)
https://movq.de/v/d4d50d3c74/los86-on-p133-from-floppy-small2.mp4
@movq the sound of the disk drive brought back so many memories! (second time I type this, first time the reply seemed to go through, just to find myself logged out 🤯).
@movq Holy moly! 😱 You've written all the userland tools for your Toy OS too right? 🤔
@movq Holy moly! 😱 You've written all the userland tools for your Toy OS too right? 🤔
@movq Wow, quite an elaborate editor you've programmed there!
@prologic Yes, it’s all written from scratch, *but* most of it is written in C (not Assembler) and having a C standard library available helps a lot. It’s not that different from writing a program for DOS, just the syscalls are different. 😅
@lyse Scrolling the viewport was the most annoying part. 🥴 The code also assumes that it is running on a “fast” PC. There are no “elaborate” data structures like a gap buffer. (But it does use dynamic arrays, which Wikipedia lists as a special case of a gap buffer. 🤔)
To display text on the screen, the editor writes directly to video memory (https://wiki.osdev.org/Printing_To_Screen). This is a blessing and much easier than fiddling with escape sequences. I wish you could do something like that on a Linux terminal.
@prologic Yes, it’s all written from scratch, *but* most of it is written in C (not Assembler) and having a C standard library available helps a lot. It’s not that different from writing a program for DOS, just the syscalls are different. 😅
@lyse Scrolling the viewport was the most annoying part. 🥴 The code also assumes that it is running on a “fast” PC. There are no “elaborate” data structures like a gap buffer. (But it does use dynamic arrays, which Wikipedia lists as a special case of a gap buffer. 🤔)
To display text on the screen, the editor writes directly to video memory (https://wiki.osdev.org/Printing_To_Screen). This is a blessing and much easier than fiddling with escape sequences. I wish you could do something like that on a Linux terminal.
@prologic Yes, it’s all written from scratch, *but* most of it is written in C (not Assembler) and having a C standard library available helps a lot. It’s not that different from writing a program for DOS, just the syscalls are different. 😅
@lyse Scrolling the viewport was the most annoying part. 🥴 The code also assumes that it is running on a “fast” PC. There are no “elaborate” data structures like a gap buffer. (But it does use dynamic arrays, which Wikipedia lists as a special case of a gap buffer. 🤔)
To display text on the screen, the editor writes directly to video memory (https://wiki.osdev.org/Printing_To_Screen). This is a blessing and much easier than fiddling with escape sequences. I wish you could do something like that on a Linux terminal.
@prologic Yes, it’s all written from scratch, *but* most of it is written in C (not Assembler) and having a C standard library available helps a lot. It’s not that different from writing a program for DOS, just the syscalls are different. 😅
@lyse Scrolling the viewport was the most annoying part. 🥴 The code also assumes that it is running on a “fast” PC. There are no “elaborate” data structures like a gap buffer. (But it does use dynamic arrays, which Wikipedia lists as a special case of a gap buffer. 🤔)
To display text on the screen, the editor writes directly to video memory (https://wiki.osdev.org/Printing_To_Screen). This is a blessing and much easier than fiddling with escape sequences. I wish you could do something like that on a Linux terminal.
@movq Implementing my own TUI rendering in the tt rewrite, I know what a headache this can be. :-)