Original Progress Thread

Porting Richard Russell's BBC BASIC (Z80) to the TI-83+ and TI-84+ series calculators.

Moderator: benryves

Post Reply
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Original Progress Thread

Post by benryves »

This is a project I initially attempted to get off the ground about four years ago, but never did. Anyhow, I've started work on it, and thanks to help from Richard Russell (the original developer) and J.G.Harston (who comparatively recently developed the Sinclair ZX Spectrum port) it looks like it should be possible this time around. :)

BBC BASIC was the native programming language on Acorn's BBC Micro. It's a structured BASIC dialect and supports procedures and functions, permitting far nicer code than the line-numbered GOTO and GOSUB code on other contemporary machines. It also has a built-in assembler, for inline assembly.

There is no source available, which is where the problems start to come in. Fortunately, J.G.Harston has developed a utility that permits the platform-agnostic BBC BASIC interpreter to be relocated. However, it assumes that the system has a jump table in RAM from $FF80..$FFFF (this jump table would be used to call platform-specific code); this memory range is not executable on the TI-83+. Execution protection in the $C000..$FFFF range may also cause issues for inline assembly code (which is, naturally, executed from RAM).

The TI-OS does not offer an especially suitable environment for BBC BASIC either; it is mainly menu driven (a command-line driven environment is preferable), does not have a plain text editor and does not use ASCII. To resolve this issues, I've concentrated on developing a suitable environment for BBC BASIC to live in, including a command-line interface and text editor.

Image

Text files are stored as AppVars with a TEXTFILE header, and I've developed a Windows-based notepad clone for editing them (it saves and loads directly to and from .8xv). The following commands are currently supported (see here for a reference from the Windows verion): BYE, COPY, DELETE, DIR, ERASE, EXEC, QUIT, RENAME, TYPE, |.

To enter the editor, EDIT can be used. This presents a full-screen editor a little like the TI-OS program editor, but edits plain text files.

The interface transparently supports AT keyboards (which are rather easier to type on than the TI's keypad). The character resolution is 24 columns in 10 rows (4x6 pixel characters), giving you quite a lot of room to see what you're working on.

I intend on the final program being a 2-page Flash application; one page for BBC BASIC, and one page for the environment and OS interface. This unfortunately makes this a TI-83+ only project.

Even if I don't manage to shoe-horn BBC BASIC onto the TI-83+, the interface code (which uses direct hardware access for everything but opening and editing AppVars) could be useful for other projects.
User avatar
qarnos
Maxcoderz Staff
Posts: 227
Joined: Thu 01 Dec, 2005 9:04 am
Location: Melbourne, Australia

Post by qarnos »

That is uber cool :)

Are the text files all in one appvar with their own file system, or separate appvars?
AT keyboards (which are rather easier to type on than the TI's keypad)
Understatement of the year! :mrgreen:
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org

avatar courtesy of driesguldolf.
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

qarnos wrote:Are the text files all in one appvar with their own file system, or separate appvars?
Each file (as seen by BBC BASIC) is its own variable, which would allow them to be moved between archive and RAM. I was thinking of implementing *LOCK and *UNLOCK as commands to copy the AppVars to and from the archive.

I'm currently working on a better file handling system that will transparently support files in RAM and in archive via handles (with simple methods such as File.OpenRead, File.ReadByte, File.Seek, File.Close and so on). It should be easy enough to have any number of files open for reading, but I'm not sure how well things are going to work with multiple files open for writing, as the TI-OS only supports one file at a time. Opening the file for editing, appending a byte, closing it again and marking all existing handles as invalid (so the next time they are accessed the variable is looked up again, as RAM has been juggled). As files opened for editing hog all of the free RAM, they can't be left open in case BBC BASIC needs to allocate some memory for itself.
User avatar
tr1p1ea
Maxcoderz Staff
Posts: 4141
Joined: Thu 16 Dec, 2004 10:06 pm
Location: I cant seem to get out of this cryogenic chamber!
Contact:

Post by tr1p1ea »

Ahh so it has come to life (ive heard you talking about this project before). Great stuff ben, the text editor looks really nice.

Is that TI's font or your own?
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
Image
Image
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

The font is a mish-mash of the TI-OS one, the Windows Terminal font and my own fiddling around to get it to fit into 3x5 pixel cells. If you think you can improve on it, here's the current resource file:

Image

(Or, if you prefer; the .fon file - I use Fony).

ASCII ` is replaced by £, | appears as ¦ and 127 (DEL) should be a solid block (as far as I can tell by examining the BBC Micro font). The two sequences of block graphics characters are Teletext "sixel" graphics.

I've redone (nearly) all of the file handling code, which is now handle-based and can support multiple open files as well as transparent support for files from the archive. When a file is opened, the internal TI-OS name is preserved, so if a ROM call is known to shuffle memory around all handles are marked as dirty and the next time a dirty one is accessed it is automatically re-opened. This means that fun can be had with EXEC:

Image

The command file creates a new file, ABC, then opens it for editing. It then pauses before executing ABC, then quits.

When I run the command file, I enter DIR twice as the content for ABC, which it then runs before quitting. This demonstrates having multiple files open (FILE and ABC) as well as the system remaining stable even when memory has been rearranged (by editing ABC).

For writing files, I imagine one way that might work quite well is to make the open file 256 bytes (or so) larger than its data. As data is written, it goes into this 256 byte dummy space. If it runs out of this dummy space, it is opened for editing (by the TI-OS), inflated another 256 bytes, then closed again (and all old handles re-opened automatically after memory is reshuffled). When the file handle is closed, it is opened for editing once again, and any remaining dummy space is removed. This should hopefully allow for multiple files to be open for reading and writing with reduced CPU overhead.
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

I've started working with the actual BBC BASIC interpreter. As it won't run in its current state on the TI calculator (it relies on a jump table at $FF80..$FFFF to interact with the host, which is protected) I'm using an Z80 emulator I wrote to try and puzzle out what the interface should be doing from the relative sanity of C# code (the jump table is populated with OUT (nn), A instructions which are subsequently trapped and handled by the emulator).

Image

Another advantage of this strategy is that a Windows implementation that covers everything that the TI version covers can be developed alongside, so BBC BASIC programs could be edited/debugged on Windows before being transferred to the calculator.

One thing I hadn't realised is that the graphics operations that BBC BASIC offers are actually implemented via the OSWRCH handler (OS WRite CHaracter), which means that BBC BASIC's PLOT, MOVE and DRAW commands will also be available, as well as any commands that use them indirectly (such as CIRCLE).
Last edited by benryves on Thu 22 May, 2008 3:29 pm, edited 1 time in total.
User avatar
qarnos
Maxcoderz Staff
Posts: 227
Joined: Thu 01 Dec, 2005 9:04 am
Location: Melbourne, Australia

Post by qarnos »

Would it be difficult to rewrite the code to use a different jump table address?

The C000h limit is the single most annoying thing TI have ever done.
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org

avatar courtesy of driesguldolf.
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

J.G.Harston, the author of the Spectrum port, has written a relocator program that will take an existing compiled BBC BASIC interpreter image and patch it to change the addresses that it relies on. He is very kindly working on updating this program to be able to change the offset of the jump table.

If BBC BASIC assembles any inline assembly in the protected area, this too will trigger a crash. I suppose one workaround would be to have a "safe" mode that sets HIMEM (the upper exclusive memory bound) to &C000; leading to the further irritation that TI stuffed all their fixed system variables into the executable portion of RAM. 8.8KB is still a little more memory than the shareware versions of x86 BBC BASIC permit (8KB), though.
User avatar
Dwedit
Maxcoderz Staff
Posts: 579
Joined: Wed 15 Dec, 2004 6:06 am
Location: Chicago!
Contact:

Post by Dwedit »

Will this thing ever support RAM bankswitching on the 84+ or 83+SE?
You know your hexadecimal output routine is broken when it displays the character 'G'.
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

It's doubtful as far as I'm concerned, as BASIC assumes a flat memory model for RAM, and I own neither calculator so wouldn't be able to develop/test the software. (Nor do I understand the operation of these extra pages).

If it's possible to swap out memory to give a fixed, free 32KB memory map from &8000..&FFFF, then that would probably work very nicely (when BBC BASIC returns to the host, the 32KB that the OS assumes is there for its own use could be swapped back).

I'll try and get it working for the regular 83+ first; if that proves a success I'm sure someone gifted in the ways of the 83+SE would be able to modify the code. :)
User avatar
qarnos
Maxcoderz Staff
Posts: 227
Joined: Thu 01 Dec, 2005 9:04 am
Location: Melbourne, Australia

Post by qarnos »

benryves wrote:J.G.Harston, the author of the Spectrum port, has written a relocator program that will take an existing compiled BBC BASIC interpreter image and patch it to change the addresses that it relies on. He is very kindly working on updating this program to be able to change the offset of the jump table.
Wow! That's pretty good of him :D

This reminds me of a trick the old spectrum programmers used to use. They would set the IM2 table to $FF, and insert a JR at $FFFF. The first byte of the spectrum ROM was as DI ($f3), which would make the code jump to $fff4, where they'd put a JP to the service routine.

I wish we could do something like that with the calcs.
leading to the further irritation that TI stuffed all their fixed system variables into the executable portion of RAM.
Well, I guess you can forgive them for that, since this goes back to the 83-, which didn't have the C000 problem. But there was no real need for them to create this artificial obstacle in the first place :?
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org

avatar courtesy of driesguldolf.
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

A minor update; I've added the ability to inject keys into the input buffer, which can then be used by something that mimics the TI-OS CATALOG menu. Anything that calls Keypad.GetChar or Console.ReadChar (note my consistent naming conventions?) will get this functionality. :)

Image

The list is populated from the BASIC commands from here; I might have missed a few that don't appear in the Z80 version of BBC BASIC (some of those listed are Windows-specific).

Depending on how much space is left in Flash I'd like to add at least basic syntax help information for each command. Failing that, an optional help dictionary could be stored in the archive (a bit like the CtlgHelp app).
bfr
New Member
Posts: 22
Joined: Sat 02 Sep, 2006 8:39 pm

Post by bfr »

That looks really cool. 8)
User avatar
benryves
Maxcoderz Staff
Posts: 3089
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Richard Russell has very kindly sent me copies of the BBC BASIC relocatable object modules. As Brass doesn't use a conventional linker I am currently working through Microsoft's documentation for their M80/L80 assembler and linker for CP/M to work out the file format (done) and how I should be translating the addresses (getting there).

What this means is that BBC BASIC can be split up and spread around ROM and RAM in a fashion that will work with the TI-OS. :)
User avatar
tr1p1ea
Maxcoderz Staff
Posts: 4141
Joined: Thu 16 Dec, 2004 10:06 pm
Location: I cant seem to get out of this cryogenic chamber!
Contact:

Post by tr1p1ea »

Great stuff ... boy this project has like exploded with progress! (I wish mine moved this fast :S).
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
Image
Image
Post Reply