STEbus 80C188

2019-02-24

I need to get some test firmware running. Traditionally one might fit a monitor or BASIC but I think that all I really need is a simple monitor that can download intel hex files and run them. A monitor could have a command letter (like 'L') to load a hex file, but why not have the monitor handle any line that begins with a colon as a line of intel hex file?

I will need to write a routine that handshakes the incoming data stream so it does not get choked while handling characters. I did that recently for the Zilog DART on a Z80 board. This board uses the more advanced Zilog SCC.

This looks a reasonable starting point:

http://web.archive.org/web/20130823172544/http://www.kmitl.ac.th/~kswichit/C188/boot.asm

This looks like a good online assembler:

http://www.compileonline.com/compile_assembly_online.php

And there's probably some way to cross-compile from Linux, so I'm not worried about tools.

2019-03-02

8088 disassemblers seem to have no common syntax. Some disassemble to mov src,dst and some to mov dst,src, and many other issues, so it has been a headache disassembling a fragment of code and reassembling it. I shan't spend any more effort on trying to analyse the firmware if it is easier to write my own. I am using nasm under Linux.

I put the demo code from the manual through nasm, and there were many syntax differences. Nasm is a more sophisticated assembler, and so things like locating the code are done by the linker, not by .org statements. Mind you, this is also true when using the as65 assembler from the cc65 package.

The demo code was scanned in very low-resolution grayscale and is very hard to read. I have made best guesses where letters could be zero, O, C or G etc. With potential transcription errors and not knowing what nasm is up to, it is unlikely to work without a lot of human work.

I need some ready-tested code to port, or check the manual demo code very carefully.

2019-03-17

Time to try some test code. There is some in the manual, very blurred, so I OCR'd it as best I could. My usual assembler (https://www.asm80.com) does not support the 8088, but there is an assembler that does - NASM. It can be used online (https://www.tutorialspoint.com/compile_assembly_online.php) but was easy to install on my Linux PC.

I've got the manual's demo code assembling but can't be sure it is generating correct code.

2019-03-24

I realised the reason I heard nothing from my 80188 board was that the serial port connector pinout is completely different from the PC serial port. Doh! I used an adapter to get the signals properly connected, and I got this sign-on message:

----*****<<<<< Arcom SC88T initialisation v1.0>>>>>*****----

                 0016K bytes of memory

Hurrah! Now I know that the logic chip equations are not disastrously wrong, and the board is fundamentally sound.

This is from the ROM that came with the board. It still hangs after sign-on, probably trying to talk to boards that are not there. Hanging in a wait-state is the correct response to that. I am confident that the board is working well enough that if my self-made software is not working, it is probably a software bug.

2019-04-06

The firmware seems organised like so:

FFFF:0000 jumps here at hardware reset

FFF0:0000 jumps here next, 4K of initialisation code and a C run-time package.
When done, does this endless loop:

loop_1:
call word 0xf800:0x0
jmp word loop_1 ;

which is calling the code at the start of the 32K ROM, at F8000.
I presume this is the entry point for the application code.

However, if I try to write an alternative application, whatever I write crashes. This includes just a simple RET instruction. So calling code in another segment fails.

I wrote some simple code to see it was still okay running experimental code in the same segment. Fortunately there is plenty of room for that.

My test code waits for a numerical character and calls an associated routine.
0 calls a return instruction.
1 echoes characters in an endless loop.
2 prints a byte as 2 hex characters, calling a routine in the RTP.
3 prints a word as 4 hex characters, calling a routine in the RTP.
4 prints "Hello world!", calling a routine in the RTP.
5 prints hex values of bytes from F800:0000
6 prints hex values of bytes from F800:0000 using ES as segment pointer.

Tests 0-4 work perfectly.

Tests 5 prints hex bytes from the default data segment (RAM) which isn't much use for verification as I don't know what they should be. Changed it to read the default (RTP) code segment, and it works fine.

Test 6 changing to temporarily set data segment to F800. It works with value FF00 (RTP segment), and FC00 (top 16K) but nothing under that. Sounds like an A14 problem. Connections buzz out okay. Checked the pinout. Aha! A 32K EPROM pinout differs from a 32K EEPROM pinout! D'oh!

Pin 27 is !WE on EEPROM, and it was linked to A14. So any access with A14 low started a write cycle and garbage was read on the data bus! Pin 1 is A14 but linked to A15. Fixed the problem by linking the pins to the correct signals.

Now to think about putting some software on this. Usually I like to port a BASIC, as I did for my 68008 and Z80 boards). It shows it is running something fairly complicated but easy to use. Anyone can type 

10 print "Hello " 20 goto 10. 

There are many BASICs for the 8086, but they all seem to be loaded through some operating system like DOS. I really don't have time to implement an OS, and the 80188 has incompatibilities with MSDOS. I want something that will run from ROM and not need loading from storage media.

Forth is an idea but has similar issues - might be good for small processors with a single memory space but it will take more time than I have to port it to the 8086 architecture.

I now declare this board is working correctly as far as I can tell, and am having a celebratory beer.

2019-02-22

JEDEC files for the two PAL chips arrived, thanks to Andy!

2019-02-23

JED files decompiled. A bit worried the pinout might differ from the manual I have (for a later version hardware). Partly a red herring, the decompiler produces expressions for i/o pins that are used as inputs, but the output is disabled so there is never a conflict. I did find some difference in the rest of the circuit but I don't have to worry about that for the purpose of recreating the logic chips.

2019-02-24

I now have a better understanding of what is going on in the PAL chips. I already have ideas to tweak it to use a 512K RAM chip (instead of two 8K or 32K chips). It has two 8K chips right now, which is fine for testing but one might like to do something more serious.

2019-03-14

Translated the logic files, compiled them with WinCUPL and programmed two 16V8 chips which I put in the board with the ROM that came with it. Nothing came through the serial port, which may be normal since I don't know what the ROM was meant to do. The 8 MHz CPU clock is being halved for the SCC clock, so that is one thing that is definitely right. The CPU is being held in a wait state, because it is doing a read cycle with none of the programmable chip selects active, which becomes an STEbus cycle. As there is nothing there, it waits forever. This may be normal too, since I don't know if it expected a slave board there.

For now I will just have to assume the logic is correct and use test code to prove or disprove it.