Shop OBEX P1 Docs P2 Docs Learn Events
TriBlade Prop PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) - Page 6 — Parallax Forums

TriBlade Prop PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC)

13468932

Comments

  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-06 07:00
    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. roll.gif

    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-06 09:02
    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...
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-06 10:18
    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:

    · 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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-06 10:31
    Ok, working on gotkey.

    Also, found the solution to the tiny propterminal display. Go into the propterminal.ini and change cols to 80 and rows to 25.'
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-06 10:44
    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.

    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-06 13:28
    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.

    Mods to spin are not too hard:
    
    ' UART constants for N8VEM
    n8vem_uart_test = $6D
    n8vem_uart_in = $68
    n8vem_uart_out = $68
    
    



    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 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
    
    



    0 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 255
    
    



    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
  • TrapperBobTrapperBob Posts: 139
    edited 2009-08-06 14:42
    Dr Acula

    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-07 02:02
    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:

    · 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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-07 02:20
    Back coding after a sleep. Lots of ideas:

    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-07 04:34
    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:

    · 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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-07 04:51
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-08 02:19
    More exciting experiments:

    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 B)

    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
    904 x 500 - 72K
    990 x 714 - 104K
    826 x 660 - 100K
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-08 05:54
    Great work James. I will have to think about this but busy with something else today.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-08 14:18
    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...
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-09 00:13
    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:

    · 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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-09 00:30
    At work today so not on skype, sorry.

    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-09 00:37
    That is exactly the same problem I was having with CPM3 - curious??? I will have a look.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-11 12:16
    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-11 14:12
    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.

    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-12 10:09
    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!
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-12 12:03
    James, fantastic news, thanks for finding this smile.gif
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-12 12:54
    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!

    Post Edited (Dr_Acula) : 8/12/2009 2:04:02 PM GMT
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-12 14:02
    James, what is your pc connection? Is it USB and FT232RL (on TriBlade) or external PropPlug or Serial and MAX3232 or something else?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-12 14:15
    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?
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-08-13 01:13
    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:

    · 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
  • KyeKye Posts: 2,200
    edited 2009-08-13 01:39
    Just reading this post now.

    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,
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-13 01:56
    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!
  • KyeKye Posts: 2,200
    edited 2009-08-13 02:42
    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?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-08-13 03:01
    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.
  • KyeKye Posts: 2,200
    edited 2009-08-13 03:34
    Hmm, I can't verifty that I have the same problem you are expierencing.

    11 bit frames aren't really that bad though. Serial is very picky depending on your setup.

    ... More testing is needed.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nyamekye,
Sign In or Register to comment.