The photo shows the board fitted with two 8K RAM chips for a grand total of 16K.
I've replaced them with a 32K RAM and a 64K ROM.

This required modding the PAL equations, and wiring extra address lines

Another issue is that the ROM is mapped from 0000 up, and the RAM from FFFF down.
CP/M needs RAM from 0000 up, so to run CP/M the SCPUB needs to disable ROM so that STEbus memory appears there.

I intend to modify the memory map so that when the ROM is switched out, on-board RAM appears there instead. CP/M is small, so I can fit it and a BASIC interpreter there.

I've looked at the BBC second processor as a model. The boot ROM is a nice small 4K, twice the size of the 6502 version, but there are two software interfaces in there. The first provides the Acorn MOS, the second provides the CP/M interface.

The BBC Z80 second processor BASIC runs as a CP/M application. Jonathan Harston has written utilities to convert it to use the BBC MOS directly: http://mdfs.net/Software/BBCBasic/Z80Basic/

I am nowhere near as experienced as Jonathan, and I found it a lot of work modifying the 2K 6502 MOS ROM, so this look as just as much work and then as much again to figure out the CP/M side.

2018-11-18 Uploaded manual, circuits and original PAL equations 

2018-11-18 Uploaded the Intel hex file of a ROM that came with the board. I believe it to be a BASIC compiler for which I have the manual. The manual says there is a ROM 'A' for the Run-Time Package in IC22 (0000-3FFF) and another 'B' for the BASIC in IC23 (4000-7FFF). I have the BASIC ROM and the RTP.

2018-11-22 I have joined the two 16K ROM images into one 32K image which I disassembled, turned into source code as far as I can, and reassembled. The output matches the original ROM data.

2018-11-25 Updated source file and manual for BASIC compiler. More details about i/o addresses, and what they operate. The manual covers everything about the language, machine-code interfacing, multi-tasking, and example programs. The i/o uses serial I/O (easy to port) and the STEbus EPROM programmer described in another project. If you don't have that, the ROM programming commands will not work. There is enough information to port it to other boards. I think I will leave it at that. 

2018-12-03 Completed mods for accepting a 32K SRAM and a 64K ROM. Also programmed two GAL chips. The 22V10 has the same logic as the original PAL. The 16V8 is modified so that it will either boot with ROM at 0x0000 and RAM at 0x8000, or have the top half of the ROM appear at 0x0000 and 0x8000 then replace the low copy with RAM. The latter is to allow the implementation of CP/M.

I have programmed the 32K BASIC into the lower half of the ROM. The upper half is reserved for CP/M boot code, but that is a future project. ROM pin A15 is wired to the link that selects the memory mapping, so one link controls both ROM and GAL.

2018-12-05 After fixing some mistakes, I now have partial success - board prints "Press RETURN" on reset, but does not respond to characters coming in. RS232 data signal is reaching the serial chip, I may try the simpler demo program from the SCPUB manual tomorrow.

2018-12-07 Found A10 floating due to track I had broken. Repaired, now compiles and runs BASIC. 

The command MLIST reports my BASIC program areas starts at 0xC000,  so I would have to mod the ROM to use the full 32K RAM available. For now I prefer to leave 16K space free for paged memory and bus memory space.

The autobaud feature copes with 300 to 9600 baud, but fails at 19200 and over. It is possible to change a byte (CONSOLE_AUTOBAUD_ENABLE_FLAG in the source code) to skip autobaud.

When terminals were not expected to send characters faster than a human typing, it was not possible to choke a computer with text. Now that the PC is the usual terminal, copy-and-pasting programs from manuals is obviously saner than typing them in.

I found that pasting whole programs mangled the lines. Telling the terminal program to wait a long time after each line, or wait for the > prompt, did not help. Each line has to be entered one by one. I believe this is because USB essentially sends packets of data, not character by character or line by line. So the USB dongle will not wait after each end-of-line character, and the Z80 misses characters while it is storing and parsing a line.

I think the answer is to set the DART to use hardware CTS/RTS handshaking, so it will automatically stop characters coming in if the previous character has not been read.

2018-12-13 Handshaking not as simple as assumed. RS232 originally used RTS  to mean "shut up and listen, I am about to talk". This is asserted until the transmit buffer is empty. This is not the same as "shut up, my receive buffer is full" which is what I need. So I have programmed the DTR line to say "Ready to receive" during the DART polling. This seems to be working as expected, i.e. asserting "ready to receive" most of the time and toggling high when characters arrive. But  characters are still being missed. I need to get the scope out to solve this mystery...

2018-12-30 After interruption by Christmas, looked at the overflow issue again. Looks like I really need a buffer that is filled by background interrupts. Luckily, I found an example routine to do this in Leventhal's book "Z80 Assembly Language Subroutines". It is for the very similar chip, the Zilog SIO.

I spent some time trying to convert the routine to run on this board, and optimise it to use 256-byte buffers. Leventhal's routine needs handshaking added.

I am confident that it can be done, but the BASIC compiler uses interrupts to do a simple form of multitasking. I suspect it will be difficult to integrate the two by hacking the BASIC. I can see how it does polled serial I/O but working out how it manages interrupts will be significantly harder and consume more time than I have spare. I am not able to reverse engineer code quickly, which is a tedious task even for talented hackers.

Therefore I have decided to shelve that idea for now.

My STEbus 65C02 had no buffer overruns, but it used an FTDI USB module. Either the BASIC polls for incoming characters very often, or the USB module has better handshaking and never loses patience by squirting out RS232 data to devices that are not listening. So my next idea is to make an STEbus slave board that carries utilities like a USB interface. This will have the benefit of solving missed characters when pasting programs into other old STEbus boards. I might even add a few other modern items as well.

2019-01-16

Handshaking working - with provisos. The code polls the DART status before calling the "poll status until you get a character" routine. So I made the polling code assert the bit driving CTS on the PC, and the wait-for-character routine release it. Thus the board says "I'm listening" when it is looking for them, and "shut up while I deal with the character" when it fetches a character.

This seems to be working well, but I have noticed a strange bug with Hyperterminal on Windows XP. If I send a blank line between non blank lines, like so:

120 i% = OPEN IN (S$): count% = 0: INPUT# i%, lnum%(count%)

130 WHILE lnum%(count%) > 0
140   count% = count% + 1:

Then list, I get this:

13 WHILE lnum%(count%) > 0
120 i% = OPEN IN (S$): count% = 0: INPUT# i%, lnum%(count%)
140   count% = count% + 1:

I guessed that it was taking longer to understand a blank line, so I set Hyperterminal to wait 1 millisecond after each line. This seems to fix things, but I am uneasy not knowing what the fault reason is. I want to be able to trust that it stored what I sent it. Changing the line number is a silent error - you are not told about a fault because it is legitimate syntax.

Not wishing to check programs myself, I think the best way to check is to list the programs and paste that to a check file. Then you can get diff or windiff to compare and report any differences.

I have not noticed any errors with gkterm under Linux Mint, but I would want to stress test it by sending a massive program (e.g. many automatically generated REM statements) over and over again, and checking them with an automated script. However I feel that the error rate is good enough for normal use. If you have a massive program, you can send it and check the listing. If you are tinkering with a BASIC program, you will be closely monitoring the lines that are typed in.

I shall class this project as working and ready to play with.