6502.org

Posted: **Mon Feb 06, 2012 3:53 pm**

I thought I'd start a new thread here, since Bruce's announcement thread need not be cluttered with my thrashing around trying to get the software working.

The code works on Bruce's emulator, and on py65.

It doesn't quite work on my OHO module: it's failing to understand decimal constants, including line numbers.

Posted: **Mon Feb 06, 2012 3:55 pm**

Back on the FPGA now. Most variables seem to have random values, which I can use to do arithmetic with. (I know, I'm procrastinating):

Code: Select all

:PRINT U,V,M,E

1       5       1000    11

:PRINT ((U+U)*E*M)/(U+U+V)

3142

but I can't input any decimal constants (including line numbers). So, most of TinyBasic is presumably working. If I print a decimal string

Code: Select all

:PRINT "42"

42

the bytes coming back are as expected - no high bits set. Although of course they have gone through an 8-bit filter, so that's not much of a test.

Posted: **Mon Feb 06, 2012 3:58 pm**

Quote:

For the other errors, it looks to me like Z2C is either advancing too far or not far enough when parsing numbers (OP_BN). Are the upper bits of digit characters in the input buffer nonzero? (the BPL after the CMP #$3A and CLC could be as issue in that case)

I added instrumentation at the top of GET_BAS_DIG, to dump the A and Y values from

Code: Select all

      LDA (Z2C),Y

with the following results:

Code: Select all

000D 0000 :PRINT A

0050 0000 0050 0000 0050 0000 0050 0000 0050 0000 0052 0000 0049 0000 004E 0000 0054 0000 0020 0000 0041 0000 0041 0000 0041 0000 0041 0000 0041 0000 0041 0000 0041 0000 000D 0000 000D 0000 000D 0000 000D 0000 -17694720000D 0000 000D 0000 000D 0000 000D 0000 

:

000D 0000 :PRINT B

0050 0000 0050 0000 0050 0000 0050 0000 0050 0000 0052 0000 0049 0000 004E 0000 0054 0000 0020 0000 0042 0000 0042 0000 0042 0000 0042 0000 0042 0000 0042 0000 0042 0000 000D 0000 000D 0000 000D 0000 000D 0000 65535000D 0000 000D 0000 000D 0000 000D 0000 

:

000D 0000 :PRINT 2

0050 0000 0050 0000 0050 0000 0050 0000 0050 0000 0052 0000 0049 0000 004E 0000 0054 0000 0020 0000 0032 0000 0032 0000 0032 0000 0032 0000 0032 0000 0032 0000 0032 0000 0032 0000 0032 0000 

!293

so it does look like the digit '2' is correctly understood.

I borrowed a couple of routines from c'mon to do that:

Code: Select all

      PHP
      PHA
      JSR OUTHSP
      TYA
      JSR OUTHSP
      PLA
      PLP

Posted: **Mon Feb 06, 2012 4:37 pm**

A bit more instrumentation, to dump P just before GET_BAS_DIG returns:

Code: Select all

      PHP    
      PHA    
      TXA
      PHA
      TSX
      LDA $10002,X
      JSR OUTHSP 
      LDA $10003,X
      JSR OUTHSP 
      PLA
      TAX
      PLA
      PLP

shows us the shocking truth that carry is never set on exit:

Code: Select all

000D 0004 :PRINT 2

0050 0004 0050 0004 0050 0004 0050 0004 0050 0004 0052 0004 0049 0004 004E 0004 0054 0004 0032 0004 0032 0004 0032 0004 0032 0004 0032 0004 0032 0004 0032 0004 0032 0004 0032 0004 

!293

which starts to look like a CPU bug.

Trying a similar piece of code in py65 we see that $31 in A, then CMP #$30 should set the carry:

Code: Select all

$00002007  00c9 0030       CMP #$0030

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 00002007 0031 0000 0001 01ff 1000000000110000
.
$00002009  00ea            NOP

          PC      AC   XR   YR   SP   NV---------BDIZC
65Org16: 00002009 0031 0000 0001 01ff 0000000000110001

Here's the code:

Code: Select all

.assemble 2000
$00002000  00a9 0031       LDA #$0031    
$00002002  00c9 003a       CMP #$003a    
$00002004  0018            CLC      
$00002005  0010 e0f8       BPL $000000ff
$00002007  00c9 0030       CMP #$0030    
$00002009  00ea            NOP      
$0000200a  00ea            NOP      
$0000200b

(that branch target is meaningless - it's not taken)

Posted: **Mon Feb 06, 2012 5:11 pm**

Quote:

starts to look like a CPU bug

It works in simulation...
I'll try this snippet in c'mon on the FPGA.

Posted: **Mon Feb 06, 2012 5:12 pm**

BigEd, if I get you right, there's an issue of the 65Org16 core not setting the Carry flag during a CMP?

I know it is working for me. Having modified the ascii character output, for C'mon to output 2 characters per 16bit location, the code is something similar. This is just part of the slightly modified code to check for ascii...

Code: Select all

D2     LDA (NUMBER),Y ;output LSB character
       AND #$00FF
       CMP #$20
       BCC D3
       CMP #$7F
       BCC D4
D3     LDA #$7F ;output solid cursor character for non-printable char's
D4     JSR OUTPUT

Posted: **Mon Feb 06, 2012 5:42 pm**

Well, I've just this minute checked with a short program in c'mon:

Code: Select all

d00@a9,31,c9,30,a9,0,2a,4c,2dd,0,
d00g

and it works:

Code: Select all

which leaves me confused as to what's happening with TinyBasic.

That program is

Code: Select all

.assemble d00
$00000d00  00a9 0031       LDA #$0031
$00000d02  00c9 0030       CMP #$0030
$00000d04  00a9 0000       LDA #$0000
$00000d06  002a            ROL A
$00000d07  004c 02dd 0000  JMP $000002dd

assembled in py65 and using the OUTHSP routine from C'mon.

Posted: **Mon Feb 06, 2012 6:25 pm**

What happens if you run the same code in simulation ?

Posted: **Mon Feb 06, 2012 6:28 pm**

It worked... well, that was not the above snippet but the TinyBasic snippet.

Posted: **Mon Feb 06, 2012 6:38 pm**

So, it works in sim, but not on real hardware. Did you check your synthesis warnings ?

Posted: **Mon Feb 06, 2012 7:25 pm**

Gah! - it's all my fault - I've resynthed from a clean git checkout and reloaded the bitstream, and it is now behaving correctly!

The 65Org16 I had on the FPGA was possibly as old as Sep 5th. Perhaps I need to arrange that the ROM startup reports a version or a build date, or both. Or a version byte in a register or trivial peripheral.

Sorry for all the doubt and confusion.

6502.org

Tiny BASIC bringup on the 65org16

Tiny BASIC bringup on the 65org16