View Full Version : MPM with user buffers

August 3rd, 2010, 03:07 AM
I've just spent a day deep inside the source code for MPM. This a nifty operating system! A scheduler for programs, bios calls to pass the cpu to other programs (which doubles as a timing loop), an accurate clock, and, of course, multiple programs running at the same time.

I am trying to solve three seperate problems, and I think I can see a way to do all three with some simple modifications to the bios.
1) Networking - where a program running in the background takes bytes from the main user and wraps them up in packets with a source, destination etc, and also decodes packets and passes them to the main user. This packet program is always running in the background.
2) An autoexec - to auto run one or many programs on startup
3) Text windows - 4 users displayed in resizable windows on the same 80x40 display.

I'd be very grateful for any MPM experts out there!

Initially I'd like to get this working on the Altair SIMH - particularly because the recompilation is much much faster.

I do have some bios (xios) code to run an autoexec, and I have had a packet program running on user 2 and the concept does work. But the code is a bit messy. Thinking about windows, I came to the conclusion that all I/O from a user needs a buffer of some sort. How big? Well when doing an xmodem transfer I can get 38kbaud so that is about 4k per second and at 50 ticks a second, that is about 80 bytes in a tick. The biggest amount of data in a buffer might be a 132 byte xmodem packet. So maybe make buffers 256 bytes?

I'm thinking 4 users in 4 windows. Maybe user 3,4,5,6. Each of these users has a 256 byte input buffer (use a circular buffer), and a 256 byte output buffer. So sacrifice 2k of space in upper memory. Hopefully it will fit! If not, there is a version of the SIMH that is hard drive only so can save some space on the floppy driver code. Or store in an upper bank of ram (if I can work out how to restore the current bank - I can't seem to find where that is stored).

Anyway, the theory is that for:
1) networking - bytes might come in on user 2 which talks to a real serial port and are routed via a small program to user 3. (this program has a very low cpu overhead as it scans for a byte, then if none present does an xios call to pass control to the next process). On user 3 is a the packet decoder/encoder, and the decoded bytes are passed to user 4.
2) autoexec - the startup code in the xios feeds some bytes to one of these buffers eg SUBMIT AUTOMPM. Once one submit program is running it can spawn others on other users.
3) Windows. Run a controlling program on user1 that connects to the keyboard/display. Draw some text boxes (eg using vt100 codes to move the cursor around). Check user 3,4,5,6 buffers and display any text. If one window is in front of the other, don't display text that is hidden, but store it for later if the focus on the windows changes. Direct keyboard to user 3,4,5,6 depending on which text box has the focus.

I've spent some time trying to understand the queue functions in the xdos, but I don't think they can be used to connect to users. But maybe they can. In any case, circular buffer code is fairly small.

Thoughts and advice would be most appreciated.

August 12th, 2010, 05:49 AM
Thanks ++ to some wonderful support from Peter Schorn (SIMH) and Max Scane, below is a screen grab of MPM running multiple consoles on the SIMH. This is an sbasic program running in user 0, with access to users 4-7 on a console screen. Each virtual console has a 256 byte input and output buffer and also a virtual VT100 terminal, so cursor move commands work for things like Wordstar. So it is possible to have Mbasic and BDS C and Wordstar all running at the same time. There is a custom xios that stores some bytes for running an autoexec, and autoexec programs can run programs on any other user so anything can be run as part of an autoexec. Windows (ok, I'll call them Frames to avoid copyright issues *grin*) can be resized and moved.

Next step is to port this to a real board. There are two physical boards I am thinking of - the Propeller emulation, and the v2 of the N8VEM which has been designed for banked memory (both use the same 512k sram chip). I'd be very hopeful this concept could be extended to other vintage hardware.

Both platforms will give some better looking graphics - the Propeller has some nice extended character graphics from 128 to 255 with proper borders and nice rounded corners for the boxes. And some of the new boards coming out for the N8VEM have pixel based boxes and lines. So it should be possible to put text boxes inside containers that look like more familiar boxes. Then it might be possible to move towards colors and objects like buttons and radio buttons, all being driven by CP/M and MP/M based software. This is totally retro-geek I know, but it is great fun!

^N to change consoles, ^O to quit ..............................................
.+-User4-------------+.......................|6A>mbasic |..
.| |...+-User5----------+..|BASIC-80 Rev. 5.21 |..
.| |...| |..|[CP/M Version] |..
.|MP/M II V2.1 |...| |..|Copyright 1977-1981 (C) by Micr|..
.|Copyright (C) 1982,|...|MP/M II V2.1 |..|Created: 28-Jul-81 |..
.| |...|Copyright (C) 19|..|19503 Bytes free |..
.|4A>SUBMIT AUTOEXEC |...| |..|Ok |..
.| |...|5A> |..|10 print "Hello World" |..
.|error on line 001 n|...| |..|run |..
.|4A> |...| |..|Hello World |..
.| |...| |..|Ok |..
.| |...+----------------+..| |..
.................................................. ..............................
.| WordStar, CP/M Edition, Release 4 |..
.| O P E N I N G M E N U |..
.| D open a document L change logged drive/user |..
.| N open a nondocument C protect a file |..
.| P print a file E rename a file |..
.| M merge print a file O copy a file |..
.| S check spelling of document Y delete a file |..
.| I index a document F turn directory off |..
.| T table of contents Esc shorthand |..
.| X exit WordStar R run a program |..
.| J help |..
.|DIRECTORY Drive A |..
.| |..
.................................................. ..............................

August 12th, 2010, 10:22 AM
Congrats! Thats some cool stuff..

I know the feeling of getting something running, after a pile of work. Especially on this old stuff, where it isn't "run the installer, click icon, enjoy"..

Even in DOS, you didn't have the option to compile most software using assembler (m80 was new to me).

August 12th, 2010, 10:30 AM
Trying to understand if you want to run a batch file every time a terminal logs in (i.e. one per terminal) or when the system boots (system terminal 0)?

August 13th, 2010, 06:07 AM
I only want to run the batch file once when the system boots. But AUTOEXEC.SUB can spawn any number of programs on any other user so it doesn't really matter which user it is set up to run on (I've got it on user 4). The new buffer code in the xios allows users to talk to each other (or they can also communicate by reading and writing files to disk, though this is slower).

Next job is to port this from the SIMH to a real board. Hopefully it won't be too slow.

August 13th, 2010, 08:49 AM
The way CP/M systems do this is to have the BIOS plug the name of a file into the CLI when it loads for the first time. Not the cleanest thing, but it was done. Does MPM have a similar area that can be written to?

August 13th, 2010, 03:44 PM
Yes I agree it is messy. Pre-storing bytes in CP/M is easier than MPM - when MPM boots up it seems to start polling for input before the A0> prompt appears. The initial code padded the buffer with a whole lot of dummy characters (0 or 13) before the autoexec message. The newer code has a counter that counts from 0 up to 255 every time the input is polled. When it polls the input the 254th time, it loads the message into the buffer. When it gets to 255 the counter stops and so only runs once (though you could reset it I suppose with an external command). With a delay of 255 on the SIMH the autoexec message appears about 1 second after the prompt appears. This variable probably will need changing on a real board.

August 22nd, 2010, 05:30 AM
At last, after many many recompiles, this crazy idea is running on a real MPM computer.

What is the point? Well, I'm glad you asked! The reason for all this is that I want to test some network protocols between boards, and for debugging purposes, it is a lot easier to debug networking between two different users on the same board. The multiuser environment makes it much easier to switch between a program doing transmission and another receiving, and to print debug messages for both at the same time.


August 25th, 2010, 05:46 PM
Attached is some software. The modified mpmxios, the windows program and a new program called BABEL which translates protocols.

The hardware description is: keyboard, 2 serial ports, vga monitor, 20x4 LCD display and the 8 MPM users. Consider these as 13 different objects, and there are lots of different ways they can all be connected. eg, you might have a keyboard and a vga display. But for out in the field or for a small computer running off a solar panel, you might only want a keyboard and a 20x4 LCD display. Or you might want a board that can take individual bytes and translate them to packets so they can go to the correct destination on a shared RS485 party line or a wireless network - that might involve data coming in one serial port and going out the other port, for interfacing vintage computers to each other via a network.

Each one of these options would need a different program.

But, is there a way of writing a generic program that can link things together?

Consider a keyboard connected to user 7 input. The keyboard number is 8 and user 7 input is 21. So I write that as


On a new line, we want to grab output from user 7, and send it to the LCD display, and out serial port to. I write that as


The buffer is cleared at the beginning of each line, and generally the first object in a line is something that creates bytes, eg a keyboard, or output from a user. Subsequent objects don't destroy the data, so data goes to a display, but the buffer still has data, so it can then go to a serial port.

One can then add other objects, eg object 14 looks for a ^X and exits if it finds one. So, on a new line, connect the local keyboard to the ^X object (8.14) and one can then abort the program and go back to MP/M.

So, with a two line .ini file, one can reconfigure the program so user 5 is connected to the serial port and hence to a terminal program on a PC. Or with a different two line file, change the program to a 'store and forward' router that can wrap data in packets.

This is an example of the bootup message:

Welcome to the Babel communications program for MP/M
The following value should be the same as the BNKXIOS location on MPM boot: C000
My name is: ALPHA
Remote name is: BETA
Multiple connnections between the following objects:
1 - Serial port 1 read
2 - Serial port 2 read
3 - User 3 read
4 - User 4 read
5 - User 5 read
6 - User 6 read
7 - User 7 read
8 - Local keyboard read
9 - VGA display write
10 - 20x4 LCD display write
11 - Store and forward packet buffer
12 - Raw Byte to Packet translator (adds destination)
13 - Packet to Raw Byte translator
14 - Quit on control X (^X)
15 - Serial port 1 write
16 - Serial port 2 write
17 - User 3 write
18 - User 4 write
19 - User 5 write
20 - User 6 write
21 - User 7 write
22 - Test if packet for me
Connections list:
Thread 0 is 8 => 9 => 10 => 15 => 16 => 14
Thread 1 is 2 => 21
Thread 2 is 7 => 16
Starting LCD
Start program

MP/M is turning out to be an amazing program capable of all sorts of new tricks. Back to coding - the next challenge is to have 4 computers in pairs, exchanging files in packets at the same time via wireless.

Thanks for looking.

Cheers, James Moxham

September 25th, 2010, 06:38 AM

This is where we are up to. 4 little terminals - the first is a keyboard entry terminal as there is a delay of a few seconds while data comes back. The second is data coming back from a board in another room with data being transmitted via radio packets. The other two terminals are local MPM users.

Next step is file transfers, either with xmodem or perhaps a new bittorrent type of protocol. Bittorrent will be slower, but it will be more efficient to distribute new programs via a radio mesh because a packet can be transmitted once and received by many boards all at the same time.

September 25th, 2010, 07:35 AM
Super-cool! I'll have to take another look at this when I finally acquire a CP/M-oriented system.