Shop OBEX P1 Docs P2 Docs Learn Events
Tachyon Forth for P2 -FAT32+WIZnet- Now Smartpins - wOOt! - Page 9 — Parallax Forums

Tachyon Forth for P2 -FAT32+WIZnet- Now Smartpins - wOOt!

12345679»

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-08 04:06
    This is just an update on the state of Tachyon in preparation for the TAQOZ BOOT ROM version. Since booting from SD cards is highly desirable I have been spending quite a bit of time on the do's and don'ts and whatif's and finer points of SD cards in SPI mode.

    Single sector read speed over 64KB takes 105ms or around 618kB/second so it would be possible to do a full 512kB load in under a second. However I'm sure that if I use multi-block read that this can be read in much faster. To fully initialize the card and mount the file system takes 125ms first time and that's with my optimizations. Yet with a 64GB card that only takes 98ms, but still in the same ballpark. So even if the user code required a 512k load and even at the single block mode read we can still be up and running in under a second. Final silicon will run faster and besides multiblock read I may even use smartpins with a software mode fallback.
    TAQOZ# FOPEN WEBSTERS.TXT...opened at 0009.61C0   ok
    TAQOZ# $3.0000 64 KB LAP FREAD LAP .LAP 8450497 cycles = 105.631ms  ok
    TAQOZ# $2.0000 256 KB LAP FREAD LAP .LAP 33435841 cycles = 417.948ms  ok
    

    Perhaps I should start up a TAQOZ thread specifically for that version
  • cgraceycgracey Posts: 14,134
    Sounds really good, Peter!
  • I spend some time while doing my failed RAISD project, comparing and reusing KYE's Fat_Engine and FSRW.

    I am still very impressed by @Lonesock's block-driver used in FSRW. Besides using multi-block reads he implemented read ahead and write behind keeping a sector buffer in the COG.

    Really enjoyable PASM code. Somewhere in it you also find @kuronekos's handwriting, a very clever way to do fast HUB-COG or COG-HUB transfers.

    On a P1 this is the fastest code I found, running over 1200kB/second on read and respectable 980kB/second on write. The read ahead and write behind made a big difference to Kye's Fat_Engine.

    Using the SD-block-driver-Cog as parallel running process, reading the next sector in advance, even if not asked for and write-behind. Copy to COG, report success (you have the content of the buffer in cog ram), write it to SD while the caller prepares the next buffer in HUB.

    really cool code. Anybody heard of @lonesock latly?

    Mike
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-08 09:54
    Just tried multiple block reads and the results look good:
    TAQOZ# $2.0000 256 KB LAP FREAD LAP .LAP 21455057 cycles = 268.188ms  ok
    
    That's 268ms vs 418ms using single block reads reading 256kB or just shy of 1MB/sec.

    So a full 512K can be loaded in just over 600ms including mounting a fresh card and the point is that this is at 80MHz and bit-bash mode only. At 160MHz this will barely be noticeable especially if the user code is a lot less. Next comes the smartpin mode.

    BTW, these SD routines aren't using a special cog, just the same one that the TAQOZ console runs from.
  • cgraceycgracey Posts: 14,134
    Wow, Peter! That's fantastic.

    I'm working on getting v28 out. We have an enhanced XORO32 and a new ONES instruction which counts the '1's in a register. Also, I added more status bits to GETINT and SETBRK. Nothing big, but I've been tidying up the Verilog as I go, trying to get everything into shape for final synthesis.
  • ElectrodudeElectrodude Posts: 1,653
    edited 2017-12-08 21:24
    How is the SD loader going to know if there actually is a crystal and what the highest PLL multiplier it can safely use is? Will it start in slow mode and then switch to fast mode after reading clkset info off of the SD card after mounting the card but before loading the program?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-12 08:52
    Everything seems to be working well on V28 so I have just been tidying up the code while getting ready to squeeze a boot ROM version of it into around 12kB or so.

    One of my tests with files is to do a simple lookup, in this case the zipcode. This is only a very rudimentary lookup but suitable for a demonstration. The longest search takes about 2 seconds. The code is rough and ready and if I was doing this a lot I would create a record handling extension vocabulary to simplify doing this (as if it were a new language).

    Usage: ( response in red )
    TAQOZ# ZIP Knoxville GA 31050 ok
    TAQOZ# ZIP Londonderry NH 03053 ok
    TAQOZ# ZIP Canton NY 13617 ok

    BTW, it's an old ZIPCODE file.
    {
    Simple ZIPCODE lookup - type in town and state to display zipcode
    
    ZIPCODE.TXT file format
    00.0000: 0D 0A 41 62 62 65 76 69 6C 6C 65 20 20 20 20 20    ..Abbeville
    00.0010: 20 20 20 20 41 4C 20 33 36 33 31 30 0D 0A 41 62        AL 36310..Ab
    
    Usage:
    TAQOZ# ZIP Knoxville GA 31050  ok
    TAQOZ# ZIP Londonderry NH 03053  ok
    TAQOZ# ZIP Canton NY 13617  ok
    }
    
    18 BYTES town
    pre ZIP ( <town> <state> -- )
    	?MOUNT
    	" ZIPCODES.TXT" FOPEN$ NOT IF PRINT" No ZIP file " EXIT THEN
    	town 17 + C~ town 17 $20 FILL
    ---	Town
    	GETWORD town OVER LEN$ CMOVE
    ---	State (2 characters) and leave on stack as a 16-bit word
    	GETWORD W@ 
    ---	locate state first as 2 characters offset from start of file
    	20 BEGIN 2DUP FSW@ <> WHILE 28 + REPEAT NIP
    ---	Found state - now point back to town field and search
    	SPACE 18 - ( @town )
    ---	quick search based on first 4 chars <> next record
    	town @ SWAP BEGIN 2DUP FS@ <> WHILE 28 + REPEAT NIP
    ---	matched first 4 characters, now match as strings
    	town 4+ SWAP 4+ ( town+4 rcdptr )
    ---	        terminate rcd (temp) then compare as string
    	BEGIN 2DUP FSADR DUP 13 + C~ COMPARE$ 0= WHILE 28 + REPEAT NIP
    ---	found it ( rcdptr ) type out zip code field
    	17 + FSADR 5 CTYPE
    	;
    

    FSADR buffers the correct sector for the 32-bit FileSystem Address of the opened file and returns with the physical address in hub RAM
    FSW@ uses FSADR but returns with a 16-bit word
    FS@ same as FSW@ but fetches a 32-bit long


Sign In or Register to comment.