Attached is an updated zip of the A.DSK file.
1) MPMXIOS.MAC edited so ticks = 5 rather than 50. This has been the key to getting MPM working without crashing every 10 minutes.
2) New MPM compiled on the board with DO MPMSYS, new MPM.COM created (I love the way the propeller can recompile operating systems!)
3) XM1.ASM and XM1.COM placed on USER 1 area for xmodem transfers via a terminal program
4) XM2.ASM and XM2.COM placed on USER 2 area for xmodem transfers via a terminal program
5) a small file LCDBOOT.COM and LCDBOOT.ASM on USER 0 which displays a signon message on the LCD display
XMODEMF.COM is the original program used to transfer files to USER 0 and this is already on the disk. If you boot up with USER 0 on the VGA screen you need to run MPM to do any file transfers. If you boot up with USER 0 on the serial port you can do file transfers to CP/M.
My AUTOEXEC.SUB file is:
LCDBOOT
MPM
I've updated my webpage below with links to the above files.
So...
pullmoll, would it be ok to make this new A.DSK the standard one?
I'm doing some experiments with driving a TV display.
I haven't had any luck with the simple graphics demo that comes with the propeller tool - I tried changing the pin definition from 001_0101 to 010_0001 which someone on another thread had suggested changes the basepin from 12 to 16. But no luck.
I have had some success though with the qZ80 object. Changed from vga to tv at the bottom of the Con section. But it is intermittently going out of sync so I get text for a few seconds then a blue screen for a few seconds. PAL is cleaner than NTSC (the display can do either) but neither are locked in properly.
I'm going to try a shorter cable, but is there a way to tweak variables to get it to lock more solidly? I suspect if that is possible it is the variable list at the beginning of the Con section in TV80.Spin but I'm not sure which ones:
#ifdef NTSC
'' NTSC 80x25 using a 6x9 font
ocols = 80 ' number of columns
orows = 25 ' number of rows
ocolsfrq = 22_478 ' Hz per active pixel
oequal1 = 6 ' number of equalization pulses
oserr = 6 ' number of serration pulses
oequal2 = 6 ' number of equalization pulses
oblank1 = 25 ' number of blank lines
oactive = orows*FONT_H ' number of active lines
oblank2 = 1 ' number of blank lines
ohalf = 343 ' vscl half line
obackp = 94 ' vscl back porch (sync to active)
ofrontp = 62 ' vscl front porch (active to sync)
oequal = 25 ' vscl equalization pulse (sync/2)
osync = 50 ' vscl sync pulse
osynch = 293 ' vscl half-sync
oequalh = 318 ' vscl half-equal
ovsclch = 4*FONT_W ' vscl character
ictra = 12 ' CTRA with PLLdiv
ifrqa = 231701456 ' required FRQA value (5MHz*16) (xfrqa replaced by start routine)
ifrqb = $4924_0000 ' 40/140 << 32 = 1,227,096,064
ifrqa_80MHz = 289626816 ' required FRQA value (5MHz*16)
ifrqa_96MHz = 241355680 ' required FRQA value (6MHz*16)
ifrqa_100MHz = 231701456 ' required FRQA value (6.25MHz*16)
ifrqa_104MHz = 222789856 ' required FRQA value (6.5MHz*16)
ifrqa_108MHz = 214538384 ' required FRQA value (13.5MHz*8)
#endif
'--------------------------------------------------------------------------------------------------
#ifdef PAL
'' PAL 80x25 using a 6x9 font
ocols = 80 ' number of columns
orows = 25 ' number of rows
ocolsfrq = 22_321 ' Hz per active pixel
oequal1 = 4 ' number of equalization pulses
oserr = 5 ' number of serration pulses
oequal2 = 5 ' number of equalization pulses
oblank1 = 49 ' number of blank lines
oactive = orows*FONT_H ' number of active lines
oblank2 = 30 ' number of blank lines
ohalf = 342 ' vscl half line
obackp = 100 ' vscl back porch (sync to active)
ofrontp = 55 ' vscl front porch (active to sync)
oequal = 24 ' vscl equalization pulse (sync/2)
osync = 49 ' vscl sync pulse
osynch = 293 ' vscl half-sync
oequalh = 318 ' vscl half-equal
ovsclch = 4*FONT_W ' vscl character
ictra = 12 ' CTRA with PLLdiv
ifrqa = 287604888 ' required FRQA value (5MHz*16) (xfrqa replaced by start routine)
ifrqb = $4924_0000 ' 40/140 << 32 = 1,227,096,064
ifrqa_80MHz = 287604888 ' required FRQA value (5MHz*16)
ifrqa_96MHz = 239669904 ' required FRQA value (6MHz*16)
ifrqa_100MHz = 230083104 ' required FRQA value (6.25MHz*16)
ifrqa_104MHz = 221233760 ' required FRQA value (6.5MHz*16)
ifrqa_108MHz = 213039920 ' required FRQA value (13.5MHz*8)
#endif
any help would be most appreciated.
(on my real TV I can tweak the tuning knob but this little TV display has no tuning knob)
Do you have a schematic for the propeller plug? I did look at this at one stage and I think it just needed some headers.
Sorry, that code isn't working. No display at all on two TVs. Is still a partial synch on the qZ80 code so the hardware I think is ok.
I think the first variable to try tweaking might be long tv_broadcast 'broadcast frequency (Hz) write-only
However, I can't see where this is actually set in the program. It gets mentioned in the Var section of graphics_demo, and it gets mentioned in the TV object as
'' long tv_broadcast 'broadcast frequency (Hz) write-only
and it gets mentioned at the bottom of the graphics_demo
long 0 'broadcast
but I'm not sure the value would be zero for frequency.
Addit - I tried tweaking ifrqa_80MHz = 287604888 ' required FRQA value (5MHz*16) in qZ80 but it just gets worse in either direction, so the synch problem is something else maybe.
@Dr_Acula: The TV 80 code synched on my "Orion" PAL CRT monitor in both, PAL and NTSC modes. For NTSC I had of course to shift the monitor's vsync potentiometer a bit until the sync snapped in, but 60 Hz are quite possible with this thing. You could perhaps try to play with the vsync position by changing oblank1 and oblank2 (increase oblank1 and decrease oblank2 by the same amount). The length of the serration and equalization pulses should be okay.
25 x 9 = 225 active scanlines, which is a lot for NTSC. Perhaps you can try to go with a 80x24 display by decreasing orows to 24.
Did you try Cluso99's original 1pin TV object? This is the code where mine is derived from. If you get Cluso's code to sync, then I must have changed something else inadvertently.
Finally: what resistor do you use? Perhaps you can get a stronger signal with a lower value. For me it worked with any of the 3 TV pins, though.
Re "For NTSC I had of course to shift the monitor's vsync potentiometer a bit until the sync snapped in,"
That might be a clue as I don't have any adjustments on the monitor. (nor on my TV).
This TV output is proving to be quite a challenge. I'm mildy annoyed with myself as I did get a TV output about 4 months ago but I can't find that code.
It ought to be simply a matter of changing the pins on the existing demo code from pin 12 to pin 16 but the examples of this scattered through the forum are a little confusing - do you change the binary value 001_0101 to 010_0001 or do you change some other variable? I've never really quite understood those binary values anyway even though they are documented here
The select group makes sense, but the other 4 bits do not, as they are described as bits 3..0 and it then goes on to list 8 bit codes. I don't really understand the difference between 0001 broadcase and 0101 baseband.
The circuit is very simple - 1k1 on pin 16, 560R on pin 17 and 270R on pin 18.
I'm not sure how to add Cluso's 1 pin demo - does this replace TV80?
Even though this is partially working on the qZ80 emulation, I think I need to go back to a very simple TV demonstration and build it up from there. I am not sure which variables to change;
tvparams long 0 'status
long 1 'enable
long %001_0101 'pins
long %0000 'mode
long 0 'screen
long 0 'colors
long x_tiles 'hc
long y_tiles 'vc
long 10 'hx
long 1 'vx
long 0 'ho
long 0 'vo
long 0 'broadcast
long 0 'auralcog
But going back through the description of those variables
long tv_status '0/1/2 = off/visible/invisible read-only
long tv_enable '0/? = off/on write-only
long tv_pins '%ppmmm = pins write-only
long tv_mode '%ccinp = chroma,interlace,ntsc/pal,swap write-only
long tv_screen 'pointer to screen (words) write-only
long tv_colors 'pointer to colors (longs) write-only
long tv_hc 'horizontal cells write-only
long tv_vc 'vertical cells write-only
long tv_hx 'horizontal cell expansion write-only
long tv_vx 'vertical cell expansion write-only
long tv_ho 'horizontal offset write-only
long tv_vo 'vertical offset write-only
long tv_broadcast 'broadcast frequency (Hz) write-only
long tv_auralcog 'aural fm cog write-only
There is the variable 'pins and I'm guessing 010_0001 and then there is the variable tv_status and should that be 2 to make it visible. (I tried those but no luck). Or maybe 010_0101?
Too many things to change. Some of these bits of code have come from existing code in the Obex so maybe I need to go back to the original source code that works on the demo board and just change one thing to make the pins start at pin 16 instead of pin 12.
If that does not work - maybe I just have two TVs that are not able to sync with the signal.
My 1-pin driver is on the obex. It is simple to change the pins (I only use 1). It is a standalone demo so you can play with it. If you download an older version it is easier to change the parameters. There is a reasonably good explanation in the code as to how TV works.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
1) Lots of progress with the networking code. I can now send a command "TYPE MYFILE.TXT" from the PC to the Propeller as a packetized piece of data, this is then interpreted by a program in user2, the data passed to user0 as a CP/M command, then the output captured and send back as packets.
The source and destination are 4 bytes, so could be an IP address, and hence there is enough information to route a packet via the internet if required. There is still a bit more to code but the fundamentals are working now. I can send a command to a particular board telling it to route all output to another board. Or turn off routing output. Packets not for a board are forwarded on, so this leads towards being able to log into remote boards via multiple hops, and still have a normal (albeit slow) session on MP/M.
2) Minor documentation error
'**********************************************************************************************
'
' Output an instruction code to the LCD
'
output_punstat
mov lmm_pc, #lmm_ram_rs
jmp #lmm_command0
'**********************************************************************************************
'
should be ' Output an instruction code to the Punch device
3) Pullmoll has very cleverly added the ^P command where all text output from a console is directed to a huge 16k circular buffer in the ram chip. The only catch is (and this is a CP/M problem) is that not everything goes there - specifically, some output from certain programs, eg from within MBASIC or WORDSTAR
I have added a little #ifdef that routes everthing from the vga display to the circular buffer. Near the beginning of the CPM.SPIN code I added this
'#define USER0_TO_PUNCH
' Define this to send all vga output also to the punch device buffer
' which is 16k in size. Read back out via ports $12 and $13
and in IO.SPIN I modified this bit of code to output to the buffer if required
'**********************************************************************************************
'
' Write to the console #0
'
conout_char
#ifdef USER0_PS2_VGA
mov lmm_pc, #lmm_vt100_out
call #lmm_func
' experiments trying to send all vga data to the punch output as well
' replicates ^P but also works within programs eg mbasic, that bypass CP/M system calls
#ifdef USER0_TO_PUNCH
mov lmm_pc, #lmm_ram_wr
call #lmm_func
#endif
#else
mov tx0_ret, conout_char_ret
jmp #tx0
#endif
conout_char_ret
ret
I wonder if this could be added to the 'official' version?
4) Talking of other minor tweaks, maybe it is a matter of personal preference but I like white on blue rather than yellow on blue. Perhaps because my old school colours were white and blue...
Anyway, I added this bit of code in the colour definitions to make it easier to change if needed. These are binary values (does %% mean octal?)
' background and foreground colors - select one of these and comment the rest out
' %00001000_11111100 ' Blue_White blue =3/4 power 10, white =full
' %00001000_11110000 ' Blue_Gold
' %00000000_11111100 ' Black_White
' %00000000_00110100 ' Black_Green + tiny amount of blue
' %00000000_11100000 ' Black_Orange
' wordfill(@vga_colors, %%0013_3303, 40)
wordfill(@vga_colors,%00001000_11111100, 40)
5) Now for the complicated part. I'm having a lot of trouble loading files on one user when a second user is running a program. I tried removing the delayed write but this made no difference (the problem is with reads, not writes). I tried dropping the interrupt rate from 5 per second to 1 per second but that didn't help (50 does not work at all as discussed previously). I note in the interrupt section this bit of code that is supposed to delay things if a disk access is happening but I'm not sure if that is happening.
' Timer interrupt executed at a rate of timer_delta cycles
'
timer_int
add timer_tick, timer_delta ' schedule next interrupt call
tjz irq_ptr, timer_int_ret ' no IRQ vector set?
tjnz hdsk_params_ptr, timer_int_ret ' do not interrupt while reading/writing hdsk params
wrlong timer_addr, irq_ptr
timer_int_ret
ret
Perhaps the best way to demonstrate this is to run two programs at the same time. This is a little mbasic program:
list
10 FOR A=1 TO 100
20 FOR B=1 TO 100
30 NEXT B
40 PRINT ".";
50 NEXT A
Ok
and it prints dots on the screen at about one per second.
When you run it on two users at once the dot rate decreases. From this I conclude that MPM perhaps bypasses a user if they are just sitting at the 1A> prompt?
But the real problem is when you load mbasic on one user and set this program running, then attempt to load any program on the second user (mbasic, wordstar, or anything that requires reading a big file off the disk). Disk access slows right down and the disk access light flashes briefly about once a second.
Eventually after about a minute mbasic loads.
The first experiment suggests to me that doubling the demands on the CPU halves the execution speed. This is not unexpected.
The second experiment shows that loading a file takes about 10 times longer if one program is already running.
I am not sure why this would be. Perhaps there is a time factor somewhere in the disk access. Perhaps continuous disk access is much more efficient than discontinuous access?
I am thinking this last possibility is the most likely - eg it is having to reinitialise something on the sd card when access is discontinuous.
I am wondering if there is a solution. Even if it is as brute force as completely turning off the interrupt timer while one user is accessing the disk? Then turn it on again after maybe 500ms have elapsed after disk access.
Thoughts would be most appreciated.
Addit: More experiments. The variable timer_delta is the delay between interrupts, and is set as 20*80_000 at the beginning of the program. But changing this value made no difference. I finally worked out that the value is overwritten by a value from MPM via the simh,
output_simh_set_timer_delta
rdlong x, #0 ' get clkfreq
mov y, i1000 ' divide by 1000
mov lmm_pc, #lmm_div32
call #lmm_func
rdword x, simh_params ' get delta in milliseconds
mov lmm_pc, #lmm_mul32
call #lmm_func
mov timer_delta, x ' delta in cycles
' display the value in hex
' mov hexval, timer_delta ' display on the screen
' call #conout_hex_l ' in hex
' call #conout_crlf
jmp #output_simh_return
and by uncommenting out the last few lines the actual value is displayed. (in my case because ticks are 5 per second, not 50 per second, I get a value of 200*80_000 which in hex is F42400
Ok, by commenting out the first part I can set it to any value, so I tried 2000*80000 which should give several seconds between each user.
Allowing for the fact that a user is bypassed if it is not running any code, I set up two users running basic programs.
Here is the strange thing. Run one program to use up lots of cpu cycles on one user. Try to load mbasic in another user. On the 5 ticks per second you can see the disk access flashing briefly about once a second. On the much slower (3 seconds between interrupts) setting, it first loads about half of mbasic really quickly, then the second half only flashes the led now ever 4 seconds.
Hmm - what is it doing for the rest of its cycle if not loading up a file?
I've simplified the above post down to a more simple question.
I am looking for a command/bdos/xios call that passes control immediately to the next user. Specifically, there is an interrupt 5x a second and if one user is busy doing a timing loop it slows down other users. I'm looking for something similar to the vb.net "DoEvents" command.
There might be a bios way to do this and there might be a pasm way. I'm trying to determine the neatest.
1) Using the bios. I found some extra commands in the MPM xios file
BIOS+33H JMP SELMEMORY SELECT MEMORY
BIOS+36H JMP POLLDEVICE POLL DEVICE
BIOS+39H JMP STARTCLOCK START CLOCK
BIOS+3CH JMP STOPCLOCK STOP CLOCK
BIOS+3FH JMP EXITREGION EXIT CRITICAL REGION
BIOS+42H JMP MAXCONSOLE MAXIMUM CONSOLE NUMBER
BIOS+45H JMP SYSTEMINIT SYSTEM INITIALIZATION
BIOS+48H JMP IDLE IDLE PROCEDURE (Optional)
I think I want a call to the dispatcher, so I think it might be a bios call to the last one on this list IDLE. The description says this;
IDLE An IDLE process is the anchor of the process ready list. The MP/M II nucleus calls the IDLE procedure when there are no other processes ready to run. The normal IDLE procedure is a call to the dispatcher. This most efficiently serves polled devices. If your system is entirely interrupt-driven (i.e. no polled devices), you can supply your own IDLE procedure, which should be as follows:
IDLE: HALT
RET
If you do not supply an IDLE procedure, place three bytes of zero at the BIOS+48H location.
I think what I want is the "normal" idle procedure, ie a call to the dispatcher, which I think in assembly is at the end of the interrupt code
; The following dispatch call will force round robin
; scheduling of processes executing at the same priority
; each 1/50th of a second.
; Note: Interrupts are not enabled until the dispatcher
; resumes the next process. This prevents interrupt
; over-run of the stacks when stuck or high frequency
; interrupts are encountered.
jp pdisp ; MP/M dispatch
(I don't think I can use a fully interrupt driven system as that has a HALT in it and HALT ends the program in pasm)
So I think what is needed is to pretend another interrupt arrived. I'm not 100% sure, but I think that involves a call to
; MP/M II V2.0 Interrupt Handler
inthnd: ld (svdhl),hl
...
rather than a call to pdisp.
For the moment the idle bios call is not implemented
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
and I'm not entirely sure what the three zeros actually do. I suppose I could experiement with uncommenting the jmp idle and commenting the db 0,0,0
2) Using pasm
I think what would be needed is to
i) add a new port address, similar to the serial ports
ii) add all the LMM code that goes with that, adding to the LMM function list etc
iii) adding a jump to this code, which executes an interrupt immediately
'**********************************************************************************************
'
' Timer interrupt executed at a rate of timer_delta cycles
'
timer_int
add timer_tick, timer_delta ' schedule next interrupt call
tjz irq_ptr, timer_int_ret ' no IRQ vector set?
tjnz hdsk_params_ptr, timer_int_ret ' do not interrupt while reading/writing hdsk params
wrlong timer_addr, irq_ptr
timer_int_ret
ret
I'm not sure which of these would be neater. (or easier, or would work)
@Dr_Acula: How about temporarily setting the interrupt time to 0 through a port write? That case could be handled by issuing one interrupt immediately and then returning to the previous rate. I.e. detect if the product of clock / 100 * rate == 0 and in that case jump to the interrupt generation in PASM.
Exciting news. Max Scane over at the N8VEM forum has solved this with a nifty function call I didn't realise was in MP/M. I
was assuming the xdos calls came after the xios calls but they are all
in different locations (all listed neatly on bootup as I now have
noticed). But you don't need to worry about where they are in memory.
Just call the function at 0005H and MP/M sorts it all out.
There are some more clever functions in the xdos. Queues looks useful.
I ran a program on another user printing out characters, and it is
running half speed until function 141 is called and then it speeds up
to "CP/M" speeds.
And as a bonus, because function 141 is being driven by an external
interrupt, it is more accurate than a software loop, and is also
independent of different clock speeds. Below is a little SBASIC
program to demonstrate this (plus the code for an MBASIC program on
another user to show the speed changes)
This opens up the possibility of smart parallel processing with up to 8 programs of 48k each running at CP/M speeds.
comment
program DOEVENTS.BAS written in SBASIC
equivalent of visual basic's 'doevents' for MP/M
see http://www.cpm.z80.de/manuals/mpm1ug01.pdf page 24 function call
141
Thanks to Max Scane for finding this;
FUNCTION 141: DELAY
Entry Parameters:
Register C: 8DH
DE: Number of Ticks
call bdos at 0005H
to test, run a small program on another user that continuously prints
something to the screen
that other program will run slower from "startup delay" to "starting
the doevents delay"
then will run faster as this program hands over CPU cycles
delay on this program with DE=30 and 5 ticks per second is 6 seconds
end
rem main
var i,hl, de, bc, a_psw = integer
print "Program loaded off disk, start the other program now"
for i=1 to 2000
next i
print "Starting the doevents delay"
hl = 0
de = 30
bc = 8DH
a_psw = 0
call (0005H,hl,de,bc,a_psw)
print "Finished"
The packet encoder/decoder is now working - able to log into a remote board with packets and run an MBASIC program.
I'm typing things and displaying things in vb.net, so next step is to write a terminal program that runs on another propeller board, and get this running without a PC
There are some nifty characters in the VT100 character set so I thought I would put them to use drawing boxes.
I've got
1) a form
2) a label
3) a text box
Next stop is a button. Windows has a system where you can use tab (or is it Alt Tab) to change the focus between objects on a form. This works without a mouse, and because CP/M has no mouse I figured this could be a good way to do things. If the focus is on a text box, then the cursor flashes. If on a button, then the text is inverted. If the focus is on a button and you hit enter, then the button is pressed. If on a text box and you type some text then the text appears in the text box.
But I seem to have got stuck with Inverse.
The VT100 command for this is <esc>[noparse][[/noparse]?5h
I can find this in the qz100 text
cmp cmd, #5 WZ ' <ESC>[noparse][[/noparse]?5h - inverse terminal on
if_z or inverse, #1
but I can't seem to get it to work.
Am I doing something wrong here?
As an aside, this is the 'main' program that drew the attached screen. Pretty easy to use once the subroutines are written.
var formx,formy=integer
cls
background
formx=10
formy=5
Form formx,formy,50,28,"Form1"
label formx+3,formy+5,"Label1"
SingleText formx+12,formy+4,25,"ABCDEFGHIJKLMNOPQRSTUVWXYZ",1,"Textbox"
InverseOn formx+3,formy+11,"Test"
JarviceMark. "Could you tell me is it possible to simulate in 8086"
Do you mean "in 8086" ? If so yes, there are many Z80 simulators that run on x86 PC's.
Do you mean"an 8086" ?
If so yes but...
This is a question that has come up a few times over the years since we first started running CP/M under a 8080/Z80 simulator on the Propeller back in the PropAltair project.
The 8 bit 8080 is a dream to emulate on the Prop as you can fit pretty much all the instruction handling code into a single COG and so it executes at a reasonable speed.
The Z80 is much more complex with a lot more instructions, the base set of instructions is the same as the 8080 and so fits in COG nicely. The extra instructions can be handled by PASM overlays or LMM code and will execute a lot more slowly. Luckily most software for Z80 does not use much of those extra Z80 op codes so most programs still run at a good speed.
The 8086 is a much bigger and significantly more complex CPU than the Z80. An emulator of 8086 on the Prop would be a much bigger program and have most of it's code outside of a single COG. As a result it would run a lot slower. 8086 programs would be using most instructions addressing modes so we don't get that lucky break as in Z80 where we can optimise some things and not worry about the speed of others.
So an 8086 emulator is of course possible but would be too slow to be any use (or fun).
I would suggest that any one who wants to do this should grab the C source of an existing 8086 emulator and compile it with Catalina for the Propeller. Us a Prop board with ext memory, DracBlade, TriBlade etc.
It would be slow. I don't see any point in trying to hand craft a 8086 emulator in PASM using LMM or overlays, it's too big an undertaking and the result would not be much better than using C.
It could be done. We could have MSDOS on the Propeller.
What a nightmare[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yeah, well spotted, someone actually putting something in that was appropriate to the thread for once lol, well done him! gotta admire that, even though he's a spammer [noparse]:([/noparse]
I'm working on adding an AUTOEXEC to user 0 in MP/M.
I've narrowed it down to the xios code and I think it goes near the end of here:
systeminit:
if banked
call checkb ; make sure we got banked memory
ld b,a ; top bank + 1
sys1: ld a,setbankselect ; prepare command
out (simhport),a ; execute it
dec b ; bank to map in
ld a,b ; prepare
out (simhport),a ; inform mmu
ld a,jpopcod ; jp instruction
ld (sysorg),a ; at 0: jp <HL>
ld (sysorg+1),hl
jp nz,sys1 ; bank 0 is the last bank
endif
ld b,endinitsequence-initsequence
ld hl,initsequence
sys2: ld a,(hl)
out (simhport),a
inc hl
dec b
jp nz,sys2
ld a,creset ; reset command
out (sts0),a ; reset console device
out (sts1),a ; reset console device
out (sts2),a ; reset console device
out (sts3),a ; reset console device
out (punstat),a ; and list/punch device
ld de,msg1 ; print welcome message
call msg
ei
ret ; return
just before "call msg" (or maybe just after), add a call to autoexec:
then in that code, output bytes to port 20H which stuffs them into console 0 input.
The text could be SUBMIT AUTOEXEC<cr>
and if AUTOEXEC.SUB does not exist, then MPM will just print an error message.
But I have run into some problems recompiling. I think the a.dsk image on page 1 of this thread might be corrupted. And I think that might be my fault, as that was a disk image I sent you!
On that A.DSK MPM.COM works and it comes up with a signon message
MP/M XIOS qZ80 Propeller.... 3 HDs.
However, if you recompile with SUBMIT SYSMPM then the new MPM does not run and crashes. I think I might have sent you an old version of the file!
A clue is that the MPMXIOS.MAC file on that disk image has a signon message that says "2" HDs, not 3. So I suspect it is an older version.
The only change I made to this MPMXIOS.MAC was to change this line
ticks equ 5 ; 5 ticks per second
(previous value was 50 ticks)
But if you are changing this, could you try adding something like this:
...
call msg
call autoexec ; send SUBMIT AUTOEXEC to user 0 on the Propeller
ei
ret ; return
; AUTOEXEC procedure J. Moxham July 2010 for the Propeller emulation
; sends SUBMIT AUTOEXEC<cr> to User 0 on startup
; uses Port 20H which sends data to user 0
autoexec:
ld a,65
out (20H),a
ret
and see if it sends A to the user0 console at startup?
If so, then I guess a little routine to send the text SUBMIT AUTOEXEC<cr> which is 16 bytes.
Another thing I was trying was to allow the same version of MPM.COM to run on the Altair SIMH. And in particular, to be able to be recompiled on the SIMH as recompilation on the Propeller takes a long time.
I took a look at your source code and it appears you have removed floppy disk support. I've got a MPM package off the SIMH site which starts up in CP/M on a 1meg floppy and then you run MPM off that. But I'm not entirely sure how you attach these bigger files, 8mb and your more recent 32mb one. Can the SIMH handle such big hard disk images?
I guess one needs a new SIMH image that boots CP/M off a large hard drive rather than a small floppy drive image. I might write to Peter Schorn about that.
Also another bug that is on one of the recent A.DSK images but not on another - in MPM if you type USER (any number) an error comes up "Reloc seg not free". This is not a problem on an image I have from about 6 weeks ago, so somewhere this bug has crept in.
Meanwhile, if you can take a look at AUTOEXEC it would be most appreciated.
I believe the 8088 was just an 8-bit wide implementation of the 8086. The I/O / memory bus was 8-bits and the chip's internal busses were 8-bits, but the instruction set was the same.
As far as I know there is no differences in instruction set between 8088 and 8086.
However the 8086 has a 6 byte instruction queue and the 8088 only a 4 byte queue. Therefore I guess with some carefully crafted self modifying code a program could find out which chip it was running on. Just modify an instruction 5 bytes ahead of the current PC and observe if it takes effect or not. Bit like the one instruction slot required for self modifying code in PASM.
No way am I doing an 8088/6. I hate that thing. Hated it when it came out and then found myself working with it for too long. The 186 was the best incarnation of it by the way. Easy to build into a embedded system and had some low power versions.
Just get an 8086 emulator written in C and run it under Catalina. The SIMH project has just the thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@Dr_Acula:
I think you can run only with 8MB hard disk images with SIMH, as it has fixed tables in it, while qz80 patches its tables according to the image sizes found on the SD. It was possible to boot the new XIOS with SIMH, though. Here's the startup file I use:
d tracks[noparse][[/noparse]0-7] 254
attach dsk mpm.dsk
attach hdsk0 C.DSK
d common c000
set cpu 64k
set cpu itrap
set cpu z80
set cpu altairrom
set cpu banked
set simh timeroff
; attach sio 10023
boot dsk
C.DSK is an 8MB hard disk image and I use it as 3rd drive with qz80, so I can PIP between the floppy (A[noparse]:)[/noparse] and the bigger drives by using the smaller SIMH compatible drive (I[noparse]:)[/noparse]. A little complicated, but you don't generate a new system all the time.
I don't have the earlier mpm_a_disk.zip handy, but I think I have the original A.DSK somewhere. Need to sort out the versions and will post an update with the timer change.
IIRC inverse should work with the VT100, unless I have a mistake in there. The upper half of the font should be inverted.
Edit: Ah, <ESC>[noparse][[/noparse]5h is inverse terminal on and is not implemented. It would mean to swap fg/bg colors and redraw the screen.
Yes sorry, my mistake for muddling up the source MPMXIOS.MAC and the working version when I sent you that image.
Re teh SIMH, if that only works with 8mb images, then maybe we could have two A.DSK images, identical files, one is 8mb and one 32mb? Then you could use the SIMH for rebuilding MPM.
Especially since you have auto recognition of file size in your code (which, btw, is very clever!).
I'll look forward to the new drive image.
Re 8086/88/186 etc, I guess that would lead to CPM86 and MSDOS. I never really got my head around the memory offset system these chips use, but I guess at the time it was a way of breaking out of the 64k limit.
I'm a bit stuck with coding without a MPMXIOS that compiles reliably, so meanwhile I'm busying myself designing the next dracblade board.
Same as the old one, but lots of optional things you can add that can't all run at once, but it means different version of the board could be built. 4 RS232 ports for a router. A socket for a radio module. Mouse. Some leds on P0-P7 and a 10 way header to bring these out. A 26 way header with 10 TTL outputs (5V) and 8 TTL inputs. I'd like to get analog I/O as well, even if it is just a few resistors and capacitors as per the demo board schematic.
addit: message from Peter Schorn - syscopy to make a bootable 8mb drive image. Off to test it now.
Addit addit: Attached is a MPM package. It is the files straight off the Altair site with no modifications at all. To this I've added Teraterm and the .ini file for teraterm with the right port settings. Extract to any directory. To run, double click MPM.BAT, then double click Teraterm.
Steps to build a hard drive booting SIMH:
1) copy mpm.bat to mpmhard.bat
2) changed the contents to: altairz80 mpmhard.txt
3) copied mpm to mpmhard.txt
4) changed text to
d tracks[noparse][[/noparse]0-7] 254
attach hdsk i.dsk
d common b000
set cpu 64k
set cpu itrap
set cpu z80
set cpu altairrom
set cpu banked
set simh timeroff
attach sio 23
boot hdsk
5) reopened mpm.bat
6) syscopy a: i: to move the system tracks to hard drive i
7) read in with R three files onto the drive that are needed - PIP.COM, DIRX.COM, SUBMIT.COM
8) PIP I:=A**.*
9) restart the emulation
The SIMH starts listing hard drives at I so it boots into an I prompt instead of an A prompt. This does appear to be a problem as running submit sysmpm gets about 1/3 of the way then gives an error
I>SUBMIT SYSMPM
I>; BUILD MP/M SYSTEM
I>; NEEDS TO BE EXECUTED UNDER CP/M 2
I>; REQUIRED SOURCES: LDRBIOS.MAC, MPMXIOS.MAC, MPMD.LIB
I>; REQUIRED PROGRAMS: M80.COM, L80.COM, DDTZ.COM, LINK.COM, XSUB.COM
I>XSUB
I>M80 =LDRBIOS/M
No Fatal error(s)
(xsub active)
I>L80 LDRBIOS,LDRBIOS/N/E
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Data 0100 044B < 843>
43759 Bytes Free
[noparse][[/noparse]0000 044B 4]
(xsub active)
I>DDTZ MPMLDR.COM
DDT/Z [noparse][[/noparse]8101]
High = 177F Max = 177F
>
Bdos Err On A: Bad Sector
intriguingly, it does not error when doing these instructions manually. So running off drive I may be a problem.
I think I will go back to compiling MPM using the floppy image, then copy MPM.COM over to drive I, do a syscopy on drive I then rename drive i.dsk as a.dsk for the purposes of using on the propeller...
OK scratch all that (I'll leave it posted though to save anyone else going down this dead end)
1) Get the SIMH package above. Leave the drive A and drive I as they are in the default
2) use R to put PIP and SUBMIT on drive A
3) use the following text for a new SYSMPM.SUB file - create it in notepad
; build MP/M system
; needs to be executed under CP/M 2
; required sources: LDRBIOS.MAC, MPMXIOS.MAC, MPMD.LIB
; required programs: M80.COM, L80.COM, DDTZ.COM, LINK.COM, XSUB.COM
XSUB
M80 =LDRBIOS/M
L80 LDRBIOS,LDRBIOS/N/E
DDTZ MPMLDR.COM
FLDRBIOS.COM
R1600
G0
SAVE 26 MPM.COM
ERA LDRBIOS.REL
ERA LDRBIOS.COM
M80 =MPMXIOS/M
LINK BNKXIOS[noparse][[/noparse]OS]=MPMXIOS
GENSYS $$A
ERA BNKXIOS.SYM
ERA MPMXIOS.REL
SYSCOPY A: I:
PIP I:=A:*.*
; start MP/M with MPM
this has two new commands at the end - SYSCOPY A: I: to copy system tracks to I, and then a PIP to copy the entire A disk to drive I.
I am hoping this will create a bootable hard drive image. The test will be to change the file MPM on the PC and edit the last line so it boots from drive i
d tracks[noparse][[/noparse]0-7] 254
attach dsk mpm.dsk
attach hdsk i.dsk
d common b000
set cpu 64k
set cpu itrap
set cpu z80
set cpu altairrom
set cpu banked
set simh timeroff
attach sio 23
boot dsk
ie change boot dsk to boot hdsk
...
ok that does work. But removing drive A altogether (ie delete the attach dsk mpm.dsk) means that MPM crashes with bdos error read on A:. However, I am hoping this image would work on the propeller and boot to drive A if it is renamed from i.dsk to a.dsk
Just got to go back and alter that ticks variable and I'll post a result. If this works I can look at the changes pullmoll made to the mpmxios file - and keep adding changes one by one and testing on the propeller and the SIMH side by side. Ideally we can find a file that works for both.
take the mpm package off the simh
start it with the default settings - drive a=floppy, drive i=hard drive
put PIP and SUBMIT on the A drive
put a bare bones wordstar setup on the floppy drive. WS.COM, WS.OVR, WSMSGS.OVR and (if you want to change the screen size), WSCHANGE.COM
use wordstar in CPM, not MPM as the SIMH MPM does not have enough space for big files like MPMXIOS.MAC
use wordstar in N mode rather than D (document) mode
edit the SYSMPM.SUB file and add these two lines at the bottom
PIP I:=A:*.*
SYSCOPY A: I:
now start editing MPMXIOS.MAC
ok, if I just change ticks from 50 to 5, it still runs fine on the SIMH. But if I download that MPM.COM file to the propeller, it does not run at all. So the next thing - what did pullmoll change in his version of MPMXIOS.MAC?
1) comment at the top - he removed floppy support and only has hard drives
2) the signon message is different
msg1: db cr, lf, 'MP/M XIOS (qZ80 Propeller, V1.11, '
db '0' + nhdisks, ' HDs, '
if banked
db 'Banked, '
endif
db '15-Apr-10)'
db cr, lf, '$'
hmm - what else is different? And in particular, how can it be possible to have a version that runs on the propeller and the SIMH?
- finding all sorts of things related to hard disks vs floppy disks. pullmoll has removed floppy support altogether - fine for the propeller. But I think I need to talk to Peter Schorn about making the hard drive as drive A instead of I, as that is upsetting MPM.
... message back from Peter - he says "having a hdsk device as drive A: is certainly possible. It requires some
changes in the BIOS to use the hdsk device instead of the dsk device.
MPMXIOS.MAC and LDRBIOS.MAC need to be changed."
so no changes to the SIMH itself. In which case building a common MPM for the Prop and SIMH seems more possible now.
...I need to go through the xios source again, but I have a feeling that ndisks is the number of floppy disks and that is set to 8. ABCDEFGH=8 letters. I is the next letter. So setting the number of floppy drives to zero might make the hard drive the first letterA. That is the theory anyway. I have a feeling that is what pullmoll's code does (and then he went one step further and actually removed the floppy code to save some bios space in upper memory).
@Drac: Consider using the PMod expansion connector scheme. There are lots of cheap addon pcb from Digilent www.digilentinc.com
8088/8086: Yes, I hated the banking scheme and never programmed it (in assembler) until the 80486 when I did a mini-emulation of the ICL System 25 (at 33MHz it was 3 times faster). However, I targetted the 486 instructions. The 68000 was a far superior chip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
1) MPMXIOS.MAC edited so ticks = 5 rather than 50. This has been the key to getting MPM working without crashing every 10 minutes.
2) New MPM compiled on the board with DO MPMSYS, new MPM.COM created (I love the way the propeller can recompile operating systems!)
3) XM1.ASM and XM1.COM placed on USER 1 area for xmodem transfers via a terminal program
4) XM2.ASM and XM2.COM placed on USER 2 area for xmodem transfers via a terminal program
5) a small file LCDBOOT.COM and LCDBOOT.ASM on USER 0 which displays a signon message on the LCD display
XMODEMF.COM is the original program used to transfer files to USER 0 and this is already on the disk. If you boot up with USER 0 on the VGA screen you need to run MPM to do any file transfers. If you boot up with USER 0 on the serial port you can do file transfers to CP/M.
My AUTOEXEC.SUB file is:
LCDBOOT
MPM
I've updated my webpage below with links to the above files.
So...
pullmoll, would it be ok to make this new A.DSK the standard one?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 6/26/2010 2:09:06 AM GMT
I'm doing some experiments with driving a TV display.
I haven't had any luck with the simple graphics demo that comes with the propeller tool - I tried changing the pin definition from 001_0101 to 010_0001 which someone on another thread had suggested changes the basepin from 12 to 16. But no luck.
I have had some success though with the qZ80 object. Changed from vga to tv at the bottom of the Con section. But it is intermittently going out of sync so I get text for a few seconds then a blue screen for a few seconds. PAL is cleaner than NTSC (the display can do either) but neither are locked in properly.
I'm going to try a shorter cable, but is there a way to tweak variables to get it to lock more solidly? I suspect if that is possible it is the variable list at the beginning of the Con section in TV80.Spin but I'm not sure which ones:
any help would be most appreciated.
(on my real TV I can tweak the tuning knob but this little TV display has no tuning knob)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I added this line of code before the tv drivers starts
tv_pins := (Tv_base & $38) << 1 | (Tv_base & 4 == 4) & %0101
BTW, I got my drake blade build and working, but I made a few changes
Do you have a schematic for the propeller plug? I did look at this at one stage and I think it just needed some headers.
Sorry, that code isn't working. No display at all on two TVs. Is still a partial synch on the qZ80 code so the hardware I think is ok.
I think the first variable to try tweaking might be long tv_broadcast 'broadcast frequency (Hz) write-only
However, I can't see where this is actually set in the program. It gets mentioned in the Var section of graphics_demo, and it gets mentioned in the TV object as
'' long tv_broadcast 'broadcast frequency (Hz) write-only
and it gets mentioned at the bottom of the graphics_demo
long 0 'broadcast
but I'm not sure the value would be zero for frequency.
Addit - I tried tweaking ifrqa_80MHz = 287604888 ' required FRQA value (5MHz*16) in qZ80 but it just gets worse in either direction, so the synch problem is something else maybe.
Any help would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 6/30/2010 1:38:52 PM GMT
25 x 9 = 225 active scanlines, which is a lot for NTSC. Perhaps you can try to go with a 80x24 display by decreasing orows to 24.
Did you try Cluso99's original 1pin TV object? This is the code where mine is derived from. If you get Cluso's code to sync, then I must have changed something else inadvertently.
Finally: what resistor do you use? Perhaps you can get a stronger signal with a lower value. For me it worked with any of the 3 TV pins, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 6/30/2010 3:11:36 PM GMT
That might be a clue as I don't have any adjustments on the monitor. (nor on my TV).
This TV output is proving to be quite a challenge. I'm mildy annoyed with myself as I did get a TV output about 4 months ago but I can't find that code.
It ought to be simply a matter of changing the pins on the existing demo code from pin 12 to pin 16 but the examples of this scattered through the forum are a little confusing - do you change the binary value 001_0101 to 010_0001 or do you change some other variable? I've never really quite understood those binary values anyway even though they are documented here
The select group makes sense, but the other 4 bits do not, as they are described as bits 3..0 and it then goes on to list 8 bit codes. I don't really understand the difference between 0001 broadcase and 0101 baseband.
The circuit is very simple - 1k1 on pin 16, 560R on pin 17 and 270R on pin 18.
I'm not sure how to add Cluso's 1 pin demo - does this replace TV80?
Even though this is partially working on the qZ80 emulation, I think I need to go back to a very simple TV demonstration and build it up from there. I am not sure which variables to change;
tvparams long 0 'status long 1 'enable long %001_0101 'pins long %0000 'mode long 0 'screen long 0 'colors long x_tiles 'hc long y_tiles 'vc long 10 'hx long 1 'vx long 0 'ho long 0 'vo long 0 'broadcast long 0 'auralcogBut going back through the description of those variables
There is the variable 'pins and I'm guessing 010_0001 and then there is the variable tv_status and should that be 2 to make it visible. (I tried those but no luck). Or maybe 010_0101?
Too many things to change. Some of these bits of code have come from existing code in the Obex so maybe I need to go back to the original source code that works on the demo board and just change one thing to make the pins start at pin 16 instead of pin 12.
If that does not work - maybe I just have two TVs that are not able to sync with the signal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
1) Lots of progress with the networking code. I can now send a command "TYPE MYFILE.TXT" from the PC to the Propeller as a packetized piece of data, this is then interpreted by a program in user2, the data passed to user0 as a CP/M command, then the output captured and send back as packets.
The source and destination are 4 bytes, so could be an IP address, and hence there is enough information to route a packet via the internet if required. There is still a bit more to code but the fundamentals are working now. I can send a command to a particular board telling it to route all output to another board. Or turn off routing output. Packets not for a board are forwarded on, so this leads towards being able to log into remote boards via multiple hops, and still have a normal (albeit slow) session on MP/M.
2) Minor documentation error
'********************************************************************************************** ' ' Output an instruction code to the LCD ' output_punstat mov lmm_pc, #lmm_ram_rs jmp #lmm_command0 '********************************************************************************************** 'should be ' Output an instruction code to the Punch device
3) Pullmoll has very cleverly added the ^P command where all text output from a console is directed to a huge 16k circular buffer in the ram chip. The only catch is (and this is a CP/M problem) is that not everything goes there - specifically, some output from certain programs, eg from within MBASIC or WORDSTAR
I have added a little #ifdef that routes everthing from the vga display to the circular buffer. Near the beginning of the CPM.SPIN code I added this
and in IO.SPIN I modified this bit of code to output to the buffer if required
'********************************************************************************************** ' ' Write to the console #0 ' conout_char #ifdef USER0_PS2_VGA mov lmm_pc, #lmm_vt100_out call #lmm_func ' experiments trying to send all vga data to the punch output as well ' replicates ^P but also works within programs eg mbasic, that bypass CP/M system calls #ifdef USER0_TO_PUNCH mov lmm_pc, #lmm_ram_wr call #lmm_func #endif #else mov tx0_ret, conout_char_ret jmp #tx0 #endif conout_char_ret retI wonder if this could be added to the 'official' version?
4) Talking of other minor tweaks, maybe it is a matter of personal preference but I like white on blue rather than yellow on blue. Perhaps because my old school colours were white and blue...
Anyway, I added this bit of code in the colour definitions to make it easier to change if needed. These are binary values (does %% mean octal?)
' background and foreground colors - select one of these and comment the rest out ' %00001000_11111100 ' Blue_White blue =3/4 power 10, white =full ' %00001000_11110000 ' Blue_Gold ' %00000000_11111100 ' Black_White ' %00000000_00110100 ' Black_Green + tiny amount of blue ' %00000000_11100000 ' Black_Orange ' wordfill(@vga_colors, %%0013_3303, 40) wordfill(@vga_colors,%00001000_11111100, 40)5) Now for the complicated part. I'm having a lot of trouble loading files on one user when a second user is running a program. I tried removing the delayed write but this made no difference (the problem is with reads, not writes). I tried dropping the interrupt rate from 5 per second to 1 per second but that didn't help (50 does not work at all as discussed previously). I note in the interrupt section this bit of code that is supposed to delay things if a disk access is happening but I'm not sure if that is happening.
' Timer interrupt executed at a rate of timer_delta cycles ' timer_int add timer_tick, timer_delta ' schedule next interrupt call tjz irq_ptr, timer_int_ret ' no IRQ vector set? tjnz hdsk_params_ptr, timer_int_ret ' do not interrupt while reading/writing hdsk params wrlong timer_addr, irq_ptr timer_int_ret retPerhaps the best way to demonstrate this is to run two programs at the same time. This is a little mbasic program:
and it prints dots on the screen at about one per second.
When you run it on two users at once the dot rate decreases. From this I conclude that MPM perhaps bypasses a user if they are just sitting at the 1A> prompt?
But the real problem is when you load mbasic on one user and set this program running, then attempt to load any program on the second user (mbasic, wordstar, or anything that requires reading a big file off the disk). Disk access slows right down and the disk access light flashes briefly about once a second.
Eventually after about a minute mbasic loads.
The first experiment suggests to me that doubling the demands on the CPU halves the execution speed. This is not unexpected.
The second experiment shows that loading a file takes about 10 times longer if one program is already running.
I am not sure why this would be. Perhaps there is a time factor somewhere in the disk access. Perhaps continuous disk access is much more efficient than discontinuous access?
I am thinking this last possibility is the most likely - eg it is having to reinitialise something on the sd card when access is discontinuous.
I am wondering if there is a solution. Even if it is as brute force as completely turning off the interrupt timer while one user is accessing the disk? Then turn it on again after maybe 500ms have elapsed after disk access.
Thoughts would be most appreciated.
Addit: More experiments. The variable timer_delta is the delay between interrupts, and is set as 20*80_000 at the beginning of the program. But changing this value made no difference. I finally worked out that the value is overwritten by a value from MPM via the simh,
output_simh_set_timer_delta rdlong x, #0 ' get clkfreq mov y, i1000 ' divide by 1000 mov lmm_pc, #lmm_div32 call #lmm_func rdword x, simh_params ' get delta in milliseconds mov lmm_pc, #lmm_mul32 call #lmm_func mov timer_delta, x ' delta in cycles ' display the value in hex ' mov hexval, timer_delta ' display on the screen ' call #conout_hex_l ' in hex ' call #conout_crlf jmp #output_simh_returnand by uncommenting out the last few lines the actual value is displayed. (in my case because ticks are 5 per second, not 50 per second, I get a value of 200*80_000 which in hex is F42400
Ok, by commenting out the first part I can set it to any value, so I tried 2000*80000 which should give several seconds between each user.
Allowing for the fact that a user is bypassed if it is not running any code, I set up two users running basic programs.
Here is the strange thing. Run one program to use up lots of cpu cycles on one user. Try to load mbasic in another user. On the 5 ticks per second you can see the disk access flashing briefly about once a second. On the much slower (3 seconds between interrupts) setting, it first loads about half of mbasic really quickly, then the second half only flashes the led now ever 4 seconds.
Hmm - what is it doing for the rest of its cycle if not loading up a file?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 7/18/2010 2:02:09 PM GMT
I've simplified the above post down to a more simple question.
I am looking for a command/bdos/xios call that passes control immediately to the next user. Specifically, there is an interrupt 5x a second and if one user is busy doing a timing loop it slows down other users. I'm looking for something similar to the vb.net "DoEvents" command.
There might be a bios way to do this and there might be a pasm way. I'm trying to determine the neatest.
1) Using the bios. I found some extra commands in the MPM xios file
BIOS+33H JMP SELMEMORY SELECT MEMORY
BIOS+36H JMP POLLDEVICE POLL DEVICE
BIOS+39H JMP STARTCLOCK START CLOCK
BIOS+3CH JMP STOPCLOCK STOP CLOCK
BIOS+3FH JMP EXITREGION EXIT CRITICAL REGION
BIOS+42H JMP MAXCONSOLE MAXIMUM CONSOLE NUMBER
BIOS+45H JMP SYSTEMINIT SYSTEM INITIALIZATION
BIOS+48H JMP IDLE IDLE PROCEDURE (Optional)
I think I want a call to the dispatcher, so I think it might be a bios call to the last one on this list IDLE. The description says this;
IDLE An IDLE process is the anchor of the process ready list. The MP/M II nucleus calls the IDLE procedure when there are no other processes ready to run. The normal IDLE procedure is a call to the dispatcher. This most efficiently serves polled devices. If your system is entirely interrupt-driven (i.e. no polled devices), you can supply your own IDLE procedure, which should be as follows: IDLE: HALT RET If you do not supply an IDLE procedure, place three bytes of zero at the BIOS+48H location.I think what I want is the "normal" idle procedure, ie a call to the dispatcher, which I think in assembly is at the end of the interrupt code
; The following dispatch call will force round robin ; scheduling of processes executing at the same priority ; each 1/50th of a second. ; Note: Interrupts are not enabled until the dispatcher ; resumes the next process. This prevents interrupt ; over-run of the stacks when stuck or high frequency ; interrupts are encountered. jp pdisp ; MP/M dispatch(I don't think I can use a fully interrupt driven system as that has a HALT in it and HALT ends the program in pasm)
So I think what is needed is to pretend another interrupt arrived. I'm not 100% sure, but I think that involves a call to
; MP/M II V2.0 Interrupt Handler
inthnd: ld (svdhl),hl
...
rather than a call to pdisp.
For the moment the idle bios call is not implemented
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 coldstartand I'm not entirely sure what the three zeros actually do. I suppose I could experiement with uncommenting the jmp idle and commenting the db 0,0,0
2) Using pasm
I think what would be needed is to
i) add a new port address, similar to the serial ports
ii) add all the LMM code that goes with that, adding to the LMM function list etc
iii) adding a jump to this code, which executes an interrupt immediately
'********************************************************************************************** ' ' Timer interrupt executed at a rate of timer_delta cycles ' timer_int add timer_tick, timer_delta ' schedule next interrupt call tjz irq_ptr, timer_int_ret ' no IRQ vector set? tjnz hdsk_params_ptr, timer_int_ret ' do not interrupt while reading/writing hdsk params wrlong timer_addr, irq_ptr timer_int_ret retI'm not sure which of these would be neater. (or easier, or would work)
Advice from pullmoll would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
was assuming the xdos calls came after the xios calls but they are all
in different locations (all listed neatly on bootup as I now have
noticed). But you don't need to worry about where they are in memory.
Just call the function at 0005H and MP/M sorts it all out.
There are some more clever functions in the xdos. Queues looks useful.
I ran a program on another user printing out characters, and it is
running half speed until function 141 is called and then it speeds up
to "CP/M" speeds.
And as a bonus, because function 141 is being driven by an external
interrupt, it is more accurate than a software loop, and is also
independent of different clock speeds. Below is a little SBASIC
program to demonstrate this (plus the code for an MBASIC program on
another user to show the speed changes)
Detailed documentation here www.cpm.z80.de/manuals/mpm1ug01.pdf
This opens up the possibility of smart parallel processing with up to 8 programs of 48k each running at CP/M speeds.
comment program DOEVENTS.BAS written in SBASIC equivalent of visual basic's 'doevents' for MP/M see http://www.cpm.z80.de/manuals/mpm1ug01.pdf page 24 function call 141 Thanks to Max Scane for finding this; FUNCTION 141: DELAY Entry Parameters: Register C: 8DH DE: Number of Ticks call bdos at 0005H to test, run a small program on another user that continuously prints something to the screen that other program will run slower from "startup delay" to "starting the doevents delay" then will run faster as this program hands over CPU cycles delay on this program with DE=30 and 5 ticks per second is 6 seconds end rem main var i,hl, de, bc, a_psw = integer print "Program loaded off disk, start the other program now" for i=1 to 2000 next i print "Starting the doevents delay" hl = 0 de = 30 bc = 8DH a_psw = 0 call (0005H,hl,de,bc,a_psw) print "Finished"and
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'm typing things and displaying things in vb.net, so next step is to write a terminal program that runs on another propeller board, and get this running without a PC
There are some nifty characters in the VT100 character set so I thought I would put them to use drawing boxes.
I've got
1) a form
2) a label
3) a text box
Next stop is a button. Windows has a system where you can use tab (or is it Alt Tab) to change the focus between objects on a form. This works without a mouse, and because CP/M has no mouse I figured this could be a good way to do things. If the focus is on a text box, then the cursor flashes. If on a button, then the text is inverted. If the focus is on a button and you hit enter, then the button is pressed. If on a text box and you type some text then the text appears in the text box.
But I seem to have got stuck with Inverse.
The VT100 command for this is <esc>[noparse][[/noparse]?5h
I can find this in the qz100 text
cmp cmd, #5 WZ ' <ESC>[noparse][[/noparse]?5h - inverse terminal on if_z or inverse, #1but I can't seem to get it to work.
Am I doing something wrong here?
As an aside, this is the 'main' program that drew the attached screen. Pretty easy to use once the subroutines are written.
var formx,formy=integer cls background formx=10 formy=5 Form formx,formy,50,28,"Form1" label formx+3,formy+5,"Label1" SingleText formx+12,formy+4,25,"ABCDEFGHIJKLMNOPQRSTUVWXYZ",1,"Textbox" InverseOn formx+3,formy+11,"Test"▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Thanks for the information. could you tell me is it possible to simulate in 8086?
average conveyancing costs
Do you mean "in 8086" ? If so yes, there are many Z80 simulators that run on x86 PC's.
Do you mean"an 8086" ?
If so yes but...
This is a question that has come up a few times over the years since we first started running CP/M under a 8080/Z80 simulator on the Propeller back in the PropAltair project.
The 8 bit 8080 is a dream to emulate on the Prop as you can fit pretty much all the instruction handling code into a single COG and so it executes at a reasonable speed.
The Z80 is much more complex with a lot more instructions, the base set of instructions is the same as the 8080 and so fits in COG nicely. The extra instructions can be handled by PASM overlays or LMM code and will execute a lot more slowly. Luckily most software for Z80 does not use much of those extra Z80 op codes so most programs still run at a good speed.
The 8086 is a much bigger and significantly more complex CPU than the Z80. An emulator of 8086 on the Prop would be a much bigger program and have most of it's code outside of a single COG. As a result it would run a lot slower. 8086 programs would be using most instructions addressing modes so we don't get that lucky break as in Z80 where we can optimise some things and not worry about the speed of others.
So an 8086 emulator is of course possible but would be too slow to be any use (or fun).
I would suggest that any one who wants to do this should grab the C source of an existing 8086 emulator and compile it with Catalina for the Propeller. Us a Prop board with ext memory, DracBlade, TriBlade etc.
It would be slow. I don't see any point in trying to hand craft a 8086 emulator in PASM using LMM or overlays, it's too big an undertaking and the result would not be much better than using C.
It could be done. We could have MSDOS on the Propeller.
What a nightmare[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/22/2010 1:04:51 PM GMT
I notice now that JarvisMark has joined the forum today with one short post containing an advertising link.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
In which case I've just failed the Turing test. Err, no ... is it that JarviceMark has just passed the Turing test?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'm working on adding an AUTOEXEC to user 0 in MP/M.
I've narrowed it down to the xios code and I think it goes near the end of here:
systeminit: if banked call checkb ; make sure we got banked memory ld b,a ; top bank + 1 sys1: ld a,setbankselect ; prepare command out (simhport),a ; execute it dec b ; bank to map in ld a,b ; prepare out (simhport),a ; inform mmu ld a,jpopcod ; jp instruction ld (sysorg),a ; at 0: jp <HL> ld (sysorg+1),hl jp nz,sys1 ; bank 0 is the last bank endif ld b,endinitsequence-initsequence ld hl,initsequence sys2: ld a,(hl) out (simhport),a inc hl dec b jp nz,sys2 ld a,creset ; reset command out (sts0),a ; reset console device out (sts1),a ; reset console device out (sts2),a ; reset console device out (sts3),a ; reset console device out (punstat),a ; and list/punch device ld de,msg1 ; print welcome message call msg ei ret ; returnjust before "call msg" (or maybe just after), add a call to autoexec:
then in that code, output bytes to port 20H which stuffs them into console 0 input.
The text could be SUBMIT AUTOEXEC<cr>
and if AUTOEXEC.SUB does not exist, then MPM will just print an error message.
But I have run into some problems recompiling. I think the a.dsk image on page 1 of this thread might be corrupted. And I think that might be my fault, as that was a disk image I sent you!
On that A.DSK MPM.COM works and it comes up with a signon message
MP/M XIOS qZ80 Propeller.... 3 HDs.
However, if you recompile with SUBMIT SYSMPM then the new MPM does not run and crashes. I think I might have sent you an old version of the file!
A clue is that the MPMXIOS.MAC file on that disk image has a signon message that says "2" HDs, not 3. So I suspect it is an older version.
The only change I made to this MPMXIOS.MAC was to change this line
(previous value was 50 ticks)
But if you are changing this, could you try adding something like this:
... call msg call autoexec ; send SUBMIT AUTOEXEC to user 0 on the Propeller ei ret ; return ; AUTOEXEC procedure J. Moxham July 2010 for the Propeller emulation ; sends SUBMIT AUTOEXEC<cr> to User 0 on startup ; uses Port 20H which sends data to user 0 autoexec: ld a,65 out (20H),a retand see if it sends A to the user0 console at startup?
If so, then I guess a little routine to send the text SUBMIT AUTOEXEC<cr> which is 16 bytes.
Another thing I was trying was to allow the same version of MPM.COM to run on the Altair SIMH. And in particular, to be able to be recompiled on the SIMH as recompilation on the Propeller takes a long time.
I took a look at your source code and it appears you have removed floppy disk support. I've got a MPM package off the SIMH site which starts up in CP/M on a 1meg floppy and then you run MPM off that. But I'm not entirely sure how you attach these bigger files, 8mb and your more recent 32mb one. Can the SIMH handle such big hard disk images?
I guess one needs a new SIMH image that boots CP/M off a large hard drive rather than a small floppy drive image. I might write to Peter Schorn about that.
Also another bug that is on one of the recent A.DSK images but not on another - in MPM if you type USER (any number) an error comes up "Reloc seg not free". This is not a problem on an image I have from about 6 weeks ago, so somewhere this bug has crept in.
Meanwhile, if you can take a look at AUTOEXEC it would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 7/28/2010 11:18:57 AM GMT
BTW, did the 8088 use the same instruction set (no extras/no fewer)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
However the 8086 has a 6 byte instruction queue and the 8088 only a 4 byte queue. Therefore I guess with some carefully crafted self modifying code a program could find out which chip it was running on. Just modify an instruction 5 bytes ahead of the current PC and observe if it takes effect or not. Bit like the one instruction slot required for self modifying code in PASM.
No way am I doing an 8088/6. I hate that thing. Hated it when it came out and then found myself working with it for too long. The 186 was the best incarnation of it by the way. Easy to build into a embedded system and had some low power versions.
Just get an 8086 emulator written in C and run it under Catalina. The SIMH project has just the thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think you can run only with 8MB hard disk images with SIMH, as it has fixed tables in it, while qz80 patches its tables according to the image sizes found on the SD. It was possible to boot the new XIOS with SIMH, though. Here's the startup file I use:
C.DSK is an 8MB hard disk image and I use it as 3rd drive with qz80, so I can PIP between the floppy (A[noparse]:)[/noparse] and the bigger drives by using the smaller SIMH compatible drive (I[noparse]:)[/noparse]. A little complicated, but you don't generate a new system all the time.
I don't have the earlier mpm_a_disk.zip handy, but I think I have the original A.DSK somewhere. Need to sort out the versions and will post an update with the timer change.
IIRC inverse should work with the VT100, unless I have a mistake in there. The upper half of the font should be inverted.
Edit: Ah, <ESC>[noparse][[/noparse]5h is inverse terminal on and is not implemented. It would mean to swap fg/bg colors and redraw the screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 7/28/2010 11:25:53 PM GMT
Re teh SIMH, if that only works with 8mb images, then maybe we could have two A.DSK images, identical files, one is 8mb and one 32mb? Then you could use the SIMH for rebuilding MPM.
Especially since you have auto recognition of file size in your code (which, btw, is very clever!).
I'll look forward to the new drive image.
Re 8086/88/186 etc, I guess that would lead to CPM86 and MSDOS. I never really got my head around the memory offset system these chips use, but I guess at the time it was a way of breaking out of the 64k limit.
I'm a bit stuck with coding without a MPMXIOS that compiles reliably, so meanwhile I'm busying myself designing the next dracblade board.
Same as the old one, but lots of optional things you can add that can't all run at once, but it means different version of the board could be built. 4 RS232 ports for a router. A socket for a radio module. Mouse. Some leds on P0-P7 and a 10 way header to bring these out. A 26 way header with 10 TTL outputs (5V) and 8 TTL inputs. I'd like to get analog I/O as well, even if it is just a few resistors and capacitors as per the demo board schematic.
addit: message from Peter Schorn - syscopy to make a bootable 8mb drive image. Off to test it now.
Addit addit: Attached is a MPM package. It is the files straight off the Altair site with no modifications at all. To this I've added Teraterm and the .ini file for teraterm with the right port settings. Extract to any directory. To run, double click MPM.BAT, then double click Teraterm.
Steps to build a hard drive booting SIMH:
1) copy mpm.bat to mpmhard.bat
2) changed the contents to: altairz80 mpmhard.txt
3) copied mpm to mpmhard.txt
4) changed text to
5) reopened mpm.bat
6) syscopy a: i: to move the system tracks to hard drive i
7) read in with R three files onto the drive that are needed - PIP.COM, DIRX.COM, SUBMIT.COM
8) PIP I:=A**.*
9) restart the emulation
The SIMH starts listing hard drives at I so it boots into an I prompt instead of an A prompt. This does appear to be a problem as running submit sysmpm gets about 1/3 of the way then gives an error
intriguingly, it does not error when doing these instructions manually. So running off drive I may be a problem.
I think I will go back to compiling MPM using the floppy image, then copy MPM.COM over to drive I, do a syscopy on drive I then rename drive i.dsk as a.dsk for the purposes of using on the propeller...
*********************************************************************
OK scratch all that (I'll leave it posted though to save anyone else going down this dead end)
1) Get the SIMH package above. Leave the drive A and drive I as they are in the default
2) use R to put PIP and SUBMIT on drive A
3) use the following text for a new SYSMPM.SUB file - create it in notepad
this has two new commands at the end - SYSCOPY A: I: to copy system tracks to I, and then a PIP to copy the entire A disk to drive I.
I am hoping this will create a bootable hard drive image. The test will be to change the file MPM on the PC and edit the last line so it boots from drive i
ie change boot dsk to boot hdsk
...
ok that does work. But removing drive A altogether (ie delete the attach dsk mpm.dsk) means that MPM crashes with bdos error read on A:. However, I am hoping this image would work on the propeller and boot to drive A if it is renamed from i.dsk to a.dsk
Just got to go back and alter that ticks variable and I'll post a result. If this works I can look at the changes pullmoll made to the mpmxios file - and keep adding changes one by one and testing on the propeller and the SIMH side by side. Ideally we can find a file that works for both.
***********************************************************************
simplify simplify
take the mpm package off the simh
start it with the default settings - drive a=floppy, drive i=hard drive
put PIP and SUBMIT on the A drive
put a bare bones wordstar setup on the floppy drive. WS.COM, WS.OVR, WSMSGS.OVR and (if you want to change the screen size), WSCHANGE.COM
use wordstar in CPM, not MPM as the SIMH MPM does not have enough space for big files like MPMXIOS.MAC
use wordstar in N mode rather than D (document) mode
edit the SYSMPM.SUB file and add these two lines at the bottom
now start editing MPMXIOS.MAC
ok, if I just change ticks from 50 to 5, it still runs fine on the SIMH. But if I download that MPM.COM file to the propeller, it does not run at all. So the next thing - what did pullmoll change in his version of MPMXIOS.MAC?
1) comment at the top - he removed floppy support and only has hard drives
2) the signon message is different
msg1: db cr, lf, 'MP/M XIOS (qZ80 Propeller, V1.11, ' db '0' + nhdisks, ' HDs, ' if banked db 'Banked, ' endif db '15-Apr-10)' db cr, lf, '$'hmm - what else is different? And in particular, how can it be possible to have a version that runs on the propeller and the SIMH?
- finding all sorts of things related to hard disks vs floppy disks. pullmoll has removed floppy support altogether - fine for the propeller. But I think I need to talk to Peter Schorn about making the hard drive as drive A instead of I, as that is upsetting MPM.
... message back from Peter - he says "having a hdsk device as drive A: is certainly possible. It requires some
changes in the BIOS to use the hdsk device instead of the dsk device.
MPMXIOS.MAC and LDRBIOS.MAC need to be changed."
so no changes to the SIMH itself. In which case building a common MPM for the Prop and SIMH seems more possible now.
...I need to go through the xios source again, but I have a feeling that ndisks is the number of floppy disks and that is set to 8. ABCDEFGH=8 letters. I is the next letter. So setting the number of floppy drives to zero might make the hard drive the first letterA. That is the theory anyway. I have a feeling that is what pullmoll's code does (and then he went one step further and actually removed the floppy code to save some bios space in upper memory).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 7/29/2010 4:45:53 AM GMT
8088/8086: Yes, I hated the banking scheme and never programmed it (in assembler) until the 80486 when I did a mini-emulation of the ICL System 25 (at 33MHz it was 3 times faster). However, I targetted the 486 instructions. The 68000 was a far superior chip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
bochs.sourceforge.net/
compliing for ZOG?
Just for fun ...
( the cpu code: bochs.sourceforge.net/cgi-bin/topper.pl?name=Bochs+Source+Code&url=http://bochs.sourceforge.net/cgi-bin/lxr/source )
Post Edited (Chris Micro) : 7/29/2010 5:01:16 AM GMT
I'm sure there are more 16 bit 8086 emulators around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
http://i8086emu.sourceforge.net/
should be much smaller in code size.