Yes, but only if it's been connected that way, so A0 = pin 7 on the chip is tied high for sure. Just having a look at it now so I will get back shortly with the code.
This code looks like it should work but I don't have a chip to try it on.
[FONT=courier new]{ Access TMP75 temperature chip
These routines allow for multiple TMP75 devices to share the bus.
Usage:
1 !TEMP \ Initialise device #1 (address $92)
1 TEMP@ CELCIUS \ Read temperature from device #1 and convert to Celcius
}
\
: TMP75 ( ch -- dev )
2* $90 +
;
\ Initialize the configuration register
: !TEMP ( ch -- )
I2CSTART TMP75 DUP I2C! \ Address device
1 I2C! \ address configuration register
100000 I2C! \ Set 12-bit resolution + defaults
I2CSTART I2C! \ Readdress to set default register as temperature
0 I2C!
I2CSTOP
;
: CELCIUS ( temp12 -- celcius )
1+ 4 SHR DUP $80 AND IF $FFFF.FF00 OR THEN
;
\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch -- temp12 )
I2CSTART TMP75 1+ I2C! \ Form I2C address & address chip (blind mode)
0 I2C@ 0 I2C@ 8 SHL OR \ Fetch two bytes from device and combine into one word
I2CSTOP
;
[/FONT]
Good news for multi-taskers! The task functions have been expanded and so you should use the new kernel and extensions. Support includes finding the next free Tachyon cog available for a task.
The EXTEND.fth has the new multichannel PWM task included as well as a background timer task.
The PWM has up to 8 channels per task with 8-bit resolution at up to 5kHz. It's also possible to run some PWM channels at a multiple of the base frequency with less resolution. If you want more channels you can run another instance as another task. If there is interest I will also include a 32-channel version I have which just means that you can pick whichever pins you want for PWM.
USAGE:
( implement 8 PWM channels on P0..P7 )
\ setup area for PWM values
TABLE pwm #256 ALLOT
\ Set the frequecy
#1000 PWMFREQ
\ Start up PWM using from P0 for 8 channels (will find the next free cog to use)
0 8 pwm RUNPWM
\ Set PWM channel 0 for 50%
$80 0 PWM!
\ Set PWM channel 7 for 25%
#25 % 7 PWM!
Many applications need some kind of background polling and timing which is what the timer task does. You can launch this in a cog and it will maintain an elapsed time in milliseconds which won't wrap-around for over 49 days plus maintain the number of countdown timers you specify. When these timers countdown to zero they automatically stop and if you have set a timeout vector for that timer then it will execute that automatically.
USAGE:
( Create 8 countdown timers and assign a BLINKY function to timer 0 )
\ Allocate space for 8 timers at 8 bytes each
TABLE mytimers #64 ALLOT
\ pass parameters to start timer task
mytimers 8 RUNTIMERS
\ demo LED flasher which takes 5 seconds before it starts flashing every 100ms
: BLINKY
#16 PIN@ 0= #16 PIN! \ toggle pin 16
0 TIMER 6 + W@ 0 TIMER ! \ reload timer using stored value in timer memory
;
\ Setup the timeout vector for TIMER 0
' BLINKY 0 TIMER 4 + W!
\ Write a reload value to timer's memory
#100 0 TIMER 6 + W!
\ Setup timer 0 to timeout in 5 seconds
#5,000 0 TIMER !
The timer functions will be expanded upon to include virtual RTC support which will also automatically detect an I2C RTC if present and hopefully figure out what device it is to correctly interface to it. RTC API is non-device specific and includes fetching and storing date and time strings and longs.
V2 source code page link will now be included in the links section of the Intro page.
This code looks like it should work but I don't have a chip to try it on.
[FONT=courier new]{ Access TMP75 temperature chip
These routines allow for multiple TMP75 devices to share the bus.
Usage:
1 !TEMP \ Initialise device #1 (address $92)
1 TEMP@ CELCIUS \ Read temperature from device #1 and convert to Celcius
}
\
: TMP75 ( ch -- dev )
2* $90 +
;
\ Initialize the configuration register
: !TEMP ( ch -- )
I2CSTART TMP75 DUP I2C! \ Address device
1 I2C! \ address configuration register
100000 I2C! \ Set 12-bit resolution + defaults
I2CSTART I2C! \ Readdress to set default register as temperature
0 I2C!
I2CSTOP
;
: CELCIUS ( temp12 -- celcius )
1+ 4 SHR DUP $80 AND IF $FFFF.FF00 OR THEN
;
\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch -- temp12 )
I2CSTART TMP75 1+ I2C! \ Form I2C address & address chip (blind mode)
0 I2C@ 0 I2C@ 8 SHL OR \ Fetch two bytes from device and combine into one word
I2CSTOP
;
[/FONT]
It is'nt working.
This is the code I tried but also no response
: TMP75_INIT
$0E $0F I2CPINS \ SET THE I2C PINS FOR THE ASC+ BOARD
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$01 I2C! \ REGISTER
$60 I2C! \ CONFIGURE
I2CSTOP \ STOP TRANSMISSION
;
: TMP75@
TMP75_INIT
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C! \ SET POINTER REGISTER TMP75 TO 0
I2CSTOP \ STOP TRANSMISSION
500 ms \ 0.5 SEC DELAY
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C@ \ READ FIRST BYTE
$01 I2C@ \ READ LAST BYTE
I2CSTOP \ STOP TRANSMISSION
;
Tis looks a little bit strange for me in the code you wrote
100000 I2C! \ Set 12-bit resolution + defaults
I think this should @60 or B01100000
I tried also the slow version no results.
It is working on the arduino, but not on the ASC+ board.
You made a mistake when you went to read the device because you used $92 to address it but it needs to have the R/W bit set so that it should be $93. There is no need to continually initialize the device every time you read plus my example left the device pointing to register 0 so that you could always just read the temperature without having to set the pointer.
With regards to the config register it looks like my code lost the (percentage 01) just before the 100000 It was okay in the text document but must have had some hungry keys eating up a couple of characters but anything was possible because I was very tired for a change!
BTW, did you try my code at all? Also Tachyon uses common prefix and suffixes for numbers so binary is either (percent)0100 or 0100b (argghhh, forum code keeps eating the percent symbol)
You made a mistake when you went to read the device because you used $92 to address it but it needs to have the R/W bit set so that it should be $93. There is no need to continually initialize the device every time you read plus my example left the device pointing to register 0 so that you could always just read the temperature without having to set the pointer.
With regards to the config register it looks like my code lost the (percentage 01) just before the 100000 It was okay in the text document but must have had some hungry keys eating up a couple of characters but anything was possible because I was very tired for a change!
BTW, did you try my code at all? Also Tachyon uses common prefix and suffixes for numbers so binary is either (percent)0100 or 0100b (argghhh, forum code keeps eating the percent symbol)
It is'nt working.
<snip>
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C@ \ READ FIRST BYTE
$01 I2C@ \ READ LAST BYTE
I2CSTOP \ STOP TRANSMISSION
;
Please find my working version.
: TMP75 ( ch -- dev )
2* $90 +
;
\ Initialize the configuration register
: !TEMP ( ch -- )
$0E $0F I2CPINS
I2CSTART TMP75 DUP I2C! \ Address device
1 I2C! \ address configuration register
$60 I2C! \ Set 12-bit resolution + defaults
I2CSTART I2C! \ Readdress to set default register as temperature
0 I2C!
I2CSTOP
;
\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch )
I2CSTART TMP75 1+ I2C! \ Form I2C address & address chip (blind mode)
0 I2C@ 0 I2C@ \ Fetch two bytes from device,
\ First byte is temperatuur
\ Second byte is fraction
I2CSTOP
4 SHR \ Remove last 4 bits second byte
$271 * \ Each bit = 0.0625 degree C
SWAP \ print fancy format
. ." ." . ." C" CR \ Print temperatuur as xx.yyyy C
;
I am not sure if this is the right thread - but since the question is directly to Peter ...
while in the hot bathtub my mind was circling around Tachyon ...
and now I need to ask ...
I want to use a prop-board as a front end for a legacy test system.
Following Tachyon and this thread quite some time it seems to fullfill my needs for handling of interactive commands and downloadable test scripts.
commands are simple and would look s.th. like this in Tachyon:
100 349 CMD
12 46 DMD ... 0 to 4 16Bit Integer arguments + 3 Char Command
so quite simple to do in Forth.
Unfortunately compatibility requires me to support the old syntax:
!CMD100;349<cr/lf>
Options:
1: write a parser (I read in a Forth book, 'try to use Forth's parser instead writing your own ...)
2: so I thought since you use HS-SerialRxL to do some preprocessing on the input stream I could extend this approach to convert
!CMD100;349 to 100 349 CMD and feed it to Tachyon to do the work
3: or modify the Tachyon parser by intercepting the 'word not defined' error, then checking for the pattern !CMDxxx:yyy or even !CMDxxxxx;yyyyy;zzzzz;qqqqq then do the transformation and feed the new tokens into the input strean for further processing.
which approach would you advise me to go?
I am quite new to prop and forth, but can read and understand extend.fth already mostly. And I am heavily working through TachyonV2 and Prop ASM.
TachonV1 was running on my PropBoE, V2 I try tomorrow.
<snip>
Unfortunately compatibility requires me to support the old syntax:
!CMD100;349<cr/lf>
Options:
1: write a parser (I read in a Forth book, 'try to use Forth's parser instead writing your own ...)
2: so I thought since you use HS-SerialRxL to do some preprocessing on the input stream I could extend this approach to convert
!CMD100;349 to 100 349 CMD and feed it to Tachyon to do the work
3: or modify the Tachyon parser by intercepting the 'word not defined' error, then checking for the pattern !CMDxxx:yyy or even !CMDxxxxx;yyyyy;zzzzz;qqqqq then do the transformation and feed the new tokens into the input strean for further processing.
which approach would you advise me to go?
Unfortunately many command syntaxes do not have any general-purpose means of parsing in that they do not have clearly defined delimiters for one. At least if the command was written as "!CMD;100;349" then that would be far easier to set Forth to have the ";" delimiter as well as <CR>. I assume they at least include a <CR> at the end too? You can scrub out approach 2 as the preprocessing it does is fairly simple and has to do it in real-time between characters.
Approach 1 with writing a simple parser will work though as you don't have to do all the processing, it may be that the command like !CMD is fixed size or always delimited by a digit etc. So you could parse this to the point of plucking out commands and parameters and pass this through the normal word interpreter. Which reminds me, I must see about including an equivalent INTERPRET command which can take a string and process it as if it were terminal input.
If you would like to maintain normal operation of Forth from the terminal command line then integrating approach 1 with approach 3 will work also. The only downside is that there will be a small delay before control is passed to your parser as the dictionary is searched first and then an attempt is made to convert it to a number.
You made a mistake when you went to read the device because you used $92 to address it but it needs to have the R/W bit set so that it should be $93. There is no need to continually initialize the device every time you read plus my example left the device pointing to register 0 so that you could always just read the temperature without having to set the pointer.
With regards to the config register it looks like my code lost the (percentage 01) just before the 100000 It was okay in the text document but must have had some hungry keys eating up a couple of characters but anything was possible because I was very tired for a change!
BTW, did you try my code at all? Also Tachyon uses common prefix and suffixes for numbers so binary is either (percent)0100 or 0100b (argghhh, forum code keeps eating the percent symbol)
Please find my working version.
: TMP75 ( ch -- dev )
2* $90 +
;
\ Initialize the configuration register
: !TEMP ( ch -- )
$0E $0F I2CPINS
I2CSTART TMP75 DUP I2C! \ Address device
1 I2C! \ address configuration register
$60 I2C! \ Set 12-bit resolution + defaults
I2CSTART I2C! \ Readdress to set default register as temperature
0 I2C!
I2CSTOP
;
\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch )
I2CSTART TMP75 1+ I2C! \ Form I2C address & address chip (blind mode)
0 I2C@ 0 I2C@ \ Fetch two bytes from device,
\ First byte is temperatuur
\ Second byte is fraction
I2CSTOP
4 SHR \ Remove last 4 bits second byte
$271 * \ Each bit = 0.0625 degree C
SWAP \ print fancy format
. ." ." . ." C" CR \ Print temperatuur as xx.yyyy C
;
So it looks like my code did work then (expect for the obvious dropped characters in the configuration).
If you want to make it more general-purpose and in line with the proven Forth philosophy of factoring functions then you would leave TEMP@ simply as a word that fetches the raw temperature data and leaves it on the stack. So it's far better for debugging and reading to factor out the I2CPINS function and the conversion and printing into your own application specific word such as ShowTemp or anything like that. Also noticed that you used $271 instead of a far more readable #625 or 625d which directly corresponds with the comment. So if you factor into general and specific words you will have a far easier time testing and especially later on when you have to read your own code you may actually save some hair!.
The Parallax C3 represents an interesting board for a Tachyon installation. The C3 includes 5 spi devices: flash memory, 2 32K sram chips, a 2 channel adc, and the sd card, all of which are multiplexed through a 4 bit counter. Two pins are used to control the chip select. The Tachyon code for selecting spi devices on the C3 is shown below.
The attached file 'C3SPI.fth" includes the basic spi words and basic commands needed to access the flash & sram memory as well as the
adc. The second file, 'SDCARD_MOD.fth, is a modified version of SDCARD.fth for the C3. It uses the spi words defined in C3SPI. These words work with Tachyon V1.1. I have not tried Tachyon V2 at this time.
The Parallax C3 represents an interesting board for a Tachyon installation. The C3 includes 5 spi devices: flash memory, 2 32K sram chips, a 2 channel adc, and the sd card, all of which are multiplexed through a 4 bit counter. Two pins are used to control the chip select. The Tachyon code for selecting spi devices on the C3 is shown below.
<snip>
The attached file 'C3SPI.fth" includes the basic spi words and basic commands needed to access the flash & sram memory as well as the
adc. The second file, 'SDCARD_MOD.fth, is a modified version of SDCARD.fth for the C3. It uses the spi words defined in C3SPI. These words work with Tachyon V1.1. I have not tried Tachyon V2 at this time.
NickL
Thanks Nick, do you want me to put these files in the Dropbox folder and perhaps link to them? It's starting to look like I need to create my own organized Tachyon OBEX! (BTW, the ! at the end of OBEX might mean what it means or it might also mean "store to OBEX" )
Just a little comment about comments too. If you place your stack comment after the name then it looks a little bit more familiar to those not familiar with Forth plus very soon my compiler will take that stack comment plus any other comment after it and place that automatically in a help section in EEPROM or SD etc. So instead of:
\ ( b -- ) Write 1 byte to memory at paddr, incrementing the page address.
pub WRITE
You could write:
pub WRITE ( b -- ) \ Write 1 byte to memory at paddr, incrementing the page address.
The stack comment and description are ignored at present but may be used later for help files and possibly local variable declarations too so therefore stack comments can be a bit more verbose for parameter names in anticipation of that feature and being able to reference the stack by symbol name.
I think that having a Tachyon OBEX is a good idea. It certainly would be useful to have the C3 spi words file listed in the Dropbox folder.
I will change my approach to adding comments to forth words and adopt your suggestion.
I have a question concerning EXECUTE and how it is used. In PropForth, one can do the following: ' <word> execute. I haven't been able to do this in Tachyon. I am interested in defining deferred words - in this example <word> is deferred and can be replaced with other words, depending on circumstances.
Good news for multi-taskers! The task functions have been expanded and so you should use the new kernel and extensions. Support includes finding the next free Tachyon cog available for a task.
This is so very helpful for interactive development and has made the return to FORTH fun, thanks Peter. Current DropBox V2 file and Extend.fth running well on PBOE.
There's hardly a day that goes by that there isn't a significant addition etc so I really recommend that you update to the latest kernel. Just a very quick summary then:
The ' (tick) word now operates within definitions correctly so that there is no need to create a constant beforehand.
VER @ will return the version and build in one handy long like this: 20120917
I'm also experimenting with the source code loader, line numbers etc.
I'm being summoned now so in the meantime here's a little bit of code for a PCF8563 I2C RTC chip. Other RTC chips will follow but will probably be integrated into the one RTC module so they can use common routines.
Is there a chance for getting an example of PWM in TACHYON?
Jan Kromhout
Hellevoetsluis-NL
Hi Jan, how did you go with using the 8 channel PWM module?
I've been using it myself with my H-bridge modules and motors and I have just updated the kernel to include a faster table update module, not that I had any problems with it, I just wanted to make it better. Originally PWM! which sets the duty cycle for the channel was just scanning through a 256 byte table clearing and setting masks which took >5ms but then I did another version which cut that in half. Not happy with that I then created a PWM! PASM module which like the other specialized modules just gets loaded as needed and are useful in repetitive tasks. So the load time is around 20us and setting the table takes around 200us.
I've had a request to interface 1-wire devices, specifically the DS1820+ temperature sensor and the DS2450+ 12-bit ADC so I got some chips in and having a play with it now. So I can read a single device fine just using Tachyon bytecode as I can manage 1us pulses without PASM. Now I am implementing the SEARCH ROM command which is probably the most complicated command. This is a work-in-progress but you can have a play with it while I continue to expand the functionality. Perhaps you can test it out yourself and report any problems or just make suggestions. https://docs.google.com/document/pub?id=1wJSI3-ozTeEEtfLECTXEzE20lFyVLavdwmCv_z7Ftg0
The DS18B20 is the most popular of the 18xx series. It offers 12 bit resolution by default, selectable down to 10 and 8 bits. Do you have any of them? If not I can send you a couple.
The DS18B20 is the most popular of the 18xx series. It offers 12 bit resolution by default, selectable down to 10 and 8 bits. Do you have any of them? If not I can send you a couple.
Yes, it is the DS18B20+ that I have a few of. I had a look at the flowchart for the SEARCH ROM command but it's so unstructured that I decided I just need to implement this command in my own fashion. In fact I just found the 1-wire PASM code in the OBEX so I will follow that as a guide instead.
Is there a possebility to connect TACHYON to the ViewPort envoirment?
So you can combine the exelent capability of TACHYON with the gui of ViewPort
I've never looked into it before as I usually just write a couple of debugging words to display the information that I need displayed and examining and changing variables from the terminal is intrinsic to Forth itself. I think Sal even wrote a logic analyzer for PropForth so this kind of thing is possible without having to resort to external debuggers. But in saying all that I do agree that Viewport is a very powerful tool for those who program in Spin.
Pete
I prepared the following code so that I could better understand LOOKUP/VECTORS words. I created a test construct word LU that is passed a number and in this case selects from 16 words for values input from 0 to 15 and a 17th for all else
TACHYON
: SPCHAR ( char -- ) SPACE EMIT ;
: 0TH "0" SPCHAR ;
: 1ST "1" SPCHAR ;
: 2ND "2" SPCHAR ;
: 3RD "3" SPCHAR ;
: 4TH "4" SPCHAR ;
: 5TH "5" SPCHAR ;
: 6TH "6" SPCHAR ;
: 7TH "7" SPCHAR ;
: 8TH "8" SPCHAR ;
: 9TH "9" SPCHAR ;
: ATH "A" SPCHAR ;
: BTH "B" SPCHAR ;
: CTH "C" SPCHAR ;
: DTH "D" SPCHAR ;
: ETH "E" SPCHAR ;
: FTH "F" SPCHAR ;
: DEFLT ." DEFLT " ;
: LU ( input -- ) \ <limit> LOOKUP <default action> <list word 0> ... <list word limit-1>
#16 LOOKUP DEFLT \ '16' number of list words start count after DEFLT, count from 0
0TH 1ST 2ND 3RD \ DEFLT is selected if input is GT or EQ to limit
4TH 5TH 6TH 7TH
8TH 9TH ATH BTH
CTH DTH ETH FTH
;
END
Here is the results a few passes through the test construct LU ... enjoy
0 LU 0 ok
1 LU 1 ok
5 LU 5 ok
8 LU 8 ok
9 LU 9 ok
#10 LU A ok
#12 LU C ok
#14 LU E ok
#15 LU F ok
#16 LU DEFLT ok
#17 LU DEFLT ok
#18 LU DEFLT ok
#102 LU DEFLT ok
Is there a possebility to connect TACHYON to the ViewPort envoirment?
So you can combine the exelent capability of TACHYON with the gui of ViewPort
propforth was working towards an interface for Hanno's tools to work with forth. the effort was overcome by other project priorities, but there werrre no technical reasons why it wouldn't work.
it might even be easier with tachyon, as there are so many folks looking at it.
Unfortunately many command syntaxes do not have any general-purpose means of parsing in that they do not have clearly defined delimiters for one. At least if the command was written as "!CMD;100;349" then that would be far easier to set Forth to have the ";" delimiter as well as <CR>. I assume they at least include a <CR> at the end too? You can scrub out approach 2 as the preprocessing it does is fairly simple and has to do it in real-time between characters.
Approach 1 with writing a simple parser will work though as you don't have to do all the processing, it may be that the command like !CMD is fixed size or always delimited by a digit etc. So you could parse this to the point of plucking out commands and parameters and pass this through the normal word interpreter. Which reminds me, I must see about including an equivalent INTERPRET command which can take a string and process it as if it were terminal input.
If you would like to maintain normal operation of Forth from the terminal command line then integrating approach 1 with approach 3 will work also. The only downside is that there will be a small delay before control is passed to your parser as the dictionary is searched first and then an attempt is made to convert it to a number.
Hi Peter,
after a closer look into Tachyon2 I am thinking of:
1. hooking into MAIN CONSOLE TERMINAL at notfound 2. transforming the content of wordbuffer into regular forthsyntax and
3. with a new word unreadbuf push the result of the transformation back on the front of the readbuffer. Since the transformation does not grow the string this will be ok for the short commands < 64 bytes each.
4. return control to normal processing of the console input.
'' The read and write index is stored as two bytes preceding the buffer, read this as a word (faster)'' BKEY ( buffer -- ch ) ' byte size buffer is preceded with a read index, go and read the next character
'' assume the buffer is 256 bytes long
' READBUF ( buffer -- ch )
READBUF
byte DUP,DEC,DEC,DUP,WFETCH ' point to read index ( buffer writeptr writeindex )
byte SWAP,DEC,DEC,WFETCH,SWAP ' ( buffer readindex writeindex )
to me - Forth-beginner - it looks like two words are fetched and not two bytes as a word. so readindex writeindex are both treated as a word even while the buffer is only 256 bytes long
For anyone who would like to try out Tachyon preloaded with the extensions and SDCARD tools you can now download it via the Dropbox link in the binaries folder. The binary is preset for 57600 baud with a 5MHz crystal but the baudrate is easy to change once you startup. To change to 230400 baud for instance just type:
#230400 CONBAUD
The # symbol is just to make sure that the baudrate is accepted as a decimal number (230400d will work too). The baudrate will be locked into EEPROM as the default baudrate on the next reboot.
I tested this binary out on my original Prop demo board.
For anyone who would like to try out Tachyon preloaded with the extensions and SDCARD tools you can now download it via the Dropbox link in the binaries folder. The binary is preset for 57600 baud with a 5MHz crystal but the baudrate is easy to change once you startup. To change to 230400 baud for instance just type:
#230400 CONBAUD
The # symbol is just to make sure that the baudrate is accepted as a decimal number (230400d will work too). The baudrate will be locked into EEPROM as the default baudrate on the next reboot.
I tested this binary out on my original Prop demo board.
I looked up "IDUMP ( src cnt -- )" . In the absence of any further guidance I typed "0 $8000 IDUMP" copy pasted the dump into a text editor and named it BINARYTEST.HEX. Opened the HEX file in SimpleIDE put the focus on the HEX and told it to BURN EEPROM, its started and then aborted, complaining "load file bigger than 32K"
What did I do wrong and/or fail to do?
OBTW - The HEX file seems to start address at $10000 maybe explaining SimpleIDE's mistaken complaint of "over 32K"
OBTW-2 - I did a manual initiated BACKUP after adding one of my personal files after EXTEND. The EEPROM would not boot. I had to go back to SimpleIDE and start over.
I looked up "IDUMP ( src cnt -- )" . In the absence of any further guidance I typed "0 $8000 IDUMP" copy pasted the dump into a text editor and named it BINARYTEST.HEX. Opened the HEX file in SimpleIDE put the focus on the HEX and told it to BURN EEPROM, its started and then aborted, complaining "load file bigger than 32K"
What did I do wrong and/or fail to do?
OBTW - The HEX file seems to start address at $10000 maybe explaining SimpleIDE's mistaken complaint of "over 32K"
OBTW-2 - I did a manual initiated BACKUP after adding one of my personal files after EXTEND. The EEPROM would not boot. I had to go back to SimpleIDE and start over.
I will have to try using SImpleIDE a little more but where does it know how to load an Intel hex file? The reason I have an Intel hex dump is that conversion utilities are very common for this format and so I run HEX2BIN and rename the file with a .binary extension for the Spin tool to recognize.
BTW - the first 2 hex characters after the : happen to be the byte code for the line, it's the next 4 hex digits that represent the address.
I will have to try using SImpleIDE a little more but where does it know how to load an Intel hex file? The reason I have an Intel hex dump is that conversion utilities are very common for this format and so I run HEX2BIN and rename the file with a .binary extension for the Spin tool to recognize.
BTW - the first 2 hex characters after the : happen to be the byte code for the line, it's the next 4 hex digits that represent the address.
I tried as many ways, programs etc that I could think of to output $0000 $8000 IDUMP to a binary including hex2bin (mac osx) None of them were recognized as a valid image by BST like your .binary was.
Here's the best of them:
hex2bin v1.0.9, Copyright (C) 2012 Jacques Pelletier
checksum extensions Copyright (C) 2004 Rockwell Automation
improved P.G. 2007, modified Danny Schneider,2012
Comments
[FONT=courier new]{ Access TMP75 temperature chip These routines allow for multiple TMP75 devices to share the bus. Usage: 1 !TEMP \ Initialise device #1 (address $92) 1 TEMP@ CELCIUS \ Read temperature from device #1 and convert to Celcius } \ : TMP75 ( ch -- dev ) 2* $90 + ; \ Initialize the configuration register : !TEMP ( ch -- ) I2CSTART TMP75 DUP I2C! \ Address device 1 I2C! \ address configuration register 100000 I2C! \ Set 12-bit resolution + defaults I2CSTART I2C! \ Readdress to set default register as temperature 0 I2C! I2CSTOP ; : CELCIUS ( temp12 -- celcius ) 1+ 4 SHR DUP $80 AND IF $FFFF.FF00 OR THEN ; \ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP) : TEMP@ ( ch -- temp12 ) I2CSTART TMP75 1+ I2C! \ Form I2C address & address chip (blind mode) 0 I2C@ 0 I2C@ 8 SHL OR \ Fetch two bytes from device and combine into one word I2CSTOP ; [/FONT]TASKS
0001: Tachyon Console 0000 00 00 00 00 00 00
0003: Tachyon Slave 0000 01 00 00 00 00 00
0004: Tachyon Slave 0000 01 00 00 00 00 00
0005: Tachyon Slave 0000 01 00 00 00 00 00
0006: Tachyon Slave 3A73 01 00 00 00 00 00
0007: Tachyon Slave 3AD4 01 00 00 00 00 00 ok
The EXTEND.fth has the new multichannel PWM task included as well as a background timer task.
The PWM has up to 8 channels per task with 8-bit resolution at up to 5kHz. It's also possible to run some PWM channels at a multiple of the base frequency with less resolution. If you want more channels you can run another instance as another task. If there is interest I will also include a 32-channel version I have which just means that you can pick whichever pins you want for PWM.
USAGE:
( implement 8 PWM channels on P0..P7 )
\ setup area for PWM values
TABLE pwm #256 ALLOT
\ Set the frequecy
#1000 PWMFREQ
\ Start up PWM using from P0 for 8 channels (will find the next free cog to use)
0 8 pwm RUNPWM
\ Set PWM channel 0 for 50%
$80 0 PWM!
\ Set PWM channel 7 for 25%
#25 % 7 PWM!
Many applications need some kind of background polling and timing which is what the timer task does. You can launch this in a cog and it will maintain an elapsed time in milliseconds which won't wrap-around for over 49 days plus maintain the number of countdown timers you specify. When these timers countdown to zero they automatically stop and if you have set a timeout vector for that timer then it will execute that automatically.
USAGE:
( Create 8 countdown timers and assign a BLINKY function to timer 0 )
\ Allocate space for 8 timers at 8 bytes each
TABLE mytimers #64 ALLOT
\ pass parameters to start timer task
mytimers 8 RUNTIMERS
\ demo LED flasher which takes 5 seconds before it starts flashing every 100ms
: BLINKY
#16 PIN@ 0= #16 PIN! \ toggle pin 16
0 TIMER 6 + W@ 0 TIMER ! \ reload timer using stored value in timer memory
;
\ Setup the timeout vector for TIMER 0
' BLINKY 0 TIMER 4 + W!
\ Write a reload value to timer's memory
#100 0 TIMER 6 + W!
\ Setup timer 0 to timeout in 5 seconds
#5,000 0 TIMER !
The timer functions will be expanded upon to include virtual RTC support which will also automatically detect an I2C RTC if present and hopefully figure out what device it is to correctly interface to it. RTC API is non-device specific and includes fetching and storing date and time strings and longs.
V2 source code page link will now be included in the links section of the Intro page.
It is'nt working.
This is the code I tried but also no response
: TMP75_INIT
$0E $0F I2CPINS \ SET THE I2C PINS FOR THE ASC+ BOARD
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$01 I2C! \ REGISTER
$60 I2C! \ CONFIGURE
I2CSTOP \ STOP TRANSMISSION
;
: TMP75@
TMP75_INIT
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C! \ SET POINTER REGISTER TMP75 TO 0
I2CSTOP \ STOP TRANSMISSION
500 ms \ 0.5 SEC DELAY
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C@ \ READ FIRST BYTE
$01 I2C@ \ READ LAST BYTE
I2CSTOP \ STOP TRANSMISSION
;
Tis looks a little bit strange for me in the code you wrote
100000 I2C! \ Set 12-bit resolution + defaults
I think this should @60 or B01100000
I tried also the slow version no results.
It is working on the arduino, but not on the ASC+ board.
With regards to the config register it looks like my code lost the (percentage 01) just before the 100000
BTW, did you try my code at all? Also Tachyon uses common prefix and suffixes for numbers so binary is either (percent)0100 or 0100b (argghhh, forum code keeps eating the percent symbol)
while in the hot bathtub my mind was circling around Tachyon ...
and now I need to ask ...
I want to use a prop-board as a front end for a legacy test system.
Following Tachyon and this thread quite some time it seems to fullfill my needs for handling of interactive commands and downloadable test scripts.
commands are simple and would look s.th. like this in Tachyon:
100 349 CMD
12 46 DMD ... 0 to 4 16Bit Integer arguments + 3 Char Command
so quite simple to do in Forth.
Unfortunately compatibility requires me to support the old syntax:
!CMD100;349<cr/lf>
Options:
1: write a parser (I read in a Forth book, 'try to use Forth's parser instead writing your own ...)
2: so I thought since you use HS-SerialRxL to do some preprocessing on the input stream I could extend this approach to convert
!CMD100;349 to 100 349 CMD and feed it to Tachyon to do the work
3: or modify the Tachyon parser by intercepting the 'word not defined' error, then checking for the pattern !CMDxxx:yyy or even !CMDxxxxx;yyyyy;zzzzz;qqqqq then do the transformation and feed the new tokens into the input strean for further processing.
which approach would you advise me to go?
I am quite new to prop and forth, but can read and understand extend.fth already mostly. And I am heavily working through TachyonV2 and Prop ASM.
TachonV1 was running on my PropBoE, V2 I try tomorrow.
Kind regards MJB Markus from Germany
Approach 1 with writing a simple parser will work though as you don't have to do all the processing, it may be that the command like !CMD is fixed size or always delimited by a digit etc. So you could parse this to the point of plucking out commands and parameters and pass this through the normal word interpreter. Which reminds me, I must see about including an equivalent INTERPRET command which can take a string and process it as if it were terminal input.
If you would like to maintain normal operation of Forth from the terminal command line then integrating approach 1 with approach 3 will work also. The only downside is that there will be a small delay before control is passed to your parser as the dictionary is searched first and then an attempt is made to convert it to a number.
#8 MASK CONSTANT .spck #25 MASK CONSTANT .spcs BYTE chan \ ( n1 -- ) Select channel: n1 is 1 - Sram bank 0 2 - Sram bank 1 3 - Flash 4 - A/D 5 - SD Card : SPSET chan C! ; \ ( on/off -- ) Selects\Deselects C3 spi channels : SPSEL .spcs OUTCLR .spcs OUTSET IF .spck OUTCLR chan C@ 0 DO .spck OUTSET .spck OUTCLR LOOP THEN ;The attached file 'C3SPI.fth" includes the basic spi words and basic commands needed to access the flash & sram memory as well as the
adc. The second file, 'SDCARD_MOD.fth, is a modified version of SDCARD.fth for the C3. It uses the spi words defined in C3SPI. These words work with Tachyon V1.1. I have not tried Tachyon V2 at this time.
NickL
Thanks Nick, do you want me to put these files in the Dropbox folder and perhaps link to them? It's starting to look like I need to create my own organized Tachyon OBEX! (BTW, the ! at the end of OBEX might mean what it means or it might also mean "store to OBEX"
Just a little comment about comments too. If you place your stack comment after the name then it looks a little bit more familiar to those not familiar with Forth plus very soon my compiler will take that stack comment plus any other comment after it and place that automatically in a help section in EEPROM or SD etc. So instead of:
\ ( b -- ) Write 1 byte to memory at paddr, incrementing the page address.
pub WRITE
You could write:
pub WRITE ( b -- ) \ Write 1 byte to memory at paddr, incrementing the page address.
The stack comment and description are ignored at present but may be used later for help files and possibly local variable declarations too so therefore stack comments can be a bit more verbose for parameter names in anticipation of that feature and being able to reference the stack by symbol name.
I think that having a Tachyon OBEX is a good idea. It certainly would be useful to have the C3 spi words file listed in the Dropbox folder.
I will change my approach to adding comments to forth words and adopt your suggestion.
I have a question concerning EXECUTE and how it is used. In PropForth, one can do the following: ' <word> execute. I haven't been able to do this in Tachyon. I am interested in defining deferred words - in this example <word> is deferred and can be replaced with other words, depending on circumstances.
NickL
This is so very helpful for interactive development and has made the return to FORTH fun, thanks Peter. Current DropBox V2 file and Extend.fth running well on PBOE.
The ' (tick) word now operates within definitions correctly so that there is no need to create a constant beforehand.
VER @ will return the version and build in one handy long like this: 20120917
I'm also experimenting with the source code loader, line numbers etc.
I'm being summoned now so in the meantime here's a little bit of code for a PCF8563 I2C RTC chip. Other RTC chips will follow but will probably be integrated into the one RTC module so they can use common routines.
[FONT=courier new]TACHYON [~ : PCF8563.fth ; : @RTC ( reg -- ) I2CSTART $A2 I2C! I2C! ; TABLE rtc #16 ALLOT TABLE rtcmasks $FF | $FF | $7F | $7F | $3F | $3F | $07 | $1F | $FF | $7F | $3F | $3F | $07 | $03 | $03 | $FF | : RDRTC ( -- ) 0 @RTC I2CSTART $A3 I2C! 0 #16 ADO 0 I2C@ I rtcmasks + C@ AND I rtc + C! LOOP 1 I2C@ DROP I2CSTOP ; : WRRTC 0 @RTC rtc #16 ADO I C@ I2C! LOOP I2CSTOP ; : RTC! rtc + C! ; : RTC@ rtc + C@ ; : .TIME RDRTC 4 RTC@ .BYTE ." :" 3 RTC@ .BYTE ." :" 2 RTC@ .BYTE ; : .DATE \ print date as DD/MM/YY RDRTC 5 RTC@ .BYTE ." /" 7 RTC@ .BYTE ." /" 8 RTC@ .BYTE ; : BCD>DEC DUP 0F AND SWAP 4 SHR #10 * + ; : TIME@ ( -- dectime ) \ Time is represented in decimal form i.e. #123055 = 12:30 PM & 55 seconds) RDRTC 4 RTC@ BCD>DEC #10000 * 3 RTC@ BCD>DEC #100 * + 2 RTC@ BCD>DEC + ; : DATE@ ( -- decdate ) \ date is represented in decimal form as YYMMDD RDRTC 8 RTC@ BCD>DEC #10000 * 7 RTC@ BCD>DEC #100 * + 5 RTC@ BCD>DEC + ; : DEC>BCD #10 U/MOD 4 SHL + ; : TIME! ( dectime -- ) \ Store the time from a decimal form ( #123055 = 12:30:55 PM) RDRTC #100 U/MOD SWAP DEC>BCD 2 RTC! #100 U/MOD SWAP DEC>BCD 3 RTC! DEC>BCD 4 RTC! WRRTC ; : DATE! ( decdate -- ) \ Store the date from a decimal form ( #120917 = 17th Sept, 2012) RDRTC #100 U/MOD SWAP DEC>BCD 5 RTC! #100 U/MOD SWAP DEC>BCD 7 RTC! DEC>BCD 8 RTC! WRRTC ; ]~ END [/FONT]Hi Jan, how did you go with using the 8 channel PWM module?
I've been using it myself with my H-bridge modules and motors and I have just updated the kernel to include a faster table update module, not that I had any problems with it, I just wanted to make it better. Originally PWM! which sets the duty cycle for the channel was just scanning through a 256 byte table clearing and setting masks which took >5ms but then I did another version which cut that in half. Not happy with that I then created a PWM! PASM module which like the other specialized modules just gets loaded as needed and are useful in repetitive tasks. So the load time is around 20us and setting the table takes around 200us.
https://docs.google.com/document/pub?id=1wJSI3-ozTeEEtfLECTXEzE20lFyVLavdwmCv_z7Ftg0
The DS18B20 is the most popular of the 18xx series. It offers 12 bit resolution by default, selectable down to 10 and 8 bits. Do you have any of them? If not I can send you a couple.
So you can combine the exelent capability of TACHYON with the gui of ViewPort
I prepared the following code so that I could better understand LOOKUP/VECTORS words. I created a test construct word LU that is passed a number and in this case selects from 16 words for values input from 0 to 15 and a 17th for all else
Here is the results a few passes through the test construct LU ... enjoy
it might even be easier with tachyon, as there are so many folks looking at it.
Hi Peter,
after a closer look into Tachyon2 I am thinking of:
1. hooking into MAIN CONSOLE TERMINAL at notfound
2. transforming the content of wordbuffer into regular forthsyntax and
3. with a new word unreadbuf push the result of the transformation back on the front of the readbuffer. Since the transformation does not grow the string this will be ok for the short commands < 64 bytes each.
4. return control to normal processing of the console input.
to me - Forth-beginner - it looks like two words are fetched and not two bytes as a word. so readindex writeindex are both treated as a word even while the buffer is only 256 bytes long
yes would love that - like LISPs EVAL function.
thanks Markus
#230400 CONBAUD
The # symbol is just to make sure that the baudrate is accepted as a decimal number (230400d will work too). The baudrate will be locked into EEPROM as the default baudrate on the next reboot.
I tested this binary out on my original Prop demo board.
[FONT=lucida console]INFO Propeller .:.:--TACHYON--:.:. Forth V20120919.1215 Clock frequency = 80,000,000 MODULES LOADED SDCARD.fth SD CARD Toolkit - 120908.0400 EXTEND.fth Primary extensions to TACHYON kernel - 120923.2300 Tasks 0000: Tachyon Slave 0000 01 00 00 00 00 00 0001: Tachyon Console 0000 00 00 00 00 00 00 0003: Tachyon Slave 0000 01 00 00 00 00 00 0004: Tachyon Slave 0000 01 00 00 00 00 00 0005: Tachyon Slave 0000 01 00 00 00 00 00 0006: Tachyon Slave 0000 01 00 00 00 00 00 0007: Tachyon Slave 4348 01 00 00 00 00 00 Status CODE @$52AC - bytes added = 2151 and 11604 bytes free NAMES @$240C - bytes added = 0739 and 1980 bytes free YCALLS @ 0103 entries free Runtime since last reset = 1,085,775ms I2C BUS SCAN Fast Device at 00A0 B4 C4 04 6F 46 10 00 00 I/O Port states +----------u----------+ P00 <-- * 1 --> P31 P01 <-- * 1 <-- P30 P02 <-- * 1 --> P29 P03 <-- * * <-- P28 P04 <-- * 1 --> P27 P05 <-- * 1 --> P26 P06 <-- * 1 --> P25 P07 <-- 1 1 --> P24 P08 <-- * * --> P23 P09 <-- * * --> P22 P10 <-- * * --> P21 P11 <-- * * --> P20 P12 <-- * * --> P19 P13 <-- * * --> P18 P14 <-- * * --> P17 P15 <-- * * --> P16 +---------------------+ Special function registers 01F0: PAR = $0000_16C0 %0000_0000_0000_0000_0001_0110_1100_0000 01F1: CNT = $43A6_CD25 %0100_0011_1010_0110_1100_1101_0010_0101 01F2: INA = $EF00_0080 %1110_1111_0000_0000_0000_0000_1000_0000 01F3: INB = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01F4: OUTA = $4000_0000 %0100_0000_0000_0000_0000_0000_0000_0000 01F5: OUTB = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01F6: DIRA = $5000_0000 %0101_0000_0000_0000_0000_0000_0000_0000 01F7: DIRB = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01F8: CTRA = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01F9: CTRB = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01FA: FRQA = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01FB: FRQB = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01FC: PHSA = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01FD: PHSB = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01FE: VCFG = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 01FF: VSCL = $0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 ok QWORDS SPINNERET PPUSB BOE BOECARD? CE1200 CE0972 P1145 P1107 P1144 LR XLOAD XSAVE SDPOLL SD XDUMP SDWR SDRD PROCESS_TOKEN SDRDBLK (SDRD) (SDWR) .CARD tval NA@ CID@ CSD@ BEXT XSHR XSHR1 !SD ?TIMEOUT !TIMEOUT GETCID GETCSD SDDAT! SDERR? STAT@ ACMD CMD MARKER? RES@ !SDIO SDBUSY &sdto SDCLK SLOWCLK SD4@ SD2@ SD! SD@ SPIO CARD? SDSEL SDPINS SCK MOSI MISO SDCS SDMASKS SDCNT #datatkne #datatkn1 #datatkn extbuf csd cid card? crc ucard timeout sdtimer oc sdrd sdwr sdflg sdsize sdpins SDBUF BLKSIZ SDCARD.fth COLD EXTEND exttimers INFO STATS END .RUNTIME BINARYDUMP IDUMP FIXCKSUM cksum CONBAUD RESTORE ?BACKUP BACKUP kernel 64K? EVERIFY EFILL EECOPY eebuf ELOAD ESAVEB ESAVE EDUMP ENDRD EE@ EE! EERD @EE I2CBUS SI2C@ SI2C! SI2C!? I2C@ I2C! I2C!? I2CSTOP I2CSTART I2CPINS EEPROM SDA SCL sda scl % PWM! PWMFREQ RUNPWM PWMCOG pwmfreq pwmtbl pwmchans pwmpins RUNTIMERS TIMERTASK ALARM TIMEOUT? TIMEOUT TIM timercnt timers runtime MUTE HZ KHZ MHZ DAC! FRQ BPIN APIN PLLDIV PLL DUTY CTRMODE NCO B A CTR@ CTR! CTR ctr PINS? .PIN SPRS REG$ .LAP .NUM (SEP) B>L B>W W>L W>B L>W >B >W CON SERIN SEROUT SERBAUD MAP MODULES QWORDS @. C~~ C~ W~~ W~ ~~ ~ C-- C++ W-- W++ -- ++ <= => >| |< seconds second MOD LONGFILL LBIT! MASKS PININP PINCLR PINSET TYPE SPACES ALIGNL TASKS TASK? ENQ@ ATN! ENQ! ATN@ ATN? RUN COGINIT @CNT @MISO @MOSI @SCK COGREG@ COGREG! CLKFREQ U@ .INDEX ... Published IMMEDIATE ok ]~ [~ LEMIT EXTEND.fth RESET 0EXIT EXIT NOP 3DROP 2DROP DROP ?DUP DUP OVER 3RD 4TH SWAP ROT NIP 1+ 1- + - * U/MOD UM* NEGATE INVERT AND ANDN OR XOR ROL ROR SHR SHL 2/ 2* REV MASK 0= = > C@ W@ @ C+! C! C@++ W+! W! +! ! CMOVE BIT! SET CLR IC! (PUSH4) (PUSH3) (PUSH2) (PUSH1) (VAR) FALSE OFF 0 1 2 3 4 5 6 7 8 ON TRUE -1 BL IN@ P@ OUT! P! CLOCK OUTSET OUTCLR OUTPUTS INPUTS WAITLOW SHROUT SHRINP LOADMOD RUNMOD SFR@ SPR@ COG@ COGREG COG! PASM STACKS LSTACK CALL JUMP (XCALL) (YCALL) (WCALL) (ELSE) (IF) (UNTIL) (AGAIN) ADO DO LOOP +LOOP FOR NEXT <BEGIN AGAIN> UNTIL> POPMARK >R R> >L L> (EMIT) (REG) REG DELTA WAITCNT WAITPEQ WAITPNE CMPSTR I XCALLS REBOOT STOP COGID PAR CNT INA INB OUTA OUTB DIRA DIRB CTRA CTRB FRQA FRQB PHSA PHSB VCFG VSCL SPR SPR! [SPIO] [SPIOD] [SDRD] [SDWR] [PWM] [PWM!] [PLOT] !SP 2+ 2- SET? / 2DUP MIN MAX 0<> <> 0> 0< < U< WITHIN ?EXIT BOUNDS LEAVE J K IX ERASE FILL ms us CNT@ NEWCNT LAPCNT OUT IN INPUT PIN! PIN@ KEY? KEY HEX DECIMAL BINARY .S DUMP COGDUMP .STACKS DEBUG EMIT CLS SPACE BELL CR SPINNER .HEX .BYTE .WORD .LONG . >DIGIT NUMBER SCRUB GETWORD FINDSTR NFA>CFA EXECUTE V2 VER .VER TACHYON @PAD HOLD >CHAR #> <# # #S (STR) .STR STRLEN U. .DEC DISCARD colors pixels REG flags base digits delim word autorun keypoll tasks unum uemit ukey names here codes errors baudcnt prompt find create lines ALLOT ALLOCATED HERE AUTO! MARK UNMARK >PFA NFA' ' KEYPOLL \ '' ( { } IFNDEF " ." AUTORUN IF ELSE THEN ENDIF BEGIN UNTIL AGAIN WHILE REPEAT ; [COMPILE] GRAB LITERAL : pub pri CREATEWORD CREATE CVARIABLE WVARIABLE VARIABLE BYTE WORD LONG TABLE CONSTANT C, | || TASK IDLE LOOKUP VECTORS +XCALL +YCALL ITEM ITEM@ ITEMS NFA>CFA WORDS =PIXELS STATS FREE COLD ok [/FONT]I looked up "IDUMP ( src cnt -- )" . In the absence of any further guidance I typed "0 $8000 IDUMP" copy pasted the dump into a text editor and named it BINARYTEST.HEX. Opened the HEX file in SimpleIDE put the focus on the HEX and told it to BURN EEPROM, its started and then aborted, complaining "load file bigger than 32K"
What did I do wrong and/or fail to do?
OBTW - The HEX file seems to start address at $10000 maybe explaining SimpleIDE's mistaken complaint of "over 32K"
OBTW-2 - I did a manual initiated BACKUP after adding one of my personal files after EXTEND. The EEPROM would not boot. I had to go back to SimpleIDE and start over.
BTW - the first 2 hex characters after the : happen to be the byte code for the line, it's the next 4 hex digits that represent the address.
I tried as many ways, programs etc that I could think of to output $0000 $8000 IDUMP to a binary including hex2bin (mac osx) None of them were recognized as a valid image by BST like your .binary was.
Here's the best of them:
hex2bin v1.0.9, Copyright (C) 2012 Jacques Pelletier
checksum extensions Copyright (C) 2004 Rockwell Automation
improved P.G. 2007, modified Danny Schneider,2012
Lowest address = 00000000
Highest address = 00007FFF
Pad Byte = FF
8-bit Checksum = 15
-rw-r--r-- 1 dp staff 32768 Sep 24 15:33 Tachyon.binary