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?
I don't think that's a good idea, because in general you might want to use the same source file at different offsets (that is, for most source files it doesn't matter what hub address you compile and link at).
I'd suggest writing a small batch file or Makefile to automate the build and get rid of the need to switch flags.
The workflow in Spin2Gui is a bit unusual but doable, and as @ersmith pointed out solvable with some batch file.
Where I am at now? I should change the thread title, because I am not hijacking the rom anymore, I am directly hijacking the newest RAM version of @"Peter Jakacki"'s TAQOZ, right out of his dropbox.
With some creative thinking Spin2Gui/FastSpin can combine your FastSpin program and a TAQOZ-driver, much alike to a serial connection to TAQOZ.
here it is in its simplest form
'
' TQ_driver.spin2
' simple driver for TAQOZ Mailbox
' implements a subset of FullDuplexSerial functionality
'
CON
_MAILBOXIN = $10000
_MAILBOXOUT = $10002
PUB tx(val)
rxflush
txflush
WORD[_MAILBOXIN] := (val & $FF)
txflush
rxwait(1000)
PUB txflush
repeat while WORD[_MAILBOXIN] <> 0
' check if byte received (never waits)
' returns -1 if no byte, otherwise byte
PUB rxcheck : rxbyte | rxtest
rxbyte := -1
rxtest := WORD[_MAILBOXOUT]
if rxtest > 0
rxbyte := rxtest & $FF
WORD[_MAILBOXOUT] := 0
' receive a byte (waits until one ready)
PUB rx : v
v := -1
repeat
v := rxcheck
while v == -1
PUB rxwait(count) : v | w
v := -1
w := count
repeat
v := rxcheck
w--
until (w < 0) or (v>-1)
PUB rxflush : v
v := 0
repeat
v := rxwait(1000)
until v == -1
'' provide the usual str(), dec(), etc. routines
#include "std_text_routines.spinh"
using it looks like this
'
' TQ_Test.spin2
' compile with -H 0x10004 -E
'
CON
oscmode = $010c3f04
freq = 160_000_000
baud = 115_200
OBJ
ser: "FullDuplexSerial2.spin"
tqz: "TQ_driver.spin2"
PUB demo | c
clkset(oscmode, freq)
ser.start(63, 62, 0, baud)
'displayResponse
ser.printf("\nswitching to_clkmode %x _clkfreq %d - %dMhz\n", _clkmode, _clkfreq, _clkfreq/1000000)
repeat
ser.str(@menu)
'ser.write(@menu, @entrynotvalid-@menu-1)
c := ser.rx
case c
49 : tqz.str(string("56 BLINK",13))
tqz.rxflush
50 : tqz.str(string("56 PIN MUTE",13))
tqz.rxflush
51 : tqz.str(string("57 BLINK",13))
tqz.rxflush
52 : tqz.str(string("57 PIN MUTE",13))
tqz.rxflush
53 : tqz.str(string("2 3 + .",13))
displayResponse
other : ser.str(@entrynotvalid)
PUB displayResponse | c
repeat 30000
if (c:=tqz.rxcheck)>-1
ser.tx(c)
DAT
menu
byte 13,10
byte "1 Test 1 - send 56 BLINK - FLUSH RESPONSE",13,10
byte "2 Test 2 - send 56 PIN MUTE - FLUSH RESPONSE",13,10
byte "3 Test 3 - send 57 BLINK - FLUSH RESPONSE",13,10
byte "4 Test 4 - send 57 PIN MUTE - FLUSH RESPONSE",13,10
byte "5 Test 5 - send 2 3 + . - DISPLAY RESPONSE",13,10,0
entrynotvalid
byte 13,10
byte "Entry not valid, try 1-5",13,10
byte 0
and linking it with TAQOZ looks like this
DAT
ORGH 0
ORG 0
file "_BOOT_P2.BIX"
ORGH $10004 ' $10000 is Mailbox between TAQOZ and Rest of Program
ORG 0
file "TQ_Test.binary"
I attach a binary to make it easy. You need to set your terminal to 115200 because the currently used TAQOZ image is set to that baudrate.
After starting you end up in a TAQOZ-session and have to copy and paste this (including the last, empty line) into the TAQOZ prompt.
I am pretty sure I will find out how to save a changed TAQOZ back to a binary, so that the copy and paste step is not needed anymore and the serial baudrate can be what your FastSpin program wants.
Ha, thanks to the help of the magic man living down under I was able to save a changed version of TAQOZ as binary, Now the copy part is not needed anymore.
Still at 115200 baud Terminal, working on that one.
I need to go through and re-read this entire thread but I thought I'd share what I spent a couple hours working on today. Because the ROM respin, the rom will not be identical in all chips so a jump table is needed. I've been trying to go through cluso's debugger and sd code and compiling a jump table with documentation. The formatting isn't perfect and there's a lot of info missing IMHO. I'd really like to know all the variables used, functions called, but it's a start.
Cluso's SD Boot
CON SD_Jump_Table
''+-------------------------------------------------------------------------------------------------------------+
''| Cluso's SD BOOT for P2 (c)2013-2018 "Cluso99" (Ray Rodrick) |
''+-------------------------------------------------------------------------------------------------------------+
''+=============================================================================================================+
_Start_SDcard = $FC560 '' jumps to serial
_Run_SDfile = $FC578 '
_Load_SDfile = $FC590 '
''+-------------------------------------------------------------------------------------------------------------+
''+ SD: Initialise/Locate/Load/Run a file from SD +
''+-------------------------------------------------------------------------------------------------------------+
''+ On Entry: +
''+ fname[3]: filename[11] 8+3 without "." (will be $0 terminated) +
''+-------------------------------------------------------------------------------------------------------------+
''+ Call Format: +
''+ CALL #@_Run_SDfile ' +
''+-------------------------------------------------------------------------------------------------------------+
''+ On Return: +
''+ "NZ" if error, else does not return +
''+ +
''+=============================================================================================================+
I'm not sure about the calls and there's probably lots of errors but I figured I'd start this. There's lots of code in the ROM that looks really useful. Stuff I have spin libraries for but I'm sure the PASM debugger code will be much faster.
I'm going to try to use the SD code for a safe version of FSRW. There might be times when the DI,CLK,DO isn't within smartpin reach so it would be really nice to hand over to the ROM code since it will be much faster than my inline asm bit-bashing.
ROM Monitor/Debugger (includes Serial Driver)
There is no change for between the ES (first version chip 2018) and the respin version (current Aug 2019). All entry points, cog ram variables ($1E0-$1EF) and PASM code and addresses are unchanged.
The Monitor/Debugger has an entry point that can be “called” from you program, and the monitor can return to you program when finished with.
Serial Routines are provided for...
Initialising the serial driver using pins P63(in) and P62(out)
Output...
Text characters (up to 4 characters can be passed in lmm_x, the lowest byte is sent first. A single $00 can be sent if lmm_x is all $0.
Text Strings, $0 terminated (must be in hub)
CRLF
Hex - long with options for the number of bytes, print as byte pairs with spaces, and reverse (change endian)
List blocks from CCOG, LUT or HUB giving start address and optional end address. The list includes both hex and ASCII.
Input...
Read character
Read string terminated with CR
Uses a default buffer at $FC000 (overwrites ROM boot code which is no longer required)
SD boot code
This code has changed between the ES and the respin versions !!!
Uses pins P61=CLK, P60=/CS, P59=DI(to SD), P58=DO(from SD). Warning: FLASH shares these pins where P61=/CS, P60=CLK.
The respin is much more robust. This code fixes the problem where the SD card software which drives the DO pin to the P2 input pin P58 fails to release the DO pin when CS returns high. IIRC there was one fix I wanted to apply but the code window was frozen - I’ll need to post this when I return home to Oz.
The timing is based on the RCFAST clock of ~22MHz. For this reason, timeouts will be slow when running at higher clock speeds.
The SPI code driving the SD interface is deliberately slow to ensure the most SD cards work, again at RCFAST. This is the Send/Receive routine, and it’s a common routine which sends as it receives (a concept I borrowed from one of the P1 SD drivers - sorry, I forget the author atm).
The SD code can be used as model code for any SD Driver. It just needs a faster Send/Recv routine which should be resident in COG or LUT for speed. It complies with all the known caveats that I could find. It’s just lacking the write commands which I stripped out so it would fit into the limited ROM space.
The SD driver requires COG $1C0-$1DF space for variables. The SD code does not require the variable space that is required by the Serial Monitor/Debugger unless you use the monitor routines (eg there is a parse filename routine).
IIRC the SD sector buffer is at HUB $0 although you can change the hub pointer to anywhere.
You can load or run a file (8+3) located in the root directory by passing the routine a file name in 8+3 format $0 terminated (3 longs).
Note: The source is heavily documented and includes calling conventions for each callable routine. All code runs in hubexec.
I've been going over the source for the rom and it is beautifully documented and very well written. I'm attempting to build a library, starting with the jump tables. I've spent so much time on formatting but hopefully this will prove helpful in the future, not just for myself but for others.
Major kudos to @Cluso99, @"Peter Jakacki" and Chip for the rom code. I've been through it several times and finally feel I'm starting to understand how to use it. The monitor seems really useful but I haven't really done anything other than open it. Still a bit above my head but I'm so glad it got included in ROM.
I'm really interested to get TaqOZ working with my hardware and there are great breadcrumbs in this thread.
Thanks @Cluso99 for being so helpful. I need to go through and finish formatting the constants. I believe the call format for will ALWAYS be CALL #_ParseHex since these are literal hub addresses. Trying to understand all the new parts of this chip and it's just overwhelming!
Great work again guys, can't wait till there's a a couple hundred more chips in the wild.
*edit - Things are looking much better. I think I'm close to something useable.
CON SD_Jump_Table
''##################################################################################
''+--------------------------------------------------------------------------------+
''| Cluso's SD BOOT for P2 (c)2013-2018 "Cluso99" (Ray Rodrick) |
''+--------------------------------------------------------------------------------+
''##################################################################################
''##################################################################################
''## REVa ROM JMP TABLE by cheezus slice - ####
''## from ROM source - all credit to original author ####
''##################################################################################
''## SD_Jump_Table - HUBEXEC code jmp table... ####
''##################################################################################
''+================================================================================+
_Start_SDcard = $FC560 '' jumps to serial
_Run_SDfile = $FC578 '' run file
_Load_SDfile = $FC590 '' load file
''+---------------------------------------------------------------------------------+
''+ SD: Initialise/Locate/Load/Run a file from SD +
''+---------------------------------------------------------------------------------+
''+ On Entry: +
''+ fname[3]: filename[11] 8+3 without "." (will be $0 terminated) +
''+---------------------------------------------------------------------------------+
''+ Call Format: +
''+ CALL #_Run_SDfile +
''+---------------------------------------------------------------------------------+
''+ On Return: +
''+ "NZ" if error, else does not return +
''+ +
''+=================================================================================+
''+---------------------------------------------------------------------------------+
''+=================================================================================+
_SDcard_Init = $FC5A4 '' SD Card Initialisation
''+---------------------------------------------------------------------------------+
''+ SD Card Initialisation +
''+---------------------------------------------------------------------------------+
''+ On Entry: +
''+---------------------------------------------------------------------------------+
''+ Call Format: +
''+ CALL #_SDcard_Init +
''+---------------------------------------------------------------------------------+
''+ On Return: +
''+ hub $0 = CSD[16] + CID[16] csd/cid data +
''+ Returns "Z" if ok, "NZ" if error +
''+ '' move source instruction to change hub buffer alts? +
''+=================================================================================+
''+---------------------------------------------------------------------------------+
''+=================================================================================+
…
''+=================================================================================+
_recvlong = $fca30 '' call here to Recv a Long (+send 1's)
_sendlong = $fca34 '' call here to Send a Long (long=32bits)
_recvbyte = $fca3c '' call here to Recv a Byte (+send 1's)
_sendbyte = $fca40 '' call here to Send a Byte (msbit first)
''+---------------------------------------------------------------------------------+
''+ SD SPI Send/Recv Routines... (write/read byte/long simultaneously) +
''+ /CS=0 & CLK=0 on both entry and exit +
''+---------------------------------------------------------------------------------+
''+ On Entry: +
''+ dataout = data to send +
''+---------------------------------------------------------------------------------+
''+ Call Format: +
''+ CALL #_recvlong ' +
''+ CALL #_sendlong ' +
''+ CALL #_recvbyte ' +
''+ CALL #_sendbyte ' +
''+---------------------------------------------------------------------------------+
''+ On Return: +
''+ reply = data read +
'' +
''+=================================================================================+
''+---------------------------------------------------------------------------------+
''+=================================================================================+
I like calling the monitor routines from any code that I’m debugging. It’s great to just print a variable(s) along the way, or list a block of variables, or a buffer. It’s just a couple of calls.
Note that the variables lmm_x and lmm_f are returned unchanged by the calls, so if you want to print a line of “-“ just load lmm_x and then repeat call @_hubTx “n” times, and then call @_hubTxCR.
See my usage examples for how to load lmm_f.
eg mov lmm_f,#_hex_+_rev_+_space_+6
to set hex mode, reverse bytes, print in pairs, and 6 bytes for the long in lmm_x
BTW the lmm_ prefix backdates from when I wrote a monitor for the original P2 using lmm mode which was how we wrote code to run from hub before hubexec.
Comments
I don't think that's a good idea, because in general you might want to use the same source file at different offsets (that is, for most source files it doesn't matter what hub address you compile and link at).
I'd suggest writing a small batch file or Makefile to automate the build and get rid of the need to switch flags.
The workflow in Spin2Gui is a bit unusual but doable, and as @ersmith pointed out solvable with some batch file.
Where I am at now? I should change the thread title, because I am not hijacking the rom anymore, I am directly hijacking the newest RAM version of @"Peter Jakacki"'s TAQOZ, right out of his dropbox.
With some creative thinking Spin2Gui/FastSpin can combine your FastSpin program and a TAQOZ-driver, much alike to a serial connection to TAQOZ.
here it is in its simplest form
' ' TQ_driver.spin2 ' simple driver for TAQOZ Mailbox ' implements a subset of FullDuplexSerial functionality ' CON _MAILBOXIN = $10000 _MAILBOXOUT = $10002 PUB tx(val) rxflush txflush WORD[_MAILBOXIN] := (val & $FF) txflush rxwait(1000) PUB txflush repeat while WORD[_MAILBOXIN] <> 0 ' check if byte received (never waits) ' returns -1 if no byte, otherwise byte PUB rxcheck : rxbyte | rxtest rxbyte := -1 rxtest := WORD[_MAILBOXOUT] if rxtest > 0 rxbyte := rxtest & $FF WORD[_MAILBOXOUT] := 0 ' receive a byte (waits until one ready) PUB rx : v v := -1 repeat v := rxcheck while v == -1 PUB rxwait(count) : v | w v := -1 w := count repeat v := rxcheck w-- until (w < 0) or (v>-1) PUB rxflush : v v := 0 repeat v := rxwait(1000) until v == -1 '' provide the usual str(), dec(), etc. routines #include "std_text_routines.spinh"using it looks like this' ' TQ_Test.spin2 ' compile with -H 0x10004 -E ' CON oscmode = $010c3f04 freq = 160_000_000 baud = 115_200 OBJ ser: "FullDuplexSerial2.spin" tqz: "TQ_driver.spin2" PUB demo | c clkset(oscmode, freq) ser.start(63, 62, 0, baud) 'displayResponse ser.printf("\nswitching to_clkmode %x _clkfreq %d - %dMhz\n", _clkmode, _clkfreq, _clkfreq/1000000) repeat ser.str(@menu) 'ser.write(@menu, @entrynotvalid-@menu-1) c := ser.rx case c 49 : tqz.str(string("56 BLINK",13)) tqz.rxflush 50 : tqz.str(string("56 PIN MUTE",13)) tqz.rxflush 51 : tqz.str(string("57 BLINK",13)) tqz.rxflush 52 : tqz.str(string("57 PIN MUTE",13)) tqz.rxflush 53 : tqz.str(string("2 3 + .",13)) displayResponse other : ser.str(@entrynotvalid) PUB displayResponse | c repeat 30000 if (c:=tqz.rxcheck)>-1 ser.tx(c) DAT menu byte 13,10 byte "1 Test 1 - send 56 BLINK - FLUSH RESPONSE",13,10 byte "2 Test 2 - send 56 PIN MUTE - FLUSH RESPONSE",13,10 byte "3 Test 3 - send 57 BLINK - FLUSH RESPONSE",13,10 byte "4 Test 4 - send 57 PIN MUTE - FLUSH RESPONSE",13,10 byte "5 Test 5 - send 2 3 + . - DISPLAY RESPONSE",13,10,0 entrynotvalid byte 13,10 byte "Entry not valid, try 1-5",13,10 byte 0and linking it with TAQOZ looks like this I attach a binary to make it easy. You need to set your terminal to 115200 because the currently used TAQOZ image is set to that baudrate.After starting you end up in a TAQOZ-session and have to copy and paste this (including the last, empty line) into the TAQOZ prompt.
I am pretty sure I will find out how to save a changed TAQOZ back to a binary, so that the copy and paste step is not needed anymore and the serial baudrate can be what your FastSpin program wants.
Anyways, almost there!
Mike
Still at 115200 baud Terminal, working on that one.
attached above demo
Mike
Sadly the TAQOZ image still sends its start screen at 115_200, so some garbage at start.
attached demo works with P2default settings in Spin2Gui. Just load and run binary. Terminal at 230_400
Enjoy!
Mike
Cluso's SD Boot
CON SD_Jump_Table ''+-------------------------------------------------------------------------------------------------------------+ ''| Cluso's SD BOOT for P2 (c)2013-2018 "Cluso99" (Ray Rodrick) | ''+-------------------------------------------------------------------------------------------------------------+ ''+=============================================================================================================+ _Start_SDcard = $FC560 '' jumps to serial _Run_SDfile = $FC578 ' _Load_SDfile = $FC590 ' ''+-------------------------------------------------------------------------------------------------------------+ ''+ SD: Initialise/Locate/Load/Run a file from SD + ''+-------------------------------------------------------------------------------------------------------------+ ''+ On Entry: + ''+ fname[3]: filename[11] 8+3 without "." (will be $0 terminated) + ''+-------------------------------------------------------------------------------------------------------------+ ''+ Call Format: + ''+ CALL #@_Run_SDfile ' + ''+-------------------------------------------------------------------------------------------------------------+ ''+ On Return: + ''+ "NZ" if error, else does not return + ''+ + ''+=============================================================================================================+Cluso's LMM Debugger
I'm not sure about the calls and there's probably lots of errors but I figured I'd start this. There's lots of code in the ROM that looks really useful. Stuff I have spin libraries for but I'm sure the PASM debugger code will be much faster.
I'm going to try to use the SD code for a safe version of FSRW. There might be times when the DI,CLK,DO isn't within smartpin reach so it would be really nice to hand over to the ROM code since it will be much faster than my inline asm bit-bashing.
There is no change for between the ES (first version chip 2018) and the respin version (current Aug 2019). All entry points, cog ram variables ($1E0-$1EF) and PASM code and addresses are unchanged.
The Monitor/Debugger has an entry point that can be “called” from you program, and the monitor can return to you program when finished with.
Serial Routines are provided for...
Initialising the serial driver using pins P63(in) and P62(out)
Output...
Text characters (up to 4 characters can be passed in lmm_x, the lowest byte is sent first. A single $00 can be sent if lmm_x is all $0.
Text Strings, $0 terminated (must be in hub)
CRLF
Hex - long with options for the number of bytes, print as byte pairs with spaces, and reverse (change endian)
List blocks from CCOG, LUT or HUB giving start address and optional end address. The list includes both hex and ASCII.
Input...
Read character
Read string terminated with CR
Uses a default buffer at $FC000 (overwrites ROM boot code which is no longer required)
SD boot code
This code has changed between the ES and the respin versions !!!
Uses pins P61=CLK, P60=/CS, P59=DI(to SD), P58=DO(from SD). Warning: FLASH shares these pins where P61=/CS, P60=CLK.
The respin is much more robust. This code fixes the problem where the SD card software which drives the DO pin to the P2 input pin P58 fails to release the DO pin when CS returns high. IIRC there was one fix I wanted to apply but the code window was frozen - I’ll need to post this when I return home to Oz.
The timing is based on the RCFAST clock of ~22MHz. For this reason, timeouts will be slow when running at higher clock speeds.
The SPI code driving the SD interface is deliberately slow to ensure the most SD cards work, again at RCFAST. This is the Send/Receive routine, and it’s a common routine which sends as it receives (a concept I borrowed from one of the P1 SD drivers - sorry, I forget the author atm).
The SD code can be used as model code for any SD Driver. It just needs a faster Send/Recv routine which should be resident in COG or LUT for speed. It complies with all the known caveats that I could find. It’s just lacking the write commands which I stripped out so it would fit into the limited ROM space.
The SD driver requires COG $1C0-$1DF space for variables. The SD code does not require the variable space that is required by the Serial Monitor/Debugger unless you use the monitor routines (eg there is a parse filename routine).
IIRC the SD sector buffer is at HUB $0 although you can change the hub pointer to anywhere.
You can load or run a file (8+3) located in the root directory by passing the routine a file name in 8+3 format $0 terminated (3 longs).
Note: The source is heavily documented and includes calling conventions for each callable routine. All code runs in hubexec.
Major kudos to @Cluso99, @"Peter Jakacki" and Chip for the rom code. I've been through it several times and finally feel I'm starting to understand how to use it. The monitor seems really useful but I haven't really done anything other than open it. Still a bit above my head but I'm so glad it got included in ROM.
I'm really interested to get TaqOZ working with my hardware and there are great breadcrumbs in this thread.
Thanks @Cluso99 for being so helpful. I need to go through and finish formatting the constants. I believe the call format for will ALWAYS be CALL #_ParseHex since these are literal hub addresses. Trying to understand all the new parts of this chip and it's just overwhelming!
Great work again guys, can't wait till there's a a couple hundred more chips in the wild.
*edit - Things are looking much better. I think I'm close to something useable.
CON SD_Jump_Table ''################################################################################## ''+--------------------------------------------------------------------------------+ ''| Cluso's SD BOOT for P2 (c)2013-2018 "Cluso99" (Ray Rodrick) | ''+--------------------------------------------------------------------------------+ ''################################################################################## ''################################################################################## ''## REVa ROM JMP TABLE by cheezus slice - #### ''## from ROM source - all credit to original author #### ''################################################################################## ''## SD_Jump_Table - HUBEXEC code jmp table... #### ''################################################################################## ''+================================================================================+ _Start_SDcard = $FC560 '' jumps to serial _Run_SDfile = $FC578 '' run file _Load_SDfile = $FC590 '' load file ''+---------------------------------------------------------------------------------+ ''+ SD: Initialise/Locate/Load/Run a file from SD + ''+---------------------------------------------------------------------------------+ ''+ On Entry: + ''+ fname[3]: filename[11] 8+3 without "." (will be $0 terminated) + ''+---------------------------------------------------------------------------------+ ''+ Call Format: + ''+ CALL #_Run_SDfile + ''+---------------------------------------------------------------------------------+ ''+ On Return: + ''+ "NZ" if error, else does not return + ''+ + ''+=================================================================================+ ''+---------------------------------------------------------------------------------+ ''+=================================================================================+ _SDcard_Init = $FC5A4 '' SD Card Initialisation ''+---------------------------------------------------------------------------------+ ''+ SD Card Initialisation + ''+---------------------------------------------------------------------------------+ ''+ On Entry: + ''+---------------------------------------------------------------------------------+ ''+ Call Format: + ''+ CALL #_SDcard_Init + ''+---------------------------------------------------------------------------------+ ''+ On Return: + ''+ hub $0 = CSD[16] + CID[16] csd/cid data + ''+ Returns "Z" if ok, "NZ" if error + ''+ '' move source instruction to change hub buffer alts? + ''+=================================================================================+ ''+---------------------------------------------------------------------------------+ ''+=================================================================================+ … ''+=================================================================================+ _recvlong = $fca30 '' call here to Recv a Long (+send 1's) _sendlong = $fca34 '' call here to Send a Long (long=32bits) _recvbyte = $fca3c '' call here to Recv a Byte (+send 1's) _sendbyte = $fca40 '' call here to Send a Byte (msbit first) ''+---------------------------------------------------------------------------------+ ''+ SD SPI Send/Recv Routines... (write/read byte/long simultaneously) + ''+ /CS=0 & CLK=0 on both entry and exit + ''+---------------------------------------------------------------------------------+ ''+ On Entry: + ''+ dataout = data to send + ''+---------------------------------------------------------------------------------+ ''+ Call Format: + ''+ CALL #_recvlong ' + ''+ CALL #_sendlong ' + ''+ CALL #_recvbyte ' + ''+ CALL #_sendbyte ' + ''+---------------------------------------------------------------------------------+ ''+ On Return: + ''+ reply = data read + '' + ''+=================================================================================+ ''+---------------------------------------------------------------------------------+ ''+=================================================================================+Note that the variables lmm_x and lmm_f are returned unchanged by the calls, so if you want to print a line of “-“ just load lmm_x and then repeat call @_hubTx “n” times, and then call @_hubTxCR.
See my usage examples for how to load lmm_f.
eg mov lmm_f,#_hex_+_rev_+_space_+6
to set hex mode, reverse bytes, print in pairs, and 6 bytes for the long in lmm_x
BTW the lmm_ prefix backdates from when I wrote a monitor for the original P2 using lmm mode which was how we wrote code to run from hub before hubexec.
https://forums.parallax.com/discussion/comment/1474731#latest
Mike