80-Bus News

Anyway on to BEEB ‘BASIC’, the quotes are deliberate, as whatever it is, it bears little relation to the original Dartmouth College Basic. In fact its closer relations would seem to be some sort of cross between Pascal and C with BASIC syntax. Perhaps a better name for it might be BEEB C-BasPas, anything, but not BASIC. As a language, it’s very powerful, but encourages “opaque programming’ under the guise of ‘structured programming’. In other words if the programmer cares to do the job properly with lashings of comment and everything laid out in a nice orderly fashion, then anything written in C-BasPas should be beautifully clear; on the other hand, if the programmer wanted make his program difficult to read (or is lazy like most of us), all he has to do is remove all the comment, jumble the order of the PROCedures and function calls, and the program becomes as clear as mud. The latter is more likely to be the case-as the available memory in the BEEB is quite small (having subtracted the screen memory and sundry workspaces (a lot of which don’t seem to do much)), as it’s quite difficult to squeeze a program of any size into the available memory space without resorting to ‘dirty’ short cuts.

The BEEB is also provided with a large number of indirectly addressed operating system calls (driven from a number table, something like NAS-SYS) which the user is encouraged to use from the C-BasPas. The OS calls are reasonably documented in the manual, but rely on an understanding of the hardware and devices used, information which is sadly not provided. (I understand the Advanced User’s manual guide goes into detail, but as the BEEB machine I have is on borrow, I don’t feel inclined to buy this just to see what’s happening).

The program uses the BEEB CUTS tape I/O but seems to address it directly, as the data sent appears to be in the form of a bit stream (as it should be) rather than ASCII characters with start and stop bits using the UART as I had hoped. Shades of nasty undocumented things going on in the ULA. All this will prove an interesting exercise on a Gemini, as I guess a couple of bits from a port are going to have to be hard wired to the tape I/O and a software UART written, either that or I’m going to have to design an SIO piggyback board.

So my original plan of quickly rewriting the PACKET program into something more generalized has had to go by the board. It’s not so much an exercise in rewriting, but having to learn C-BasPas and the detail innards of the BEEB operating system and hardware, a time wasting exercise that I’m not too keen on. Oh well, I will carry on (unless someone else wants to have a go). Instead of something I judged would take a few evenings to do, it looks like it’s going to take weeks. Still when (if) I’ve done it we’ll publish it here so that Gemini’s and Nascom’s can take to the air in the PACKET mode.

As to my opinion of the BEEB after a couple of days acquaintance .. well let’s say I wouldn’t give more than fifty quid for one if someone was rash enough to pass one my way!! Torch have the right idea, demote the BEEB to a terminal for use on a CP/M system, it’s about all it’s good for. Pity Torch had to do their own thing with a non-standard CP/M system. Perhaps I might have a go at doing the same with a MultiBoard system, because overpriced as the BEEB is, it might just be cheaper than buying an SVC and keyboard; it could then replace these two, with high res. colour thrown in. Now all this brands me as a heretic with the BEEB cult. So I’d better keep quiet otherwise some dark night, someone might find me lying in a dark alley with a BEEB in my back.