> The model weights and inference code need to be contained within 25KB of user-space memory
Wouldn’t it be era-appropriate to allow relying on banked memory? You’d still need to hold the inference code, but you could effectively stream(ing page) the weights as you compute on them.
Banking RAM is most simply done by physically wiring RAMs in parallel and routing Chip Select/Chip Enable pins individually from GPIO. People were doing it in PDAs until late 00s. Also, I/O ports on these old machines and CPUs up until switch to PCI Express were philosophically just DRAM slots in alternate shapes, so RAMs could be more or less simply installed and RAMs on adapter cards just accessed. This is also technically applicable to PCIe from various perspectives other than performance.
Update: Actually, there were other boards. I remember one particular advert for a board that could handle 256KB of RAM/ROM. I'm now actually curious if adding too many ROMs would make the * commands noticeably slower (the OS would look for the commands in the ROMs, one by one, until it found the code to handle them).
Cool to think this demo would have been possible over fifty years ago. I wonder what someone from 1975 would have said if you had shown this to them back then.
This is super cool!
As someone who's worked a little with NES programming and tried out cc65, I'm surprised he didn't just hand write some assembly, he likely couldve saved a lot of space if I had to guess.
From my experience, modern machine learning models don't scale well down at all, and it's almost certainly better to just use a simple Markov chain variant of some sort - like Niall on the Amiga, or whatever Terry Pratchett used to come up with Foul Ol' Ron's catchphrase, "Millennium hand and shrimp".
> The model weights and inference code need to be contained within 25KB of user-space memory
Wouldn’t it be era-appropriate to allow relying on banked memory? You’d still need to hold the inference code, but you could effectively stream(ing page) the weights as you compute on them.
From a look at https://en.wikipedia.org/wiki/BBC_Micro#Specifications I think the 6502 versions of the beeb didn't have banked RAM so to keep it loadable from tape the limits might be as stated.
But with substantial additional effort, maybe some banked ROMs could be added..?
Banking RAM is most simply done by physically wiring RAMs in parallel and routing Chip Select/Chip Enable pins individually from GPIO. People were doing it in PDAs until late 00s. Also, I/O ports on these old machines and CPUs up until switch to PCI Express were philosophically just DRAM slots in alternate shapes, so RAMs could be more or less simply installed and RAMs on adapter cards just accessed. This is also technically applicable to PCIe from various perspectives other than performance.
You could buy a board called Integra-B to expand a model B.
https://www.youtube.com/watch?v=lT07uPRRPfU
A few games required some extra RAM.
Update: Actually, there were other boards. I remember one particular advert for a board that could handle 256KB of RAM/ROM. I'm now actually curious if adding too many ROMs would make the * commands noticeably slower (the OS would look for the commands in the ROMs, one by one, until it found the code to handle them).
the banking was done via an external ram controller whose bank control register was mapped to some (unbanked) controller address.
Cool to think this demo would have been possible over fifty years ago. I wonder what someone from 1975 would have said if you had shown this to them back then.
This is super cool! As someone who's worked a little with NES programming and tried out cc65, I'm surprised he didn't just hand write some assembly, he likely couldve saved a lot of space if I had to guess.
From my experience, modern machine learning models don't scale well down at all, and it's almost certainly better to just use a simple Markov chain variant of some sort - like Niall on the Amiga, or whatever Terry Pratchett used to come up with Foul Ol' Ron's catchphrase, "Millennium hand and shrimp".
The 6502 is notoriously unfit for a C compiler, so probably there is room for more performance in the future. :)
The biggest win for AI dev efficiency is cutting down what gets loaded into context. Semantically matching tasks to the top tools helps a lot.
This is amazing project! I hope it will result in real miniaturization of AI - for example, edge LLM inside of glasses. That will be awesome.
really great work
[flagged]
[flagged]