Thursday, 21 January 2016

Adding some preprocessor stuff

Image result for macrosHaving done a bit of testing, I've decided to add a sort of very basic Macro processor for writing MINOL code.

Instead of everything being upper case, which I always think is horribly unreadable, I've made everything lower case.

Anything in upper case is a macro, which has a straight text substitution.

This allows me to write code like

:Energy e

To define a macro which is a variable, and then write

Energy = Energy + 1

which the system converts into e = e + 1 automatically. This should improve readability no-end, even though it is very primitive.

For development, I'm also going to cheat slightly and speed the emulated CPU up a lot, just to make running it quicker. The first thing the program does is to set up the quadrants and so on, which would take long enough to be annoying each time I run it.

Tuesday, 19 January 2016

Font changes for Trek

Over the years, there has arisen a standard set of graphics for text star trek, derived from David Ahl's version.

These are things like +++ for Klingons and <*> for the Enterprise.

To keep these (the Tiny Basic Trek actually has slightly different ones, but I prefer the classics) I've made some amendment to the font, adding eight font characters, 2 per graphic.

I have to do this because at some point I will show the short range scan which is an 8 x 8 grid. On a 16 x 8 screen, this gives (obviously) 2 characters per 'cell', and the graphics are three characters per cell.

So as you can see (in the top left of the snap) I have "Poked" 224 and 225 into the first two bytes of display memory, and it shows a <*> which will be the Enterprise.

Release 2


Well, sort of. The current release is the one with 2 2k ROMs in it (effectively) which boots into MINOL (you can access the monitor via the OS command, and return using G 9000). The zip contains the executable and the SDL DLL if you don't have it.

The hardware version is updated to match ; both should be version 0.94


Of ROMs, PROMs and EPROMs....

So…. Looking at the resulting MINOL ROM, it’s about 2,500 bytes or thereabouts in total.

Thinking in hardware terms, how you would actually put this on a machine - this isn’t good. I’m wasting 1/2k of ROM here – now, that isn’t much in 2016 terms, but in 1975 terms it is a heck of a lot.

So I have decided on some reorganisation.

Out from the monitor ROM go the Mathematics routines – which now aren’t used by anything – and into the monitor ROM goes the scrolling screen handler.

I’ve tweaked it a bit so there are vectors at 3 (Print Char/String) 5 (Get Char) 7 (Get String) and obviously changed MINOL so it calls these routines directly. This is also handy in that I can call these routines from MINOL if required.

The monitor ROM now has two sets of screen drivers – the roll to the top and the scrolling version. It also has two keyboard input routines, but this isn’t really worth fixing.

There’s one problem ; I fixed up the integer printer so when it is left it sets P3 to the Print routine, so this can’t happen any more – the Print routine is elsewhere – so this is set up manually after the three calls to this routine.

It works quite nicely, and each ROM image (both 2 x 1k ROMs) has about 128 bytes of free program space, which is handy if there are any messy bugs.

Minol Completed


Well, it’s sort of finished and working, probably. I added the final bits this morning.

  1. I added a marker in RAM (a 32 bit value) that if present indicated memory already had a MINOL program in there – if this isn’t present it does a NEW on start, otherwise it leaves it alone. You can switch back and forth from MINOL and the Monitor at will. 
  2. Ctrl+C now interrupts at Print statements. 10 PR "HELLO WORLD":GOTO 10 previously could only be got out of using the RESET button.
  3. It looks for the stack top rather than assuming it’s there (it was previously hard coded to $0FF8). It should run with only 2 x 6810 RAM chips (e.g. $C00-$CFF) in the main board, except that a long typed in instruction won't work (the keyboard buffer and stack will collide). It really needs at least three ($C00-$D7F)
  4. The current line number is cleared when you type in a keyboard command. (this was a bug), meant that if you typed PR 1/0 in the command line the number given was the last line number executed.

I will update the released version so it has both ROM images in it sometime soon, e.g. it boots into MINOL, you can type MINOL programs into it and so on. It's not bad, the original code was 1.75k this is about 2.5k but most of the difference is because of the screen driver.

The next bit is to write the code to translate a text file to MINOL format – may do something automatic with line numbers ? – and get that loading in.  You can type in programs like we used to with C64 and Speccys, it does work, but it's not a good idea on a beta langiage. I remember writing about my experiences with such earlier.

Then, once that’s done, look at Star Trek. I think there are three Star Trek related retrochallenges this half-year :)



Monday, 18 January 2016

Benchmarking an interpreter

Back in the dim and distant past, the first thing that magazines would do with the latest home computer is benchmark its internal ROM BASIC.

Virtually every machine released over a period of about 1978-1988 ish had a built in ROM BASIC, with a few exceptions – I owned a Sharp MZ-80K where it had to be loaded in from tape, and the Jupiter Ace had FORTH – but most had BASIC.

When the machines arrived that had floppy disks as standard – primarily the Amiga and Atari ST – the BASIC interpreter became something provided on a floppy disk.

The UK magazine Personal Computer World had its own set of benchmarks, which were BASIC programs that were run and measured to see how long they took. The simplest one was this :

100 FOR I = 1 TO 1000
110 NEXT I

I’ve actually found them here http://www.geocities.ws/peterochocki/computers/pcwbm.html 

To give some idea ; a ZX81 4.5s, a Speccy 4.4s, a C64 1.2s,a BBC Micro 0.8s. The slowest machine would be a ZX81 in slow mode which would be about 18s or so (estimate).

The variation is quite surprising. The first thing on the list is a 68000 at 8Mhz (HP Integral PC) which takes 1.9s ; it is quite remarkable that the BBC Micro (6502 at 2Mhz) should be over twice as fast given that both are operating in floating point. The ZX Spectrum BASIC is based on Nine Tiles original ZX80 BASIC which is designed to operate with 1k of RAM and doesn’t care about speed – a typical Z80 machine of the time clocked at 3.5-4Mhz would probably run the first benchmark in about a second.

So, I have benchmarked it. I can’t actually run Benchmark 1 – no FOR/NEXT loop, but I can run Benchmark 2, which is the same thing with an IF … GOTO instead , in MINOL, if I reduce the count to 250.

100 LET A = 0
110 LET A = A + 1
120 IF A#250; GOTO 110

Which runs in about 19 seconds (when wrapped in a loop running it four times).
This isn’t bad, really – it’s a slow processor, it’s running at a quarter of its actual speed anyway (just sticking an SC/MP 2 in and clocking it up to 4Mhz will get that down to 5 seconds) and it’s not written for efficiency by any means, it’s written more with clarity in mind (honest – an optimised one would look like spaghetti – and it wouldn’t be that much quicker anyway).

By comparison : ZX81 6.9s, Speccy 8.2s, C64 9.3s, Atari 800 7.3s

So not too bad really. If I conveniently forget they are all doing it in floating point and I’m doing it in 8 bit integer

The SC/MP is a notoriously slow processor though – having attempted to emulate processors on an Arduino, it can cope with 4004/4040/8008, the RCA1802 and the SC/MP and that’s about it. I wrote an Apple 1 emulator (more as a protest than anything else) and it ran at about 15-20% of the speed of the real thing (which didn’t matter in most cases because of the slooooow TV Typewriter output).

For depressing comparison ; 2400Mhz Celeron, running QBASIC, 0.011s. I have reduced this PC to a wreck of its original finery.

MINOL on Hardware

So, this is a sort of actually working BASIC program here.

Okay, so it’s not exactly the most complex code ever written, but it is working as it should, and it picks up errors a bit better than the original