One of the first things I teach my students is the Pareto-principle or commonly known as 80/20 rule.
This is another nice example of it in action.
On the left the implementation of the basic ." word the literal PRINTSTRING.
On the right the new version with the extensions to handle escaped characters like \n\r\t\...
Nice how simple the basic code is and how much more is needed to handle this special extension.
and it saves 6 bytes, but costs around additional ~73 bytes in the extended kernel vs 29 bytes of the base code !!
And this cost is there even if this feature will not be used.
At todays memory sizes this is of course nothing to spend a second thought on.
But on REALLY size restricted systems like the 32k Propeller it can be significant.
So thanks Peter, looks great -
AND this is the path that lead us to Windows (huge and full of functions which are rarely used/useful) ;-)
Of course this could have been implemented as an optional extension as well.
But windows had little problems since the HW was always growing fast -
as is the new P2 vs. P1 ... memory size ;-)
I'm so tempted to say goodbye to these forums sometimes...
I, for one, would hate to see that happen Peter. I haven't learned Tachyon Forth yet, but I will. I am always intrigued by your posts, and grateful for your contributions to the Propeller community.
@MJB - don't fret, this is a useful feature at least for inserting double quotes and also for some control characters. I could decide not to implement the \n\r\t and save 30 bytes but have a look at all this memory that is just sitting around and that has nothing to do with code or dictionary.
SERIAL BUFFERS
0000.7100: ...BUFFERS .WORD...S..MAP..MAP....$100 MAP..0 $8000 DUMPL.A.BLKSIZ 4 * ...$*....S.$1234 DUP 2*.....S.$7F00 $100 i
0000.7180: dth.0 $8000 DUMPA....Z.`.R...)=a.P.p.P=..R...)=a/.L\.Z=...|\.P}..Z...H....T\...h...h.R..6R.....d.R..9R...)=b..T\.
FILE BUFFERS B
0000.7200: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
<snip>
0000.7980: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBk
VGA BUFFERS V (960bytes)
0000.7A00: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
<snip>
0000.7D80: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FREE F (384 bytes)
0000.7E00: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
0000.7E80: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
0000.7F00: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
This is where I can gain more memory by examining where I can consolidate some of this buffer space such as combining the file buffers with the VGA in the second 1K section and save 1.4k. Trouble is this is the area that is reused after the coginits from the cog images for Tachyon, VGA, Serial/PingPong and I can only use them for buffers and not code or dictionary since we don't want to write over that original images in EEPROM when we do a BACKUP.
If I get around to loading cog images into upper EEPROM then I can free up the lower memory but that introduces more complexities with compiling plus getting that image into upper EEPROM. What I need is to load all the cogs first and then load my 32k RAM unencumbered by cog images. Optimizing memory for the P1 is not easy though.
@JonnyMac - I haven't left yet but I sure do hate walking around cold deserted streets in a rundown part of town where many have packed up and left long ago and those left over are rather sad and sorry looking getting rid of old stuff while others keep languishing and hanging out year after year waiting for the next big thing. The place may have plenty of history and old-timers hanging around eager to engage you in idle chit-chat or debates but the bub has gone from the hub.
Hi there,
(Tachyon) FORTH is really a language of enormous efficiency. As I'm always interested in reusing learned lessons I would like to (learn) program more in Forth. In a windows environment I'm looking for a solution to do some database access to a postgres database. I searched shortly and it seems that there are not many matches for these topics (search was "forth windows postgres"). Forth is a niche language.
Before I spend more time in researching do you have experience with a forth in a windows/linux(/android/ios) environment which suits well with the tachyon paradigms and which you recommend?
Well I use a few different database systems professionally; MS SQL, MYSQL, SYBASE ...
And to access them all I tend to use RedBean, a lightweight Object Relationship Mapper and PHP. Use the right tool for the job in my view.
But back to how cool Tachyon Forth is
Here's a word that takes two parameters and transmits the "sentence" to a 4D Systems uLCD display via serial with checksum on the fly. Now I'm sure a brighter bulb could remove some swaps or dups but this works perfectly for my needs currently at 9600 baud.
#ptx is the serial output pin constant and #wr_obj is just the write command constant
: SDMSG ( val obj -- )
#wr_obj DUP >L \ loop stack as a checksum accumulator, first byte
#ptx SEROUT \ send write obj cmd
W>B \ move obj into 2 byte msb top of stack
DUP L> XOR >L \ add byte to checksum
SWAP \ need the other one
DUP L> XOR >L \ add other byte to checksum
SWAP \ align bytes in proper order for transmission
#ptx SEROUT \ send first byte
#ptx SEROUT \ send second byte
W>B \ move val into 2 bytes
DUP L> XOR >L \ add byte to checksum
SWAP \ do the dance again
DUP L> XOR >L \ add byte to checksum
SWAP \ align bytes in proper order
#ptx SEROUT \ send msb of val
#ptx SEROUT \ send lsb of val
L> #ptx SEROUT \ send checksum
;
Easy and clean no?
EDIT
Took about 43.234 seconds before I got a "little bird" notice of a more Elegant implementation per Peter, THANKS.
This has got me thinking how to dispatch incoming message and object events from the 4D uLCD systems.
Let's just look at the object events
6 serial bytes arrive
<B><B><B><B><B><B>
EventType byte
object type high byte (i.e. button type)
object type low byte (i.e. button instance )
object value high byte
object value low byte
checksum byte
Based on object type and instance I would dispatch to the proper word.
Currently doing the dance with case statements and IFs, it's getting cluttered as the UI gets more complicated and new features are added based on user requests.
The other message type is also 6 bytes. I'm trying to refactor the code base on Peter's previous example using a vector to handle the chksum calculation.
LAP $2000 $1000 SDMSG .LAP 23.515secs ok \ new routine
LAP $2000 $1000 SDMSG1 .LAP 21.711secs ok \ previous routine
Now it's not seconds but milli seconds?
You missed the lapping LAP after SDMSG and before .LAP.
There's also the even simpler version I sent you too:
: >4D ( sum ch -- sum ) >B SWAP OVER XOR SWAP #ptx SEROUT ;
: SDMSG ( val obj -- )
0 #wr_obj >4D
OVER 8>> >4D SWAP >4D
OVER 8>> >4D SWAP >4D
DUP >4D DROP
;
Here's the timing:
LAP $1000 $2000 SDMSG LAP .LAP 6.988ms ok
But that doesn't tell you much as the routine is caught up in bit-bashing 9600 baud serial. Here it is with say 250k baud
LAP $1000 $2000 SDMSG LAP .LAP 377.166us ok
and also
400000 SERBAUD ok
LAP $1000 $2000 SDMSG LAP .LAP 278.166us ok
btw, LAP is a fast opcode unlike .LAP which is a high-level bytecode definition so LAP introduces minimal timing delays that are also measured and taken into account inside of .LAP
I realized the timing wasn't gonna be close given 9600 baud.
The hardest part of FORTH is thinking instead of just following the syntax of other languages.
I suppose that I end up being a "tutor" not simply because I know Tachyon but also because of the way I look at and reduce problems to a simple solution. Complex stuff is too complex for my little brain and I like simple solutions. It is amazing though the number of times I have had to tackle complex problems with complex specifications and standards that after doing the hard yards on it turns out to be quite simple after you cut through all that added complexity fluff ...... and even simpler when you reimplement it!
I've been working on a V2.10 which may just become V3 as I have found a way to precompile "ROMS" for cogs without losing any hub memory. Well, it's a trick and they are in memory when the kernel is first loaded but the cog images are in the free memory area between the end of the kernel bytecode and the low end of the dictionary (grows down). When I load up EXTEND.fth and just before it does a BACKUP to EEPROM it searches the EEPROM for "ROMS" and copies this whole area which may consist of several ROMS to >32k EEPROM. When we want to load a cog with a ROM we just specify the name and the cog to load like " VGA" 4 LOADROM or something like that. ROMs can also be stored on SD card, stacks of them in fact. Initially I have simply made the resident VGA driver a "ROM". Still a WIP but it shouldn't be long before it's all up and running fully.
V2.10 was started initially to try to free up some more memory so I cut my vector table down from 2K to 1K and made adjustments elsewhere to keep it happy. I then loaded up EXTEND, a hardware header, SDCARD, and EASYFILE and compared the differences since less vectors means more calls will be compiled as 3 bytes vs 2 bytes. Anyway, even so, the newer version saved at least 400 bytes in this area alone. I also made changes so that we have NFA for a name field, a BFA for the bytecodes field address in the header, and CFA for the actual runtime code itself. Probably a few other things too but it's late/early now.
Excellent news, while there is basically unlimited memory for my needs in P2 I've often run out of memory in P1 and had to forgo using EasyNet which I would really like to get back in certain projects.
Excellent news, while there is basically unlimited memory for my needs in P2 I've often run out of memory in P1 and had to forgo using EasyNet which I would really like to get back in certain projects.
Have you ever used COMPACT in EEWORDS to build a dictionary in upper EEPROM to free up space? I've got applications built on top of EASYNET because around 10k of RAM is freed up with the COMPACT operation. The dictionary may be in EEPROM but it's not slow as the words are hashed grouped into blocks read quickly into a buffer where searched words are maintained and freshened in a RAM cache with any newer words just building on top of that cache as a regular RAM dictionary. It is very similar in speed to a regular RAM dictionary search since it doesn't have to check every word in the dictionary, but after searching any new words in RAM and cache and if not found then the word is hashed which forms an index to 1 of 64 blocks that should contain the entry. So at the most it is a single EEPROM block read.
Yes I have used COMPACT and EEWORDS. It's my bloated code that I am refactoring rapidly as I move away from linear syntax style programming. It's a slog but I enjoy being a novice and learning new challenging things. I pity those stuck in the rut needing to always be the expert. FORTH/Tachyon is similar to chess for me, lots of moves, some just wrong, some more clever, some more lethal
ROMS
Now that I can put ROMS into the kernel code without consuming hub memory and available as runtime objects to load into cogs I just need to polish a little bit more to make it work.
So I could for instance load cog 4 with the SIDEMU with the command " SIDEMU" 4 LOADROM but there is also the matter of setup parameters that I need to work out.
Things are looking good so far, after loading a kernel I can add EXTEND.fth which then automatically detects the ROMs in lower EEPROM and moves them into upper EEPROM before BACKUP which of course writes over the old image. Now I've been stepping through some of those ROMs which btw are simply just the PASM part of an object that normally gets loaded into a cog with coginit. One of the first ROMs I'm testing is the VGA32x15 text mode driver. The method is to pass the parameter, cog, and name to LOADCOG which scans the upper EEPROM and if found it will COGINIT the cog with this ROM.
This is how I am loading up the VGA driver at present from within my code:
vgapars 2 " VGA32x15" LOADCOG
These are some of the ROMS I have already included:
Things are looking good so far, after loading a kernel I can add EXTEND.fth which then automatically detects the ROMs in lower EEPROM and moves them into upper EEPROM before BACKUP which of course writes over the old image. Now I've been stepping through some of those ROMs which btw are simply just the PASM part of an object that normally gets loaded into a cog with coginit. One of the first ROMs I'm testing is the VGA32x15 text mode driver. The method is to pass the parameter, cog, and name to LOADCOG which scans the upper EEPROM and if found it will COGINIT the cog with this ROM.
This is how I am loading up the VGA driver at present from within my code:
vgapars 2 " VGA32x15" LOADCOG
These are some of the ROMS I have already included:
The QUADUART is really just the 4-port full-duplex serial driver that I will have to test out next but the SIDEMU will be more fun.
wow - great progress
now we can be more generous with a few bytes here and there ;-)
and later those ROMs can be generated dynamically with the ASSEMBLER
and written to SD ...
so OBEX is coming
when doing this major revision,
maybe you can change ACC to spicnt in SPIWR16,
so it is consistent with the documentation and SPIWRX can be used as described,
by loading 'n spicnt COGREG! ' before, which is very hard with ACC as it is now.
wow - great progress
now we can be more generous with a few bytes here and there ;-)
and later those ROMs can be generated dynamically with the ASSEMBLER
and written to SD ...
so OBEX is coming
when doing this major revision,
maybe you can change ACC to spicnt in SPIWR16,
so it is consistent with the documentation and SPIWRX can be used as described,
by loading 'n spicnt COGREG! ' before, which is very hard with ACC as it is now.
OBEX is what I was thinking about too. Although my fixed point math has gotten much much better without FP support in Tachyon, there are some standard saturated vapor pressure equations for wet/dry bulb RH measurement I would just prefer to let F32.asm handle in a single cog.
OBEX is what I was thinking about too. Although my fixed point math has gotten much much better without FP support in Tachyon, there are some standard saturated vapor pressure equations for wet/dry bulb RH measurement I would just prefer to let F32.asm handle in a single cog.
Really neat Peter
F32 could easily be added and as I said I am still tweaking this version but so far, so good. Since this version frees up a lot of memory then this might be suitable for you to use even without compacting the dictionary. Don't forget you can also RECLAIM private words either globally or selectively and gain a bit more there too.
I tried to download TACHYON V3.0 JUNO and received the following error message: Limit of 1024 DAT symbols exceeded.
The load stopped at _UnitTrunc in the code.
Nick
I'd been scratching my head trying to figure out what you were saying as a "download" is normally when we grab a file from somewhere else like the interweb thingy but it just dawned on me that you meant you tried to load the Prop, doh! (and I just had a coffee). I normally use BST which always works so much better than the Prop Tool but I just tried using Prop Tool and now I see what you mean. I'm not sure if I've got a way around it but can you try it with BST in the meantime (or just always)?
I have a BST archive in my Tachyon tools folder and the version I like to use in linux is 19.4pre11 so give that a try. You can also get BST to generate a real listing which I normally copy from the listing window back into a Spin document so I can reference and search it easily.
Loaded here correctly with BST as well. Extend is loaded too. Really nice Peter.
00:00:00 End of source code, 2392 lines processed and 0000 errors found
Load time = 7.187secs
MODULES LOADED:
1787: EXTEND.fth Primary extensions to TACHYON kernel - 160720-1500
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5B62...74C6 for 6,500 bytes (+3,861)
CODE: $0930...341B for 10,987 bytes (+7,316)
RAM: 10,055 bytes free
BUILD: FIRMWARE BUILD DATE 000000:000000 BOOTS: 0 runtime 0
BOOT: EXTEND.boot ok
ok
IFDEF V3 ok
--- ok
: SAVEROMS
" ROMS" U@ @NAMES 3 ANDN ' TACHYON 3 ANDN
DO I E@ OVER = IF CR PRINT" COPY ROMS @" I .WORD PRINT" for " I 4 + E@ .DEC I roms I 4 + E@ romsz MIN ECOPY LEAVE THEN
4 +LOOP
DROP
; ok
SAVEROMS
COPY ROMS @1738 for 6872 ok
FORGET COPYROMS COPYROMS not found ok
I tried to download TACHYON V3.0 JUNO and received the following error message: Limit of 1024 DAT symbols exceeded.
The load stopped at _UnitTrunc in the code.
Nick
I'd been scratching my head trying to figure out what you were saying as a "download" is normally when we grab a file from somewhere else like the interweb thingy but it just dawned on me that you meant you tried to load the Prop, doh! (and I just had a coffee). I normally use BST which always works so much better than the Prop Tool but I just tried using Prop Tool and now I see what you mean. I'm not sure if I've got a way around it but can you try it with BST in the meantime (or just always)?
I have a BST archive in my Tachyon tools folder and the version I like to use in linux is 19.4pre11 so give that a try. You can also get BST to generate a real listing which I normally copy from the listing window back into a Spin document so I can reference and search it easily.
@D.P Just saw a tiny error there and fixed EXTEND as I was changing names and COPYROMS was changed to SAVEROMS (which it does) before they are obliterated in the first 32k when Tachyon does a BACKUP. So once SAVEROMS runs once it isn't needed anymore so we FORGET it before a backup (I don't want MJB breathing down my neck for wasting that handful of bytes now do I? )
I still can't decide if I want to say LOADROM or LOADCOG because it loads a ROM but it also loads a cog but it is part of the ROM words..........sometimes choosing a good name takes longer than writing the word, it does, it does.
note: I suppose that since these words extend the language it is important then to have good names unlike traditional compilers where it really_doesn't_matter_what_you_call_it!!!!!
acknowledged, just got the one posted 6 min ago now
MJB can see your evil waste in the kernel now, beware
00:00:00 End of source code, 2392 lines processed and 0000 errors found
Load time = 6.559secs
MODULES LOADED:
1787: EXTEND.fth Primary extensions to TACHYON kernel - 160720-1500
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5B62...74C6 for 6,500 bytes (+3,861)
CODE: $0930...341B for 10,987 bytes (+7,316)
RAM: 10,055 bytes free
BUILD: FIRMWARE BUILD DATE 000000:000000 BOOTS: 0 runtime 0
BOOT: EXTEND.boot ok
ok
IFDEF V3 ok
--- ok
: SAVEROMS
" ROMS" U@ @NAMES 3 ANDN ' TACHYON 3 ANDN
DO I E@ OVER = IF CR PRINT" COPY ROMS @" I .WORD PRINT" for " I 4 + E@ .DEC I roms I 4 + E@ romsz MIN ECOPY LEAVE THEN
4 +LOOP
DROP
; ok
SAVEROMS
COPY ROMS @1738 for 6872 ok
FORGET SAVEROMS ok
} ok
ok
?BACKUP ok
ok
ok
ok
@D.P - btw, you can load F32 into a cog with a suitable parameter and start testing it if you like. I still need to get a round tuit as these PASM drivers still need an interface at the Forth level but the Spin code should give you a good guide.
btw again, EXTEND now has a default of a smaller build so I don't have to worry but I suppose what I should really do is get rid of the SMALL word and CREATE LARGE or EXPLORER to specify a larger build than the default.
Hey I saw that F32 in the listing! Nice work. Really look forward to V3. Dang and a peak at the workbench, nice and cluttered, getting stuff done!
That's supposed to be the clean area of my PC bench but that's also where I have test equipment on the shelf above. Now if I panned around the workshop you would see that I am surrounded by benches as the one in front of me continues to the right over to the corner where I do my soldering, then all the drills and grinders etc then over to a wall of parts drawers, then a wall of parts shelves and then there is the island bench right behind so I can swivel around and work from there too. Somewhere in between all the benches and shelves and equipment I have some room to move I will have to give you some sneak peeks at other areas when I do a proper V3 video.
(darn.....where's that phone of mine, put something down on the bench and it disappears.....)
Comments
This is another nice example of it in action.
On the left the implementation of the basic ." word the literal PRINTSTRING.
On the right the new version with the extensions to handle escaped characters like \n\r\t\...
Nice how simple the basic code is and how much more is needed to handle this special extension.
of course writing might look more familiar to C programmers than and it saves 6 bytes, but costs around additional ~73 bytes in the extended kernel vs 29 bytes of the base code !!
And this cost is there even if this feature will not be used.
At todays memory sizes this is of course nothing to spend a second thought on.
But on REALLY size restricted systems like the 32k Propeller it can be significant.
So thanks Peter, looks great -
AND this is the path that lead us to Windows (huge and full of functions which are rarely used/useful) ;-)
Of course this could have been implemented as an optional extension as well.
But windows had little problems since the HW was always growing fast -
as is the new P2 vs. P1 ... memory size ;-)
I, for one, would hate to see that happen Peter. I haven't learned Tachyon Forth yet, but I will. I am always intrigued by your posts, and grateful for your contributions to the Propeller community.
Jon
This is where I can gain more memory by examining where I can consolidate some of this buffer space such as combining the file buffers with the VGA in the second 1K section and save 1.4k. Trouble is this is the area that is reused after the coginits from the cog images for Tachyon, VGA, Serial/PingPong and I can only use them for buffers and not code or dictionary since we don't want to write over that original images in EEPROM when we do a BACKUP.
If I get around to loading cog images into upper EEPROM then I can free up the lower memory but that introduces more complexities with compiling plus getting that image into upper EEPROM. What I need is to load all the cogs first and then load my 32k RAM unencumbered by cog images. Optimizing memory for the P1 is not easy though.
@JonnyMac - I haven't left yet but I sure do hate walking around cold deserted streets in a rundown part of town where many have packed up and left long ago and those left over are rather sad and sorry looking getting rid of old stuff while others keep languishing and hanging out year after year waiting for the next big thing. The place may have plenty of history and old-timers hanging around eager to engage you in idle chit-chat or debates but the bub has gone from the hub.
Well I use a few different database systems professionally; MS SQL, MYSQL, SYBASE ...
And to access them all I tend to use RedBean, a lightweight Object Relationship Mapper and PHP. Use the right tool for the job in my view.
But back to how cool Tachyon Forth is
Here's a word that takes two parameters and transmits the "sentence" to a 4D Systems uLCD display via serial with checksum on the fly. Now I'm sure a brighter bulb could remove some swaps or dups but this works perfectly for my needs currently at 9600 baud.
#ptx is the serial output pin constant and #wr_obj is just the write command constant
: SDMSG ( val obj -- ) #wr_obj DUP >L \ loop stack as a checksum accumulator, first byte #ptx SEROUT \ send write obj cmd W>B \ move obj into 2 byte msb top of stack DUP L> XOR >L \ add byte to checksum SWAP \ need the other one DUP L> XOR >L \ add other byte to checksum SWAP \ align bytes in proper order for transmission #ptx SEROUT \ send first byte #ptx SEROUT \ send second byte W>B \ move val into 2 bytes DUP L> XOR >L \ add byte to checksum SWAP \ do the dance again DUP L> XOR >L \ add byte to checksum SWAP \ align bytes in proper order #ptx SEROUT \ send msb of val #ptx SEROUT \ send lsb of val L> #ptx SEROUT \ send checksum ;Easy and clean no?
EDIT
Took about 43.234 seconds before I got a "little bird" notice of a more Elegant implementation per Peter, THANKS.
BYTE 4dsum : 4DO DUP 4dsum C@ XOR 4dsum C! #ptx SEROUT ; : 4D ' 4DO uemit W! 4dsum C~ ; : SDMSG ( val obj -- ) 4D #wr_obj EMIT W>B EMIT EMIT W>B EMIT EMIT 4dsum C@ EMIT CON ;EDIT timing
Now it's not seconds but milli seconds?
Let's just look at the object events
6 serial bytes arrive
<B><B><B><B><B><B>
EventType byte
object type high byte (i.e. button type)
object type low byte (i.e. button instance )
object value high byte
object value low byte
checksum byte
Based on object type and instance I would dispatch to the proper word.
Currently doing the dance with case statements and IFs, it's getting cluttered as the UI gets more complicated and new features are added based on user requests.
The other message type is also 6 bytes. I'm trying to refactor the code base on Peter's previous example using a vector to handle the chksum calculation.
You missed the lapping LAP after SDMSG and before .LAP.
There's also the even simpler version I sent you too:
: >4D ( sum ch -- sum ) >B SWAP OVER XOR SWAP #ptx SEROUT ; : SDMSG ( val obj -- ) 0 #wr_obj >4D OVER 8>> >4D SWAP >4D OVER 8>> >4D SWAP >4D DUP >4D DROP ;Here's the timing:
LAP $1000 $2000 SDMSG LAP .LAP 6.988ms ok
But that doesn't tell you much as the routine is caught up in bit-bashing 9600 baud serial. Here it is with say 250k baud
LAP $1000 $2000 SDMSG LAP .LAP 377.166us ok
and also
400000 SERBAUD ok
LAP $1000 $2000 SDMSG LAP .LAP 278.166us ok
btw, LAP is a fast opcode unlike .LAP which is a high-level bytecode definition so LAP introduces minimal timing delays that are also measured and taken into account inside of .LAP
I realized the timing wasn't gonna be close given 9600 baud.
The hardest part of FORTH is thinking instead of just following the syntax of other languages.
I suppose that I end up being a "tutor" not simply because I know Tachyon but also because of the way I look at and reduce problems to a simple solution. Complex stuff is too complex for my little brain and I like simple solutions. It is amazing though the number of times I have had to tackle complex problems with complex specifications and standards that after doing the hard yards on it turns out to be quite simple after you cut through all that added complexity fluff ...... and even simpler when you reimplement it!
I've been working on a V2.10 which may just become V3 as I have found a way to precompile "ROMS" for cogs without losing any hub memory. Well, it's a trick and they are in memory when the kernel is first loaded but the cog images are in the free memory area between the end of the kernel bytecode and the low end of the dictionary (grows down). When I load up EXTEND.fth and just before it does a BACKUP to EEPROM it searches the EEPROM for "ROMS" and copies this whole area which may consist of several ROMS to >32k EEPROM. When we want to load a cog with a ROM we just specify the name and the cog to load like " VGA" 4 LOADROM or something like that. ROMs can also be stored on SD card, stacks of them in fact. Initially I have simply made the resident VGA driver a "ROM". Still a WIP but it shouldn't be long before it's all up and running fully.
V2.10 was started initially to try to free up some more memory so I cut my vector table down from 2K to 1K and made adjustments elsewhere to keep it happy. I then loaded up EXTEND, a hardware header, SDCARD, and EASYFILE and compared the differences since less vectors means more calls will be compiled as 3 bytes vs 2 bytes. Anyway, even so, the newer version saved at least 400 bytes in this area alone. I also made changes so that we have NFA for a name field, a BFA for the bytecodes field address in the header, and CFA for the actual runtime code itself. Probably a few other things too but it's late/early now.
Have you ever used COMPACT in EEWORDS to build a dictionary in upper EEPROM to free up space? I've got applications built on top of EASYNET because around 10k of RAM is freed up with the COMPACT operation. The dictionary may be in EEPROM but it's not slow as the words are hashed grouped into blocks read quickly into a buffer where searched words are maintained and freshened in a RAM cache with any newer words just building on top of that cache as a regular RAM dictionary. It is very similar in speed to a regular RAM dictionary search since it doesn't have to check every word in the dictionary, but after searching any new words in RAM and cache and if not found then the word is hashed which forms an index to 1 of 64 blocks that should contain the entry. So at the most it is a single EEPROM block read.
Now that I can put ROMS into the kernel code without consuming hub memory and available as runtime objects to load into cogs I just need to polish a little bit more to make it work.
So I could for instance load cog 4 with the SIDEMU with the command " SIDEMU" 4 LOADROM but there is also the matter of setup parameters that I need to work out.
Things are looking good so far, after loading a kernel I can add EXTEND.fth which then automatically detects the ROMs in lower EEPROM and moves them into upper EEPROM before BACKUP which of course writes over the old image. Now I've been stepping through some of those ROMs which btw are simply just the PASM part of an object that normally gets loaded into a cog with coginit. One of the first ROMs I'm testing is the VGA32x15 text mode driver. The method is to pass the parameter, cog, and name to LOADCOG which scans the upper EEPROM and if found it will COGINIT the cog with this ROM.
This is how I am loading up the VGA driver at present from within my code:
These are some of the ROMS I have already included:
The QUADUART is really just the 4-port full-duplex serial driver that I will have to test out next but the SIDEMU will be more fun.
wow - great progress
now we can be more generous with a few bytes here and there ;-)
and later those ROMs can be generated dynamically with the ASSEMBLER
and written to SD ...
so OBEX is coming
when doing this major revision,
maybe you can change ACC to spicnt in SPIWR16,
so it is consistent with the documentation and SPIWRX can be used as described,
by loading 'n spicnt COGREG! ' before, which is very hard with ACC as it is now.
OBEX is what I was thinking about too. Although my fixed point math has gotten much much better without FP support in Tachyon, there are some standard saturated vapor pressure equations for wet/dry bulb RH measurement I would just prefer to let F32.asm handle in a single cog.
Really neat Peter
F32 could easily be added and as I said I am still tweaking this version but so far, so good. Since this version frees up a lot of memory then this might be suitable for you to use even without compacting the dictionary. Don't forget you can also RECLAIM private words either globally or selectively and gain a bit more there too.
EDIT: here's a quick little intro video on Dropbox where it loads up a VGA "ROM" and runs a demo (got cut short at the end)
I tried to download TACHYON V3.0 JUNO and received the following error message: Limit of 1024 DAT symbols exceeded.
The load stopped at _UnitTrunc in the code.
Nick
I'd been scratching my head trying to figure out what you were saying as a "download" is normally when we grab a file from somewhere else like the interweb thingy but it just dawned on me that you meant you tried to load the Prop, doh! (and I just had a coffee). I normally use BST which always works so much better than the Prop Tool but I just tried using Prop Tool and now I see what you mean. I'm not sure if I've got a way around it but can you try it with BST in the meantime (or just always)?
I have a BST archive in my Tachyon tools folder and the version I like to use in linux is 19.4pre11 so give that a try. You can also get BST to generate a real listing which I normally copy from the listing window back into a Spin document so I can reference and search it easily.
Loaded here correctly with BST as well. Extend is loaded too. Really nice Peter.
00:00:00 End of source code, 2392 lines processed and 0000 errors found Load time = 7.187secs MODULES LOADED: 1787: EXTEND.fth Primary extensions to TACHYON kernel - 160720-1500 VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000 FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X) NAMES: $5B62...74C6 for 6,500 bytes (+3,861) CODE: $0930...341B for 10,987 bytes (+7,316) RAM: 10,055 bytes free BUILD: FIRMWARE BUILD DATE 000000:000000 BOOTS: 0 runtime 0 BOOT: EXTEND.boot ok ok IFDEF V3 ok --- ok : SAVEROMS " ROMS" U@ @NAMES 3 ANDN ' TACHYON 3 ANDN DO I E@ OVER = IF CR PRINT" COPY ROMS @" I .WORD PRINT" for " I 4 + E@ .DEC I roms I 4 + E@ romsz MIN ECOPY LEAVE THEN 4 +LOOP DROP ; ok SAVEROMS COPY ROMS @1738 for 6872 ok FORGET COPYROMS COPYROMS not found okI still can't decide if I want to say LOADROM or LOADCOG because it loads a ROM but it also loads a cog but it is part of the ROM words..........sometimes choosing a good name takes longer than writing the word, it does, it does.
note: I suppose that since these words extend the language it is important then to have good names unlike traditional compilers where it really_doesn't_matter_what_you_call_it!!!!!
MJB can see your evil waste in the kernel now, beware
00:00:00 End of source code, 2392 lines processed and 0000 errors found Load time = 6.559secs MODULES LOADED: 1787: EXTEND.fth Primary extensions to TACHYON kernel - 160720-1500 VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000 FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X) NAMES: $5B62...74C6 for 6,500 bytes (+3,861) CODE: $0930...341B for 10,987 bytes (+7,316) RAM: 10,055 bytes free BUILD: FIRMWARE BUILD DATE 000000:000000 BOOTS: 0 runtime 0 BOOT: EXTEND.boot ok ok IFDEF V3 ok --- ok : SAVEROMS " ROMS" U@ @NAMES 3 ANDN ' TACHYON 3 ANDN DO I E@ OVER = IF CR PRINT" COPY ROMS @" I .WORD PRINT" for " I 4 + E@ .DEC I roms I 4 + E@ romsz MIN ECOPY LEAVE THEN 4 +LOOP DROP ; ok SAVEROMS COPY ROMS @1738 for 6872 ok FORGET SAVEROMS ok } ok ok ?BACKUP ok ok ok okbtw again, EXTEND now has a default of a smaller build so I don't have to worry but I suppose what I should really do is get rid of the SMALL word and CREATE LARGE or EXPLORER to specify a larger build than the default.
Tachyon 100 Club ( 100 pages on the forums or bust)
100 pages of "code" !!! Sounds good
Just detail your F32 tests, that'll help.
That's supposed to be the clean area of my PC bench but that's also where I have test equipment on the shelf above. Now if I panned around the workshop you would see that I am surrounded by benches as the one in front of me continues to the right over to the corner where I do my soldering, then all the drills and grinders etc then over to a wall of parts drawers, then a wall of parts shelves and then there is the island bench right behind so I can swivel around and work from there too. Somewhere in between all the benches and shelves and equipment I have some room to move
(darn.....where's that phone of mine, put something down on the bench and it disappears.....)
I'm having an issue I guess. Also "suitable" parameters?
EDIT
I can't FINDROM on anything loaded but lsroms works, more looking here.