• Please review our updated Terms and Rules here

Enhanced ROM Monitor/Loader for system restorers

RickNel

Veteran Member
Joined
Apr 24, 2009
Messages
641
Location
Canberra, Australia
From my experience getting a s-100 machine back to life I've built on the work of others to put together an EPROM-based monitor/loader to support restoration and maintenance of Z80/8080 machines that don't have access to an OS.

Many of the debug features are directly descended from Zapple and DDT, but culled to conserve EPROM space and on the principle that once you have access to an operating system, more comprehensive debug utilities will be available.

I'm calling it Minimon.

The Boot module is of course system-specific. Assembler code is organised to be as modular as possible, since each implementation is likely to be for a different hardware environment and/or configuration.

The new feature of most interest may be the "Load" module, which loads a binary file (or keyboard input) from a serial port to any memory location *without any operating system or disk drives*. I've not found anything else that does this without system calls. It can save a lot of Front Panel switch-flipping.

Operating system components can be loaded from external storage or an external development environment, then run or tested with Minimon's debug capabilities. Also testing of EPROM code prior to burning. If an operating system is already loaded, Load can overlay a revised BIOS or whatever directly from the PC where it was assembled.

I have uploaded the files for Minimon to http://thwaites.homemail.com.au/minimon/

The zip file contains Z80 assembler sources, a comprehensive Readme, and some ancillary macros for Minimon and for a PC to send a file to the Load module.

Minimon as currently configured cold boots from EPROM with a sequence of tests to check response of Console, RAM, Diskette, and Keyboard, then presents its menu or boots directly to CP/M.

It will start to function with minimum hardware of just CPU and EPROM, and becomes increasingly useful when there is Console and RAM.

Comments and suggestions welcome.

Rick
 
Hi! Great idea! Does your monitor work without RAM? That is very useful indeed! Does it require a working serial port? If not how does it output status information?

I think this is a great idea. Either a CPU board with EPROM socket or CPU board and EPROM board to resurrect even the most difficult broken computers.

Excellent work! I assume builders can customize with custom reset vectors, ROM addresses, UART routines, etc?

Very nice! Thanks and have a nice day!

Andrew Lynch

PS, any interest in making a similar system for S-100 68K CPU for boot strap? It is approaching prototype board build and test phase and is going to need something just like your program to get up and running.
 
Second that! Looks very interesting and potentially useful; now I just have to find time to try it out on one of my CP/M systems...
 
Andrew -

The scope and limitations are explained in the Readme in the zip file.

Absolute minimum working hardware is CPU and EPROM - but obviously the next priority is console I/O so you can start interactive usage. The monitor's first task on boot is to test and confirm console output [IF NO OUTPUT, FIX CONSOLE!], then it tests presence of RAM, then presence of disk, then keyboard input. This part is based on John Monahan's monitor code, with a few tweaks.

It can be assembled to remain resident in ROM and therefore independent of RAM - but without RAM the functions are limited to port operations and RAM testing. Loading, booting, disk ops and code debugging need RAM.

It is more useful if loaded to high RAM so that it can be available even after loading of CP/M or whatever OS.

I configured my version to be resident in the boot EPROM socket on a machine. Your reference to a separate board as a general-purpose tool is interesting. I think such a board would work best as a kind of in-circuit emulator with an address-switchable serial port and EPROM socket, so that the monitor capabilities could be available without conflict with the hardware of the machine under test. So it might be more a matter of adding an EPROM (or any other ROM device) to some kind of ICE with serial i/o to the outside world.

This is all open code, so any adaptation is encouraged. Every hardware configuration is likely to be unique, and the monitor has to work below the abstraction layer of an operating system (ie there is no BIOS or system calls). So every working configuration of a monitor will be different at the point of code assembly.

I see this as being useful once the basic hardware checks (using front panel, data probe, oscilloscope or whatever technique) have established that you have a working bus, CPU, ROM read, and if possible console i/o. RAM comes next, then any other system ports and finally disk i/o and boot firmware/software.

Once you have an operating system loaded, you are in another world...
 
Back
Top