This is a work in progress and ultimately I'd like to have a step-by-step guide to running MP/M, though the hardware is the same as CP/M. The networking is a slow work in progress but pieces of the jigsaw are coming together.
Fixed a bug in vt100.spin which was writing the row colours array beyond its size, thus destroying some of the variables in hub RAM that followed it.
Changed the VGA_HiRes_Text vertical front and back porch so that the display is vertically inside the displayed area (of my LCD monitor, that is). If it doesn't work for you, please report and we will have to find a way to have these parameters (vf and vb) set to values that work for everyone.
I downloaded the latest spin/pasm version on page 1. Tested with Wordstar - works perfectly now. Thanks++
There is a program WSCHANGE.COM on the disk image. I ran this and created an new version of WS.COM that has 40 lines instead of 25. So now it uses the full VGA screen. It was pretty quick to run this program - maybe quicker almost for you to run it yourself.
Attached is WS2.ZIP If this works for you, would you mind changing it to WS.COM, then putting it on the disk image? (if you think it is ok, that is!).
On the original spin version of the dracblade I had a lot of problems with scanning the keyboard when wordstar started up. The scan code bypassed teh CP/M bios. It seems you have this working perfectly in the new qZ80 code. Well done!
Back in the Ye Olden Days, I only had a 80x25 screen. It is great to have more lines in Wordstar.
Also, the new version centres perfectly in my VGA screen (which was originally set up for Windows) So that is another fantastic improvement.
I'm having a small problem with the LCD display - it has stopped working for the versions of code from a couple of days ago. Did anything change from a few days back?
I'm having a small problem with the LCD display - it has stopped working for the versions of code from a couple of days ago. Did anything change from a few days back?
Cheers, Drac
It's still working here, so the problem is probably on your side!? mbasic out 49,65 prints an "A" on the LCD.
Hmm, something isn't right. Blank LCD screen on two seperate boards. Hardware is ok as older versions all work. Something changed in the last few days. Would you mind posting one of the previous versions, eg two versions ago? Many thanks.
Addit - I completely erased all trace of the old versions and downloaded everything again. It is all working now. Not sure how that happened - must have had an old version overwriting a newer version.
No - not working again, on both boards. Something is very fragile here. It booted once with the LCD working then won't work at all now. Did any timings change in the last few days?
Ok, I've found the error I think. I've been running at a slower baud rate (38400) and if I change the baud in io.spin to 38400 then the LCD display does not initialise (no flashing cursor). However if the baud rate is 115200 then it does initialise and works perfectly.
But - the LCD is not being driven by a serial port. So has a timing loop changed somewhere - I'm wondering about the delays between bytes starting up the LCD - maybe they depend on different delays setting up the serial ports or something?
Dr_Acula said...
Hmm, something isn't right. Blank LCD screen on two seperate boards. Hardware is ok as older versions all work. Something changed in the last few days. Would you mind posting one of the previous versions, eg two versions ago? Many thanks.
Addit - I completely erased all trace of the old versions and downloaded everything again. It is all working now. Not sure how that happened - must have had an old version overwriting a newer version.
No - not working again, on both boards. Something is very fragile here. It booted once with the LCD working then won't work at all now. Did any timings change in the last few days?
Ok, I've found the error I think. I've been running at a slower baud rate (38400) and if I change the baud in io.spin to 38400 then the LCD display does not initialise (no flashing cursor). However if the baud rate is 115200 then it does initialise and works perfectly.
But - the LCD is not being driven by a serial port. So has a timing loop changed somewhere - I'm wondering about the delays between bytes starting up the LCD - maybe they depend on different delays setting up the serial ports or something?
The timing of the LCD is separate from anything related to the SIO. There is a constant value lcd_delay which is set at 100_000 and is the number of clock cycles between an enable pin high and low transition. You could perhaps try to set this higher. I have no idea how the serial port speed could influence this timing, except by the time until the display is initialized with starting the I/O cog, which is later when it takes longer to send the startup messages to the SIO port 0.
Many thanks. I'll try a different timing delay. It could be due to cogs starting up at different speeds. In the past I have had to deliberately slow down LCD driver code in both the original zicog and on a real Z80 board. I'm testing at 38400 and 115200 but ultimately in a wireless network the second port will need to go down to 9600 as that is the speed of the wireless modules (and the longer range ones are 1200).
LCD boots and runs fine at
1200
2400
4800
9600
19200
57600
115200
but not at 38400
As you say, the LCD should have nothing to do with the baud rate.
Next experiment - increase the delay on lcd_delay which is currently at 100000
Tried 200000 and baud 38400 and it gave some rubbish bytes but at least gave something
Tried 300000 and baud 38400 and it works
The LCD is slightly slower, but no matter, at least it works. (Indeed, on the zicog CP/M code, the LCD display was already slowing down the VGA display by a huge amount. Seperating them in MP/M and adding an OUT port for the LCD display is a brilliant idea. Now you can still have the LCD display, even if it is slower. Or debug to a vga display much faster).
Is it possible to add the lcd_delay of 300_000 to the next release?
Indeed! But don't forget about that strange SD + SPI thing I had to sort out. Let's be happy that the LCD runs for you at all!
Dr_Acula said...
Is it possible to add the lcd_delay of 300_000 to the next release?
I will do that. I have to look into the original LCD functions if perhaps a delay at another point would be needed. I seem to remember there were two kinds of delays in the code, not just the one on the enable line toggle.
BTW: While looking at the current layout of the various code fragments in the listing, I realized that I can probably use a rather large contiguous chunk of memory. The entire fatfs.spin code isn't required after booting (2224 bytes). It is followed by the DracBlade_spi_warp (or DracBlade_spi) code, where the Spin code isn't used at all. Once the cog is loaded, there are only - unfortunately - the 5 longs it uses to communicate with the outside world: SPI_engine_cog, SPI_command, SPI_block_index, SPI_buffer_address and HighLatchVal. If I could change the code so that these were in some other memory region (e.g. main's DAT), that would give me 2480 bytes and a total of 4704 bytes, which is very close to the 4800 required for the 80x30 full colour VGA frame buffer.
Ah, so maybe the memory can fit? Almost fits in two pieces. So you could do it in 3 pieces? Is 80x30 set in stone (ie a format from another computer) or was it just the one that fit best in the code?
Dr_Acula said...
Ah, so maybe the memory can fit? Almost fits in two pieces. So you could do it in 3 pieces? Is 80x30 set in stone (ie a format from another computer) or was it just the one that fit best in the code?
It does still not fit, no. The sequential RAM range is too small.
80x30 stems from the 640/8 and 480/16 relation, i.e. screen size to font size. Font height can be any multiple of 4, so 8x20 would work and result in a 80x24 display. Of course a 8x20 font uses even more hub RAM: 256 more longs compared to the 8x16. 80x24 would OTOH save just 6x80x2 bytes = 240 longs of frame buffer.
I'm pretty sure most of the wireless code is working. So next step is to write a little terminal program to test it. I have an idea that one can boot up in MP/M with user0 on the VGA screen and turn on other users with a ^P then talk to them, PIP programs over and run programs.
I'd like to split the VGA screen into 4 parts, with three MP/M users and also 1/4 for Help.
So as a start, I was wondering if there are some graphics characters in the VGA object. I wrote a little program to dump out the characters, and indeed, there are some characters from 128 up. VT100 can also put characters in any position on the screen, but for starters I thought I would write a quick MBASIC program to print a box and write something in it.
Apart from the blurry photo, it looks quite nifty. It will interesting to see where this goes...
[noparse][[/noparse]
addit - as an aside, when running User0 as the vga display, it is still possible to transfer files using user 1 or user 2. Simply pip the file to the other user eg
PIP BOX.BAS[noparse][[/noparse]G1]=BOX.BAS
also put xmodem on the other user, eg
PIP XMODEMF.BAS[noparse][[/noparse]G1]=XMODEMF.COM
]
I unified the TriBlade and RamBlade XMM code with the DracBlade code in a commonly used spi_warp.spin. Could some of you with either a TriBlade or a RamBlade give it a test? My own RamBlade seems to have a problem and I can't test the code other than that it compiles ok.
SD:>spin qz80
SIO initialized, 5 cogs free.
qZ80 I/O starting...
Volume serial #00B3-0DDF, label NO NAME
?, sector 0382C7, size 514.7MB, 2058-02-19 27:00:00
A.DSK failed: -1
A.DSK failed: -1
Renamed cpm.bin to qz80.bin, card size is really 1GB,
Are qz80 binary and the A.DSK image enough? or some other file is needed, bootrom maybe?
You also need the BOOT.DSK image that is on the top of the thread - I hope - I have to check this.
It looks like the spi_warp.spin code isn't working right on the RamBlade, though, as it is telling Smile about the (probably missing) BOOT.DSK image.
I'll attach it here for you to try.
I very much like this line and I am using this permanently now.
' If undefined, user 0 is on SIO port #0 and user 1 on PS/2 and VGA/TV
#define USER0_PS2_VGA
However, it has upset these lines:
constat_port = $10 ' console 0 status port (on SIO #0)
condata_port = $11 ' console 0 data port (on SIO #0)
punstat_port = $12 ' punch 1 status port
pundata_port = $13 ' punch/reader 1 data port
con1stat_port = $14 ' console 1 status port (on Keyboard / VGA)
con1data_port = $15 ' console 1 data port (on Keyboard / VGA)
Specifically, if in MBASIC you use
OUT &H11,65
then the data goes to the VGA display.
I don't think you need to change any code, but maybe the comment needs to change
' console 0 data port (on SIO #0)
changed to
' USER 0 data port
or maybe
' USER 0 data port (VGA or serial port depending on #define USER0_PS2_VGA in cpm.spin)
if so, then the comments for ports $10,$11,$14 and $15 need changing.
In addition to the above, a very technical question
How do I scan for keyboard input?
I tried this:
var a,b=integer
for b=1 to 100
a=inp(10H)
print a;
next b
But it always returns "2" and never returns "3" (which I think is the value if a key has been pressed), even if pressing a key while the program is running. Am I reading the wrong port??
In addition to the above, a very technical question
How do I scan for keyboard input?
I tried this:
var a,b=integer
for b=1 to 100
a=inp(10H)
print a;
next b
But it always returns "2" and never returns "3" (which I think is the value if a key has been pressed), even if pressing a key while the program is running. Am I reading the wrong port??
No, the port is correct, but if you run this under MP/M, the system may fetch the port data before you have a chance to see the bit.
On CP/M it should work, as long as MBASIC doesn't call constat or conin inside the loop.
I think the easiest way to look for keyboard input is the INKEY$!?
I got 'inkey' working in C. I've also got an LCD driver working in C. And I now have the IDE working properly for C, with rapid 10 second compile/download with one keypress. Plus C in Color! (see attached).
testforkeypress() /* wait for a keypress and return 255 if timeout or n=keypress*/
{
int k,t;
k=0;
t=0;
do
{
k=kbhit(); /* if any keyboard input then k is not zero */
t++; /* add one to timer */
if (t>2000) k=255; /* timeout */
}
while (k==0);
if (k !=255)
{
k=getchar(); /* get the character if not a timeout */
/* printf("getting character"); */
}
return k;
}
I have an idea that I could run a program at startup that asked the user to hit a key if they want MP/M networking. If no keypress in a few seconds then it just skips this. And if the user does want networking, this program sends the text "NETWORK" to user 2 which starts the network program. It all works fine except for one minor problem:
When I run AUTOEXEC.SUB at bootup, it runs MP/M, but then MP/M seems to start from nothing and deletes the list of instructions so it does not run the next instruction.
Would there be a way of passing a list of SUBMIT instructions to MP/M?
Updated the core to the latest Spectrum support. Also fixed some minor issues with ini(r)/outi(r)/ind(r)/outd(r) where B wasn't masked with $FF, so B could become $ffffffff, which is impossible.
The Colour Genie memory map was also changed to reflect the new screen access code.
Yes, baggers seems to be very close to getting the spectrum working. Having common code for all these emulations makes a lot of sense - I hope you are not close to running out of hub ram?
There are so many emulations I'm having trouble keeping up!
Does the different color genie memory map fix the issues with games like Invader?
I've got two new boards being made. One is an enlarged version of the dracblade with RS485, and the other is a 'watchdog' board that can turn the dracblade on and off using packets, and check that it boots up correctly (occasionally MP/M won't boot properly).
For this, I am thinking of using two baud rates - 1200 and 9600 (maybe 19200) on the RS485 bus.
I was wondering if qZ80 is able to change baud rates using an OUT command?
I did have something similar working on the zicog emulation, and it was a matter of reloading the serial driver cog and restarting it with new settings. It would not matter if all users (ie both serial ports) were the same rate.
Do you think it would be possible to change the baud rates, either restarting a cog, or changing a value that is stored in a known location eg in hub?
Dr_Acula said...
Do you think it would be possible to change the baud rates, either restarting a cog, or changing a value that is stored in a known location eg in hub?
It should be possible to add two reads of two hub longs for the bit_ticks and bit_ticks1 values in the cog, which are the variables defining the baud rate of a channel. Then io.spin of cpm just needs one or two ports where you write a new rate.
PRI baud_port2 | baudrate
' send io_data multiple of 1200 eg 1=1200, 16=19200, 96=115200
' port number 7C
baudrate:=io_data*1200
UART.init ' reinitialise the uart
UART.AddPort(0,31,30,-1,-1,0,0,baud) ' set up port 0 again to 19200
UART.AddPort(1,25,24,-1,-1,0,0,baudrate) ' new baud rate
UART.Start ' restart the uart driver
' 10 BAUD = 1200 ' mbasic example
' 20 OUT (&H7C),BAUD/1200
as you can see it was a fairly crude solution. Maybe not the most elegant. Restart the uart driver, set port 1 to the constant (which you have defined as variable 'baud'), but change the rate on the second port.
I did it this way because I think it ended up using the least amount of code.
But your idea of tracing the actual variable that holds the baud rate for port1 is intriguing. Maybe this would use even less code?
Which do you think is the most 'elegant' solution - 'poke' values to the baud rate variables, or restart the driver?
Dr_Acula said...
Which do you think is the most 'elegant' solution - 'poke' values to the baud rate variables, or restart the driver?
I changed the SIO object to read two variables with the bit times on every loop, so you can change the baud rate on the fly.
Perhaps you can try this first before I implement it in io.spin. I have no time right now to do it.
The variables are new_bit_ticks0 and new_bit_ticks1 for port 0 and 1, and they have to be set to clkfreq/baudrate.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
This is a work in progress and ultimately I'd like to have a step-by-step guide to running MP/M, though the hardware is the same as CP/M. The networking is a slow work in progress but pieces of the jigsaw are coming together.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Changed the VGA_HiRes_Text vertical front and back porch so that the display is vertically inside the displayed area (of my LCD monitor, that is). If it doesn't work for you, please report and we will have to find a way to have these parameters (vf and vb) set to values that work for everyone.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I downloaded the latest spin/pasm version on page 1. Tested with Wordstar - works perfectly now. Thanks++
There is a program WSCHANGE.COM on the disk image. I ran this and created an new version of WS.COM that has 40 lines instead of 25. So now it uses the full VGA screen. It was pretty quick to run this program - maybe quicker almost for you to run it yourself.
Attached is WS2.ZIP If this works for you, would you mind changing it to WS.COM, then putting it on the disk image? (if you think it is ok, that is!).
On the original spin version of the dracblade I had a lot of problems with scanning the keyboard when wordstar started up. The scan code bypassed teh CP/M bios. It seems you have this working perfectly in the new qZ80 code. Well done!
Back in the Ye Olden Days, I only had a 80x25 screen. It is great to have more lines in Wordstar.
Also, the new version centres perfectly in my VGA screen (which was originally set up for Windows) So that is another fantastic improvement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'm having a small problem with the LCD display - it has stopped working for the versions of code from a couple of days ago. Did anything change from a few days back?
Cheers, Drac
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
It's still working here, so the problem is probably on your side!? mbasic out 49,65 prints an "A" on the LCD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Addit - I completely erased all trace of the old versions and downloaded everything again. It is all working now. Not sure how that happened - must have had an old version overwriting a newer version.
No - not working again, on both boards. Something is very fragile here. It booted once with the LCD working then won't work at all now. Did any timings change in the last few days?
Ok, I've found the error I think. I've been running at a slower baud rate (38400) and if I change the baud in io.spin to 38400 then the LCD display does not initialise (no flashing cursor). However if the baud rate is 115200 then it does initialise and works perfectly.
But - the LCD is not being driven by a serial port. So has a timing loop changed somewhere - I'm wondering about the delays between bytes starting up the LCD - maybe they depend on different delays setting up the serial ports or something?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/9/2010 2:22:46 PM GMT
The timing of the LCD is separate from anything related to the SIO. There is a constant value lcd_delay which is set at 100_000 and is the number of clock cycles between an enable pin high and low transition. You could perhaps try to set this higher. I have no idea how the serial port speed could influence this timing, except by the time until the display is initialized with starting the I/O cog, which is later when it takes longer to send the startup messages to the SIO port 0.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I changed the baud rate and nothing else.
LCD boots and runs fine at
1200
2400
4800
9600
19200
57600
115200
but not at 38400
As you say, the LCD should have nothing to do with the baud rate.
Next experiment - increase the delay on lcd_delay which is currently at 100000
Tried 200000 and baud 38400 and it gave some rubbish bytes but at least gave something
Tried 300000 and baud 38400 and it works
The LCD is slightly slower, but no matter, at least it works. (Indeed, on the zicog CP/M code, the LCD display was already slowing down the VGA display by a huge amount. Seperating them in MP/M and adding an OUT port for the LCD display is a brilliant idea. Now you can still have the LCD display, even if it is slower. Or debug to a vga display much faster).
Is it possible to add the lcd_delay of 300_000 to the next release?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Indeed! But don't forget about that strange SD + SPI thing I had to sort out. Let's be happy that the LCD runs for you at all!
I will do that. I have to look into the original LCD functions if perhaps a delay at another point would be needed. I seem to remember there were two kinds of delays in the code, not just the one on the enable line toggle.
BTW: While looking at the current layout of the various code fragments in the listing, I realized that I can probably use a rather large contiguous chunk of memory. The entire fatfs.spin code isn't required after booting (2224 bytes). It is followed by the DracBlade_spi_warp (or DracBlade_spi) code, where the Spin code isn't used at all. Once the cog is loaded, there are only - unfortunately - the 5 longs it uses to communicate with the outside world: SPI_engine_cog, SPI_command, SPI_block_index, SPI_buffer_address and HighLatchVal. If I could change the code so that these were in some other memory region (e.g. main's DAT), that would give me 2480 bytes and a total of 4704 bytes, which is very close to the 4800 required for the 80x30 full colour VGA frame buffer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/10/2010 9:49:50 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
It does still not fit, no. The sequential RAM range is too small.
80x30 stems from the 640/8 and 480/16 relation, i.e. screen size to font size. Font height can be any multiple of 4, so 8x20 would work and result in a 80x24 display. Of course a 8x20 font uses even more hub RAM: 256 more longs compared to the 8x16. 80x24 would OTOH save just 6x80x2 bytes = 240 longs of frame buffer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/11/2010 6:08:34 PM GMT
I'd like to split the VGA screen into 4 parts, with three MP/M users and also 1/4 for Help.
So as a start, I was wondering if there are some graphics characters in the VGA object. I wrote a little program to dump out the characters, and indeed, there are some characters from 128 up. VT100 can also put characters in any position on the screen, but for starters I thought I would write a quick MBASIC program to print a box and write something in it.
Apart from the blurry photo, it looks quite nifty. It will interesting to see where this goes...
[noparse][[/noparse]
addit - as an aside, when running User0 as the vga display, it is still possible to transfer files using user 1 or user 2. Simply pip the file to the other user eg
PIP BOX.BAS[noparse][[/noparse]G1]=BOX.BAS
also put xmodem on the other user, eg
PIP XMODEMF.BAS[noparse][[/noparse]G1]=XMODEMF.COM
]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/14/2010 2:06:01 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Changed speed to 6_500_000, top define to RamBladeProp and recompiled.
[noparse][[/noparse]...] 10060 RMDIR.BIN 346388 SST.BIN 18136 RB_BASIC.BIN 16112 BOOTPROP.BI_ 21160 QZ80.BIN 33554432 A.DSK SD:>spin qz80 SIO initialized, 5 cogs free. qZ80 I/O starting... Volume serial #00B3-0DDF, label NO NAME ?, sector 0382C7, size 514.7MB, 2058-02-19 27:00:00 A.DSK failed: -1 A.DSK failed: -1Renamed cpm.bin to qz80.bin, card size is really 1GB,
Are·qz80 binary and the A.DSK image enough? or some other file is needed, bootrom maybe?
You also need the BOOT.DSK image that is on the top of the thread - I hope - I have to check this.
It looks like the spi_warp.spin code isn't working right on the RamBlade, though, as it is telling Smile about the (probably missing) BOOT.DSK image.
I'll attach it here for you to try.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I very much like this line and I am using this permanently now.
However, it has upset these lines:
constat_port = $10 ' console 0 status port (on SIO #0) condata_port = $11 ' console 0 data port (on SIO #0) punstat_port = $12 ' punch 1 status port pundata_port = $13 ' punch/reader 1 data port con1stat_port = $14 ' console 1 status port (on Keyboard / VGA) con1data_port = $15 ' console 1 data port (on Keyboard / VGA)Specifically, if in MBASIC you use
OUT &H11,65
then the data goes to the VGA display.
I don't think you need to change any code, but maybe the comment needs to change
changed to
or maybe
if so, then the comments for ports $10,$11,$14 and $15 need changing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/16/2010 1:57:42 PM GMT
In addition to the above, a very technical question
How do I scan for keyboard input?
I tried this:
var a,b=integer for b=1 to 100 a=inp(10H) print a; next bBut it always returns "2" and never returns "3" (which I think is the value if a key has been pressed), even if pressing a key while the program is running. Am I reading the wrong port??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
No, the port is correct, but if you run this under MP/M, the system may fetch the port data before you have a chance to see the bit.
On CP/M it should work, as long as MBASIC doesn't call constat or conin inside the loop.
I think the easiest way to look for keyboard input is the INKEY$!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 5/17/2010 11:51:33 PM GMT
The only catch - I'm using sbasic which does not have INKEY$
I think I might look at BDS C for this one. Or maybe fire up the BASCOM compiler.
Addit: Yes there is a C instruction just for this purpose. BDS C looks like it will work very well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/20/2010 11:18:36 PM GMT
testforkeypress() /* wait for a keypress and return 255 if timeout or n=keypress*/ { int k,t; k=0; t=0; do { k=kbhit(); /* if any keyboard input then k is not zero */ t++; /* add one to timer */ if (t>2000) k=255; /* timeout */ } while (k==0); if (k !=255) { k=getchar(); /* get the character if not a timeout */ /* printf("getting character"); */ } return k; }I have an idea that I could run a program at startup that asked the user to hit a key if they want MP/M networking. If no keypress in a few seconds then it just skips this. And if the user does want networking, this program sends the text "NETWORK" to user 2 which starts the network program. It all works fine except for one minor problem:
When I run AUTOEXEC.SUB at bootup, it runs MP/M, but then MP/M seems to start from nothing and deletes the list of instructions so it does not run the next instruction.
Would there be a way of passing a list of SUBMIT instructions to MP/M?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The Colour Genie memory map was also changed to reflect the new screen access code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
There are so many emulations I'm having trouble keeping up!
Does the different color genie memory map fix the issues with games like Invader?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I've got two new boards being made. One is an enlarged version of the dracblade with RS485, and the other is a 'watchdog' board that can turn the dracblade on and off using packets, and check that it boots up correctly (occasionally MP/M won't boot properly).
For this, I am thinking of using two baud rates - 1200 and 9600 (maybe 19200) on the RS485 bus.
I was wondering if qZ80 is able to change baud rates using an OUT command?
I did have something similar working on the zicog emulation, and it was a matter of reloading the serial driver cog and restarting it with new settings. It would not matter if all users (ie both serial ports) were the same rate.
Do you think it would be possible to change the baud rates, either restarting a cog, or changing a value that is stored in a known location eg in hub?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
It should be possible to add two reads of two hub longs for the bit_ticks and bit_ticks1 values in the cog, which are the variables defining the baud rate of a channel. Then io.spin of cpm just needs one or two ports where you write a new rate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
This was the code in the zicog:
as you can see it was a fairly crude solution. Maybe not the most elegant. Restart the uart driver, set port 1 to the constant (which you have defined as variable 'baud'), but change the rate on the second port.
I did it this way because I think it ended up using the least amount of code.
But your idea of tracing the actual variable that holds the baud rate for port1 is intriguing. Maybe this would use even less code?
Which do you think is the most 'elegant' solution - 'poke' values to the baud rate variables, or restart the driver?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I changed the SIO object to read two variables with the bit times on every loop, so you can change the baud rate on the fly.
Perhaps you can try this first before I implement it in io.spin. I have no time right now to do it.
The variables are new_bit_ticks0 and new_bit_ticks1 for port 0 and 1, and they have to be set to clkfreq/baudrate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects