Are there any books and/or information on Tachyon Forth? I have tried used Spin, and it
seems problematic.
If you can't swim in Spin you will definitely sink in Forth. There are so many tutorials and examples and support for Spin that even if it's your first time programming you should be able to pick it up as long as you go through it methodically, not trying to jump the gun, just wishin' n Hopin'.
Not saying Forth is hard but it's a different mindset and with embedded programming you need to know your hardware, it's not like a PC with all it's drivers and API layers insulating the programmer from all those "details" etc. Go through the Spin tutorials from the beginning, simple stuff, but make sure you totally grok it before you move on to the next step. You've been given some links I see and only you can really help yourself. If you don't then you will never progress and get that satisfaction from learning and making it all happen.
There are a lot of younger ones these days that have been "spoilt" on a diet of easy 123 tech that makes it look like you are a genius, but someone else had already done the amazing stuff and packaged it up, the kids just play with it and rearrange it. Do you really want to be in this game? ...don't be a kid, man up.
0025 ok ON ECHO ON OK 0 uemit W! ;
0026 ok
[~ \
0192 INCLUDING #9 PIN_I/O_OPERATIONS
0340 INCLUDING #8 CHARACTER_OUTPUT
0401 INCLUDING #7 LOCAL_VARIABLES
0420 INCLUDING #6 FIXED_POSITION_VARIABLES
0486 INCLUDING #5 MATHS_FUNCTIONS
0577 INCLUDING #12 NUMBER_PRINT_FORMATING
0679 INCLUDING #19 ANSI_TERMINAL
--> OPCODE <-- not found
And EXTEND.FTH gives me a fault on Tachyon V2.3.spin.
It was that sunday.
I downloaded Tachyon V2.4.spin, and changed baud to 115200, but only get a blue screen like windoze.
Unfortunately I deleted the old version before I tryed the new one.
Tachyon V2.3.spin works, so now I have to start all over again.
2.4 is the way to go but only change the baud rate, do not touch the clock settings as they automatically adjust for 5 or 10MHz. Your CON block should look like this:
CON
_clkmode = xtal1 + pll8x
_xinfreq = 10_000_000 ' <--- AUTOMATIC 5 or 10MHz operation change at boot
sysfreq = 80_000_000
baud = 115200 ' <-- user change - tested from 300 baud to 3M baud
Re OPCODE: There were options in EXTEND.fth for V2.3 and V2.4 but there is really no reason any longer to use 2.3.
now with CRC8 - modified a CRC16 I found in Peter's code
( 1-Wire.fth )
{ first part is base code from Peter Jakacki with minor adaptions
second part is romsearch extensions by MJB Markus Baer }
TACHYON
[~
: 1WIRE.fth ." 1-wire interface 121025:0000 " ;
{
The 1-Wire interface is implemented in bytecode so it does not require a special cog to handle the timing. Testing is being done on DS1820+ and DS2450S+ chips.
CHANGELOG:
121025
Fixed bugs in routines
Added strong pullup after writing to provide power for parasitic devices
Add some of Brian Riley's code
Allow for redirection of DQ line
}
( I/O DEFINITIONS )
LONG dq
pri DQ@ dq @ ;
pub DQ! dq ! ;
#P14 |< DQ! \ set the default
pub 1W.RESET ( -- ack )
DQ@ OUTCLR 1 ms
DQ@ INPUTS #60 us
DQ@ IN 0=
#400 us
;
pub 1W.BITWR ( iomask dat -- iomask dat/2 )
OVER OUTCLR \ pulse low for 1us
SHROUT \ output next data bit then shift data right
#60 us \ minimum cycle time
OVER OUTSET \ Force line high at end of slot (rather than float)
;
pub 1W.BITRD ( iomask dat -- iomask dat+ )
OVER OUTCLR OVER INPUTS \ pulse line low for 1us then float
8 us
SHRINP \ assemble another bit by right shifting
#50 us \ MJB
OVER OUTSET \ Force line high at end of slot (rather than float)
;
\ Transmit 8-bit lsb first
pub 1W! ( dat -- )
DQ@ SWAP \ mask and data ( iomask dat )
8 FOR 1W.BITWR NEXT \ write 8 bits lsb first
2DROP \ discard mask and used data
;
\ Receive 8-bit data lsb first
pub 1W@ ( -- dat )
DQ@ 0 \ initial mask and data ( iomask dat )
8 FOR 1W.BITRD #45 us NEXT
NIP #24 SHR \ right justify ( dat )
;
\ Get bytes from bus and print as hex bytes
pub .1W ( bytes -- ) FOR 1W@ .BYTE SPACE NEXT ;
pub READROM $33 1W! ; \ send read ROM command code
pub SKIPROM $CC 1W! ; \ send skip ROM command code
pub MATCHROM $55 1W! ; \ command to match an ID to a specific device
pub CONVERTT $44 1W! ; \ commands all Temp sensors to start measurement (750 ms)
pub READSCR $BE 1W! ; \ starts to: dumps 9 bytes (8 plus CRC) of device scratchpad
pub 1WSCMD 1W.RESET DROP SKIPROM ; \ reset, skip ROM for single sensor only and prepare for next command
pub RDROMH 1W.RESET DROP READROM 8 .1W ; \ read and print 8 byte ROM code
pub RDSCRH 1WSCMD READSCR 9 .1W ; \ reset, skip ROM, read and print Scratchpad 9 bytes
pub TEMP@ ( -- temp ) \ read first 2 bytes from scratchpad and assemble to temperature value on TOS ( binary, low nibble is fraction )
READSCR
1W@ 1W@ B>W \ combine 2 bytes to 1 long on stack
;
pub .TEMP ( temp -- )
DUP $0F AND SWAP 4 SHR \ put whole degrees in one long and fraction in another
$830A .NUM \ print whole number
"." EMIT \ print decimal point
#100 * 4 SHR \ turn binary bits to 100ths
$020A .NUM \ print decimal
." 'C "
;
\ 18B20 diagnostic routines
: SHOWTEMP ( reads annd displays a single DS18B20 alone on a 1-W bus )
1WSCMD CONVERTT #750 ms
1WSCMD TEMP@ DUP CR .TEMP
SPACE 4 SHR 0 DO ." *" LOOP
;
: SHOWSP ( reads annd displays a single DS18B20 SCRATCHPAD alone on a 1-W bus )
1WSCMD CONVERTT #750 ms
1WSCMD RDSCRH
;
: SHOWTEMPS BEGIN SHOWTEMP 2 seconds KEY? AND UNTIL ;
]~
END
{ DEMO USAGE
SHOWTEMPS
+036.81'C ************************************
+036.62'C ************************************
+036.06'C ************************************
+035.68'C ***********************************
+034.62'C **********************************
+034.68'C **********************************
+034.25'C **********************************
+033.31'C *********************************
+032.87'C ********************************
+032.50'C ********************************
+032.81'C ********************************
+033.12'C *********************************
+033.25'C *********************************
+033.31'C *********************************
+033.43'C *********************************
+033.50'C *********************************
+033.68'C *********************************
+033.68'C *********************************
+033.62'C *********************************
+032.87'C ********************************
+031.62'C *******************************
+031.00'C *******************************
+028.12'C ****************************
+026.62'C **************************
+026.31'C **************************
+025.81'C *************************
+024.43'C ************************
+024.18'C ************************
+022.37'C **********************
+021.68'C *********************
+021.81'C *********************
+022.18'C **********************
+022.50'C **********************
+023.18'C ***********************
+023.93'C ***********************
}
{
To check the ROM of a single device:
1WRESET DROP READROM
}
]~
END
\ here starts the code by MJB Markus Baer
( 1WireMJB.fth )
TACHYON
[~
: 1WIREMJB.fth ." 1-wire interface extensions MJB 140525:0000 " ;
\ CREATE SMALL \ define SMALL before a load to specify a SMALL build to limit the sections included IFNDEF SMALL
{
\ DESCRIPTION
\
\ Maxim 1-wire ROM Search algorithm
\ straight forward implementation
\ per AN937 "Book of iButton Standards", figure 5-3
\ for TACHYON Forth 2014 by Markus Baer aka MJB @ parallax forums,
\ inspired by am-forth implementation by Bradford J. Rodriguez.
\ USES
\ 1WIRE.fth from Tachyon Forth by Peter Jakacki
\ and of course the TACHYON System (Kernel 2.3 + EXTEND) - thanks Peter
\
\ ** USES from 1-wire.fth ****
\ 1W.RESET ( -- ack )
\ 1W.BITWR ( iomask dat -- iomask dat/2 )
\ 1W.BITRD ( iomask dat -- iomask dat+ )
\ 1W! ( c -- ) Write one byte to the 1-wire bus.
\ 1W@ ( -- c ) Read one byte from the 1-wire bus.
}
{ if you need it ...
: 1W.!N ( xN .. x1 N -- ) FOR 1W! NEXT ; \ send N characters/bytes from stack
: 1W.@N ( N -- x1 .. xN ) FOR 1W@ NEXT ; \ fetch N characters/bytes to stack
: 1W..ROM RDROMH ; \ print 1Wire single device ROM code
}
BYTE 1W.lastdisc ( used as byte variable to hold last discrepancy )
BYTE 1W.doneflag
BYTE 1W.rombit ( used as byte variable, 1..64 )
BYTE 1W.discmark
\ buffer for one ROM-ID 1W.romid ( 8 byte array )
8 BYTES 1W.romid
pri 1W.!rombit ( f -- set the bit 1..32 given by 1W.rombit in buffer 1W.romid to flag value f )
1W.rombit C@ 1- 8 U/MOD ( -- f bit# byte# )
1W.romid + ( f bit# addr )
SWAP MASK SWAP ( f bitmask addr )
ROT ( bitmask addr f )
BIT!
;
pri 1W.@rombit ( -- f \ f is 0 or non-0 not necc. 1 \ fetch the bit 1..32 given by 1W.rombit from buffer 1W.romid to flag f )
1W.rombit C@ 1- 8 U/MOD ( -- bit# byte# )
1W.romid + C@ ( -- bit# byte )
SWAP MASK ( -- byte bitmask )
AND
;
\ helper
pub <>0 ( val -- 0or1 \ convert any non 0 to 1 instead of -1 as 0<> does )
IF 1 ELSE 0 THEN ;
#P14 |< DQ! \ for my setup MJB, this is the pin my 1-wire bus is attached to 4.7k or 5k pullup required
\ single bit operations to read and write 1-wire bus
pri 1W.BIT@ ( -- bit ) DQ@ 0 1W.BITRD NIP <>0 ; \ gives bit as 0 or 1
pri 1W.BIT! ( bit -- ) DQ@ SWAP 1W.BITWR 2DROP ; \ takes bit as 0 or 1
{ for test
pri .rombit ( bitnumber -- ) 1W.rombit C! 1W.@rombit . ; \ print 1W.rombit value
pri .RB ( -- ) 1W.@rombit . ;
pri .romid ( -- ) 1W.romid 8 ADO I C@ . SPACE LOOP ;
}
BYTE 1W.devcnt
LONG 1W.devaddr
TABLE 1W.1Wdevs #8 #8 * ALLOT \ prepare for 8 devices here, change as appropriate
pri 1W.NEWSEARCH ( -- \ clear variables used in search )
1W.lastdisc C~
1W.doneflag C~
1 1W.rombit C! \ 1..64
1W.romid #8 ERASE
1W.devcnt C~ \ set device count to 0
;
pri 1W.SEARCHROM ( -- f ) ( search for one additional device. Returns 0 if done or 1 if more to come. see 1W.SCAN )
0 ( default return value ) ( 0 )
1W.doneflag C@ IF
1W.doneflag C~ \ clear doneflag
EXIT ( leaves 0 )
THEN
1W.RESET IF ( presence signal detected? )
1 1W.rombit C! ( yes: set ROM bit index to 1 )
1W.discmark C~ ( set discrepancy marker to 0 ) ( 0 )
$F0 1W! ( send search command on bus ) ( 0 )
BEGIN
1W.BIT@ 1W.BIT@ 2* + ( 0 BA ) \ 2 bits A & B in bit pos 0 AND 1
DUP $03 = ( 0 BA flag )
IF ( bitA = bitB = 1?)
DROP
1W.lastdisc C~ \ clear
EXIT ( leaves 0 )
ELSE ( 0 BA )
?DUP 0= ( 0 BA false | 0 true )
IF ( bitA = bitB = 0?) ( 0 )
1W.rombit C@ 1W.lastdisc C@ = ( 0 flag )
IF
1 1W.!rombit ( 0 )
ELSE
1W.rombit C@ 1W.lastdisc C@ > ( 0 flag )
IF
0 1W.!rombit
1W.rombit C@ 1W.discmark C! ( 0 )
ELSE
1W.@rombit 0= ( 0 flag )
IF
1W.rombit C@ 1W.discmark C! ( 0 )
THEN
THEN ( 0 )
THEN ( 0 )
ELSE ( 0 BA )
$01 AND ( bit A value , bit B is inverse so we don't need it )
1W.!rombit ( 0 )
THEN
THEN ( 0 )
1W.@rombit <>0 \ gives 0 or 1 as logical values instead of 0 -1
1W.BIT! ( DROP what is this drop for ??? )( send ROM bit to bus )
1W.rombit C@
1+ DUP
1W.rombit C! ( 0 1W.rombitVal ) \ increment 1W.rombit index
$40 > UNTIL \ check > 64 ( 0 )
1W.discmark C@
DUP 1W.lastdisc C! ( 0 discmark )
0= IF
1 1W.doneflag C! ( 0 )
ELSE
1+ ( set return value to 1 = true )
THEN
ELSE ( no presence signal )
1W.lastdisc C~ \ set 0
THEN
;
\ calc the CRC given start and length of string/bytes. If string includes the CRC the result is 0 for OK
\ Peter's 16 bit CRC adapted
pub CRC8 ( str cnt -- crc )
0 ROT ROT
ADO
I C@ SWAP
8 FOR
2DUP XOR 1 AND
ROT 2/ ROT 2/ ROT
IF $8C XOR THEN
NEXT
NIP
LOOP
;
\ Demonstrates how to use SEARCHROM to find all attached devices and store them in table 1W.1Wdevs
pri 1W.PRINTromid ( addr -- ) \ print the ROM-ID at address
8 ADO I C@ .BYTE SPACE LOOP CR
;
pub 1W.SCAN ( -- ) \ scan for any devices on 1-wire bus and store them in table 1W.1Wdevs
1W.NEWSEARCH
1W.1Wdevs 1W.devaddr ! \ begin at start of table
CR
BEGIN
1W.SEARCHROM
1W.romid 1W.PRINTromid \ print it
1W.romid 8 CRC8 IF ." CRC mismatch above" CR THEN
\ ' CMOVE ( src dst cnt -- ) Copy bytes from src to dst address for cnt bytes using increment for up or down
1W.romid 1W.devaddr @ 8 CMOVE \ SEARCHROM could be optimized to store directly to table,
\ by making 1W.romid a CONST pointing to the table entry and changing it for each run
1W.devaddr DUP @ 8 + SWAP ! \ increment the address to store by 8 bytes
0= UNTIL
CR
;
{ test it on 2 devices
LAP 1W.SCAN LAP .LAP
28 09 6C CD 04 00 00 82
28 F7 E6 BF 04 00 00 3A
Time: 56.01ms ok for discovering 2 DS18B20 sensors
1W.1Wdevs $20 DUMP
1W.1Wdevs $20 ADO I C@ .BYTE SPACE LOOP
1W.1Wdevs $16 ERASE
}
{ some demo / test code
pub 1W..1Wdevs \ print the table of 1W.1Wdevs discovered by 1W.SCAN ( if table is not full )
1
1W.1Wdevs
CR
BEGIN \ BEGIN condition WHILE code REPEAT
DUP
C@ WHILE ( 1 1W.1Wdevs ) \ works only if there is at least one element in table which is 0ed
SWAP DUP .BYTE ":" EMIT SPACE 1+ SWAP
DUP 1W.PRINTromid
8 +
REPEAT
DROP
;
pub 1W..1WdevsT \ print the table of 1W.1Wdevs discovered by 1w.scan in Table format for inclusion in Tachyon code
1W.1Wdevs
CR ." TABLE 1W.my1Wdevs" CR
BEGIN \ BEGIN condition WHILE code REPEAT
DUP C@
WHILE ( 1 1W.1Wdevs )
SPACE
DUP 8 ADO ." $" I C@ .BYTE ." | " LOOP CR \ ADO ( from cnt -- )
8 +
REPEAT
DROP
;
\ print the discovered 1Wire-IDs
1W..1Wdevs
\ print the table of 1W.1Wdevs discovered by 1w.scan in Table format for inclusion in Tachyon code
1W..1WdevsT
}
\ 1 Wire Multibus CoMmanD takes the address of a ROM code and performs a matchROM command
pub 1W.MCMD ( -- ) 1W.RESET DROP MATCHROM ; \ reset and send Match ROM command
pub 1W.MATCH ( addr -- ) \ address sensor with 64-bit rom code given at addr then ready for next command
1W.MCMD 8 ADO I C@ 1W! LOOP ;
\ IFNDEF SMALL
\ DS18B20 diagnostic routines
: 1W.SHOWTEMPM ( tableaddr n -- \ reads and displays a DS18B20 on a multibus. n is the index into the table of devices 1W.1Wdevs )
\ 1W.1Wdevs table of discovered 1W devices with SEARCHROM
1- 8 * + \ calculate start of ROM code to address
DUP 1W.MATCH CONVERTT #750 ms
\ 1W.MATCH TEMP@ DUP .TEMP
1W.MATCH TEMP@ .TEMP
\ SPACE 4 SHR 0 DO ." *" LOOP \ bar graph
;
: 1W.SHOWSPM ( tableaddr n -- \ reads and displays a DS18B20 SCRATCHPAD on a multibus n is the index into the table of devices 1W.1Wdevs )
\ 1W.1Wdevs table of discovered 1W devices with SEARCHROM
1- 8 * + \ calculate start of ROM code to address
DUP 1W.MCMD CONVERTT #750 ms
1W.MCMD RDSCRH
;
\ for sensor# from I = 1 to n from ROM-Code table given show the temp readings cyclically until key pressed
: 1W.SHOWTEMPSM ( tableaddr n -- )
CR
BEGIN
1 OVER ADO \ from 1 to n
OVER I 1W.SHOWTEMPM SPACE
LOOP
CR 2 seconds
KEY? AND \ AND required, since KEY? ( -- key flag )
UNTIL
2DROP ;
} \ end IFNDEF SMALL
{ the generated table ready to paste into Tachyon again
TABLE 1W.my1Wdevs
$28 | $09 | $6C | $CD | $04 | $00 | $00 | $82 |
$28 | $F7 | $E6 | $BF | $04 | $00 | $00 | $3A |
1W.my1Wdevs 2 1W.SHOWTEMPSM \ show the temperature for my 2 sensors
\ next line works directly after romsearch from found IDs
\ 1W.1Wdevs 2 1W.SHOWTEMPSM
1W.1Wdevs 2 1W.SHOWTEMPSM
+023.00'C +023.18'C
+023.00'C +023.18'C
+023.31'C +023.18'C
+024.00'C +023.18'C
+024.50'C +023.18'C
+025.00'C +023.18'C
+025.37'C +023.18'C
+025.81'C +023.18'C
+026.12'C +023.18'C
+026.18'C +023.25'C
+026.25'C +023.75'C
+026.06'C +024.18'C
+025.87'C +024.62'C
+025.75'C +025.06'C
+025.62'C +025.31'C
ok
}
]~
END
Well it has been quite a journey to get TACHYON V2.4 to come to live.
I have made some changes in it, to get it to work.
There are some thing I do not understand, but at the moment, I dont need these functions.
Have a look at the pictures. I now have my 1-wire up running again.
A watchdog never sleeps.
Now my watchdog have played around with TACHYON a bit.
Next thing I found out was, change fit to 497 and insert a nop after RESET or somewhere around.
But today I moved "sdbuf long @RESET+s" to a new place, and wupti now it runs.
I moved it form line 3603 to line 3732 right after the last instr.
I don't think it like's a long inbetwen instr.
A watchdog never sleeps.
Now my watchdog have played around with TACHYON a bit.
Next thing I found out was, change fit to 497 and insert a nop after RESET or somewhere around.
But today I moved "sdbuf long @RESET+s" to a new place, and wupti now it runs.
I moved it form line 3603 to line 3732 right after the last instr.
I don't think it like's a long inbetwen instr.
That sdbuf line is just a long constant used by MYOP which in itself is basically just used at present to speed up some virtual memory addressing. So a long constant (more than a 9-bit immediate) is just another location in cog memory and it can be pretty much anywhere out of the way.
By changing fit to 497 and inserting an extra long it will actually allow a LOADMOD to overflow into the special purpose registers, specifically the PAR register, not good. But what are you trying to achieve? When I get a new car I just like to drive it around and take it on a trip to see what it can do first rather than try to improve it by messing under the hood
Ok , as it couldn't bring on the screen message after a reset, on my Propeller board, I had to do something.
But I shall not disturb you again.
Have a nice day.
Ok , as it couldn't bring on the screen message after a reset, on my Propeller board, I had to do something.
But I shall not disturb you again.
Have a nice day.
Mean what you say but don't be mean when you say it, and I wasn't so I'm sorry if it came across that way, so there is no need to take offense and besides we are all reasoning adults here. Your last two posts left me scratching my head trying to figure why you had to do what you did, and what made you target some obscure lines of code. It's like you are tinkering under the bonnet immediately because you are trying to start the car with the wrong set of keys.
As far as I can tell these were not the current sources as I checked those and they compile perfectly. The google docs version is always current of course but if you work off the "published" version you may need to refresh the page. But if there is a problem then it pays to provide a little more information as I rely on feedback to improve these sources or perhaps even the manner in which they are updated.
Well, to be specific, I need help in making up a help file that will reside on the SDFS so that in combination with SDWORDS etc we can have a lot more at our fingertips. Although all words compiled after SDFS is in place could have a structure that included help information which would be extracted and written to the HELP file as the code was compiled, there is still all the code up to and including the SDFS ( SDCARD + EASYFILE ) that we need to get the help information for. Now either we just create a file from scratch or perhaps even pass the source code for the Tachyon kernel, EXTEND, headers, SDCARD and EASYFILE back through a help file extractor so that only the source code needs to have this information in the first place. Of course we would just have the files loaded onto the SD card to make it easy to parse or it could even be loaded serially as needed.
The help file structure itself has not been fully defined but normally it doesn't require any super-fast lookup as it is normally invoked interactively from the console so it may just end up as an unstructured text file with control codes to mark the words.
But wait!, it's possible perhaps that the help file is in fact all the source code files themselves and the help extractor could find code tags to mark each word and help section then build an index file which otherwise would take a bit of time to search through a few megabytes. This means we could have a HELP.IDX file which points to the correct source code file and position so that we don't need to have one large help file, just the source code files themselves with included help information.
How would this look then?
[B]HELP FOPEN$[/B]
HELP: FOPEN$ ( namestr -- sector )
Open the file with the 8.3 name and return with it's sector or 0 if failed
The variable fstat can be checked for more information if there was an error
Execution time ~ 10ms
Usage: " SYSLOG.TXT" FOPEN$ IF etc etc
}
pub FOPEN$ ( namestr -- sector )
FCLOSE
DUP C@
IF --- skip null name
DUP C@ "/" = IF 1+ THEN --- ignore leading / in file name
DUP LEN$ #12 >
IF "!" fstat C! DROP FALSE EXIT THEN --- abort with ! status if name is too long
DUP FILE$ $! --- set the name for this file
>F83 DIR? DUP --- find the dir entry
IF FOPEN# ( sector ) --- open the file from the dir entry
ELSE "?" fstat C! --- else ? not found
THEN
ELSE
DROP FALSE " " fstat C! --- null string, so not found of course
THEN
;
The HELP: starts a comment section up to the } but the extractor uses HELP: as a code tag and includes all information up to the next blank line (or perhaps another code tag but I'm trying to avoid that).
So please Tachyonites, any ideas on how this can be handled but more importantly can you provide some help adding this help information and tags to the source codes?
Well, to be specific, I need help in making up a help file that will reside on the SDFS so that in combination with SDWORDS etc we can have a lot more at our fingertips. Although all words compiled after SDFS is in place could have a structure that included help information which would be extracted and written to the HELP file as the code was compiled, there is still all the code up to and including the SDFS ( SDCARD + EASYFILE ) that we need to get the help information for. Now either we just create a file from scratch or perhaps even pass the source code for the Tachyon kernel, EXTEND, headers, SDCARD and EASYFILE back through a help file extractor so that only the source code needs to have this information in the first place. Of course we would just have the files loaded onto the SD card to make it easy to parse or it could even be loaded serially as needed.
The help file structure itself has not been fully defined but normally it doesn't require any super-fast lookup as it is normally invoked interactively from the console so it may just end up as an unstructured text file with control codes to mark the words.
But wait!, it's possible perhaps that the help file is in fact all the source code files themselves and the help extractor could find code tags to mark each word and help section then build an index file which otherwise would take a bit of time to search through a few megabytes. This means we could have a HELP.IDX file which points to the correct source code file and position so that we don't need to have one large help file, just the source code files themselves with included help information.
How would this look then?
[B]HELP FOPEN$[/B]
HELP: FOPEN$ ( namestr -- sector )
Open the file with the 8.3 name and return with it's sector or 0 if failed
The variable fstat can be checked for more information if there was an error
Execution time ~ 10ms
Usage: " SYSLOG.TXT" FOPEN$ IF etc etc
}
pub FOPEN$ ( namestr -- sector )
FCLOSE
DUP C@
IF --- skip null name
DUP C@ "/" = IF 1+ THEN --- ignore leading / in file name
DUP LEN$ #12 >
IF "!" fstat C! DROP FALSE EXIT THEN --- abort with ! status if name is too long
DUP FILE$ $! --- set the name for this file
>F83 DIR? DUP --- find the dir entry
IF FOPEN# ( sector ) --- open the file from the dir entry
ELSE "?" fstat C! --- else ? not found
THEN
ELSE
DROP FALSE " " fstat C! --- null string, so not found of course
THEN
;
The HELP: starts a comment section up to the } but the extractor uses HELP: as a code tag and includes all information up to the next blank line (or perhaps another code tag but I'm trying to avoid that).
So please Tachyonites, any ideas on how this can be handled but more importantly can you provide some help adding this help information and tags to the source codes?
TIA, Peter
Seems that embedded HELP in the source comments the source code as well as renders HELP from the console. I will fill out what I know/understand when the design decision is made on which way HELP should work. This will really HELP MJB who has been wishing for more documentation on the sources in general. Me too.
Seems that embedded HELP in the source comments the source code as well as renders HELP from the console. I will fill out what I know/understand when the design decision is made on which way HELP should work. This will really HELP MJB who has been wishing for more documentation on the sources in general. Me too.
Good, I think the HELP: embedded into the source code and having HELP find the source code section from an index file is best. That way only a MAKEHELP or something needs to be run after a build to generate the index file and all the documentation stays with the sources. This format looks flexible enough and having the actual source code come up is a bonus.
MAKEHELP would scan through all .FTH files on SDFS to locate these sections but since it can have multiple files open at a time it should be quick enough in generating the index file.
So please Tachyonites, any ideas on how this can be handled but more importantly can you provide some help adding this help information and tags to the source codes?
TIA, Peter
Hi Peter,
yes , we have been talking about HELP / DOC generation from source.
I opt for the help information inside the source.
Mostly because my development mode would NOT need the help on the prop itself usually.
I keep ALL the Tachyon files open simultaneously in Notepad++ so I can easily do a 'search all files' for a pub XXX pr pri XXX to find the definition.
I also write a Notepad++ extension for syntac coloring and for listing the definitions in a clickable index list aside teh edit window.
this is pretty neat
so structured in file help and doc YES
on SD - well fine - I can use FTP to get it when running in NW-mode
but editing and accessing help will mostly be in the IDE, not the tachyon terminal
EXCEPT: a quick way to get the arguments of a word listed.
ARGS <word> to see what it expects on the stack and leaves after completion
HELP <word> just lists args + top doc
SOURCE <word> lists complete definition incl comments
Hi Peter,
yes , we have been talking about HELP / DOC generation from source.
I opt for the help information inside the source.
Mostly because my development mode would NOT need the help on the prop itself usually.
I keep ALL the Tachyon files open simultaneously in Notepad++ so I can easily do a 'search all files' for a pub XXX pr pri XXX to find the definition.
I also write a Notepad++ extension for syntac coloring and for listing the definitions in a clickable index list aside teh edit window.
this is pretty neat
so structured in file help and doc YES
on SD - well fine - I can use FTP to get it when running in NW-mode
but editing and accessing help will mostly be in the IDE, not the tachyon terminal
EXCEPT: a quick way to get the arguments of a word listed.
ARGS <word> to see what it expects on the stack and leaves after completion
HELP <word> just lists args + top doc
SOURCE <word> lists complete definition incl comments
It is my intent to build help info in the source but I'm not always tethered to a PC and sometimes I only have my phone so having a system that I can perhaps even edit source on via Bluetooth/serial/telnet is always a bonus.
As for HELP words it should never become too complicated otherwise you will need HELP HELP etc. I think if we type HELP then we expect at least the help info and perhaps something as simple as a ^? ($1F) after a word would just list the parameters. The source listing may just be SHOW <word> which would also include the help info. Then there is the EDIT <word> which would take you straight to the correct source file and word
Now the original intent of announcing the HELP function was also to call for HELP, from interested Tachyonites who will be able to sift through the source codes and create HELP: stubs for most of the main words at least. Even if the wording is not totally correct it's a start in the right direction and these things can be refined later. Some of you already have edit permissions for the source code but anyone else who would like to contribute then please let me know.
The general format for a help stub is fairly simple, to Tachyon it looks like a comment block but when the source code files are on SD or Flash then this section is scanned by the MAKEHELP word (not implemented yet) which builds a word index and pointers and offset to the source file. So when we are connected to the target system we can type HELP FOPEN$ and get:
HELP: FOPEN$ ( namestr -- sector )
Open the file with the 8.3 name and return with its sector or 0 if failed
The variable fstat can be checked for more information if there was an error
Execution time ~ 10ms
Usage: " SYSLOG.TXT" FOPEN$ IF etc etc
}
Or SHOW FOPEN$ will reveal the source code as well:
HELP: FOPEN$ ( namestr -- sector )
Open the file with the 8.3 name and return with its sector or 0 if failed
The variable fstat can be checked for more information if there was an error
Execution time ~ 10ms
Usage: " SYSLOG.TXT" FOPEN$ IF etc etc
}
pub FOPEN$ ( namestr -- sector )
FCLOSE
DUP C@
IF --- skip null name
DUP C@ "/" = IF 1+ THEN --- ignore leading / in file name
DUP LEN$ #12 >
IF "!" fstat C! DROP FALSE EXIT THEN --- abort with ! status if name is too long
DUP FILE$ $! --- set the name for this file
>F83 DIR? DUP --- find the dir entry
IF FOPEN# ( sector ) --- open the file from the dir entry
ELSE "?" fstat C! --- else ? not found
THEN
ELSE
DROP FALSE "?" fstat C!
THEN
;
Now that I have the dictionary indexed and stored in a file there is a lot more room available for more enhancements and applications. The HELP feature therefore becomes part of the interactive development and if I implement a text editor, maybe just via the terminal with VT100/ANSI controls formatting then it's possible that as we type or select a word that the HELP is automatically displayed in a footer section, especially if we have 50 terminal lines on the screen. At 230,400 baud the terminal screen refreshes quite fast so that a 128x50 screen with up to 6,400 characters would completely refresh in a quarter of a second but partial refreshes of course are faster still. We can also run at a much higher baud-rate too, but 230,400 was chosen as a balance between speed and compatibility with terminals etc.
There is also the possibility of implementing text VGA, even a 80x40 only needs 3,200 bytes for the character buffer and a PS/2 keyboard could be connected. So imagine a tiny Prop board, even the +P8, as a stand-alone development system. Alternatively we have a Prop as the "terminal" complete with VGA and keyboard that is connected serially to the target but it's the target that holds the source files and development environment.
Now the original intent of announcing the HELP function was also to call for HELP, from interested Tachyonites who will be able to sift through the source codes and create HELP: stubs for most of the main words at least. Even if the wording is not totally correct it's a start in the right direction and these things can be refined later. Some of you already have edit permissions for the source code but anyone else who would like to contribute then please let me know.
The general format for a help stub is fairly simple, to Tachyon it looks like a comment block but when the source code files are on SD or Flash then this section is scanned by the MAKEHELP word (not implemented yet) which builds a word index and pointers and offset to the source file. So when we are connected to the target system we can type HELP FOPEN$ and get:
HELP: FOPEN$ ( namestr -- sector )
Open the file with the 8.3 name and return with its sector or 0 if failed
The variable fstat can be checked for more information if there was an error
Execution time ~ 10ms
Usage: " SYSLOG.TXT" FOPEN$ IF etc etc
}
Or SHOW FOPEN$ will reveal the source code as well:
HELP: FOPEN$ ( namestr -- sector )
Open the file with the 8.3 name and return with its sector or 0 if failed
The variable fstat can be checked for more information if there was an error
Execution time ~ 10ms
Usage: " SYSLOG.TXT" FOPEN$ IF etc etc
}
pub FOPEN$ ( namestr -- sector )
FCLOSE
DUP C@
IF --- skip null name
DUP C@ "/" = IF 1+ THEN --- ignore leading / in file name
DUP LEN$ #12 >
IF "!" fstat C! DROP FALSE EXIT THEN --- abort with ! status if name is too long
DUP FILE$ $! --- set the name for this file
>F83 DIR? DUP --- find the dir entry
IF FOPEN# ( sector ) --- open the file from the dir entry
ELSE "?" fstat C! --- else ? not found
THEN
ELSE
DROP FALSE "?" fstat C!
THEN
;
Now that I have the dictionary indexed and stored in a file there is a lot more room available for more enhancements and applications. The HELP feature therefore becomes part of the interactive development and if I implement a text editor, maybe just via the terminal with VT100/ANSI controls formatting then it's possible that as we type or select a word that the HELP is automatically displayed in a footer section, especially if we have 50 terminal lines on the screen. At 230,400 baud the terminal screen refreshes quite fast so that a 128x50 screen with up to 6,400 characters would completely refresh in a quarter of a second but partial refreshes of course are faster still. We can also run at a much higher baud-rate too, but 230,400 was chosen as a balance between speed and compatibility with terminals etc.
There is also the possibility of implementing text VGA, even a 80x40 only needs 3,200 bytes for the character buffer and a PS/2 keyboard could be connected. So imagine a tiny Prop board, even the +P8, as a stand-alone development system. Alternatively we have a Prop as the "terminal" complete with VGA and keyboard that is connected serially to the target but it's the target that holds the source files and development environment.
So, any volunteers?
Okay, I start writing HELP for all the words I know how to use in EXTEND.fth
Recently I reclaimed a big chunk of ram by coming up with a method or compacting the dictionary into a file on the SD card. Now that I am shipping IoT5500 modules along with the +P8 Propeller module I wanted to have these preloaded with everything including the networking, however I'm not shipping these with microSD cards so I can't have the dictionary there, so what do I do? Well I thought about it and decided that since the dictionary file only takes up 32k that I could use the upper 32k of EEPROM and since the one fitted can work at 1MHz then it wouldn't be too much slower than SD. In fact the 512 byte "sector" load from EEPROM could be cut short once I encounter a few blank bytes, so it might be even faster.
The EPRINT won't be used in this version as it really only saves around 1.5kB anyway and I am moving the system parameters from $FF00 over to $FFC0 so all references now will be from that address. I'm still doing some testing but the updates to the sources will filter through soon.
Now, there is this one big question I want to ask, since the eeprom file is really 64k and not 32k is there one of the Spin tools or something that can load more than 32k?
Now, there is this one big question I want to ask, since the eeprom file is really 64k and not 32k is there one of the Spin tools or something that can load more than 32k?
I believe SimpleIDE's loader will load programs into the upper 1/2 of 64K EEPROMs. It may be simpler to just make a stand-alone Spin program that writes one or more DAT sections to the upper 32K of the EEPROM. You can use the FILE statement to include a binary file in a DAT section. That way, you'd just download and run this program from RAM to write the upper 32K of the EEPROM, then download and write the main module to the lower 32K.
Now, there is this one big question I want to ask, since the eeprom file is really 64k and not 32k is there one of the Spin tools or something that can load more than 32k?
maybe load the high EEPROM with a few lines of TACHYON from SD. If the loader code resides in conventional dictionary after COMPACT this should work.
The SD slot is there anyhow - isn't it?
you move from 128 sectors down to 64 sectors for this? to fit th 32k ?
so it is not just moving the dictionary file directly to EEPROM storage?
maybe load the high EEPROM with a few lines of TACHYON from SD. If the loader code resides in conventional dictionary after COMPACT this should work.
The SD slot is there anyhow - isn't it?
you move from 128 sectors down to 64 sectors for this? to fit th 32k ?
so it is not just moving the dictionary file directly to EEPROM storage?
I want to be able to provide an image that is also preloaded onto my modules that does not require an SD card at the time. There is no problem in production as I just load the eeprom directly from another Prop configured as a production programmer. However the problem is that if I deploy a new binary then how does the end user load it simply if they do not have Tachyon already on it or it has been corrupted? With Tachyon preloaded it is easy enough to receive a hex file directly into EEPROM although I'm not a great fan of that because if there's an error then you have to go back to Prop's bootloader anyway. I would really love a EEPROM that had a protected area for a bootloader but it's a write anything or write nothing with the WP pin.
Maybe I will come up with a bootloader scheme that preserves a Tachyon bootloader in eeprom and loads and validates a hex load into eeprom. Even if it's complete garbage that's loaded in it will still be under the control of the bootloader which can check for a valid image. I will think on this. Either way the standard Prop bootloader has the 32k all or nothing limitation. So a bootloader could be loaded in with the Spin tool and then the eeprom image under the control of the bootoader is probably the way to go.
btw, the current dictionary indexing scheme creates a 7-bit index which from all my tests show this is sufficient and gives a good spread over the sectors with only 1 or 2 not utilized and one that is up to 75% utilized in a full system fully compacted, but no sectors are in danger of overflow. Besides I think if I tweak the compact routine that if it finds a sector fully utilized then it can leave the word in conventional dictionary space since the hybrid dictionary scheme allows for that.
I want to be able to provide an image that is also preloaded onto my modules that does not require an SD card at the time. There is no problem in production as I just load the eeprom directly from another Prop configured as a production programmer. However the problem is that if I deploy a new binary then how does the end user load it simply if they do not have Tachyon already on it or it has been corrupted? With Tachyon preloaded it is easy enough to receive a hex file directly into EEPROM although I'm not a great fan of that because if there's an error then it you have to go back to Prop's bootloader anyway. I would really love a EEPROM that had a protected area for a bootloader but it's with write anything or write nothing with the WP pin.
Maybe I will come up with a bootloader scheme that preserves a Tachyon bootloader in eeprom and loads and validates a hex load into eeprom. Even if it's complete garbage that's loaded in it will still be under the control of the bootloader which can check for a valid image. I will think on this. Either way the standard Prop bootloader has the 32k all or nothing limitation. So a bootloader could be loaded in with the Spin tool and then the eeprom image under the control of the bootoader is probably the way to go.
I'm not sure if someone has already mentioned this but Andre' LaMothe's Hydra had a utility for managing data in EEPROMs called the Hydra Asset Manager. Maybe it could be used to write your Tachyon images?
Edit: Oops, I guess someone already mentioned this in message 1763. Sorry! Also, it seems to require .NET.
I believe SimpleIDE's loader will load programs into the upper 1/2 of 64K EEPROMs. It may be simpler to just make a stand-alone Spin program that writes one or more DAT sections to the upper 32K of the EEPROM. You can use the FILE statement to include a binary file in a DAT section. That way, you'd just download and run this program from RAM to write the upper 32K of the EEPROM, then download and write the main module to the lower 32K.
Unless I missed something, "SimpleIDE's loader" is actually propeller-load which is part of the PropGCC toolchain. While it does know how to write to EEPROM space above 32k, it doesn't really have a general way of doing that. It writes to upper EEPROM memory when it writes XMM images to EEPROM and it also has a mechanism for writing COG drivers to upper EEPROM memory to be loaded later into COGs. It would probably be a good idea to add support for writing images at arbitrary offsets but that feature isn't in the current version of propeller-load.
Unless I missed something, "SimpleIDE's loader" is actually propeller-load which is part of the PropGCC toolchain. While it does know how to write to EEPROM space above 32k, it doesn't really have a general way of doing that. It writes to upper EEPROM memory when it writes XMM images to EEPROM and it also has a mechanism for writing COG drivers to upper EEPROM memory to be loaded later into COGs. It would probably be a good idea to add support for writing images at arbitrary offsets but that feature isn't in the current version of propeller-load.
The PC resident loader almost needs to automatically load a bootloader onto the Prop, even in RAM, which can then accept any size image or offset. This is quite doable I would think although I'm not familiar with SimpleIDE's source but certainly makes sense and could also mean that since the Prop is running at full speed with the bootloader that the 64k or greater image could be loaded into the eeprom much faster than otherwise possible with the RCFAST pseudo-asynch mode of the Prop's bootloader. It would be really good to work out a standard way of doing this so we don't end up with a hodgepodge of mixed loading schemes.
edit: the IDE could read the clock settings from the binary and pass this to the bootloader to switch to the correct clock settings.
btw: where did this subject title "Re: Telewizja przesmylowa" come from?
The PC resident loader almost needs to automatically load a bootloader onto the Prop, even in RAM, which can then accept any size image or offset. This is quite doable I would think although I'm not familiar with SimpleIDE's source but certainly makes sense and could also mean that since the Prop is running at full speed with the bootloader that the 64k or greater image could be loaded into the eeprom much faster than otherwise possible with the RCFAST psuedo-asynch mode of the Prop's bootloader. It would be really good to work out a standard way of doing this so we don't end up with a hodgepodge of mixed loading schemes.
As I said, I don't think SimpleIDE itself does any loading but propeller-load does load a "helper" program into Propeller RAM which it then communicates with using an xmodem-like protocol to write the actual EEPROM data. As you say, it can do that much faster than the ROM-based loader built into the Propeller.
I've posted the EEWORDS.FTH to Dropbox and this seems to work quite well. Seeing that it doesn't require the SDFS then this module can be loaded very early, just after EXTEND.FTH in fact. Performance is very good as although it works in a similar way to the SD file version in that it uses sectors or blocks of 512 bytes, the EEPROM version will load or save a partial block when it encounters blanks at the logical end of the block.
I haven't done a proper 1MHz I2C driver yet but have just patched the main read and write routines so that they run faster but these will be improved, not that it seems to make any difference at present.
Rather than leave EEWORDS.FTH as a separate module I may just incorporate it directly into EXTEND.FTH to simplify building a kernel. Next thing to do is to make sure the compiler generates direct calls for when it runs out of vectors so that an implicit call to a functions generates a ACALL bytecode plus two bytecodes for the 16-bit direct address.
Since the dictionary can be compacted and indexed easily in the upper 32K of a 64K EEPROM, there is also no more need for EPRINT which stored the literal strings in this area. The EPRINT routine was only saving around 1K effectively, maybe 2K at a pinch, and now that area is being used for the dictionary so EPRINT is really deprecated in favor of EEWORDS. There's probably not much need for SDWORDS either but it's an option and I probably want the operation of these two very similar dictionary modules made as transparent as possible at some time.
Having the dictionary in EEPROM also simplifies burning the binary image into Props as I don't have to worry about Tachyon not responding because the SD card is removed. I normally load the EEPROM directly so a 64K file is not a problem. To make it easier to load in from a PC I am testing a bootloader which is actually part of the console receive routine which runs in it's own cog. The idea is that on a new load that the Tachyon kernel can still be loaded with the Prop tool as per usual but the main difference is that the serial routine is independent of Forth and can recognize an Intel hex load file and automatically burn each line into EEPROM when the checksum is correct. So it's a two part load for a clean system, the Prop tool gets the kernel loaded but not the compacted dictionary, so after boot Tachyon doesn't recognise any words but the hex file can be loaded in (pasted as text) through the console port.
Comments
If you can't swim in Spin you will definitely sink in Forth. There are so many tutorials and examples and support for Spin that even if it's your first time programming you should be able to pick it up as long as you go through it methodically, not trying to jump the gun, just wishin' n Hopin'.
Not saying Forth is hard but it's a different mindset and with embedded programming you need to know your hardware, it's not like a PC with all it's drivers and API layers insulating the programmer from all those "details" etc. Go through the Spin tutorials from the beginning, simple stuff, but make sure you totally grok it before you move on to the next step. You've been given some links I see and only you can really help yourself. If you don't then you will never progress and get that satisfaction from learning and making it all happen.
There are a lot of younger ones these days that have been "spoilt" on a diet of easy 123 tech that makes it look like you are a genius, but someone else had already done the amazing stuff and packaged it up, the kids just play with it and rearrange it. Do you really want to be in this game? ...don't be a kid, man up.
And EXTEND.FTH gives me a fault on Tachyon V2.3.spin.
It was that sunday.
2.4 is the way to go but only change the baud rate, do not touch the clock settings as they automatically adjust for 5 or 10MHz. Your CON block should look like this:
Re OPCODE: There were options in EXTEND.fth for V2.3 and V2.4 but there is really no reason any longer to use 2.3.
When I changed the baud in ver. 2.3 it works.
There is no difference in V2.4 in this regard. Can you post the file you used. BTW, what hardware are you using?
and the latest extend.fth, I are up running again.
I am using a Gadget Gangster Propeller Platform without any extra.
Then while optimizing I created a stupid bug.
while
var C~ is 0 var C!
var C~~ is not 1 var C! !!! ;-) it is -1 var C! instead !!!
anyway here the code:
https://docs.google.com/document/d/1AwbcLGf53UOlMXBO7mGlk6_0YorKoPKYFvtiur6X_zM/pub
LAP 1W.SCAN LAP .LAP 28 09 6C CD 04 00 00 82 28 F7 E6 BF 04 00 00 3A Time: 56.01ms ok for discovering 2 DS18B20 sensors { \ print the table of 1W.1Wdevs discovered by 1W.SCAN in Table format for inclusion in Tachyon code 1W..1WdevsT \ gives TABLE 1W.my1Wdevs $28 | $09 | $6C | $CD | $04 | $00 | $00 | $82 | $28 | $F7 | $E6 | $BF | $04 | $00 | $00 | $3A | \ show 2 tmperature measurements 1W.my1Wdevs 2 1W.SHOWTEMPSM +023.00'C +023.18'C +023.00'C +023.18'C +023.31'C +023.18'C +024.00'C +023.18'C +024.50'C +023.18'C +025.00'C +023.18'C +025.37'C +023.18'C +025.81'C +023.18'C +026.12'C +023.18'C +026.18'C +023.25'C +026.25'C +023.75'C +026.06'C +024.18'C +025.87'C +024.62'C +025.75'C +025.06'C +025.62'C +025.31'C ok } 00:00:16 End of source code, 0047 lines processed and 0000 errors found MODULES LOADED: 46C8: 1WIRE.fth 1-wire interface 121025:0000 3C6A: EASYFILE.fth FAT32 Virtual Memory Access File System Layer V1.1 140626-2100 34F9: SDCARD.fth SD CARD Toolkit - 140626.1400 1880: EXTEND.fth Primary extensions to TACHYON kernel - 140703-14OO NAMES: $546B...743E for 8147 (0230 bytes added) CODE: $0000...47E1 for 10254 (0281 bytes added) CALLS: 0244 vectors free RAM: 3210 bytes free ( 1WireMJB.fth ) ok 00:00:31 End of source code, 0146 lines processed and 0000 errors found MODULES LOADED: 47E1: 1WIREMJB.fth 1-wire interface extensions MJB 141123:2230 NAMES: $5332...743E for 8460 (0313 bytes added) CODE: $0000...49D9 for 10445 (0504 bytes added) CALLS: 0221 vectors free RAM: 2393 bytes free Total: Vectors used: 46 RAM used: 524 bytes@frida - now we can compare our codes ... to learn from each other ( I see you have a CRC .. :-) )
@Peter - thanks for the base code
( 1-Wire.fth ) { first part is base code from Peter Jakacki with minor adaptions second part is romsearch extensions by MJB Markus Baer } TACHYON [~ : 1WIRE.fth ." 1-wire interface 121025:0000 " ; { The 1-Wire interface is implemented in bytecode so it does not require a special cog to handle the timing. Testing is being done on DS1820+ and DS2450S+ chips. CHANGELOG: 121025 Fixed bugs in routines Added strong pullup after writing to provide power for parasitic devices Add some of Brian Riley's code Allow for redirection of DQ line } ( I/O DEFINITIONS ) LONG dq pri DQ@ dq @ ; pub DQ! dq ! ; #P14 |< DQ! \ set the default pub 1W.RESET ( -- ack ) DQ@ OUTCLR 1 ms DQ@ INPUTS #60 us DQ@ IN 0= #400 us ; pub 1W.BITWR ( iomask dat -- iomask dat/2 ) OVER OUTCLR \ pulse low for 1us SHROUT \ output next data bit then shift data right #60 us \ minimum cycle time OVER OUTSET \ Force line high at end of slot (rather than float) ; pub 1W.BITRD ( iomask dat -- iomask dat+ ) OVER OUTCLR OVER INPUTS \ pulse line low for 1us then float 8 us SHRINP \ assemble another bit by right shifting #50 us \ MJB OVER OUTSET \ Force line high at end of slot (rather than float) ; \ Transmit 8-bit lsb first pub 1W! ( dat -- ) DQ@ SWAP \ mask and data ( iomask dat ) 8 FOR 1W.BITWR NEXT \ write 8 bits lsb first 2DROP \ discard mask and used data ; \ Receive 8-bit data lsb first pub 1W@ ( -- dat ) DQ@ 0 \ initial mask and data ( iomask dat ) 8 FOR 1W.BITRD #45 us NEXT NIP #24 SHR \ right justify ( dat ) ; \ Get bytes from bus and print as hex bytes pub .1W ( bytes -- ) FOR 1W@ .BYTE SPACE NEXT ; pub READROM $33 1W! ; \ send read ROM command code pub SKIPROM $CC 1W! ; \ send skip ROM command code pub MATCHROM $55 1W! ; \ command to match an ID to a specific device pub CONVERTT $44 1W! ; \ commands all Temp sensors to start measurement (750 ms) pub READSCR $BE 1W! ; \ starts to: dumps 9 bytes (8 plus CRC) of device scratchpad pub 1WSCMD 1W.RESET DROP SKIPROM ; \ reset, skip ROM for single sensor only and prepare for next command pub RDROMH 1W.RESET DROP READROM 8 .1W ; \ read and print 8 byte ROM code pub RDSCRH 1WSCMD READSCR 9 .1W ; \ reset, skip ROM, read and print Scratchpad 9 bytes pub TEMP@ ( -- temp ) \ read first 2 bytes from scratchpad and assemble to temperature value on TOS ( binary, low nibble is fraction ) READSCR 1W@ 1W@ B>W \ combine 2 bytes to 1 long on stack ; pub .TEMP ( temp -- ) DUP $0F AND SWAP 4 SHR \ put whole degrees in one long and fraction in another $830A .NUM \ print whole number "." EMIT \ print decimal point #100 * 4 SHR \ turn binary bits to 100ths $020A .NUM \ print decimal ." 'C " ; \ 18B20 diagnostic routines : SHOWTEMP ( reads annd displays a single DS18B20 alone on a 1-W bus ) 1WSCMD CONVERTT #750 ms 1WSCMD TEMP@ DUP CR .TEMP SPACE 4 SHR 0 DO ." *" LOOP ; : SHOWSP ( reads annd displays a single DS18B20 SCRATCHPAD alone on a 1-W bus ) 1WSCMD CONVERTT #750 ms 1WSCMD RDSCRH ; : SHOWTEMPS BEGIN SHOWTEMP 2 seconds KEY? AND UNTIL ; ]~ END { DEMO USAGE SHOWTEMPS +036.81'C ************************************ +036.62'C ************************************ +036.06'C ************************************ +035.68'C *********************************** +034.62'C ********************************** +034.68'C ********************************** +034.25'C ********************************** +033.31'C ********************************* +032.87'C ******************************** +032.50'C ******************************** +032.81'C ******************************** +033.12'C ********************************* +033.25'C ********************************* +033.31'C ********************************* +033.43'C ********************************* +033.50'C ********************************* +033.68'C ********************************* +033.68'C ********************************* +033.62'C ********************************* +032.87'C ******************************** +031.62'C ******************************* +031.00'C ******************************* +028.12'C **************************** +026.62'C ************************** +026.31'C ************************** +025.81'C ************************* +024.43'C ************************ +024.18'C ************************ +022.37'C ********************** +021.68'C ********************* +021.81'C ********************* +022.18'C ********************** +022.50'C ********************** +023.18'C *********************** +023.93'C *********************** } { To check the ROM of a single device: 1WRESET DROP READROM } ]~ END \ here starts the code by MJB Markus Baer ( 1WireMJB.fth ) TACHYON [~ : 1WIREMJB.fth ." 1-wire interface extensions MJB 140525:0000 " ; \ CREATE SMALL \ define SMALL before a load to specify a SMALL build to limit the sections included IFNDEF SMALL { \ DESCRIPTION \ \ Maxim 1-wire ROM Search algorithm \ straight forward implementation \ per AN937 "Book of iButton Standards", figure 5-3 \ for TACHYON Forth 2014 by Markus Baer aka MJB @ parallax forums, \ inspired by am-forth implementation by Bradford J. Rodriguez. \ USES \ 1WIRE.fth from Tachyon Forth by Peter Jakacki \ and of course the TACHYON System (Kernel 2.3 + EXTEND) - thanks Peter \ \ ** USES from 1-wire.fth **** \ 1W.RESET ( -- ack ) \ 1W.BITWR ( iomask dat -- iomask dat/2 ) \ 1W.BITRD ( iomask dat -- iomask dat+ ) \ 1W! ( c -- ) Write one byte to the 1-wire bus. \ 1W@ ( -- c ) Read one byte from the 1-wire bus. } { if you need it ... : 1W.!N ( xN .. x1 N -- ) FOR 1W! NEXT ; \ send N characters/bytes from stack : 1W.@N ( N -- x1 .. xN ) FOR 1W@ NEXT ; \ fetch N characters/bytes to stack : 1W..ROM RDROMH ; \ print 1Wire single device ROM code } BYTE 1W.lastdisc ( used as byte variable to hold last discrepancy ) BYTE 1W.doneflag BYTE 1W.rombit ( used as byte variable, 1..64 ) BYTE 1W.discmark \ buffer for one ROM-ID 1W.romid ( 8 byte array ) 8 BYTES 1W.romid pri 1W.!rombit ( f -- set the bit 1..32 given by 1W.rombit in buffer 1W.romid to flag value f ) 1W.rombit C@ 1- 8 U/MOD ( -- f bit# byte# ) 1W.romid + ( f bit# addr ) SWAP MASK SWAP ( f bitmask addr ) ROT ( bitmask addr f ) BIT! ; pri 1W.@rombit ( -- f \ f is 0 or non-0 not necc. 1 \ fetch the bit 1..32 given by 1W.rombit from buffer 1W.romid to flag f ) 1W.rombit C@ 1- 8 U/MOD ( -- bit# byte# ) 1W.romid + C@ ( -- bit# byte ) SWAP MASK ( -- byte bitmask ) AND ; \ helper pub <>0 ( val -- 0or1 \ convert any non 0 to 1 instead of -1 as 0<> does ) IF 1 ELSE 0 THEN ; #P14 |< DQ! \ for my setup MJB, this is the pin my 1-wire bus is attached to 4.7k or 5k pullup required \ single bit operations to read and write 1-wire bus pri 1W.BIT@ ( -- bit ) DQ@ 0 1W.BITRD NIP <>0 ; \ gives bit as 0 or 1 pri 1W.BIT! ( bit -- ) DQ@ SWAP 1W.BITWR 2DROP ; \ takes bit as 0 or 1 { for test pri .rombit ( bitnumber -- ) 1W.rombit C! 1W.@rombit . ; \ print 1W.rombit value pri .RB ( -- ) 1W.@rombit . ; pri .romid ( -- ) 1W.romid 8 ADO I C@ . SPACE LOOP ; } BYTE 1W.devcnt LONG 1W.devaddr TABLE 1W.1Wdevs #8 #8 * ALLOT \ prepare for 8 devices here, change as appropriate pri 1W.NEWSEARCH ( -- \ clear variables used in search ) 1W.lastdisc C~ 1W.doneflag C~ 1 1W.rombit C! \ 1..64 1W.romid #8 ERASE 1W.devcnt C~ \ set device count to 0 ; pri 1W.SEARCHROM ( -- f ) ( search for one additional device. Returns 0 if done or 1 if more to come. see 1W.SCAN ) 0 ( default return value ) ( 0 ) 1W.doneflag C@ IF 1W.doneflag C~ \ clear doneflag EXIT ( leaves 0 ) THEN 1W.RESET IF ( presence signal detected? ) 1 1W.rombit C! ( yes: set ROM bit index to 1 ) 1W.discmark C~ ( set discrepancy marker to 0 ) ( 0 ) $F0 1W! ( send search command on bus ) ( 0 ) BEGIN 1W.BIT@ 1W.BIT@ 2* + ( 0 BA ) \ 2 bits A & B in bit pos 0 AND 1 DUP $03 = ( 0 BA flag ) IF ( bitA = bitB = 1?) DROP 1W.lastdisc C~ \ clear EXIT ( leaves 0 ) ELSE ( 0 BA ) ?DUP 0= ( 0 BA false | 0 true ) IF ( bitA = bitB = 0?) ( 0 ) 1W.rombit C@ 1W.lastdisc C@ = ( 0 flag ) IF 1 1W.!rombit ( 0 ) ELSE 1W.rombit C@ 1W.lastdisc C@ > ( 0 flag ) IF 0 1W.!rombit 1W.rombit C@ 1W.discmark C! ( 0 ) ELSE 1W.@rombit 0= ( 0 flag ) IF 1W.rombit C@ 1W.discmark C! ( 0 ) THEN THEN ( 0 ) THEN ( 0 ) ELSE ( 0 BA ) $01 AND ( bit A value , bit B is inverse so we don't need it ) 1W.!rombit ( 0 ) THEN THEN ( 0 ) 1W.@rombit <>0 \ gives 0 or 1 as logical values instead of 0 -1 1W.BIT! ( DROP what is this drop for ??? )( send ROM bit to bus ) 1W.rombit C@ 1+ DUP 1W.rombit C! ( 0 1W.rombitVal ) \ increment 1W.rombit index $40 > UNTIL \ check > 64 ( 0 ) 1W.discmark C@ DUP 1W.lastdisc C! ( 0 discmark ) 0= IF 1 1W.doneflag C! ( 0 ) ELSE 1+ ( set return value to 1 = true ) THEN ELSE ( no presence signal ) 1W.lastdisc C~ \ set 0 THEN ; \ calc the CRC given start and length of string/bytes. If string includes the CRC the result is 0 for OK \ Peter's 16 bit CRC adapted pub CRC8 ( str cnt -- crc ) 0 ROT ROT ADO I C@ SWAP 8 FOR 2DUP XOR 1 AND ROT 2/ ROT 2/ ROT IF $8C XOR THEN NEXT NIP LOOP ; \ Demonstrates how to use SEARCHROM to find all attached devices and store them in table 1W.1Wdevs pri 1W.PRINTromid ( addr -- ) \ print the ROM-ID at address 8 ADO I C@ .BYTE SPACE LOOP CR ; pub 1W.SCAN ( -- ) \ scan for any devices on 1-wire bus and store them in table 1W.1Wdevs 1W.NEWSEARCH 1W.1Wdevs 1W.devaddr ! \ begin at start of table CR BEGIN 1W.SEARCHROM 1W.romid 1W.PRINTromid \ print it 1W.romid 8 CRC8 IF ." CRC mismatch above" CR THEN \ ' CMOVE ( src dst cnt -- ) Copy bytes from src to dst address for cnt bytes using increment for up or down 1W.romid 1W.devaddr @ 8 CMOVE \ SEARCHROM could be optimized to store directly to table, \ by making 1W.romid a CONST pointing to the table entry and changing it for each run 1W.devaddr DUP @ 8 + SWAP ! \ increment the address to store by 8 bytes 0= UNTIL CR ; { test it on 2 devices LAP 1W.SCAN LAP .LAP 28 09 6C CD 04 00 00 82 28 F7 E6 BF 04 00 00 3A Time: 56.01ms ok for discovering 2 DS18B20 sensors 1W.1Wdevs $20 DUMP 1W.1Wdevs $20 ADO I C@ .BYTE SPACE LOOP 1W.1Wdevs $16 ERASE } { some demo / test code pub 1W..1Wdevs \ print the table of 1W.1Wdevs discovered by 1W.SCAN ( if table is not full ) 1 1W.1Wdevs CR BEGIN \ BEGIN condition WHILE code REPEAT DUP C@ WHILE ( 1 1W.1Wdevs ) \ works only if there is at least one element in table which is 0ed SWAP DUP .BYTE ":" EMIT SPACE 1+ SWAP DUP 1W.PRINTromid 8 + REPEAT DROP ; pub 1W..1WdevsT \ print the table of 1W.1Wdevs discovered by 1w.scan in Table format for inclusion in Tachyon code 1W.1Wdevs CR ." TABLE 1W.my1Wdevs" CR BEGIN \ BEGIN condition WHILE code REPEAT DUP C@ WHILE ( 1 1W.1Wdevs ) SPACE DUP 8 ADO ." $" I C@ .BYTE ." | " LOOP CR \ ADO ( from cnt -- ) 8 + REPEAT DROP ; \ print the discovered 1Wire-IDs 1W..1Wdevs \ print the table of 1W.1Wdevs discovered by 1w.scan in Table format for inclusion in Tachyon code 1W..1WdevsT } \ 1 Wire Multibus CoMmanD takes the address of a ROM code and performs a matchROM command pub 1W.MCMD ( -- ) 1W.RESET DROP MATCHROM ; \ reset and send Match ROM command pub 1W.MATCH ( addr -- ) \ address sensor with 64-bit rom code given at addr then ready for next command 1W.MCMD 8 ADO I C@ 1W! LOOP ; \ IFNDEF SMALL \ DS18B20 diagnostic routines : 1W.SHOWTEMPM ( tableaddr n -- \ reads and displays a DS18B20 on a multibus. n is the index into the table of devices 1W.1Wdevs ) \ 1W.1Wdevs table of discovered 1W devices with SEARCHROM 1- 8 * + \ calculate start of ROM code to address DUP 1W.MATCH CONVERTT #750 ms \ 1W.MATCH TEMP@ DUP .TEMP 1W.MATCH TEMP@ .TEMP \ SPACE 4 SHR 0 DO ." *" LOOP \ bar graph ; : 1W.SHOWSPM ( tableaddr n -- \ reads and displays a DS18B20 SCRATCHPAD on a multibus n is the index into the table of devices 1W.1Wdevs ) \ 1W.1Wdevs table of discovered 1W devices with SEARCHROM 1- 8 * + \ calculate start of ROM code to address DUP 1W.MCMD CONVERTT #750 ms 1W.MCMD RDSCRH ; \ for sensor# from I = 1 to n from ROM-Code table given show the temp readings cyclically until key pressed : 1W.SHOWTEMPSM ( tableaddr n -- ) CR BEGIN 1 OVER ADO \ from 1 to n OVER I 1W.SHOWTEMPM SPACE LOOP CR 2 seconds KEY? AND \ AND required, since KEY? ( -- key flag ) UNTIL 2DROP ; } \ end IFNDEF SMALL { the generated table ready to paste into Tachyon again TABLE 1W.my1Wdevs $28 | $09 | $6C | $CD | $04 | $00 | $00 | $82 | $28 | $F7 | $E6 | $BF | $04 | $00 | $00 | $3A | 1W.my1Wdevs 2 1W.SHOWTEMPSM \ show the temperature for my 2 sensors \ next line works directly after romsearch from found IDs \ 1W.1Wdevs 2 1W.SHOWTEMPSM 1W.1Wdevs 2 1W.SHOWTEMPSM +023.00'C +023.18'C +023.00'C +023.18'C +023.31'C +023.18'C +024.00'C +023.18'C +024.50'C +023.18'C +025.00'C +023.18'C +025.37'C +023.18'C +025.81'C +023.18'C +026.12'C +023.18'C +026.18'C +023.25'C +026.25'C +023.75'C +026.06'C +024.18'C +025.87'C +024.62'C +025.75'C +025.06'C +025.62'C +025.31'C ok } ]~ ENDI have made some changes in it, to get it to work.
There are some thing I do not understand, but at the moment, I dont need these functions.
Have a look at the pictures. I now have my 1-wire up running again.
Now my watchdog have played around with TACHYON a bit.
Next thing I found out was, change fit to 497 and insert a nop after RESET or somewhere around.
But today I moved "sdbuf long @RESET+s" to a new place, and wupti now it runs.
I moved it form line 3603 to line 3732 right after the last instr.
I don't think it like's a long inbetwen instr.
That sdbuf line is just a long constant used by MYOP which in itself is basically just used at present to speed up some virtual memory addressing. So a long constant (more than a 9-bit immediate) is just another location in cog memory and it can be pretty much anywhere out of the way.
By changing fit to 497 and inserting an extra long it will actually allow a LOADMOD to overflow into the special purpose registers, specifically the PAR register, not good. But what are you trying to achieve? When I get a new car I just like to drive it around and take it on a trip to see what it can do first rather than try to improve it by messing under the hood
But I shall not disturb you again.
Have a nice day.
Mean what you say but don't be mean when you say it, and I wasn't so I'm sorry if it came across that way, so there is no need to take offense and besides we are all reasoning adults here. Your last two posts left me scratching my head trying to figure why you had to do what you did, and what made you target some obscure lines of code. It's like you are tinkering under the bonnet immediately because you are trying to start the car with the wrong set of keys.
As far as I can tell these were not the current sources as I checked those and they compile perfectly. The google docs version is always current of course but if you work off the "published" version you may need to refresh the page. But if there is a problem then it pays to provide a little more information as I rely on feedback to improve these sources or perhaps even the manner in which they are updated.
Well, to be specific, I need help in making up a help file that will reside on the SDFS so that in combination with SDWORDS etc we can have a lot more at our fingertips. Although all words compiled after SDFS is in place could have a structure that included help information which would be extracted and written to the HELP file as the code was compiled, there is still all the code up to and including the SDFS ( SDCARD + EASYFILE ) that we need to get the help information for. Now either we just create a file from scratch or perhaps even pass the source code for the Tachyon kernel, EXTEND, headers, SDCARD and EASYFILE back through a help file extractor so that only the source code needs to have this information in the first place. Of course we would just have the files loaded onto the SD card to make it easy to parse or it could even be loaded serially as needed.
The help file structure itself has not been fully defined but normally it doesn't require any super-fast lookup as it is normally invoked interactively from the console so it may just end up as an unstructured text file with control codes to mark the words.
But wait!, it's possible perhaps that the help file is in fact all the source code files themselves and the help extractor could find code tags to mark each word and help section then build an index file which otherwise would take a bit of time to search through a few megabytes. This means we could have a HELP.IDX file which points to the correct source code file and position so that we don't need to have one large help file, just the source code files themselves with included help information.
How would this look then?
[B]HELP FOPEN$[/B] HELP: FOPEN$ ( namestr -- sector ) Open the file with the 8.3 name and return with it's sector or 0 if failed The variable fstat can be checked for more information if there was an error Execution time ~ 10ms Usage: " SYSLOG.TXT" FOPEN$ IF etc etc } pub FOPEN$ ( namestr -- sector ) FCLOSE DUP C@ IF --- skip null name DUP C@ "/" = IF 1+ THEN --- ignore leading / in file name DUP LEN$ #12 > IF "!" fstat C! DROP FALSE EXIT THEN --- abort with ! status if name is too long DUP FILE$ $! --- set the name for this file >F83 DIR? DUP --- find the dir entry IF FOPEN# ( sector ) --- open the file from the dir entry ELSE "?" fstat C! --- else ? not found THEN ELSE DROP FALSE " " fstat C! --- null string, so not found of course THEN ;The HELP: starts a comment section up to the } but the extractor uses HELP: as a code tag and includes all information up to the next blank line (or perhaps another code tag but I'm trying to avoid that).
So please Tachyonites, any ideas on how this can be handled but more importantly can you provide some help adding this help information and tags to the source codes?
TIA, Peter
Seems that embedded HELP in the source comments the source code as well as renders HELP from the console. I will fill out what I know/understand when the design decision is made on which way HELP should work. This will really HELP MJB who has been wishing for more documentation on the sources in general. Me too.
Good, I think the HELP: embedded into the source code and having HELP find the source code section from an index file is best. That way only a MAKEHELP or something needs to be run after a build to generate the index file and all the documentation stays with the sources. This format looks flexible enough and having the actual source code come up is a bonus.
MAKEHELP would scan through all .FTH files on SDFS to locate these sections but since it can have multiple files open at a time it should be quick enough in generating the index file.
yes , we have been talking about HELP / DOC generation from source.
I opt for the help information inside the source.
Mostly because my development mode would NOT need the help on the prop itself usually.
I keep ALL the Tachyon files open simultaneously in Notepad++ so I can easily do a 'search all files' for a pub XXX pr pri XXX to find the definition.
I also write a Notepad++ extension for syntac coloring and for listing the definitions in a clickable index list aside teh edit window.
this is pretty neat
so structured in file help and doc YES
on SD - well fine - I can use FTP to get it when running in NW-mode
but editing and accessing help will mostly be in the IDE, not the tachyon terminal
EXCEPT: a quick way to get the arguments of a word listed.
ARGS <word> to see what it expects on the stack and leaves after completion
HELP <word> just lists args + top doc
SOURCE <word> lists complete definition incl comments
It is my intent to build help info in the source but I'm not always tethered to a PC and sometimes I only have my phone so having a system that I can perhaps even edit source on via Bluetooth/serial/telnet is always a bonus.
As for HELP words it should never become too complicated otherwise you will need HELP HELP etc. I think if we type HELP then we expect at least the help info and perhaps something as simple as a ^? ($1F) after a word would just list the parameters. The source listing may just be SHOW <word> which would also include the help info. Then there is the EDIT <word> which would take you straight to the correct source file and word
The general format for a help stub is fairly simple, to Tachyon it looks like a comment block but when the source code files are on SD or Flash then this section is scanned by the MAKEHELP word (not implemented yet) which builds a word index and pointers and offset to the source file. So when we are connected to the target system we can type HELP FOPEN$ and get:
Or SHOW FOPEN$ will reveal the source code as well:
HELP: FOPEN$ ( namestr -- sector ) Open the file with the 8.3 name and return with its sector or 0 if failed The variable fstat can be checked for more information if there was an error Execution time ~ 10ms Usage: " SYSLOG.TXT" FOPEN$ IF etc etc } pub FOPEN$ ( namestr -- sector ) FCLOSE DUP C@ IF --- skip null name DUP C@ "/" = IF 1+ THEN --- ignore leading / in file name DUP LEN$ #12 > IF "!" fstat C! DROP FALSE EXIT THEN --- abort with ! status if name is too long DUP FILE$ $! --- set the name for this file >F83 DIR? DUP --- find the dir entry IF FOPEN# ( sector ) --- open the file from the dir entry ELSE "?" fstat C! --- else ? not found THEN ELSE DROP FALSE "?" fstat C! THEN ;Now that I have the dictionary indexed and stored in a file there is a lot more room available for more enhancements and applications. The HELP feature therefore becomes part of the interactive development and if I implement a text editor, maybe just via the terminal with VT100/ANSI controls formatting then it's possible that as we type or select a word that the HELP is automatically displayed in a footer section, especially if we have 50 terminal lines on the screen. At 230,400 baud the terminal screen refreshes quite fast so that a 128x50 screen with up to 6,400 characters would completely refresh in a quarter of a second but partial refreshes of course are faster still. We can also run at a much higher baud-rate too, but 230,400 was chosen as a balance between speed and compatibility with terminals etc.
There is also the possibility of implementing text VGA, even a 80x40 only needs 3,200 bytes for the character buffer and a PS/2 keyboard could be connected. So imagine a tiny Prop board, even the +P8, as a stand-alone development system. Alternatively we have a Prop as the "terminal" complete with VGA and keyboard that is connected serially to the target but it's the target that holds the source files and development environment.
So, any volunteers?
Okay, I start writing HELP for all the words I know how to use in EXTEND.fth
Update: can I get edit permissions for EXTEND.fth
I'll use GIT locally to add my HELP until then.
The EPRINT won't be used in this version as it really only saves around 1.5kB anyway and I am moving the system parameters from $FF00 over to $FFC0 so all references now will be from that address. I'm still doing some testing but the updates to the sources will filter through soon.
Now, there is this one big question I want to ask, since the eeprom file is really 64k and not 32k is there one of the Spin tools or something that can load more than 32k?
HAM maybe?
The SD slot is there anyhow - isn't it?
you move from 128 sectors down to 64 sectors for this? to fit th 32k ?
so it is not just moving the dictionary file directly to EEPROM storage?
I want to be able to provide an image that is also preloaded onto my modules that does not require an SD card at the time. There is no problem in production as I just load the eeprom directly from another Prop configured as a production programmer. However the problem is that if I deploy a new binary then how does the end user load it simply if they do not have Tachyon already on it or it has been corrupted? With Tachyon preloaded it is easy enough to receive a hex file directly into EEPROM although I'm not a great fan of that because if there's an error then you have to go back to Prop's bootloader anyway. I would really love a EEPROM that had a protected area for a bootloader but it's a write anything or write nothing with the WP pin.
Maybe I will come up with a bootloader scheme that preserves a Tachyon bootloader in eeprom and loads and validates a hex load into eeprom. Even if it's complete garbage that's loaded in it will still be under the control of the bootloader which can check for a valid image. I will think on this. Either way the standard Prop bootloader has the 32k all or nothing limitation. So a bootloader could be loaded in with the Spin tool and then the eeprom image under the control of the bootoader is probably the way to go.
btw, the current dictionary indexing scheme creates a 7-bit index which from all my tests show this is sufficient and gives a good spread over the sectors with only 1 or 2 not utilized and one that is up to 75% utilized in a full system fully compacted, but no sectors are in danger of overflow. Besides I think if I tweak the compact routine that if it finds a sector fully utilized then it can leave the word in conventional dictionary space since the hybrid dictionary scheme allows for that.
Edit: Oops, I guess someone already mentioned this in message 1763. Sorry! Also, it seems to require .NET.
The PC resident loader almost needs to automatically load a bootloader onto the Prop, even in RAM, which can then accept any size image or offset. This is quite doable I would think although I'm not familiar with SimpleIDE's source but certainly makes sense and could also mean that since the Prop is running at full speed with the bootloader that the 64k or greater image could be loaded into the eeprom much faster than otherwise possible with the RCFAST pseudo-asynch mode of the Prop's bootloader. It would be really good to work out a standard way of doing this so we don't end up with a hodgepodge of mixed loading schemes.
edit: the IDE could read the clock settings from the binary and pass this to the bootloader to switch to the correct clock settings.
btw: where did this subject title "Re: Telewizja przesmylowa" come from?
I haven't done a proper 1MHz I2C driver yet but have just patched the main read and write routines so that they run faster but these will be improved, not that it seems to make any difference at present.
Rather than leave EEWORDS.FTH as a separate module I may just incorporate it directly into EXTEND.FTH to simplify building a kernel. Next thing to do is to make sure the compiler generates direct calls for when it runs out of vectors so that an implicit call to a functions generates a ACALL bytecode plus two bytecodes for the 16-bit direct address.
Since the dictionary can be compacted and indexed easily in the upper 32K of a 64K EEPROM, there is also no more need for EPRINT which stored the literal strings in this area. The EPRINT routine was only saving around 1K effectively, maybe 2K at a pinch, and now that area is being used for the dictionary so EPRINT is really deprecated in favor of EEWORDS. There's probably not much need for SDWORDS either but it's an option and I probably want the operation of these two very similar dictionary modules made as transparent as possible at some time.
Having the dictionary in EEPROM also simplifies burning the binary image into Props as I don't have to worry about Tachyon not responding because the SD card is removed. I normally load the EEPROM directly so a 64K file is not a problem. To make it easier to load in from a PC I am testing a bootloader which is actually part of the console receive routine which runs in it's own cog. The idea is that on a new load that the Tachyon kernel can still be loaded with the Prop tool as per usual but the main difference is that the serial routine is independent of Forth and can recognize an Intel hex load file and automatically burn each line into EEPROM when the checksum is correct. So it's a two part load for a clean system, the Prop tool gets the kernel loaded but not the compacted dictionary, so after boot Tachyon doesn't recognise any words but the hex file can be loaded in (pasted as text) through the console port.