Thanks for the thanks, may the 4th be with you!
Forth is fun, sharing is fun, sharing Forth is even more fun.
@D.P - I never thought that by radically changing how Tachyon operates under the hood that this is would make it appear intimidating
.
.
.
First experiences. The prompt was distracting and case sensitivity. Then no SD Card access. First attempt was with no card inserted, detected this fine. Next attempt card inserted then hangs on the DIR until card is removed. The second code snippet shows V3 in action. This card works great with V3. Here's the dump. Most likely user error, change is always hard.
Propeller .:.:--TACHYON--:.:. Forth V4.3 DAWN 430170501.0164
MODULES LOADED:
3296: EASYFILE.fth SDHC card + FAT32 Virtual Memory Access File System Layer V1.2 170430-0000
1A40: EXTEND.fth Primary extensions to TACHYON+ kernel - 170427-2200
AUTORUN BOOT
FREQ = 96.0MHz
*** INITS ***
INIT#0 37EA MOUNT
Loading cog 3 E506 F32
*** ROMS ***
0,848 VGA32x15
0,388 HSUART
1,900 F32
0,196 MONO16
1,900 F32
*** I2C ***
A0 EEPROM
CODE:$411A =16154 bytes NAME:$53D4 =8236 bytes DATA:$7925 =789 bytes =4794 bytes free Data Stack (0)
--------------------------------------------------------------------------------
( 0001 $411A ok ) SD8 SDPINS MOUNT
*Card Error*
( 0002 $411A ok ) SD8 SDPINS MOUNT
Mounted 2901.009C-0000.0000 0MB (0/cluster)
( 0003 $411A ok ) ls
( 0004 $411A ok ) DIR
V3 same sd card
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
PCB: P5555 +P8 Only (5555)
FREQ: 96MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $6CEA...74DC for 2,034
CODE: $0930...60C4 for 22,420
RAM: 3,110 bytes free
BUILD: FIRMWARE BUILD DATE 170502:163325 BOOTS: 67 runtime 95
BOOT:
MODULES LOADED:
5058: GARDENCONTROL.fth Garden Control PBJ-8 160908 1100 V1.5
38A9: EASYFILE.fth SD card + FAT32 Virtual Memory Access File System Layer V1.2 16080711-23
00
4DC5: DLVR-L30D.fth DLVR-L30D PSI Sensor v1.3 160830.0930
1800: EXTEND.fth Primary extensions to TACHYON kernel - 160828-1400
3851: P8Only.fth P8 Only HARDWARE DEFINITIONS 160823.1800
ROMS
0848 VGA32x15
0236 HSSERIAL
1648 SIDEMU
1940 QUADUART
0196 MONO16
1900 F32
----------------------------------------------------------------
192.168.37.108 #ls
ls
Mounted 2901.009C-1A0E.2B9B NO NAME FAT32 3,955MB (32,768/cluster)
NO NAME
RUNTIME0.TXT RUNTIME1.TXT RUNTIME2.TXT ok
192.168.37.108 #dir
dir
NO NAME
RUNTIME0.TXT .....a 0000.40C0 May 2 2017 17:39 4,000
RUNTIME1.TXT .....a 0000.4140 May 2 2017 17:39 4,000
RUNTIME2.TXT .....a 0000.41C0 May 2 2017 17:39 4,000 ok
@D.P - did you try V4 with another card? Sandisk always work but the other thing you can do is just check that it initialized with "!SD ." which should be non-zero. V4 clock SD reads at 10MHz (1/8 of the system clock) so there may be a problem with that perhaps although the older 4MHz read methods are still there too, they just need to be revectored.
As for the prompt I find it quite helpful although non-traditional for sure but the prompt and accept response are easy to modify but in fact I may just put in a simple word to switch the prompt from verbose to "ok". Let's call that ON OK or OFF OK, is that OK? Then you can lock it in with a BACKUP.
@D.P - did you try V4 with another card? Sandisk always work but the other thing you can do is just check that it initialized with "!SD ." which should be non-zero. V4 clock SD reads at 10MHz (1/8 of the system clock) so there may be a problem with that perhaps although the older 4MHz read methods are still there too, they just need to be revectored.
As for the prompt I find it quite helpful although non-traditional for sure but the prompt and accept response are easy to modify but in fact I may just put in a simple word to switch the prompt from verbose to "ok". Let's call that ON OK or OFF OK, is that OK? Then you can lock it in with a BACKUP.
Tried a brand new SanDisk 8GB out of the package. Formatted using the SD Card Association format tool.
I get some junk reading an empty disk when I can get it to respond. Inserting and removing causing Tachyon to lock and reboot.
Hardware is a known good IO5500 module.
insertion and issue ls tachyon lockup
( 0020 $4112 ok ) ls
*No Card inserted!* *Card Error* *Card Error*
( 0021 $4112 ok ) è ???
after removing card
( 0024 $4112 ok ) ls
Mounted A0C6.77DA-0000.0000 0MB (0/cluster)
[
Ӎ ]
( 0025 $4112 ok ) dir ???
And for completeness same hardware with V3
Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
PCB: P5555 +P8 Only (5555)
FREQ: 96MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5219...74DC for 8,899 bytes (+2,156)
CODE: $0930...4DC5 for 17,557 bytes (+5,404)
RAM: 1,108 bytes free
BUILD: FIRMWARE BUILD DATE 160804:180000 BOOTS: 0 runtime 39
BOOT: EXTEND.boot
MODULES LOADED:
38A9: EASYFILE.fth SD card + FAT32 Virtual Memory Access File System Layer V1.2 16080711-2300
3851: P8Only.fth P8 Only HARDWARE DEFINITIONS 160823.1800
1800: EXTEND.fth Primary extensions to TACHYON kernel - 160828-1400
ROMS
0848 VGA32x15
0236 HSSERIAL
1648 SIDEMU
1940 QUADUART
0196 MONO16
1900 F32
----------------------------------------------------------------
dir
Mounted A0C6.77DA-9E8F.3F53 NO NAME FAT32 7,740MB (32,768/cluster)
NO NAME
SYSTEM~1. .hs.d. 0000.4040 May 5 2017 23:50 0,000 ok
ls
NO NAME
[SYSTEM~1] ok
But how did it respond to the basic init with !SD because even if it isn't formatted correctly etc you should be able to do this otherwise it indicates a problem elsewhere. Even a raw dump using 0 $200 SD DUMP for instance should display the contents of the first sector.
I'm guessing too that this is a genuine Sandisk as all the current ones are Sandisk Ultra (red and gray). After init the 16 bytes of cid and csd as well as the 4 bytes of ocr can be dumped. Notice the SDSD04G string in the dump plus other bytes:
But how did it respond to the basic init with !SD because even if it isn't formatted correctly etc you should be able to do this otherwise it indicates a problem elsewhere. Even a raw dump using 0 $200 SD DUMP for instance should display the contents of the first sector.
I'm guessing too that this is a genuine Sandisk as all the current ones are Sandisk Ultra (red and gray). After init the 16 bytes of cid and csd as well as the 4 bytes of ocr can be dumped. Notice the SDSD04G string in the dump plus other bytes:
Fresh Tachyon load on hardware and yes this is an original all black SanDisk, I'll try a Red and Black later.
@D.P - did you get the red and gray Sandisk Ultra to mount ok? It should, but I did test with an older black Sandisk and it failed when it went to read the FAT32 sector so I am investigating why but this may be due to some optimizations that I did to the code to improve latencies. My slightly earlier V4 versions had been working though.
Some improvements may need to be improved
btw - Use "cid $30 DUMP" to view the card registers after a !SD. There is also some extra code available to decode these registers and display the information but that is not necessary here.
@D.P - did you get the red and gray Sandisk Ultra to mount ok? It should, but I did test with an older black Sandisk and it failed when it went to read the FAT32 sector so I am investigating why but this may be due to some optimizations that I did to the code to improve latencies. My slightly earlier V4 versions had been working though.
Some improvements may need to be improved
btw - Use "cid $30 DUMP" to view the card registers after a !SD. There is also some extra code available to decode these registers and display the information but that is not necessary here.
Peter, one of the above dumps is the SanDisk Ultra, so no I can't get it to work either, yet.
Here is the cid dump from the Ultra
( 0009 $42DC ok ) !SD
( 0010 $42DC ok ) .@ ???
( 0011 $42DC ok ) .S
Data Stack (1)
$C0FF.8000 - -1056997376
( 0012 $42DC ok ) cid 30 DUMP
0000.76E8: 03 53 44 53 55 30 38 47 80 21 AD 62 92 00 DA 51 .SDSU08G.!.b...Q
0000.76F8: 40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.
( 0013 $42DC ok ) ls
[|????]
Non-s.yst
( 0014 $42DC ok ) DIR
*CLOSED*
Non-s.yst r.s..a 8000.2000 Mar 19 1996 14:27 9,481
( 0015 $42DC ok )
@D.P. - That was a little strange that the other 8GB Ultra didn't work as I use lots of them but I will get around to making EASYFILE work with the older cards again real soon. APPEND is going through a change as previously it depended upon the sector routine identifying the first occurrence of a null or eof character as it was faster to do it this way as it was being read in. But now the sector read is optimized for low latency and f/8 transfer rate, however I will see about getting APPEND to work again.
Hi Peter - I'm quite successful advancing with my PC-Tachyon-Ethernet communication.
After the PC has connected, a simple Forth string is sent to Tachyon, executed there and the answer is mirrored back via the socket. This is so simple - I love manually starting stopping and communicating via the user interface and see the data flying from one to another. I wrote already several socket communications which did semantically the same but they were way way more difficult to implement with terrible protocols.
Nevertheless sometimes I kill the connection from the PC side (maybe quitting the connection in the debugger) and so I lose the pc-side socket. Then Tachyon waits for data coming from the lost socket which never occurs and hangs therfore.
There is no possibility to switch from LAN to CON any more. There is only reset.
I tried to investigate further by using LANCON which as I thought would mirror socket I/O to console but it doesn't - I don't see any transmitted data in minicom.
Isn't it so that LANCON enables a parallel input output via socket and console?
Do you have an advice on how to heal a pc-side lost socket connection?
Thanks in advance,
proplem
Hi Peter - I'm quite successful advancing with my PC-Tachyon-Ethernet communication.
After the PC has connected, a simple Forth string is sent to Tachyon, executed there and the answer is mirrored back via the socket. This is so simple - I love manually starting stopping and communicating via the user interface and see the data flying from one to another. I wrote already several socket communications which did semantically the same but they were way way more difficult to implement with terrible protocols.
Nevertheless sometimes I kill the connection from the PC side (maybe quitting the connection in the debugger) and so I lose the pc-side socket. Then Tachyon waits for data coming from the lost socket which never occurs and hangs therfore.
There is no possibility to switch from LAN to CON any more. There is only reset.
I tried to investigate further by using LANCON which as I thought would mirror socket I/O to console but it doesn't - I don't see any transmitted data in minicom.
Isn't it so that LANCON enables a parallel input output via socket and console?
Do you have an advice on how to heal a pc-side lost socket connection?
Thanks in advance,
proplem
I noticed this problem myself and especially if I type BYE to close a connection rather than quitting telnet, it just locks up somewhere, rather mysterious This is something I will look into fixing in the next day or so.
By default now EASYNET only compiles the drivers and telnet server but by defining +FTP before compile it will also include FTP and HTTP however doing this would require a COMPACT beforehand to free up memory. I may add a +HTTP switch as well.
@D.P. - That was a little strange that the other 8GB Ultra didn't work as I use lots of them but I will get around to making EASYFILE work with the older cards again real soon. APPEND is going through a change as previously it depended upon the sector routine identifying the first occurrence of a null or eof character as it was faster to do it this way as it was being read in. But now the sector read is optimized for low latency and f/8 transfer rate, however I will see about getting APPEND to work again.
Is the 'scan sector for char' routine gone or is this functionality still available then?
@D.P. - That was a little strange that the other 8GB Ultra didn't work as I use lots of them but I will get around to making EASYFILE work with the older cards again real soon. APPEND is going through a change as previously it depended upon the sector routine identifying the first occurrence of a null or eof character as it was faster to do it this way as it was being read in. But now the sector read is optimized for low latency and f/8 transfer rate, however I will see about getting APPEND to work again.
Is the 'scan sector for char' routine gone or is this functionality still available then?
I have two RUNMODs, one for fast f/8 transfers, and the other I can put the scan function back into. So APPEND will use the slower SDRD for scanning but otherwise normal sector reads will use the fast SDRDF.
So along with a couple of things I need to fix, this will be put back in this week. I'm also putting in a "line mode" option especially for interactive work so it is easy to backspace and edit the line plus I may also be able to recall the previous line or more of history. Maybe I can hold the history in a file or on EEPROM. However TACHYON block mode will still compile word by word and line mode is only a layer on top of this anyway. I think I could probably even introduce simple editing commands for this lines too as that starts to form the basis for an editor.
To Do:
* fix Telnet disconnect bug
* Add sector scan function back in
* Add editable line mode layer
Hi @Peter - I downloaded latest dropbox V4 sources. I have the feeling they have grown up a lot.
- the build runs better - I need just 4 minutes to build completely from scratch and I didn't hurry
- runtime is running again
- the DISCONNECT bug seems to be fixed
One conspicuity: I use a different ip-address which is not overwritten by the build process although it should. But it isn't so important. With some trial and error I could get managed with this. (Of course I did pay attention on SDPINS and WIZPINS)
BTW I use this to set the IP configuration for IOT5500:
FORGET .&
&27.24.26.25 SDPINS
pub .& '&' EMIT 4 FOR 8 ROL DUP >B . IX 1 > IF '.' EMIT THEN NEXT DROP ;
&17.1.19.18 WIZPINS
&192.168.1.124 == myIP
&192.168.1.1 == myGW
&255.255.255.0 == mySN
WCOLD
Keep up the good work - the improvements are definitely going to be improved :-)
PS:
Shouldn't you append a hint to Tachyon in The X-Wing logo?
@proplem - thanks, I have my line delay set to 3ms and it works just fine. Maybe I can do better yet plus I am thinking of automatically buffering direct to a temporary file if it is available too which is especially helpful when the dictionary is compacted into EEPROM.
The default IP settings in the source code won't override any that have been set into upper EEPROM, so it's not a bug, it's the way it is intended to work so each device can retain its ID even if the prop loader were to wipe the first 32k.
I was having a bit of fun with the logo and ended up going minimalistic although I could add the word "Tachyon" in there I guess
On that note have you all noticed that the other Propeller Forths have been inactive for quite a while? Caskaz usually posts some Propforth snippet at least every month but I noticed that even he has not posted for a while. I did PM him a few weeks ago to see if he is alright, but I haven't received any reply. It was always a bit sad that even the Forth community was divided, as if some sense of loyalty was involved. For me it was a matter not of loyalty or academic interest or playtime but one of practical need, otherwise I would stick with Spin or even Propforth since rolling my own solution would involve that dreaded four letter word "work".
But Tachyon is wonderfully fast, not just in tiny cacheable snippets, but where it counts, in final commercial product. I never thought I'd fit all this functionality into a standard Prop as I used to run out of memory doing much simpler things (slowly) before I developed Tachyon. So because some of us actually expect to build real products with the Prop then Tachyon is the means I use to get the Prop to do that without waiting year after year for P2 or switching to another processor. Anyway how could I wait? If I need to make a product, I need to make it now, or just don't bother. I'm always fascinated by the years many seem to be able to spend talking about P2 but obviously don't seem to have any commercial need. P1+Tachyon gets a lot done now and done very well, yet this solution seems to be ignored in general. I'm sure P3+Python would do what we do now but I've checked used car sales and I haven't found Marty's DeLorean yet.
In the last weeks I've checked REVECTOR a few times always without success. Now I tried again:
( 0001 $589E ok ) pub CUR ." cur" ;
( 0002 $58A6 ok ) pub NEW ." new" ;
( 0003 $58AE ok ) CUR
cur
( 0004 $58AE ok ) NEW
new
( 0005 $58AE ok )
( 0006 $58AE ok ) REVECTOR CURR NEW
( 0007 $58AE ok ) CURR ???
( 0008 $58AE ok )
Is REVECTOR failing or do I completely misunderstand it's working?
Best regards,
proplem
In the last weeks I've checked REVECTOR a few times always without success. Now I tried again:
( 0001 $589E ok ) pub CUR ." cur" ;
( 0002 $58A6 ok ) pub NEW ." new" ;
( 0003 $58AE ok ) CUR
cur
( 0004 $58AE ok ) NEW
new
( 0005 $58AE ok )
( 0006 $58AE ok ) REVECTOR CURR NEW
( 0007 $58AE ok ) CURR ???
( 0008 $58AE ok )
Is REVECTOR failing or do I completely misunderstand it's working?
Best regards,
proplem
Has it ocCURRed to you that CURR and CUR are not the same?
In the last weeks I've checked REVECTOR a few times always without success. Now I tried again:
( 0001 $589E ok ) pub CUR ." cur" ;
( 0002 $58A6 ok ) pub NEW ." new" ;
( 0003 $58AE ok ) CUR
cur
( 0004 $58AE ok ) NEW
new
( 0005 $58AE ok )
( 0006 $58AE ok ) REVECTOR CURR NEW
( 0007 $58AE ok ) CURR ???
( 0008 $58AE ok )
Is REVECTOR failing or do I completely misunderstand it's working?
Best regards,
proplem
Has it ocCURRed to you that CURR and CUR are not the same?
Arrgghh - no the Forth was not with me.
I corrected the typo but it gets even worse - reset after the revectoring happened successful
( 0001 $589E ok ) pub CUR ." cur" ;
( 0002 $58A6 ok ) pub NEW ." new" ;
( 0003 $58AE ok ) CUR
cur
( 0004 $58AE ok ) NEW
new
( 0005 $58AE ok )
( 0006 $58AE ok ) REVECTOR CUR NEW
CUR
new
Propeller .:.:--TACHYON--:.:. Forth V4.3 DAWN 430170501.0164
MODULES LOADED:
4BE6: EASYNET.fth WIZNET NETWORK SERVERS 170421.0000
4338: W5500.fth WIZNET W5500 driver 170421.0000
32D6: EASYFILE.fth SDHC card + FAT32 Virtual Memory Access File System Layer V1
1A80: EXTEND.fth Primary extensions to TACHYON+ kernel - 170427-2200
AUTORUN �
FREQ = 96.0MHz
*** INITS ***
INIT#0 3834
Loading cog 3 E50A F32
*** ROMS ***
0,848 VGA32x15
0,392 HSUART
1,900 F32
0,196 MONO16
1,900 F32
*** I2C ***
A0 EEPROM
CODE:$58AE =22190 bytes NAME:$66AE =3410 bytes DATA:$7A48 =1080 bytes =3584 by)
--------------------------------------------------------------------------------
( 0001 $58AE ok )
In the last weeks I've checked REVECTOR a few times always without success. Now I tried again:
There was a bug in REVECTOR which probably came about when it was combined with +VECTOR. REVECTOR should set the lsb of the new address so that it becomes a jump rather than a call. I've fixed EXTEND but this is the bit of code that has been updated. The bug wasn't noticed before but since there is only a string following the ." then by replacing the first wordcode which was the runtime for ." with a call, it ended up trying to execute the string as invalid wordcodes after its return.
--- REVECTOR oldcode newcode - Replaces first code of oldcode with jump to newcode
pre REVECTOR 1
pri ~v [C] ' [C] ' [C] GRAB ROT + SWAP W! ;
pre +VECTOR 0 ~v ;
There was a bug in REVECTOR which probably came about when it was combined with +VECTOR. REVECTOR should set the lsb of the new address so that it becomes a jump rather than a call. I've fixed EXTEND but this is the bit of code that has been updated. The bug wasn't noticed before but since there is only a string following the ." then by replacing the first wordcode which was the runtime for ." with a call, it ended up trying to execute the string as invalid wordcodes after its return.
--- REVECTOR oldcode newcode - Replaces first code of oldcode with jump to newcode
pre REVECTOR 1
pri ~v [C] ' [C] ' [C] GRAB ROT + SWAP W! ;
pre +VECTOR 0 ~v ;
Upcoming V4.4 updates:- New DOFOR loop construct; Console Line mode; Console history; case insensitive
Forth implements loops with either a simple counted FOR NEXT or the start and end version DO LOOP with the additional +LOOP which can use a value other than the default value of +1. However Tachyon normally uses ADO instead of DO since most loops need a start value and a count whereas DO uses an awkward limit and start value but also checks against that limit every time it LOOPs. This does not work the way you would expect sometimes. BTW, most DO LOOPs in Forth end up using a start value and a count anyway when they combine BOUNDS with DO which is basically what ADO does in one operation.
Well now I've decided to throw the traditional DO LOOP into the trash so to speak. I'm playing with replacing it with DOFOR which accepts a start index value, a count, and a loop index increment value. If we are addressing longs in hub memory this is how it may be done:
hublongs 8 4 DOFOR I @ .LONG SPACE LOOP
Nice and simple, we use our address as a starting index, for 8 times, and increment the address by 4 bytes each time.
The traditional method may have looked like this though:
hublongs 32 BOUNDS DO I @ .LONG SPACE 4 +LOOP
Even though we only wanted it to loop 8 times we still had to set up the count correctly as 8*4 and use BOUNDS do convert it to a limit.
The advantage of the new DOFOR method is that loops can run much faster (avoids data stack push/pop) and a loop count is just that, a count.
$20 64 1 DOFOR I EMIT LOOP
The old DO, ADO, and +LOOP are now no longer needed.
If this all works out well then this will be included in V4.4 along with console line mode and history so each task can just build a text input line before passing it to the evaluate layer which compiles this at the end of code memory and executes it or locks it in if it is part of a definition. This means telnet can operate along with the serial console without interference but also means you can backspace and edit a line before commit. However the fast TACHYON block load mode will directly interface to the eval layer as it does now. EEPROM may be used to keep and recall history automatically.
Searches will also be made case insensitive by default. You can still switch back to the case sensitive mode if you like.
There's also another feature which strictly speaking isn't part of the kernel but once EASYFILE has been loaded it will always try to mount the file system on startup via the "inits" table. If a FASTLOAD.TXT file is found then all TACHYON mode block loads will directly write to that and when the input stream times out it will automatically FLOAD FASTLOAD.TXT. This means that we don't have to increase the terminal line delay after the dictionary has been moved to EEPROM for instance where searches are much slower (unfortunately).
Upcoming V4.4 updates:- New DOFOR loop construct; Console Line mode; Console history; case insensitive
...
All these changes are very welcome to me though I have some remarks:
- compatibility: The new DOFOR loop is attracting me although I would resist throwing old "loop technology" away. For a long time Forth loops are done this historic way you know better than me. Maybe beginners would be excluded from Tachyon ... although a good documentation ... Hmmm. But there is more documentation using the old syntax. I vote for supporting the old syntax maybe it could be implemented using the new DOFOR syntax.
- console history is very welcome!!! Oh yes yes yes :-)) But it is also a question of compatibility if it is dependent from an SDCARD. There are hardwares which even don't supply an SDCARD.
- I'm more a friend of case sensitivity. I want to get what I see. And I want to fail early if I do a typo.
Last but not least a question: Peter will Tachyon support other SDCARDs than SANDISK again? In my opinion the old V3 was much more tolerant. This is also something that could exclude beginners or make first steps more difficult.
@proplem
The standard LOOP has to do a compare index with limit and depending which works fine for simple increment but +LOOP can jump that boundary. It seems to me that I have only ever used loops that run n times using a starting index which normally increments by one but sometimes I require that to be variable. DOFOR does all this very nicely and all that LOOP has to do is add the increment to the index, then a DJNZ on the count. Much simpler and variable increment loops run just as fast a a normal loop. But as I said, I am playing with it although it is looking very good so far.
Console history will rely upon hub RAM and EEPROM, not SD card as that may or may not be inserted or available etc.
The console is also easier to use if we switch to non-case sensitive mode as caps lock can be up or down and it doesn't matter. But I have made this selectable and it can be locked in EEPROM.
Line mode is also selectable too but that is also where I am maintaining history etc.
The problem with different cards should be very minor but I have other types of cards that just work anyway. I started to check with the scope the other day and I'm sure it is just a matter of supplying extra clocks or something. It's not really a V4 vs V3 thing as the same would have happened in V3 if I had optimized the drivers too.
Can you check -FERASE in EASYNET.fth please. Last time I tried it with a .FILE OPENED the card was erased.
" RUNTIME0.TXT" FOPEN$
RW
-FERASE
FCLOSE
I like the DOFOR LOOP syntax, one mnemonic to rule them all.
I will keep trying to move my V3 projects forward.
I remember updating -FERASE the other day and the code for it looks right if you like to check it.
--- Erase the current file by overwriting with nulls
pub -FERASE
FSECT@ 0EXIT
sdbuf BLKSIZ ERASE
FSECT@ FSIZE@ BLKSIZ ALIGN 9 >> ADO I WRSECT DROP LOOP
;
The last line would start writing to the file sector and continue for however many sectors make up the file. Since it is not trying to read any sectors it is very fast.
I remember updating -FERASE the other day and the code for it looks right if you like to check it.
--- Erase the current file by overwriting with nulls
pub -FERASE
FSECT@ 0EXIT
sdbuf BLKSIZ ERASE
FSECT@ FSIZE@ BLKSIZ ALIGN 9 >> ADO I WRSECT DROP LOOP
;
The last line would start writing to the file sector and continue for however many sectors make up the file. Since it is not trying to read any sectors it is very fast.
Lastest V4r3 sources, still no APPEND and disk gets wiped after -FERASE causes a TACHYON reboot.
( 0033 $41D6 ok ) DIR
NO NAME
RUNTIME0.TXT .....a 0000.AF80 May 14 2017 09:11 8,576
RUNTIME1.TXT .....a 0000.C940 May 14 2017 09:11 8,576
RUNTIME2.TXT .....a 0000.DE80 May 14 2017 09:11 8,576
( 0034 $41D6 ok ) .FILE
#3 *CLOSED*
( 0035 $41D6 ok ) .FILES
#0 *CLOSED*
#1 *CLOSED*
#2 *CLOSED*
#3 *CLOSED*
( 0036 $41D6 ok ) FOPEN RUNTIME0.TXT
...opened at 0000.AF80 for 1048576
.S
Data Stack (0)
( 0037 $41D6 ok ) RW
( 0038 $41D6 ok ) .S
Data Stack (0)
( 0039 $41D6 ok ) -FERASE
2A
Propeller .:.:--TACHYON--:.:. Forth V4.3 DAWN 430170514.0076
MODULES LOADED:
3324: EASYFILE.fth SDHC card + FAT32 Virtual Memory Access File System L
1A40: EXTEND.fth Primary extensions to TACHYON+ kernel - 170427-2200
AUTORUN BOOT
FREQ = 96.0MHz
*** INITS ***
INIT#0 3880 MOUNT
Loading cog 3 E50A F32
*** ROMS ***
0,848 VGA32x15
0,392 HSUART
1,900 F32
0,196 MONO16
1,900 F32
*** I2C ***
A0 EEPROM
CODE:$41D6 =16342 bytes NAME:$538A =8310 bytes DATA:$7925 =789 bytes =4)
--------------------------------------------------------------------------------
( 0001 $41D6 ok ) DIR
NO NAME
@D.P - ok, I see the problem, I don't know my own code. WRSECT does not take a stack parameter for a sector, it simply writes the sector back from the last one read.
I've patched EASYFILE and checked it on my online unit.
pub -FERASE
FSECT@ 0EXIT
sdbuf BLKSIZ ERASE
FSECT@ FSIZE@ BLKSIZ ALIGN 9 >> ADO sdbuf I SDWR DROP LOOP
;
peter@peter-workstation ~ $ telnet 192.168.0.99 10001
Trying 192.168.0.99...
Connected to 192.168.0.99.
Escape character is '^]'.
WELCOME TO THE TACHYON WIZNET TELNET SESSION!
( 0056 $4F0A ok ) ls
WIDGET
128K .BIN 256K .BIN DEBUG .ROM EASYFILE.FTH EASYNET .FTH
ECOLCD .PDF EXTEND .FTH FAVICON .ICO FIRMWARE.ROM FRED .PNG
FSRPCB .PNG FSRSCH .PNG HELP .TXT HOME .HTM HTTP404 .HTM
IMAGE IMAGE1 IMAGE2 IMAGE3 IOT5500 .HTM
LOGON .HTM LOVE .MP3 P8 .H P8X32A .PDF POPCORN .MP3
PREVIOUS.ROM SDCARD .FTH SITE0001.LOG SITE0002.LOG SITE0003.LOG
SITE0004.LOG SYSLOG .TXT TACHYON .HTM W5200 .FTH W5500 .FTH
WELCOME .TXL LOVE .WAV POPCORN .WAV WARPEACE.TXT COMPACT .FTH
SEE .FTH SDLEDS .FTH RXLED .FTH TEMP .TXT LANLED .FTH
FL .FTH LIFE .FTH SPLAT .FTH DRAGON .JPG CE1372 .JPG
CHARLCD .JPG HCB4208 .JPG IOT5500 .JPG IOT5500H.JPG IOTPINS .JPG
P8CPU .JPG PARALLAX.PNG
( 0057 $4F0A ok ) QV LOGON.HTM
0000.0000: HTTP/1.1 401 Unauthorized..Server: TACHYON..Date: Tue Jan 4 23:
0000.0040: 15:48 2000..WWW-Authenticate: Basic realm="Tachyon Web Server"..
0000.0080: Pragma: no-cache..Cache-Control: no-cache..Content-Type: text/ht
0000.00C0: ml....<html><head><title>Document Error: Unauthorized</title></h
( 0058 $4F0A ok ) .FILE
#3 LOGON .HTM .....a 0000.7109 Jun 15 2014 05:44 0,388
( 0059 $4F0A ok ) -FERASE
( 0060 $4F0A ok ) QV LOGON.HTM
0000.0000: ................................................................
0000.0040: ................................................................
0000.0080: ................................................................
0000.00C0: ................................................................
( 0061 $4F0A ok ) ls
WIDGET
128K .BIN 256K .BIN DEBUG .ROM EASYFILE.FTH EASYNET .FTH
ECOLCD .PDF EXTEND .FTH FAVICON .ICO FIRMWARE.ROM FRED .PNG
FSRPCB .PNG FSRSCH .PNG HELP .TXT HOME .HTM HTTP404 .HTM
IMAGE IMAGE1 IMAGE2 IMAGE3 IOT5500 .HTM
LOGON .HTM LOVE .MP3 P8 .H P8X32A .PDF POPCORN .MP3
PREVIOUS.ROM SDCARD .FTH SITE0001.LOG SITE0002.LOG SITE0003.LOG
SITE0004.LOG SYSLOG .TXT TACHYON .HTM W5200 .FTH W5500 .FTH
WELCOME .TXL LOVE .WAV POPCORN .WAV WARPEACE.TXT COMPACT .FTH
SEE .FTH SDLEDS .FTH RXLED .FTH TEMP .TXT LANLED .FTH
FL .FTH LIFE .FTH SPLAT .FTH DRAGON .JPG CE1372 .JPG
CHARLCD .JPG HCB4208 .JPG IOT5500 .JPG IOT5500H.JPG IOTPINS .JPG
P8CPU .JPG PARALLAX.PNG
( 0062 $4F0A ok )
Comments
V3 same sd card
As for the prompt I find it quite helpful although non-traditional for sure but the prompt and accept response are easy to modify but in fact I may just put in a simple word to switch the prompt from verbose to "ok". Let's call that ON OK or OFF OK, is that OK? Then you can lock it in with a BACKUP.
Tried a brand new SanDisk 8GB out of the package. Formatted using the SD Card Association format tool.
I get some junk reading an empty disk when I can get it to respond. Inserting and removing causing Tachyon to lock and reboot.
Hardware is a known good IO5500 module.
insertion and issue ls tachyon lockup
after removing card
And for completeness same hardware with V3
I'm guessing too that this is a genuine Sandisk as all the current ones are Sandisk Ultra (red and gray). After init the 16 bytes of cid and csd as well as the 4 bytes of ocr can be dumped. Notice the SDSD04G string in the dump plus other bytes:
Looks like SanDisk 8GB microSD are EOL at Officeworks, and gone
16GB are $12.
Fresh Tachyon load on hardware and yes this is an original all black SanDisk, I'll try a Red and Black later.
update: here is a red and gray SanDisk know good card
Some improvements may need to be improved
btw - Use "cid $30 DUMP" to view the card registers after a !SD. There is also some extra code available to decode these registers and display the information but that is not necessary here.
Peter, one of the above dumps is the SanDisk Ultra, so no I can't get it to work either, yet.
Here is the cid dump from the Ultra
Seems APPEND is returning false though? Files are 256K null filled.
After the PC has connected, a simple Forth string is sent to Tachyon, executed there and the answer is mirrored back via the socket. This is so simple - I love manually starting stopping and communicating via the user interface and see the data flying from one to another. I wrote already several socket communications which did semantically the same but they were way way more difficult to implement with terrible protocols.
Nevertheless sometimes I kill the connection from the PC side (maybe quitting the connection in the debugger) and so I lose the pc-side socket. Then Tachyon waits for data coming from the lost socket which never occurs and hangs therfore.
There is no possibility to switch from LAN to CON any more. There is only reset.
I tried to investigate further by using LANCON which as I thought would mirror socket I/O to console but it doesn't - I don't see any transmitted data in minicom.
Isn't it so that LANCON enables a parallel input output via socket and console?
Do you have an advice on how to heal a pc-side lost socket connection?
Thanks in advance,
proplem
I noticed this problem myself and especially if I type BYE to close a connection rather than quitting telnet, it just locks up somewhere, rather mysterious
By default now EASYNET only compiles the drivers and telnet server but by defining +FTP before compile it will also include FTP and HTTP however doing this would require a COMPACT beforehand to free up memory. I may add a +HTTP switch as well.
I have two RUNMODs, one for fast f/8 transfers, and the other I can put the scan function back into. So APPEND will use the slower SDRD for scanning but otherwise normal sector reads will use the fast SDRDF.
So along with a couple of things I need to fix, this will be put back in this week. I'm also putting in a "line mode" option especially for interactive work so it is easy to backspace and edit the line plus I may also be able to recall the previous line or more of history. Maybe I can hold the history in a file or on EEPROM. However TACHYON block mode will still compile word by word and line mode is only a layer on top of this anyway. I think I could probably even introduce simple editing commands for this lines too as that starts to form the basis for an editor.
To Do:
* fix Telnet disconnect bug
* Add sector scan function back in
* Add editable line mode layer
- the build runs better - I need just 4 minutes to build completely from scratch and I didn't hurry
- runtime is running again
- the DISCONNECT bug seems to be fixed
One conspicuity: I use a different ip-address which is not overwritten by the build process although it should. But it isn't so important. With some trial and error I could get managed with this. (Of course I did pay attention on SDPINS and WIZPINS)
BTW I use this to set the IP configuration for IOT5500:
Keep up the good work - the improvements are definitely going to be improved :-)
PS:
Shouldn't you append a hint to Tachyon in The X-Wing logo?
Best regards, and thanks a lot
proplem
The default IP settings in the source code won't override any that have been set into upper EEPROM, so it's not a bug, it's the way it is intended to work so each device can retain its ID even if the prop loader were to wipe the first 32k.
I was having a bit of fun with the logo and ended up going minimalistic although I could add the word "Tachyon" in there I guess
On that note have you all noticed that the other Propeller Forths have been inactive for quite a while? Caskaz usually posts some Propforth snippet at least every month but I noticed that even he has not posted for a while. I did PM him a few weeks ago to see if he is alright, but I haven't received any reply. It was always a bit sad that even the Forth community was divided, as if some sense of loyalty was involved. For me it was a matter not of loyalty or academic interest or playtime but one of practical need, otherwise I would stick with Spin or even Propforth since rolling my own solution would involve that dreaded four letter word "work".
But Tachyon is wonderfully fast, not just in tiny cacheable snippets, but where it counts, in final commercial product. I never thought I'd fit all this functionality into a standard Prop as I used to run out of memory doing much simpler things (slowly) before I developed Tachyon. So because some of us actually expect to build real products with the Prop then Tachyon is the means I use to get the Prop to do that without waiting year after year for P2 or switching to another processor. Anyway how could I wait? If I need to make a product, I need to make it now, or just don't bother. I'm always fascinated by the years many seem to be able to spend talking about P2 but obviously don't seem to have any commercial need. P1+Tachyon gets a lot done now and done very well, yet this solution seems to be ignored in general. I'm sure P3+Python would do what we do now but I've checked used car sales and I haven't found Marty's DeLorean yet.
Best regards,
proplem
Has it ocCURRed to you that CURR and CUR are not the same?
Arrgghh - no the Forth was not with me.
I corrected the typo but it gets even worse - reset after the revectoring happened successful
There was a bug in REVECTOR which probably came about when it was combined with +VECTOR. REVECTOR should set the lsb of the new address so that it becomes a jump rather than a call. I've fixed EXTEND but this is the bit of code that has been updated. The bug wasn't noticed before but since there is only a string following the ." then by replacing the first wordcode which was the runtime for ." with a call, it ended up trying to execute the string as invalid wordcodes after its return.
Forth implements loops with either a simple counted FOR NEXT or the start and end version DO LOOP with the additional +LOOP which can use a value other than the default value of +1. However Tachyon normally uses ADO instead of DO since most loops need a start value and a count whereas DO uses an awkward limit and start value but also checks against that limit every time it LOOPs. This does not work the way you would expect sometimes. BTW, most DO LOOPs in Forth end up using a start value and a count anyway when they combine BOUNDS with DO which is basically what ADO does in one operation.
Well now I've decided to throw the traditional DO LOOP into the trash so to speak. I'm playing with replacing it with DOFOR which accepts a start index value, a count, and a loop index increment value. If we are addressing longs in hub memory this is how it may be done:
hublongs 8 4 DOFOR I @ .LONG SPACE LOOP
Nice and simple, we use our address as a starting index, for 8 times, and increment the address by 4 bytes each time.
The traditional method may have looked like this though:
hublongs 32 BOUNDS DO I @ .LONG SPACE 4 +LOOP
Even though we only wanted it to loop 8 times we still had to set up the count correctly as 8*4 and use BOUNDS do convert it to a limit.
The advantage of the new DOFOR method is that loops can run much faster (avoids data stack push/pop) and a loop count is just that, a count.
$20 64 1 DOFOR I EMIT LOOP
The old DO, ADO, and +LOOP are now no longer needed.
If this all works out well then this will be included in V4.4 along with console line mode and history so each task can just build a text input line before passing it to the evaluate layer which compiles this at the end of code memory and executes it or locks it in if it is part of a definition. This means telnet can operate along with the serial console without interference but also means you can backspace and edit a line before commit. However the fast TACHYON block load mode will directly interface to the eval layer as it does now. EEPROM may be used to keep and recall history automatically.
Searches will also be made case insensitive by default. You can still switch back to the case sensitive mode if you like.
There's also another feature which strictly speaking isn't part of the kernel but once EASYFILE has been loaded it will always try to mount the file system on startup via the "inits" table. If a FASTLOAD.TXT file is found then all TACHYON mode block loads will directly write to that and when the input stream times out it will automatically FLOAD FASTLOAD.TXT. This means that we don't have to increase the terminal line delay after the dictionary has been moved to EEPROM for instance where searches are much slower (unfortunately).
Can you check -FERASE in EASYNET.fth please. Last time I tried it with a .FILE OPENED the card was erased.
I like the DOFOR LOOP syntax, one mnemonic to rule them all.
I will keep trying to move my V3 projects forward.
- compatibility: The new DOFOR loop is attracting me although I would resist throwing old "loop technology" away. For a long time Forth loops are done this historic way you know better than me. Maybe beginners would be excluded from Tachyon ... although a good documentation ... Hmmm. But there is more documentation using the old syntax. I vote for supporting the old syntax maybe it could be implemented using the new DOFOR syntax.
- console history is very welcome!!! Oh yes yes yes :-)) But it is also a question of compatibility if it is dependent from an SDCARD. There are hardwares which even don't supply an SDCARD.
- I'm more a friend of case sensitivity. I want to get what I see. And I want to fail early if I do a typo.
Last but not least a question: Peter will Tachyon support other SDCARDs than SANDISK again? In my opinion the old V3 was much more tolerant. This is also something that could exclude beginners or make first steps more difficult.
The standard LOOP has to do a compare index with limit and depending which works fine for simple increment but +LOOP can jump that boundary. It seems to me that I have only ever used loops that run n times using a starting index which normally increments by one but sometimes I require that to be variable. DOFOR does all this very nicely and all that LOOP has to do is add the increment to the index, then a DJNZ on the count. Much simpler and variable increment loops run just as fast a a normal loop. But as I said, I am playing with it although it is looking very good so far.
Console history will rely upon hub RAM and EEPROM, not SD card as that may or may not be inserted or available etc.
The console is also easier to use if we switch to non-case sensitive mode as caps lock can be up or down and it doesn't matter. But I have made this selectable and it can be locked in EEPROM.
Line mode is also selectable too but that is also where I am maintaining history etc.
The problem with different cards should be very minor but I have other types of cards that just work anyway. I started to check with the scope the other day and I'm sure it is just a matter of supplying extra clocks or something. It's not really a V4 vs V3 thing as the same would have happened in V3 if I had optimized the drivers too.
I remember updating -FERASE the other day and the code for it looks right if you like to check it.
--- Erase the current file by overwriting with nulls pub -FERASE FSECT@ 0EXIT sdbuf BLKSIZ ERASE FSECT@ FSIZE@ BLKSIZ ALIGN 9 >> ADO I WRSECT DROP LOOP ;The last line would start writing to the file sector and continue for however many sectors make up the file. Since it is not trying to read any sectors it is very fast.
Lastest V4r3 sources, still no APPEND and disk gets wiped after -FERASE causes a TACHYON reboot.
I've patched EASYFILE and checked it on my online unit.
pub -FERASE FSECT@ 0EXIT sdbuf BLKSIZ ERASE FSECT@ FSIZE@ BLKSIZ ALIGN 9 >> ADO sdbuf I SDWR DROP LOOP ;