Ross: No hurry for me. I am documenting it as I build it. I am also going to do some current consumption tests along the way.
Here is v092 (minor update so not posted to the start of the thread) There is now only one place for the baudrate to be set and I am using a modified PC_Text and PC_Keyboard. The start methods are now like the FullDuplexSerial, so I can pass the baudrate. I no longer use FullDuplexSerial.
Heater - do you want me to change your start parameters too and use the modified PC_Text & PC_Keyboard·routines? Ultimately I guess I should do a modified FullDuplexSerial so we only have to use 1 cog instead of 2. BTW do you have the hard disk working? I see code for 4 x hard disks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks for the update. This new version seems much much simpler. All the bits are in the package and it downloads and compiles instantly. I don't know what you changed with the baudrate and serial objects, but whatever it was, it is brilliant because my system now seems to be able to handle 115k baud.
The only minor change I've got now is adding that linefeed. I'm working through getting the propterminal program working. It is opening in a tiny window and I think that has something to do with the fonts. I'll try to get the font installed.
Down the track, ? a zip package that includes propterminal as well. And maybe the instructions for the font once I find that again (it was in a thread somewhere).
Once I get that working, I'll get to work on the code for xmodem so we can transfer files to the sd card. I saw your post on the n8vem forum - I don't think you need to understand the disk format. This is the nice thing about cp/m - there are lots of calls already written to access the disk and they are already there in the code. for instance, in xmodem is a routine to open a file (the BDOS bit)
OPENFIL:XOR A ; SET EXT & REC # TO 0 FOR PROPER OPEN
LD (FCBEXT),A
LD (FCBSNO),A
LD DE,FCB ; POINT TO FILE
LD C,OPEN ; GET FUNCTION
CALL BDOS ; OPEN IT
INC A ; OPEN OK?
JP NZ,OPENOK ; ..YES
CALL ERXIT ; ..NO, ABORT
.DB "++OPEN ERROR++",CR,LF,'$'
I know how to get a byte from the serial input and I know how to send a byte. Both are trapped in the I/O. So the only bit of spin I need to write is the bit to ask the serial input object if it has a byte or not. Back to coding...
James: Shouldn't be any faster than v091 I posted yesterday.
For asking the serial object if a byte is ready use kb.getkey or kb.gotkey (see PC_Keyboard.spin). No, I am not interested in the CPM disk structure.
I have modified PC_Text to add a LF after CR (optional #define addLF in ZiCog_demo009_rr093). I have not tested it, so could you please do that, thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Just remembered... I compiled v093 on bst and it passes the #defines to lower objects. So just add the #define line to the top of PC_Text as well for now.
The file download is proving tricky. Need to test every step of the way in mbasic, and also every step from the PC end with a vb.net program (coded to run xmodem - slowly), and also a serial port sniffer program.
PRI on_input
'Handle Z80 IO port reads
case io_port
srport: 'Altair front panel switches register
in_srport
simhport: 'SIMH control port
in_simhport
constat: 'Console status port.
in_constat
condata: 'Console data port
in_condata
statin: 'Altair disk status port
in_statin
secpos: 'Altair disk sector position port
in_secpos
dskread: 'Altair disk read port
in_dskread
n8vem_uart_test: ' test port $6D
in_test_n8vem ' is a byte ready returns 0 for no byte, 1 for a byte
n8vem_uart_in: ' ask for input from port $68
in_condata ' get the byte
and then
PRI in_test_n8vem
' for xmodem tests if any input from the serial port
if kb.gotkey == 0
io_data :=%00000000
else
io_data :=%00000001
and then
PRI on_output
'Handle Z80 IO port writes
case io_port
ledport: 'An 8 bit parallel output with LEDs attached
out_ledport
simhport: 'SIMH control port
out_simhport
condata: 'Console data port
out_condata
constat: 'Console status port
out_constat
punstat:
out_punstat 'Punch control port
selout: 'Altair disk controller select port
out_selout
dskcon: 'Altair disk function port
out_dskcon
dskwrit: 'Altair disk write port
out_dskwrit
n8vem_uart_out:
out_n8vem_byte
and
PRI out_n8vem_byte
' TV.str(string("Write to n8vem uart I/O Port $ "))
' TV.hex(io_data,2)
' TV.out(13)
TV.out(io_data) ' send out the data to the port (for xmodem)
the problem is that for some reason xmodem is running about 20x slower than it should be. Maybe some of the instructions in the delay loop are actually a lot slower to emulate. So I need to go through the delays and change a few settings. At present it is a catch22 - I can't download a file in order to download a file. So every change to xmodem involves a recompile using TASM, then importing into a disk image on the SIMH, then exporting it, then running it through the vb6 program to convert from 137 to 128 bytes, then putting the sd card in the sd card reader and copying the new disk b image, then doing a pip of the xmodem program to drive A, then testing it. Am getting there, but slowly.
Also, the input checking routine to see if a byte is present is very slow too. Like half a second between checks. A quick mbasic program found that. So some things might need changing a bit.
Hmm - addit, here is an odd bug:
10 FOR A=0 TO 255
20 PRINT CHR$(A);
30 FOR B=1 TO 500:NEXT B
40 NEXT A
And now watch that on the sniffer program. It prints all the numbers perfectly from 0 to 7 and from 10 to 255. But numbers 8 and 9 come out as eight ascii 32s. And they come out quickly too, whereas the other numbers come out with a delay of a second between them.
I cannot see anything in the text out code that would do this. This is the conout data:
PRI out_condata
'Handle writes to the console data output port
'data := data & $7F 'Use this for 4KBASIC which spits out Smile
' if io_data <> 10
TV.out(io_data)
so 10 is commented out. Every byte should go through to here:
PUB out(c) | i, k
'' Output a character
''
'' $00 = clear screen
'' $01 = home
'' $08 = backspace
'' $09 = tab (8 spaces per)
'' $0A = set X position (X follows)
'' $0B = set Y position (Y follows)
'' $0C = set color (color follows)
'' $0D = return
'' others = printable characters
print(c)
{{
PUB setcolors(colorptr) | i, fore, back
'' Override default color palette in real driver
'' not used here
}}
PRI print(c)
'' Send byte (may wait for room in buffer)
repeat until (tx_tail <> (tx_head + 1) & $1FF)
tx_buffer[noparse][[/noparse]tx_head] := c
tx_head := (tx_head + 1) & $1FF
DAT
'***********************************
'* Assembly language serial driver *
'***********************************
org 0
'
'
' Entry
'
entry mov t1,par 'get structure address
add t1,#2 << 2 'skip past heads and tails
rdlong t2,t1 'get tx_pin
mov txmask,#1
shl txmask,t2
or outa,txmask 'idle = 1
or dira,txmask 'Pin30 = output
add t1,#4 'get bit_ticks
rdlong bittime,t1
add t1,#4 'get buffer_ptr
rdlong txbuff,t1
transmit mov t1,par 'check for head <> tail
rdlong t2,t1
add t1,#1 << 2
rdlong t3,t1
cmp t2,t3 wz
if_z jmp #transmit
sendloop add t3,txbuff 'get byte and inc tail
rdbyte txdata,t3
sub t3,txbuff
add t3,#1
and t3,#$1FF
wrlong t3,t1
mov txcnt,#10
or txdata,#$100 'add stoppbit
shl txdata,#1 'add startbit
mov dtime,cnt
add dtime,bittime
sendbit shr txdata,#1 wc 'test LSB
mov t2,outa
if_nc andn t2,txmask 'bit=0 or
if_c or t2,txmask 'bit=1
mov outa,t2
waitcnt dtime,bittime 'wait 1 bit
djnz txcnt,#sendbit '10 times
waitcnt dtime,bittime '2 stopbits
jmp #transmit 'done,wait for next
This is most odd. I guess these two bytes (8 and 9) would never be noticed if there was a bug somewhere. However, xmodem needs every single byte to go through exactly as it is.
Tomorrow I might try at a lower baud rate and see if the error can be replicated.
Post Edited (Dr_Acula (James Moxham)) : 8/6/2009 1:54:11 PM GMT
Just a quick observation from your post printout. It looks as if your terminal understood 8 to be backspace and 9 to be tab ( 8 spaces - 32=0x20 space)
Haven't looked at code!
James, wondering if there is an easier way to prove whats working....
Since you have a short connection, what about getting it working without Xmodem? Superimpose that later.
This way you can use the SO (serial out) to echo whatever you want for debugging. i.e. it will be a one-way transfer initially, no protocol, so just put delays between characters and keep the baudrate high. You just want to confirm that MBASIC is getting the character correctly and then you can confirm that it writes to the SD correctly. The fdx.hex(c) then fdx.tx(32) is a good way to check the character received. Once that is working·you can add the xmodem protocol.
Alternately, you could lift U23 A18 (pin 1) of the sram and tie it via a 10K to GND (or 3v). Then you could use this as a second serial output using FullDuplexSerial and start(-1, 26, 0, 115200) [noparse][[/noparse]-1 means no input pin]. You can actually do the same for A17 and you would have a second serial port. Of course, you now only have 128KB sram, but for now that does not matter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Found the 08 and 09 bug - thanks ++ TrapperBob. It is in Basic where a tab is changed to spaces if you use print. Use a raw output in basic rather than a print:
10 FOR A=0 TO 255
20 OUT &H68,A
30 NEXT
Also xmodem checks bit0 of port &H6D to ask whether a byte has come in. But it also checks bit5 to ask if a byte can be sent out. I am assuming here that the output object is always able to output a byte? If so, this is the modified spin code:
PRI in_test_n8vem
' for xmodem tests if any input from the serial port
' input present = bit 0. Output ready to go = bit 5 (always high). bit1=0 (carrier detect)
if kb.gotkey == 0
io_data :=%00100000
else
io_data :=%00100001
So now outputs are working for all bytes. Next thing to get working is inputs...
Ok, inputs are more complicated. xmodem needs to ask the input buffer "do you have a byte?". yes or no. If yes, give me the byte.
this is in the pri on_input
n8vem_uart_test: ' test port $6D
in_test_n8vem ' is a byte ready returns 0 for no byte, 1 for a byte
n8vem_uart_in: ' ask for input from port $68
in_uart_n8vem ' get the byte
so it polls port 6D until something is there, then gets it.
PRI in_test_n8vem
' for xmodem tests if any input from the serial port
' input present = bit 0. Output ready to go = bit 5 (always high). bit1=0 (carrier detect)
if kb.gotkey == 0
io_data :=%00100000
else
io_data :=%00100001
PRI in_uart_n8vem
io_data :=kb.key
But getting the key seems to return 0. Further down is some code
PRI in_constat
'Handle reads from the console status port
if kb.gotkey == 0 'Is there a key press ?
io_data := %00000010 'No: Return no char ready for input and output rdy.
else
key := kb.key 'Yes: Get the key
if key <> 0 'NULL character ?
' TV.out("<")
' TV.hex(key,4)
' TV.out(">")
case key 'No: Translate some keys for CP/M
$00C8: key := $08 'backspace
$0263: key := $03 'control-c
$0265: key := $05 'control-e
$0268: key := $08 'control-h
$0270: key := $10 'control-p
$0272: key := $12 'control-r
$0273: key := $13 'control-s
$0275: key := $15 'control-u
$0278: key := $18 'control-x
$027A: key := $1A 'control-z
$00C9: key := $7F 'rubout
$00C2: key := $5E 'up arrow
#ifdef convertkeys
$D0 : key := $1A 'F1 -> Cltr-Z
$D1 : key := $13 'F2 -> Ctrl-S
$D2 : key := $03 'F3 -> Ctrl-C
#endif
'if key => "a" and key =< "z" 'Use this for 4kBASIC which does not like lower case.
' key := key - $20
io_data := %00000011 'Return char ready for input and output rdy.
else
io_data := %00000010 'Yes: Return no char ready for input and output rdy.
I am wondering, when you get a key and the byte value is in key, does io_data then get changed to %00000011 to say there is a key there?
Also, if a character arrives in the keyboard input object, and I poll it 20x to ask if they key is there, can I then ask for the key on the 21st time and get it? It isn't ever deleted, right?
Also, does reading in the key with in_data:=kb.key destroy the byte afterwards? Or could you read it 10x and get the same number?
I'm still trying to work out the maths of a protocol that actually works. Say I poll something to ask if a byte has arrived. Then I get the byte. I'm thinking that I then need to send something out to say I now have the byte, and to clear the buffer ready for the next one? Otherwise, the "byte is available" flag will never get reset?
Unless it is reset when the byte is read?
The problem is that xmodem needs to take over control of all I/O while it is running. It stops CP/M polling the input and does all its polling internally. Otherwise bytes might get missed as they come in. I'm not sure if anything else ends up polling the inputs in the simulation. CP/M won't be if xmodem is running. But is anything else?
Another thought - is there a buffer on the input? And if so, how many bytes does it hold? I'm thinking of how the 16550 uart works, where it buffers bytes, and if it has bytes and you ask for one, it decrements a counter and gives you the byte, and when there are no bytes left the flag goes low.
Post Edited (Dr_Acula (James Moxham)) : 8/7/2009 3:53:39 AM GMT
James: Once you read a key (k:=kb.key) the char is removed from the buffer. If you do not want this then you will have to modify PC_Keyboard.
You will have to change the byte available flag - remember, there is no real byte available flag - we are doing all this in software.
PC_Keyboard most likely has a 16 byte buffer. This is normal for tx and rx in FDX and basically PC_Text and PC_Keyboard is a seperation of FDX. I think you should look at the spin section of PC_Keyboard and PC_Text to get a feel of what is happening. Basically it is a 16 byte FIFO which is cyclic. So there is an input pointer and an output pointer. When they are equal there is no characters in there. As the input routine adds a character it adds 1 to the input pointer. When a character is taken out, it increments the output pointer. The pointers wrap. Hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re "So there is an input pointer and an output pointer. When they are equal there is no characters in there."
Ah, that makes a lot of sense. And 16 bytes is the same as the real 16C450/16C550 uart. So should be plenty.
At work till late tonight, but I have some more ideas to test out.
Addit: this input code has me completely stumped. I just don't seem to be able to capture keypresses.
10 FOR A=1 TO 1000
20 B=INP(&H6D)
25 PRINT B;
30 IF B=33 THEN C=INP(&H68):PRINT C
40 NEXT A
Ok
PRI in_test_n8vem
' for xmodem tests if any input from the serial port
' input present = bit 0. Output ready to go = bit 5 (always high). bit1=0 (carrier detect)
if kb.gotkey == 0
io_data :=%00100000
else
io_data :=%00100001
PRI in_uart_n8vem
key :=kb.key ' get the byte
io_data := key 'Return char ready for input and output rdy.
Sending bytes from the PC to the board, only about one in 10 seem to get captured. And when they are captured, reading the byte invariably returns zero.
Maybe something else is reading the keyboard object too?
Just for fun, I edited this
PRI on_input
'Handle Z80 IO port reads
case io_port
srport: 'Altair front panel switches register
in_srport
simhport: 'SIMH control port
in_simhport
constat: 'Console status port.
in_constat
TV.out(66)
condata: 'Console data port
in_condata
TV.out(65)
so it prints A when reading a byte and B when reading the status port. Lost of Bs printed on teh screen all the time, but it is possible to run mbasic and test the program above. And it is checking the constat: about 4-5x per line of basic code.
I thought mbasic didn't check for input between each line but maybe it does. Maybe it is looking for a ^C for instance. Come to think of it, it probably does.
So - do I write some pure assembly to see if constat is checked each line of simulated code? Or ask the experts? Or do this in sbasic (where you can turn on or off keyboard input with $LINES).
I'm thinking that if constat is read all the time, then the PRI in_constat will be reading the kb object and then when xmodem goes to read it, the byte has already been read (which is why it keeps returning zero).
More testing - yes mbasic must be checking the console because
10 FOR A=1 TO 30000:NEXT
will abort with a ^C
So need to do this in assembler I think. It is late now, but perhaps tomorrow I will use wordstar to write it and M80 and L80 to compile and single step it through with DDTZ.COM
Post Edited (Dr_Acula (James Moxham)) : 8/7/2009 2:14:36 PM GMT
Getting wordstar working. As a bare minimum, wordstar needs just three files; WS.COM, WS.OVR and WSMSGS.OVR. Copied onto one of the disk images. Ran it through the vb6 program to change from 137 to 128 bytes. Copied onto the sd card. (I threw in a few more useful programs like M80, L80, ZASM.SUB, SUPERSUB.COM, DDTZ.COM). Got a little USB to SD card reader using USB2 now and about 100x faster than before.
Wordstar needs a VT100 terminal, so moved over to Teraterm/Hyperterminal.
Steps to recompile a .spin:
shut down any terminal programs
edit and save program in notepad
double click z.bat
double click zicog_demo009_rr092.binary which opens the propeller tool in a download window
click 'Load eeprom'
shut down propeller tool
reopen terminal program
This means some delays are not needed so commented out this line
' waitcnt(clkfreq*3 + cnt) 'delay (so you can get PropTerminal active) <=== 3 secs
and changed this line in the pc_text object from 2 secs to 0
STARTDELAY = 0 'seconds (0=Off)
In wordstar there is a bit of code that scans the keyboard where you enter the name of the file to open. This is very similar code to the code xmodem uses, and it comes up in some other places too. And I think there was mention earlier in another context of this problem as this bit of code is skipping every second character. I think the difference is whether a program requests a line of text via the relevant BDOS call, or whether it codes the input itself. If the latter, which wordstar and xmodem do, then characters are getting missed.
So I added a couple of tv.out commands - one after this bit of code (print out an A)
PRI in_constat
'Handle reads from the console status port
if kb.gotkey == 0 'Is there a key press ?
io_data := %00000010 'No: Return no char ready for input and output rdy.
else
key := kb.key 'Yes: Get the key
tv.out(65) ' added
and one after this bit of code (print out a
PRI in_condata
'Handle reads from the console data port
io_data := key 'Return the keyboard character
tv.out(66) ' added
Testing this, every time a character is typed at the CP/M console, it prints out AB every time a key is pressed. Which is correct.
But, when it is in wordstar scanning for keyboard input, if you type very slowly it prints AB. However, if you type fast, it only types A. So - for fast input somehow it is correctly scanning the console status, but not telling the in_condata to actually read that charater.
I'm trying to work out the logic of how the status and keyboard input work. Is there a condition where it can miss something? What about the condition where key is zero - there are test conditions for that, and yet zero is a valid byte input too? (not from a keyboard, but certainly from an xmodem transfer).
Plus there is a lot of legacy code in the in_constat presumably from a real keyboard. And in the pc_keyboard object. To keep things simple, ? only allow byte values 0 to 255 (and make 0 a valid code rather than an error??)
My brain hurts after thinking about this. So I thought I would play PACMAN instead. Attached is a screenshot of it working on the Triblade/Zicog (Needs the N8VEM terminal as there are some Wyse cursor movement commands in there as well as VT100). Pacman also needs each key pressed twice (so same problem as above). But it works. Very fast though. Might have to slow down the clock a bit.
Also a screenshot of it running on Absolute Telnet with a WYSE60 emulation.
Post Edited (Dr_Acula (James Moxham)) : 8/8/2009 2:44:47 AM GMT
I modified this code in the pc_keyboard object:
PUB key : keycode
'' Get key (never waits)
'' returns key (0 if buffer empty)
' (lowest Level)
skey := rxcheck
if skey < 0
keycode := 65 ' should never happen as should have checked if empty first. returns A for debugging
else
keycode :=skey
' case skey
' $01: keycode := 0 'shift
' kstat |= $100
' $02: keycode := 0 'ctrl
' kstat |= $200
' 3: kstat &= !$100 'shift off
' 4: kstat &= !$200 'ctrl off
' $DB: keycode := $D9 + kstat 'F12->F10 fix problems with F10
' other: keycode := skey + kstat
So now it does not modify the characters at all. This has made a difference in wordstar as now all the control characters work. ^KX to quit for instance. The aim really is not to change any bytes that go through.
Still missing characters when typing too fast in wordstar. And the code above returns an A if there is an error, but that is never displaying. So I don't think it is trying to get a character when there isn't one. Most tricky...
Great. Thinking overnight, I was just about to suggest that once you get everyting running in spin I can write a new PC_Keyboard that handles the flags like the 16550 in PASM (which is like simulating the hardware).
Seems you have resolved most problems. As for the dropping keys, I presume it is only missing random characters and not a buffer full (i.e. 16 bytes)??? This would be wrap-around. It is relatively easy to increase the buffer size.
No, thinking further, the 16550 can only have a character read once and it will be removed from the receive buffer. I guess I really need to understand what is required before I can offer any constructive suggestions. No doubt, the solution is easy... it is just understanding the problem that is difficult :-(
I will be on Skype shortly if you want to discuss.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Emulating a UART sounds a great idea. I think it is getting close anyway. Can you get wordstar working? (as this shows up the fault in the most obvious way). It is dropping every second character - type abcdef quickly and you get ace. Type slowly and it works. Baud rate doesn't matter (been testing at 38400 and 1200). The serial port sniffer program shows the bytes are going out so somehow they are not being captured. I can't see where in the code so it probably needs little flags through the code to find an error like this.
This one has me beaten for the moment, so any help from the 'brains trust' would be most appreciated!
Unfortunately, having to type really slowly makes the whole triblade/zicog system unusable, so this is kind of a critical problem.
Ok, the main program calls the keyboard object (which is actually so stripped down that it is really just a serial input 'uart' object now). There could be two bits of code calling it and conflicting, but I've gone through in notepad and can only find one instance where it asks 'do you have a byte', and one instance where it gets that byte. So I don't think it is that.
Putting flags in the main program certainly shows something is being missed. The flag is very simple - TV.out(n) where n is a number eg 65 for A, 66 for B and then you can trace things.
But I think it needs a trace inside the object that is reading the serial port.
Problem is, adding TV.out(n) inside the keyboard object causes an error. Which makes sense in a way, because the main routine is the one that controls all the objects.
You can't single step this because serial objects need to work in real time.
So - is there a way to flag code in an object has got to certain points in the code? And flag in such a way as to not upset the code itself (a sort of quantum Heisenberg principle problem where the measurement alters the outcome. The critical stuff is in pasm).
The best I can think of is to set up a long array and store data to that array as it runs. Sort of like a digital storage scope on the serial port and really catch what is going on (eg stop bits, gap between bytes too short etc, bytes captured but not passed, bytes somehow flagged as captured but not quite captured yet). But this is quite an undertaking.
Addit: it was a long shot but dropped the baud rate to 110. But still drops every second character in wordstar if type too fast.
Any help and advice would be most appreciated.
Post Edited (Dr_Acula (James Moxham)) : 8/11/2009 12:37:10 PM GMT
James: Sorry, I didn't get a chance to look before I had to fly to Qld. I will be driving back tomorrow, so will not get a chance to look at it till at least Thursday evening. I suspect that the calling routine to find if there is a character available may actually be deleting the character, so when the routine then reads the character it is getting the next one.
You could try removing the PC_Keyboard and PC_Text objects and add the FullDuplexSerialPlus object (as TV) and rename all kb.gotkey and kb.key to TV.gotkey and TV.key. This will then use the serial routine which we know works.
Thanks for the link to Kye's code - that was the key to solving this!
Attached is a zip. Cluso will know what to do with this!
Ok, the bad news is that I've been coding with a slightly older version. So Cluso and I need to get together and work out what changes we both have made to code recently (and before I forget!).
All references to kb and tv and debug are replaced with UART.
I'm using 38400 baud
Ascii 13s changed to 13 then 10. So works with many types of terminal programs
A minor bug coming up occasionally in
PRI out_constat
'Handle writes to the console command port
' perhaps need to add the byte value. ? where these come from
UART.transmitCharacters(string("Unknown console status write",13,10))
Not sure what is actually going out or why.
Need to speed up some timing loops in xmodem. Fast for sending to the PC. Not so fast for receiving.
Heaps of code that is not used has been commented out
Boots up automatically to the sd card - no questions on startup.
Removed several startup delays.
I'm using Teraterm and Hyperterminal as they have inbuilt xmodem file transfer.
Building files - run z.bat, shut down any terminal programs, double click the .binary, program to the eeprom, shut down the prop tool, reopen the terminal. Opening the terminal reboots the propeller.
Included in the zip is the batch file and tasm for recompiling xmodem. I will be looking at the delays but might not have a chance to do this for a couple of days. I think it involves tweaking msec so on startup it sends NAK characters more frequently to startup the transfer. It sends 10 before giving up, so too long a delay and you wait forever, and too short and it cycles all 10 and then gives up before you can type the filename in the terminal program.
I'd be interested to see how CP/M 3 goes with this!
James, fantastic news, thanks for finding this
Likewise, I will not be free till the weekend. Not leaving for Sydney/Gosford till the morning.
I will replace the calls so that we can use a #define to be able to keep seperate keyboard and display. The keyboard is the best/simplest place to do it as there are only a couple of calls. My RamBlade will have an additional breakoff section containing a keyboard and TV socket for single chip emulation, so I will need to be able to seperate the keyboard and display code when required. Of course, when communicating to another cog, then fdx is the way to go (single object).
BTW, if you want to ty CPM3, just change the #define statements and it should work. Remember, I had to type the keys twice, so this may have resolved that problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
CPM3 still a little while away. Working on xmodem at the moment.
I added this little routine at the bottom of the main object for debugging purposes as Kye's code doesn't have hex:
PUB PrintHex(value)
' print a byte in hexadecimal
value <<= (8 - 2) << 2 ' digits always 2
repeat 2
UART.transmitCharacter(lookupz((value <-= 4) & $F : "0".."9", "A".."F"))
Still trapping some calls to ports that don't exist. Better to see what they are than have mysterious hangs.
Ok - xmodem working but with a fix. Able to capture the bytes as they come into the uart ports.
But - it does not work if you dump out the bytes continuously ie as per terminal programs. So I've got my own terminal program with xmodem coded in vb.net, so I can add in variable delays. The answer is to add tiny delays between each byte. They are well under 1ms per byte. With those tiny delays able to transfer MBASIC.COM perfectly over about 30 seconds and then run it. It is cool watching the delays here and there as it writes to the sd card. xmodem can handle delays like that.
But why is it so? Could it be that 10 bit vs 11 bit thing mentioned ealier, where continuous bytes start as a low transition right after the end of the previous stop bit? Maybe Kye can answer that one as I must say I don't understand the PASM very well.
Or, and I hope this isn't the case, there is a slight delay at the end of each byte to store it. But I don't think that is the case, as this problem is exactly the same from 38400 down to 300 baud. If you send bytes continuously they don't work, but tiny delays between each byte and they do.
Anyway, 'tis cool xmodem is partially working.
HA HA. Done it. Got xmodem working on a standard terminal program. See attached screenshot of halfway through an mbasic transfer. Also a zip of the program with shorter delays (still might need to go shorter again as takes about 8 secs to startup).
The secret? Kye isn't going to like this, coz it is to add two stop bits. Hmm. That adds a little bit of extra delay. Which explains the vb.net experiment above. So - is it possible to tweak the serial object to handle just one stop bit with 10 bits per byte and continuous receive? If so, that would be awesome!
Old school serial connection to the back of the PC. Into a max232 and then 1k resistors to the propeller. Transistor reset circuit. Essentially the circuit from the PockeTerm.
See edited post above yours. I hope there are no problems adding the two stop bits to your USB to serial chip...
Or maybe we do have to ask Kye nicely to look at that code?
James, the problem is dropping characters being received from external devices, correct? If so, then this means that the serial receive code on the prop is the problem. So the transmitting code on the other device (PC) must be set with 2 stop bits, not the prop end. Does this make sense and confirm your testing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The serial driver can receive a continous stream of bytes. It only samples the first nine bits of a packet and then waits for a start bit again. Thus it ignores the stop bits.
I've had perfect results with the prop plug. It may be your setup that makes the data corrupted.
The serial driver expects fast rise and low times. You will need to tweak your setup or the code so that it waits a bit longer before sampling.
Yes, Cluso, it is data going from an external device to the propeller.
Baud rate does not matter. In vb.net you can send out a continuous stream of data and that fails. But if you send out the bytes individually it works (miniscule delays between each byte).
In a terminal program, it doesn't work with one stop bit but does with two.
Re Kye's post, when you say it samples the first 9 bits, what does it then do? Is it triggered by a high to low transition and then sampling at the half way point for each bit? Or is it using the tranistions to work out the bits?
I'm thinking of the waveforms if you sample 9 rather than 10 bits. What does it do after the 9th bit? Does it then wait one more bit period and assume that should be high as it should then be in the middle of a stop bit and then wait for the high to low transition to start the next byte? Or does it wait longer than one bit period?
I'd answer that question myself looking at the code but I'm still trying to learn PASM? Thnkx for being patient with these questions!
Dr_Acula said...
I'm thinking of the waveforms if you sample 9 rather than 10 bits. What does it do after the 9th bit? Does it then wait one more bit period and assume that should be high as it should then be in the middle of a stop bit and then wait for the high to low transition to start the next byte? Or does it wait longer than one bit period?
It does that.
Wait, is the driver having problems? You comments in the other post are conflicting. Is the driver having problems or not?
Yes, sorry, two threads and conflicting comments. My mistake.
Data going out of the propeller works perfectly. Receiving data works perfectly with your code IF you put in two stop bits instead of 1, OR IF you put a slight delay between the bytes coming in.
But it won't work on a continuous data stream of bytes, with no pauses and only 1 stop bit.
I guess I'm being a bit of a perfectionist here. But on the other hand, a continuous stream of data with 1 stop bit is quite a common format for RS232.
I think it is something to do with the way you resynchronise at the beginning of the byte (or not, as the case may be). See the other post for the technical question and the code.
Comments
Here is v092 (minor update so not posted to the start of the thread) There is now only one place for the baudrate to be set and I am using a modified PC_Text and PC_Keyboard. The start methods are now like the FullDuplexSerial, so I can pass the baudrate. I no longer use FullDuplexSerial.
Heater - do you want me to change your start parameters too and use the modified PC_Text & PC_Keyboard·routines? Ultimately I guess I should do a modified FullDuplexSerial so we only have to use 1 cog instead of 2. BTW do you have the hard disk working? I see code for 4 x hard disks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The only minor change I've got now is adding that linefeed. I'm working through getting the propterminal program working. It is opening in a tiny window and I think that has something to do with the fonts. I'll try to get the font installed.
Down the track, ? a zip package that includes propterminal as well. And maybe the instructions for the font once I find that again (it was in a thread somewhere).
Once I get that working, I'll get to work on the code for xmodem so we can transfer files to the sd card. I saw your post on the n8vem forum - I don't think you need to understand the disk format. This is the nice thing about cp/m - there are lots of calls already written to access the disk and they are already there in the code. for instance, in xmodem is a routine to open a file (the BDOS bit)
OPENFIL:XOR A ; SET EXT & REC # TO 0 FOR PROPER OPEN
LD (FCBEXT),A
LD (FCBSNO),A
LD DE,FCB ; POINT TO FILE
LD C,OPEN ; GET FUNCTION
CALL BDOS ; OPEN IT
INC A ; OPEN OK?
JP NZ,OPENOK ; ..YES
CALL ERXIT ; ..NO, ABORT
.DB "++OPEN ERROR++",CR,LF,'$'
I know how to get a byte from the serial input and I know how to send a byte. Both are trapped in the I/O. So the only bit of spin I need to write is the bit to ask the serial input object if it has a byte or not. Back to coding...
For asking the serial object if a byte is ready use kb.getkey or kb.gotkey (see PC_Keyboard.spin). No, I am not interested in the CPM disk structure.
I have modified PC_Text to add a LF after CR (optional #define addLF in ZiCog_demo009_rr093). I have not tested it, so could you please do that, thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 8/6/2009 10:32:07 AM GMT
Also, found the solution to the tiny propterminal display. Go into the propterminal.ini and change cols to 80 and rows to 25.'
When you are ready download Brad's bst compiler. It has an inbuilt terminal program and works on mac and unix also !
http://www.fnarfbargle.com/bst/ version 0184
Here is the thread...
http://forums.parallax.com/forums/default.aspx?f=25&m=298620&p=1
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Mods to spin are not too hard:
and further down
PRI on_input 'Handle Z80 IO port reads case io_port srport: 'Altair front panel switches register in_srport simhport: 'SIMH control port in_simhport constat: 'Console status port. in_constat condata: 'Console data port in_condata statin: 'Altair disk status port in_statin secpos: 'Altair disk sector position port in_secpos dskread: 'Altair disk read port in_dskread n8vem_uart_test: ' test port $6D in_test_n8vem ' is a byte ready returns 0 for no byte, 1 for a byte n8vem_uart_in: ' ask for input from port $68 in_condata ' get the byteand then
PRI in_test_n8vem ' for xmodem tests if any input from the serial port if kb.gotkey == 0 io_data :=%00000000 else io_data :=%00000001and then
PRI on_output 'Handle Z80 IO port writes case io_port ledport: 'An 8 bit parallel output with LEDs attached out_ledport simhport: 'SIMH control port out_simhport condata: 'Console data port out_condata constat: 'Console status port out_constat punstat: out_punstat 'Punch control port selout: 'Altair disk controller select port out_selout dskcon: 'Altair disk function port out_dskcon dskwrit: 'Altair disk write port out_dskwrit n8vem_uart_out: out_n8vem_byteand
PRI out_n8vem_byte ' TV.str(string("Write to n8vem uart I/O Port $ ")) ' TV.hex(io_data,2) ' TV.out(13) TV.out(io_data) ' send out the data to the port (for xmodem)the problem is that for some reason xmodem is running about 20x slower than it should be. Maybe some of the instructions in the delay loop are actually a lot slower to emulate. So I need to go through the delays and change a few settings. At present it is a catch22 - I can't download a file in order to download a file. So every change to xmodem involves a recompile using TASM, then importing into a disk image on the SIMH, then exporting it, then running it through the vb6 program to convert from 137 to 128 bytes, then putting the sd card in the sd card reader and copying the new disk b image, then doing a pip of the xmodem program to drive A, then testing it. Am getting there, but slowly.
Also, the input checking routine to see if a byte is present is very slow too. Like half a second between checks. A quick mbasic program found that. So some things might need changing a bit.
Hmm - addit, here is an odd bug:
And now watch that on the sniffer program. It prints all the numbers perfectly from 0 to 7 and from 10 to 255. But numbers 8 and 9 come out as eight ascii 32s. And they come out quickly too, whereas the other numbers come out with a delay of a second between them.
I cannot see anything in the text out code that would do this. This is the conout data:
PRI out_condata 'Handle writes to the console data output port 'data := data & $7F 'Use this for 4KBASIC which spits out Smile ' if io_data <> 10 TV.out(io_data)so 10 is commented out. Every byte should go through to here:
PUB out(c) | i, k '' Output a character '' '' $00 = clear screen '' $01 = home '' $08 = backspace '' $09 = tab (8 spaces per) '' $0A = set X position (X follows) '' $0B = set Y position (Y follows) '' $0C = set color (color follows) '' $0D = return '' others = printable characters print(c) {{ PUB setcolors(colorptr) | i, fore, back '' Override default color palette in real driver '' not used here }} PRI print(c) '' Send byte (may wait for room in buffer) repeat until (tx_tail <> (tx_head + 1) & $1FF) tx_buffer[noparse][[/noparse]tx_head] := c tx_head := (tx_head + 1) & $1FF DAT '*********************************** '* Assembly language serial driver * '*********************************** org 0 ' ' ' Entry ' entry mov t1,par 'get structure address add t1,#2 << 2 'skip past heads and tails rdlong t2,t1 'get tx_pin mov txmask,#1 shl txmask,t2 or outa,txmask 'idle = 1 or dira,txmask 'Pin30 = output add t1,#4 'get bit_ticks rdlong bittime,t1 add t1,#4 'get buffer_ptr rdlong txbuff,t1 transmit mov t1,par 'check for head <> tail rdlong t2,t1 add t1,#1 << 2 rdlong t3,t1 cmp t2,t3 wz if_z jmp #transmit sendloop add t3,txbuff 'get byte and inc tail rdbyte txdata,t3 sub t3,txbuff add t3,#1 and t3,#$1FF wrlong t3,t1 mov txcnt,#10 or txdata,#$100 'add stoppbit shl txdata,#1 'add startbit mov dtime,cnt add dtime,bittime sendbit shr txdata,#1 wc 'test LSB mov t2,outa if_nc andn t2,txmask 'bit=0 or if_c or t2,txmask 'bit=1 mov outa,t2 waitcnt dtime,bittime 'wait 1 bit djnz txcnt,#sendbit '10 times waitcnt dtime,bittime '2 stopbits jmp #transmit 'done,wait for next0 1 2 3 4 5 6 7 32 32 32 32 32 32 32 32 10 11 12 13 14 ... ..... 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 ................ 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 . !"#$%&'()*+,-. 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 /0123456789:;<=> 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 ?@ABCDEFGHIJKLMN 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 OPQRSTUVWXYZ[noparse][[/noparse]\]^ 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 _`abcdefghijklmn 111 13 10 112 113 114 115 116 117 118 119 120 121 122 123 124 o..pqrstuvwxyz{| 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 }~ 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 ¡¢£¤¥¦§¨©ª« 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 *®¯°±²³´µ·¸¹º»¼ 189 190 191 13 10 192 193 194 195 196 197 198 199 200 201 202 ½¾¿..ÀÁÂÃÄÅÆÇÈÉÊ 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 ËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚ 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 ÛÜÝÞßàáâãäåæçèéê 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 ëìíîïðñòóôõö÷øùú 251 252 253 254 255This is most odd. I guess these two bytes (8 and 9) would never be noticed if there was a bug somewhere. However, xmodem needs every single byte to go through exactly as it is.
Tomorrow I might try at a lower baud rate and see if the error can be replicated.
Post Edited (Dr_Acula (James Moxham)) : 8/6/2009 1:54:11 PM GMT
Just a quick observation from your post printout. It looks as if your terminal understood 8 to be backspace and 9 to be tab ( 8 spaces - 32=0x20 space)
Haven't looked at code!
TrapperBob
Since you have a short connection, what about getting it working without Xmodem? Superimpose that later.
This way you can use the SO (serial out) to echo whatever you want for debugging. i.e. it will be a one-way transfer initially, no protocol, so just put delays between characters and keep the baudrate high. You just want to confirm that MBASIC is getting the character correctly and then you can confirm that it writes to the SD correctly. The fdx.hex(c) then fdx.tx(32) is a good way to check the character received. Once that is working·you can add the xmodem protocol.
Alternately, you could lift U23 A18 (pin 1) of the sram and tie it via a 10K to GND (or 3v). Then you could use this as a second serial output using FullDuplexSerial and start(-1, 26, 0, 115200) [noparse][[/noparse]-1 means no input pin]. You can actually do the same for A17 and you would have a second serial port. Of course, you now only have 128KB sram, but for now that does not matter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Found the 08 and 09 bug - thanks ++ TrapperBob. It is in Basic where a tab is changed to spaces if you use print. Use a raw output in basic rather than a print:
Also xmodem checks bit0 of port &H6D to ask whether a byte has come in. But it also checks bit5 to ask if a byte can be sent out. I am assuming here that the output object is always able to output a byte? If so, this is the modified spin code:
PRI in_test_n8vem ' for xmodem tests if any input from the serial port ' input present = bit 0. Output ready to go = bit 5 (always high). bit1=0 (carrier detect) if kb.gotkey == 0 io_data :=%00100000 else io_data :=%00100001So now outputs are working for all bytes. Next thing to get working is inputs...
Ok, inputs are more complicated. xmodem needs to ask the input buffer "do you have a byte?". yes or no. If yes, give me the byte.
this is in the pri on_input
n8vem_uart_test: ' test port $6D in_test_n8vem ' is a byte ready returns 0 for no byte, 1 for a byte n8vem_uart_in: ' ask for input from port $68 in_uart_n8vem ' get the byteso it polls port 6D until something is there, then gets it.
PRI in_test_n8vem ' for xmodem tests if any input from the serial port ' input present = bit 0. Output ready to go = bit 5 (always high). bit1=0 (carrier detect) if kb.gotkey == 0 io_data :=%00100000 else io_data :=%00100001 PRI in_uart_n8vem io_data :=kb.keyBut getting the key seems to return 0. Further down is some code
PRI in_constat 'Handle reads from the console status port if kb.gotkey == 0 'Is there a key press ? io_data := %00000010 'No: Return no char ready for input and output rdy. else key := kb.key 'Yes: Get the key if key <> 0 'NULL character ? ' TV.out("<") ' TV.hex(key,4) ' TV.out(">") case key 'No: Translate some keys for CP/M $00C8: key := $08 'backspace $0263: key := $03 'control-c $0265: key := $05 'control-e $0268: key := $08 'control-h $0270: key := $10 'control-p $0272: key := $12 'control-r $0273: key := $13 'control-s $0275: key := $15 'control-u $0278: key := $18 'control-x $027A: key := $1A 'control-z $00C9: key := $7F 'rubout $00C2: key := $5E 'up arrow #ifdef convertkeys $D0 : key := $1A 'F1 -> Cltr-Z $D1 : key := $13 'F2 -> Ctrl-S $D2 : key := $03 'F3 -> Ctrl-C #endif 'if key => "a" and key =< "z" 'Use this for 4kBASIC which does not like lower case. ' key := key - $20 io_data := %00000011 'Return char ready for input and output rdy. else io_data := %00000010 'Yes: Return no char ready for input and output rdy.I am wondering, when you get a key and the byte value is in key, does io_data then get changed to %00000011 to say there is a key there?
Also, if a character arrives in the keyboard input object, and I poll it 20x to ask if they key is there, can I then ask for the key on the 21st time and get it? It isn't ever deleted, right?
Also, does reading in the key with in_data:=kb.key destroy the byte afterwards? Or could you read it 10x and get the same number?
I'm still trying to work out the maths of a protocol that actually works. Say I poll something to ask if a byte has arrived. Then I get the byte. I'm thinking that I then need to send something out to say I now have the byte, and to clear the buffer ready for the next one? Otherwise, the "byte is available" flag will never get reset?
Unless it is reset when the byte is read?
The problem is that xmodem needs to take over control of all I/O while it is running. It stops CP/M polling the input and does all its polling internally. Otherwise bytes might get missed as they come in. I'm not sure if anything else ends up polling the inputs in the simulation. CP/M won't be if xmodem is running. But is anything else?
Another thought - is there a buffer on the input? And if so, how many bytes does it hold? I'm thinking of how the 16550 uart works, where it buffers bytes, and if it has bytes and you ask for one, it decrements a counter and gives you the byte, and when there are no bytes left the flag goes low.
Post Edited (Dr_Acula (James Moxham)) : 8/7/2009 3:53:39 AM GMT
You will have to change the byte available flag - remember, there is no real byte available flag - we are doing all this in software.
PC_Keyboard most likely has a 16 byte buffer. This is normal for tx and rx in FDX and basically PC_Text and PC_Keyboard is a seperation of FDX. I think you should look at the spin section of PC_Keyboard and PC_Text to get a feel of what is happening. Basically it is a 16 byte FIFO which is cyclic. So there is an input pointer and an output pointer. When they are equal there is no characters in there. As the input routine adds a character it adds 1 to the input pointer. When a character is taken out, it increments the output pointer. The pointers wrap. Hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Ah, that makes a lot of sense. And 16 bytes is the same as the real 16C450/16C550 uart. So should be plenty.
At work till late tonight, but I have some more ideas to test out.
Addit: this input code has me completely stumped. I just don't seem to be able to capture keypresses.
10 FOR A=1 TO 1000
20 B=INP(&H6D)
25 PRINT B;
30 IF B=33 THEN C=INP(&H68):PRINT C
40 NEXT A
Ok
PRI in_test_n8vem
' for xmodem tests if any input from the serial port
' input present = bit 0. Output ready to go = bit 5 (always high). bit1=0 (carrier detect)
if kb.gotkey == 0
io_data :=%00100000
else
io_data :=%00100001
PRI in_uart_n8vem
key :=kb.key ' get the byte
io_data := key 'Return char ready for input and output rdy.
Sending bytes from the PC to the board, only about one in 10 seem to get captured. And when they are captured, reading the byte invariably returns zero.
Maybe something else is reading the keyboard object too?
Just for fun, I edited this
PRI on_input
'Handle Z80 IO port reads
case io_port
srport: 'Altair front panel switches register
in_srport
simhport: 'SIMH control port
in_simhport
constat: 'Console status port.
in_constat
TV.out(66)
condata: 'Console data port
in_condata
TV.out(65)
so it prints A when reading a byte and B when reading the status port. Lost of Bs printed on teh screen all the time, but it is possible to run mbasic and test the program above. And it is checking the constat: about 4-5x per line of basic code.
I thought mbasic didn't check for input between each line but maybe it does. Maybe it is looking for a ^C for instance. Come to think of it, it probably does.
So - do I write some pure assembly to see if constat is checked each line of simulated code? Or ask the experts? Or do this in sbasic (where you can turn on or off keyboard input with $LINES).
I'm thinking that if constat is read all the time, then the PRI in_constat will be reading the kb object and then when xmodem goes to read it, the byte has already been read (which is why it keeps returning zero).
More testing - yes mbasic must be checking the console because
10 FOR A=1 TO 30000:NEXT
will abort with a ^C
So need to do this in assembler I think. It is late now, but perhaps tomorrow I will use wordstar to write it and M80 and L80 to compile and single step it through with DDTZ.COM
Post Edited (Dr_Acula (James Moxham)) : 8/7/2009 2:14:36 PM GMT
Getting wordstar working. As a bare minimum, wordstar needs just three files; WS.COM, WS.OVR and WSMSGS.OVR. Copied onto one of the disk images. Ran it through the vb6 program to change from 137 to 128 bytes. Copied onto the sd card. (I threw in a few more useful programs like M80, L80, ZASM.SUB, SUPERSUB.COM, DDTZ.COM). Got a little USB to SD card reader using USB2 now and about 100x faster than before.
Wordstar needs a VT100 terminal, so moved over to Teraterm/Hyperterminal.
Steps to recompile a .spin:
shut down any terminal programs
edit and save program in notepad
double click z.bat
double click zicog_demo009_rr092.binary which opens the propeller tool in a download window
click 'Load eeprom'
shut down propeller tool
reopen terminal program
This means some delays are not needed so commented out this line
' waitcnt(clkfreq*3 + cnt) 'delay (so you can get PropTerminal active) <=== 3 secs
and changed this line in the pc_text object from 2 secs to 0
STARTDELAY = 0 'seconds (0=Off)
In wordstar there is a bit of code that scans the keyboard where you enter the name of the file to open. This is very similar code to the code xmodem uses, and it comes up in some other places too. And I think there was mention earlier in another context of this problem as this bit of code is skipping every second character. I think the difference is whether a program requests a line of text via the relevant BDOS call, or whether it codes the input itself. If the latter, which wordstar and xmodem do, then characters are getting missed.
So I added a couple of tv.out commands - one after this bit of code (print out an A)
PRI in_constat
'Handle reads from the console status port
if kb.gotkey == 0 'Is there a key press ?
io_data := %00000010 'No: Return no char ready for input and output rdy.
else
key := kb.key 'Yes: Get the key
tv.out(65) ' added
and one after this bit of code (print out a
PRI in_condata
'Handle reads from the console data port
io_data := key 'Return the keyboard character
tv.out(66) ' added
Testing this, every time a character is typed at the CP/M console, it prints out AB every time a key is pressed. Which is correct.
But, when it is in wordstar scanning for keyboard input, if you type very slowly it prints AB. However, if you type fast, it only types A. So - for fast input somehow it is correctly scanning the console status, but not telling the in_condata to actually read that charater.
I'm trying to work out the logic of how the status and keyboard input work. Is there a condition where it can miss something? What about the condition where key is zero - there are test conditions for that, and yet zero is a valid byte input too? (not from a keyboard, but certainly from an xmodem transfer).
Plus there is a lot of legacy code in the in_constat presumably from a real keyboard. And in the pc_keyboard object. To keep things simple, ? only allow byte values 0 to 255 (and make 0 a valid code rather than an error??)
My brain hurts after thinking about this. So I thought I would play PACMAN instead. Attached is a screenshot of it working on the Triblade/Zicog (Needs the N8VEM terminal as there are some Wyse cursor movement commands in there as well as VT100). Pacman also needs each key pressed twice (so same problem as above). But it works. Very fast though. Might have to slow down the clock a bit.
Also a screenshot of it running on Absolute Telnet with a WYSE60 emulation.
Post Edited (Dr_Acula (James Moxham)) : 8/8/2009 2:44:47 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
PUB key : keycode
'' Get key (never waits)
'' returns key (0 if buffer empty)
' (lowest Level)
skey := rxcheck
if skey < 0
keycode := 65 ' should never happen as should have checked if empty first. returns A for debugging
else
keycode :=skey
' case skey
' $01: keycode := 0 'shift
' kstat |= $100
' $02: keycode := 0 'ctrl
' kstat |= $200
' 3: kstat &= !$100 'shift off
' 4: kstat &= !$200 'ctrl off
' $DB: keycode := $D9 + kstat 'F12->F10 fix problems with F10
' other: keycode := skey + kstat
So now it does not modify the characters at all. This has made a difference in wordstar as now all the control characters work. ^KX to quit for instance. The aim really is not to change any bytes that go through.
Still missing characters when typing too fast in wordstar. And the code above returns an A if there is an error, but that is never displaying. So I don't think it is trying to get a character when there isn't one. Most tricky...
Seems you have resolved most problems. As for the dropping keys, I presume it is only missing random characters and not a buffer full (i.e. 16 bytes)??? This would be wrap-around. It is relatively easy to increase the buffer size.
No, thinking further, the 16550 can only have a character read once and it will be removed from the receive buffer. I guess I really need to understand what is required before I can offer any constructive suggestions. No doubt, the solution is easy... it is just understanding the problem that is difficult :-(
I will be on Skype shortly if you want to discuss.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Emulating a UART sounds a great idea. I think it is getting close anyway. Can you get wordstar working? (as this shows up the fault in the most obvious way). It is dropping every second character - type abcdef quickly and you get ace. Type slowly and it works. Baud rate doesn't matter (been testing at 38400 and 1200). The serial port sniffer program shows the bytes are going out so somehow they are not being captured. I can't see where in the code so it probably needs little flags through the code to find an error like this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Unfortunately, having to type really slowly makes the whole triblade/zicog system unusable, so this is kind of a critical problem.
Ok, the main program calls the keyboard object (which is actually so stripped down that it is really just a serial input 'uart' object now). There could be two bits of code calling it and conflicting, but I've gone through in notepad and can only find one instance where it asks 'do you have a byte', and one instance where it gets that byte. So I don't think it is that.
Putting flags in the main program certainly shows something is being missed. The flag is very simple - TV.out(n) where n is a number eg 65 for A, 66 for B and then you can trace things.
But I think it needs a trace inside the object that is reading the serial port.
Problem is, adding TV.out(n) inside the keyboard object causes an error. Which makes sense in a way, because the main routine is the one that controls all the objects.
You can't single step this because serial objects need to work in real time.
So - is there a way to flag code in an object has got to certain points in the code? And flag in such a way as to not upset the code itself (a sort of quantum Heisenberg principle problem where the measurement alters the outcome. The critical stuff is in pasm).
The best I can think of is to set up a long array and store data to that array as it runs. Sort of like a digital storage scope on the serial port and really catch what is going on (eg stop bits, gap between bytes too short etc, bytes captured but not passed, bytes somehow flagged as captured but not quite captured yet). But this is quite an undertaking.
Addit: it was a long shot but dropped the baud rate to 110. But still drops every second character in wordstar if type too fast.
Any help and advice would be most appreciated.
Post Edited (Dr_Acula (James Moxham)) : 8/11/2009 12:37:10 PM GMT
You could try removing the PC_Keyboard and PC_Text objects and add the FullDuplexSerialPlus object (as TV) and rename all kb.gotkey and kb.key to TV.gotkey and TV.key. This will then use the serial routine which we know works.
FWIW Kye was commenting on a potential problem with receiving characters into Windows with the FTDI driver
http://forums.parallax.com/forums/default.aspx?f=25&m=374912
Just wondering if there is a slight timing issue here somewhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Attached is a zip. Cluso will know what to do with this!
Ok, the bad news is that I've been coding with a slightly older version. So Cluso and I need to get together and work out what changes we both have made to code recently (and before I forget!).
All references to kb and tv and debug are replaced with UART.
I'm using 38400 baud
Ascii 13s changed to 13 then 10. So works with many types of terminal programs
A minor bug coming up occasionally in
PRI out_constat 'Handle writes to the console command port ' perhaps need to add the byte value. ? where these come from UART.transmitCharacters(string("Unknown console status write",13,10))Not sure what is actually going out or why.
Need to speed up some timing loops in xmodem. Fast for sending to the PC. Not so fast for receiving.
Heaps of code that is not used has been commented out
Boots up automatically to the sd card - no questions on startup.
Removed several startup delays.
I'm using Teraterm and Hyperterminal as they have inbuilt xmodem file transfer.
Building files - run z.bat, shut down any terminal programs, double click the .binary, program to the eeprom, shut down the prop tool, reopen the terminal. Opening the terminal reboots the propeller.
Included in the zip is the batch file and tasm for recompiling xmodem. I will be looking at the delays but might not have a chance to do this for a couple of days. I think it involves tweaking msec so on startup it sends NAK characters more frequently to startup the transfer. It sends 10 before giving up, so too long a delay and you wait forever, and too short and it cycles all 10 and then gives up before you can type the filename in the terminal program.
I'd be interested to see how CP/M 3 goes with this!
Likewise, I will not be free till the weekend. Not leaving for Sydney/Gosford till the morning.
I will replace the calls so that we can use a #define to be able to keep seperate keyboard and display. The keyboard is the best/simplest place to do it as there are only a couple of calls. My RamBlade will have an additional breakoff section containing a keyboard and TV socket for single chip emulation, so I will need to be able to seperate the keyboard and display code when required. Of course, when communicating to another cog, then fdx is the way to go (single object).
BTW, if you want to ty CPM3, just change the #define statements and it should work. Remember, I had to type the keys twice, so this may have resolved that problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I added this little routine at the bottom of the main object for debugging purposes as Kye's code doesn't have hex:
PUB PrintHex(value) ' print a byte in hexadecimal value <<= (8 - 2) << 2 ' digits always 2 repeat 2 UART.transmitCharacter(lookupz((value <-= 4) & $F : "0".."9", "A".."F"))Still trapping some calls to ports that don't exist. Better to see what they are than have mysterious hangs.
Ok - xmodem working but with a fix. Able to capture the bytes as they come into the uart ports.
But - it does not work if you dump out the bytes continuously ie as per terminal programs. So I've got my own terminal program with xmodem coded in vb.net, so I can add in variable delays. The answer is to add tiny delays between each byte. They are well under 1ms per byte. With those tiny delays able to transfer MBASIC.COM perfectly over about 30 seconds and then run it. It is cool watching the delays here and there as it writes to the sd card. xmodem can handle delays like that.
But why is it so? Could it be that 10 bit vs 11 bit thing mentioned ealier, where continuous bytes start as a low transition right after the end of the previous stop bit? Maybe Kye can answer that one as I must say I don't understand the PASM very well.
Or, and I hope this isn't the case, there is a slight delay at the end of each byte to store it. But I don't think that is the case, as this problem is exactly the same from 38400 down to 300 baud. If you send bytes continuously they don't work, but tiny delays between each byte and they do.
Anyway, 'tis cool xmodem is partially working.
HA HA. Done it. Got xmodem working on a standard terminal program. See attached screenshot of halfway through an mbasic transfer. Also a zip of the program with shorter delays (still might need to go shorter again as takes about 8 secs to startup).
The secret? Kye isn't going to like this, coz it is to add two stop bits. Hmm. That adds a little bit of extra delay. Which explains the vb.net experiment above. So - is it possible to tweak the serial object to handle just one stop bit with 10 bits per byte and continuous receive? If so, that would be awesome!
Post Edited (Dr_Acula) : 8/12/2009 2:04:02 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
See edited post above yours. I hope there are no problems adding the two stop bits to your USB to serial chip...
Or maybe we do have to ask Kye nicely to look at that code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The serial driver can receive a continous stream of bytes. It only samples the first nine bits of a packet and then waits for a start bit again. Thus it ignores the stop bits.
I've had perfect results with the prop plug. It may be your setup that makes the data corrupted.
The serial driver expects fast rise and low times. You will need to tweak your setup or the code so that it waits a bit longer before sampling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Baud rate does not matter. In vb.net you can send out a continuous stream of data and that fails. But if you send out the bytes individually it works (miniscule delays between each byte).
In a terminal program, it doesn't work with one stop bit but does with two.
Re Kye's post, when you say it samples the first 9 bits, what does it then do? Is it triggered by a high to low transition and then sampling at the half way point for each bit? Or is it using the tranistions to work out the bits?
I'm thinking of the waveforms if you sample 9 rather than 10 bits. What does it do after the 9th bit? Does it then wait one more bit period and assume that should be high as it should then be in the middle of a stop bit and then wait for the high to low transition to start the next byte? Or does it wait longer than one bit period?
I'd answer that question myself looking at the code but I'm still trying to learn PASM? Thnkx for being patient with these questions!
Wait, is the driver having problems? You comments in the other post are conflicting. Is the driver having problems or not?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Data going out of the propeller works perfectly. Receiving data works perfectly with your code IF you put in two stop bits instead of 1, OR IF you put a slight delay between the bytes coming in.
But it won't work on a continuous data stream of bytes, with no pauses and only 1 stop bit.
I guess I'm being a bit of a perfectionist here. But on the other hand, a continuous stream of data with 1 stop bit is quite a common format for RS232.
I think it is something to do with the way you resynchronise at the beginning of the byte (or not, as the case may be). See the other post for the technical question and the code.
11 bit frames aren't really that bad though. Serial is very picky depending on your setup.
... More testing is needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,