Ok, xmodemf source and compiled attached. Now with these huge drives, no problem including the source as well.
Baud rate - the fastest is 19200. The fundamental problem is that bytes are coming in to the 4 port serial object and are being gobbled up by CP/M but the packet size in xmodem is 131 bytes and the buffer size in the 4 port object is only 64 bytes. So the buffer overruns.
I thought once about only having 2 of the 4 serial ports used (we only use 2 anyway) and freeing up some memory for a bigger buffer, but the code is very complex.
I got one bdos error out of about 20 xmodem downloads, and it was just a matter of doing it again.
Are you interested in the vb.net program I use for writing code and downloading?
Addit: This is like discovering all sorts of christmas presents. The LCD has remained blank but I thought I would send something to the PUNCH device. Hey presto! It works!!!
10 A$="Hello World"
20 GOSUB 1000
30 END
1000 FOR I=1 TO LEN(A$)
1010 OUT &H13,ASC(MID$(A$,I,1))
1020 NEXT I
1030 RETURN
Ok
I can turn that into C or Sbasic which is a bit neater than mbasic
Dr_Acula said...
Ok, xmodemf source and compiled attached. Now with these huge drives, no problem including the source as well.
Baud rate - the fastest is 19200. The fundamental problem is that bytes are coming in to the 4 port serial object and are being gobbled up by CP/M but the packet size in xmodem is 131 bytes and the buffer size in the 4 port object is only 64 bytes. So the buffer overruns.
I thought once about only having 2 of the 4 serial ports used (we only use 2 anyway) and freeing up some memory for a bigger buffer, but the code is very complex.
I got one bdos error out of about 20 xmodem downloads, and it was just a matter of doing it again.
Are you interested in the vb.net program I use for writing code and downloading?
Well, I can have a look if there is a way to increase the buffer size and instead strip out 2 serial ports.
If you run Wordstar under MP/M you will quickly run into errors when it writes its *.$A$ and *.$B$ intermediate files. I think I have the retry code right now, because I can actually edit somethin in MP/M, too.
I can't use Visual Basic code on Linux I would have to dig out another terminal program that has xmodem support, or change gtkterm to support it. I already patched it to quit on Alt+Q instead of Ctrl-Q, because of Wordstar...
I'm running Teraterm on User 0 on COM1, VGA display for user 1, I've got a program printing to the local LCD display via the punch device.
So I got out a USB to serial device, plugged it into the USB port and started up another terminal program, Hyperterm. Connected to COM3 and the second Serial D9 on the Dracblade board with a Null modem cable (female to female, swap pins 2 and 3). Hit Enter and I am able to connect to User 2 with 2A>
Ok, how about this. Assembly, C and Basic all running on the Propeller AT THE SAME TIME!!
Just to show it can be done, here is a tiny little program running in three users at the same time.
10 PRINT A
20 A=A+1
30 IF A>1000 THEN A=0
40 GOTO 10
See attached photo.
Notes:
1) Speed of each emulation does not appear to slow down as more programs are added.
2) There does seem to be a slight slowdown of PIP file copying when a program is running.
3) The syntax for copying a program from one user to another is
PIP MBASIC.COM[noparse][[/noparse]G1]=MBASIC.COM
where Gn is the user number.
4) Download settings need to be slowed down a little - the ERA then XMODEM file transfer is taking about 2 seconds when other user programs are running, so when I am downloading a C program with BASIC running on other users the timing delay in the vb.net program needs extending slightly again. I do have C and BASIC running at the same time now, but I had to stop Basic while doing the C download.
Only one minor bug. The LCD display is printing line 1 then 3 then 2 then 4. Where are those settings hidden?
Dr_Acula said...
Only one minor bug. The LCD display is printing line 1 then 3 then 2 then 4. Where are those settings hidden?
The LCD output is the raw text output without handling of control characters or cursor wrapping. Writing to the LCD status/control port sends LCD instructions to the display (cursor on/off/block, display on/off, cursor position etc.). I could try to squeeze a "LCD screen" handler with text buffer into io.spin, while it may be easier to do this on the Z80 side of things. A driver that could live in the banked memory of MP/M perhaps...
BTW: I modified pcFullDuplexSerial4FC to ...2FC and spent the two possible ports a 256 rx buffer each. Surprisingly the change worked out of the box (which means there is a very nasty bug hidden somewhere [noparse]:)[/noparse]. I just transferred a file to the Propeller with xmodem running at 115k2 baud.
I'll pack everything together and release a new version as well as a new A.DSK with the sector read/write retry, the new SIO buffer sizes and your xmodemf code.
What's left to do before version 1.0 is to track down the bug that causes some TRS80 games to behave erratic.
You're making excellent progress you two [noparse]:)[/noparse] can't wait to join in the fun, but need some spare time [noparse]:([/noparse] which is coming up really soon!
This is truly funny. I go off and spend 10 minutes writing a quick email to the N8VEM group, and in that time pullmoll goes and rewrites the serial port driver so it can handle an xmodem data packet.
Juergen, do you have any idea how long I have stared at that code? It is days, weeks, months even!!!
I am more than happy!
I didn't appreciate how to talk to the LCD display. Which spin object is that in?
If you talk to each line directly, that is even better. And only a few lines of code in Basic or C. So don't change any of the spin/pasm code, just tell me what the syntax is - which port number etc. (I'm ok with LCD opcodes)
@baggers, can we start to dream about 80x40 VGA with each byte a variable color? Chunky color graphics for games? What would it take to run Wolfenstein - either vga or TV?
Dr_Acula said...
This is truly funny. I go off and spend 10 minutes writing a quick email to the N8VEM group, and in that time pullmoll goes and rewrites the serial port driver so it can handle an xmodem data packet.
Juergen, do you have any idea how long I have stared at that code? It is days, weeks, months even!!!
Nah, come on. It was just ripping out all variable2 and variable3 references, the whole block of port 2 and 3 code and the $3F masks changed to $FF. Finally the rx_buffer and rx_buffer1 needed a couple of longs more and that was it. As I said, I didn't even have to make any change after my first edit
Dr_Acula said...
I didn't appreciate how to talk to the LCD display. Which spin object is that in?
If you talk to each line directly, that is even better. And only a few lines of code in Basic or C. So don't change any of the spin code, just tell me what the syntax is.
The display is at the punch/reader ports: 18 (&H12) is the status on read, always returning %00000010 (tx possible, no rx char). Writing to this ports writes to the LCD in instruction mode. 19 (&H13) is the text mode write to the LCD - returns nothing on read. I don't have the LCD instructions handy, but they sure can be found on the net.
Where you mention colors: The VT100 escape sequences for the attribute colors now change the entire screen background / foreground, since we do not have per character colors (yet).
P.S.: I tried running MP/M with the q85.spin, but it didn't want to work. Now this isn't tragic, as everything seems to fit. If I managed to get it working, you would have ~2500 longs free, though.
but but but
Tim Moore said at the beginning of the code
'* Note: There are 8 longs remaining in the cog's memory, *
'* expect to do some work to add features [noparse]:)[/noparse]. *
You make it sound so easy. For a start, if the buffer size is 64 bytes with 4 ports and you have half the number of ports, how have you got to a 256 byte buffer?
Anyway, that sounds great. I think I've got enough to get the networking code ported over. Debug and packet info will go to the LCD display and/or to the VGA terminal, depending on whether a node is on 240V in a shed, or out in the field on a solar panel.
Meanwhile, time to look at games. Baggers has done some amazing things already.
Just a thought. If you have 80x40 vga characters and each of those is a solid block of color, and you refresh at 25 frames a second, and you have a color that is in 1 byte, that is 80,000 bytes per second. Is it possible to read this sort of information out of an external ram chip fast enough?
Dr_Acula said...
but but but
Tim Moore said at the beginning of the code
'* Note: There are 8 longs remaining in the cog's memory, *
'* expect to do some work to add features [noparse]:)[/noparse]. *
You make it sound so easy. For a start, if the buffer size is 64 bytes with 4 ports and you have half the number of ports, how have you got to a 256 byte buffer?
There was more data per port, such as the bit masks and various other bits - and of course all the code lines that were thrown out. I didn't count, just tried it and it fits. There are actually 152 free longs in the SIO cog now.
Dr_Acula said...
Just a thought. If you have 80x40 vga characters and each of those is a solid block of color, and you refresh at 25 frames a second, and you have a color that is in 1 byte, that is 80,000 bytes per second. Is it possible to read this sort of information out of an external ram chip fast enough?
I also thought if this was possible. I guess that if you use the locking mechanism to make sure you have the I/O pins in the VGA renderer, you could burst read 256 bytes a time with just chaning the LSB latch. It needs some cycle calculation to see if this is fast enough for one attribute per character. 12 times 256 reads and then 128 once, 25 times per second. It may be possible with another, dedicated cog that would always ensure that 80 bytes for the current character row are ready. If it is possible to tweak the VGA code to do an attribute per character is more questionable. I think it is at the very limit of cycles per VSCL frame.
BTW My 1pinKBD seems to work with all keyboards so far, so 2 pins and 2 cogs will get you 1pin TV & 1pin KBD for mono 64x25 chars.
I don't use 1 pin KBD, as the DracBlade has a regular PS/2 port, but a modified version of your 1 pin TV doing 80x25 is part of what I ship with qz80.
The only thing that's not so nice about it is the distorted first 4-5 active scanlines. I couldn't get them straight by shifting the active range down, i.e. drawing more blank lines at top and fewer at the bottom, so I think it has to be something else that causes this. To illustrate the effect, this is how a block cursor at 0,0 looks like:
Baggers said...
Hi Guys, are you wanting a 640x480 VGA with 8x8 font, two ( or 4 ) colours per character?
Can I use Prop HUB RAM for the display?
Two colors per character would be required, but the 3200 bytes (4 bits bg, 4 bits fg color) of attributes probably won't fit in the hub RAM anymore. They would have to come from external RAM, and fetching them would be target dependent... You have up to 3 cogs available if we ditch the standard VGA_HighRes_Text object.
I can supply code to access the DracBlade external RAM if needed. It's not too difficult, it's just that we have to use locking in order to prevent concurrent access to the external RAM. You would probably need to burst read a character row of attributes in a separate cog in order to have them ready in time. Perhaps also the screen buffer could be put in external RAM, so one cog could be fetching character/attribute rows in time for the VGA cog to render them from always the same character/attribute row buffer?
1) Changing the buffer size of the serial ports has made a huge difference to the maximum baud rate of xmodem. I had a previous maximum of 19200 baud, but it now works fine at 115200 baud. Of course, the real transfer rate is a little lower than that. It is now limited by the rate data can be stored to the sd card. However, a transfer of MBASIC.COM is extremely fast and so is the download of compiled C and SBASIC programs. Now the write/compile/download/edit/download cycle for development is a lot faster.
2) A minor bug with Teraterm - it won't save the baud rate of 115200 and keeps changing it to 9600. Other baud rates are ok. So I can't use Teraterm. However, Hyperterminal works. Also my vb.net IDE works. Tested both with xmodem file transfers.
3) I added MPM to the AUTOEXEC.SUB file and now it auto boots into MPM. This is stable enough that I don't think I need to be in CP/M any more. Plus I want the VGA and keyboard to start working without needing a PC running a terminal program in order to write "MPM"
This is truly amazing. And extremely useful.
I have another tiny request. If I run a packet decoder program in one user, I can send data to another user by writing to one of the new ports. But, how can I get data to come back again?
Let's say we send a request to a user via one of those special ports. We send "DIR"
The user responds with a listing to the local device - eg it sends it to the VGA display.
Can we also send it back to the requesting user?
I have been thinking about ways to do this. Back in the olden days, I think you could type ^P at the CP/M prompt and it would sent everything you typed to the Printer. It was like a typewriter. I'm not exactly sure what the "Printer" is in MPM. But I was thinking if you could send output to a port that is a printer, with ^P, you could log into a user with ^P to switch on output, then collect the bytes. I was also thinking of a byte buffer, but you probably don't need one. If you output one byte, but the byte has to be cleared by the receiving program. If you output a second byte, it hangs until the first byte is cleared.
Or maybe a buffer is easier, but it ought to store in external ram?? as hub is running out??
I am thinking of the scenario where the DIR is being created by Assembly (which is fast) but it is being processed by a slower high level language (C or Basic). So the easiest is probably to block the sender and make the sender 'hang' till the byte is read.
Or maybe there is another way?
I'm also thinking about a little "terminal" program that connects to other users (eg ones that have no physical connection). How many users do we have? Could you send a message to a user to run some code and give you the answer? Hmm - you can start to think of the emulation as a parallel machine in the same way you think about the propeller as a parallel machine. I'm not sure how to use that yet. But then again, the ways to use the propeller probably were not obvious at the beginning either.
jp list ; list character out
jp rtnempty ; punch not implemented
jp rtnempty ; reader not implemented
And the list output goes to the port pundata, which is the raw LCD in our case... not too useful.
There are some blocks of unused RAM available. I changed the banking to use 64K chunks, because there is a maximum of 7 additional banks in MPM. We could think about making the extra 7 * 16KB ($c000-$ffff range of bank 1..7) available through ports and redirect the list output there. I think there is only one LST device (or ^P redirector) for the entire system, not one per user, so that port accessible memory would be a shared resource.
If I changed the banking size back to $c000 (or rather banksize) chunks, we would be left with a consecutive range of currently 7*$4000 =$1c000 = 114688 bytes at the end of the RAM.
For simplicity we could define just one output port to write to a head_ptr in high RAM and one input port to read from a tail_ptr in high RAM. There could be a status port for reading (and writing?) indicating when characters are available in the buffer. For writing we could either ignore the buffer full condition, or hold on the out command until some other process read at least one character from the buffer. The problem is if there is no one reading the buffer, the writing process will be stuck in an out command and could not be stopped.
I think that we should probably move the LCD to some other ports in any case, because the raw text output isn't really useful as a "printer" replacement.
There are as many users as consoles, so we now have 3 users running. If we would add more users, the common memory range would grow (I don't know by how much) and their console ports would at least have to return a status of $02 (tx empty, no rx available). The problem is that the io.spin cog is rather full (3 longs left), and even LMM code needs the 3 instructions to setup the pointer, call the lmm function and return to the command loop. The only code that could be LMMized is the LCD code (14 longs). I would have to replace the nested calls by inlined code, because a LMM function can't call another LMM function now (-> 2*12 longs). This would use some more longs of the (still) available hub RAM.
Dr_A: MP/M uses queues to communicate between the user and the Terminal Message Processor. I remember long ago one of the magazines described some mods to support batch processing whereby there was a program that pushed commands from a file into a queue and took the output and put it into a file. It was setup effectively as a user without a physical terminal. I implemented it on one of my mp/m systems and if I recall it wasn't a big job.
Maybe you could create your packet processor as a user process and use the virtual terminal to push commands into the system?
One little problem I noticed when I setup a new SD card. I forgot to put the boot.dsk file on the sd card. The system started up but it didn't report the the file was missing and just hung when it tried to start qZ80.
Also has anyone had problems with the second serial port? I had to change the speed down to 19200 as my olds PC couldn't support 115200 and I get output on the serial port ok but as soon as I type anything is looks like the receive baud rate is wrong as I get random characters being echoed back?
MaxS said...
One little problem I noticed when I setup a new SD card. I forgot to put the boot.dsk file on the sd card. The system started up but it didn't report the the file was missing and just hung when it tried to start qZ80.
Also has anyone had problems with the second serial port? I had to change the speed down to 19200 as my olds PC couldn't support 115200 and I get output on the serial port ok but as soon as I type anything is looks like the receive baud rate is wrong as I get random characters being echoed back?
Did the second serial port work with the version before I changed to the pcFullDuplexSerial2FC code? I may have broken something for the second port when I ripped out port 3 and 4 code from the source. I think that Dr_A had tested it before, but not (yet) with the new code.
pullmoll: I wasn't seeing any distortion on the TV. What clock speed are you running? Are you running NTSC or are you using PAL? IIRC 80x25 requires a higher clock (don't have code with me). You can move the screen down a few lines - I will look later and post a mod for this to try.
Baggers: We are using 1 cog and the hub code space is reclaimed as the 2K screen buffer. It is B&W mono only.
Jurgen, I see your qz80 is progressing nicely - congratulations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
pullmoll: I wasn't seeing any distortion on the TV. What clock speed are you running? Are you running NTSC or are you using PAL? IIRC 80x25 requires a higher clock (don't have code with me). You can move the screen down a few lines - I will look later and post a mod for this to try.
I run at 5MHz * 16xPLL, PAL. I managed to do 80x25 by combining 4 characters into one waitvid of 4*6 pixels. Moving the screen up or down doesn't change anything - that's what seemed odd to me.
For VGA we're using the 2 cog VGA_HiRes_Text object and I think that could be replaced with something that can do per character colors. That would be nice to have, if Baggers manages to do it. The VT100 emulation is ready to store a lot of attributes along with the character. Highlighting could be done with a palette of 16 colors, inverse with the high bit of the character code (already done that way).
MaxS said...
I have only tried qz80-0.9.17. Sorry didn't notice that have been a couple of updates. I'l try the latest tonight and see if it is still a problem.
Before 0.9.18 or 0.9.19 there was a problem with the 2nd SIO port read code, which wouldn't read data from the tail pointer, but always from the first byte of the buffer. I think this bug was still in 0.9.17, so that may be what you're seeing. I'll wait how 0.9.21 works for you.
The latest version now uses external memory as kind of a printer spooler buffer. A small piece of code that follows the buffer and prints it to the local console is this:
0100 LD C,0B ; console status func
0102 CALL 0005 ; call BDOS
0105 OR A ; do we have a keyboard input?
0106 JR Z,0110 ; no, skip
0108 LD C,01 ; yes, read a character
010A CALL 0005 ; call BDOS
010D CP 03 ; is it ^C?
010F RET Z ; yes, return from program
0110 IN A,(12) ; get shared memory status
0112 AND 01 ; is a character available?
0114 JR Z,0100 ; no, poll again
0116 IN A,(13) ; yes, get character
0118 LD E,A ; to E
0119 LD C,02 ; console output func
011B CALL 0005 ; call BDOS
011E JR 0100 ; poll again
I hacked it in using DDTZ and saved it with SAVE 1 TAIL.COM in CP/M. After switching to MPM I then copied it for user 1 with PIP TAIL.COM[noparse][[/noparse]G1]=TAIL.COM and started it on user 1's console. On the main console hitting ^P and doing a DIR then redirects output to the printer, and thus to user 1 listening on the shared memory port. You could use it the other way round as well, but only 1 user at a time may use the printer. Hitting ^P will print an error message, if the printer is busy.
Writing a 3 (reset) to the punch status port 18 ($12) resets the head and tail pointers to zero.
I think this is all you need Dr_A!?
Did you try my code with 64x25 PAL mode at 80MHz with Inverse removed and did that work? If not, I suggest you see if this works because 60x25 at 8x8 (60x8=480 pixels) is equivalent to 80x20 at 6x9 (80x6=480 pixels).
If so, then maybe there is a timing problem with your code or the timing calcs need rework?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
That sounds great pullmoll. I've been away from my propeller chip for nearly 24 hours now and withdrawals are starting to set in. I'm looking forward to testing this.
pullmoll said...
Before 0.9.18 or 0.9.19 there was a problem with the 2nd SIO port read code, which wouldn't read data from the tail pointer, but always from the first byte of the buffer. I think this bug was still in 0.9.17, so that may be what you're seeing. I'll wait how 0.9.21 works for you.
@Dr_A: Here's tail.com as an attachment. Had to rename it to tail.bin for the upload. It's fun to do this: ^P and DIR, perhaps stop by pressing any key, then run TAIL. It prints the directory again, then the tail command and then the story repeats da capo al fine
@MaxS: Good to know, so SIO #1 is working as it should be.
Cluso99 said...
pullmoll: I looked at your modified 1pin code.
Did you try my code with 64x25 PAL mode at 80MHz with Inverse removed and did that work? If not, I suggest you see if this works because 60x25 at 8x8 (60x8=480 pixels) is equivalent to 80x20 at 6x9 (80x6=480 pixels).
If so, then maybe there is a timing problem with your code or the timing calcs need rework?
Yes, recalculating the timing did the trick! I suppose I had one or more bugs in manually converting the 4096+xx values to xx only. Now I modified 1pinTV_calcs_rr001.spin to print the values as 4096+xx in the first place. As you may have noticed, I use movs to modify the lower 9 bits of VSCL instead of always writing the higher 9 bits, too. So this tv80.spin gives 80x25 at 80MHz with inverse characters by wasting lots of hub RAM for the inverted font.
1) Both serial ports are working fine for me too.
2) LCD is working but I'll need to write some example driver code in C or BASIC to replicate the spin code simple terminal
3) Re the print spool buffer, this is absolutely brilliant. It is a great way to transfer data to and from users, and also replicates the real print buffers on older machines (there were add-on projects that did this and they cost a lot of money).
A tiny program could output to a real printer if you wanted.
A quick little MBASIC program to test the print spooler.
10 OUT (18),3: ' set head and tail to be equal
20 LPRINT "Hello World"
30 PRINT "Reading data back from print spool buffer"
40 A=INP(18)
50 IF A<>3 THEN END
60 A=INP(19)
70 PRINT CHR$(A);
80 GOTO 40
4) I'm very occasionally getting those BDOS errors loading and saving files.
5) Local compilation of SBASIC programs takes about 30 seconds. SIMH compilation and download is about 10 seconds.
Dr_Acula said...
4) I'm very occasionally getting those BDOS errors loading and saving files.
I have no idea how to solve this - and why they still slip through. 3 retries is a lot already. Perhaps I could disable interrupts while trying to read/write a sector...
FWIW I played a bit with Turbo Pascal. I found version 3.01 at some retro computing site and downloaded it to the Prop with xmodem. Now this is fun seeing how your fingers alone remember those old key sequences. It is as if it was yesterday that I hacked on my Schneider CPC464 with Turbo. It only seems I forgot some things related to Pascal over the years of using nothing but C.
Comments
Baud rate - the fastest is 19200. The fundamental problem is that bytes are coming in to the 4 port serial object and are being gobbled up by CP/M but the packet size in xmodem is 131 bytes and the buffer size in the 4 port object is only 64 bytes. So the buffer overruns.
I thought once about only having 2 of the 4 serial ports used (we only use 2 anyway) and freeing up some memory for a bigger buffer, but the code is very complex.
I got one bdos error out of about 20 xmodem downloads, and it was just a matter of doing it again.
Are you interested in the vb.net program I use for writing code and downloading?
Addit: This is like discovering all sorts of christmas presents. The LCD has remained blank but I thought I would send something to the PUNCH device. Hey presto! It works!!!
I can turn that into C or Sbasic which is a bit neater than mbasic
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/21/2010 12:20:06 PM GMT
Well, I can have a look if there is a way to increase the buffer size and instead strip out 2 serial ports.
If you run Wordstar under MP/M you will quickly run into errors when it writes its *.$A$ and *.$B$ intermediate files. I think I have the retry code right now, because I can actually edit somethin in MP/M, too.
I can't use Visual Basic code on Linux
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I'm running Teraterm on User 0 on COM1, VGA display for user 1, I've got a program printing to the local LCD display via the punch device.
So I got out a USB to serial device, plugged it into the USB port and started up another terminal program, Hyperterm. Connected to COM3 and the second Serial D9 on the Dracblade board with a Null modem cable (female to female, swap pins 2 and 3). Hit Enter and I am able to connect to User 2 with 2A>
Ok, how about this. Assembly, C and Basic all running on the Propeller AT THE SAME TIME!!
Just to show it can be done, here is a tiny little program running in three users at the same time.
See attached photo.
Notes:
1) Speed of each emulation does not appear to slow down as more programs are added.
2) There does seem to be a slight slowdown of PIP file copying when a program is running.
3) The syntax for copying a program from one user to another is
PIP MBASIC.COM[noparse][[/noparse]G1]=MBASIC.COM
where Gn is the user number.
4) Download settings need to be slowed down a little - the ERA then XMODEM file transfer is taking about 2 seconds when other user programs are running, so when I am downloading a C program with BASIC running on other users the timing delay in the vb.net program needs extending slightly again. I do have C and BASIC running at the same time now, but I had to stop Basic while doing the C download.
Only one minor bug. The LCD display is printing line 1 then 3 then 2 then 4. Where are those settings hidden?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/21/2010 12:54:27 PM GMT
Glad to see you are (almost) happy
The LCD output is the raw text output without handling of control characters or cursor wrapping. Writing to the LCD status/control port sends LCD instructions to the display (cursor on/off/block, display on/off, cursor position etc.). I could try to squeeze a "LCD screen" handler with text buffer into io.spin, while it may be easier to do this on the Z80 side of things. A driver that could live in the banked memory of MP/M perhaps...
BTW: I modified pcFullDuplexSerial4FC to ...2FC and spent the two possible ports a 256 rx buffer each. Surprisingly the change worked out of the box (which means there is a very nasty bug hidden somewhere [noparse]:)[/noparse]. I just transferred a file to the Propeller with xmodem running at 115k2 baud.
I'll pack everything together and release a new version as well as a new A.DSK with the sector read/write retry, the new SIO buffer sizes and your xmodemf code.
What's left to do before version 1.0 is to track down the bug that causes some TRS80 games to behave erratic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/21/2010 1:42:27 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Juergen, do you have any idea how long I have stared at that code? It is days, weeks, months even!!!
I am more than happy!
I didn't appreciate how to talk to the LCD display. Which spin object is that in?
If you talk to each line directly, that is even better. And only a few lines of code in Basic or C. So don't change any of the spin/pasm code, just tell me what the syntax is - which port number etc. (I'm ok with LCD opcodes)
@baggers, can we start to dream about 80x40 VGA with each byte a variable color? Chunky color graphics for games? What would it take to run Wolfenstein - either vga or TV?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/21/2010 1:49:34 PM GMT
Nah, come on. It was just ripping out all variable2 and variable3 references, the whole block of port 2 and 3 code and the $3F masks changed to $FF. Finally the rx_buffer and rx_buffer1 needed a couple of longs more and that was it. As I said, I didn't even have to make any change after my first edit
The display is at the punch/reader ports: 18 (&H12) is the status on read, always returning %00000010 (tx possible, no rx char). Writing to this ports writes to the LCD in instruction mode. 19 (&H13) is the text mode write to the LCD - returns nothing on read. I don't have the LCD instructions handy, but they sure can be found on the net.
Where you mention colors: The VT100 escape sequences for the attribute colors now change the entire screen background / foreground, since we do not have per character colors (yet).
P.S.: I tried running MP/M with the q85.spin, but it didn't want to work. Now this isn't tragic, as everything seems to fit. If I managed to get it working, you would have ~2500 longs free, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/21/2010 1:57:05 PM GMT
Tim Moore said at the beginning of the code
'* Note: There are 8 longs remaining in the cog's memory, *
'* expect to do some work to add features [noparse]:)[/noparse]. *
You make it sound so easy. For a start, if the buffer size is 64 bytes with 4 ports and you have half the number of ports, how have you got to a 256 byte buffer?
Anyway, that sounds great. I think I've got enough to get the networking code ported over. Debug and packet info will go to the LCD display and/or to the VGA terminal, depending on whether a node is on 240V in a shed, or out in the field on a solar panel.
Meanwhile, time to look at games. Baggers has done some amazing things already.
Just a thought. If you have 80x40 vga characters and each of those is a solid block of color, and you refresh at 25 frames a second, and you have a color that is in 1 byte, that is 80,000 bytes per second. Is it possible to read this sort of information out of an external ram chip fast enough?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
There was more data per port, such as the bit masks and various other bits - and of course all the code lines that were thrown out. I didn't count, just tried it and it fits. There are actually 152 free longs in the SIO cog now.
I also thought if this was possible. I guess that if you use the locking mechanism to make sure you have the I/O pins in the VGA renderer, you could burst read 256 bytes a time with just chaning the LSB latch. It needs some cycle calculation to see if this is fast enough for one attribute per character. 12 times 256 reads and then 128 once, 25 times per second. It may be possible with another, dedicated cog that would always ensure that 80 bytes for the current character row are ready. If it is possible to tweak the VGA code to do an attribute per character is more questionable. I think it is at the very limit of cycles per VSCL frame.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
BTW My 1pinKBD seems to work with all keyboards so far, so 2 pins and 2 cogs will get you 1pin TV & 1pin KBD for mono 64x25 chars.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I don't use 1 pin KBD, as the DracBlade has a regular PS/2 port, but a modified version of your 1 pin TV doing 80x25 is part of what I ship with qz80.
The only thing that's not so nice about it is the distorted first 4-5 active scanlines. I couldn't get them straight by shifting the active range down, i.e. drawing more blank lines at top and fewer at the bottom, so I think it has to be something else that causes this. To illustrate the effect, this is how a block cursor at 0,0 looks like:
xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/21/2010 3:20:37 PM GMT
Can I use Prop HUB RAM for the display?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Two colors per character would be required, but the 3200 bytes (4 bits bg, 4 bits fg color) of attributes probably won't fit in the hub RAM anymore. They would have to come from external RAM, and fetching them would be target dependent... You have up to 3 cogs available if we ditch the standard VGA_HighRes_Text object.
I can supply code to access the DracBlade external RAM if needed. It's not too difficult, it's just that we have to use locking in order to prevent concurrent access to the external RAM. You would probably need to burst read a character row of attributes in a separate cog in order to have them ready in time. Perhaps also the screen buffer could be put in external RAM, so one cog could be fetching character/attribute rows in time for the VGA cog to render them from always the same character/attribute row buffer?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/21/2010 4:34:24 PM GMT
1) Changing the buffer size of the serial ports has made a huge difference to the maximum baud rate of xmodem. I had a previous maximum of 19200 baud, but it now works fine at 115200 baud. Of course, the real transfer rate is a little lower than that. It is now limited by the rate data can be stored to the sd card. However, a transfer of MBASIC.COM is extremely fast and so is the download of compiled C and SBASIC programs. Now the write/compile/download/edit/download cycle for development is a lot faster.
2) A minor bug with Teraterm - it won't save the baud rate of 115200 and keeps changing it to 9600. Other baud rates are ok. So I can't use Teraterm. However, Hyperterminal works. Also my vb.net IDE works. Tested both with xmodem file transfers.
3) I added MPM to the AUTOEXEC.SUB file and now it auto boots into MPM. This is stable enough that I don't think I need to be in CP/M any more. Plus I want the VGA and keyboard to start working without needing a PC running a terminal program in order to write "MPM"
This is truly amazing. And extremely useful.
I have another tiny request. If I run a packet decoder program in one user, I can send data to another user by writing to one of the new ports. But, how can I get data to come back again?
Let's say we send a request to a user via one of those special ports. We send "DIR"
The user responds with a listing to the local device - eg it sends it to the VGA display.
Can we also send it back to the requesting user?
I have been thinking about ways to do this. Back in the olden days, I think you could type ^P at the CP/M prompt and it would sent everything you typed to the Printer. It was like a typewriter. I'm not exactly sure what the "Printer" is in MPM. But I was thinking if you could send output to a port that is a printer, with ^P, you could log into a user with ^P to switch on output, then collect the bytes. I was also thinking of a byte buffer, but you probably don't need one. If you output one byte, but the byte has to be cleared by the receiving program. If you output a second byte, it hangs until the first byte is cleared.
Or maybe a buffer is easier, but it ought to store in external ram?? as hub is running out??
I am thinking of the scenario where the DIR is being created by Assembly (which is fast) but it is being processed by a slower high level language (C or Basic). So the easiest is probably to block the sender and make the sender 'hang' till the byte is read.
Or maybe there is another way?
I'm also thinking about a little "terminal" program that connects to other users (eg ones that have no physical connection). How many users do we have? Could you send a message to a user to run some code and give you the answer? Hmm - you can start to think of the emulation as a parallel machine in the same way you think about the propeller as a parallel machine. I'm not sure how to use that yet. But then again, the ways to use the propeller probably were not obvious at the beginning either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
jp list ; list character out jp rtnempty ; punch not implemented jp rtnempty ; reader not implementedAnd the list output goes to the port pundata, which is the raw LCD in our case... not too useful.
There are some blocks of unused RAM available. I changed the banking to use 64K chunks, because there is a maximum of 7 additional banks in MPM. We could think about making the extra 7 * 16KB ($c000-$ffff range of bank 1..7) available through ports and redirect the list output there. I think there is only one LST device (or ^P redirector) for the entire system, not one per user, so that port accessible memory would be a shared resource.
If I changed the banking size back to $c000 (or rather banksize) chunks, we would be left with a consecutive range of currently 7*$4000 =$1c000 = 114688 bytes at the end of the RAM.
For simplicity we could define just one output port to write to a head_ptr in high RAM and one input port to read from a tail_ptr in high RAM. There could be a status port for reading (and writing?) indicating when characters are available in the buffer. For writing we could either ignore the buffer full condition, or hold on the out command until some other process read at least one character from the buffer. The problem is if there is no one reading the buffer, the writing process will be stuck in an out command and could not be stopped.
I think that we should probably move the LCD to some other ports in any case, because the raw text output isn't really useful as a "printer" replacement.
There are as many users as consoles, so we now have 3 users running. If we would add more users, the common memory range would grow (I don't know by how much) and their console ports would at least have to return a status of $02 (tx empty, no rx available). The problem is that the io.spin cog is rather full (3 longs left), and even LMM code needs the 3 instructions to setup the pointer, call the lmm function and return to the command loop. The only code that could be LMMized is the LCD code (14 longs). I would have to replace the nested calls by inlined code, because a LMM function can't call another LMM function now (-> 2*12 longs). This would use some more longs of the (still) available hub RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/22/2010 10:31:04 PM GMT
Maybe you could create your packet processor as a user process and use the virtual terminal to push commands into the system?
Also has anyone had problems with the second serial port? I had to change the speed down to 19200 as my olds PC couldn't support 115200 and I get output on the serial port ok but as soon as I type anything is looks like the receive baud rate is wrong as I get random characters being echoed back?
Did the second serial port work with the version before I changed to the pcFullDuplexSerial2FC code? I may have broken something for the second port when I ripped out port 3 and 4 code from the source. I think that Dr_A had tested it before, but not (yet) with the new code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/22/2010 11:14:52 PM GMT
Baggers: We are using 1 cog and the hub code space is reclaimed as the 2K screen buffer. It is B&W mono only.
Jurgen, I see your qz80 is progressing nicely - congratulations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I run at 5MHz * 16xPLL, PAL. I managed to do 80x25 by combining 4 characters into one waitvid of 4*6 pixels. Moving the screen up or down doesn't change anything - that's what seemed odd to me.
For VGA we're using the 2 cog VGA_HiRes_Text object and I think that could be replaced with something that can do per character colors. That would be nice to have, if Baggers manages to do it. The VT100 emulation is ready to store a lot of attributes along with the character. Highlighting could be done with a palette of 16 colors, inverse with the high bit of the character code (already done that way).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/22/2010 11:48:25 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I hacked it in using DDTZ and saved it with SAVE 1 TAIL.COM in CP/M. After switching to MPM I then copied it for user 1 with PIP TAIL.COM[noparse][[/noparse]G1]=TAIL.COM and started it on user 1's console. On the main console hitting ^P and doing a DIR then redirects output to the printer, and thus to user 1 listening on the shared memory port. You could use it the other way round as well, but only 1 user at a time may use the printer. Hitting ^P will print an error message, if the printer is busy.
Writing a 3 (reset) to the punch status port 18 ($12) resets the head and tail pointers to zero.
I think this is all you need Dr_A!?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/23/2010 1:47:05 AM GMT
Did you try my code with 64x25 PAL mode at 80MHz with Inverse removed and did that work? If not, I suggest you see if this works because 60x25 at 8x8 (60x8=480 pixels) is equivalent to 80x20 at 6x9 (80x6=480 pixels).
If so, then maybe there is a timing problem with your code or the timing calcs need rework?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
@MaxS: Good to know, so SIO #1 is working as it should be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Yes, recalculating the timing did the trick! I suppose I had one or more bugs in manually converting the 4096+xx values to xx only. Now I modified 1pinTV_calcs_rr001.spin to print the values as 4096+xx in the first place. As you may have noticed, I use movs to modify the lower 9 bits of VSCL instead of always writing the higher 9 bits, too. So this tv80.spin gives 80x25 at 80MHz with inverse characters by wasting lots of hub RAM for the inverted font.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
2) LCD is working but I'll need to write some example driver code in C or BASIC to replicate the spin code simple terminal
3) Re the print spool buffer, this is absolutely brilliant. It is a great way to transfer data to and from users, and also replicates the real print buffers on older machines (there were add-on projects that did this and they cost a lot of money).
A tiny program could output to a real printer if you wanted.
A quick little MBASIC program to test the print spooler.
10 OUT (18),3: ' set head and tail to be equal
20 LPRINT "Hello World"
30 PRINT "Reading data back from print spool buffer"
40 A=INP(18)
50 IF A<>3 THEN END
60 A=INP(19)
70 PRINT CHR$(A);
80 GOTO 40
4) I'm very occasionally getting those BDOS errors loading and saving files.
5) Local compilation of SBASIC programs takes about 30 seconds. SIMH compilation and download is about 10 seconds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/23/2010 2:04:06 PM GMT
I have no idea how to solve this - and why they still slip through. 3 retries is a lot already. Perhaps I could disable interrupts while trying to read/write a sector...
FWIW I played a bit with Turbo Pascal. I found version 3.01 at some retro computing site and downloaded it to the Prop with xmodem. Now this is fun seeing how your fingers alone remember those old key sequences. It is as if it was yesterday that I hacked on my Schneider CPC464 with Turbo. It only seems I forgot some things related to Pascal over the years of using nothing but C.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects