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.

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?

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.

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.



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:

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.


(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

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:

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.

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.



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?

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

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

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:



It can also list and run a program:

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

Something goes wonky with the RND() function though:

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.

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?

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

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

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.