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

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

12628303132

Comments

  • heaterheater Posts: 3,370
    edited 2009-11-16 16:17
    I rember someone saying that when they saw a wind-up gramophone for sale in 1970's.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-17 01:08
    Toby: Mike NZ should be sending you a PM about the Nascom.

    heater: I am still looking for my old fashioned clunky morse key. I threw a lot of stuff out in 2000 when we moved. Hoping that didn't go too. Not that I ever got my morse ticket. But the real thing is all my Motorola kits and Z80 kits, plus tubes of new Z80's and SCC's etc that got thrown out (sold for scrap along with my mini computers).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-17 03:31
    This is a special present for Heater. Wordstar running on a single propeller as a standalone computer with keyboard and display driver and sd card.

    Ok, it is slow to load (because the ram DMA is in spin and needs to be ported over to pasm. A couple of hours work)
    It also needs tweaking as the wordstar version is using 24 lines and the prop terminal program is set up for 40 lines. Need to edit a wordstar overlay file (which isn't too hard). So - lots more lines of text. Sweet!
    I made it green screen as it is getting close to the capacity of the internal memory of the propeller and some of the vga driver code for multiple colors was not needed. But with optimisation I think it can go back in.

    8080 codes work fine. VT100 codes also work fine. The spin code scans both the serial port input for keypresses (from the PC) and also the local keyboard and sends both through to CP/M. The output goes to both the PC terminal program and to the vga display. (and given there is a nifty 20x4LCD display object in the obex, I'll also send it to a small LCD display).

    8x 8mb hard drives. Two serial ports.

    The code is a mess as it includes lots of commented out lines and lots of triblade ifdefs that actually should be dracblade ifdefs. I need to take the latest version of Cluso's code ((I'm on 127) and rebuild it properly so it has the triblade or the dracblade. An other hour or two of coding, but all straightforward to do.

    Eventually I'll need to take a close look at trying to go back to Z80 codes. Then again, I never really use many as I tend to use only 8080 codes but write assembly in Z80 mnemonics. Indeed (and intriguingly), the only unique Z80 code I really like is DJNZ, which I see has found its way into PASM.

    I have a new board on the way. It has onboard switchers for both 3V3 and 5V and has the wirelinks fixed. Also some pins were changed so the SD card pins are now grouped together. Once that arrives next week and I can prove it works, I might see my way clear to sending a few freebies to anyone that is keen to give this a go.

    The catch. There is always a catch. It is about 2/3 of the speed of the triblade. I think it would be up to the user to decide on speed vs cost.

    The upside - pacman runs at a *normal* speed, so it is possible to win!!

    Back to coding...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 11/17/2009 3:45:59 AM GMT
    1280 x 960 - 321K
    1280 x 960 - 271K
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-17 03:41
    Nice work James smile.gif
    I just posted a version of ZiCog that saves another 8 longs. There are probably other savings but I didn't look closely.

    Probably need to profile the instruction set usage to find out what are most used.

    Are you home today???

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • heaterheater Posts: 3,370
    edited 2009-11-17 11:37
    Thanks for the special present. Very impressive.

    How much space have you got left in HUB ? Going to full Z80 also eats HUB space with extra dispatch tables.

    Yep, you now have unenviable job of getting it to compile and run for both TriBlade and DracBlade. I imagine we are running into some messy "#ifdef" soup by now.

    Hmm..freebies [noparse]:)[/noparse]

    Perhaps you should put up a DracBlade thread so the future DracBlade followers can find what they need.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-17 11:57
    Yes, you need a DracBlade thread describing the hardware. Then we will have 3+ places to look for code. OUCH!

    Had my TriBlade running today for the first time since the 3rd Adelaide propfest. It has done some travelling - Surfers, Gosford, Adelaide, Gosford, Surfers, Gosford. At least I didn't leave it on a bus LOL.
    I will have to download TeraTerm. James, are there any tricks to get running with wordstar ???

    heater: did you look at the ZiCog code where I found 8 longs. Found another 2. Slightly faster too. But of course I want to use them to speedup the emulation - fetching words would be a nice improvement in speed.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • heaterheater Posts: 3,370
    edited 2009-11-17 12:21
    Enough with the bus jokes already....grrr

    No time to fire up any prop code. I'm running about a lot, on that damn bus, just have odd moments to ramble on here.

    Anyway, all changes to the zicog emulation itself need checking by running the instruction set test program EXZ80DOC.COM. If that passes at least as well normal I'd be more than happy with any optimizations anyone can come up with. Problem is it takes a good long time to run.

    Note: Must use CPU_Z80 and EXZ80DOC.COM. There is also an EX8080.COM that tests 8080 only op-codes only but as we are setting the flags like a Z80 it fails pretty much every test. Perhaps one day the will be a shed load more #ifdefs to get the 8080 flag setting right.

    EXZ80ALL.COM tests against undocumented flag register bit settings which I've never bothered to look into.

    WORD read/writes would be great if you can find enough space to put the extra code in.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-17 12:42
    Yes, ok three threads it may have to be. This board isn't quite ready yet though for prime time so I hope it is ok to keep posting here for the moment...

    Re how much space free, BST tells me that the program is 4800 longs, the variable list is 1518 longs and there are 1870 longs free. I don't think the ifdefs will be too bad - it should be possible for instance to put most of it in a single big group at the bottom of the existing code as a single ifdef.

    And as a shameless plug for BST, the quick F10 compile/test/run has greatly sped up development.

    Next little job is to replicate the triblade driver as a dracblade driver, and that should simplify the ifdef situation even further.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-18 02:23
    James: No problems - keep it here until you have fully spec'd hw.

    The space problems are in the ZiCog cog for your extra code, and hub only in heater's DemoBoard platform (no SRAM) where every bit of space is required for CPM.

    To see how much ZiCog space is available place some nop's at the beginning of the ZiCog code after outx and before the jmp #fetch. After this instruction it will be removed by bst as unused code!

    I have a little time over the next few days so I will try and get the new fsrw running on ZiCog/TriBlade. Whether it works or not, I think it is time for a V1.0 release, arts and all, so I will liase with heater on this.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-18 12:23
    This picture is a bit blurry but it demonstrates writing an SBasic program in the N8VEM IDE and then hitting a 'compile' button and downloading and running it on the Propeller. For a small program compiled by shelling the SIMH and downloading the .COM it takes about 10 seconds. Alternatively, the program can be downloaded compiled on the Propeller and this takes about 20 seconds. Both are 'one click' options, much like the F10 option for compiling the entire Zicog (which in itself is about 10 seconds).

    So the development cycle for writing code is fast.

    The N8VEM IDE has a number of 'one click' options, including downloading batches of files using xmodem. A batch of files might be the Wordstar group, or the BDS C group. This all is working brilliantly on the propeller.

    What is new today is the Dracblade driver in PASM. This is the same as the Triblade driver, so the concept here is that you drop in a single object depending on the hardware. The code is now greatly simplified. The main differences now with the Triblade code is the startup code for the keyboard and vga, duplicating UART.tx("A") with VGATEXT.OUT("A") for diagnostic messages, and some extra code at the bottom included as a single #ifdef that handles the VT100 terminal.

    Bootup is *fast*. Indeed, with a cathode ray monitor switched off at the powerpoint, and switching both the monitor and the propeller on at the same time, the A> is ready for use about the same time as the monitor is warmed up. Since when has Windows been able to do that?!

    @Cluso, if it is ok with you, I'd like to try to combine these two projects into one source code, with suitable #ifdefs? I've looked through the code and I don't think it will decrease the readability of the triblade code as the dracblade will largely replicate the triblade as an alternate group of ifdef code. Do you have a copy of your latest version by any chance? OR - would you prefer I wait till 1.0 comes out?

    Re the zicog in Z80, I'm over by 14 longs.
    I might be able to save a few as I have
    Zero                    long    %00000000_00000000_00000000_00000000
                            mov dira,zero                   ' tristate all pins
    
    



    Is this the same as mov dira,0 ?, ie specifically, given that constants seem to be limited to 9 bits, does mov dira,0 tristate bits 10 up?

    That might save a little.

    Then I've also noticed that the entire ram driver only uses pins 0-15. So, instead of
    LatchDirection          long    %00000000_00000000_00011101_11111111
    
    



    Is it possible to substitute a word instead of a long? (assuming that pins 16-31 are definitely all tristated).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
    1280 x 960 - 321K
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-18 12:47
    Great work James jumpin.gif

    If you want to put the DracBlade driver within the TriBlade driver and select by #ifdef, that is fine by me. I guess, as we add other platforms, it will only be necessary to issue one set of software files which will be simpler.

    Would you like to email me your ZiCog code and I will see if I can find some longs for you. I am not confident though. Heater maybe able to put one of the Z80 resident opcodes into an overlay to save the space for you.

    I think mov dira,#0 is legitimate.

    The latch direction is in the cog, so it has to be long.

    I don't think I have done anything to the code (except the ZiCog.spin yesterday) since I gave you the latest - it is only comments and I can add them easily. email me on when you are available and I can hook up skype.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-18 12:57
    Ok, doing mov dira,0 doesn't work
    Changing longs to words doesn't work either (it did work but only with one variable, and then I needed to pad it anyway so the dispatch tables lined up.

    I shaved two nops on the ram and now it is only over by 12 longs.
    I haven't put in the changes you suggested on the zicog thread but I think you shaved another ?2 longs

    Re the code, I commented out these lines:
    '#ifdef TriBladeProp
    'the following are also used as variables later...
    'The TriBladeProp Blade #2 driver presets the latch to enable SRAM -CE(U23)=0 and hold LE=0
    'datax                   mov     outa, ram_latched          '-WE=1 -OE=1, all other bits=0
    'outx                    mov     dira, ram_dir_read         ' setup direction to read
    '#endif
    
    



    and then the ramd driver code is below. Otherwise the zicog is unchanged.
    GateHigh                long    %00000000_00000000_00000001_00000000  ' HC138 gate high, all others must be low
    Outx                    long   %00000000_00000000_00000000_00000000  ' temp variable                                   ' for temp use, same as n in the spin code
    LatchDirection          long    %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active
    LatchDirection2         long    %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read
    LowAddress              long    %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1
    MiddleAddress           long    %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1
    'ReadEnable long    %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1
                                                            ' commented out as the same as GateHigh
    WriteEnable             long    %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1  
    
    Zero                    long    %00000000_00000000_00000000_00000000 ' for tristating all pins
    
    
    read_memory_byte 
                            call #RamAddress                ' sets up the latches with the correct ram address
                            mov dira,LatchDirection2        ' for reads so P0-P7 tristate till do read
                            mov outa,GateHigh               ' actually ReadEnable but they are the same
                            andn outa,GateHigh              ' set gate low
    '                        nop                             ' short delay to stabilise
                            nop                             ' none does not work, 1 does work
                            mov data_8, ina                 ' read SRAM
                            and data_8, #$FF                ' extract 8 bits
                            or  outa,GateHigh               ' set the gate high again
                            mov dira,zero                   ' tristate all pins
    read_memory_byte_ret    ret
    
    write_memory_byte
                            call #RamAddress                ' sets up the latches with the correct ram address
                            mov outx,data_8                 ' get the byte to output
                            and outx, #$FF                  'ensure upper bytes=0    
                            or outx,WriteEnable             ' or with correct 138 address
                            mov outa,outx                   ' send it out
                            andn outa,GateHigh              ' set gate low
    '                        nop                            ' no nop doesn't work, one does, so put in two to be sure
                            nop                             ' another NOP
                            or outa,GateHigh                ' set it high again
                            mov dira,zero                   ' 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,LatchDirection         ' set up the pins for programming latch chips
                            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
                            mov outa,outx                   ' send it out
                            andn outa,GateHigh              ' set gate low
                                                            ' ?? a NOP
                            or outa,GateHigh                ' set it high again  
                                                            ' now 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
                            mov outa,outx                   ' send it out
                            andn outa,GateHigh              ' set gate low
                            or outa,GateHigh                ' set it high again 
    RamAddress_ret          ret
    
    



    If you can see an optimisation that would be great!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-11-18 14:37
    Has to be "mov dira,#0" - which I use all the time [noparse]:)[/noparse]
    Dr_Acula said...
    Ok, doing mov dira,0 doesn't work
    Changing longs to words doesn't work either (it did work but only with one variable, and then I needed to pad it anyway so the dispatch tables lined up.

    I shaved two nops on the ram and now it is only over by 12 longs.
    I haven't put in the changes you suggested on the zicog thread but I think you shaved another ?2 longs

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
    Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
    Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-18 14:37
    Here is the first optimisation - saves 3 longs but is slower
    GateHigh                long    %00000000_00000000_00000001_00000000  ' HC138 gate high, all others must be low
    LatchDirection          long    %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active
    LatchDirection2         long    %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read
    LowAddress              long    %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1
    MiddleAddress           long    %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1
    'ReadEnable long    %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1
                                                            ' commented out as the same as GateHigh
    WriteEnable             long    %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1  
    Zero                    long    %00000000_00000000_00000000_00000000 ' for tristating all pins
    outx                    long    $0                                   ' temp variable                                   ' for temp use, same as n in the spin code
    addrx                   long    $0
    read_memory_byte 
                            call    #RamAddress             ' sets up the latches with the correct ram address
                            mov     dira,LatchDirection2    ' for reads so P0-P7 tristate till do read
                            mov     outa,GateHigh           ' actually ReadEnable but they are the same
                            call    LatchItRead
                            mov     data_8,outx             ' get the data read
                            and     data_8, #$FF            ' extract 8 bits
                            mov     dira,zero               ' tristate all pins
    read_memory_byte_ret    ret
    write_memory_byte
                            call    #RamAddress             'sets up the latches with the correct ram address
                            mov     outx,data_8             'get the byte to output
                            mov     addrx,WriteEnable       'or with correct 138 address
                            call    LatchIt
                            mov     dira,zero               '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,LatchDirection
                            mov     outx,address            'set address 0-7 (& 8-15)
                            mov     addrx,LowAddress        'set the Low Address
                            call    LatchIt
                            mov     outx,address            
                            ror     outx,#8                 'set address 8-15
                            mov     addrx,MiddleAddress     'set the Middle Address
                            call    LatchIt
    RamAddress_ret          ret
                            
    LatchIt                 and     outx,#$FF               ' mask the low byte (data/address byte)
                            or      outx,addrx              ' or with 138 mask
                            mov     outa,outx               ' send it out
    LatchItRead             andn    outa,GateHigh           ' set gate low
                            nop                             ' ?? a NOP
                            mov     outx,ina                ' read SRAM (in case it is a read)
                            or      outa,GateHigh           ' set it high again  
    LatchIt_ret             ret
    
    

    Here is a second - another saving of 3 longs. Note the immediate values - they should work
    GateHigh                equ     %1_00000000                           ' HC138 gate high, all others must be low
    LatchDirection2         equ     %0_11111111                           ' for reads so data lines are tristate till the read
    Zero                    equ     $0                                    ' for tristating all pins
    DAT
    'GateHigh               long    %00000000_00000000_00000001_00000000  ' HC138 gate high, all others must be low
    LatchDirection          long    %00000000_00000000_00011101_11111111 ' 138 active, gate active and 8 data lines active
    'LatchDirection2        long    %00000000_00000000_00011101_00000000 ' for reads so data lines are tristate till the read
    LowAddress              long    %00000000_00000000_00001001_00000000 ' low address latch = xxx010xx and gate high xxxxxxx1
    MiddleAddress           long    %00000000_00000000_00001101_00000000 ' middle address latch = xxx011xx and gate high xxxxxxx1
    'ReadEnable long    %00000000_00000000_00000001_00000000 ' /RD = xxx111xx and gate high xxxxxxx1
                                                            ' commented out as the same as GateHigh
    WriteEnable             long    %00000000_00000000_00011101_00000000 ' /WE = xxx111xx and gate high xxxxxxx1  
    'Zero                   long    %00000000_00000000_00000000_00000000 ' for tristating all pins
    outx                    long    $0                                   ' temp variable                                   ' for temp use, same as n in the spin code
    addrx                   long    $0
    read_memory_byte 
                            call    #RamAddress             ' sets up the latches with the correct ram address
    '                       mov     dira,LatchDirection2    ' for reads so P0-P7 tristate till do read
                            andn    dira,#LatchDirection2   ' for reads so P0-P7 tristate till do read
                            mov     outa,#GateHigh          ' actually ReadEnable but they are the same
                            call    LatchItRead
                            mov     data_8,outx             ' get the data read
                            and     data_8, #$FF            ' extract 8 bits
                            mov     dira,#zero              ' tristate all pins
    read_memory_byte_ret    ret
    write_memory_byte
                            call    #RamAddress             'sets up the latches with the correct ram address
                            mov     outx,data_8             'get the byte to output
                            mov     addrx,WriteEnable       'or with correct 138 address
                            call    LatchIt
                            mov     dira,#zero              '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,LatchDirection
                            mov     outx,address            'set address 0-7 (& 8-15)
                            mov     addrx,LowAddress        'set the Low Address
                            call    LatchIt
                            mov     outx,address            
                            ror     outx,#8                 'set address 8-15
                            mov     addrx,MiddleAddress     'set the Middle Address
                            call    LatchIt
    RamAddress_ret          ret
                            
    LatchIt                 and     outx,#$FF               ' mask the low byte (data/address byte)
                            or      outx,addrx              ' or with 138 mask
                            mov     outa,outx               ' send it out
    LatchItRead             andn    outa,#GateHigh          ' set gate low
                            nop                             ' ?? a NOP
                            mov     outx,ina                ' read SRAM (in case it is a read)
                            or      outa,#GateHigh          ' set it high again  
    LatchIt_ret             ret
    
    

    Now that saves 6 longs plus the 8 I saved yesterday.. So it should now fit provided I have correctly redone your code :-)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

    Post Edited (Cluso99) : 11/18/2009 2:44:07 PM GMT
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-11-18 14:43
    - you don't need "GateHigh" as you can use the constant "#$100"

    Saves you one long!
    Dr_Acula said...
    Ok, doing mov dira,0 doesn't work
    Changing longs to words doesn't work either (it did work but only with one variable, and then I needed to pad it anyway so the dispatch tables lined up.

    I shaved two nops on the ram and now it is only over by 12 longs.
    I haven't put in the changes you suggested on the zicog thread but I think you shaved another ?2 longs

    If you can see an optimisation that would be great!
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
    Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
    Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-18 14:44
    Bill - thinking alike smile.gif (see prev page)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-18 22:34
    Thanks ++ for those suggestions. I can't wait to get home from work tonight and try this out.

    I'm still trying to get the hang of mixing up a 32 bit processor with 8 bits, 16 bits and 9 bit constants. If code space wasn't an issue (as it isn't generally in Spin) then I guess it is just easier to do everything in longs.

    So to clarify, mov myvalue, #nn will work with #nn from 0 to $1FF? But mov outa,#0 will tristate all 32 pins?

    And if I have a long and I OR it with a constant, and the constant only goes up to $1FF, then do the bits above bit 9 remain unchanged?
    What would happen if you did an AND with a constant? would the bits above bit 9 remain unchanged, or are they ANDed with a hidden value of either 0 or 1?

    Another thought - can outa be used as a register? I'm thinking of the code where it starts with a value in outx, does some bit manipulation on that then about half way through puts that into outa and then does some more bit manipulation. So long as the 138 latch bit always stays high or tristate through this process, it won't really matter if the other lines are going on and off as the pins are set up. Could this then mean outx isn't needed as a variable??

    I'll ponder that a bit more as it might be that the changes already made have resulted in enough savings. Cluso, are you up to 8 longs already in other parts of the code?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
  • heaterheater Posts: 3,370
    edited 2009-11-18 22:45
    Ultimately all Prop ops are 32 bits wide. If you use a literal value (with the #) you get to specify only the low 9 bits, the other 23 being zeros. So you can work out what AND, OR, etc do from that.

    No reason you can't use outa as a register. Well, it IS a register. Execute an instruction from it if you want to "JMP #OUTA"

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-19 02:17
    James: As heater said, the #$00-#$1FF are zero extended by the hardware, so any instruction will just make the remaining bits zero. It is a neat trick we use.

    There are 4 to 6? usable shaddow memory locations in the cog ram register range $1F0-$1FF that can be used. I use them for my zero footprint debugger which wholy resides in the shaddow ram and executes from there. It is tricky to use but as a last resort it's there. There is DIRB, INB, OUTB.

    I already found 8 longs in the ZiCog.spin I posted 2 days ago. I re-used 2 instructions which were only executed on startup for temporary locations (datax & outx ??). I found address_stash and ???_stash could also find an instruction only used on startup.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-20 01:52
    Got there - the zicog now fits on the dracblade with Z80 opcodes and precisely zero longs spare!

    Optimisations:
    1) - Cluso's 8 longs saved in rr128
    2) Realising that WriteEnable and LatchDirection2 in my variables were the same thing
    3) Using andn outa,#$100 ' set gate low using a constant rather than a long. This saved code in many places.
    4) I didn't end up needing the LatchIt optimisations so speed is still the same
    5) removing multiple instances of
    '#ifdef TriBladeProp
    ' mov dira, ram_dir_input 'RR20090321 (pass I/O to another cog)
    '#endif

    as I'm pretty sure my dira gets set explicitly with each memory call. Unless I misunderstand this bit of code.
    and 6) - the one that might be controversial: At the beginning of the zicog is this:
    DAT
                            org     0
    entry
    OVERLAY_LOAD_RET
    '                        jmp       #RESIDENT_CODE           'Go execute resident code first (loaded automatically at CogNew)
                                                               'Can use as a RET instruction AFTER execution of the loaded overlay
    '---------------------------------------------------------------------------------------------------------
    'RESIDENT ROUTINES follow...
    '
    RESIDENT_CODE 
    
    



    and as shown above, I commented out the jmp #resident_code

    It still seems to work but am I missing something with this jump to the very next label in the code?


    **postedit - attached is my collection of useful Z80 assembly routines with low level CP/M calls like print to the screen, file I/O, math and strings. Compilation off board and download using the N8VEM editor takes about 5 seconds. All works perfectly though it doesn't use all the instructions, so I'm going to leave it running overnight with the EXZ80DOC program.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 11/20/2009 2:22:31 AM GMT
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-20 02:34
    Drac, the jmp #resident_code is modified if heater uses the overlay as a call. I cannot answer if this is used or not, because the overlay mechanism I wrote allows a few options. Try comenting out the label OVERLAY_LOAD_RET. If it still compiles then it is ok, if not then you may get wierd results because the next instruction will be modified with a call return address.

    So if I understand correctly you have 1 long to find if you need the above instruction. Is there any code you execute once on startup? address_stash can be placed on this instruction and save a long. Use DIRB as a register to save & restore for address_stash. This will give you 1 long.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-20 03:27
    Yes I thought the jmp resident_code looked a bit easy. It might also explain a few fails in the instruction exercisier.

    So--- need to look at those other options. I looked at address_stash (and the other stash one)and outx but they seem to both be used as part of the same routine (ie stash/read/restore from stash)so no luck there. Ditto using data_8 as a working variable inside the read/write routines.

    DIRB it might be then - I'll check it out.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 11/20/2009 3:34:41 AM GMT
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-20 04:43
    You have to be careful using the registers as memory storage as not all are read/write and there is also shaddow ram underneath them.

    But you can (should be able) to use the DIRB as a temp storage location without problems. So just change address_stash or data_stash to DIRB - IIRC data-stash is only used once so it is an easier mod.

    The simpler the mod the better smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-20 12:24
    I tried something else. There is a variable 'nibble' in the main zicog code. I searched through and could only find this variable in the DAA overlay. So I fingured maybe it could be moved to the overlay? eg comment it out here
    '---------------------------------------------------------------------------------------------------------
    'Z80 String operation parts
    
    '---------------------------------------------------------------------------------------------------------
    'Misc variables
    alu                     long    0
    aux                     long    0
    'nibble                  long    0
    mask_bit_16             long    $0001_0000
    mask_low_word           long    $0000_FFFF
    cmd_pending             long    0  
    
    



    and put it at the end of the overlay.
    daa_ovl
                            rdbyte  data_8, a_reg
                            mov     nibble, data_8             'Isolate low nibble of accumulator
                            and     nibble, #$0F                        
                            cmp     nibble, #10 wc             'Test for greater than 9                
                            test    flags, #aux_bit wz            'Test auxillary carry
                if_nz_or_nc add     data_8, #$06               'Add 6 to accumulator if greater than 9 or AUX carry
                            add     nibble, #6                 'Check for AUX carry from low nibble
                            test    nibble, #%00010000 wz
                            muxnz   flags, #aux_bit            'and set AUX flag if so.      
                            mov     nibble, data_8             'Isolate high nibble of accumulator
                            shr     nibble, #4
                            cmp     nibble, #10 wc             'Test for greater than 9
                            test    flags, #carry_bit wz       'Test carry flag
                if_nz_or_nc add     data_8, #$60               'Add (6 << 4) to accumulator if greater than 9 or carry
                            test    data_8, #$100 wz           'Check for 8 bit carry out
                if_nz       or      flags, #carry_bit          'Set carry flag if so (N.B. Do NOT clear carry if not so)
                            and     data_8, #$FF wz, wc
                            muxz    flags, #zero_bit           'Set Z80 zero flag from props zero
                            muxnc   flags, #parity_bit
                            test    data_8, #128 wz
                            muxnz   flags, #sign_bit
                            wrbyte  data_8, a_reg                        
                            jmp     #fetch
    nibble                  long    0
                            long    $0[noparse][[/noparse]($ - OVERLAY_START) // 2]    'fill to even number of longs (REQUIRED)
    daa_ovl_end
                            fit    $1F0            
    
    



    This gives me the long I need. Compiles fine. Also tested it with a quick program in assembly and traced it through with DDT. Put 0B2H into
    the A register and it returns 12 which is correct as B+6=decimal 17 which is 16+1, and the 2 stays the same. Gives the same result as it gave before.

    I hope this isn't missing something?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-20 12:46
    Drac: That sounds fine but heater would know precisely. Congratulations are in order smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-20 14:01
    Wasn't Turbulence using the "output pins" as fast storage. The first time I ran it, it was on my early Z80 bd which was laden with debug LEDs. They were almost as entertaining as the VGA output.

    Dr_A

    I have mused on the decoder and latch bits of Dracblade, they will fit int a XC9536XL (·LCD not implimented )·One spare pin and only 66% used innards, although I havent floorplanned it yet.


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point

    Post Edited (Toby Seckshund) : 11/20/2009 2:09:04 PM GMT
  • heaterheater Posts: 3,370
    edited 2009-11-20 14:46
    Moving nibble I'm sure is just fine. It will slow down DAA as it's another long to load. We don't much care about the speed of DAA.

    Actually thinking about it, generally moving data from "resident" to overlay in what is the biggest overlay would not gain you any space. After all that just makes the resident area smaller and the required overlay area bigger. But there is the fact that overlays have to be an even number of LONGS in size. So perhaps we are lucky and the nibble just moves into a place that would be padded out with zero anyway. In which case there is no loss in speed either.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2009-11-20 14:48
    By the way that "cmd_pending" LONG does not seem to be used anywhere. Can't for the life of me remember what it was supposed to be for anyway.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-11-20 15:00
    bst optimises so if it's not used it's probably not in the compiled code. I fell into that trap trying to add dummy longs to find out how many longs were left in the cog.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • heaterheater Posts: 3,370
    edited 2009-11-20 15:41
    "bst optimises so if it's not used it's probably not in the compiled code"

    As far as I can tell this is NOT true for LONGs in PASM. I've just tried it again with simple test prog with all optimizations turned on.

    For sure it would be very bad to just remove along from the middle of PASM which could well beak some code that depends on the offsets of things. Unlike Spin it is very dangerous to remove away code from assembly languages.

    I have used the trick of adding "unused long 0[noparse][[/noparse]43]" as dummy longs before a "fit" statement to determine the amount of free space. But you don't need to, BST tells us in the listing file output.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
Sign In or Register to comment.