6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 7:48 pm

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Wed Aug 17, 2011 3:19 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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:
BitWise wrote:
Highly experimental draft assembler and linker.

http://www.obelisk.demon.co.uk/files/65016.zip...

The binary and hex file outputs from the linker look OK but need more testing...

by critiquing this simple adding program using the 16-bit data and 32-bit address format of the 65Org16:
Code:
;==============================================================================
; Example Boot ROM for 65Org16
;------------------------------------------------------------------------------

      .TITLE   "65Org16 Simple Add"

      .CODE
      .ORG   $FFFFF000
      
RESHandler:      
      CLC
      LDA $00000002
      ADC #$0001
      STA $00000000
      LDA $00000003
      ADC #$0001
      STA $00000001

      
IRQHandler:
      RTI

NMIHandler:
      RTI
      
;===============================================================================
; Vectors
;-------------------------------------------------------------------------------
      
      .ORG   $FFFFFFFA
      
      .WORD   NMIHandler
      .WORD   RESHandler
      .WORD   IRQHandler
      
      .END

The resultant binary:
Code:
0018 00A5 0002 0069 0001 0085 0000 00A5 0003 0069 0001 0085 0001 0040 0040


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:
Code:
;==============================================================================
; Example Boot ROM for 65Org16
;------------------------------------------------------------------------------

      .TITLE   "65Org16 Simple Add"

      .CODE
      .ORG   $FFFFF000
      
RESHandler:      
      CLC
      LDA $FFFF0002
      ADC #$0001
      STA $FFFF0000
      LDA $FFFF0003
      ADC #$0001
      STA $FFFF0001

      
IRQHandler:
      RTI

NMIHandler:
      RTI
      
;===============================================================================
; Vectors
;-------------------------------------------------------------------------------
      
      .ORG   $FFFFFFFA
      
      .WORD   NMIHandler
      .WORD   RESHandler
      .WORD   IRQHandler
      
      .END

The resultant binary:
Code:
0018 00AD 0002 FFFF 0069 0001 008D 0000 FFFF 00AD 0003 FFFF 0069 0001 008D 0001 FFFF 0040 0040


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


Last edited by ElEctric_EyE on Sat Aug 20, 2011 11:35 pm, edited 3 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 4:48 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
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:
Code:
java -cp ./65016.jar org.x6502.x65016.As65016  boot.asm
java -cp ./65016.jar org.x6502.x65016.Lk65016 -bss $00010000-$EFFFFFFF -code $FFFFF000-$FFFFFFFF -s19 -output boot.s19 boot.obj
java -cp ./65016.jar org.x6502.x65016.Lk65016 -bss $00010000-$EFFFFFFF -code $FFFFF000-$FFFFFFFF -hex -output boot.hex boot.obj
java -cp ./65016.jar org.x6502.x65016.Lk65016 -bss $00010000-$EFFFFFFF -code $FFFFF000-$FFFFFFFF -bin -output boot.bin boot.obj


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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 5:08 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
BigEd wrote:
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:
Code:
java -cp ./65016.jar org.x6502.x65016.As65016  boot.asm
java -cp ./65016.jar org.x6502.x65016.Lk65016 -bss $00010000-$EFFFFFFF -code $FFFFF000-$FFFFFFFF -s19 -output boot.s19 boot.obj
java -cp ./65016.jar org.x6502.x65016.Lk65016 -bss $00010000-$EFFFFFFF -code $FFFFF000-$FFFFFFFF -hex -output boot.hex boot.obj
java -cp ./65016.jar org.x6502.x65016.Lk65016 -bss $00010000-$EFFFFFFF -code $FFFFF000-$FFFFFFFF -bin -output boot.bin boot.obj
...
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.

BigEd wrote:
...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...
Cheers
Ed

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 5:43 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
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:
BitWise wrote:
ElEctric_EyE wrote:
...

How hard do you think it would be to get a 4K .bin file that conatins a 8-bit 6502 program, and automatically translate it to 65Org16?
I was thinking about it, and at least one rule would have to be followed: The 8-bit program to be translated would have to start out with an opcode, i.e no data values at the very beginning. So the translater can track the opcode conversion...

I don't think it would work. For example consider a simple code sequence like:
Code:
  CLC
  LDA A+0
  ADC B+0
  STA C+0
  LDA A+1
  ADC B+1
  STA C+1

If you convert this code to 65Org16 it won't work as expected. Rather than being a 16-bit addition it would become a 64-bit addition. All such sequence would have to be rewritten to yield the expected runtime behaviour.

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 6:00 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
BigEd wrote:
...existing code will have two-byte operations which only need to be single-'byte' operations....

Yes, for these all that would be needed is a shift right 4x I think with a CLC before.
BigEd wrote:
...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...Cheers
Ed

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?
BigEd wrote:
...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...
Cheers
Ed

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

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 6:07 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
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
Code:
LDA #$80
isn't it impossible to know if that should be
Code:
LDA #$FF80
or
Code:
LDA #$0080

?

Sorry to seem very negative.

Ed


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 6:14 am 
Offline
User avatar

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 6:17 am 
Offline

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 6:31 am 
Offline
User avatar

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Aug 17, 2011 6:42 am 
Offline

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 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: