My favorite anecdote relating to Firebird/Interbase (its original name) is that it is supposed to be renowned for its durability (i.e. resistance to corruption) and fast start times.
Because of this, they used it within the internal systems of the M-1 Abrahms tank.
Apparently when the main gun is fired, it gives off such a powerful energy impulse, that there is (at least was) a tendency for it to crash the internal systems.
So, they adopted Interbase because of its ability to work well in an environment where hard computer crashes are more a norm than an outlier.
There's a legend (perhaps me misremembering, or simply making it up, thus making it a legend rather than an anecdote) that Chuck Moore did something like this that eventually ended up as ColorForth.
The story is simply that he started with MS-DOS, some floppy disks, and DEBUG. Starting there, he bootstrapped to being able to boot something from a floppy, and just pushed on from there.
Its an interesting development idea of simply molding a RAM image to your liking with little more than POKE, PEEK, BLOCKMOVE and READ/WRITE the RAM image. The assembler is a tasty treat, but hardly necessary, and perhaps not as helpful as one would like since while the mnemonics are nice, its the labels that give an assembler its real power.
I always visualized putting subroutines at 16 byte boundaries, if only to make the addresses stand out a bit in the hex noise, but also to give a little wiggle room to make changes without stomping on other code. Thinking how cautious one has to be, particularly on an MS-DOS machine, you have to be knowing one misstep, one stuck loop, and you're reloading from disk again. "Save early, save often". Plus that one point when you're in the phase of writing the floppy bootsector and you now, suddenly have a larger step to go from bootable primitive Forth kernel, to one that can self-host, even if it's just defining code words as blocks of hex numbers, forgoing an actual assembler early on. But, ideally, by that point, you're already comfortable with block of hex code, however now you don't have the benefit of a disassembler outside of the carbon based meat computer stuck in your head.
I think after a day or two of full immersion in this environment, disassembling hex code would be mostly straightforward. Woz is said to have 6502 binary memorized. It doesn't really take much, you don't need to memorize it all. Knowing a dozen instructions can take you a long way.
Anyway, always been an interesting thought exercise. Nice to see something similar. I like the primitive base Forth used.
In my very modest experience, I once wrote a system that I could boot from a floppy, edit, then recompile. For this I needed to make an assembler, or rather I was willing to meet the challenge of writing an assembler for the 8086, which was notoriously difficult (not really for the subset I needed, which did not include the complex addressing modes for one thing).
When it came to writing the changes on the floppy I was very scared to trash my hard disk (writing to HD or floppy was just a value in a register when you use the BIOS API), but fortunately I found an old Toshiba laptop that had an external power-on switch for the hard disk! That thing was running at 10 Mhz in "turbo" mode!
Bottom line: I spent a lot of times reading the ISA specs, write the assembler in Forth, and compare/check its output with an actual assembler. It would have been more efficient to enter directly the instructions in hex, I think, except maybe for the boot sector.
I think after a day or two of full immersion in this environment, disassembling hex code would be mostly straightforward. Woz is said to have 6502 binary memorized. It doesn't really take much, you don't need to memorize it all. Knowing a dozen instructions can take you a long way.
It does. I am certainly no Woz, but I used to program a KIM-1 by hand assembling with pencil and paper from a programming card, then keying hex codes into its onboard keypad. After a few days you don't need to look at the card much. It's really quite practical - it's actually easier than dealing with editor and assembler tools. After fifty years, I still recall that A5 encodes LDA.
I am teaching myself Arm assembly for the M-series of processors, M-4 for now. I have been playing and using J (jsoftware.com) since 2010, and I have to say that as much as the higher abstracted languages and programs become, I still love the atoms and terseness of array languages and writing close to the metal. I started with Factor, gforth, and retro years ago. Something magical happens when you immerse yourself in it. Right now, I am working with KlongPy, which using the PyTorch backend along with the Klong language is amazing. I used to write assembly code for my Vic-20 back in the day and then bought the VIC FORTH cartridge for like $30 in 1982. I programmed my 1977 PET 2001 in the Commodore Basic 1.0 it came with, but there was a sys instruction for machine code! I used to write my code on an index card before typing it in and saving to the cassette recorder. Magazines had code to hand type in, so my coding was learned with reading and writing it first. I accidentally bought a hardcover book on PDP-11 programming and read the whole book before I bought my PET in 1977. Machine language.
I miss the early days of computing before the internet or Genie Online, but Echo in NYC was a blast - thanks, Stacy!!
Agreed, though I would say that 6502 is a lot more straightforward to memorize than x86. A lot fewer addressing modes and every instruction is always just a byte, possibly followed by immediate data. The 6502 was a little gem.
If you read the colorforth source (there’s only around 1000 instructions of assembly, it’s not a long read), there’s a real sense that much of the design (pretokenization, color tags, etc) are built around the punchline of a single (with rep prefix) instruction being used to linear-search the dictionary — going to trivial hardware-supported data structures here constrains the implementation a bunch, but there’s magic in self-imposed constraints.
there's a similar story by kragen on .. hmm HN or maybe SO where he describes a bootstrapping from a micro hand crafted asm monitor to forth to more and higher level languages. "stuck-in-a-basement" kindof challenge.
I can’t speak to getting an LLM to talk to a CL listener, simply because I don’t know the mechanics of hooking it up. But being as they can talk to most anything else, I see no reason why it can’t.
What they can certainly do is iterate with a listener with you acting as a crude cut and paste proxy. It will happily give you forms to shove into a REPL and process the results of them. I’ve done it, in CL. I’ve seen it work. It made some very interesting requests.
I’ve seen the LLM iterate, for example, with source code by running it, adding logging, running it again, processing the new log messages, and cycling through that, unassisted, until it found its own “aha” and fixed a problem.
What difference does it make whether it’s talking to a shell or a CL listener? It’s not like it cares. Again, the mechanics of hooking up an LLM to a listener directly, I don’t know. I haven’t dabbled enough in that space to matter. But that’s a me problem, not an LLM problem.
I live in rock and rolling California, and we love our stick framed houses. They’re very resilient to the tremblors that plague us.
Yea, if we’re hit hard enough, the stucco may or drywall may crack, but, big picture, those are cheap cosmetic fixes compared to anything more structural being damaged.
Back during the Northridge quake, my friend was buying a second floor condo in Santa Monica (which was hit pretty hard). It resulted in several drywall cracks, but nothing worse than that. Even better, the closing day was scheduled for the day after the quake.
My (large) bank is yanking their safety deposit boxes out. They let subscribers know that they have, like, 1 or 2 years to go. They're doing it across the branches. They basically feel it's not worth the liability any more, and the way it was presented to me, it's not just them, but other banks are also doing (or at least considering) this.
Things we take for granted. When my father passed, I was digging stuff out of SDBs that he had for decades.
“Simply Scheme” was a foundational work on my path to a parenthesta.
Simply, for me it was a Rosetta Stone that put Lisp/Scheme concepts into ones that I already understood. Simple things like using “function” instead of “lambda” were Aha moments that lead to breakthroughs.
I use to muse if I put the money I spent on computer gear back in the day instead into woodworking tools, I'd not only have a bigger, better shop than Norm Abrahm, all of the tools would probably still work.
I lose my Time Machine drive, like, every year or two.
Sometimes, Time Machine just goes stupid and I have to wipe the drive and start over. All of my efforts in the past to copy or repair or do anything to a Time Machine drive has ended in folly, so when it starts acting up, I just wipe it and start anew.
Other times, it's the drive itself, and I swap it out.
99% of the time, it Just Works. Wiping the drive for me is more annoying than catastrophic (99.9999% of the time I don't care about my 18 month old data). It's mostly for local catastrophic fat fingering on my part, and to make sure I have a solid back up after I do a OS update. I have BackBlaze for "Why is there 5 feet mud in my burning house" scenarios.
Outside of that, I've always been able to recover from it.
My wife has a SSD drive she plugs into her laptop for TM backup. That machine at most makes laps around the house, so its not that big of a deal for her.
My understanding is that routing through residential IPs is a part of the business of some VPN providers. I don't know how above board they are on this (as in notifying customers that this may happen, however buried in the usage agreement, or even allowing them to opt out).
But, my main point, is that the whole business is "on the up and up" vs some dark botnet.
> While operators of residential proxies often extol the privacy and freedom of expression benefits of residential proxies, Google Threat Intelligence Group’s (GTIG) research shows that these proxies are overwhelmingly misused by bad actors
Mullvad seems to be one of those VPN providers. [1] Though I very much doubt they would sneakily make end-users devices exit nodes. Though, as a historical side note, let's not forget Skype used to make users computers act as a relay as well during its more decentralized days.
Starting with Assembly is simply a bad idea because the tooling is terrible, and the learning curve of the tooling is steep. Filled with arcane codes and abbreviations and workflow right out the gate.
Programming concepts are pretty much universal. Being distanced from computer architecture is not a limitation for novice programmers, Python et al succeeds for a reason.
If you're determined to start with assembly, then I hope you can find someone to help you get started with all the machinations necessary to get from LDA #0 to A9 00 with as little drama as possible. Someone to show you how to use the assembler, what the directives mean, the linker, a symbolic debugger (if you're lucky). Someone to provide you with a .DUMPREG "START OF SORT" and .DUMPMEM BUFF $80 "AFTER INPUT" macros that you can liberally scatter throughout your code so you actually progress and get some insight into what the heck you code is doing. Perhaps some way to stop your programs that doesn't include hitting the reset button on the machine.
I mention that because, again, the tooling is terrible. All of the is easier said than done. None of the assembly books address this, none of the assembly program reference guides do either. Assembly is VERY black box. It's a large step up to even get started.
It's much easier to "learn programming" first at a higher level, where you can quickly progress and succeed, before turning into the dark hole that is assembly, particularly on older machines.
At least on a KIM-1 you can hit the STOP button and cursor through memory (being conscious that the memory architecture of the KIM is quite funky), something that simple is quite difficult on an Apple ][.
In general, Assembly for a simple well documented CPU is fairly close to most familiar calculator operations, and is demonstrated as a 1 to 1 relationship in the binary firmware. If folks drop on abstractions like Scratch/Basic/Python/Java the students will develop a random notion of what Register/Stack/Heap even means.
I would recommend looking at a few random samples of Ben's build series, as he covers most first year subjects in subtle efficient ways.
Soldering kit PCB or Emulators are insufficient to demonstrate a physical bus wire harness, clock timing, and memory layout. Best of luck =3
Because of this, they used it within the internal systems of the M-1 Abrahms tank.
Apparently when the main gun is fired, it gives off such a powerful energy impulse, that there is (at least was) a tendency for it to crash the internal systems.
So, they adopted Interbase because of its ability to work well in an environment where hard computer crashes are more a norm than an outlier.
reply