MOS tech 6502 8-bit microprocessor in pure SQL powered by Postgres (github.com)

Cool! How about Postgres on MOS tech 6502 8-bit microprocessor powered by Microsoft's 6502 BASIC?

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.

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:

    # 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.

Waiting for 6502 implemented on top of Sudoku!

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...

Can someone take this and build a working 6502 binary that creates a SQL database?

[dead]

Lovely! (I saw a few examples in "tests")

Next step : insert the Applesoft Basic assembly code and allow programming in Basic through SQL

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...

[dead]