slightly OT: a simple Benchmark

[GaBuZoMeu]

Just to understand - B-Em is the Beeb Emulator running on your PC?

[Chromatix]

Yes. B-Em and BeebEm are both emulators, though they aim for cycle accuracy.

[BillO]

Chromatix wrote:

That would be amusing if nothing else. I'm slightly more interested in the 16MHz "Jaguar".

Here it is. What would you like to know about it?

[GaBuZoMeu]

Then I use your 4MHz figures. It is easy to compare against 1 or 2 MHz machines and dividing the numbers by 4 or 16 or more can be done easily. This sort of benchmark scales linear with the µPs clock. There is no other device (beside RAM) involved.

THX!

Arne

[GaBuZoMeu]

A red skinned Jaguar

[Chromatix]

How fast can it run my code? I have emulation numbers for 16MHz, but it'd be nice to verify them with real hardware.

The code is assembled to $4000 by default (easily changed), and uses 16 zero-page bytes beginning at $70 (again, easily changed). The main entry point is at $4000 with $70 set to the gap size to search for; it returns with the following six bytes containing the pair of primes found with at least that gap. The eighth byte is zeroed so that the second prime can be read as a 4-byte integer by BASIC.

At the end of the source file is a test routine covering cases A-F, verifying that it produces the correct result. If it gets as far as the final NOP-NOP-NOP-NOP-BRA, it's all correct. If it goes into any of the other BNE loops, there's a mismatch. My emulator is set up to detect these tight loops and treat them as an exit condition, due to the test suite.

[GaBuZoMeu]

If you could manage to use only NMOS instructions and can produce an Intel hex style file - I just got an old board up and running . Addresses are ok. But it's a NMOS and only 1 MHz. I am going to verify the SYM-1 times with it. So far they are precise.

Arne

[BillO]

Chromatix wrote:

How fast can it run my code? I have emulation numbers for 16MHz, but it'd be nice to verify them with real hardware.

The code is assembled to $4000 by default (easily changed), and uses 16 zero-page bytes beginning at $70 (again, easily changed). The main entry point is at $4000 with $70 set to the gap size to search for; it returns with the following six bytes containing the pair of primes found with at least that gap. The eighth byte is zeroed so that the second prime can be read as a 4-byte integer by BASIC.

At the end of the source file is a test routine covering cases A-F, verifying that it produces the correct result. If it gets as far as the final NOP-NOP-NOP-NOP-BRA, it's all correct. If it goes into any of the other BNE loops, there's a mismatch. My emulator is set up to detect these tight loops and treat them as an exit condition, due to the test suite.

What assembler did you use?

[Chromatix]

I used ca65, target 'none'.

Here's the NMOS version as well. I gave it a test run to make sure it still worked correctly.

[whartung]

Chromatix wrote:

The story with the BBC Micro was that the BBC wanted to promote computer literacy in the UK, and needed a standard, inexpensive home computer with a high-quality BASIC to do it - and by "high quality", they meant that none of the ubiquitous M$ derived BASICs would do. As a side-effect, they also wanted a machine that could overlay text and graphics on a broadcast TV signal with minimal added hardware.

So what distinguished BBC BASIC from a MS BASIC.

I've heard MS BASIC called many things, but no ones ever suggested it wasn't a high quality BASIC.

Outside of specific hardware extensions, it was a pretty good and advanced BASIC. At most it suffered from an 8080 design being ported to completely different CPUs.

So, curious what makes BBC BASIC "higher" quality.

[Chromatix]

Most 6502 micros running an MS BASIC variant used a 16KB or even 8KB ROM for everything. Acorn used *two* 16KB ROMs, putting a relatively sophisticated (if still single-tasking) OS in one, including a powerful graphics driver and a complete ASCII character set (many other micros, including the C64, still only supported upper-case). The other 16KB ROM was dedicated to BBC BASIC. (Eventually most BBC Micros had at least a third ROM fitted, containing the Disk Filing System to drive the FDD controller.)

The BBC were particularly keen to have a language which encouraged *structured* programming, in keeping with their computer-literacy goals. MS BASIC had FOR-NEXT and GOSUB-RETURN, supplemented by IF-THEN-GOTO-ELSE-GOTO, which with no universally-adopted alternatives was legitimately criticised as leading to spaghetti code. A key limitation of GOSUB was that it didn't allow for local variables within the subroutine. BBC BASIC added REPEAT-UNTIL, DEF PROC-ENDPROC, DEF FN, and LOCAL. (Years later, BBC BASIC V on the Archimedes added WHILE loops and multi-line IF-THEN-ELSE-ENDIF, but that's less relevant here.) A reasonably complete set of mathematical functions was provided, with a 5-byte floating-point format giving quite acceptable precision for a home computer.

BBC BASIC was also an exceptionally fast interpreted BASIC, over and above the relatively high clock speed (for the time) of the CPU, much of which could be attributed to the generous allocation of ROM space, but also to the skill of its authors. Just look at the benchmark results at the top of this thread. The later Archimedes version could legitimately boast to be the fastest interpreted BASIC in the world, backed by the exceptionally efficient ARM CPU.

BBC BASIC also provided a reasonably direct interface to the graphics routines built into the BBC Micro's OS. MOVE, DRAW and POINT were shortcuts for specific PLOT commands, which in turn translated directly to six-byte VDU sequences. Precisely the same effects could be produced by constructing a string containing the correct codes and passing that to PRINT, or from an assembly routine by calling OSWRCH. Oh, and BBC BASIC included an assembler - you embedded your assembly code into a BASIC program and got a great deal of the power of a macro-assembler for free. (On the Archimedes, the 6502 assembler facilities were of course replaced by an ARM assembler.)

Similarly direct facilities were provided for the sound chip - which, while not a patch on the SID, was simple to understand and at least comparable in capabilities to many other 8-bit machines. BBC BASIC provided SOUND and ENVELOPE with thorough documentation of how they worked.

Other, more advanced OS facilities could be accessed using the *FX command - not strictly a BASIC feature, but a way of interfacing to the OS' built-in command-line interpreter. This eliminated most of the messing around with POKEs on other micros. BBC BASIC doesn't have PEEK or POKE keywords, but does have byte and word indirection operators which perform the same function. Yes, BBC BASIC has pointers!

[BillO]

Chromatix wrote:

I used ca65, target 'none'.

Here's the NMOS version as well. I gave it a test run to make sure it still worked correctly.

I'll give it a shot, but it will take a few days before I can get around to it.

Does it time itself?

[Chromatix]

Well, no, because I have no idea how to do that on your hardware. On the Beeb I just built a small BASIC wrapper around it.

[BigEd]

(A couple of other notable advantages of BBC Basic: integer variables; hex constants and hex printing; bitwise boolean operators; the RENUMBER command; INKEY, ADVAL and CALL. The original "outline specification" from the BBC, inviting responses from companies to make the BBC Micro, is discussed here on StarDot. Here's a good 78 page writeup of the legacy of the computer literacy project by Tilly Blyth of the Science Museum.)

[commodorejohn]

BillO wrote:

Chromatix wrote:

That would be amusing if nothing else. I'm slightly more interested in the 16MHz "Jaguar".

Here it is. What would you like to know about it?

Ooh, now that's a sharp-looking little beast. I don't see a thread for it on the forum here - did you design it? What are the specs, and is there anyplace to get a bare board?