Getting my modified Basic to work on the ubee512 Microbee emulator

I spent some time adapting my basic so that it'll work on the Compact Flash Coreboard. I realised that ubee512 has the ability to emulate that, so worked out how to run it under ubee512.

The source code (plus the final PCF.ROM for those who don't want to asemble their own is on my Google Drive.

I use the same source now to assemble either the PAK Cart Basic or CF Basic. There's a pair of variables right at the top of Freebee Fremium Basic 1.0.asm that define what we're doing:

;#############################################################################################
; Define what we're assembling
;#############################################################################################

PAKBASIC: 	equ 0		; = 1 if we're targetting the PAK Cart Coreboard
CFBASIC:	equ 1		; = 1 if we're targetting the Compact Flash Coreboard

Set CFBASIC to 1 and PAKBASIC to 0 to assemble the CF Basic.

Assemble the ROM using:

z80asm -i Freebee\ Fremium\ Basic\ 1.0.asm -o output.bin -llisting.txt
split -b 8k output.bin
cat xae xaf xag xah > PCF.ROM
dd if=/dev/zero bs=1 count=229376 >> PCF.ROM

This places the ROMA at 00000h, ROMB at 02000h, ROMC at 04000h, and the CF boot code from 05800h in PCF.ROM, and pads the ROM out to 256K so ubee512 doesn't complain about size.

Copy the resultant PCF.ROM file to your ubee512k ROM directory.

Execute ubee512 with:

ubee512 --model=pcf --rom256k=PCF.ROM

A USB PAK Cart for Freebee

Greybeard on MSPP has developed code to use a CH376 USB host interface on a Microbee, allowing reading and writing of FAT partitioned USB sticks. The chip is only available as a SOIC, which really doesn't suit the through-hole-only construction of Freebee. But I can always sneak one onto a PAK cart...

So here goes, along with a little 32kx8 EEPROM for storing the code:

This time, the bodge is not my fault

I spent some time earlier in the week diagnosing an issue with the latest Freebee premium board, where monitors were dropping out of sync when a key was pressed when running CP/M.

Like a good hardware designer, I blamed the software. I used the standard "doesn't happen for me under Basic" line. And I was right. The CP/M boot rom and CBIOS on Microbee does bad things when it scans the keyboard, chiefly in not masking out unused bits of the scancode when it scans the keyboard. The long and the short of it is that a line that I use to do a VSYNC inversion, to maybe support EGA sync rates in the future, gets flipped by the key scanning routine, causing, well, random VSYNCs on the monitor.

Much debate on the MSPP forum ensued. I even provided a patch for the boot rom to stop it happening in the boot monitor (but haven't yet gone so far in the CBIOS).

But really, I should relent. I can't expect people to become experts at patching software just to use Freebee. It's going to have to be more compatible. So the bodge, thanks to a random software person in the probably late seventies, who didn't mask unused bits after the rotate. In essence we disconnect MA12 between the CRT controller and IC29 pin 4, then ground IC29 pin 4. It's slightly advanced because the whole trace is on middle layers, so you either cut a pin on one of the two chips (yuck), remove the IC socket pin for the CRTC (IC8 pin 16) or, as I have, drill out a via to do the disconnect.

The safest spot for our surgery is the via between pins 8 and 9 of IC7. It's isolated so we're unlikely to clobber anything else. Here's a photo of the bodge, complete with the little drill bit I used for removing the via (teeny hole just to the right)

Extending Microbee Basic for the PAK Cart Coreboard

Now that I've got Basic properly figured out, I can do absolutely whatever I like with it. On the Premium bee, there's a third 8K ROM, which is bank switched in to 8000-9FFF, which contains the premium patches. The patches only occupy about 2K, so there is heaps of space.

I started by moving code out of the ROM A and ROM B sections to ROM C, cleaning up many of the patches, and rewriting the colour command so it uses an actual keyword rather than just hacking the compressline and expandline routines to create POKEs.

Then I added commands to work with PAK Carts. PAK DELETE nn can delete a PAK. PAK COPY xx TO yy copies from one PAK to another. PAK LIST lists the contents of PAKs.

I added support for high-speed 2400 baud tape load and save (LOADF, SAVEF) and further worked on the LOAD routine to allow loading of tape software directly to PAK. So LOADF TO PAK loads a program from tape at 2400 baud, and stores it in the next available non-blank PAK with headers that allow PAK LISTing, plus execution simply USING PAK nn.

Next I added Freebee Monitor to ROM C. Normally Freebee Monitor resides in PAK, but I wanted to be able to examine what was in my PAKs from monitor, and it's hard to do that when you blow your monitor code away when you change PAKs. So in it goes!

That got me thinking about 80 column mode, as my monitor runs in 80 column mode. Wouldn't it be nice to extend basic to support 80 columns? So I did, including LORES that now works in 80 x 24 mode with a stunning 160 x 72 pixels.

I used (thanks to the suggestions of the crew at MSPP) the keyword WIDTH to allow 80 column mode, so WIDTH 64 does 64x16, and WIDTH 80 does 80x24. Microsoft basic back in the day allowed things like WIDTH 40... So, let's do that also. Freebee doesn't support halving the dot clock like Premium Microbees did (for Viatel), but it does have heaps of PCG RAM, so we can copy the character set to PCG and 'smear' the 8 bit wide characters across two PCG banks, then edit the screen output routines to write the two characters.

The result is what you see at the top of the page.

Having made double width characters, I next added a WIDE keyword that can display the wide characters alongside normal ones. Then I moved underline to it's own PCG bank (bank 7), and reworked inverse so that it swaps foreground and background colours for the selected character, rather than using PCG. This results in being able to display normal text, underlined text, inverse text, wide text, and low resolution graphics simultaneously, as shown below for both WIDTH 64 (512x256) and WIDTH 80 (640 264).