lefticus / 6502-cpp Goto Github PK

Hi,

Using the same technology would it be possible to write in C++ and then translate the assembler to Z80 cpus ? Of course re-writing x86-to-6502 project. I want to know if it is possible and how hard would it be for someone who does not know assembler language at all (but wants to learn it).

Thank you very much for this and for your youtube videos. Sorry if this is the wrong place to post, I did not know a better place.

best regards,
ovi

Hey Jason,

I've begun a large refactor using these original sources to build something a little more expandable and maintainable (although I must say the code was still a breeze to work with even in this state!)

I've currently done the following:

• Cleanup everything from main into seperate files
• Abstracted away the translation code for the 6502, which means that in theory another CPU like the z80 could be added.
• Added some more opcodes like being able to call functions from existing assembly (through the cdecl calling convention), which paves the way for 16bit math (which should really not be inlined)
• Began work on unit tests (using google test)
• Added initial support for custom interrupt vectors for IRQ and NMI. Having a cdecl void named irq or nmi will generate this code as an interrupt, also generating a rti instruction instead of rts.
• Fixed some minor bugs
  • Parse error when running on clang on windows (unindented directive line)
  • Parse error when some instructions are generated with a comment behind it (fixed regex)
  • Changed optimization to O2, since O3 wants to unroll loops which seems like a really bad idea (why was it O3?)
• Added CI jobs on travis-ci (clang) and appveyor (vs2017)
• Added support for the SP/ESP registers (untested on commodore, I've picked 2 seemingly? free addresses from the zero page)
• Replaced register numbers with a proper enum containing all supported i386 registers (readability)
• Added some godbolt example config and script which can be used to plug it straight into godbolt without needing additional changes. The only limitation here is that additional arguments given in the browser are ignored at the moment

If you're interrested, perhaps we should discuss the way forward to get things in sync. I've spend a few afternoons tinkering with it, but I'm sure it can be improved and I'd love to hear your ideas.

Check it out at https://github.com/robindegen/x86-to-6502

When the translator cannot handle the x86 "pull" or "sbbb" instructions, it is issuing a misleading error message "Cannot translate sbb instruction". Likewise, similar error messages say "movl" instead of "xorl" and "cmb" instead of "cmpb".
The first commit in pull request 1 would address these as well as implement a 16-bit translation of the 32-bit shrl instruction.

z80 support is really missing! :)

How do you manage the translation of the registers? I assume there are less registers on 6502 than on x86.

This can be fairly convenient, as the user can input an executable file and this app can spit out another executable, ready to go. Example:

x86to6502 i8086-test-executable.com -o 6502-test-executable.bin

Or this:

i8086-gcc test.c -S -o - | x86to6502 -o 6502-test.bin

As time permits please add support for 'illegal opcodes.' An excellent reference exists at NMOS 6510 Unintended Opcodes: No More Secrets.

The 6510 on the C64 had these op-codes but other variants of the MOS 65xx family did not. For example, the 8-bit chip 65C02 (common in early C64 accelerators) lacked support for these op-codes. Also, the 16 bit variant WDC 65C816 found in the SuperCPU, the Apple 2GS, etc. redefined these codes to entirely different (now valid) op-codes. So, you'll probably want to use a command line switch to enable/disable this feature if you add it.

It's worth noting that modern C64 accelerators such as the Turbo Chameleon 64 do support these op-codes and even today some demo coders use them to save a few CPU cycles now and again.