P2 Monitor/Debug for possible inclusion in the ROM

Cluso99 · 2018-04-22 05:26

This is in case Peter cannot fit TAQOZ into the ROM.

The code runs in hub in hubexec mode and supports Serial I/O on P62&63 as well as various list commands that may be called from a users program.
I have detailed the output in previous thread(s).
https://forums.parallax.com/discussion/comment/1435968/#Comment_1435968

This code requires COG $1E0-$1EF for parameter passing to the hubexec code, and a further 128 bytes somewhere in hub ram for buffer and stack space. Currently this is a fixed location, but is intended to be set as a parameter when the serial code is initialised. The baud is already set by a passed parameter to _SerialInit. This will be a second parameter.

The following calls are supported...

_HubTx          transmit a serial character
_HubTxString    transmit a serial string, $0 terminated
_HubHex         transmit in hex
_HubList        list cog/lut/hub data

_HubRx          receive a serial character
_HubRxString    receive a serial string, <cr> terminated

_HubMonitor     call the monitor/debug with following command formats
[[#]xxxxxxxx] [-] [.yyyyy] [,[$]ccccc] z [m] <cr>

[xxxxxx] . [yyyyyy] L <cr>      List COG/LUT/HUB from addr1 to addr2
Q <cr>                           Return to user program
? <cr>                           Display help

WIP
[xxxxxx] - [xxxxxxxx] ... <cr>         Store to address with data...
  (will take paste of list output format)

To do (time permitting)
[xxxxxx] G <cr>                        Goto address
[xxxxxx] . [yyyyyy] , [ccccc] M<cr>    Move  COG/LUT/HUB from addr1 to addr2 for count
#[xxxxxxxx] . [yyyyyy] , [ccccc] M<cr> Fill  COG/LUT/HUB with data to addr2 for count

Attached is the code for testing.

Please don't ask for features as I don't have the time for discussion as the ROM closes Friday !!!

msrobots · 2018-04-22 15:55

nice, but eventually to late.

As far as I understood @chips posts the ROM had to be at OnSemi TODAY (22) and the ROM closed last Friday.

Mike

Dave Hein · 2018-04-22 17:53

On the 18th Chip posted

cgracey wrote: »

In the meantime, we have until next Friday to get the ROM together.

I interpret "next Friday" as the 27th. If he meant the 20th I think he would have said "this" instead of "next".

Cluso99 · 2018-04-22 18:36

I asked Chip a few posts later and he confirmed 27th.

I am waiting for him to finish with onsemi to finalise the SD Boot for the ROM.

BTW Is anyone actually testing the current P2 v32b code???

cgracey · 2018-04-23 04:06

Yes, we officially have until Friday to get the ROM done.

I am behind on the debug documentation. Is this needed for the ROM code?

cgracey · 2018-04-23 04:12

I have been thinking that because we have strict execution time limits on serial boot code, maybe we should have SD card booting not bother with serial booting. If the SD card is detected via the pull up, or pull down, we abandon the normal loading and attempt to boot from the SD. On failure, we could always go to TAQOZ. Then, we need to figure how to get into TAQOZ from the serial boot.

Cluso99 · 2018-04-23 04:20

cgracey wrote: »

I have been thinking that because we have strict execution time limits on serial boot code, maybe we should have SD card booting not bother with serial booting. If the SD card is detected via the pull up, or pull down, we abandon the normal loading and attempt to boot from the SD. On failure, we could always go to TAQOZ. Then, we need to figure how to get into TAQOZ from the serial boot.

Agreed.
The only other thought was to boot from serial and on another cog run either flash or sd boot. Whichever completed first would stop the other. But this is more complicated and with only days to go might not be worth the risk.

I am not sure where Peter is at with TAQOZ today. I spoke to him over the w/e. In case he's not ready i have been working on a Monitor/Debug that could go in its place.

Cluso99 · 2018-04-23 04:24

cgracey wrote: »

Yes, we officially have until Friday to get the ROM done.

I am behind on the debug documentation. Is this needed for the ROM code?

Not for me.

jmg · 2018-04-23 06:20

cgracey wrote: »

I have been thinking that because we have strict execution time limits on serial boot code, maybe we should have SD card booting not bother with serial booting. If the SD card is detected via the pull up, or pull down, we abandon the normal loading and attempt to boot from the SD..

The boot needs to have fast paths possible into each of UART, SPI, SD.
Fastest entry currently into serial is to continually send a repeating "> Prop_Chk 0 0 0 0 ", and wait for an echo (P2 out of reset) of CR+LF+“Prop_Ver Au”+CR+LF

Cluso99 · 2018-04-29 05:09

Here is an updated version of my proposed Monitor/Debugger v116a for P2-V32c

In the sample program (the cog section) this code will display a piece of code from cog, lut and hub.
Then the user is prompted to enter a string of text terminated with <cr>. <bs> works too, and the characters are echoed.

Next the user program calls the monitor program. Here are some strings to enter to try it out.
The "*" is a prompt character from the monitor.
Most spaces are optional (except in the download where spaces cause the write of the accumulated hex long to be written).

The download format is the same as that output by the "L" list command. pnut outputs with ascii but doesn't have a delimiter quote

I tried to cut and past a line in PST but PST doesn't like it

A terminal program would likely work fine.

* 000 . 010 L <cr>               list cog from $000 to $010
* 200 . 210 L <cr>               list lut from $200 to $210
* 00000 . 00020 L <cr>           list hub from $00000 to $00020
* 4000 . 4010 L <cr>             list hub from $4000 to $4010

*  000- 00 11 22 33 44 55 66 77  'xxxx' <cr>      download/store in cog $000 the hex characters
*00000- 00 11 22 33 44 55 66 77         <cr>      download/store in hub $00000 the hex characters (bytes)      

*4000 G <cr>                     Jump to hub $4000 (there is some code stored here for testing)
*000 G <cr>                      Jump to cog $000  (careful - there is test no code here to run)

* Q <cr>                         Quit back to the user program
* ? <cr>                         Display a help screen

Please check it works properly.
Please, no requests for added features!

Cluso99 · 2018-04-29 10:35

Oops! Would help to upload the code

evanh · 2018-05-02 02:28

Smartpin mode setting for async serial can be done with just # (short immediate) addressing mode. It's not much but an easy 8 bytes to be saved in _SerialInit routine.

Cluso99 · 2018-05-02 04:00

evanh,
Thanks, but I specifically didn't want to use smartpins in boot code.
It then has to be cleared down, and I didn't want this to be required.
This way, I don't have to worry about interrupts either.

I know Chip has used the smartpin in the boot code.

jmg · 2018-05-02 04:17

Cluso99 wrote: »

... I specifically didn't want to use smartpins in boot code.
It then has to be cleared down, and I didn't want this to be required.
This way, I don't have to worry about interrupts either.

I know Chip has used the smartpin in the boot code.

There are merits both ways. First generation boot loaders needed to be KISS, and so used SW baud.
That also means you have more control over a chip with possible HW faults.
However, Smart pins do allow higher boot baud rates, and that is important.
Smart pins are also now looking mature, with more testing hours on the clock, especially in serial mode...
OnSemi seem to be claiming a high chance of working silicon, and especially of Logic portions, so that risk appears to be lower...

Just looking now at new data on small MCUs that claim up to SysCLK(24MHz)/4 Baud rates.

evanh · 2018-05-02 09:16

Cluso99 wrote: »

evanh,
Thanks, but I specifically didn't want to use smartpins in boot code.
It then has to be cleared down, and I didn't want this to be required.
This way, I don't have to worry about interrupts either.

I know Chip has used the smartpin in the boot code.

Ah, here's your init routine, out of the above source file, that uses a couple of Smartpins for the async serial.

''-------[ Serial Routines (uses SmartPins) ]---------------------------------- <--- serial initialise --->
''_SerialInit
'' On Entry:
''      lmm_x = _bitper                                 ' tx & rx bit period + #(bits-1)
'' Call Format:
''            CALL      #_SerialInit                    '                       < call: serial initilise>
'' On Return:
''      lmm_x = #CR                                     ' (changed)
''--------------------------------------------------------------------------------------------------
_SerialInit
                wrpin   ##_txmode,        #_txpin       ' set asynchronous tx mode in smart pin tx
                wxpin   lmm_x,            #_txpin       ' set tx bit period + #(bits-1)
                dirh    #_txpin                         ' enable smart pin tx 
                
                wrpin   ##_rxmode,        #_rxpin       ' set asynchronous rx mode in smart pin rx
                wxpin   lmm_x,            #_rxpin       ' set rx bit period + #(bits-1)
                dirh    #_rxpin                         ' enable smart pin rx

                mov     lmm_x,            #CR           ' we have to prime send buffer empty flag, 
                wypin   lmm_x,            #_txpin       ' ... so send <cr> to tx pin
              RET                               wcz     '                       <--- return to calling routine --->
''--------------------------------------------------------------------------------------------------

Cluso99 · 2018-05-02 10:55

Oh! That was so looong ago I had forgotten. Think it may even go back to p2hot.
Originally I used bit banging back in the first P2.
Guess I must say it's been working for years.

Cluso99 · 2018-05-04 11:03

Ugh!!
Just realised why I haven't been able to get my monitor running properly/reliably when I insert it into the boot code.
Serial interrupts are still running from the booter trying to autobaud causing weird serial responses

Off to read the manual on clearing interrupts and resetting smart pins

ozpropdev · 2018-05-04 11:20

Wow!
By a "spooky" coincidence I was messing with autobaud stuff today.

Cluso99 · 2018-05-04 11:57

SUCCESS

' NEED TO DISABLE CHIP'S SERIAL & AUTOBAUD !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
		wrpin	#0, #rx_ths
		wxpin	#0, #rx_ths
		wypin   #0, #rx_ths
		wrpin	#0, #rx_tne
		wxpin	#0, #rx_tne
		wypin   #0, #rx_tne
		setint1 #0
		setint2 #0
		setint3 #0

Here is Bootloader code that can be downloaded and run...

Try "> " to set autobaud in Chip's code, followed by one of...

<esc> to run TAQOZ
<ctl-d> to boot a file named "_BOOT_P2.BIX" or _"BOOT_P2.BIY" from an SD card
<ctl-e> to run my monitor

Monitor Commands... (spaces for clarity and optional)

xxxxxx.xxxxxx L <cr>      List cog/lut/hub from addr to addr

xxxxx - xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 'xxxxxxxxxxxxxx' <cr>   Store in cog/lut/hub (no. of bytes optional, ascii optional)
xxxxx G <cr>  Goto/jump to addr in cog/lut/hub

Q <cr>        Quit (return to users calling program) - currently responds "!" and jumps back to monitor code


examples(spaces optional)
 
0 L <cr>               lists cog $000
200 L <cr>             lists lut $200
0000 L <cr>            lists hub $00000
1000.1080 L <cr>       lists hub $1000 to $1080

000- 11 22 33 44 55667788 <cr>   stores in cog (note the reversal of the long $55667788)

The file _BOOT_P2.BIX.spin2 needs to be renamed (remove ".spin2" - forum requirement) and copied to an SD card. It flashes a LED on P5.

Peter Jakacki · 2018-05-04 12:25

I seem to have over 1kB free in the ROM. I wonder if I can squeeze something useful in there....

This hubmap counts active bytes in 256 byte blocks capped at $FF (=256). The .. are all zeros and each line represents 4kB which is skipped if it is all zeros (unused).

TAQOZ# HUBMAP 
0000.0000 FF .. .. .. 51 .. .. .. .. .. .. .. .. .. .. 02 
0000.8000 FC .. .. 08 D7 E5 F5 FF F7 FF FE FF FE FF 32 .. 
0000.C000 EE F1 A6 EF E8 D8 CA CD C1 B9 C8 C9 CF C1 F0 D8 
0000.D000 DE D0 CA D8 D9 DF BB BD DF DD E7 DF E1 C2 .. .. 
0000.E000 .. .. .. .. .. .. .. .. 5F E0 EE E9 EB E1 F6 F2 
0000.F000 D4 EF ED E8 D3 E3 F0 EF F0 F2 62 .. .. .. 34 02 
0007.C000 EE F1 A6 EF E8 D8 CA CD C1 B9 C8 C9 CF C1 F0 D8 
0007.D000 DE D0 CA D8 D9 DF BB BD DF DD E7 DF E1 E4 DA E8 
0007.E000 F5 FF F7 FF FD FF FE FF 69 E0 EE E9 EB E1 F6 F2 
0007.F000 D4 EF ED E8 D3 E3 F0 EF F0 F2 62 .. .. .. .. .. 
000F.C000 EE F1 A6 EF E8 D8 CA CD C1 B9 C8 C9 CF C1 F0 D8 
000F.D000 DE D0 CA D8 D9 DF BB BD DF DD E7 DF E1 E4 DA E8 
000F.E000 F5 FF F7 FF FD FF FE FF 69 E0 EE E9 EB E1 F6 F2 
000F.F000 D4 EF ED E8 D3 E3 F0 EF F0 F2 62 .. .. .. .. ..  ok

TAQOZ# WORDS 
DUP OVER SWAP ROT -ROT DROP 3RD 4TH 2DROP 3DROP NIP 2SWAP 2DUP ?DUP AND 
ANDN OR XOR ROL ROR >> << SAR 2/ 2* 4/ 4* 8<< 16>> 8>> 9<< 9>> REV |< >| 
>N >B >9 BITS NOT = <> 0= 0<> 0< < U< > U> <= => WITHIN DUPC@ C@ W@ @ C+! 
C! C@++ W+! W! +! ! BIT! SET CLR SET? 1+ 1- 2+ 2- 4+ + - UM* * W* / U/ 
U// // */ UM// C++ C-- W++ W-- ++ -- RND GETRND SQRT ~ ~~ W~ W~~ C~ C~~ 
L>S >W L>W W>B W>L B>W B>L MINS MAXS MIN MAX ABS -NEGATE ?NEGATE NEGATE 
ON TRUE -1 FALSE OFF GOTO IF ELSE THEN BEGIN UNTIL AGAIN WHILE REPEAT SWITCH 
CASE@ CASE= CASE> BREAK CASE ADO DO LOOP +LOOP FOR NEXT ?NEXT I J LEAVE 
IC@ I+ BOUNDS H L T F R HIGH LOW FLOAT PIN@ WRPIN WXPIN WYPIN RDPIN RQPIN 
AKPIN WAITPIN WRACK PIN @PIN ns PW PULSE PULSES HILO DUTY NCO HZ KHZ MHZ 
MUTE BLINK PWM SAW BIT BAUD TXD RXD TXDAT WAITX WAITCNT REBOOT RESET 0EXIT 
EXIT NOP CALL JUMP >R R> >L L> !SP DEPTH COG@ COG! LUT@ LUT! COGID COGINIT 
COGSTOP COGATN POLLATN SETEDG POLLEDG KEY KEY! CON NONE COM CONKEY CONEMIT 
EMIT EMITS CRLF CR CLS DOT SPACE SPACES RAM DUMP: DUMP DUMPW DUMPL DUMPA 
DUMPAW QD DEBUG lsio COG LUT KB MB M . PRINT .AS .AS" .DECL .DEC4 .DEC2 
HOLD #> <# # #S <D> U. .DEC .BIN .B .BYTE .W .WORD .L .LONG .ADDR PRINT$ 
LEN$ " ." CTYPE ?EXIT DATA? ERASE FILL CMOVE <CMOVE s ms us CNT@ LAP LAP@ 
.LAP .ms HEX DEC BIN .S WORDS @WORDS GET$ SEARCH $># @DATA HERE @HERE @CODES 
LOOKIN LOOKUP uemit ukey char delim names TASK REG @WORD SPIN | || , [W] 
["] NULL$ $! $= FORGET CREATE$ CREATE VAR pub pri pre module : ; [ ' := 
== ==! ALIGN DATCON ALLOT org bytes words longs byte word long res [C] 
GRAB NFA' CPA CFA \ --- ( { } IFNDEF IFDEF IDLE .VER TAQOZ TERM AUTO SPIRD 
SPIRDL SPIWB SPIWR SPICE SPIWC SPIWW SPIWS SPIPINS SPIRX SPITXE SPITX CLKIN 
CLKOUT CLOCK WSLED WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ CLKMHZ BUFFERS 
ROM IRQVEC PTRA PTRB DIRA DIRB OUTA OUTB INA INB ERROR END  394 ok

Cluso99 · 2018-05-04 12:28

Sssh. I might find something

BTW I think all those serial problems were to do with the Interrupt stealing some input characters.

Did you remove, or make the ascii terminal controls optional ?

Cluso99 · 2018-05-04 12:36

Peter,
Am I correct in recalling that TAQOZ interprets the input as it's being entered?

What did you squeeze to save that space?

Peter Jakacki · 2018-05-04 12:49

Yes, all delimited words are tested for numbers first or the dictionary is searched and if not an immediate word (IF/THEN etc) then the wordcode is compiled. On a CR the compiled code is either executed or if it is part of a definition then the code pointer is simply advanced to continue to compile as part of a definition.

I removed all the ANSI for starters. I'd like to the SPLAT logic analyzer if I can. Anyone with a terminal can capture port signals and display them easily.

David Betz · 2018-05-04 13:34

Cluso99 wrote: »

Monitor Commands... (spaces for clarity and optional)

xxxxxx.xxxxxx L <cr>      List cog/lut/hub from addr to addr

xxxxx - xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 'xxxxxxxxxxxxxx' <cr>   Store in cog/lut/hub (no. of bytes optional, ascii optional)
xxxxx G <cr>  Goto/jump to addr in cog/lut/hub

Q <cr>        Quit (return to users calling program) - currently responds "!" and jumps back to monitor code


examples(spaces optional)
 
0 L <cr>               lists cog $000
200 L <cr>             lists lut $200
0000 L <cr>            lists hub $00000
1000.1080 L <cr>       lists hub $1000 to $1080

000- 11 22 33 44 55667788 <cr>   stores in cog (note the reversal of the long $55667788)

The file _BOOT_P2.BIX.spin2 needs to be renamed (remove ".spin2" - forum requirement) and copied to an SD card. It flashes a LED on P5.

Your monitor commands look like Forth with arguments first followed by a command. May as well just let TAQOZ do the job.

Peter Jakacki · 2018-05-04 13:46

Cluso's debugger is used to debug other software. TAQOZ does have extensive debug words but it may not be compatible with the memory footprint of the user's code.

TAQOZ# 0 $20 COG DUMP 
00.0000:  FDAF.DA68 FD90.00C0 0000.0000 0000.0000  0000.0000 0000.0000 0000.0000 0000.0000 
00.0008:  0000.0000 0000.FE00 0000.0000 0000.DC04  0000.0050 4000.0032 0000.B9B8 0000.4404 
00.0010:  0000.0000 0000.0001 0000.0021 0000.0032  0000.0042 0000.0001 0000.0000 0000.0000 
00.0018:  0000.0000 0000.0000 0000.0050 0000.0000  0000.0000 0000.DA43 0000.FBFF 0000.FCFF  ok
TAQOZ# 0 $20 LUT DUMP 
00.0000:  0000.0000 DEAD.BEEF 0000.0000 DEAD.BEEF  DEAD.BEEF 0000.DEAD FFFF.FFFF FFFF.FFFF 
00.0008:  0000.0000 FFFF.FFFF 0000.0000 FFFF.FFFF  0000.0041 0000.0041 0000.0041 0000.0041 
00.0010:  AD65.FE28 AB04.0000 8D9F.F7B4 F527.F403  FD64.0025 F606.CA00 F606.CC00 FD64.7E40 
00.0018:  FC0C.7C3F FC0C.F83E FD64.7C41 FC06.7C01  FC06.7E00 FC1C.0200 FC2C.0000 FD67.0020  ok
TAQOZ# 0 $40 DUMP 
00.0000: FF FF 3C 00 00 00 FF FF FF FF 00 00 56 06 56 06    ..<.........V.V.
00.0010: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                    
00.0020: 20 20 09 09 09 2D 2D 2D 20 53 65 74 75 70 20 61      ...--- Setup a
00.0030: 20 70 6F 69 6E 74 65 72 20 74 6F 20 74 68 65 20     pointer to the  ok
TAQOZ# 0 $100 DUMPAW 
00.0000: ..<.........d.d.                  ...--- Setup a pointer to the raw file starting sector...  DUP $24 SD!......--- write the file
00.0080:  size we are using...  diradr @FILE @ $28 SD!.....--- save 64GB encoded pointer to the directory entry..\.  TIME. $30 SD!......- ok
TAQOZ#

Cluso99 · 2018-05-04 13:48

David,
Those commands were built with a group of user callable commands to send characters, hex, string, and read characters, strings, etc. So, it's like a bios for serial. The monitor is just the user friendly (from a command line terminal) section of those calls. I did strip quite a bit of functionality out though.

My understanding is that TAQOZ is more of an alternative language that can be used to test out the hardware. I know Peter is using it to construct real programs but unfortunately I don't expect a lot of users to do this. But it's a great interactive development tool that will hopefully get a lot of people into P2.

David Betz · 2018-05-04 14:03

Peter Jakacki wrote: »

Cluso's debugger is used to debug other software. TAQOZ does have extensive debug words but it may not be compatible with the memory footprint of the user's code.

TAQOZ# 0 $20 COG DUMP 
00.0000:  FDAF.DA68 FD90.00C0 0000.0000 0000.0000  0000.0000 0000.0000 0000.0000 0000.0000 
00.0008:  0000.0000 0000.FE00 0000.0000 0000.DC04  0000.0050 4000.0032 0000.B9B8 0000.4404 
00.0010:  0000.0000 0000.0001 0000.0021 0000.0032  0000.0042 0000.0001 0000.0000 0000.0000 
00.0018:  0000.0000 0000.0000 0000.0050 0000.0000  0000.0000 0000.DA43 0000.FBFF 0000.FCFF  ok
TAQOZ# 0 $20 LUT DUMP 
00.0000:  0000.0000 DEAD.BEEF 0000.0000 DEAD.BEEF  DEAD.BEEF 0000.DEAD FFFF.FFFF FFFF.FFFF 
00.0008:  0000.0000 FFFF.FFFF 0000.0000 FFFF.FFFF  0000.0041 0000.0041 0000.0041 0000.0041 
00.0010:  AD65.FE28 AB04.0000 8D9F.F7B4 F527.F403  FD64.0025 F606.CA00 F606.CC00 FD64.7E40 
00.0018:  FC0C.7C3F FC0C.F83E FD64.7C41 FC06.7C01  FC06.7E00 FC1C.0200 FC2C.0000 FD67.0020  ok
TAQOZ# 0 $40 DUMP 
00.0000: FF FF 3C 00 00 00 FF FF FF FF 00 00 56 06 56 06    ..<.........V.V.
00.0010: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                    
00.0020: 20 20 09 09 09 2D 2D 2D 20 53 65 74 75 70 20 61      ...--- Setup a
00.0030: 20 70 6F 69 6E 74 65 72 20 74 6F 20 74 68 65 20     pointer to the  ok
TAQOZ# 0 $100 DUMPAW 
00.0000: ..<.........d.d.                  ...--- Setup a pointer to the raw file starting sector...  DUP $24 SD!......--- write the file
00.0080:  size we are using...  diradr @FILE @ $28 SD!.....--- save 64GB encoded pointer to the directory entry..\.  TIME. $30 SD!......- ok
TAQOZ#

I see. It's too bad TAQOZ couldn't be made to run from the 16K "ROM" area. Wouldn't it just take one additional instruction (add on a base address) to get your word codes working from a higher address?

Peter Jakacki · 2018-05-04 14:23

I could get it "working" sorta but if I try to extend it when I interact and create new words outside of that area then I'm in trouble. But there would a whole lot of things to think about and document if it we made to run in that area too for the reason that it would be co-resident with user code. How much time do we have? Not enough...

David Betz · 2018-05-04 14:47

Peter Jakacki wrote: »

I could get it "working" sorta but if I try to extend it when I interact and create new words outside of that area then I'm in trouble. But there would a whole lot of things to think about and document if it we made to run in that area too for the reason that it would be co-resident with user code. How much time do we have? Not enough...

I guess the non-linear memory map doesn't help much with the 16K "ROM" area way at the top of the address space. If it were just at the top of 512K then you could set the base address at 512K-64K and put all of the core words in the last 16K. Then you'd have the remaining 48K for user extensions which is what you get if you zero as your base address.

Cluso99 · 2018-05-04 14:55

As I understand TAQOZ, they are lots of tiny executables. If they are not on the bottom 64KB, then every time you go to run a little executable, of just a couple of instructions, you have to add a base address. So every few instructions, you add another one for overhead. That's going to slow the amazing speed significantly.
Peter has built an amazing piece of code, but it just needs to run at the bottom 64KB.

David Betz · 2018-05-04 15:11

Cluso99 wrote: »

As I understand TAQOZ, they are lots of tiny executables. If they are not on the bottom 64KB, then every time you go to run a little executable, of just a couple of instructions, you have to add a base address. So every few instructions, you add another one for overhead. That's going to slow the amazing speed significantly.
Peter has built an amazing piece of code, but it just needs to run at the bottom 64KB.

I had originally envisioned TAQOZ as a programmable monitor for the P2. I don't think it is absolutely essential that it be blindingly fast. I imagine that when Peter or anyone else wants to write a full application in Forth they will use full Tachyon not what is in the ROM. As it stands now we get a simple monitor and a stripped down implementation of a programming language.

P2 Monitor/Debug for possible inclusion in the ROM

Comments