6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Jun 16, 2024 4:09 am

All times are UTC




Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Fri May 27, 2011 12:54 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri May 27, 2011 2:54 am 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 390
Location: Minnesota
Quote:
We need a coder for an assembler for the 65Org16 (65016) project.


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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri May 27, 2011 3:38 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8458
Location: Southern California
Quote:
If a 65xx-assembler won't permit macros with the same names as existing instructions

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri May 27, 2011 9:31 am 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri May 27, 2011 9:42 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri May 27, 2011 2:02 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
teamtempest wrote:
Quote:
We need a coder for an assembler for the 65Org16 (65016) project.


Have you considered using an existing macro assembler to prototype the instruction set?
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


Top
 Profile  
Reply with quote  
 Post subject: 65C816 Assembler
PostPosted: Fri May 27, 2011 5:55 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8214
Location: Midwestern USA
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... :(

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 Assembler
PostPosted: Fri May 27, 2011 6:21 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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 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...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri May 27, 2011 7:22 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat May 28, 2011 3:45 am 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 390
Location: Minnesota
Quote:
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.


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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat May 28, 2011 4:18 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
teamtempest wrote:
...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)?
...

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

Code:
 *= $FFFFE000                 ;START   COPY PATTERN $AA55
                              ;FROM $10000000 TO $FFFEFFFF (($FFFE X 10000) + FFFF)
                              ;
FFFFE000   LDA #$0000         ;00A9 0000
FFFFE002   STA $0000          ;0085 0000
FFFFE004   LDA #$1000         ;00A9 1000
FFFFE006   STA $0001          ;0085 0001
FFFFE008   LDX #$FFFE         ;00A2 FFFE
FFFFE00A   LDY #$0000         ;00A0 0000
FFFFE00C   LDA #$AA55         ;00A9 AA55
FFFFE00E   STA ($0000),Y      ;0091 0000
FFFFE010   INY                ;00C8
FFFFE011   BNE FFFFE00E       ;00D0 FFFB
FFFFE013   INC $0001          ;00E6 0001
FFFFE014   DEX                ;00CA
FFFFE015   BNE FFFFE00E       ;00D0 FFF6
FFFFE017   JMP FFFFE017       ;004C E017 FFFF


Last edited by ElEctric_EyE on Sun May 29, 2011 12:56 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat May 28, 2011 6:12 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
I've composed some responses in my head which are now somewhat redundant...

teamtempest wrote:
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)?
Two, as EE has now illustrated - I prefer to call them 16-bit bytes although words might be less confusing.

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.

teamtempest wrote:
...suppose we have this source:
Code:
here: BEQ here
...If [] it should be "00F0 FFFE" (BEQ -2), then we can do this, I think:
Code:
.macro BEQ, ?target
.word $00F0, (*-(?target)+2)/2
.endm
This trick of dividing by two might be the winning tactic!

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat May 28, 2011 8:49 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
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 ?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat May 28, 2011 9:42 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10827
Location: England
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 Assembler
PostPosted: Sun May 29, 2011 1:20 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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! :wink:
Someone else called you grumpy and I agree, and am further quantifying that with "old bastard"... ***ROAST*** arg, arg , arg (arg arg arg = LOL)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 19 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: