SOSomeone·Apr 14, 2026
This, basically, uses a table to store 64 kilobytes of memory, a single-row table for storing register values, and uses regular procedural programming to run the CPU (https://github.com/lasect/pg_6502/blob/main/init/05_execute....)
I give that an A+ for perseverance, but I would have hoped to see something that uses the strengths of SQL more.
For example, there could be a table with the decode ROM (https://www.cpcwiki.eu/index.php/MOS_6502#The_Decode_ROM_.28...) that could be used to drive the logic.
Have a main loop that uses the inputs of that ROM to look up the output bits and update a table, and add triggers that handle each “micro-op”. A SQL engine could run those triggers in parallel until they hit a race condition, but those can be avoided a bit by having separate tables for each register.
Even better would be if there were tables
Read the rest
with every logic gate and wire in the original CPU, using a trigger to move the signals around. That would be a good test of the trigger handling in a SQL engine.