Demo video

So, here is the video of the emulator running. I start it up, it boots straight into MINOL (it autodetects the ROM image and boots there).

I then immediately exit, disassemble and list some memory to show the monitor ROM, and boot MINOL back with G 9000.

Then the Star Trek program is listed and run - it does take a few seconds to create the galaxy, and then I fly about a bit, shoot up some Klingons and exit to the MINOL command line.

All very primitive :)

Executable rebuilt, RC/2016 pretty much done.

In what will probably the final thing I do for Retrochallenge 2016/1 ,

I've rebuilt the executables and the hardware version so that Star Trek will run automatically, e.g. it is loaded into memory.

All you have to do is run the executable, press F5 to run it, and type RUN and it should start. Slowly :)

I might put a screengrab/video up a bit later on.

This is a picture of Star Trek just having started and being run on the hardware "replica".

Trek complete

Yes, it's finished and working, coming in at 3,227 bytes.

This is the (probably) final listing. The next (and probably last) thing I will do is rig the emulator up so this is loaded by default.

I didn't actually write this ; it's pretty incomprehensible. The commented version with full variable names, which is about 5 times as long is on github.

A peculiarity of the original MINOL is you have to write it like this (except you can have comments) - most of the time the interpreter does not allow spaces so you can't write "PR C" it has to be "PRC". I removed the spaces in the preprocessor primarily to save space.

Though I have just noticed it has the superfluous 'A' command which invites the Klingons to attack you (which was for debugging). Still, maybe a Ferengi will play the game, it might be useful ?

The main thing that is missing that I might add, but probably won't as it's nearly time out and the weekend, is the phaser damage does not take distance into account.

But overall I'm quite pleased with it. It does have most of the proper features of Star Trek BASIC, which the other tiny versions (<4k) I have seen don't.

It may be technically wrong. The original MINOL claims a line length of 70 odd characters max but this is more to do with the keyboard buffer than internal structure. With 700 bytes left, I could stretch it out so no line is more than 70 characters long, but I won't :)

   2 (14,254)=12:(14,255)=0:PR$(14,254),"STAR TREK V1.0":PR"(C) PSR 2016":PR:(14,240)=0:(14,241)=7:(14,242)=8
   3 (14,243)=9:(14,244)=255:(14,245)=0:(14,246)=1:(14,247)=0-9:(14,248)=0-8:(14,249)=0-7
   4 PR"SKILL 1-9 ?";:IND:IFD=0;D=5:K=0:I=0
   5 N=0:IF!<2*D+35;N=N+!/80+1:K=K+N:IF!<16;N=N+100:(14,I)=!/50+1*10+N:I=I+1:IFI<64;GOTO5
   6 E=250:T=4:Q=!/4:(14,Q)=163:PRK,"KLINGONS"
  10 I=64:PR"IN QUADRANT ";:N=Q/8*8:(14,254)=Q-N+48:PR$(14,254),",";:(14,254)=Q/8+48:PR$(14,254)
  11 (14,I)=0:I=I+1:IFI#128;GOTO11:N=(14,Q):J=1:O=0:(14,J+151)=255:(14,J+152)=255:(14,J+153)=255:(14,J+154)=255
  12 IFN/10*10=N;GOTO14
  13 I=!/4+64:IF(14,I)#0;GOTO13:(14,I)=J:N=N-1:IF9<J;GOTO12:(14,J+150)=I-64:(14,J+160)=!/10+12:J=J+1:O=O+1:GOTO12
  14 N=N/10:J=J+1:IFJ<9;J=10:IFN#0;GOTO12
  15 S=!/4:IF(14,S+64)#0;GOTO15:(14,S+64)=12
  20 IFK=0;GOTO245:I=(12,128):PR" ",E;:(12,128)=I:PR"E:";:(12,128)=I+5:(14,254)=T+'0';:PR" T:",$(14,254),">";:INI
  21 IFI='A';GOTO200
  22 IFI<33;GOTO30:IFI='S';GOTO30:IFI='L';GOTO40:IFI='W';GOTO50:IFI='M';GOTO60:IFI='Q';GOTO70:IFI='T';GOTO80:IFI='P';GOTO90
  23 PR"CMD: SLWMPTQ":GOTO20
  30 (14,254)=12:PR$(14,254):I=0
  31 N=(14,I+64):IFN=0;GOTO34:IFN<9;N=9:N=N-9*2+224:(0,I*2)=N:(0,I*2+1)=N+1
  34 I=I+1:IFI#64;GOTO31:CALL(0,5):PR$(14,254);:GOTO20
  40 I=7
  41 J=0:PR"  ";
  42 N=I+J:N=(14,240+N):N=N+Q
  43 IFN<64;GOTO44:N=N-64:GOTO43
  44 N=(14,N):M=N/100*100:N=N-M:PRN;:(12,128)=(12,128)-4
  45 (14,254)=M/100+'0':PR$(14,254);:(12,128)=(12,128)+2:IFJ#2;PR"!";:J=J+1:IFJ#3;GOTO42
  46 I=I-3:PR:IFI<7;PR"  ---+---+---":IFI<7;GOTO41:GOTO20
  50 IFE-1<8;GOTO53:PR"DIR:";:INI:IF9<I;GOTO20:Q=Q+(14,240+I):E=E-8
  51 IFQ<64;GOTO52:Q=Q-64:GOTO51
  52 GOTO10
  53 PR"ENERGY!":GOTO20
  60 PR"DIR : ";:INI:IF9<I;GOTO20:I=(14,240+I):IFI=0;GOTO20:PR"WARP: ";:INJ:IF8<J;GOTO20:(14,S+64)=0
  61 IFJ=0;GOTO65:IFE-1<2;GOTO65:J=J-1:E=E-2:S=S+I
  62 IFS<64;GOTO63:S=S-64:GOTO62
  63 N=(14,S+64):IFN=0;GOTO61:IFN<10;GOTO240:IFN=10;GOTO241:PR"STARBASE DOCK":E=250:T=4:(14,Q)=(14,Q)-100
  65 (14,S+64)=12:GOTO200
  70 PR"SURE ?";:INI:IFI='Y';GOTO242:GOTO20
  80 IFT=0;GOTO20:PR"DIR : ";:INI:IF9<I;GOTO20:I=(14,240+I):IFI=0;GOTO20:J=7:N=S:T=T-1
  81 IFJ=0;GOTO200:J=J-1:N=N+I
  82 IFN<64;GOTO83:N=N-64:GOTO82
  83 M=(14,64+N):IFM=0;GOTO81:IFM=10;GOTO200:IFM=11;GOTO243:IFM=12;END:I=M:GOTO120
  90 IFO=0;GOTO20:PR"LVL : ";:INI:IFI=0;GOTO20:IFE-1<I;GOTO20:E=E-I:N=I/O+3:N=N-D+5:IF200<N;N=0:I=1
  91 IF(14,150+I)=255;GOTO94:J=(14,160+I)-N:(14,160+I)=J:IF200<J;GOTO120
  94 I=I+1:IFI#5;GOTO91:GOTO200
 120 PR"KLINGON DOWN !":J=(14,I+150):IFJ=255;END:N=(14,J+64):IFN#I;END:K=K-1:PRK,"LEFT"
 121 O=O-1:(14,J+64)=0:(14,I+150)=255:(14,Q)=(14,Q)-1:IFK=0;GOTO245:GOTO200
 200 IFO=0;GOTO20:I=0:PR"KLINGONS ATTACK"
 201 I=I+1:IFI=5;GOTO20:IF(14,I+150)=255;GOTO201:GOTO220
 210 N=!/32+1:IFN=6;N=9:N=(14,N+240):J=(14,I+150)+N:IF(14,(14,I+150)+64)#I;END
 211 IFJ<64;GOTO212:J=J-64:GOTO211
 212 IF(14,J+64)#0;GOTO201:(14,(14,I+150)+64)=0:(14,I+150)=J:(14,J+64)=I:GOTO201
 220 N=(14,I+160):N=N+D-5:M=!/64+1:N=N*M/4:IFN=0;GOTO201:IFE<N;N=E
 221 E=E-N:PRN,"DAMAGE":IFE=0;GOTO244
 222 M=(14,I+160):N=N/3:IFM-1<N;N=M-1:(14,I+160)=M-N:GOTO201
 240 PR"YOU HAVE COLLIDED WITH A KLINGON.":END
 241 PR"YOU HAVE BURNED UP IN A STAR.":END
 242 PR"YOU HAVE RESIGNED FROM STARFLEET.":END
 243 PR"YOU HAVE DESTROYED A STARBASE AND BEEN ARRESTED.":END
 244 PR"A KLINGON SHIP DESTROYED YOU":END
 245 PR"CONGRATS - YOU WON !":END

.

And more commands

Well, the program is now up to 2,338 bytes - I can scrape back a few if necessary - and it's mostly, not entirely there.

The two outstanding parts are firing phasers, and the Klingons firing (and , if I have space, I might make them move as well)

So today I have added the in-quadrant movement, and torpedo firing - but this also includes a lot of the code to 'clear up' dead Klingons, so it really should fit in the 1700 odd bytes remaining.

The actual source code - the stuff with all the macros and comments - is about 14k, so the output code does look rather like it went through one of those programs that compressed BASIC that used to be available.

More Commands

Well, I'm a bit more optimistic than yesterday about program size, at present it is 1,336 bytes and since yesterday I've added the long range scan - this is messier because MINOL doesn't really handle the requirement to print 42 as 042 well, and the annoying printing of spaces before and after (I didn't write its spec) which you can't suppress. You can see the long range scan on the right. (It shows the contents of adjacent quadrants).

I've also added the warp command - this Trek has two moves, one in a quadrant, and one between quadrants. It just warps to an adjacent quadrant using the directional aspect of a PC numeric keypad.

So that leaves Move, Firing Phasers and Torpedoes, getting the Klingons to fire back, and end game stuff. I'm reasonably confident of getting that into 2.5k or so.

Out of interest, I ran it in normal speed - I've been developing in a version of the emulator that runs flat out - and it is actually not so bad. It takes maybe 3 seconds to create the galaxy, and a couple of seconds to create a quadrant. Short and Long range scans take a second or two. It's a bit slow, but playable - it's actually reminiscent of playing it on a teleprinter, or a machine like an Apple 1 or a similar TV Typewriter device.

Or over a modem. Which reminds me.

I used to work in Halifax (its in Yorkshire), for a company making vertical market software for property management. We wanted to set up a machine in Edinburgh , a unix box. We had an old audio coupler modem - one of those things you plugged the old phones into physically, which was supposed, I think to run at 300 baud. (This was in the late 1980s)

It was rubbish. I couldn't even type ls<return> half the time, and when I did I just got gobbledegook back. Nothing we did made it better. We were part of a big

On the upside, I did get sent up there with a box of backup tapes and did it the hard way. Well actually I spent most of a couple of days waiting for the compiler. So a free holiday. Unfortunately it chucked it down every night, so I didn't see much of Edinburgh.

Halifax is a wierd place. It's a small Yorkshire town. Well actually it's really dull .... except if you approach it from Leeds.

Then your first view is this ridiculously futuristic road layout with overpasses and all sorts of wierd junctions. It completely threw me the first time, it's like finding a motorway built in someone's back garden. Apparently, in the 1970s they had this idea for this super-duper ultra-modern town road system, but it ran out of money half way through - so getting out of the south end of town was (and apparently still is) dreadful.

More here

Short range scanner

Having had a little time to tinker with it, I now have a working short range scanner.

The * are stars, the +++ are Klingons (this is TOS Star Trek .....), >!< are starbases and <*> is the Enterprise.

I hope it's going to fit ; so far this occupies 899 bytes of program memory. This is a little unnerving as I only have 4096 bytes, slightly over 20% used.

If it doesn't fit ; I'll implement "Hunt the Wumpus" instead :)

Building a galaxy, one atom at a time.

Primarily for reasons of space , I'm not going to directly port Tiny BASIC Trek. I had a look at various small Treks and concluded they were all too big, so I decided to write it from scratch and use the Computing Today as a base for ideas.

Minol isn't very compact - it doesn't have any tokenising so keywords like PRINT, which is stored in one byte in most BASIC interpreters, is stored in 2 (it is PR). It doesn't sound like much but over time it does get a bit cramped.

I think though that I will get most of the features in - it might be a bit rough and ready, but it will work. So far, I've done all the set up - the creation of the initial galaxy, and the creation of the new 'quadrant' from that galaxy data, which means I can start to work on the movement routines next.

Adding some preprocessor stuff

Having 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.

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 :)

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

Running programs, after a fashion ....

Well, we sort of have it running MINOL. Very shoddily, but it does work, and as defined by the document from DDJ.

Admittedly you do have to type it into the assembler  directly , well, with a macro anyway – but it does sort of work and seem to do what it’s supposed to. It's junk code, just testing various things.

 1 "START:CLEAR:INA:PR A,A,A,A:GOTO240
 10 HELLO WORLD
 20 GOTO 20
 30 LETB=69:LETA=42:C=A+B:END
 120 D=D+1:(0,4)=D:(12,130)=69:GOTO120
 130 A=!:B='@':C=42:D=0-1:GOTO130
 140 IF1#255;A=A+1:B=B+1
 150 IF255#255;C=C+1:D=D+1
 200 LETA=0
 210 LETA=A+1:IFA#250;GOTO210
 240 PR42,69,Y
 241 PR "A:",A,"STAR TREK"
 242 PR "(",$(144,33),")"

Next up, the console stuff – editing programs, running commands from the keyboard and so on.

MINOL Commands

I seem to have written a lot since the last post in terms of the project moving forward. It is now executing code, albeit not in an interactive environment, and the GOTO RUN NEW CLEAR END OS CALL LET and IF commands are coded, leaving PR, IN and LIST.

Then I have to write the code so you can actually edit programs using the keyboard. At present the “program” is put in using Assembler Macros which works fine for testing but isn’t any good for the final thing.

I have also written a separate integer printing routine, so actually none of the math routines are now used that I wrote ages ago (well a few days ago anyway).

Part of the reason is this is a bit of a swine in SC/MP. You have four pointer registers. One is the program counter, one is used for subroutines (P3) and one for the stack (P2) – this is just convention.
This leaves you with one pointer register, P1. In this code it is normally pointing at the program code.

My original integer to ASCII routine (a 16 bit one) used this as a pointer to memory to store the result in. In the end I decided it was simpler just to write a simple byte only one that used subtraction not division – it only does decimal, and 0-255, but that doesn’t actually matter, and it is simpler to use – it just prints the number in ‘E’.

Half time - state of play

Well, so far, I'm quite pleased with progress. I have:

1. Digitised the circuit diagrams
2. Written an Emulator, running on the PC and "replica" hardware.
3. Debugged the original monitor
4. Written a Machine code monitor with a simple assembler
5. Written a fair chunk of a "High Level" language

to finish ....

1. complete the Language and test it a bit.
2. write some sort of text -> MINOL translator - I whilst I could physically type the code into the emulator, well, that's the plan any way, it would be much easier to have it as a text file and convert it into MINOL format and load it straight in.
3. write Star Trek - and testing the language

The Star Trek I was going to base it on was the one by Ian Powell published in Computing Today (a UK Magazine) in 1979 ; the reason is I have already ported this (it's for an obscure machine, the Transam Triton) to whatever computer I had at the time (Sharp MZ80K I think ....), so it seems appropriate.

Writing a program in a partly tested language is no fun. I've actually done it before, professionally, it was a BASIC owned by a Dutch company (but written by an Englishman). It was, well, interesting. You would enter GOSUB 3000 and it didn't. Variables would occasionally disappear or the program would crash altogether. I don't know what happened to that project (Hotel Management package) but it had disaster written all over it.... I did my best. On the up side, I did get to spend several months in Dordrecht in the Netherlands, which was fun. Even if all the girls (bar one) were taller than me. In fact everyone was taller than me. Even the five year olds.

Expressions in MINOL

So, having been tinkering for a bit, I’ve written the functions to calculate expressions for MINOL. 

This is considerably simpler than BASIC , because there is no order of precedence, and only five possible terms:

• integer constant
• variable A-Z
• a random number - ! (e.g. !*2)
• quoted character value (‘a’) 
• memory access (4,1) (which reads $0401). 

Plus, they are all one byte which means I can return them easily in E rather than use the stack.

The code is actually just the expression and the test code, which is python generated expressions which are then run and compared with the calculated answer – this kind of thing for example 

(4,(2,(((7,'O'),Z),70)))-6-90+D-4/50+D 

which is, incidentally, 23 (on the current version of the monitor, which is used for memory reads).

Obviously I don't use random numbers in a unit test but this is the Galoisian LFSR again, which is quite a decent random number generator.

MINOL

I was originally going to use VTL-2 as my High Level Language, but I discovered this Tiny BASIC ish language while poking around, it was published in an old edition of Dr Dobbs Journal.

I’d already written the screen driver (see previous post) and some evaluation stuff for VTL-2 but this looked more interesting to program in.

In some ways it’s appropriate. It was designed by someone in their “Third year of High School” (Erik Mueller, who I think is the guy pictured – not aged 13) in 1976, which means he is about the same age as me plus or minus a year.

It’s slightly odd as Tiny BASICs go ; for a start it has 1 byte values, both variables and line numbers – this means that my work on 2 byte maths routines is pretty much to pot. It does support strings, sort of and it also supports direct access to memory both for data and code.

It’s pretty impressive for a 13/14 year old and fits in under 2k of memory. This is what the code looks like :-

10 " *** NUMBER- A NUMBER GUESSING GAME (NUM05) 
20 PR:PR" WHAT IS YOUR NAME";:IN$(14,1) 
30 X=!:S=0:PR"HI, " ;$(14,1);" . WELCOME TO THE GAME OF NUMBER" 
40 PR" I'M THINKING OF A NUMBER FROM 0 TO 255" 
50 PR" GUESS MY NUMBER !!" 
60 PR: PR "YOUR GUESS": ING: S=S+1 
65 IFG=X; GOTO90 
70 IFG<X; PR" TOO SMALL. TRY A BIGGER NUMBER." 
80 IFX<G; PR"TOO BIG. TRY A SMALLER NUMBER." 
85 GOTO60 
90 PR " THAT’S RIGHT, ";$(14,1);" I ! YOU GOT IT IN";S; "GUESSES" 
100 PR" PLAY AGAIN" ; : INA: IFA=’Y';GOTO30 
110 PR " OK HOPE YOU HAD FUN . " : END 

This is (of course) the very common Hi Lo game.

• $(14,1) is the string at H = 14, L = 1 e.g. $0E01, 
• ! is a random number from 0-255. 
• Lines beginning with a “ are comments (e.g. 10)

Other than that it should be fairly clear. I will probably be a bit more syntactically friendly, skipping spaces and so on - looking at the original code (8080 assembler) it could get a bit confused running program if you aren't fairly straight with syntax - so mine will support IF G=X ; GOTO 90 rather than IFG=X; GOTO90

New Screen Driver

The picture is a thing called Curses. It was (or is) a sort of terminal driver / text ui library  that allowed the use of completely different terminals with the same code, it worked with termcap or terminfo to provide device independence.

I used to work at a place that used it ; it was a really cheap place to work. Not only did we use a version of curses we typed in ourselves from a book – wrongly, which we didn’t know until I tried to do a vertical menu with it and it crashed all the time. When allocating memory for the window we’d used w * w rather than h * w, which worked fine provided w was greater than h, which it isn’t in some drop down menus.

The hardware we developed on was on loan from someone or other – a huge 386 box about the size of a fridge. We kept having to concoct reasons why we were still ”testing” this gear …… this company was a subset of a big commercial organisation too. If the owners had wanted it back we would have been stuffed….. we were running Xenix/386 on it and we wouldn’t have had a machine to develop on.

I also worked at a place where I was given an original IBM PC to work on, the 4.77Mhz one, with a specialised BASIC interpreter. I got an upgrade when I pointed out the machine could not keep up with my typing – type LIST and it took about 5 seconds to appear. Not awfully good for productivity (this same place I was ridiculed for suggesting DBASE III type screen painters …. this was in the late 1980s ….)

Anyway, the point of this is I have released, hopefully, a new screen driver for the HLL – this one does proper scrolling unlike the rolling of the monitor, which means it needs 128 bytes of RAM all to itself – because the design does not allow you to read video ram, you have to keep a shadow copy of everything. I wanted the Monitor ROM to be able to operate in one 128 x 8 RAM.

It’s about 400 bytes and provides string and character input and output. There’s a program testing it that just inputs a line and echos it again.