Hijacking the P2-EVAL ROM (now hijacking current TAQOZ)
msrobots
Posts: 3,709
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
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
Now Larson runs on COG1 and TAQOZ on COG0 using USB to PC.
that made me interested, so I dug in deeper...
Mike
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
Comments
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 really like the work you did with the Monitor and serial routines. The TAQOZ part is less understandable...
Mike
What did you mean by hijacking? Did you manage to rewrite the ROM?
Kind regards, Samuel Lourenço
Of course you can replace it entirely.
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.
Kind regards, Samuel Lourenço
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
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?
Here it is in the EVAL rom
_START_TAQOZ = $FD028
Mike
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
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.
This kills the serial port and release P63 and P62.
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:
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.
There was no rom space for a jump table for entry points.
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
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 would allow to start the included binary (and the binary running in COG0 needs to start Spin (whatever) at $10000 in some COG 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
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
Mike
IMHO Fastspin should become the standard compiler for P2. Eric has done a superb job here
yes
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 -Econ 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.spin2for 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
To just fill HUB memory up to $10000 use "ORGH $10000".
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
it has to be -H 0x10000 not - H $10000
gosh. Those who can READ have really a advantage...
will change the posts
Mike