3 ms·

Not sure what the advantage is, relative to the tables as CSV files.

by snvzz 3y ago

simonw 3y ago
The ability to ship SQL views that join multiple tables as part of the schema is pretty cool, and something you can't come close to replicating with CSVs. https://lite.datasette.io/?sql=https://gist.github.com/simonw/60fd6fedb3fd460bcfd1c5263618b0ac#/data/opcodes?_facet=mode&_facet=base_cycles&_facet=force_cycles&_facet=bytes https://lite.datasette.io/?sql=https://gist.github.com/simon...
- maxcoder4 3y ago
  I like how it looks, and I appreciate the effort that went into it, but other than using it to export a table in just a right format that you will then embed into your assembler directly, I'm not sure how to use it. And I use opcode references [1] very often (sometimes daily, depending on the project). I even wrote my own disassemblers. But I mostly use opcode references for manual cross checking, so maybe I'm not a target of this project? [1] My favorite one for x64 is https://ref.x86asm.net/coder64.html https://ref.x86asm.net/coder64.html
  - simonw 3y ago
    The ability to export data from a table or query in whatever format you need is one of my favorite things about distributing data using SQLite.
thristian 3y ago
As far as I know, most information about the 6502 instruction set comes in two forms: - emulators/simulators/FPGA code - books, data sheets, OCR'd PDFs of books and data sheets, text files copy/pasted from PDFs or retyped from books and data sheets Code is likely to be heavily tested, but it makes extracting high-level information about the instruction set very difficult. Data is easy to analyse and synthesise, but since it's described in prose there's no easy way to test or validate it - if somebody in 1984 made a typo that a particular instruction took 3 cycles instead of 2, and that error was copy/pasted and made its way into half the "6502 instruction set" websites online, how would you know? How would you detect it? Using SQL to enforce constraints and validation gives me confidence that there aren't a bunch of typos and copy/paste errors in this data. In addition, being able to express special cases like "read-modify-write instructions applying to the accumulator do not pay the three cycle penalty" in code rather than in prose makes it more likely they will be applied correctly. Lastly, since the result is an SQL database, it can be pretty easily formatted to resemble any book or data sheet you like for simplified visual verification against book/data sheet sources.

Not sure what the advantage is, relative to the tables as CSV files.

by snvzz 3y ago

Not sure what the advantage is, relative to the tables as CSV files.

The ability to ship SQL views that join multiple tables as part of the schema is pretty cool, and something you can't come close to replicating with CSVs. https://lite.datasette.io/?sql=https://gist.github.com/simonw/60fd6fedb3fd460bcfd1c5263618b0ac#/data/opcodes?_facet=mode&_facet=base_cycles&_facet=force_cycles&_facet=bytes https://lite.datasette.io/?sql=https://gist.github.com/simon...

maxcoder4 3y ago
I like how it looks, and I appreciate the effort that went into it, but other than using it to export a table in just a right format that you will then embed into your assembler directly, I'm not sure how to use it. And I use opcode references [1] very often (sometimes daily, depending on the project). I even wrote my own disassemblers. But I mostly use opcode references for manual cross checking, so maybe I'm not a target of this project? [1] My favorite one for x64 is https://ref.x86asm.net/coder64.html https://ref.x86asm.net/coder64.html
- simonw 3y ago
  The ability to export data from a table or query in whatever format you need is one of my favorite things about distributing data using SQLite.

thristian 3y ago

As far as I know, most information about the 6502 instruction set comes in two forms: - emulators/simulators/FPGA code - books, data sheets, OCR'd PDFs of books and data sheets, text files copy/pasted from PDFs or retyped from books and data sheets Code is likely to be heavily tested, but it makes extracting high-level information about the instruction set very difficult. Data is easy to analyse and synthesise, but since it's described in prose there's no easy way to test or validate it - if somebody in 1984 made a typo that a particular instruction took 3 cycles instead of 2, and that error was copy/pasted and made its way into half the "6502 instruction set" websites online, how would you know? How would you detect it? Using SQL to enforce constraints and validation gives me confidence that there aren't a bunch of typos and copy/paste errors in this data. In addition, being able to express special cases like "read-modify-write instructions applying to the accumulator do not pay the three cycle penalty" in code rather than in prose makes it more likely they will be applied correctly. Lastly, since the result is an SQL database, it can be pretty easily formatted to resemble any book or data sheet you like for simplified visual verification against book/data sheet sources.