Hijacking the P2-EVAL ROM (now hijacking current TAQOZ)

msrobotsmsrobots Posts: 2,819
edited 2019-07-22 - 01:56:08 in Propeller 2
While I just was thinking about how nice the build in Monitor/Debugger works and one can switch between Monitor and TAQOZ, I stumbled about TAQOZ doing a cold start all the time I switched between Monitor and TAQOZ.
Not nice, I just had finally some words defined, hit ctrl-D use the monitor, hit ESC cr, back in TAQOZ, my words are gone.

That was, what started this.

I needed to patch the ROM that @Cluso99 's monitor/debugger on ESC cr NOT jumps to _START_TAQOZ but to _REENTER_TAQOZ and voila, my words stay alive.

That got me thinking what else could I patch into the ROM that might be useful.

And looking thru the ROM source I decided to try to Hijack the complete thing. Sure none of this will work on the next ROM, but it can be adapted.

Most of it is changing rx and tx port numbers away from the usb-port, so that stays free for the user application. It would be nice if the next ROM could spare two longs for rx/tx pins instead of hardcoding it into every instruction with #rx_pin.

compared to current it would save a lot of patching, just 2 longs not xxx places in the ROM code.


ok lets start with some code
' This program creates an 4-LED Larson scanner on the P2 Eval board

ls_fwd  mov 	ledpin, 	#56     ' start with p56
        mov 	cycles, 	#3      ' light 4 going up
.loop   drvl    ledpin          	' led on
        waitx   ##_clockfreq/8  	' wait 1/8 second
        drvh    ledpin          	' led off
        add 	ledpin, 	#1      ' next pin
        djnz    cycles, 	#.loop  ' done? 

ls_rev  mov 	ledpin, 	#59     ' start with p60
        mov 	cycles, 	#3      ' light 4 going down
.loop   drvl    ledpin
        waitx   ##_clockfreq/8
        drvh    ledpin
        sub 	ledpin, 	#1
        djnz    cycles, 	#.loop

        jmp 	#ls_fwd

ledpin  res 1
cycles  res 1

Since I want serial coms to the ROM I need some frequency, so I use @Cluso99 method to calculate as constants and switch to it, then start a new COG with my Larson.

Basically I just add the launch code in front of the PASM and change orgh to greater as $FFFF
CON
  _XTALFREQ     = 20_000_000                                    ' crystal frequency
  _XDIV         = 4             '\                              '\ crystal divider                      to give 5.0MHz
  _XMUL         = 72            '| 180MHz                       '| crystal / div * mul                  to give 360MHz
  _XDIVP        = 2             '/                              '/ crystal / div * mul /divp            to give 180MHz
  _XOSC         = %10                                   '15pF   ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
  _XSEL         = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
  _XPPPP        = ((_XDIVP>>1) + 15) & $F                       ' 1->15, 2->0, 4->1, 6->2...30->14
  _CLOCKFREQ    = _XTALFREQ / _XDIV * _XMUL / _XDIVP            ' internal clock frequency                
  _SETFREQ      = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
  _ENAFREQ      = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator
'------------------------------------------------------------------------------------------------
  _baud         = 2_000_000'115_200
  _bitper       = (_clockfreq / _baud) << 16 + 7          	' 115200 baud, 8 bits
  _SerialInit   = $fcab8        				' Serial Initialise     (lmm_x & lmm_bufad must be set first)
  _HubMonitor   = $fcd78        				' Calls the Monitor; uses lmm_bufad as the input buffer address
  _HUBBUF       = $FC000        				' overwrite Booter as serial buffer
  _START_TAQOZ  = $FD028

  lmm_x         = $1e0          				' parameter passed to/from LMM routine (typically a value)
  lmm_bufad     = $1ef          				'_HubRxString
'------------------------------------------------------------------------------------------------
DAT
        orgh    0
        org     0

        hubset  #0                              ' set 20MHz+ mode
        hubset  ##_SETFREQ                      ' setup oscillator
        waitx   ##_XTALFREQ/100                	' ~10ms
        hubset  ##_ENAFREQ                      ' enable oscillator

	' patch ROM
	' _REENTER_TAQOZ not _START_TAQOZ on ESC cr
        wrbyte	#$B4,		  ##$FCD8C   	' new - if_e    jmp     #@_REENTER_TAQOZ
						' old - if_e    jmp     #@_START_TAQOZ

	' now start
        mov     lmm_bufad,        ##_HUBBUF     ' locn of hub buffer for serial routine 
        mov     lmm_x,            ##_bitper     ' sets serial baud
        call    #_SerialInit                    ' initialise serial
	
        'SETQ    ptra_val           		' would end up in ptra of new cog
        coginit #1,##@_mainprogram              ' Start Main program in COG #1

	jmp	#_START_TAQOZ			' and transfer control of COG 0 to TAQOZ
 
        fit     $1E0                    	' ensure LMM reserved area cog $1E0-$1EF available                                                                              
''---------------------------------------------------------------------------------------------------
        orgh    $10000              		' leave the first 64K free for TAQOZ
        org 0
_mainprogram
''---------------------------------------------------------------------------------------------------
'' HERE NOW THE SOURCE OF WHATEVER YOU WANT TO PLAY WITH (it will run on COG #1++)
''---------------------------------------------------------------------------------------------------

' This program creates an 4-LED Larson scanner on the P2 Eval board

ls_fwd  mov 	ledpin, 	#56     ' start with p56
        mov 	cycles, 	#3      ' light 4 going up
.loop   drvl    ledpin          	' led on
        waitx   ##_clockfreq/8  	' wait 1/8 second
        drvh    ledpin          	' led off
        add 	ledpin, 	#1      ' next pin
        djnz    cycles, 	#.loop  ' done? 

ls_rev  mov 	ledpin, 	#59     ' start with p60
        mov 	cycles, 	#3      ' light 4 going down
.loop   drvl    ledpin
        waitx   ##_clockfreq/8
        drvh    ledpin
        sub 	ledpin, 	#1
        djnz    cycles, 	#.loop

        jmp 	#ls_fwd

ledpin  res 1
cycles  res 1


Now Larson runs on COG1 and TAQOZ on COG0 using USB to PC.

that made me interested, so I dug in deeper...

Mike
I am just another Code Monkey.
A determined coder can write COBOL programs in any language. -- Author unknown.
Press any key to continue, any other key to quit

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
«1

Comments

  • Now my goal is to use all the mighty of the ROM build in TAQOZ from other more readable languages. Like one can dedicate a job to a smart pin, one can dedicate a job to a TAQOZ smart core.

    And it works. I can basically 'talk' to TAQOZ or the MONITOR/DEBUGGER via serial. To leave the standard serial port for the normal application I needed to convince the current ROM routines to listen and write to different pins, but this was doable by patching the ROM.

    except 'lsio'

    that sort of resets the rx/tx pins and kills me.

    Anyways, it is working, sort of.

    I patch the ROM to use different pins, then I patch the rx smartpin of the ROM to listen to the pin next to itself. Same for my connecting driver, it also listen to the pin next to it. Those smart pins are cool.

    OK,

    now I have COG0 running TAQOZ/MONITOR, 4 pins to communicate and everything else free.

    But it is a tedious process, compiling with fastspin, opening the P2ASM file, inserting the block of code directly at the first DAT line, changing orgh $800 against orgh $10800. On every compile.

    attached some source to compile and run, created with fastspin and modified a bit...

    you can compile it and load it with whatever you have, it is just PASM

    I need some buffered serial smart pin driver to get this usable.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Now you get an idea how hard it was in testing our ROM code, and we were up against the time barrier and ROM space. We had to cull the code to make it fit. But Peter and I had fun :smiley:
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • yes @Cluso99

    I really like the work you did with the Monitor and serial routines. The TAQOZ part is less understandable...

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Hi msrobots,

    What did you mean by hijacking? Did you manage to rewrite the ROM?

    Kind regards, Samuel Lourenço
  • He means patching.
    Of course you can replace it entirely.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • evanhevanh Posts: 7,522
    edited 2019-01-18 - 15:05:07
    because it sits in hubRAM, unlike the Prop1.

    The physical ROM storage is not executable, there is a special few hardwired instructions, in cog0 only, that copy it into hubRAM on power up ... Or something like that.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanh wrote: »
    because it sits in hubRAM, unlike the Prop1.

    The physical ROM storage is not executable, there is a special few hardwired instructions, in cog0 only, that copy it into hubRAM on power up ... Or something like that.
    Ah, I see. So, he only altered the copy in RAM (which is a feat by itself). I was finding strange that you could change the ROM (because after all it could be an EEPROM). It the ROM could be altered, that could render the P2 unusable.

    Kind regards, Samuel Lourenço
  • Cluso99 wrote: »
    He means patching.
    Of course you can replace it entirely.

    No by hijacking I meant using the build in ROM (especially TAQOZ, but also the MONITOR) by talking to it as serial device on some other pins then 63/62.

    The goal here is to be able to 'program' TAQOZ from say SPIN or BASIC or Assembler or C by using it as serial device (supported by all languages) sending TAQOZ one liners to the serial port and receiving results via serial port. Just like using it now from a Terminal, but have your program type the commands and read the response.


    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    Cluso99 wrote: »
    He means patching.
    Of course you can replace it entirely.

    No by hijacking I meant using the build in ROM (especially TAQOZ, but also the MONITOR) by talking to it as serial device on some other pins then 63/62.

    The goal here is to be able to 'program' TAQOZ from say SPIN or BASIC or Assembler or C by using it as serial device (supported by all languages) sending TAQOZ one liners to the serial port and receiving results via serial port. Just like using it now from a Terminal, but have your program type the commands and read the response.


    Enjoy!

    Mike
    The Monitor can be patched for the serial pins. There are 10 instructions in the ROM requiring this.

    AFAIK TAQOZ probably cannot be easily patched as the next version will be compressed. While it would be nice to feed one-liners to TAQOZ I don't know if this is possible. Peter?
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • evanh wrote: »
    I've just had a nosy at the ROM source and didn't find any obvious jump entry, even one way, to TaqOz.

    Cluso's monitor I think is meant to have callable subroutines but I haven't noticed any stickied links to documentation.

    Here it is in the EVAL rom
    _START_TAQOZ = $FD028

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • I posted lots of sample code calling my ROM Monitor. They are old threads from ~2017 but they are still valid. The only change from the ES chips to the new chips due shortly is the SD boot section was heavily tweeked.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • msrobots wrote: »
    Here it is in the EVAL rom
    _START_TAQOZ = $FD028
    Is that a fixed address in a jump table? If not, then the next revision will be a different address.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanh wrote: »
    msrobots wrote: »
    Here it is in the EVAL rom
    _START_TAQOZ = $FD028
    Is that a fixed address in a jump table? If not, then the next revision will be a different address.

    No jump table, fixed rom address one for eval, one for rev2. The monitor calls seem to be at the same place in rev2 but TAQOZ is different, can't test it, have no FPGA.

    Fore sure my patches will not work anymore and the new TAQOZ in the new rom is compressed and gets deflated at startup, so patching the rom might not be a option anymore.

    It is maybe possible to start TAQOZ from rom, kill the COG, patch the lower ram and start TAQOZ again.

    If not then the only solution would be to include some 'embedded' Version of TAQOZ into other programs, making TAQOZ in rom fairly useless. Those who want TACHYON/TAQOZ will boot a full blown version and the rom version does not cooperate with other languages.

    All monitor functions of @Cluso99 are callable from HUBexec and work pretty nice, so we have some BIOS in the rom, TAQOZ is not made for that.

    But it is RAM so one can patch it. My goal here is to use the rom version somehow to have a fixed starting point, TAQOZ itself is a moving target, the rom code is fixed.

    I am thinking about the possibility to set the smartpin using usb tx to something like A or B so I could send some initial commands to TAQOZ from some other pin while TX pin is still connected to USB, A or B might work maybe !A or B.

    Then I could start TAQOZ from rom, send some initial script to switch it to a mailbox (Peter gave me a example) and proceed from there to send more commands to disable TAQOZ access to the serial ports.

    My understanding of FORTH is that one can redefine words so one can not just add a new I/O handler for the mailbox, but replace the existing CON thru the mailbox. Like @Peter Jakacki I am quite stubborn, so I will try to make some use out of the rom version.

    I will try that next with the EV, that would make the patching of the rom un-needed since I would start my program in COG1 leaving the first 64K free, and start TAQOZ like it is in rom in COG0.

    Then hijack the TX smartpin to accept USB (A input) and me from some nearby pin (B input), TAQOZ does not need to know about it. Then send some magical TAQOZ definitions and go from there...

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • I was vaguely thinking of having my test runs end by jumping to TaqOz. No plans for what to use it for so no biggie.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Peter JakackiPeter Jakacki Posts: 8,514
    edited 2019-07-15 - 00:41:47
    Here is the source code for the P2ES ROM if you really must try to patch it although I am updating the RAM version to make any cog running TAQOZ easy to talk to via a mailbox.

    In the P2ES ROM you could patch two vectors to point to a mailbox routine and then simply MUTE the serial pins which will disable their smartpin functionality.
    ----------------------------------------------------------------
      Parallax P2  .:.:--TAQOZ--:.:.  V1.0--142          180530-0135
    ----------------------------------------------------------------
    TAQOZ# uemit .L $0000_FE10 ok
    TAQOZ# ukey .L $0000_FE12 ok
    

    This kills the serial port and release P63 and P62.
    TAQOZ# 63 PIN MUTE 62 PIN MUTE
    

    These are the entry points which you can see in the listing file. BTW, the spin2 and list file are generated by my M4 preprocessor which takes Chip and Cluso99's source and all the TAQOZ files and generates a spin2 file. Thanks to p2asm I am also able to generate a listing.
    fd028                              orgh
    fd028              		alignw
                       
                       ''-------[ Start TAQOZ ]----------------------------------------------------- <--- start TAQOZr --->
    fd028     fdbffa4c _Start_TAQOZ    call    #@_reset_booter                 ' reset the booters interrupts and autobaud
                       
    fd02c              _Enter_TAQOZ
                       ''---------------------------------------------------------------------------------------------------
                       
                       
    fd02c     fedfefd0                 loc     PTRA,#_hubrom           ' copy all of ROM to low 64K'
    fd030     fef0efcc                 loc     PTRB,#$C000
    fd034     ff000008                 rep     #2,##$1000
    fd038     fcdc0400 
    fd03c     fb041761                 rdlong  fx,PTRA++
    fd040     fc6417e1                 wrlong  fx,PTRB++
    

    Confirm this is correct:
    TAQOZ# $FD02C $40 DUMPL 
    000F_D02C: FEDF_EFD0 FEF0_EFCC FF00_0008 FCDC_0400     '................'
    000F_D03C: FB04_1761 FC64_17E1 FF00_07F6 FCEC_0164     'a.....d.....d...'
    000F_D04C: 0000_000A 6B9A_B1A7 2032_3431 FEAE_F820     '.......k142  ...'
    000F_D05C: FC06_00E0 F80A_0073 FC02_00B5 F80D_0069     '....s.......i...' ok
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • Does this also prevent 'lsio' to re-attach the smart pins to TAQOZ?

    I am off work in a couple of hours and can try...

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    Does this also prevent 'lsio' to re-attach the smart pins to TAQOZ?

    I am off work in a couple of hours and can try...

    Mike

    lsio is really meant as a quick hardware check but obviously if you have setup some pins as smartpins then lsio will be releasing the dir bit afterwards leaving them in reset. So lsio is normally used when you enter TAQOZ and want to check the state of your hardware quickly. If you have an NPN connected to a pin then it should show up as a pull-down as should an LED to ground etc.
    TAQOZ# lsio 
    P:00000000001111111111222222222233333333334444444444555555555566
    P:01234567890123456789012345678901234567890123456789012345678901
    =:dddddhhh~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~h ok
    TAQOZ# 16 PIN 1 MHZ  ok
    TAQOZ# lsio 
    P:00000000001111111111222222222233333333334444444444555555555566
    P:01234567890123456789012345678901234567890123456789012345678901
    =:dddddhhh~~~~~~~~d~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~h ok
    

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • I adjusted the SD code to ensure the MONITOR remained at the same addresses. SD calls however did move :( from the ES to the next silicon.
    There was no rom space for a jump table for entry points.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • msrobotsmsrobots Posts: 2,819
    edited 2019-07-18 - 22:38:54
    I was mailing with @MJB and he brought another aspect into it, as so often I might make things way to complicated on the first try.

    One can modify a TAQOZ add a mailbox substract CON so TAQOZ leaves serial alone and save it to SD. Voila there is the block we need to include from 0-64K.

    Besides adding Mailbox and subtracting serial it would just need to start COG1 at $10000.

    This would not be doable with the ROM TAQOZ but with newer versions of TAQOZ. @Peter Jakacki wrote that he will it make more easy to use a TAQOZ COG via mailbox.

    Including that with FastSpin might be quite trivial, after compiling you have the PASM source and modify it to include the TAQOZ binary with file:... and change ORGH to $10000 for FastSpin code like in my first post.

    Then compile and run changed PASM with fastspin and run.

    I need to try if that works.

    This might need some workaround with clockset in fastspin and TAQOZ but both agree about the same locations in HUB for that.

    weekend is coming...

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    Including that with FastSpin might be quite trivial, after compiling you have the PASM source and modify it to include the TAQOZ binary with file:... and change ORGH to $10000 for FastSpin code like in my first post.

    fastspin also has a "-H" address for setting the starting address, and a -E flag for saying it isn't the first thing to run. So if you give fastspin "-H 0x10000 -E" then it will output a binary program that can be loaded at address $10000 and run from there. I suspect TAQOZ has a way to load a binary file into memory and to jump to PASM code.
  • ersmith wrote: »
    msrobots wrote: »
    Including that with FastSpin might be quite trivial, after compiling you have the PASM source and modify it to include the TAQOZ binary with file:... and change ORGH to $10000 for FastSpin code like in my first post.

    fastspin also has a "-H" address for setting the starting address, and a -E flag for saying it isn't the first thing to run. So if you give fastspin "-H 0x10000 -E" then it will output a binary program that can be loaded at address $10000 and run from there. I suspect TAQOZ has a way to load a binary file into memory and to jump to PASM code.

    Oh cool, I wanted to ask you that.

    My idea is to integrate TAQOZ into FastSpin as a Object usable like other objects from all supported languages. That would be the Spin-Stub talking to the PASM COG of TAQOZ via Mailbox. Could use you std-serial routines.

    I would like to stay in the Spin2Gui workflow but this seems not to be to farfetched.

    something like
    CON 
     COG0START = $0
     HUBSTART = $10000 
    
    OBJ
     TAQOZ = "taqozstub.spin"
    
    DAT
     ORGH 0
     ORG 0
     file: "taqoz64K.binary"
    
    PUB main
    ...
    
    would allow to start the included binary (and the binary running in COG0 needs to start Spin (whatever) at $10000 in some COG
    CON 
     COG0START = $10000
     HUBSTART = $10000 
    
    DAT
     ORGH 0
     ORG 0
     file: "64K.binary"
    
    PUB main
    ...
    
    would include the binary and still start Spin(whatever) as usual.

    My primary goal is TAQOZ here and the reserved location in lower HUB for clock settings are the same so TAQOZ and FastSpin will work fine and TAQOZ and Prop2gcc should work also.

    that would be awesome, and the pieces seem to be there...

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Oh @ersmith, you have included a brute force linker! LOOK:
    DAT
    	ORGH	0
    	ORG	0
    	file 	"TQ_Blink56.binary"
    	ORGF	@10000
    	ORG	0
    	file 	"TQ_Blink57.binary"
    

    compiles, creates the correct combined binary, perfect. Compile and run works also.

    "TQ_Blink56.binary" was created without -H xx -E, just standard - supposed to be TAQOZ - starts a COG at $10000 and then blinks pin 56
    "TQ_Blink57.binary" was created with -H 0x010000 -E - supposed to be main program - starts at $10000 - blinks pin 57

    And it runs. Just hilarious.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • to happy to early, but this should work...

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Sweet! Easy peasy overlays. (In addition to the things you are looking to do)
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Taqoz could also be compiled with Fastspin.

    IMHO Fastspin should become the standard compiler for P2. Eric has done a superb job here :smiley:
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Taqoz could also be compiled with Fastspin.

    IMHO Fastspin should become the standard compiler for P2. Eric has done a superb job here :smiley:

    yes
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobotsmsrobots Posts: 2,819
    edited 2019-07-20 - 01:49:29
    After looking at my generated lst file it dawned on me where my error is

    here TQ_Blink56.spin2 - this simulates TAQOZ starting my own program in COG1
    con
      pin = 56
      freq = 160_000_000
      mode = $010007f8
      delay = freq / 10
    
    pub demo
      clkset(mode, freq)
      cognew($10000,0)
      dirb[pin-32] := 1
      repeat
        !outb[pin-32]
        waitcnt(cnt + delay)
    
    here TQ_Blink57.spin2 - the main fastspin program - needs to be compiled with -H 0x10000 -E
    con
      pin = 57
      freq = 160_000_000
      mode = $010007f8
      delay = freq / 10
    
    pub demo
      clkset(mode, freq)
      dirb[pin-32] := 1
      repeat
        !outb[pin-32]
        waitcnt(cnt + delay)
    
    here the correct TQ_link.spin2
    DAT
    	ORGH	0
    	ORG	0
    	file 	"TQ_Blink56.binary"
    	ORGF	$10000/4
    	ORG	0
    	file 	"TQ_Blink57.binary"
    

    for reasons I do not understand ORGF $10000 is filling the HUB up to $40000.

    Now both COGs are blinking.

    attached are 3 files

    TQ_Blink56.spin2 simulates a TAQOZ binary and starts a COG at HUB $10000 then blinks Pin56 - this is compiled as usual without -H 0x10000 -E to create the TQ_Blink56.binary.
    TQ_Blink57.spin2 is my main FastSpin Program it just blinks P57 - this needs to be compiled with -H 0x10000 -E to create the TQ_Blink57.binary
    TQ_link.spin2 is the program to compile and run, it combines the created binaries into one runnable binary - this is compiled as usual without -H 0x10000 -E

    Next step is to create a TAQOZ binary that uses a mailbox, not serial.

    Enjoy

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    for reasons I do not understand ORGF $10000 is filling the HUB up to $40000.
    ORGF is for COG memory (so it uses COG addresses).

    To just fill HUB memory up to $10000 use "ORGH $10000".

  • msrobotsmsrobots Posts: 2,819
    edited 2019-07-20 - 01:48:30
    OK, makes sense.

    it is kind of booring to switch the spin2gui command from with -H 0X10000 -E to without -H 0x10000 -E. Would there be any chance to define -H xxx -E in the source file?

    just asking...

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • so I spend the last 3 hours searching for a error sitting right in front of the screen.

    it has to be -H 0x10000 not - H $10000

    gosh. Those who can READ have really a advantage...

    will change the posts

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.