| Author |
Message |
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
 Posted: 04 Jun 2008 11:13:05 am Post subject: |
|
|
I'm posting here for advice and suggestions on design with a project that I've wanted to get onto the calculator for over four years now -- running Richard Russell's excellent Z80 version of BBC BASIC on the TI-83+.
  
BBC BASIC is much closer to conventional BASICs (unlike the built-in language in the TI-OS, which only bears a passing resemblance). Have no fears, though; even if it is a comparatively old language, it supports clean, structured programming techniques unlike the GOTO-riddled code of some of its contemporaries.
Here's quick, incomplete summary of some of the advatages over TI-BASIC (in no particular order:
- User-defined procedures and functions.
- Named variables; you're not limited to the predefined variables that the TI-OS gives you.
- Structured error handling.
- File I/O (which can be extended to device I/O).
- Integrated assembler, so if you need ultimate speed you can mix Z80 assembly directly into your BASIC program.
- Trace line numbers of programs as they run for easier debugging.
- Extensive library of built-in statements, covering some of the notable gaps in TI-BASIC (especially when it comes to patchy areas such as string manipulation).
- Low-level access to the hardware, including being able to read and write memory directly or call Z80 code by address.
On top of all this it's fast and easy to use. :)
Now, as you can possibly tell I'd really like this project to turn out well. I have posted some design questions on the main thread at MaxCoderz, but as this forum is busier and has more BASIC programmers I thought I'd ask for your advice here too.
My current line of investigation is how you feel files should be handled. I have posted what I plan here; to summarise how I think this should work:
I'm intending on using an extension to define the type of a file. For example:
- FILE.8XP - a named, variable-sized TI-OS program, shows up on the PRGM menu.
- FILE.8XV - a named, variable-sized TI-OS AppVar.
- PIC0.8XI - a numbered, fixed-sized TI-OS Pic variable.
- FILE.DEV - a device file.
I'm not sure whether using 8X?-type extensions is a good idea; what if there was a (theoretical) TI-83 port? Should I use .PRG, .VAR and .PIC-type extensions (or would that be confusing)? BBC BASIC doesn't typically use extensions; if I tried to open FILE for reading what should it do? Default to FILE.8XP?
As for .DEV files, here are the ones I intend on supporting (as I've already written the code to support them, so it's easy to copy):
- TILP.DEV - data over the TI's link port using the Texas Instruments protocol.
- AT.DEV - AT (PS/2) protocol.
- SIRCS.DEV - Sony IR remote control protocol.
- I2C:D0.DEV - I²C bus protocol (in this case, slave address $D0, DS1307 clock).
Anyway, I hope you can think of some suggestions or questions that'll help make this as good a programming language as possible for the 83+ series. 
Last edited by Guest on 04 Jun 2008 11:14:14 am; edited 1 time in total |
|
| Back to top |
|
|
Ed H
Member
Joined: 30 Nov 2007
Posts: 138
|
| Posted: 04 Jun 2008 11:38:20 am Post subject: |
|
|
Wow, that looks really great. I wouldn't know about the file types; I just program in BASIC. And from that point of view, one feature I'd find really useful is integer types. Most of the time in TI-BASIC one is forced to use floating-points numbers when faster and smaller 8-bit and 16-bit integers will do. I don't know whether or not this is a part of the original BBC BASIC, but regardless integer types would be a great feature.
Good work and good luck on the project! 
Last edited by Guest on 04 Jun 2008 11:39:50 am; edited 1 time in total |
|
| Back to top |
|
|
tifreak8x
Elite
Joined: 27 Aug 2005
Posts: 956
|
| Posted: 04 Jun 2008 11:39:04 am Post subject: |
|
|
| Look nice. Out of curiousity, will there be any memory restrictions? Will it be able to call the code directly from Archive? |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 04 Jun 2008 12:27:55 pm Post subject: |
|
|
Ed H wrote: And from that point of view, one feature I'd find really useful is integer types. Most of the time in TI-BASIC one is forced to use floating-points numbers when faster and smaller 8-bit and 16-bit integers will do. I don't know whether or not this is a part of the original BBC BASIC, but regardless integer types would be a great feature. The Z80 version of BBC BASIC supports 32-bit integers and real numbers. I haven't done any proper benchmarking of BBC BASIC's performance yet, but it certainly feels a lot faster than the TI-OS's handling of real numbers.
If you need to store data as bytes (for space rather than performance reasons) you can allocate an area of memory using DIM, then access the memory via the [url="http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin2.html#query"]? operator[/url].
tifreak8x wrote: Out of curiousity, will there be any memory restrictions? Will it be able to call the code directly from Archive? Well, there's one of the problems. BBC BASIC requires 768 bytes of 256-byte-aligned memory for its scratch space, and the TI-OS does not let code execute from $C000 and above. This means that from $9E00..$A0FF is BASIC's scratch space, and $A100..$BFFF (maximum) is memory used for variables, loaded programs and so on. This is a maximum of 7936 bytes for BASIC programs to live in (this is at runtime; the actual programs can be stored outside this area - in the archive or in RAM above $C000 - and are copied into BASIC's memory as required).
On the plus side, this does leave space for new programs to be created and grow, but does rather restrict BASIC a little. What I was planning was that this would be the default behaviour, and a BASIC programmer could choose to restart the environment (from the BASIC program itself) with a set of requirements. For example, if they were not going to create new files and didn't use any inline assembly they could restart the environment to use as much of the calculator's free RAM as possible. Alternatively, if they only had a very small program and wanted to do more with file manipulation they could restart the environment and only allocate a small amount of memory for BASIC.
Another option is if the TI-83+ SE and above lets you map its extra "unused" memory to $8000..$FFFF and lets you execute code from it, to have an SE-only version that used the full 32KB that was available to it. Not owning an SE, though, I can't comment on the possibility of such a version.
Last edited by Guest on 04 Jun 2008 12:34:11 pm; edited 1 time in total |
|
| Back to top |
|
|
magicdanw
pcGuru()
Calc Guru
Joined: 14 Feb 2007
Posts: 1110
|
| Posted: 04 Jun 2008 01:11:59 pm Post subject: |
|
|
| I think this project looks great! The editor I've seen in screenshots looks really nice too. Maybe you would consider releasing the code for it (if it's at a stable place), because I or someone else could try adapting it as a replacement for the TI-BASIC editor. |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 04 Jun 2008 01:45:30 pm Post subject: |
|
|
magicdanw wrote: The editor I've seen in screenshots looks really nice too. Maybe you would consider releasing the code for it (if it's at a stable place), because I or someone else could try adapting it as a replacement for the TI-BASIC editor. I'm not sure if that would work too well unfortunately. The editor I've written only edits plain text files using ASCII encoding; BASIC programs (be they TI-BASIC or BBC BASIC) programs are tokenised and so cannot be edited as easily.
For the sake of BBC BASIC I was going to try to write a program that would convert to and from ASCII and BBC BASIC programs (so they could then be edited; this could be done automatically when opening a file to edit). |
|
| Back to top |
|
|
Taricorp
Member
Joined: 09 Mar 2006
Posts: 188
|
| Posted: 04 Jun 2008 03:42:30 pm Post subject: |
|
|
To actually answer the query, I would prefer .PRG, .PIC, etc extensions to .8XP and such.
Also, that's looking amazing. |
|
| Back to top |
|
|
TheStorm
Calc Guru
Joined: 17 Apr 2007
Posts: 1233
|
| Posted: 04 Jun 2008 04:37:59 pm Post subject: |
|
|
Taricorp wrote: To actually answer the query, I would prefer .PRG, .PIC, etc extensions to .8XP and such.
Also, that's looking amazing.
[post="124235"]<{POST_SNAPBACK}>[/post]
Yeah I agree .prg, .pic. etc would be better that way if it were ported to say the ti-86:)
things would be less of an issue.
@tari if hey gets this done you may be able to add this into LIFOS as a ti-basic replacement though at two pages it is pretty large.
Last edited by Guest on 04 Jun 2008 04:57:14 pm; edited 1 time in total |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 04 Jun 2008 05:09:14 pm Post subject: |
|
|
| BBC BASIC itself is only about 13KB in ROM. However, there's no way I'd be able to fit all the host interface code into 3KB (file handling code, graphics routines, console I/O, text editor, ...) so it does spill over onto a second page. |
|
| Back to top |
|
|
TheStorm
Calc Guru
Joined: 17 Apr 2007
Posts: 1233
|
| Posted: 04 Jun 2008 05:12:30 pm Post subject: |
|
|
| well if it were just an interpreter would it fit? If you could separate the console and just have the interpreter for people who aren't interested in making programs of their own but would like to have that option, and also since you can edit them on the computer you don't need the on-calc editor/console. You could just list the programs like a shell would. |
|
| Back to top |
|
|
magicdanw
pcGuru()
Calc Guru
Joined: 14 Feb 2007
Posts: 1110
|
| Posted: 04 Jun 2008 05:19:53 pm Post subject: |
|
|
| I'm afraid I don't understand the issue of the file extensions. On the calculator, can't the programs only be, well, program files? When transfered to the computer, won't they always be 8xp files, no matter what extension you give them? Changing the extension won't make it transferrable to another calculator model... |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 04 Jun 2008 05:39:34 pm Post subject: |
|
|
TheStorm wrote: well if it were just an interpreter would it fit? If you could separate the console and just have the interpreter for people who aren't interested in making programs of their own but would like to have that option, and also since you can edit them on the computer you don't need the on-calc editor/console. By the "console" I refer to the thing that handles text input and displays text output, not the utilities such as the editor (which is a perk). BBC BASIC relies on a certain amount of basic functionality from the host interface, such as routine to input a line of text. As the TI-OS cannot be used for this (wrong character set for starters) all these routines have to be recreated. Code to handle BBC BASIC's graphics output also needs to be written, as a programming language that only lets you input and output text isn't going to be all that exciting from a games perspective. All this takes room, sadly.
magicdanw wrote: I'm afraid I don't understand the issue of the file extensions. On the calculator, can't the programs only be, well, program files? When transfered to the computer, won't they always be 8xp files, no matter what extension you give them? Changing the extension won't make it transferrable to another calculator model... Well, the issue is that there's more to calculator files than programs. What if the user has a program called FILE and an AppVar called FILE; how would BASIC know which to open when you tried to OPENIN "FILE"?
For example, you might wish to write a program that copied the display buffer to the picture variable Pic1. You could do it like this:
Code:
10 GBUF = &9340
20 PIC = OPENOUT "PIC1.PIC"
30 FOR I = 0 TO (EXT# PIC) - 1
40 BPUT# PIC, GBUF?I
50 NEXT I
60 CLOSE# PIC
Internally, the TI-OS uses a single prefix on variable names to denote their type. This isn't very intuitive from the perspective of the BASIC programmer, and so I was thinking of representing different file types with different extensions (which should be familiar to most people).
This isn't so much for identifying programs you simply wish to run -- it's to identify files that are created and read from within BASIC programs.
Last edited by Guest on 04 Jun 2008 05:40:37 pm; edited 1 time in total |
|
| Back to top |
|
|
Ed H
Member
Joined: 30 Nov 2007
Posts: 138
|
| Posted: 04 Jun 2008 11:46:53 pm Post subject: |
|
|
| Honestly, I'd prefer to denote the type of a variable with prefixes like $. But for file extensions, .PRG, .PIC, .VAR and the like would definitely be the least confusing. |
|
| Back to top |
|
|
magicdanw
pcGuru()
Calc Guru
Joined: 14 Feb 2007
Posts: 1110
|
| Posted: 05 Jun 2008 01:10:56 pm Post subject: |
|
|
| Oh, I see. I know about how variables are defined by their type byte, like 5 for ProgObj, but I thought you were talking about the PC file extensions. Sure, that sounds like a fine idea. |
|
| Back to top |
|
|
elfprince13
Retired
Super Elite (Last Title)
Joined: 11 Apr 2005
Posts: 3500
|
| Posted: 05 Jun 2008 01:31:43 pm Post subject: |
|
|
| .PRG, .PIC .VAR, etc sound good to me, although you should support the full range of TI-OS files. |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 05 Jun 2008 03:37:29 pm Post subject: |
|
|
The difficulty with the other formats is that they are very TI-OS specific; there is no provision within BBC BASIC for manipulating them -- file access is at the byte level.
That's not to say that you shouldn't be able to open them for access, though. There are a number of ways of extending the built-in functionality (* commands, assembly entry points) that can be used to add functionality, and helper routines could possibly be added. It's not going be be as elegant as accessing the variables directly from the TI-OS, but it might just work. |
|
| Back to top |
|
|
Harrierfalcon
The Raptor of Calcs
Super Elite (Last Title)
Joined: 25 Oct 2006
Posts: 2535
|
| Posted: 06 Jun 2008 09:14:29 am Post subject: |
|
|
Hm...
A careful look at the commands makes this look like a command-prompt and TI-Basic hybrid. Interesting.
I'd be more than happy to test any betas you come up with  . This looks pretty sweet! |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 06 Jun 2008 10:43:21 am Post subject: |
|
|
Not all features mentioned on the BBC BASIC website are available in the Z80 version, as the Windows version extends the language further. Most are, though. Some conspicuous differences are WHILE loops (REPEAT is still available, though) and some of the drawing keywords -- all drawing operations are available through MOVE, DRAW and PLOT, but the Windows version of BBC BASIC also supports statements such as LINE or CIRCLE that are a bit more intuitive.
Although the original BBC Micro user guide makes reference to several BBC Micro-specific features it's a bit closer to the what the Z80 version of BBC BASIC supports. There's a keyword list here.
This sort of thing is going to be a bit confusing for people trying to learn the language, so comprehensive documentation is going to be required.
As Z80 BBC BASIC is the copyrighted property of Richard Russell (and is/was itself a commercial product), I would like to make sure that he has the opportunity to check the package before it is released to the community (either for beta testing or on general release).
To speed up this process, it might be more sensible to strip out as many of the "optional" features as possible -- no graphics, no on-calculator editor, no device I/O -- (programs are editable from the line-number based editor within BASIC anyway) and concentrate instead on compiling a release package (documentation, sample programs, licence information), verify that it's safe to release, then add the extra parts over time.
Edit: Well, I've been busy recently so not had much time to work on this, but here's a little example of how the file manipulation statements could be used to - in this case - create a Pic variable.
(GBUF=&9340 - plotSScreen, the graph buffer, is located in memory at 9340h).
Last edited by Guest on 06 Jun 2008 07:53:58 pm; edited 1 time in total |
|
| Back to top |
|
|
Harrierfalcon
The Raptor of Calcs
Super Elite (Last Title)
Joined: 25 Oct 2006
Posts: 2535
|
| Posted: 07 Jun 2008 08:48:46 am Post subject: |
|
|
I can't wait until you get this finished . Looks awesome!
Just a side note: [2nd][PRGM][>][>][2] leads to the RecallPic token, and you really only need to put the number of the pic as an argument, not the pic variable itself.
Pardon me >_<.
What was that funky symbol on line 4? After BPUT.
Last edited by Guest on 02 Aug 2010 01:55:25 am; edited 1 time in total |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 07 Jun 2008 09:24:47 am Post subject: |
|
|
Harrierfalcon wrote: Just a side note: [2nd][PRGM][>][>][2] leads to the RecallPic token, and you really only need to put the number of the pic as an argument, not the pic variable itself. Cheers, I'm not really all that good with getting around the TI-OS (or, indeed, the key mapping on emulators, hence my cack-handed typing in the screenshots). :)
Quote: What was that funky symbol on line 4? After BPUT. Ah, the joys of being restricted to 3x5 pixel characters. It's meant to be a #, which is used to denote a file handle in several BASIC dialects. Aside from its use in the file-specific statements, INPUT reads a value from the console and PRINT writes a value to the console; INPUT# reads a value from a file handle and PRINT# writes a value to a file handle.
If you think you can improve on the font, you can download it here (Fony is a decent free font editor).
Here's an example of using the inline assembler to mix assembly code into a BASIC program (and you don't have to suffer me typing it in line by line!)
(*Insert usual disclaimer about it looking smoother on hardware*).
Code:
10 DIM SCROLL% 3
20 P%=SCROLL%
30 [
40 OPT 0
50 OUT (16),A
60 RET
70 ]
80 REPEAT
90 A%=&40+(TIME MOD 64)
100 CALL SCROLL%
110 UNTIL INKEY(0)>0
120 A%=&40:CALL SCROLL%
- DIM SCROLL% 3 allocates 3 bytes of memory and stores a pointer to it in SCROLL%.
- P%=SCROLL% sets the program counter for assembly output to this pointer.
- OPT 0 disables the assembler's text output.
- CALL SCROLL% loads A% into the accumulator (and other registers as applicable) and CALLs the Z80 assembly code previously generated and pointed to by SCROLL%
Last edited by Guest on 02 Aug 2010 01:55:04 am; edited 1 time in total |
|
| Back to top |
|
|
|
Project Ideas/Start New Projects => Your Projects
