Date   : Mon, 12 Feb 1996 18:38:49 +0000 (GMT)
From   : Mark Cooke <mpc@...>
Subject: Re: bpc status

CC'd reply to the Beeb list as a rough guide to what BPC is for those who 
weren't around when I was actively working on BPC. Hope you don't mind, 
Robert.

On Mon, 12 Feb 1996, Robert Schmidt wrote:
> Hehe... I finally got hold of your proper mail address...
> 
> I was wondering if you'd take the time to fill in some info for the BPC
> entry at http://www.idt.unit.no/~robert/bbc/emulators.html#BPC - like: what
> it currently supports (graphics, disk, snapshots, sideways RAM/ROM),
> approximate speed, and whatever you see fitting.  A release date would be
> nice!  ;-)

Whee.... Sounds like I'm being press ganged into working on it again :-)

Well, where it's at is:

Platform:     PC
Language:     80386 Assembler
Requirements: 386+ CPU, EMS (for sideways ram/rom)
              Registerlevel compatible VGA card, and probably an SVGA 
              monitor.

Features:

Simple opcode interpreting. Nothing clever like dynamic recompilation, though
I may add some features to handle the common dec/dey/dex bne/bra/... as a 
single 'megacode'. The way the emulator is structured this would be a 
pain though.

Small code footprint. To save time getting between opcodes, each opcode 
is on a 256 byte boundary, and I use a jmp [bx], where, bh is the opcode, 
and bl is zero to move to the next one.

The pure 6502 opcode interpreter runs the 256^3 test that was bandied 
about the old list in about 13 seconds. ISTR the beeb does it in 60 or so.

The entire code is < 64K, and so all the calls are near - this is a 
significant saving. To toggle between BCD and normal modes, I had planned 
on duplicating the opcodes and using bl = 128 to provide fast switching.
The opcodes are too big for that, so I will eventually get around to 
duplicating the 64K segment, and doing a far jump on translations.

Hardware:

In previous revisions of the software, I have had the system via, timers 
and screen code operating nicely. It should just be a case of integrating 
them all into the final version.

Screen: 

The screen uses one of two modes - either a true 640x256 mode (hence the 
need for register comatible VGA and multisync - although this may work on 
a normal VGA monitor), or a 640x350 letterbox/debugging mode.

The debugging mode displays registers, flags and other information in a 
strip at the bottom of the screen.

The internal representation of the screen is such that split screen modes 
are fully supported. Palette manipulation is also possible. Fairly fast 
because of optimized machine code writing directly to the screen memory.
Probably not as hardware independant as it should be.

Keyboard:

Direct hardware irq hooking to try to provide accurace emulation of the 
beeb keyboard response with regard to inkey's and so forth. Initial 
keypresses are translated into a grid organized like the Beeb keyboard.
The grid columns have total number of keys pressed count, that is used in 
the VIA processing to reduce the amount of work done in multiplexing the
grid ala the beeb.

Sound:

None

Disk/Tape support:

None yet

Sideways Rom/Ram:

Fully supported for ROM/RAM as boot time.

Outstanding Issues:

Lots. Mainly time, disk/tape handling. Messing around with direct 
hardware manipulation for improving speed. The screen code is fast, but 
slows the system down a lot. I will probably revamp it before I go much 
further with it.

Release Date:

realistically with my workload at the momennt, not before the end of the 
year at the earliest. The Xray telescope is taking priority right now - 
sorry guys :-)

Regards,

Mark

Mark Cooke                             The views expressed above are mine
Systems Programmer                     and do not reflect in any way the
University Of Birmingham               current policy of my employers.