Tiny BASIC for the 65org16

dclxvi · Post by **dclxvi** » Wed Feb 01, 2012 3:10 am

I've got a port of Tiny BASIC for the 65org16 working on the simulator. As always, available here:

http://www.lowkey.comuf.com/

The labels still have a bunch of disassembly artifacts, so I may clean them up a bit in the near future.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Feb 01, 2012 2:51 pm

I'll try this out soon, hopefully by next week. In the meantime I'll read up on the User's Manual and Experimenter's Kit...

How big is your ported version?

dclxvi · Post by **dclxvi** » Thu Feb 02, 2012 2:57 am

It's under 9 pages (not counting input and output routines) -- a little bit smaller than the 6502 version. By default, the user area (where programs are stored) starts at $2900 (i.e. just after Tiny BASIC itself), but you can change that by changing the G2900 label.

The User Manual describes the 6809 version which is assembled at $100, so (e.g.) address 106 in the User Manual is address $2006 on the 65org16 (unless you change the .org). Beyond that, it should be fairly straightforward.

BigEd · Post by **BigEd** » Thu Feb 02, 2012 9:20 pm

Another nice one Bruce! Got it running in py65, with the usual tweaks to accommodate the i/o routines and a fix to halt the memory check at a suitable limit.

Edit: Bruce's site is offline at present, so here's an archive.

Code: Select all

$ PYTHONPATH=py65/src python py65/src/py65/monitor.py -m 65Org16 -l TBO16.bin -g 2000 
Reset with new MPU 65Org16
Wrote +10478 bytes from $00000000 to $000028ed

:10 PRINT 22000/7
:20 END
:LIST

10 PRINT 22000/7
20 END

:RUN
3142

:

The memory check could run into a mirroring problem presumably, especially on fpga: it might be useful to check for that. Here's a quick hack:

Code: Select all

La0   LDA (Z22),Y  ;; read location

      CMP $0       ;; check for wraparound
      BNE nowrap1
      ;; slight suspicion - check thoroughly
      INC $0       ;; perturb
      LDA $0
      CMP (Z22),Y
      BNE nowrap2
      DEC $0       ;; restore
      ;; we did wraparound - $0 is the same location as (Z22),Y
      DEY
      JMP OP_MT    ;; jump out of the memory test

nowrap2:
      DEC $0       ;; restore
      LDA (Z22),Y
nowrap1:

      TAX
      EOR #$FF
      STA (Z22),Y  ;; store complement
      CMP (Z22),Y  ;; see if it changed

As memory generally comes in round-number sizes, and presuming that we start the check at a round-number boundary, I'm tempted to speed up the check by not checking every byte. However, probably the check doesn't take much time in reality - only in emulation.

Code: Select all

      STA (Z22),Y  ;; put back the value
      ; INC Z22
      LDA #$80     ;; we don't need to check every byte
      CLC
      ADC Z22
      STA Z22

(Edit: this doesn't work as written: the initial value of Y needs to be $80 too, and the final DEY needs to be LDY #0. Then we're left with a detected top of memory which is 127 bytes short.)

(I'll correct any errors - just let me know!)

Cheers
Ed

BigEd · Post by **BigEd** » Fri Feb 03, 2012 7:49 pm

No doubt I've done something wrong(*), but I thought you'd be interested in first light: I dusted off my OHO spartan-3 module and loaded and ran this TinyBASIC port on the FPGA:

Code: Select all

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

################################################################################################################################################



Download Successful!

Jumping to location $0200



:

:

:print 4



!184

:PRINT 4



!293

[snip]
:PRINT "hi"

hi

:

:PRINT 22000/7



!293

As you see: partial success. I may well have broken the memory test. I'll put it back to the original, have a look, and update this post.

Edit: Hmm, 293 means "Syntax error in expression - expects value" - my line-ends are 0x0d as sent down the line. What else would be syntactically wrong?
Edit: more pedestrian memory check acts the same.

(*)Edit: yes, I did something wrong - wrong CPU revision! Now working.

dclxvi · Post by **dclxvi** » Sat Feb 04, 2012 7:13 pm

BigEd wrote:

The memory check could run into a mirroring problem presumably, especially on fpga: it might be useful to check for that.

I'm not personally wild about the memory scan. In addition to mirroring issues, there could be an I/O location at the end of RAM. I was tempted to replace the memory scan with a fixed (.equ) value and store that in Z22. I had jotted down a few other things that could be done in a 2.0 version of Tiny BASIC (such as not spewing all those control characters), but in the end I kept the 1.0 65org16 version as close as possible to the 6502 so that things wouldn't get out of hand. So the memory scan survived.

Since my emulator acts like a pre-loaded 32 x 16-bit RAM (essentially the A31 to A15 "pins" are not "connected"), the memory scan won't work (it'll wrap and either clobber itself or go haywire when Z22 gets overwritten). So I load Tiny BASIC and then patch it to set Z22 to a fixed address and skip over the memory scan. It's pretty much the idea described in the User Manual (the paragraph before the STATEMENTS section), but the first command need not be CLEAR since I skip to OP_MT rather than OP_WS (as jumping to $2003 would do).

I'm not planning on making a 2.0 version (it certainly wouldn't be high priority). I'll leave the memory scan in 1.0, but by all means feel free to replace it.

BigEd wrote:

As you see: partial success.

Tiny BASIC is case sensitive, so lower case print giving an error is expected. 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'd recommend dumping Z2C in the loop of the OP_BN routine. Another way to trace things is output the X register, Z2A, and Z2C at G20FC (and preserve the P register -- some OP_ routines depend on the carry value, I think), and you should be able to watch Tiny BASIC work its way through the TBIL code and your statements/program.

If you've changed the .org or any of the Z labels, it should work, but it's possible I've missed something, so you might want to check any instructions with immediate addressing. I've only done quick tests with those sorts of changes, nothing extensive, though. It's also possible that something might not work if you put labels in different order (e.g. Z82 at a lower address than Z80), though it's not supposed to be that way.

Beyond that, nothing else comes to mind other than the usual sanity/weirdness check, e.g. are any of the addresses $2x-$Cx (or wherever the Z labels are) not RAM for whatever reason?

BigEd · Post by **BigEd** » Mon Feb 06, 2012 2:30 pm

Thanks for the tips. Quick update: this version is built to load at $200. I just checked, and it does run in py65, so it isn't the relocation at fault. I've got C'mon running on the fpga now. So I need to put those two things together and use the monitor to see where the problem lies (or, do as you suggest, and start adding instrumentation into tinybasic itself)

It only takes 10s or so to load the monitor as a hex package, so even without having it at reset time, it's pretty much there when I want it. (The system resets into the hex loader, and I don't feel like rejigging the boot ROM right now, although that would be a step forward.)

Cheers
Ed

BigEd · Post by **BigEd** » Mon Feb 06, 2012 3:28 pm

Moved my bringup meanderings to a new thread to remove clutter.

BigEd · Post by **BigEd** » Mon Feb 06, 2012 7:55 pm

Apologies - my trouble with the bringup on 65Org16 was all my own fault, for using an old CPU which was already in the FPGA and assuming it would be OK.

Tiny Basic now runs nicely, and reports 4k as the top of memory, as expected:

Code: Select all

:PRINT USR(831,34)
4095

It can also list and run a program:

Code: Select all

:LIST
10 PRINT 22000/7
20 PRINT "Pi!"
30 END
:RUN
3142
Pi!

(I'm getting stray newlines but not to worry about that - typical line-end convention nonsense.)

Something goes wonky with the RND() function though:

Code: Select all

:PRINT RND(100)

-45

:

d--

d--

and so on, repeating a nonsense non-prompt until reset. Which doesn't happen in emulation. So perhaps I need to revisit the bringup thread - but probably not tonight.

ElEctric_EyE · Post by **ElEctric_EyE** » Mon Feb 06, 2012 11:07 pm

Excellent work BigEd! On my way home from work, just thought I'd throw this out there:

It is one of my little goals now that we have a version of Basic to get this Mandlebrot program made by Bob Bishop for the Apple to work on the 65Org16.

I guess in order for the plotting portion, we would have to use the USR function to call an assembly routine?

I know TinyBasic does not have the ability for Arrays, does the Basic portion of Bob's program use arrays?

BigEd · Post by **BigEd** » Tue Feb 07, 2012 7:00 pm

Special bonus from a 16-bit machine: TinyBasic has 32-bit arithmetic:

Code: Select all

:A=32768
:B=65535
:C=A*B
:PRINT A,B,C
32768   65535   2147450880
:PRINT C+A
-2147483648

Yes, you'd use USR to call a plotting routine. I don't believe you need arrays. (If you're about to embark on an adventure, can I suggest a new thread?)
Cheers
Ed

dclxvi · Post by **dclxvi** » Wed Feb 08, 2012 3:34 am

ElEctric_EyE wrote:

I know TinyBasic does not have the ability for Arrays, does the Basic portion of Bob's program use arrays?

Listing 4 (the lo-res version) does, but only to select a color. It could easily be replaced by a few IF statements. However, a more significant issue is that both Listing 4 and Listing 5 make use of floating point arithemetic, which Tiny BASIC lacks (or fixed-point arithmetic either, which would work just as well). One approach would be to write the remaining fixed point routines (division and conversion) you'd need in assembly, and recode the BASIC programs in assembly.