Regression with the C64
tensorthings.com
tensorthings.com
I agree, with this, and the general sentiments in this blog post.
Yet I am one of those "Experts" out there who knows nodejs et al, and builds things with it. I recognise it's deep flaws, evade them as much as I am able and am always trying to find better ways of doing things - but this is the domain I work in, and using these tools and building blocks to some degree is quite difficult to completely avoid (and I say this as someone who has gone to quite some extremes in my attempts to do so).
My point is, even though the issue is a cultural one, not everyone caught up in a particular manifestation of these issues is blind to them - Please remember this the next time you judge a web dev, or foo dev, or someone from whatever area you perceive to be hopelessly flawed.
Gatekeeping at its finest.
Of course this is a neat exercise to do on a C64, but in no way does this give any reason to think we're doing something wrong by using more powerful computers to study vastly more data (using more complex algorithms - we are not just doing "the same thing" as in this demo). The gap between showing that you can fit a line to two points on old hardware and concluding that modern data science is one big heap of inefficiency is just too large.
Is anything actually stopping you writing it in baremetal x86 assembly if you wanted?
Oh, before someone comes up with "Just use UEFI". UEFI was made by the same people and is the same kind of pain in the ass.
But, people routinely code to this sort of specs (minus the transistors count): the lowest end of NXP SoC spec has 1-4K RAM and 8-32K ROM (though probably high 5 figures transistors count, possibly low 6).
Disclosure: Maintainer of emlearn project.
Reminds me of when everyone in the SV bubble was all excited about "graph theory" because Facebook was using it. But it's something that was being done in 16K BASIC back in the 1970's.
And it's just as stupid.
That said, going back to less powerful hardware is the right thing to do because we get longer lasting batteries:
https://shop.pimoroni.com/products/picosystem
Dual Arm Cortex M0+ running at up to 133Mhz with 264kB of SRAM, this is the equivalent to a modern C64 and it consumes 0.1W instead of 20W.
That said again, I'm targeting the Raspberry 4 for my upcoming 3D action MMO and that is 5W when maxxing the GPU and one CPU core.
It's a good way to keep your expectations in check as electricity prices rise indefinitely.
The only thing I'm 100% sure of is that people will soon not be able to afford to play on 200+W machines.
A friend of mine calls 8 bit computers "glorified calculators" and he's right. You could have tons of fun though.
You don't have to use Windows 10, there are better options. You have to waste tons of RAM for an IDE to keep fast useful indexes in-memory. You don't have to use Spring Boot, there are better options.
For example, the C64 Action Replay cartridge had a built-in monitor. Software machine code monitors and assemblers were also available.
If you download the binary and hex dump it, it's a PRG file which contains a 2-byte header ($0801, the load address), followed by a short basic program (816 SYS 2061) followed by the actual code at 2061 ($080d). The actual code starts with LDA $01 but the address is off by 2 bytes (due to the PRG header) so the JSR subroutines are off as well.
The BRK instruction, if I recall correctly from my 6502 days, forces an interrupt for reasons I can't precisely remember.
sta Routine_0c86 certainly is weird. It modifies the first byte of a subroutine. Again, that could be self-modifying code, but such a byte cannot be an immediate data byte or part of an address, making that less likely.
Things like jsr $ffff also are weird. Why would there be a subroutine starting at the last addressable byte?
Also, "JAM". Really.