6502.org

Posted: **Fri Aug 19, 2011 5:08 pm**

I made the first steps in extending Mike's py65 emulator to support the 65Org16 as a 3rd choice of CPU. The (python) source is on github.

When you run the emulator, it's in 6502 mode, then you switch to 65Org16 mode:

Code: Select all

Py65 Monitor

       PC  AC XR YR SP NV-BDIZC
6502: 0000 00 00 00 ff 00110000
.mpu
Current MPU is 6502
Available MPUs: 6502, 65Org16, 65C02
.mpu 65Org16
Reset with new MPU 65Org16

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 00000000 0000 0000 0000 ffff 0000000000110000

There's an assembler and disassembler but I haven't touched them yet, likewise the memory fill and dump commands are still 8-bit and limited to 64k address space.

But I could step through a short test program (note the lack of 16-bit constants and any branch offsets, and the opcodes and operands all coming out as 8-bit):

Code: Select all

$0000  a9 6a     LDA #$6a
$0002  6a        ROR A
$0003  6a        ROR A
$0004  6a        ROR A
$0005  6a        ROR A
$0006  69 50     ADC #$50
$0008  6a        ROR A
$0009  6a        ROR A
$000a  48        PHA
$000b  88        DEY
$000c  98        TYA
$000d  38        SEC
$000e  69 02     ADC #$02
$0010  aa        TAX
$0011  68        PLA
$0012  ea        NOP
$0013  4c 00 00  JMP $0000

and it behaves as expected:

Code: Select all

 PC      AC   XR   YR   SP   NV---------BDIZC 
00000000 0000 0000 0000 fff6 0000000000110100  LDA #$6a
00000002 006a 0000 0000 fff6 0000000000110100  ROR A
00000003 0035 0000 0000 fff6 0000000000110100  ROR A
00000004 001a 0000 0000 fff6 0000000000110101  ROR A
00000005 800d 0000 0000 fff6 1000000000110100  ROR A
00000006 4006 0000 0000 fff6 0000000000110101  ADC #$50
00000008 4057 0000 0000 fff6 0000000000110100  ROR A
00000009 202b 0000 0000 fff6 0000000000110101  ROR A
0000000a 9015 0000 0000 fff6 1000000000110101  PHA
0000000b 9015 0000 0000 fff5 1000000000110101  DEY
0000000c 9015 0000 ffff fff5 1000000000110101  TYA
0000000d ffff 0000 ffff fff5 1000000000110101  SEC
0000000e ffff 0000 ffff fff5 1000000000110101  ADC #$02
00000010 0002 0000 ffff fff5 0000000000110101  TAX
00000011 0002 0002 ffff fff5 0000000000110101  PLA
00000012 9015 0002 ffff fff6 1000000000110101  NOP
00000013 9015 0002 ffff fff6 1000000000110101  JMP $0000

(some reformatting for the forum - it actually looks like this:)

Code: Select all

.
$000d  38        SEC

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 0000000d ffff 0000 ffff fff5 1000000000110101
.
$000e  69 02     ADC #$02

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 0000000e ffff 0000 ffff fff5 1000000000110101
.
$0010  aa        TAX

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 00000010 0002 0000 ffff fff5 0000000000110101
.

Posted: **Fri Aug 19, 2011 8:27 pm**

The docs for Mike's py65 can be found here.

Anyone picking up my work-in-progress from github will need to know that they'll need (*) the 'blist' package in their python installation (or in their python path.) If you're using ActiveState python on Windows there's a utility 'pypm' for installing packages.

(I used blist to model the huge memory space of the 65Org16.)

Cheers
Ed

Edit: I briefly put up a windows exe on my dropbox, but it looks like that would be a licensing violation unless I included all the source, so I've taken it down again. It is possible to make a standalone exe though. Let me know if you want one.

Edit: (*) blist not needed any more

Posted: **Sat Aug 20, 2011 9:48 pm**

Got the remains of the 16-bit conversion done, I think.

Should mean that anyone can have a try with Bruce's program of the day... or maybe I need to fixup the 'load' function to do something useful about loading 16-bit binaries.

Sources in github as usual, where you can also download a zipfile or tarball.

Cheers
Ed

Code: Select all

.add_label 4000 init
.add_label 4004 I1
.add_label 6000 P
.disassemble init:init+10
$00004000  00a9 0002       LDA #$0002
$00004002  00a2 1192       LDX #$1192
$00004004  0095 6000       STA P,X
$00004006  00ca            DEX
$00004007  0010 fffb       BPL I1
$00004009  0060            RTS

Posted: **Sun Aug 21, 2011 12:25 pm**

BigEd wrote:

... or maybe I need to fixup the 'load' function to do something useful about loading 16-bit binaries.

load and save are working now.

Posted: **Mon Aug 22, 2011 3:28 pm**

Armed with the py65 emulator(*), I've used Bitwise's assembler to produce a binary bootrom(**) which can load intel hex, and teamtempest's assembler to produce that (variant) intel hex for test programs.

Creating the bootrom:

Code: Select all

java -cp ./65016.jar org.x6502.x65016.As65016  bootrom.asm
java -cp ./65016.jar org.x6502.x65016.Lk65016 -bss \$00010000-\$EFFFFFFF -code \$0000fe00-\$0000FFFF -bin -output bootrom.bin bootrom.obj

The test program:

Code: Select all

        .hexfile

        .cpu T_32_M16
        .assume BIT32=1032, BIT32R=3210
        .include "i6502.a"

; I/O is memory-mapped in py65:
PUTC     = $f001
GETC     = $f005 ; blocking input

; our bootstrap ROM will only load to $0200
 .ORG $200

another
        lda GETC
        eor #$20   ; swap upper and lower case as a demo
        sta PUTC
        jmp another

Assembling the test program:

Code: Select all

./HXA_TW.EXE testprog.asm 
cat TESTPROG.HEX

which gives us

Code: Select all

;020000040000FA
;1202000000A5F005004900200085F001004C0200000025
;00000001FF

(of which we need to discard the first line)

And then we can spin up the emulator, load the ROM, feed in the hex, and then type in some text:

Code: Select all

$ PYTHONPATH=. python ./py65/monitor.py -m 65Org16

Py65 Monitor

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 00000000 0000 0000 0000 ffff 0000000000110000
.load bootrom.bin fe00
Wrote +512 bytes from $0000fe00 to $0000ffff

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 00000000 0000 0000 0000 ffff 0000000000110000
.goto fe00

Send 65Org16 code in variant Intel Hex format at 19200,n,8,1 ->
#

Download Successful!
Jumping to location $0200
*hELLOwORLD*

(The # is feedback to say one hex record was successfully loaded)

For reference: re-stating TT's example with some extraneous slashes to demarcate these fields:

Code: Select all

       │Record │ Record │ Load   │ Record │ Data │ Checksum │
       │Mark   │ Length │ Offset │ Type   │      │          │

Short standard 8-bit Intel record for a 32-bit wide address space looks like this starting at $FFFFE000:

Code: Select all

:/02/0000/04/FFFF/xx
:/08/E000/00/0001020304050607/xx
:/08/E008/00/08090A0B0C0D0E0F/xx
:/00/0000/01/FF

Then the 16-bit format with the novel ';' record start character looks like this:

Code: Select all

;/02/0000/04/FFFF/xx
;/10/E000/00/00000001000200030004000500060007/xx
;/10/E008/00/00080009000A000B000C000D000E000F/xx
;/00/0000/01/FF

teamtempest wrote:

Notice:
- the "record start" character changes from ":" to ";"
- the "data byte count" remains octet-correct
- the "address offset" is 16-bit correct

(*) an extension of Mike's
(**) based on Ross Archer's code

6502.org

65Org16 - beginnings of an emulator

65Org16 - beginnings of an emulator