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:
This looks like a good online assembler:
And there's probably some way to cross-compile from Linux, so I'm not worried about tools.
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.
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.
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.
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:
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.