Original Progress Thread

[b-flat]

Wow; I just noticed this project and it looks amazing!

Anyway, would it be possible to get a release out? I'm going on a road trip for two weeks starting on Saturday, so I want to have it to test out (and learn BBC Basic) in the car...

[benryves]

As much as I'd like to, I think Saturday would be rather optimistic. I would need to get documentation written and checked by the author before I released this, as it is based on commercial software and I need to ensure that I'm not violating any copyrights (otherwise I would have been releasing beta versions as I went).

Sorry to disappoint you, but if it's any consolation I don't think anyone else will have a head-start over you -- even three weeks is pushing it.

Thanks for the comments and enthusiasm!

[qarnos]

VDU 5 lets you use the graphics cursor to position text anywhere on screen; this rather nicely brings me onto the next thing I've added, sprites.

If you are trying to make Ti-BASIC obsolete (relatively speaking), then you are going the right way about it.

Good job!

[benryves]

Thank you.

I've been pondering a way to add assembly libraries to BBC BASIC. There's a CALL statement that lets you CALL a particular address, passing parameters (the Z80 code is handed a pointer to a table of parameters in IX). It doesn't let you return values, but as the arguments are effectively passed by reference this shouldn't be a problem. Maybe it could work something like this?

Code: Select all

10 *LOADLIB "SCALESPR"

In this example, the library is going to be a scaled sprite drawing routine. *LOADLIB finds the library (which is just a regular program variable), and relocates it. HIMEM points to the first byte after usuable RAM, so HIMEM will end up being reduced by the size of the library.

Code: Select all

20 drawScaled%=0
30 drawScaled$="drawScaled"
40 CALL &FFFF,drawScaled$,drawScaled%

The next thing we'd need to do is to find the address of the entry point to a function inside the library. In this case, we're looking for "drawScaled", so create an integer variable to hold the pointer and a string variable to hold its name, then call &FFFF. BBC BASIC lets you trap CALLs into the &FF00..&FFFF range (to implement BBC Micro OS emulation, if you so wish), so chances are the "get entry point" function is going to be there, though probably not at &FFFF.

Code: Select all

50 CALL drawScaled%,sprite%,x%,y%,w%,h%

At this point we could call it a day and use the entry directly, or one may wish to wrap it up into a BBC BASIC procedure.

Code: Select all

60 END
70 DEF PROC_drawScaled(sprite%,x%,y%,w%,h%)
80 CALL drawScaled%,sprite%,x%,y%,w%,h%
90 END PROC

The library binaries themselves will be regular Z80 binaries with a header (to identify them as BBC BASIC libraries) and relocation data.

[qarnos]

The library binaries themselves will be regular Z80 binaries with a header (to identify them as BBC BASIC libraries) and relocation data.

Sounds awesome I'd be interested to hear how you plan on handling the relocation. Would BRASS be expanded to automatically generate this?

I am wondering how you would handle something like this:

Code: Select all

g_lookupTableForSomething   .equ $80

            ld      h, g_lookupTableForSomething
            ld      l, someValue
            ld      a, (hl)

I guess it's no biggie, just as long as the rules are well defined so programmer know what they can and can't do. The above example would be pretty hard to handle automagically.

[benryves]

I'd be interested to hear how you plan on handling the relocation. Would BRASS be expanded to automatically generate this?

It would not be Brass-specific, though I will write a script (or a plugin) to help. I'm probably going to try and stick to a very simple system for the moment, where the assembled binary has an origin of $0000, and has a table at the end of itself that has the offsets of absolute references within the binary. You'd probably need to write code like this:

Code: Select all

SomeFunction:
    ld hl,Rel(SomeInternalTable)
    ld a,(hl)
    call Rel(SomeInternalRoutine)
    ret

SomeInternalRoutine:
    ret

SomeInternalTable:
    .db 1, 2, 3

...Rel() being a function that returns the value of the passed argument, but adds the current program counter to a list that would then be stuck somewhere in the library as a list of addresses that needed to be patched (ie, have the relocated address added to them).

I am wondering how you would handle something like this:

Code: Select all

g_lookupTableForSomething   .equ $80

            ld      h, g_lookupTableForSomething
            ld      l, someValue
            ld      a, (hl)

I guess it's no biggie, just as long as the rules are well defined so programmer know what they can and can't do. The above example would be pretty hard to handle automagically.

As you have astutely pointed out, that wouldn't be possible.

There is, as ever, BBC BASIC's inline assembler, but this has a few limitations of its own, not to mention the size overhead of storing the assembly source in the BASIC program, so it would be more useful for smallish snippets of specific code rather than large, generic libraries.

[benryves]

I've got a fairly hackish "graphical text" mode set up (enabled with VDU 5, disabled with VDU 4) that causes all text that is sent to the console to be drawn using the current graphics mode (at the graphics cursor position, using the graphics colour and logical plotting mode and graphics viewport). This allows text to be drawn at any position on-screen, but is (understandably) a bit slower and doesn't let you do some of the things you may be used to (such as scrolling text, copy-key editing and the like).



I've also done some work on a tool to convert files from the PC to use in BBC BASIC. It takes the form of a Notepad-like text editor:



BBC BASIC programs are stored in a tokenised format (usually .bbc files on a PC) and need to be wrapped into a .8xp for transferring to the calculator. The editor above can open .8xp, .bbc and .txt directly, and will save to .8xp.

The detokeniser can be passed a number of settings, which can be used to (for example) generate HTML output, like this. The indentation is generated by the detokeniser (leading/trailing whitespace is stripped by the tokeniser). The tool can also be used to directly convert binaries into .8xp files if need be.

[tr1p1ea]

Ben, you have to stop the rampant progress on this project ... you're making us all look bad! (JUST KIDDING! ).

Man this thing is feature packed!

[benryves]

Cheers for the kind words, tr1p1ea.



I've been doing a little work on a flood-filling algorithm. (PLOT 128-135, 136-143). The above images show its progress; on the left is the first version (which can only fill in black). There is a hole in the bottom-left of the shape, so the leaking is intentional. It also stops one pixel away from the screen boundary -- this too is intentional (it clips against the viewport). The second version, in the middle, plugs the leak and applies a pattern (which will be a dither pattern in BBC BASIC) to the filled area. On the right is the third version, which will fill over black or white pixels with a pattern.

The main filling algorithm needs a 764 byte buffer for the node queue and three 16-bit pointer variables to manage the queue. I've rounded the queue size up to 768 bytes, so it fits neatly on one of the RAM areas designed to store a bitmap of the display.

The problem is filling with a pattern. The way I currently do this is to back up the current screen image to a second 768-byte buffer, fill in black as normal, then compare the two buffers to work out which bits have been filled and use those as a mask to overlay the dither pattern. This is quite a lot of RAM, just to flood-fill an image!

For those who are interested, I'm using the "practical" implementation of a flood fill algorithm from Wikipedia.

PS: I know I usually cheat with 15MHz screenshots; those at the top of this post are regular 6MHz screenshots. The algorithm is fairly fast, if a bit memory hungry.

[qarnos]

Oooh! Flood-filling!

I was wondering if you were going to do that. Nice job!

The two left screen shots seem a bit slow - but I guess that is because you are updating the LCD during the fill?

I'd love to see one of those two screens without the continuous LCD update - the star on the right (presumably without the continuous update) is lightning fast.

[Dwedit]

Heh, I learned how to do flood fills by playing ZZT. ZZT's algorithm is a little different from what I see in the screenshot though.

[benryves]

The two left screen shots seem a bit slow - but I guess that is because you are updating the LCD during the fill?

I'd love to see one of those two screens without the continuous LCD update - the star on the right (presumably without the continuous update) is lightning fast.

The test programs pause until the use presses a key, then they fill, so I'm not sure how you can tell the star is much faster.



Here's one with the pause removed. Not very fast, I'm afraid.

[Dwedit]

I think the star looks faster because the flood fill algorithm fills it with black first, then draws the pattern over anything it had changed to black.
Because it's already black, you can not see the gradual process of it being filled with black.

[benryves]

I know I haven't updated here in a while, sorry. I've been busy with BBC BASIC (Z80) on another platform, though, so I'm still keen to work on the TI-83+ port.

I've started documenting BBC BASIC in MediaWiki. This makes creating the documentation much faster. Not the most exciting of screenshots, I'll give you that, but progress is being made.

[tr1p1ea]

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