Larger TPA = more room for those big BASIC and C programs, right? Alt F1 etc makes a lot of sense.On the propeller emulation for instance, we set aside 16k in the ram for a huge circular PUNCH device buffer. Any user can read and write to this. You can also add code to dump data here when it also goes out a serial port or to a display. One could think of a very simple system that takes each byte and turns it into two bytes where the first byte is the user number and the second byte is the data.
Then whatever program decodes the data stream could reconstruct which bytes belong to which user, and put them in the appropriate window.
The propeller includes an internal font with vertical lines, horizontal lines and the corners of boxes. I wrote a tiny demo program to draw a box and it looks very good. So draw a window in this way, then put each byte in the right window. Add some scrolling. Maybe even add vt100 commands for each window. It could be quite a fun little project.
10 REM 138 = top left corner 20 REM 139 = top right corner 30 REM 140 = bottom left corner 40 REM 141 = bottom right corner 50 REM 142 = horizontal line 60 REM 143 = vertical line 70 PRINT CHR$(138);STRING$(7,142);CHR$(139) 80 PRINT CHR$(143);" Box ";CHR$(143) 90 PRINT CHR$(143);" ";CHR$(143) 100 PRINT CHR$(140);STRING$(7,142);CHR$(141) Regarding the function calls, that looks absolutely perfect.Is the MPM programmers manual available somewhere online? I've only got the Users Guide and there is nothing mentioned there.
How do you call those system calls? eg 141, is that a call to FC00 plus the hex value of 141?
If so, I've just been playing around with MBASIC 10 MYPROG = &HFC00 20 CALL MYPROG 30 PRINT "FINISHED"which never gets to line 30 as a call to FC00 returns to the A1> prompt. So I know this is working.
I think you can pass parameters CALL MYPROG(I,J,K) though I'm not sure how those map to the A BC DE registers as my MBASIC book says this is beyond the scope of the book. SBASIC and BDS C can also do system calls so if this is how they work it could be very useful.
Am I on the right track do you think? Cheers, James Max Scane wrote:
Hi James, The hardware to do memory banking is already in the N8VEM. It is used for the RAM and ROM disks. I use the same hardware in cp/m 3. I just reduce the RAM disk by 1 track. My main interest with cp/m 3 is the modular bios and the banked support. With 2.2 each driver you add reduces the TPA, with cp/m 3 there is a separate memory bank that is used for drivers (with a smaller footprint in common RAM) so you can have a larger TPA. I have IDE, RAM/ROM disk, floppy and parallel port IDE disk and still have around 59KB of TPA. CP/M 3 also supports larger than 8MB disks, although I can't fill 8MB at the moment. Regarding the PROP IO terminal I was thinking of how Linux does it, eg Alt+F1 for screen 1, Alt+F2 for screen 2 etc. Of course, you need support in MP/M for this also. One other thing, MP/M supports CP/Net as a type of server which I would like to get going once I have MP/M up and going. Regarding the delay call. It is a just a simple system call you don't need to delve into the BIOS: (from the mp/m programmer manual) FUNCTION 141: DELAY Entry Parameters: Register C: 8DH DE: Number of Ticks The Delay function delays execution of the calling process for the specified number of system time units, thus allowing other processes to use the CPU while the specified period of time elapses. Use of Function 141 avoids the typical programmed delay loop, which should be avoided under MP/M II because it consumes the CPU. The system time unit is typically 60 Hz (16.67 milliseconds), but can vary according to application. For example, it is likely that in Europe it would be 50 Hz (20 milliseconds). The calling process passes a 16-bit integer in register pair DE which specifies the number of ticks the process is to be delayed. Since calling the delay procedure is usually asynchronous to the actual time base itself, there is up to one tick of uncertainty in the exact amount of time delayed. Thus, a delay of 10 ticks guarantees a delay of at least 10 ticks, but it may be nearly 11 ticks. The other function that may be of interest is: FUNCTION 142: DISPATCH Entry Parameters: Register C: 8EH The Dispatch function causes MP/M II to determine the highest priority ready process, and then give that process the CPU. Function 142 is intended for non-interrupt driven systems in which it is desirable to enable a compute-bound process to periodically relinquish the CPU. Since all user processes usually run at the same priority, invoking Dispatch at various points in a program allows other processes access to the CPU in a round-robin fashion. Dispatch can also safely enable interrupts following the execution of a disable interrupt instruction (DI). There are no parameters passed in register pair DE, and no values returned in register A. The process calls Function 142 by passing the function number 8EH in register C. Note: Calling Dispatch does not remove the calling process from the Ready List. Regards, Max On Jul 20, 3:21 pm, James Moxham <mox...@internode.on.net> wrote:Hi Max, Ah - I missed the bit about the 16k vs 32k block sizes. Yes, as you say, V2 would be better seperating into 16k blocks so (somehow) you can keep the top 16k of a 64k group as common and switch out the bottom 48k. There must be a simple hardware circuit that can do this. Is it a matter of decoding 2 bits - bits 14 and 15, and if they are 00 01 or 10 do nothing, and if they are 11 then make bits 16,17 and 18 all Low. I think that becomes some AND OR and Invert gates. CP/M3 sounds interesting. I never used this OS - what nifty things can it do compared with 2.2? Re the propeller as a terminal, yes, I'm sure there is something clever that can be done. There is plenty of memory to keep copies of multiple terminals in 'windows' and display them one above the other, with arbitrary sizes for each window. Re the timing loop problem: Attached is the MPMXIOS.MAC file which is essentially the file from the ALTAIR SIMH. I think a clue is in the ; bios ; jump vector for individual subroutines and interestingly, I see that in the MPM bootup there is a message XIOSJMP TBL FC00H 0100H and I wrote a quick little MBASIC program to peek FC00 and there certainly appears to be a jump table there. I'm pretty sure it is the one I need. So to list them off ; bios ; jump vector for individual subroutines jp commonbase jp warmstart ; warm start jp const ; console status jp conin ; console character in jp conout ; console character out jp list ; list character out jp rtnempty ; punch not implemented jp rtnempty ; reader not implemented jp home ; move head to home jp seldsk ; select disk jp settrk ; set track number jp setsec ; set sector number jp setdma ; set dma address jp read ; read disk jp write ; write disk jp pollpt ; list status jp sectrn ; sector translate jp selmemory ; select memory jp polldevice ; poll device jp startclock ; start clock jp stopclock ; stop clock jp exitregion ; exit region jp maxconsole ; maximum console number jp systeminit ; system initialization db 0,0,0 ; force use of internal dispatch @ idle ; jmp idle ; idle procedure commonbase: jp coldstart swtuser: jp $-$ swtsys: jp $-$ pdisp: jp $-$ xdos: jp $-$ sysdat: dw $-$ I was looking at modifying the idle procedure jump so it did the same thing as an interrupt. But I just noticed underneath is a jump "swtuser". I wonder if that means "switch user?" Cheers, James Max Scane wrote:Hi James,MP/M's memory architecture is a little bit different to what you havedescribed. It has the concept of common memory and banked memory.Common memory extends down from the top of the (logical) memoryaddress space (ie. FFFF) to a point called common base. The size of common memory is generally hardware dependent but needs to be sufficient to hold all of MP/Ms common code.Banked memory starts from 0 and extends up to common base. There aremultiple banks of memory that can be switched in as required. For example if you had a common area of 16KB then the maximum bank size would be 48KB. With the N8VEM V1, the common area size is 32KB and the maximum bank size is 32KB. When the N8VEM V2 is available I think you can have a 16KB common with 48KB banks.The bank size is important because it limits the available TPA for anapplication.When you generate a system you describe how the memory is calved up. Any .com application needs a bank that starts at 0 to run. Non 0starting banks can be ised but you ned a .prl or .spr application.I have started on an implementation of MP/M for the N8VEM but I gotdelayed building a banked version of CP/M 3 which is now completed. I have the loader built but need to finish the XIOS. The implementation I am working on uses the Z80 peripherals card as both extra serialports as well as using one of the CTC channels as a timer interrupt. There are actually two clocks in MP/M, one for the RTC and one fortimer que management. To have multiple users, you need to have a UART for each user. One thought comes to mind with the PROP IO card, maybe it could emulate multiple windows (terminals) so you could have several terminal ports available. I guess that there maybe a RAM issue as you would have to store multiple copies of Video RAM.Regarding your timing loop problem, you need to think in terms of amulti-tasking environment. Try to avoid loops they waste cpu cycles that can be used by other processes. MP/M has a call that will delay a process for a period of time (expressed in ticks I think) that would be more appropriate. Get a hold of the MP/M programmers guide and have a look at the XDOS calls I think they are what you are looking for.Regards, Max. On Tue, Jul 20, 2010 at 10:51 AM, James Moxham (Dr_Acula)<mox...@internode.on.net <mailto:mox...@internode.on.net>> wrote:Hi all, My purpose in posting this is two fold:1) To flush out any MP/M experts (I know you are there!) and 2) to discuss running MP/M on the N8VEMTo 2) first. I'm currently running MP/M on the propeller emulation and learning alot about how it works. With all the progress being made on the N8VEM running hard disks and the like, I think MP/M ought to be possible on the N8VEM.A couple of issues. One is that you need banked memory, one slot of64k memory for each user. But it might be possible to, say, allocate two banks taking 128k, and still leave space for a slightly smaller ram disk.Second issue - a regular interrupt. Could this just be a 555 drivingthe interrupt line?Third, if you have two users then you need two serial ports. Thatmight involve rewiring the uart in some way (? like the mini N8VEM) or (probably the better solution) using an external board that increases the number of serial ports with some more uarts (does such a board exist).To 1) now, Maybe MP/M has no immediate practical use for many, but for me I seeit as a way to run background processes without having to keep changing the BIOS or CP/M. Specifically, what I'm working on is running a network packet protocol in the background on one of the users which takes console characters and wraps them up into packets, and also decodes packets and sends them to the console transparently.But I have run up against a small problem - when I run a timing loopon one user, it slows down other users too much. What I'm looking for is a bdos call or something that tells MP/M, "don't worry about me, go on to the next user". Then repeat that n times rather than having a timing loop.So if anyone is an expert on MP/M, help would be most appreciated. But in a more general sense, I'm also thinking about MP/M running onthe N8VEM - maybe even as a way of having multiple users all on one screen, each user running their own program in their own text "window".Thoughts would be most appreciated. --You received this message because you are subscribed to the Google Groups "N8VEM" group. To post to this group, send email to n8...@googlegroups.com <mailto:n8...@googlegroups.com>. To unsubscribe from this group, send email to n8vem+un...@googlegroups.com <mailto:n8vem%2Bu...@googlegroups.com>. For more options, visit this group at http://groups.google.com/group/n8vem?hl=en.--You received this message because you are subscribed to the Google Groups "N8VEM" group. To post to this group, send email to n8...@googlegroups.com. To unsubscribe from this group, send email to n8vem+un...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/n8vem?hl=en.mpmxios.mac 24KViewDownload