[HN Gopher] Regression with the C64
___________________________________________________________________
Regression with the C64
Author : BruceEel
Score : 38 points
Date : 2021-12-27 17:38 UTC (5 hours ago)
(HTM) web link (tensorthings.com)
(TXT) w3m dump (tensorthings.com)
| LeoPanthera wrote:
| I wonder if you could use a modern system to "evolve" C64 6502
| machine code until you got the result you wanted.
| brazzy wrote:
| This is the IT equivalent of the grumpy old man declaring that
| "in my day we walked to school 10 miles barefoot through snow,
| uphill both ways!".
|
| And it's just as stupid.
| blueflow wrote:
| You are the equivalent of the person who hails their new Ad-
| riddled TV because its "smart" and "modern".
| Nuzzerino wrote:
| I'm not one of those people and I found the article to be
| pretty useless.
| z0r wrote:
| I partially agree, but I don't think it's stupid - I've been
| experiencing a gradual push to do more things in the browser
| for 2 decades (along with everyone else I'm sure) and I don't
| think it's a positive thing. My workplace is experimenting with
| people getting a cloud computer and laptop instead of a
| workstation (and laptop) when it's time for new hardware, and
| my experience during the last couple of years of WFH has been
| that our nice modern laptops cannot really provide enough power
| for Chrome to do everything they want us to use Chrome to do.
| reaperducer wrote:
| ML on a C-64. Pretty interesting.
|
| 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.
| Someone wrote:
| Not ML, only linear regression. Looking at the screen dump
| (can't figure that out from the 'source' code, as that is
| junk), possibly only with two points, and in two dimensions. If
| so, it finds the line through two points.
| reaperducer wrote:
| Thanks for the clarification. I know zero about ML and was
| assessing it based on the text.
| Flashtoo wrote:
| Since the article doesn't bother to explain the regression method
| or its implementation, I'll assume this is ordinary least squares
| regression, a method invented over 200 years ago. It's only shown
| to work with two variables, so perhaps it is just determining the
| equation for a line through two points. Either way, this is
| something that has been trivial to do using your own brain before
| even the C64 existed.
|
| 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.
| intricatedetail wrote:
| It still frustrates me that e.g. text editors can't get the
| basics like a latency between a key press and character appearing
| on the screen. My latest Ryzen can't compete with C64 in that
| regard.
| jandrese wrote:
| Some of that isn't the text editors fault. With the C64 the
| keystroke may be on the screen before it out of the USB stack
| on a modern computer. That is even before you start to consider
| the latency in the video stack. As John Carmack once noted: "I
| can send an IP packet to Europe faster than I can send a pixel
| to the screen. How f'd up is that?" --
| https://twitter.com/id_aa_carmack/status/193480622533120001
| forinti wrote:
| Reminds me of some pretty nice articles on Acorn User about
| colliding galaxies, animated lissajous curves, fractals (of
| course), etc.
|
| A friend of mine calls 8 bit computers "glorified calculators"
| and he's right. You could have tons of fun though.
| PaulHoule wrote:
| Linear regression was a common type-in BASIC program at the time
| for computers like the TRS-80, Apple ][, Coco, Atari 800, C64,
| etc.
| 0x0 wrote:
| Does the assembly listing look sensible to anyone? It's been a
| long time but to me it looks like the disassembly of random
| bytes. "Jam rts"? "Nop $60"? "Brk brk sta Routine_0c86"? And a
| ton of raw un-assembled ".byte"?
| scarygliders wrote:
| Nope, it's a perfectly normal listing of 6502 code in
| Assembler.
|
| The BRK instruction, if I recall correctly from my 6502 days,
| forces an interrupt for reasons I can't precisely remember.
|
| EDIT : https://www.c64-wiki.com/wiki/BRK
| Someone wrote:
| Yes, but two BRKs in succession make little sense. The only
| reason to use that I can think of is as placeholders in self-
| modifying code.
|
| _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?
| onurcel wrote:
| that's really weird. It looks like the author wrote it with a
| more powerful system then partly disassembled it. In my opinion
| this hurts the narrative of this otherwise cool
| project/article.
| scarygliders wrote:
| That's not the case. Back in the day you would use some sort
| of "monitor" program to assemble that code (or to disassemble
| code already in memory).
|
| For example, the C64 Action Replay cartridge had a built-in
| monitor. Software machine code monitors and assemblers were
| also available.
| ksherlock wrote:
| You're 100% right. It looks like output from a tracing
| disassembler but it didn't account for the preamble so it
| quickly gets pear shaped.
|
| 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.
|
| https://michaelcmartin.github.io/Ophis/book/x72.html
| roywiggins wrote:
| "To perform the same code on another System, you need more than a
| few transistors, 64 kilobytes of RAM, and a small ROM with an
| even small BASIC interpreter. You need at least a small operating
| system, a much bigger Python interpreter, and a lot of libraries
| to perform the same actions in mostly the same amount of time."
|
| Is anything actually stopping you writing it in baremetal x86
| assembly if you wanted?
| blueflow wrote:
| x86 is a pain, and for much functionality, you need to do
| things like parsing the ACPI tables.
|
| 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.
| masklinn wrote:
| Of course not. Though baremetal x86 is probably not the best
| architecture to work with.
|
| 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).
| nickdothutton wrote:
| The desktop computer revolution lead us on a gigantic 30 year
| detour we are only now coming to the end of.
| tcbawo wrote:
| Detour where? Benchmark-driven, commodity, general-purpose
| computing instead of niche, application-specific, optimized
| hardware?
| pjmlp wrote:
| Being wasted to run Electron apps.
| jononor wrote:
| The C64 has 64 kB of RAM. That is more than many contemporary
| microcontrollers. Using something like
| https://github.com/emlearn/emlearn allows to generate portable C
| code of ML models for such targets. Should be able to classify
| digits (MNIST) no problem on such hardware. Assuming there is a
| workable C compiler available.
|
| Disclosure: Maintainer of emlearn project.
___________________________________________________________________
(page generated 2021-12-27 23:01 UTC)