Hi all. A most excellent effort has been shown by Bitwise and teamtempest to create an assembler for the 65Org16 CPU. In all honesty, I have not gotten around to teamtempest yet, as I am concentrating alot of my time on the hardware aspect of this project, so my time is very limited. Although BigEd has tested them both.

But IMHO, someone needed to continue Dr. Jefyll's topic about a compiler for the 65Org16. Instead of a compiler though, how about a translator. I started a new thread here because I would like to explore the assembler Bitwise has produced in order to compare some 65Org16 code to 6502 code.

So, as a first step, I would like to check out the binary output of Bitwise's 65Org16 assembler...
We need to compare the code in .bin (binary) form after his assembler converts the boot.asm and then compare it to an original 6502 binary. This should not only point out possible errors in the draft assemblers, but also make us realize if a translator, i.e. automatic porting, is even possible. Also, the FPGA can be programmed with this binary file. I personally think it is possible, and a great many programs alot of people have put much skill and genius into can be reborn! Alas, I am thinking in general terms only ATM.
Now it's time to get to the specifics and to prove and disprove. Hopefully a most constructive argument will result!

So, I would like to start here:

by critiquing this simple adding program using the 16-bit data and 32-bit address format of the 65Org16:

The resultant binary:


Observations:
The length of the file is correct, everything is correct, except for the expected 32-bit address. You can see after the ($00A5) LDA, only a 16-bit address ($0002) is shown.
Is it optimizing the $0000 MSB value out? YES!

Making an address change to prove this:

The resultant binary:


I'm starting to get a good feeling about this. Hopefully it's not just a lack of sleep...

EDIT: Fixed a bad link.
EDIT: Renamed Title
EDIT: Fixed mispelling

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

To help future adventurers: once you've unpacked BitWise's zip file, you'll have a Makefile and an NMAKE.exe which are set up to build from the supplied boot.asm

If you have a different source file, you'll need to edit the Makefile, or copy and modify the commands which it issues:


Note that we do have a verilog implementation (or two) of the 65Org16, so it can be simulated, but we don't yet have an emulator. EEye mentions Mike's py65 above: that might be the most likely source of an emulator.

Cheers
Ed

Also, as Bitwise pointed out, you will need to download the java 1.6 JRE/JDK, which is where I went wrong about a month or two ago.


The 65Org16.x most definately can be simulated using ISE. We've (Arlet, you and me) proved that this core can work.
As for an emulator, maybe that belongs in a separate thread...
I think those interested, and hopefully I am not the only one, would like to pursue translating 8-bit 6502 into 16-bit 65Org16.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Hi EEye

(not meaning to hijack your thread there)

Seeking some clarification here, because I'm not sure what kind of translating you have in mind...

If you're thinking of just re-assembling existing 8-bit sources as-is, we have Bitwise's comment:

existing code will have two-byte operations which only need to be single-'byte' operations.

Or were you thinking - it seemed like you might be - of translating an 8-bit binary into a 16-bit binary? Which has the above problem, and an additional problem, of whether to zero-pad or sign-extend each byte. Opcodes need zero-padding but branch offsets need sign-extending. Operands might need one or the other depending on the programmer's intent.

Or, when you say translate, do you mean a manual process, of carefully going through an 8-bit source file, re-writing it into 65Org16 code, which is what I did with the hex loader? (I'm ashamed to say I still haven't run that on the physical CPU yet)

Cheers
Ed

Yes, for these all that would be needed is a shift right 4x I think with a CLC before.

The sign extending is where the real work would figure in for branching and jumping I guess, all the other stuff seems straight forward...

so converting to 16-bit branch from puny 8-bit branches shouldn't be to hard conversion should it? Wouldn't you again just basically truncate the MSB?

No, I mean for a program to do all the work!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

No, I don't get it I'm afraid. For me, the 65Org16 is not even source code compatible: it's just a very familiar machine. I find it very hard to see how one could write a program to do a binary translation. It would be even harder than a true disassembler (one which can figure out all sections of code and data, and figure out jump tables, and tables of return addresses, and split tables of LSB and MSB addresses.)

If I had
isn't it impossible to know if that should be
or

?

Sorry to seem very negative.

Ed

I should add: before we had any assembler at all, I did consider exactly the sort of translation you suggest, but only for

- very simple bootloader
- written specifically with the translation in mind

Now we have two and a half assemblers, the picture's different. It's still true that porting, say, EhBASIC might be quite a job. (It might not) But you'd want to put the effort in at least some places: doing 32-bit arithmetic in two operations instead of four would be part of the advantage.

Cheers
Ed

Ok, follow me just for arguments's sake. Trying to think out of the box here...

This is what I meant by 1 rule the translator had to follow: The program to be translated must start with an opcode. Opcodes would then be put into separate groups: 1, no operand (like CLC). 2, 1 16-bit operand, 3 2 16-bit operand. So based on the opcode (<256 right now), the translator would know how many 16-bit data to skip until the next opcode to be read/converted, be it 0, 1 or 2.

I'm pretty sure it can be done. At least for simple program, like the addition program mentioned at the beginning.
Data tables and such would definately throw a monkey wrench in the translation, especially if they were in the middle or beginning.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yes, you can follow the possible execution paths and find all the opcodes, at least for moderate cases.

But what about operands? You can't tell if they are signed or unsigned. And if there's any shifting or masking, you get into trouble because bit 7 is no longer the sign bit.

So, for some programs you'll be fine, I agree. It's a question of how many: whether the idea is useful enough to be worth doing - and that's a judgement call.

Do we agree that some programs won't work?

Cheers
Ed

Yes, I agree for now... More testing tomorrow. I intend to compare code. Thanks for entertaining my thoughts BigEd!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502