I have just returned from a two and a half week training combined with short vacation. I haven’t posted for a while but the project is well alive and it will regain momentum now when I am back home. Immediate plans are to complete the Monitor/OS with a little help of a nice gadget described in this post and then start working on software emulator of the CPU and the C compiler port (most probably it will be a port of LCC).
Monitor/OS development
Although still very much work in progress, it is slowly taking shape. I currently have a decent interrupt-driven RS/232 driver with support for hardware flow control running at 9600 bps. Higher baud rates are possible but I have not yet tested for stability. I also implemented some helper routines to print and get strings, hexadecimal and decimal numbers. Kernel routines exist to detect available RAM/ROM and installed devices. It allowed me to develop this (screenshot of terminal program connecting to actual hardware via serial):
Most shell functions presented in the screenshot are still only stubs (or very early drafts) but it gives an idea of what I want to achieve. I want the monitor program to be able to:
- load a program via serial port and execute it
- print code/data memory contents to terminal screen (hexadecimal dump)
- print disassembly of code memory contents to terminal screen
- store series of bytes to code/data memory region (poke)
- execute code starting from arbitrary code memory address
- print and set current time (although this will only be possible when I develop a RTC/IDE expansion card which is still missing)
- perform some IDE operations like device discovery, sector read/write (prerequisite same as above)
That seems to be enough to start with. I don’t want to over-engineer the Monitor/OS as it is not my ultimate goal. I want to start working on a C port as soon as possible to be able to port some “serious” software. Assembly programming is fun and mind stimulating, but awfully slow.
EPROM emulator
A colleague at work called me one day and offered to borrow this little gadget that should help me to dramatically speed up the development process of Monitor/OS kernel. Last time I reported that it is ineffective and somewhat disconcerting to burn kernel ROM whenever I want to test my new (oftentimes faulty) code.
It is an EPROM emulator which you connect by a ribbon cable to a socket where you normally have a ROM chip. It simulates the EPROM by using internal SRAM which is easily programmed by a standard parallel cable when the device is connected to the recipient and the PC. It does not require external power supply (it draws power from the emulated chip’s host). For a PC this device is essentially a printer, so programming its SRAM is as easy as copying a binary image to /dev/lp0 in linux. It is really simple and should give my software development a nice boost. No more ROM chip pulling, programming, or continuous laptop rebooting to run my Windows based EPROM programmer software. It should reduce the time from assembly coding to execution to as little as few seconds, as opposed to few minutes minimum of frustrating manual work I have been experiencing so far.
I haven’t yet given it a try but I studied its documentation and I am pretty confident that it will work with my setup. All I need to do is to build my own custom ribbon cable to match the pinouts of my 29F010 bios/kernel EEPROM chip. The emulator is limited to 64kB but I should be able to easily overcome this limitation, too (currently I am using all 128kB of my ROM chip by placing data segments in the upper 64kB, but this is only for convenience). I will work on it during next weekend’s session.
Very nice toy! –I did not know such a thing existed. It makes a lot of sense. I’m sure it will be of great help.
On my part, I am enjoying the now working Console based on lamps (LEDs) and switches, as in the old days I missed. It is a lot better than burning EPROMs but it is not practical for large amounts of code. So I’m working on the Serial port, as you did. Your work has served as a reference to me; thank you for keeping your project so well documented.
Question:
You mentioned plans for porting LCC. Does this mean: make the computer to host a development environment on its own (including a text editor, of course)?
No, LCC is a full blown C compiler intended to be hosted on a PC for cross-compilation. My plan is to develop a new back-end for LCC to generate assembly code for my CPU. Then I will pass the generated code through my assembler and run it on the computer (the DIY one). LCC is even too big to fit in my 64kB code + 64kB data memory model. An alternative, that could be hosted on the computer natively in smallC. The bootstrapping method would be to compile smallC (which is itself written in C) by LCC, assembly the result and have a smallC working natively. So, in any case, I need a cross-compiler first. LCC seems to be the best choice. It is well documented and designed to be open for porting to new CPU targets.
Question:
How do you probe for hardware (UART0: found, UART1: found)?
I used a scratch register of both UARTs to detect them. My UARTs are mapped to addresses $1000 and $1010 in memory (I have 16-byte device blocks). The scratch register of 16550D is located at offset 7, so addresses $1007 and $1017 point to scratch registers of both UARTs in my case. I probe if scratch registers are functional, i.e. I may read/write arbitrary values to them. With UART card disconnected (or even if I remove the chip on a connected card) these memory addresses would not reference any device, read results in floating “value” 0xffff (DBUS in high impedance state), and write does not change anything. Based on this I determine if UART is there or not. I am not sure if there is any other way.