16-bit homebuilt computer project

A functional interrupt-driven RS/232 driver is currently in operation, supporting hardware flow control at a baud rate of 9600 bps. Although higher baud rates are achievable, stability has yet to be verified. Helper routines have been developed to facilitate the printing and retrieval of strings, as well as hexadecimal and decimal numbers. Kernel routines are in place to identify available RAM/ROM and installed devices. This setup has enabled the development of a terminal program that connects to actual hardware via serial communication. Most shell functions displayed in the terminal program screenshot remain in the early stages of development, providing a preliminary idea of the intended functionality. The goal is for the monitor program to be fully operational without excessive complexity, as the primary focus is to transition to a C port for more advanced software development. While assembly programming offers intellectual stimulation, it is considerably slower. A colleague has provided an EPROM emulator designed to expedite the development process of the Monitor/OS kernel. Previously, it was inefficient to rewrite kernel ROM for testing new and often flawed code. The EPROM emulator connects via a ribbon cable to the socket typically occupied by a ROM chip, using internal SRAM to simulate the EPROM. It can be programmed with a standard parallel cable when connected to a PC, requiring no external power as it draws from the emulated chip's host. To a PC, the device functions like a printer, allowing SRAM programming by simply copying a binary image to /dev/lp0 in Linux. This streamlined process is expected to significantly enhance software development efficiency, reducing the time from assembly coding to execution from several minutes to mere seconds. Although the emulator has not yet been tested, its documentation has been thoroughly reviewed, and confidence in its compatibility with the current setup is high. The construction of a custom ribbon cable to match the pinouts of the 29F010 BIOS/kernel EEPROM chip is the next step. The emulator's limitation of 64kB is manageable, as the current usage of 128kB for the ROM chip can be adjusted for convenience.

The RS/232 driver operates based on interrupt-driven architecture, allowing it to efficiently handle serial communication without blocking the main execution thread. The hardware flow control ensures that data transmission is synchronized between the communicating devices, preventing data loss during high-speed transfers. The implementation of helper routines enhances usability by enabling the easy conversion and display of data types, which is critical during debugging and monitoring processes.

The kernel routines for detecting RAM/ROM and installed devices provide essential feedback regarding the system's resources, facilitating better resource management and allocation. The terminal program serves as an interface for users to interact with the hardware, enabling commands and data exchanges in real-time.

The EPROM emulator is a significant advancement in the development workflow. By eliminating the need for physical ROM programming, it allows for rapid iterations and testing of code changes. The internal SRAM can be easily updated, which is crucial for debugging. The programming method using the parallel port is straightforward, making it accessible for developers familiar with Linux systems.

To address the limitation of the emulator, strategies can be devised to segment the code and data efficiently, ensuring that all necessary functions fit within the available memory. This approach may involve optimizing the code to utilize the memory more effectively or implementing a paging mechanism to swap segments in and out of the emulator's available space.

Overall, the integration of the RS/232 driver, kernel routines, and the EPROM emulator represents a robust foundation for the Monitor/OS development, paving the way for future enhancements and more complex software implementations. This streamlined approach is anticipated to yield significant productivity gains and facilitate the transition towards a more advanced programming environment.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: 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. 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. 🔗 External reference