bound,

We need a coder for an assembler for the 65Org16 (65016) project. It is identical to the 6502 (except BCD mode, SED & CLD opcodes are non-existent) and has the same opcodes as the original 6502, except the data bus is 16 bit. Also, the address bus is 32 bit, giving a user 4GBytes of linear addressable memory, i.e. no banking registers, thanks to BigEd's original mod of Arlet's core: Check here and here.
So, for example, coding for an LDA #$00 in original 6502 would be A9,00. For the new CPU coding for LDA #$0000 would be 00A9,0000... I would like to add more opcodes/accumulators/index registers in the future. But for now, we at least need some kind of basic assembler to boost the 65Org16 into orbit and you seem to have the very useful skills to contribute?

Right now I am hard coding in a text editor. PITA!

If you decide to contribute, I may have a piece of hardware to contribute for your efforts so you can test your own code on this before posting...

Don't get discouraged.... See here when I got fed up with posting on my PWA project, and actually started deleting links to pics I had posted...
You may actually be ahead of the power curve and not even realize it...

Regards,
EE

Have you considered using an existing macro assembler to prototype the instruction set? An earlier thread discussed using macros to add R65C02 instructions to a 65C02 assembler; this would be the same thing, just on a larger scale.

I'd think it would be much easier to get things "just right" by editing macro definitions than by re-writing an assembler each time a change was desired. Once a macro set "jelled" and became comfortable an assembler could be written to handle the instructions natively (ie., faster).

Any macro assembler that has the flexibility to let you write macros that specify exactly what bytes you want where should do. If a 65xx-assembler won't permit macros with the same names as existing instructions (<cough> HXA65 </cough>), perhaps an assembler for another cpu would (<shameless plug> HXA_T </shameless plug>).

Many assemblers have the MACFIRST directive which allows using macros to re-define mnemonics.

I could probably tweak the source for mine in a couple of hours. I'll have a try at the weekend

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

That would be very much appreciated!

I'm using a modified version of Dave Beazley's assembler, which is better than hand-assembling, but it does have limitations.

Cheers
Ed

Hi TT
The thing I'm not sure about here is that we need 16-bit bytes. So every opcode is 16 bits, and operands are 16 or 32 bits. Now, you might think you can just output pairs of bytes. But the PC counts in 16-bit bytes, so you'd need to take into account that branching back by 6 (16-bit) bytes is only a distance of 6, not 12.

Also, branch distances are now 16-bit signed quantities, so ideally an assembler can cope with distances much greater than 128. A very simple macro-based approach might only allow distances of 64, depending on how the byte-counting was tackled.

It's an interesting puzzle though - do you still think it can be done?

Cheers
Ed

I was going to get involved until I saw the no-BCD thingie...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I believe BigEd is pursuing BCD mode in his version, the original 65Org16. I took BCD out of my version, 65Org16.b, because top speed is one of my highest priorities. BCD can be worked around...

In fact, in my version BCD is subject to conditional compilation, so it's an option. That's slightly messy in the source, but it means there's no runtime penalty if you don't want the feature.

Unfortunately EE took his baseline from my version before I did that, and stripped out BCD in the more straightforward way. That could always be redone of course, if anyone were interested. BDD: that could be your fork! You could put back in BCD when the dust settles.

(Indeed, someone might also want to implement a 16bit version of BCD, but again that's not a huge challenge. It might be an interesting exercise, especially to do it with minimum speed impact. Hint: carry-select adder.)

Cheers
Ed

My first impression is that the main thing to understand is exactly how the program counter works on your processor.

You said the equivalent of "LDA #$00" works out to "00A90000". Suppose those 32 bits are stored at location zero ($00000000). After that is the program counter value two ($00000002) or four ($00000004)?

Relative branches are easy to work out with macros. The equivalent of a standard 6502 "BEQ" instruction might be:

.macro BEQ, ?target
.byte $F0, *-(?target)+1
.endm

Giving that a 16-bit range would be:

.macro BEQ, ?target
.word $00F0, *-(?target)+2
.endm

At least when dealing with 8-bit bytes. This also works if the program counter value I asked about above is four, rather than two. If the value is two, I'd have to think about it some more.

Mmm, if the value is two, doesn't that mean you have only 2^31 addressable locations, rather than 2^32, even with a 32-bit address bus?

--------

After thinking about it a bit longer, suppose we have this source:

here BEQ here

and are using the 16-bit relative branch above.

Should the assembled code be "00F0 FFFC" (BEQ -4)? If so, no changes necessary. If instead it should be "00F0 FFFE" (BEQ -2), then we can do this, I think:

.macro BEQ, ?target
.word $00F0, (*-(?target)+2)/2
.endm

32 bits cannot be store at 1 memory location...

Thanks for responding teamtempest! I'll try to explain since I was the one that wrote that. Original opcodes have been preserved to $00xx-$00xx. No more bytes. Now 16-bit words.
This is a simple program, which may help you understand, that I've written to write a pattern to almost the full 4GB of addressable memory, and BigEd has helped me to debug. I've tested it in simulation...

I've composed some responses in my head which are now somewhat redundant...

Two, as EE has now illustrated - I prefer to call them 16-bit bytes although words might be less confusing.

It's 2^32 - I don't think I see your reasoning, although it might be an artifact of using the macros to promote a byte-based assembler to work in double-bytes.

This trick of dividing by two might be the winning tactic!

Cheers
Ed

Instead of getting all creative with macros wouldn't it be easier to pick up an existing open-source 6502 assembler, and just modify it a bit to emit 16 bit opcodes and operands ?

It would for some: depends on programming skill.

I did that with Dave B's, but his code isn't yet open source (it is however available)

Bitwise kindly offered to have a look at porting his.

I had a quick look at Ophis but was daunted.

Because previous debates about assemblers have exposed some strong syntax preferences, we probably won't have everyone happy until every assembler is ported. But seriously, because programming can be fun, I see no harm in people pursing a port as a project. For me, cc65 (ca65) would be favourite although (or because) it would naturally lead to the question about porting cc65 itself! But tinycc is also a good starting point for a C compiler: it worked for the '816.

(Edit: linkified)

Cheers
Ed

I don' t think you would ever get involved... You're too much of a grumpy old bastard!
Someone else called you grumpy and I agree, and am further quantifying that with "old bastard"... ***ROAST*** arg, arg , arg (arg arg arg = LOL)