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 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.
Very cool! If you want to see a much simpler version of this I wrote an article a few years implementing a stack language in Postgres PL/pgSQL similar to what this one does.
But I'd love it if it could run in SQLite3.
The stored functions and procedures here are neat, but I wonder if they could be turned into views and combinations of built in functions...
I think triggers can do nearly everything that a stored procedure does, perhaps with a little bit more fiddling. I sometimes make "parameter tables" where I insert all the necessary data and a trigger does what effectively a stored proc does.
Maybe there'd need to be a few imported functions?
I wonder if an AI could be persuaded...
I've got to run under OpenBSD/i386 but it needs a bit of tweaks in the Makefile. On the target section:
# CFLAGS=$CFLAGS" -m32" # on x86 64-bit systems
CFLAGS=$CFLAGS" -static" # in case all else fails
CFLAGS=$CFLAGS" -fPIC" # get rid of stupid linker errors
CFLAGS=$CFLAGS" -Wl,-z,notext" # get rid of stupid linker errors
CFLAGS=$CFLAGS" -fno-PIE -no-pie" # get rid of stupid linker errors
Do the same in the bin/tx0.sh and bin/build.sh just in case.
In my system I set the target to unix-386, and T3XDIR it's set
to T3XDIR=/usr/local/t3x/lib in the Makefile and bin/tx0.sh scripts.
Also, T3XBIN it's set to BINDIR= /usr/local/t3x/bin
Then I ran:
sh bin/modpath.sh /usr/local/t3x/lib
gmake all-native
doas gmake install-native install-modules
But it was still broken. Then, I edited /usr/local/t3x/bin/tx0 and set
TX3DIR is above, and ditto with the four CFLAGS flags I posted.
Just the ones at lines 38-42.
OFC set PATH to /usr/local/t3x0/bin:$PATH in ~/.profile:
export PATH=/usr/local/t3x0/bin:$PATH
Yeah, it's tricky, but from now on everything will just compile with
'tx0 foo'
where 'foo' it's a foo.t file.
This was compiled under an Atom n270 CPU based netbook. I think the author uses a Pentium III machine. If T3X0 can do a MOS 6502 emulation that well, you can try expanding s65/sim65 to cover the Apple I emulation.
And, as a plus, it might run fast on DOS 386 machines if s65/sim65 it's compiled a native binary.
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 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.
Very cool! If you want to see a much simpler version of this I wrote an article a few years implementing a stack language in Postgres PL/pgSQL similar to what this one does.
https://notes.eatonphil.com/exploring-plpgsql-forth-like.htm...
This is great!! .....
But I'd love it if it could run in SQLite3. The stored functions and procedures here are neat, but I wonder if they could be turned into views and combinations of built in functions...
I think triggers can do nearly everything that a stored procedure does, perhaps with a little bit more fiddling. I sometimes make "parameter tables" where I insert all the necessary data and a trigger does what effectively a stored proc does.
Maybe there'd need to be a few imported functions? I wonder if an AI could be persuaded...
Can someone take this and build a working 6502 binary that creates a SQL database?
Kim-1 emulator and assembler for T3X0:
https://t3x.org/t3x/0/sim65kit.html
https://t3x.org/kimuno/
Pocket calc as 6502 code
https://t3x.org/kimuno/kimcalc.html
T3x0 compiler to build the emulator:
https://t3x.org/t3x/0/index.html
I've got to run under OpenBSD/i386 but it needs a bit of tweaks in the Makefile. On the target section:
Do the same in the bin/tx0.sh and bin/build.sh just in case. In my system I set the target to unix-386, and T3XDIR it's set to T3XDIR=/usr/local/t3x/lib in the Makefile and bin/tx0.sh scripts.Also, T3XBIN it's set to BINDIR= /usr/local/t3x/bin
Then I ran:
But it was still broken. Then, I edited /usr/local/t3x/bin/tx0 and setTX3DIR is above, and ditto with the four CFLAGS flags I posted.
Just the ones at lines 38-42.
OFC set PATH to /usr/local/t3x0/bin:$PATH in ~/.profile:
Yeah, it's tricky, but from now on everything will just compile with where 'foo' it's a foo.t file.This was compiled under an Atom n270 CPU based netbook. I think the author uses a Pentium III machine. If T3X0 can do a MOS 6502 emulation that well, you can try expanding s65/sim65 to cover the Apple I emulation.
And, as a plus, it might run fast on DOS 386 machines if s65/sim65 it's compiled a native binary.
Lovely! (I saw a few examples in "tests")
Next step : insert the Applesoft Basic assembly code and allow programming in Basic through SQL
Cool! How about Postgres on MOS tech 6502 8-bit microprocessor powered by Microsoft's 6502 BASIC?
Waiting for 6502 implemented on top of Sudoku!
How would that work?
[dead]
[dead]