Shop OBEX P1 Docs P2 Docs Learn Events
yaz80 - yet another z80 core — Parallax Forums

yaz80 - yet another z80 core

pullmollpullmoll Posts: 817
edited 2010-03-30 11:10 in Propeller 1
Last night I wrote another Z80 CPU emulation based on the experiences and code snippets from the ditched attempt to do a dynamically recompiling Z80. For obvious reasons I named it yaz80. The code isn't complete yet, but almost as complete as the last try was, and it is much simpler and also (or thus) faster than pm80.

The concept this time was: keep some registers in hub RAM, except PC, SP, A and flags, i.e. the most often used ones. All opcodes are executed as LMM instructions by a 4 times expanded classic LMM fetch + execute loop. Every repeatedly appearing alu operation and flag effects are subroutines in cog RAM. Also the core of LDIR and LDDR are in cog RAM to speed up things. The tables indexing the opcode functions are words, and thus as compact as possible.

The only thing left to do is fixing the opcodes, or their flag effects, that fail the EXZ80DOC exercise. Currently there are some well known candidates which I hope to nail down soon.

The code is available via my CVS repository at anoncvs@pmbits.ath.cx:/anoncvs with the module name yaz80.
you@host:~$</font> cvs -d: pserver:anoncvs@pmbits.ath.cx:/anoncvs login</font>
Just hit ENTER when asked for a password.
If this fails with an error message, try
you@host:~$</font> touch ~/.cvspass</font>
to create an empty file for CVS passwords.
Check out the source with:
you@host:~$</font> cvs -d: pserver:anoncvs@pmbits.ath.cx:/anoncvs co yaz80</font>
Enter the new directory with:
you@host:~$</font> cd yaz80</font>
And build, upload to /dev/ttyS0 (COM1) and run with:
you@host:~/yaz80$</font> make</font>
Updates to the source can later be fetched doing:
you@host:~/yaz80$</font> cvs up -dAP</font>

Note: There is no blank between ':' and 'pserver:', but the forum software mangles the text, if I leave no space between ':' and 'p'. You gotta love it!

The required software to translate it all is:
<ul>
[*] BradC's bst.linux or the corresponding Windows executable (change Makefile for your system)
[*] GNU compiler collection (gcc)
[*] GNU make
[*] BISON a replacement for yacc, a parser generator.
[*] FLEX a replacement for lex, a lexical analyzer for compiler-compilers.
[*] GtkTerm in your path is fired up after running the compiled code from RAM (change Makefile to your needs)
[/list]

YAZ80 now supports reading the image files on FAT12, FAT16 and FAT32!

History:
0.0.1 first public
0.0.2 moved all registers to the cog RAM
0.0.3 shrink size by moving repeated code to cog RAM
0.0.4 extend io.spin to access SD card
0.1.0 fixed add16, shrunk hub RAM use, add RamBlade support
0.1.1 fixed sbc16/adc16 - not much more left to do until perfect bonus 10'000 pts
0.1.2 fixed DAA - perfect!?
0.2.0 add code to find hard disk images inside the FAT filesystem
0.2.1 fixed <rot/res/set> (ix/iy+disp8), though the implementation should have been okay, but it breaks exerciser
0.2.2 add timed flush to the 128 byte sector writing (1 second idle), reducing the SD 512 byte sector rewrites
0.2.3 for TriBladeProp call idle/active around SD card functions in io.spin; Add optional code to check for Z80 interrupts
0.2.4 Separate FAT fs functions from io.spin to fatfs.spin, add date/time info for the files being inspected
0.2.5 Add optional cycle counting and speed measuring to yaz80. I get abt. 1,4MHz on the DracBlade with CP/M ;-P
0.2.6 Found a bug in SRL (IX/IY+disp8); it was calling alu_rlc - a copy+paste bug. Doesn't fix the opcode group, though
0.3.0 Fixed the shift/rotate bug after reading the Propeller manual. Note to self: do that more often.
0.3.1 Add support for interrupt modes 0, 1 and 2. Changed I/O to use a single long for inter cog communication
0.3.2 Support a bastard 8080 CPU, i.e. one without Z80 opcodes except DJNZ and JR <cond>
0.3.3 Got the PS/2 keyboard interface working on the DracBlade. RamBlade still doesn't work.
0.3.4 Working on a TV 80x24 display and VT100 terminal emulation. It's halfway done. Out of cogs again, so no Keyboard or no TV text...
0.3.6 Fixed the bug causing Wordstar to send broken escape sequences. It was ADD16, i.e. ADD HL,BC or ADD IY,SP.
0.3.7 Fixed a bug in ADC16/SBC16 that could leave H with a value > $FF, which is - of course - impossible for an 8bit register
0.3.8 Not released - tried to reduce cog memory, rearranged some TRS80 specific code, broke ADC16/SBC16 again.
0.3.9 ADC16/SBC16 fixed again. The exerciser is happy with everything, except INI/IND/INIR/INDR and OUTI/OUTD/OTIR/OTDR
0.3.10 Add CPU_8085 flag and opcodes, so you can now chose between CPU_Z80, CPU_8080 and CPU_8085

That's all for now. The attachment will have the latest version, updated from time to time.

He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.

Post Edited (pullmoll) : 4/1/2010 10:58:28 AM GMT
«13456

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2010-03-19 09:06
    Nice work Jurgen. I will be interested in the speed compared with ZiCog.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 09:26
    "Last night I wrote another Z80 CPU emulation..."

    How does he do it???

    I guess, like Cluso, I've got to ask about speed. There are many models, but the fastest one is the one that wins. Though smaller is good too, especially if it frees up the 10-20 longs needed to run banked memory. Which I think LMM already does easily.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • heaterheater Posts: 3,370
    edited 2010-03-19 09:47
    Well, once you have written one...

    That 4 COG version I tried was put together in a day or so just by copy and pasting from the version before. Likewise for the ZiCog we have now. Of course shaking out all the last remaining "features" might take longer....

    I'm fascinated to see the results. ZiCog has had a good run but there is always a new kid on the block [noparse]:)[/noparse]

    We don't need 10 longs to do banked memory which ever.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 10:12
    Dr_Acula said...
    "Last night I wrote another Z80 CPU emulation..."

    How does he do it???

    I guess, like Cluso, I've got to ask about speed. There are many models, but the fastest one is the one that wins. Though smaller is good too, especially if it frees up the 10-20 longs needed to run banked memory. Which I think LMM already does easily.

    BTW: I'd like to add the DracBlade memory access to yaz80, too, of course. Unfortunately the Prop isn't detected on the serial port (using bstc). Any idea what I may be doing wrong?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-03-19 10:25
    Which form of connect are you using? RS232 or USB ? I know that there were issues with the latest versions of Ubuntu, has it connected before ??

    I use BST on windows via Comm1 via a three transistor interface, often the first connect atempt fails but the second onwards are ok (I wonder if the baud rate is being learnt)

    Anyway, It is coming up towards lunchtime there, have you finished that total re-write yet?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 10:48
    Re "We don't need 10 longs to do banked memory which ever."

    Excellent.

    Re "Anyway, It is coming up towards lunchtime there, have you finished that total re-write yet?"

    Lucky Toby is not your boss, eh?

    Re BST - which board, which circuit, real RS232 or serial adaptor, and windows or ubuntu??

    Dracblade works fine with real rs232 and usb serial adaptor.

    It won't work if another program is using the serial port. I get trapped by that one sometimes.

    Not finding a propeller - maybe the propeller isn't working? What circuit are you using? Was it working before??


    They finally let me out of work. I'm happily coding an xmodem variant in basic on the propeller while listening to Rammstein. Life doesn't get much better than this!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 10:54
    Dr_Acula said...

    Re BST - which board, which circuit, real RS232 or serial adaptor, and windows or ubuntu??

    Your board. Female Sub-D connector to real RS232, Ubuntu 9.10. BST says no prop detected.
    Running CP/M off the SD it works with 19k2, so it can't be all that bad. Perhaps the reset circuit?
    Tried again with the 19k2 terminal: every key I send resets the prop. Wrong cabling? But how should my board then have been working!?
    Ok, toggling DTR manually from the terminal resets the prop, too. But why is it resetting when I send a character?
    Dr_Acula said...
    Not finding a propeller - maybe the propeller isn't working? What circuit are you using? Was it working before??

    I couldn't, it arrived this morning (local time). It's YOUR board. My PropRPB works fine with the RS232 cable I made, DracBlade doesn't seem to want to.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.

    Post Edited (pullmoll) : 3/19/2010 11:22:55 AM GMT
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 11:27
    Ah, ok.

    What is the pinout of the RS232 cable you have? Sounds like pin 3 and 4 crossed or joined if resetting when data going from PC to the board.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller

    Post Edited (Dr_Acula) : 3/19/2010 11:32:50 AM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 11:31
    Dr_Acula said...
    Ah, ok.

    What is the pinout of the RS232 cable you have?
    The cable is 1:1 and was/is working perfectly fine with the PropRPM board. We use just Rx/Tx and DTR anyway!?

    Ok, I managed to overwrite the EEPROM with the Python script Loader.py, and after that also bstc is able to find the prop. It looks like the bootstrap code had no chance to download anything after a reset. It always just said:
    Timeout Failed at read 1
    No Propeller detected on port /dev/ttyS0
    Now it seems to work, so I can test the external RAM access.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.

    Post Edited (pullmoll) : 3/19/2010 11:39:55 AM GMT
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 11:33
    What terminal program? Can you check 'flow control' and make sure it is "none". If it is set to 'hardware' it would reset...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 11:36
    Dr_Acula said...
    What terminal program? Can you check 'flow control' and make sure it is "none". If it is set to 'hardware' it would reset...
    I'm using GtkTerm. Flow control is set to "none". I overwrote the EEPROM now, can't test until I reload it with ZiCog etc.
    Anyway, I'll find out what the reason for this is/was later on. First I'll play around a bit with latches and RAM smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 11:37
    Alles gut!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 11:39
    Dr_Acula said...
    Alles gut!
    Jawohl! Off to studying specs how to address DracBlade's RAM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 11:52
    Schematic here


    www.smarthome.viviti.com/files/documents/Propeller_v5.pdf


    and this is the code

    ' **************************** Dr_Acula single propeller driver ****************
    ' three latches to access the ram chip - see main program for spin version
    ' uses variables address and data_8. skip banked memory and checking for out of bounds address
    ' will need two nop instructions in /rd and /wr to be sure 
    
    Outx                    long    %00000000_00000000_00000000_00000000  ' temp variable                                   ' for temp use, same as n in the spin code
    Direction138            long    %00000000_00000000_00001111_00000000 ' for reads so data lines are tristate till the read
    LowAddress              long    %00000000_00000000_00000101_00000000 ' low address latch = xxxx010x and gate high xxxxxxx1
    MiddleAddress           long    %00000000_00000000_00000111_00000000 ' middle address latch = xxxx011x and gate high xxxxxxx1
    WriteEnable             long    %00000000_00000000_00000011_00000000 ' write enable xxxx001x and xxxxxxx0
    
    
    read_memory_byte 
    '#ifdef banked_memory
    '                        cmp     address, common_ram wc     'Address in resident RAM area ?
    '              if_c      add     address, bank_offset       'No: Add offset to current memory bank in ext RAM
    '#endif
                            call #RamAddress                ' sets up the latches with the correct ram address
                            mov dira,Direction138           ' for reads so P0-P7 tristate till do read
                            mov outa,#$0                    ' set 000 low 138 read, low gate and P0-P7 are inputs
                            nop                             ' none does not work, 1 does work
                            mov data_8, ina                 ' read SRAM
                            and data_8, #$FF                ' extract 8 bits
                            or  outa,#$100                  ' set the gate high again
                            mov dira,#0                     ' tristate all pins
    read_memory_byte_ret    ret
    
    write_memory_byte
    '#ifdef banked_memory
    '                        and     address, mask_low_word     'Ensure address is within 64K
    '                        cmp     address, common_ram wc     'Address in resident RAM area ?
    '              if_c      add     address, bank_offset       'No: Add offset to current memory bank
    '#endif
    
                            call #RamAddress                ' sets up the latches with the correct ram address
                            ' experiments both replacing outx with outa, and also using data_8 as the working variable instead of outx have both failed
                            mov outx,data_8                 ' get the byte to output
                            and outx, #$FF                  'ensure upper bytes=0
                            or outx,WriteEnable             ' or with correct 138 address which is the same as latchdirection2
                            mov outa,outx                   ' send it out
                            andn outa,#$100                 ' set gate low
                            nop                             ' NOP  needs at least one due to 138 propogation delay
                            or outa,#$100                   ' set it high again
                            mov dira,#0                     ' tristate all pins
    write_memory_byte_ret   ret
    
    RamAddress ' sets up the ram latches. Assumes high latch A16-A18 low so only accesses 64k of ram
                            mov dira,Direction138           ' set up the pins for programming latch chips
                            or  dira,#$FF                   ' set P0-P7 high
                            mov outx,address                ' get the address into a temp variable
                            and outx,#$FF                   ' mask the low byte
                            or  outx,LowAddress             ' or with 138 low address
    '                        call #ToggleGate
                            mov outa,outx                   ' send it out
                            andn outa,#$100                 ' set gate low
                            or outa,#$100                   ' set it high again and repeat for the middle byte
                            mov outx,address                ' get the address into a temp variable
                            shr outx,#8                     ' shift right by 8 places
                            and outx,#$FF                   ' mask the low byte
                            or  outx,MiddleAddress          ' or with 138 middle address
    '                        call #ToggleGate
                            mov outa,outx                   ' send it out
                            andn outa,#$100                 ' set gate low
                            or outa,#$100                   ' set it high again
    RamAddress_ret          ret
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 12:32
    Dr_Acula said...
    Schematic here


    www.smarthome.viviti.com/files/documents/Propeller_v5.pdf


    and this is the code

    Yep, I found it in an archive of yours. I'll have a top level #define DracBladeProp which enables the necessary things.
    It's getting tight in the cog RAM with latched memory addresses. I have to optionally throw out some "kernel code" with debugging on. Without debugging it still fits.

    What's not so nice is that BSTC only every now and then manages to upload to the DracBlade - perhaps 1 out of 10 times. Either BSTC's timing is too tight, or the reset is different from how the PropRPM does it. Are there any things to try? Bigger capacitor on the DTR line perhaps? Or even with a resistor instead? Or without the transistor at all? It isn't fun developing code when the uploads fail most of the times :-/

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 12:43
    I'm only using BST. Hmm - what is different?

    My version is a little older - 15th Jan.

    And I'm using windows rather than ubuntu.

    Try a bigger cap on the reset line?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-03-19 13:37
    Guessing in the dark,

    Isn't there a reset from DTR, or something else, as an option ?

    As for being a slave driver, I have just got back from the pub. The first of many practice "Goodbyes" to the guys I work with. Hic.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 13:48
    Toby Seckshund said...
    Isn't there a reset from DTR, or something else, as an option ?

    No, it's not an option, it's a must. BSTC resets the Propeller to activate the builtin boot loader. I then sends data to either RAM, or to write to the EEPROM, and/or to run it. I'm using the option to write to the RAM, because I do dozens of builds a day.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • BradCBradC Posts: 2,601
    edited 2010-03-19 13:52
    I can see a potential problem with the reset pulse coming from bst[noparse][[/noparse]c] when used with the DracBlade circuit vs the normal Prop-Plug.

    A proper RS232 interface inverts the signal coming from the port prior to it being introduced to the transistor via the cap on the base.
    The FTDI circuit uses the correct TTL levels. bst[noparse][[/noparse]c] makes the reset pulse longer than the pulse from the prop tool to accommodate some scheduling issues with OSX. This might pose a problem for "budget" reset circuits, but works perfectly on FTDI based devices (which are all I have). I guess I need to build an RS232-Prop interface to test with <sigh>.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 14:26
    BradC said...
    I can see a potential problem with the reset pulse coming from bst[noparse][[/noparse]c] when used with the DracBlade circuit vs the normal Prop-Plug.

    A proper RS232 interface inverts the signal coming from the port prior to it being introduced to the transistor via the cap on the base.
    The FTDI circuit uses the correct TTL levels. bst[noparse][[/noparse]c] makes the reset pulse longer than the pulse from the prop tool to accommodate some scheduling issues with OSX. This might pose a problem for "budget" reset circuits, but works perfectly on FTDI based devices (which are all I have). I guess I need to build an RS232-Prop interface to test with <sigh>.

    A perhaps helpful hint: The python script Loader.py that someone posted to the forums manages to talk to the DracBlade. It usually fails once, though, and only in the second try uploads to the EEPROM. And after that script succeeded, I can upload with BSTC to RAM exactly once. It looks to me as if there is some ttySx control or state that is different after the script has been run?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-03-19 23:40
    Re "The FTDI circuit uses the correct TTL levels. bst[noparse][[/noparse]c] makes the reset pulse longer than the pulse from the prop tool to accommodate some scheduling issues with OSX. This might pose a problem for "budget" reset circuits, but works perfectly on FTDI based devices (which are all I have). I guess I need to build an RS232-Prop interface to test with <sigh>."

    That could be an important clue.
    1) what is the timing?
    2) If the signal is inverted, is it resetting on the trailing edge rather than the leading edge, and if so, is this now not leaving enough time?

    So if variables are going to be adjusted, I see two variables, not one.
    1) The length of the reset pulse
    2) The delay from the reset pulse to the start of the download.

    In addition, there are different circuits around.

    www.parallax.com/Portals/0/Downloads/docs/prod/prop/SerialtoPropeller.pdf

    Note the 10k between DTR and reset. I think its function is to borrow the -12V from the DTR line to keep pin 2 resting at -12V. Then the 3906 pulls it up to 3V3 as needed.

    But I am not sure how pulses on DTR then go and affect the Rx line. I wanted a circuit that did not couple the DTR line and the Rx line in any way, so this 10k is not on the dracblade circuit. Since the max232 already is creating the correct voltages, borrowing negative volts from other lines is not necessary.

    The dracblade download circuit comes from the pocketerm circuit www.brielcomputers.com/wik/images/0/01/PTschematic.pdf

    I need to check with Brad - do you have direct control over the DTR line, and if so, is its resting state -12V and you make it +12V to reset, or is the signal inverted? Could you give us a setting in bst where you can adjust the polarity, reset pulse width and delay between reset pulse and the start of download?

    @pullmoll, I am presuming you don't have windows so you can't run the standard proptool program and test if that works?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller

    Post Edited (Dr_Acula) : 3/19/2010 11:46:38 PM GMT
  • SapiehaSapieha Posts: 2,964
    edited 2010-03-19 23:47
    Hi pullmoll

    If it is RESET timing's problems with to longht reset time from BST YOU can experiment with change RESET Capacitor to litle smaller capacitanse.
    That can compensate reset pulse time

    Regards

    Christoffer J

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer.
    Don't guess - ask instead.
    If you don't ask you won't know.
    If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


    Sapieha
  • pullmollpullmoll Posts: 817
    edited 2010-03-19 23:55
    Dr_Acula said...
    @pullmoll, I am presuming you don't have windows so you can't run the standard proptool program and test if that works?

    I have Windows, yes. Need to reboot my box. I'll give it a try and report in this post how it behaves.
    Edit: It works like a charm with Parallax' Prop Tool. Not one failure in 10-15 tries to upload to RAM.
    Dr_Acula said...
    ...do you have direct control over the DTR line, and if so, is its resting state -12V and you make it +12V to reset, or is the signal inverted?

    FWIW: In the terminal the reset happens when DTR goes high. I can toggle it off without any effect, then toggling it on resets the prop.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.

    Post Edited (pullmoll) : 3/20/2010 12:28:19 AM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-03-20 00:07
    Sapieha said...
    Hi pullmoll

    If it is RESET timing's problems with to longht reset time from BST YOU can experiment with change RESET Capacitor to litle smaller capacitanse.
    That can compensate reset pulse time

    Regards

    Christoffer J

    Did you have similar experiences or is this just a guess? I'll see if I can find anything smaller than .01µF in my shland box smile.gif
    Edit: No difference with an 1nF cap, i.e. 1/10th of the original value. If it is the wrong edge of the DTR pulse, then I won't change anything with another cap.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.

    Post Edited (pullmoll) : 3/20/2010 12:24:59 AM GMT
    1024 x 768 - 230K
  • BradCBradC Posts: 2,601
    edited 2010-03-20 01:09
    Dr_Acula said...

    I need to check with Brad - do you have direct control over the DTR line, and if so, is its resting state -12V and you make it +12V to reset, or is the signal inverted? Could you give us a setting in bst where you can adjust the polarity, reset pulse width and delay between reset pulse and the start of download?

    On the FTDI devices, the resting state is GND. You set it high to reset. I twiddle it a bit before hand to work around some other misc OS bugs. The direct output from the RS232 port is of course inverted.

    I'm not keen at all on making any of the communications or reset sequences configurable. It must just work *all* the time.

    I'm sure if I can build one of those RS232-Prop circuits I can get it on the CRO and make it work as reliably as the Prop Plug, but I need some time to sit down and build it, and time is something I'm short of right now. Like I said in the bst thread, I test the detect/load 20,000 times in my regression test, so I'm sure I can tweak it to make it work on all hardware variants.

    It would be working after the Python loader as it would leave the DTR in a different state.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
  • SapiehaSapieha Posts: 2,964
    edited 2010-03-20 01:27
    Hi pullmoll

    I not had problems to short pulse if edge of it was correct.
    BUT not had problems with wrong DTR polarity

    Regards

    On SerPlug I and Bill Henning have build we can select If it is RTS else DTR that will triger Reset and none of them have that problems You describe.
    BUT I Only tested it ON Windows.

    It is one thing to consider from that You describe that Yours Linux else one of programs initiate Serial Port's DTR signal line in bad way ( (Pulse it only istead of change state from inactive to active else not activate it at als). Some of Programs need DTR be Connected to DSR to work to work correctly.
    Have You LED's connected to TX and RX to see if In casses of problems Program transmit anything at als.

    Regards
    Christoffer J

    PS. I see You use BSTC with script in Linux - Have You posibility to Control Serial Port TTYx Initial state in it. If so You can tray Reset initial DTR state to HIGH - Inactive before You CALL - BSTC



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer.
    Don't guess - ask instead.
    If you don't ask you won't know.
    If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


    Sapieha

    Post Edited (Sapieha) : 3/20/2010 1:38:31 AM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-03-20 01:44
    Sapieha said...
    I see You use BSTC with script in Linux - Have You posibility to Control Serial Port TTYx Initial state in it. If so You can tray Reset initial DTR state to HIGH - Inactive before You CALL - BSTC

    Ok, I think we're close to the reason now. I have to read a few man pages if I can change DTR before running BSTC. It's not exactly a script but a Makefile that calls BSTC, i.e. I just type "make" to build and upload a new version.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • pullmollpullmoll Posts: 817
    edited 2010-03-20 01:47
    BradC said...
    It would be working after the Python loader as it would leave the DTR in a different state.

    Exactly. This is what I wrote in your thread. Loader.py leaves DTR=0 all the time and also when exiting. I thought that perhaps stty has a command to modify the DTR line, but it doesn't seem so. Right now I'm just calling Loader.py to fail before calling BSTC and this awful hack works for me [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
  • SapiehaSapieha Posts: 2,964
    edited 2010-03-20 01:55
    Hi pullmoll

    Sorry - I have one question to YOU that Not are Propeller related.
    You not need answer if You not like it.

    Question.
    As I read in one post from YOU Yours Family comme from Finland - Why I ask is as first time I see YOUrs Picture I think It is my FRIEND that started with propeller and nos say me anything - YOU are very like HIM. I needed look on his PICTURE to be sure at it is not he so like it is.

    Know You if You still have any family in FINLAND ad what City else part of Finlad them come ?

    Regards
    Christoffer J

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer.
    Don't guess - ask instead.
    If you don't ask you won't know.
    If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


    Sapieha
  • pullmollpullmoll Posts: 817
    edited 2010-03-20 02:08
    Sapieha said...
    As I read in one post from YOU Yours Family comme from Finland

    That was just a JOKE - we were talking about drinking alcohol and I jokingly said I think my ancestors came from Finland.

    HTH,
    Juergen (born in Bonn, Germany, still living in Bonn, and all of the family coming from close around Bonn)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    He died at the console of hunger and thirst.
    Next day he was buried. Face down, nine edge first.
Sign In or Register to comment.