65816 Assembler for Windows

[BigDumbDinosaur]

ElEctric_EyE wrote:

BigDumbDinosaur wrote:

ElEctric_EyE wrote:

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)...

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

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)

Actually, the other person referred to me as a "grumbler."

[teamtempest]

Quote:

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

I should have said "stored starting at $00000000..."

Quote:

teamtempest wrote:
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?

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.

Perhaps I'm confused because I was thinking of most commercially available 4GB RAM chips. It seems to me that however such a chip is physically addressed it's not possible to get more than 2GB 16-bit locations out of it (at least non-overlapping ones).

I guess I wasn't really thinking about what most people consider 8GB of RAM these days (4GW or 4GDB, perhaps?).

[ElEctric_EyE]

I was recently thinking of 128Kx16...

This would at least cover the entire 65016 64K zero page ($00000000-$0000FFFF) and 64K stack ($00010000-$0001FFFF).

[BigEd]

teamtempest wrote:

Perhaps I'm confused because I was thinking of most commercially available 4GB RAM chips.

Ah, I see: you were thinking of a particular implementation. More generally: we'll have 32 address lines, and 16 data lines, and so the memory subsystem can hang enough chips off those lines to give us 2^32 words of 16 bits each, however many chips that takes.

In practice, as EE suggests, and certainly at this stage, we'll usually see much less memory than that.

But if we happen to install more than 16MByte, we'll have more memory than an '816 system, and a familiar flat addressing model in all addressing modes.

At more than 64kByte, we'll have more memory than a 6502 system.

But even at under 64kB, we have some interesting effects of large zero page, stack and branch distances. And native 16-bit data types.

One architectural twiddle to look into is the single-byte pointer, which will lead nicely to the 65Org32.

Cheers
Ed

[BitWise]

The biggest issue with converting my code has proven to be the 16-bit bytes but I've nearly got that sorted now.

[BigEd]

great news - thanks for the update!

[BigEd]

Arlet wrote:

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 ?

I see now that in the particular case of the HXA assembler, it's natural to define entire instruction sets as macros, and include that set of definitions at the head of a source file. The 65xx family, from NMOS up to '816, is defined that way. However, it's starting to look like 16-bytes are sufficiently different from the usual sort that a change to the source might be the best approach. (HXA is open source)

I'm collecting practical approaches to a 65Org16 assembler in this thread.

Cheers
Ed