Original Progress Thread
Moderator: benryves
- 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:
Re: Original Progress Thread
Ben, are you freaking kidding me?!
This is insane! As a byproduct you can do assembly oncalc .. man thats awesome. How long did it take you to rewrite all of the OS level commands?
So much flexibility!.
This is insane! As a byproduct you can do assembly oncalc .. man thats awesome. How long did it take you to rewrite all of the OS level commands?
So much flexibility!.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
As seen in the source code only lines 170-370 contain the assembly code, and you need to allocate a buffer in memory to store the assembled program to, so it's rather memory-limited and a little clunky to use as a general-purpose assembler.
The OS commands didn't take too long to rewrite. Most of the problems boiled down to how I was parsing command-line arguments before - a routine called GetCommandLineArg that took an index and a pointer to the command-line string that copied the argument term to a temporary buffer where it could then be parsed. The new parser is much more efficiently written; you just set HL to point at the start of the command line and call routines to read off arguments one-by-one (eg GetFilename, GetHexWord, GetDecimal and so on).
The supported OS/star commands are
The OS commands didn't take too long to rewrite. Most of the problems boiled down to how I was parsing command-line arguments before - a routine called GetCommandLineArg that took an index and a pointer to the command-line string that copied the argument term to a temporary buffer where it could then be parsed. The new parser is much more efficiently written; you just set HL to point at the start of the command line and call routines to read off arguments one-by-one (eg GetFilename, GetHexWord, GetDecimal and so on).
The supported OS/star commands are
- BYE
- COPY
- DELETE
- DIR
- ESC
- EXEC
- FX
- HELP
- LOAD
- REFRESH
- SAVE
- TYPE
Re: Original Progress Thread
Are you forced to use line numbers? Any way to automatically renumber line numbers in case you want to add more than 10 lines of code between two previous lines of code? Any way to edit a program and never see line numbers?
You know your hexadecimal output routine is broken when it displays the character 'G'.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
No, but programs without line numbers aren't LISTed and you can't create/edit them on the calculator. There's also no practical way of establishing where an error happened.Are you forced to use line numbers?
The RENUMBER command renumbers the program starting at line 10 and incrementing by 10. You can also pass it a start number and step if you wanted to, say, start at 1 and increment by 1 instead.Any way to automatically renumber line numbers in case you want to add more than 10 lines of code between two previous lines of code?
Not within BBC BASIC itself, as it uses the line numbers to drive the line-based program editor. The program format is well documented and so it's easy enough to write external editors for BBC BASIC programs.Any way to edit a program and never see line numbers?
An alternative would be to save a regular ASCII text file containing the BBC BASIC program with the command AUTO at the top. The *EXEC command could then be used to read data from the text file into the console.
Re: Original Progress Thread
Really can't wait until this is finished!!!!
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
Welcome to MaxCoderz, and thanks! Neither can I, for that matter...
I've been busy over the last few days, but have now resumed work. I'm still working on the OS routines from the BBC Micro MOS; I've recently added support for some of the file related routines, allowing you to manipulate files from in-line assembly code. With some help from J.G.Harston I hope to be able to implement these parts in a fashion that is compatible with other versions of BBC BASIC.
I've been busy over the last few days, but have now resumed work. I'm still working on the OS routines from the BBC Micro MOS; I've recently added support for some of the file related routines, allowing you to manipulate files from in-line assembly code. With some help from J.G.Harston I hope to be able to implement these parts in a fashion that is compatible with other versions of BBC BASIC.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
The BBC Micro had a virtual resolution of 1280x1024, meaning that if you drew a circle centred on 1280/2,1024/2 it would appear in the middle of the screen regardless of its pixel resolution. On top of that, (0,0) was in the bottom-left hand corner of the screen with the Y axis pointing upwards.
Thus far I'd been using the slightly more intuitive fixed resolution of 96x64 with (0,0) in the top-left hand corner with the Y axis pointing downwards. This means that any graphics program for the TI-83+ version appears upside down and squashed into the bottom-left corner when run on the BBC Micro.
I have worked on attempting to remedy this. 1280x1024 does not divide cleanly into 96x64, so I've used a constant scale factor of 16 on both axes resulting in a virtual resolution of 1536x1024. (Flipping the Y axis is easy enough). This means that programs drawing shapes (lines, circles, triangles, rectangles, parallelograms) will run on both BBC Micro "compatible" versions of BBC BASIC and the TI-83+ and produce roughly the same results.
As this may not be to everyone's tastes the two options may be independently controlled with two new star commands;
I have also been working on implementing the OS call OSGBPB. This call allows you to read/write multiple bytes of data in one go, so is much faster than using the byte-at-a-time BGET# and BPUT# statements. It also provides a way to enumerate filenames, a feature I have yet to implement but one that should be useful (eg to search for data files for your own program without having the filename hard-coded or having to prompt the user).
Thus far I'd been using the slightly more intuitive fixed resolution of 96x64 with (0,0) in the top-left hand corner with the Y axis pointing downwards. This means that any graphics program for the TI-83+ version appears upside down and squashed into the bottom-left corner when run on the BBC Micro.
I have worked on attempting to remedy this. 1280x1024 does not divide cleanly into 96x64, so I've used a constant scale factor of 16 on both axes resulting in a virtual resolution of 1536x1024. (Flipping the Y axis is easy enough). This means that programs drawing shapes (lines, circles, triangles, rectangles, parallelograms) will run on both BBC Micro "compatible" versions of BBC BASIC and the TI-83+ and produce roughly the same results.
As this may not be to everyone's tastes the two options may be independently controlled with two new star commands;
- *YAXIS UP|DOWN
- *GSCALE ON|OFF
I have also been working on implementing the OS call OSGBPB. This call allows you to read/write multiple bytes of data in one go, so is much faster than using the byte-at-a-time BGET# and BPUT# statements. It also provides a way to enumerate filenames, a feature I have yet to implement but one that should be useful (eg to search for data files for your own program without having the filename hard-coded or having to prompt the user).
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
I've changed the scaling so it can be set from any power-of-two factor between 1 and 128. J.G.Harston has provided a lot of helpful information and guidance on how I should implement the text and graphics output for improved compatibility with the BBC Micro video modes.
On top of this I've rewritten large portions of the VDU code, separating text I/O from everything else. I've abstracted the actual text output (ie, drawing it to the screen) from the VDU emulator via a series of vectors so different screen modes (with different sized characters) are possible.
MODE 4 is of the most interest, I feel:
Those enormous characters clearly don't leave a whole lot of room on the screen to edit programs. However, what makes those 8x8 characters interesting is that the font data for them resides in RAM - they are user definable characters. 8x8 pixel characters in a 12x8 grid sounds like it'd be good for tilemapped games!
On top of this I've rewritten large portions of the VDU code, separating text I/O from everything else. I've abstracted the actual text output (ie, drawing it to the screen) from the VDU emulator via a series of vectors so different screen modes (with different sized characters) are possible.
MODE 4 is of the most interest, I feel:
Those enormous characters clearly don't leave a whole lot of room on the screen to edit programs. However, what makes those 8x8 characters interesting is that the font data for them resides in RAM - they are user definable characters. 8x8 pixel characters in a 12x8 grid sounds like it'd be good for tilemapped games!
Re: Original Progress Thread
Wow, that looks great.
Does BBC Basic use loops or gotos more? If the former, I'd definitely use it over Ti-basic. If the latter, I still might check it out. Having 0,0 in the lower left corner is almost reason enough to use it.
Does BBC Basic use loops or gotos more? If the former, I'd definitely use it over Ti-basic. If the latter, I still might check it out. Having 0,0 in the lower left corner is almost reason enough to use it.
My ethicator machine must have had a built-in moral compromise spectral release phantasmatron! I'm a genius!
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
BBC BASIC is structured, so there is virtually never any reason to use GOTO. It has named, re-entrant procedures ("subs") and functions; as for loops there's a FOR...NEXT construct and a REPEAT...UNTIL construct.
One feature it does lack is blocks. That's why the condition for the REPEAT structure comes at the end - BBC BASIC must execute the contents of the structure at least once. This has a few side-effects, for example with multi-line procedures or functions:
For this reason procedures and functions are usually defined at the end of the program, after an END statement.
This is more of a problem with IF statements, as there's a maximum limit of 255 characters per line. In these cases you could either GOTO past the end of the IF statement block or put the body of the IF block in a procedure and call that.
One feature it does lack is blocks. That's why the condition for the REPEAT structure comes at the end - BBC BASIC must execute the contents of the structure at least once. This has a few side-effects, for example with multi-line procedures or functions:
Code: Select all
DEF FN_Double(x) =x*2 : Single line, works.
DEF FN_Triple(x)
=x*3 : Error when BASIC runs onto this line.
Code: Select all
PRINT FN_Triple(100)
END
:
DEF FN_Triple(x)
=x*3
Code: Select all
10 IF X<>12 GOTO 30
20 REM IF block in here.
30 :
10 IF X=12 PROC_X12
...
100 END
110 DEF PROC_X12
120 REM IF block in here.
130 ENDPROC
Re: Original Progress Thread
That makes sense. Took me a while to wrap my head around, but I understand how that's superior to Ti-Basic. It reminds me of assembly, actually (though less difficult).
One thing I learned in QBASIC that I miss in Ti is the one-line if statement like you have in your example.
That reminds me of another Ti-Basic fault: How to goto out of an if statement without leaking memory.
The above code will never release the memory taken by the if statement, because it never reaches "end". The loss is insignificant in this example, but can add up quickly in others. I suppose I could restructure the loop so the if statement is replaced by a "while" at the end, using goto to jump into the correct place from the start. I dunno.
One thing I learned in QBASIC that I miss in Ti is the one-line if statement like you have in your example.
That reminds me of another Ti-Basic fault: How to goto out of an if statement without leaking memory.
Code: Select all
//Loop Start
code
code
code
if <condition> then
goto B
end if
code
code
code
//Loop End
Label B
My ethicator machine must have had a built-in moral compromise spectral release phantasmatron! I'm a genius!
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
It's possible to leak memory in BBC BASIC by jumping out of a REPEAT or FOR loop: see here for more information.
The biggest advantage (to me, at any rate) are the named, re-entrant procedures and functions. For example, you can define the factorial (n!) function like this:(The =value syntax returns a value from a function).
Procedures don't return a value and their name must start with PROC. Functions return a value and their name must start with FN. My favourite procedure is this one:LOCAL allows you to define variables local to the scope of a procedure or function; without LOCAL et any variable called et outside the procedure would have been overwritten (arguments are implicitly local and passed by value).
I've also done a little work on the PC-based editor; a useful feature is the ability to renumber messy programs.
Note that the 60 GOTO 10 is correctly renumbered to 50 GOTO 20 at the end (the RENUMBER command on the calculator does the same job, but it's useful to have on the PC too).
The biggest advantage (to me, at any rate) are the named, re-entrant procedures and functions. For example, you can define the factorial (n!) function like this:
Code: Select all
10 DEF FN_fac(n) IF n=1 =1 ELSE =n*FN_fac(n-1)
20 PRINT FN_fac(12) : REM Prints 479001600.
Procedures don't return a value and their name must start with PROC. Functions return a value and their name must start with FN. My favourite procedure is this one:
Code: Select all
10 DEF PROCRASTINATE(t) LOCAL et : et=TIME+t : REPEAT : UNTIL TIME >= et : ENDPROC
20 PROCRASTINATE(200) : REM Pauses for 200cs (2 seconds).
I've also done a little work on the PC-based editor; a useful feature is the ability to renumber messy programs.
Note that the 60 GOTO 10 is correctly renumbered to 50 GOTO 20 at the end (the RENUMBER command on the calculator does the same job, but it's useful to have on the PC too).
Re: Original Progress Thread
Ben, I am really amazed to all the work you have done for calcs and beyond! I am sorry I have nothing important to contribute, but I would love to see the completion of this..I would love to dabble in this, but would you have some sort of guide or recommend one?
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
For Richard Russell's versions of BBC BASIC you could visit the BBC BASIC website, from where you can download a shareware copy of the Windows version (limited to 8KB memory). The Windows version has a tutorial here.
The Z80 version is close to the older DOS x86 version, which has full documentation available online.
If you'd rather experiment with the original version, BeebEm emulates the BBC Micro/Master.
The Z80 version is close to the older DOS x86 version, which has full documentation available online.
If you'd rather experiment with the original version, BeebEm emulates the BBC Micro/Master.
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Re: Original Progress Thread
I hope you don't mind, tr1p1ea, but your xLIB tilemap demo seemed a good base for a BBC BASIC demo; so here it is, shamelessly ripped off.
The source code for this is here (works in BBC BASIC for Windows). Each row of tiles is stored as a string, with each tile represented by a character in the string.
The source code for this is here (works in BBC BASIC for Windows). Each row of tiles is stored as a string, with each tile represented by a character in the string.