Shop OBEX P1 Docs P2 Docs Learn Events
TAQOZ - Tachyon Forth for the P2 BOOT ROM - Page 10 — Parallax Forums

TAQOZ - Tachyon Forth for the P2 BOOT ROM

17810121338

Comments

  • I'll get onto it shortly
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-22 23:47
    I've been playing with adding in VGA into TAQOZ which I compile for testing out of P2 RAM and it seems to be working well so far. I'm fixing up any bugs and adding new features with a view to seeing what I can cram into the new ROM. I am able view load bmp files easily and I would like to add vga text as well although I know that the font table won't fit. I really wish we could have a 32k ROM but maybe I will design TAQOZ so that it automatically extends itself if it finds support in the Flash or SD. Then again, it is just as easy for it to load a new version anyway.

    So on my list of to do's I need to add functionality to create a boot file on Flash and/or SD. The new P2D2 has a small support micro onboard and besides boot control and temperature monitoring it also provides reference timing so the P2 can work out what frequency it is running at.

    Another item for my wish list is if only the P2 could read it's own clock input directly so that before it is applied as the system clock we could check automatically that it was working and what the frequency is and whether it is a straight oscillator or a crystal etc. Maybe a high value resistor from XI to one of the boot I/O might be sufficient given that even with the RC filtering that happens we could use smartpins to detect reduced levels.
  • Maybe use a compressed 6x8 font? That seems to be the lower limit on what is readable. The MSX computers used a 6x8 font. Uncompressed, that's 1.5k.
  • potatoheadpotatohead Posts: 10,261
    edited 2018-10-23 01:48
    Well, here are a couple tiny fonts:

    https://graphicdesign.stackexchange.com/questions/91478/a-font-thats-readable-with-a-5px-height/91523

    At least one of those packs 2 characters into 5 bytes!

    That yields a font table of only 320 bytes!

    That, on a 640x480 screen means... over 80 columns x over 60 columns.

  • Thanks for that info on the fonts guys. If we did manage to get about 2k free I could build it in although the VGA would really only work if we had an external clock source.

    Playing with the VGA at 200MHz clock.
  • cgraceycgracey Posts: 14,134
    Thanks for that info on the fonts guys. If we did manage to get about 2k free I could build it in although the VGA would really only work if we had an external clock source.

    Playing with the VGA at 200MHz clock.

    That's neat, Peter. Were those files on an SD card?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-23 03:09
    Yes, the video is a bit rough but you can see I did a DIR from TAQOZ and I cheated a little bit in defining TIGER as : TIGER $22440 VIEW ; etc but that is in anticipation of having TAQOZ searching the SD card automatically for when it doesn't find the word in the dictionary. So TIGER would fail a dictionary search and then would scan the file directory and find a BMP with that name which would then associate the BMP with VIEW, all seamlessly!


    The SD read routine is still a bit slow because I had a problem with multiple block reads and just reverted quickly to a sector at a time version.
  • cgraceycgracey Posts: 14,134
    edited 2018-10-23 03:16
    Yes, the video is a bit rough but you can see I did a DIR from TAQOZ and I cheated a little bit in defining TIGER as : TIGER $22440 VIEW ; etc but that is in anticipation of having TAQOZ searching the SD card automatically for when it doesn't find the word in the dictionary. So TIGER would fail a dictionary search and then would scan the file directory and find a BMP with that name which would then associate the BMP with VIEW, all seamlessly!


    The SD read routine is still a bit slow because I had a problem with multiple block reads and just reverted quickly to a sector at a time version.

    Nice.

    Ideas for out-of-the-box usefulness are interesting. I wonder what kinds of functions could sell a bunch of chips/boards without the customer being very technical.

    I think everything today that permits you to simply view a file is also routing all your activity to the corp/gov data collectors.
  • jmgjmg Posts: 15,162
    Another item for my wish list is if only the P2 could read it's own clock input directly so that before it is applied as the system clock we could check automatically that it was working and what the frequency is and whether it is a straight oscillator or a crystal etc. Maybe a high value resistor from XI to one of the boot I/O might be sufficient given that even with the RC filtering that happens we could use smartpins to detect reduced levels.

    The lack of a missing clock detector, is a weakness in P2.
    Not sure how you could fix that, in verilog ?
    If a copy of the Xtal signal could be polled in a register, code in HFOSC mode could check it was at least not stuck H or L over many samples.

    You would need to rely on HFOSC being unstable enough to not lock to Xtal in. Maybe HFOSC code can enable PLL and sweep during the test ?
    Or, an edge-triggered S_R cell could clear from HFOSC and trigger from Xtal pin edge ?

    Of course, that is still short of a limp-home mode, but an external watchdog could re-enter the HFOSC code, which then decides to not enable the missing Xtal ?

  • cgraceycgracey Posts: 14,134
    Peter, have you got any advice on what to do with the non-CS/CLK/DI/DO pins on an SD card? Do some need to be pulled high or low, or can they be wired high or low? We just need the minimal setup for our board. Thanks.
  • cgracey wrote: »
    Peter, have you got any advice on what to do with the non-CS/CLK/DI/DO pins on an SD card? Do some need to be pulled high or low, or can they be wired high or low? We just need the minimal setup for our board. Thanks.

    In my experience I find that no pull-ups are needed, especially the chip select. All the really old information on the net would have all these pull-ups, even on the unused pins, but the fact that they totally missed the point about not having a pull-up on the CS indicated to me that they didn't really read or know the spec, they were playing it "safe" from their point of view. Even on serial Flash I only use the one pull-up, which of course for these chips is on the CS since they don't have a built-in pull-up like SD cards do :)
  • cgraceycgracey Posts: 14,134
    cgracey wrote: »
    Peter, have you got any advice on what to do with the non-CS/CLK/DI/DO pins on an SD card? Do some need to be pulled high or low, or can they be wired high or low? We just need the minimal setup for our board. Thanks.

    In my experience I find that no pull-ups are needed, especially the chip select. All the really old information on the net would have all these pull-ups, even on the unused pins, but the fact that they totally missed the point about not having a pull-up on the CS indicated to me that they didn't really read or know the spec, they were playing it "safe" from their point of view. Even on serial Flash I only use the one pull-up, which of course for these chips is on the CS since they don't have a built-in pull-up like SD cards do :)

    Thanks, Peter. This will keep things simple.
  • Cluso99Cluso99 Posts: 18,069
    edited 2018-10-23 11:46
    Yes, no pull-ups are required for an SD card. I had used a pull-up on /CS due to old habits, plus I used a 4x10K which I used on RST, SCL, SCK, CS on my P1 boards. But I would not put one on CS to the SD these days.

    BTW IIRC don't forget P59 requires ~10pF to GND for the current P2 silicon.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-23 14:57
    Here a a few improvements to TAQOZ and VGA capabilities, mainly in reading the bmp file and also in the vga driver. The vga driver's palette and intensity are updated every vsynch.
    Also, I've fixed the camera in place for a clear view.

  • Cluso99Cluso99 Posts: 18,069
    Nicely done Peter :)
  • Cluso99Cluso99 Posts: 18,069
    edited 2018-10-25 06:35
    TAQOZ - Introduction Teaser

    When getting my P2D2 running, Peter helped me do some TAQOZ testing. I thought I would document those commands here to make it easy for others not familiar with TAQOZ to get started.

    From power-up/restart, enter the following three characters
    "< {esc}"
    without quotes, where {esc} is the esc character. Note the space after the "<" is required. Don't wait too long after power up to enter this.
    The "< " sets the autobaud in ROM for the serial, and the <esc> forces a jump to TAQOZ. Replace the <esc> with Ctrl-D to jump to the Monitor.

    Here are some TAQOZ commands. Note some require the additional TAQOZ code stored in flash.
    Ctrl-W                                                  List TAQOZ words
    Ctrl-D                                                  Jumps to the ROM Monitor/Debugger
    
    lsio <cr>                                               List all I/O pin values
    
    61 pin 10 hz <cr>                                       outputs a 10Hz signal on P61 (the P2D2 board has a LED on P61)
    61 blink <cr>                                           outputs a 1Hz signal on P61
    61 pin mute <cr>                                        turns off the output to P61
    
    10 for crlf ."Hello World"next <cr>                     prints 10 times
    
    0 $100 dump <cr>                                        dump memory 0-$100
    0 $100 dumpw <cr>                                       dump word
    0 $100 dumpa <cr>                                       dump ascii
    0 $100 dumpaw <cr>                                      dump ascii word ??
    0 $100 dumpl <cr>                                       dump long
    0 qd <cr>                                               quick dump
    0 sf qd <cr>                                            quick dump serial flash
    .sf <cr>                                                print flash serial numbers
    sfsid .l <cr>                                           print flash serial number
    sfjid .l <cr>                                           print flash jedec number
    
    0 pin 115200 txd                                        sets up serial txd on P0
    $55 wypin                                               outputs char($55) on P0
    
    fibos <cr>                                              prints the fibonacci results
    
    The following commands change the oscillator (requires the Flash TAQOZ) and reset the serial baud
    Ctrl-R                                                  Restore from flash (requires additional TAQOZ code to be stored in flash
    Ctrl-W                                                  List TAQOZ words
    
    hyper 115200 conbaud <cr>                               340 MHz
    turbo 115200 conbaud <cr>                               250 MHz
    cruise 115200 conbaud <cr>                              180 MHz
    slow 115200 conbaud <cr>                                 40 MHz
    
    If you are using an ANSI terminal such as TeraTerm etc
    Alt-i Alt-s e <cr>                                      resets TeraTerm com port and P2D2
    Ctrl-R                                                  Restore from flash (requires additional TAQOZ code to be stored in flash
    erscn                                                   clear screen but leaves cursor at same position
    home erscn                                              clear screen and home
    : cls home erscn ; <cr>                                 defines new TAQOZ word cls that does home erscn
    
  • I thought I'd have a play with some image processing and one of the routines I use a lot in my photo editors is gamma correction. So I'd thought I'd have some fun and just did a quick and simple gamma correction which simply looks for a threshold and if a value is below that it will apply a correction lighter or darker. The whole routine takes 86 bytes and it is already very useful just as it is and only takes about 3ms to correct a bmp palette.
    --- simple gamma routine
    : GAMMA ( gamma* gamma/ thresh< -- )
    	_th C! gam/ C! gam* C!
    	PALETTE $400 ADO
    	  I @ RGB> ( split into components )
    	  3 FOR DUP _th C@ < IF gam* C@ gam/ C@ */ THEN ROT NEXT
    	  >RGB I ! ( recombine rgb and update )
    	4 +LOOP DROP
    	;
    

  • Just added VGA text on VGA graphics handling although nothing has yet been optimized. I can however direct TAQOZ output to the VGA monitor and draw and view etc on the screen at the same time interactively.

    Up to 106x60 text which of course can be any color or textured. Next thing to try is converting a BREAKOUT game for this and then adding a wave player.

  • potatoheadpotatohead Posts: 10,261
    edited 2018-10-28 06:36
    #@)(&$@#)(%^@#$!!

    You are having way too darn much fun, while I struggle with "doesn't have a chip yet" envy! My FPGA board will not fire up. Gonna have to sort out why.

    Well done Peter. Well earned too. Nice work.

    (And I will be fine. The boards with Rev A chips will be here soon enough...)

  • cgraceycgracey Posts: 14,134
    Wow, Peter! I think you've nearly got a computer there.

    That scrolling could be made really fast by using SETQ+RDLONG, followed by SETQ+WRLONG, to move big chunks at a time.
  • cgracey wrote: »
    Wow, Peter! I think you've nearly got a computer there.

    That scrolling could be made really fast by using SETQ+RDLONG, followed by SETQ+WRLONG, to move big chunks at a time.

    When I get USB HID working and then add in Ethernet then I might be close(r).

    Thanks for the tip about SETQ RDLONG but doesn't that need to read into cog memory first? I'm still using a REPS loop that moves bytes around but obviously if I did the same for longs it would run faster.
    ' (RCMOVE) ( src dst cnt -- ) Copy bytes from src to dst for cnt bytes starting from the ends (in reverse)
    pRCMOVE                 modcz   _set,0 wc  'modc    $0F wc          ' set carry for decrementing (always cleared by PUSH)
    ' (CMOVE) ( src dst cnt -- ) Copy cnt bytes from src to dst address
    CMOVE                   rep     @.end,tos
                            rdbyte  R0,tos2         ' read source byte
                            sumc    tos2,#1         ' inc or dec depending upon carry
                            wrbyte  R0,tos1         ' write destination byte
                            sumc    tos1,#1         ' inc or dec depending upon carry!!
    .end                    jmp     #DROP3
    
  • cgraceycgracey Posts: 14,134
    cgracey wrote: »
    Wow, Peter! I think you've nearly got a computer there.

    That scrolling could be made really fast by using SETQ+RDLONG, followed by SETQ+WRLONG, to move big chunks at a time.

    When I get USB HID working and then add in Ethernet then I might be close(r).

    Thanks for the tip about SETQ RDLONG but doesn't that need to read into cog memory first? I'm still using a REPS loop that moves bytes around but obviously if I did the same for longs it would run faster.
    ' (RCMOVE) ( src dst cnt -- ) Copy bytes from src to dst for cnt bytes starting from the ends (in reverse)
    pRCMOVE                 modcz   _set,0 wc  'modc    $0F wc          ' set carry for decrementing (always cleared by PUSH)
    ' (CMOVE) ( src dst cnt -- ) Copy cnt bytes from src to dst address
    CMOVE                   rep     @.end,tos
                            rdbyte  R0,tos2         ' read source byte
                            sumc    tos2,#1         ' inc or dec depending upon carry
                            wrbyte  R0,tos1         ' write destination byte
                            sumc    tos1,#1         ' inc or dec depending upon carry!!
    .end                    jmp     #DROP3
    

    Read and write 32-long blocks. It will be >100x faster.
  • cgracey wrote: »
    Read and write 32-long blocks. It will be >100x faster.

    I used the upper 128 longs in LUT memory and found that it ran about 43 times faster for 300k memory. Should it be faster?
    TAQOZ# LAP $3.0000 DUP 310000 CMOVE LAP .LAP 7,517,772 cycles = 30,071,088ns @250,000,000Hz ok
    TAQOZ# LAP $3.0000 DUP 310000 4/ LMOVE LAP .LAP 174,820 cycles = 699,280ns @250,000,000Hz ok
    
    ' LMOVE ( src dst longs -- ) ' preset for 128 long chunks
    LMOVE			setq2	#$80-1
    			rdlong	$180,tos+2
    			setq2	#$80-1
    			wrlong	$180,tos+1
    			add	tos+2,L200
    			add	tos+1,L200
    			sub	tos,#$80 wc
    		if_nc	jmp	#LMOVE
    			jmp	#DROP3
    L200			long	$200
    

  • cgraceycgracey Posts: 14,134
    edited 2018-10-28 18:56
    I guess that's all we get, then. I was being overly optimistic.

    Hey, you are loading into the control registers at $1Fx. Better change that $180 base to $170.

  • Cluso99Cluso99 Posts: 18,069
    edited 2018-10-28 20:48
    Isn't he loading to/from LUT ? No control regs in lut.
    Or is rdlut & wrlut required also?
  • cgraceycgracey Posts: 14,134
    Cluso99 wrote: »
    Isn't he loading to/from LUT ? No control regs in lut.
    Or is rdlut & wrlut required also?

    You're right. I didn't notice the SETQ2.

    It makes sense, afterall.
  • Will TAQOZ include a Windowing System in the next re-spin?
  • Will TAQOZ include a Windowing System in the next re-spin?
    Sure, if we have a larger ROM :)
    But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.


  • cgraceycgracey Posts: 14,134
    edited 2018-10-30 04:35
    Will TAQOZ include a Windowing System in the next re-spin?
    Sure, if we have a larger ROM :)
    But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.


    Right now, we are using Ray's SD booter, right? Could it be integrated into TAQOS, so that its subroutines become available in Forth? Or, have you got the equivalent code in TAQOS, already? I mean, is there any functional redundancy, at this point? Or, can making this TAQOS-compatible expand the Forth, while still providing SD boot?
  • ElectrodudeElectrodude Posts: 1,650
    edited 2018-10-30 05:10
    cgracey wrote: »
    Will TAQOZ include a Windowing System in the next re-spin?
    Sure, if we have a larger ROM :)
    But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.


    Right now, we are using Ray's SD booter, right? Could it be integrated into TAQOS, so that its subroutines become available in Forth? Or, have you got the equivalent code in TAQOS, already? I mean, is there any functional redundancy, at this point? Or, can making this TAQOS-compatible expand the Forth, while still providing SD boot?

    Please merge them or use just TAQOZ. It'd be great if TAQOZ bytecode could be loaded out of the MBR. This would allow any combination of manually specifying which file to load instead of loading the default file (e.g. based on hardware present), reading some filesystem other than FAT (e.g. ext4 or something exotic or custom), or finding the partition from some partition table format other than MBR (e.g. GPT), without having to worry about support for other filesystems or partition table types in ROM. Of course, leave FAT and MBR support (but all through TAQOZ) in ROM to make things easy in the normal case, but add this to make it possible to replace parts of the boot process with custom parts.

    You would write the MBR from TAQOZ just like any other forth word, and then tell it to write that word to the MBR.
Sign In or Register to comment.