Dr_Acula
Experienced Member
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.
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.
