Page 1 of 1

Machine Code Converters: 6502 to 68000

Posted: Sun Jan 07, 2018 7:34 pm
by Outsoft
I've read, on Facebook, that there are guys that have developed some machine code converters from 6502 to 68000 processors like the great Ergon do for the Famous Speccy Emulator of the 1993 (ZMht).

I've a friend that program on C-64 that would like to convert is games, easily, on the QL.

If someone know something about that please reply me gently.

Best regards.

Re: Machine Code Converters: 6502 to 68000

Posted: Sun Jan 07, 2018 9:43 pm
by Zarchos
No idea at all if that can help you, but you could also ask on the stardot forum.
After all the early Acorns use a 6502, and there are some really talented geeks on this forum.

Please keep us informed.
If it can be more than a converter, but some sort of resourcer, that could be interesting.
I doubt automatic conversion from 6502 to 68000 can be as good as direct 68000 programming, but who knows the level of optimisation put into this converter, after all ?
If the 68000 code produced is sourced, and well sourced with comments, that can certainly help for an optimised conversion.

Re: Machine Code Converters: 6502 to 68000

Posted: Sun Jan 07, 2018 9:46 pm
by Derek_Stewart
Hi,

Many years ago in the 1990s I thought the 68000 could run 6502 assembler source code. To implement this I starting writing a macro library file for the QMAC assembler.

The idea was to define the 6502 op codes with QMAC macros and 68000 assembley op codes.

Since the 6502 CPU is 8 bit, the 68000 CPU could easily handle the 8 bit 6502 registers.

Another idea was to write the 6502 op codes in Turbo compiled basic.

But the main problem with these approaches is the 6502 code will be specific to the hardware it runs on.

The NES console has software to help convert the 6502 to 68000 see this list:

http://nes.goondocks.se/software.php

This might help.

Maybe with alot of effort 6502 or 68000 console games could be converted to the QL or Q68...

Re: Machine Code Converters: 6502 to 68000

Posted: Mon Jan 08, 2018 6:01 am
by Zarchos
Yes Derek.

This is why a resourcer, with comments for the areas too specific to the 6502 machine (chipset or system routines) could help.
Now all functions are documented on the various retro machines, you could imagine appearing in the source a link to a section of a database storing descriptive, technical infos.

Re: Machine Code Converters: 6502 to 68000

Posted: Tue Jan 16, 2018 9:49 pm
by Outsoft
Derek_Stewart wrote:Hi,

Many years ago in the 1990s I thought the 68000 could run 6502 assembler source code. To implement this I starting writing a macro library file for the QMAC assembler.

The idea was to define the 6502 op codes with QMAC macros and 68000 assembley op codes.

Since the 6502 CPU is 8 bit, the 68000 CPU could easily handle the 8 bit 6502 registers.

Another idea was to write the 6502 op codes in Turbo compiled basic.

But the main problem with these approaches is the 6502 code will be specific to the hardware it runs on.

The NES console has software to help convert the 6502 to 68000 see this list:

http://nes.goondocks.se/software.php

This might help.

Maybe with alot of effort 6502 or 68000 console games could be converted to the QL or Q68...
Thanks Derek!!!

Re: Machine Code Converters: 6502 to 68000

Posted: Wed Jan 17, 2018 6:11 am
by Dave
Honestly, my ears prick up any time someone suggests we port QDOS (or SMSQ/E) to ARM. Now, there's some room for growth!

Re: Machine Code Converters: 6502 to 68000

Posted: Wed Jan 17, 2018 5:47 pm
by XorA
Dave wrote:Honestly, my ears prick up any time someone suggests we port QDOS (or SMSQ/E) to ARM. Now, there's some room for growth!
If it can be done with AmigaOS then it certainly can be done for QDOS :-)

Re: Machine Code Converters: 6502 to 68000

Posted: Sun Oct 13, 2019 9:58 am
by tricky
When I first got my AtariST, I started writing a BBC emulator for it.
I reserved 64K for the beebs memory and just used a jump table indexed by opcode for the 6502 part.
I also tried jumping to N*opcode to avoid the extra indirection and jumped from there if the code couldn't fit in N bytes.
I was only trying to emulate a 2MHz 6502, so it didn't matter that the 68K was much less efficient, but probably would here.