Original Progress Thread

[benryves]

In this case, I haven't actually written the documentation. It's pretty much a copy-and-paste job from the BBCBASIC(86) documentation, with x86/DOS-specific stuff removed and replaced with Z80/TIOS-specific stuff. Richard Russell seems happy with this arrangement, which certainly makes life a lot easier for me.

[Timendus]

You're one of the few people that writes decent documentation ... *hides* .

Hey!

[benryves]

With some assistance with the undocumented ROM calls from BrandonW, I've added support for the TI-84+'s real-time clock. It is accessed via the pseudo-variable TIME$ (a string), and can be read from or written to to retrieve or set the time and date.

A minor bug in WabbitEmu (that has been fixed since the screenshot was taken) meant that any time entered was offset by how long WabbitEmu had been running, so ignore the time being set incorrectly. As you can see, you can update either the time or date component (or both) at a time.

Some questions; what should it do if you feed it in an invalid date? Other versions of BBC BASIC ignore errors (but the time may be set incorrectly) which I feel is probably the best way to do it.

The other issue is what to do on the TI-83+ calculators, without the realtime clock. Three options present themselves:

• Trigger an error when trying to read or write the time, as no clock is available.
• Allow the user to read or write the TIME$ string, which would be static. This would allow people to work out the day of the week a date falls on by setting $TIME then reading back the day of the week component.
• Implement a clock and calendar using the timer interrupts. This would provide at least rudimentary time-keeping functions, even though the actual time and date would not be updated when BBC BASIC was not running and would be very inaccurate.

More clock information may be seen here.

[benryves]

I spent most of the weekend looking for a bug in my code - a procedure kept failing with a No such variable error, where the variable clearly was defined. This usually means that an important register or piece of memory is being overwritten, so I went over all the code trying to find it - to no avail.

Turns out the PC-based tokeniser (that turns text into BBC BASIC binary programs) was tokenising PI as "P" then "I", rather than the PI token. It was also tokenising ENDPROC as two distinct tokens, END and PROC, hence the weirdness!

Well, that now works, and the above shows a simple analogue clock program. There have been a few other fixes (AF' is backed up correctly when switching to TIOS code, a program error repaints the display when *REFRESH OFF has been issued previously, copy key editing works again - it had been broken adding the graphical text mode).

Here's the source code for the analogue clock program.

Code: Select all

   10 *REFRESH OFF
   20 VDU 29,48;32;
   30 GCOL 0,128
   40 REPEAT
   50   t$=TIME$
   60   hour%=VAL(MID$(t$,17,2))MOD12
   70   min%=VAL(MID$(t$,20,2))
   80   sec%=VAL(MID$(t$,23,2))
   90   sec=sec%/60
  100   min=(min%+sec)/60
  110   hour=(hour%+min)/12
  120   CLG
  130   GCOL 0,127
  140   MOVE 0,0
  150   PLOT 153,31,0
  160   GCOL 0,0
  170   FOR h=1TO12
  180     hA= h/6*PI
  190     hX=30*SIN(hA)
  200     hY=30*COS(hA)
  210     MOVE hX,hY
  220     DRAW hX*0.9,hY*0.9
  230   NEXT h
  240   PROC_drawHand(sec,30)
  250   PROC_drawHand(min,24)
  260   PROC_drawHand(hour,16)
  270   *REFRESH
  280 UNTIL INKEY(0)<>-1
  290 *REFRESH ON
  300 END
  310 DEF PROC_drawHand(pos,length)
  320 MOVE 0,0
  330 pos=pos*2*PI
  340 DRAW length*SIN(pos),-length*COS(pos)
  350 ENDPROC

Edit: The clock now works on an 84+ (uses the hardware clock, accurate) and the 83+ (uses a software clock using timer interrupts, inaccurate).

[tr1p1ea]

Great work ben! This is now allowing for some pretty neat stuff to be done rather easily.

Sucks that the 83+ doesnt have a hardware clock, but what can you do eh? . In the example i especially like how the minute hand creeps as the seconds close in on a full minute .

[b-flat]

w00t; I am glad that I have found MaxCoderz again (I had thought that the site had simply disappeared until I posted about it on Cemetech).

Now, more importantly, when will we be getting a beta / demo?

[benryves]

"When it's done". It's getting there, slowly. 95 keywords are documented!

I'm currently working on the VDU emulator (this handles VDU commands, eg VDU 30 to move the cursor to the top-left of the window). Quite a few features were missing!

[benryves]

In relation to the documentation, I've started writing a little utility that will compile MediaWiki documentation into a CHM file.

How good is CHM support outside of Windows? A Wiki is not the best way to release copyrighted information, so whilst it's quick for me to use to generate the documentation I'm not sure I'd be happy to have it publicly accessible.

[GuillaumeH]

I have already used xCHM once under linux, it works well and is available is most distros' repositories.

[benryves]

That's good to hear. The documentation is nearly complete.

I've made a few more bugfixes and additions;

• The graph buffer is cleared properly when starting.
• GCOL colour is an acceptable alternative for GCOL mode,colour (sets mode to 0, plot).
• *DELETE (as well as its abbreviated form and synonyms *DEL, *ERASE and *ERA) can be used to delete files.
• CLG clears the screen with the logical operation specified in mode.

The last one is quite interesting. CLG is used to clear the graphics window, and previously it would just replace the existing data with the background colour. GCOL can be used to specify a plotting mode - 0=plot (replace colour), 1=OR, 2=AND, 3=exclusive-OR or 4=invert - so now this code:

Code: Select all

GCOL 4,0
CLG

...inverts the graphics window rather than clearing it.

There is one problem, though; space. BBC BASIC is already a two-page application, and though there are features I'd like to add they won't fit in the 1KB space I have left. Would people object to a three-page application?

[b-flat]

I personally think that the extra features should be worth it, so go ahead and make it a 3-page app.

However, if size is a big concern, why don't you release two separate versions (one with a few features missing so i can be kept to 2 pages and one with everything you want)?

[benryves]

That is always possible, though having a single version is preferable if possible.

Memory allocation is still a bit of a worry. Currently it will allocate as much memory between &A100~&BFFF as is available for BBC BASIC's use, which imposes a limit of 7936 bytes. The reason for this is that you cannot execute machine code in the memory range &C000~&FFFF, and as BBC BASIC has an inline assembler I'd like to avoid the potential problem of people loading assembly code into his region. However, even though this is safer, it does impose a rather pathetic memory limitation!

On the other hand, if all RAM was allocated to BBC BASIC, you wouldn't be able to create new files in your program.

There is, therefore, a tradeoff between safety for assembly programmers and leaving free space in the OS for new files.

An option would be to have a star (OS-level) command that restarts BASIC with a different view on memory (defaulting, however, to the safe mode capped at &BFFF described above). Maybe something like this:

• *MEMORY SAFE - Safe memory mode, up to &BFFF.
• *MEMORY RESERVE 5000 - Use all but 5000 bytes of RAM.
• *MEMORY CAPPED 2000 - Only use a up to 2000 bytes of RAM for BASIC.

(The last example, CAPPED, would be useful if you intended on creating large files but only had a small BASIC program).

Such commands would have to be at the start of your program, as they would force the BASIC environment to restart. I don't know whether such a thing could be automated, though, these are just ideas.

Come to think of it, maybe there should just be RESERVE and CAPPED, with SAFE being an optional modifier for both of them..!

[tr1p1ea]

I wouldnt mind a 3-page application at all. And damn TI for the $C000 limit :\.

[benryves]

Three pages it may well end up being, then. It's still fitting on two for the moment.

All of the programs I've run so far have been quick and simple test apps, nothing like a real-world program. To remedy this I threw together a quick and incomplete Lights Out game.

The levels were extracted from the Blink level file. The program and its source code are available if you'd like to get an idea of how BBC BASIC could be used. The program is compatible with BBC BASIC for Windows if you'd like to try it on your own machine, but the different colour palette means that the game appears inverted and different coordinate system means the game appears small and upside down. It still plays well, though! (Cursor keys to move, Enter to toggle).

To get this to work, I had to implement INKEY(n) where n is less than zero. This allows the BASIC program to poll the state of keys directly (rather than read a letter; this allows for non-printable keys, such as the cursor keys, to be read, as well as supporting multiple presses at once). The slightly odd constants in the FN_getGameKey function are relics of the BBC Micro keyboard layout. I'm wondering if it would be a good idea to allow TI-OS-getKey-style key values offset by a large amount (eg -10043 for PRGM, usually 43).

[benryves]

Each PLOT mode has four different ways of colouring the shape; invisible, foreground, inverse and background colour respectively. For example, PLOT 5 draws a line in the current foreground colour, PLOT 6 draws an inverting line (so black pixels underneath it turn white and white pixels underneath it turn black) and PLOT 7 draws a line in the current background colour.

I hadn't actually implemented this (a bit of an oversight) and the colours and plotting modes were only being set by GCOL and from then all only used the foreground colour.

I have reworked quite a large chunk of the graphics code to support this, as well as adding the flood-filling code and single-pixel plotting operations.

I'm thinking that adding a way for users to define their own fill patterns may be useful. Currently implemented plot codes are in the range 0-71, 96-103, 128-159, 192-207, with a sprite extension at 208-215. Notable omissions are:

• Horizontal line fill to non-background.
• Plot and fill a triangle.
• Horizontal line fill to background right.
• Horizontal line fill to foreground.
• Plot and fill a parallelogram.
• Horizontal line fill to non-foreground right.
• Draw a circular arc.
• Plot and fill a segment.
• Plot and fill a sector.
• Move a rectangular block.
• Copy a rectangular block.
• Swap a rectangular block.

Quite a few, sadly. The move/copy/swap rectangular block operations may be useful for scrolling, so I may try and implement those. Triangle filling (and, by extension, parallelogram filling) would be nice but I'm stumped on the filling. Partial circles (arcs, segments and sectors) are utterly beyond me at the moment.

I've added a section to the documentation entitled BBC BASIC for TI-OS Programmers that discusses the BBC BASIC equivalent of the various statements that are provided for programming by the TI-OS.