"the values at the ROM location just happens to contain the same value for 4 longs in a row"
Thanks for looking at this. The "F"/"0" scenario happens throughout the entire ROM pick a row any row. ... If that indeed is the case, then the entire ROM could be represented in 1/4 of the current size substituting every "F" with a "1". I would be extremely surprised if that were the case.
I can 'trick' the output into reporting something other than "F" or "0" by adding a random element after the ROM read. So that sort of rules out reading the 'ROM_Word' improperly
PropellerROM := long[ Base + WordLineOffset + ROM_Longs ] 'Read LONG value from Propeller's ROM
If ROM_Longs == 0 or ROM_Longs == 1 or ROM_Longs == 5
PropellerROM?
...but because it's pseudo random and the Seed relies on the current value, a simple line of...
PropellerROM := long[ Base + WordLineOffset + ROM_Longs ] 'Read LONG value from Propeller's ROM
PropellerROM?
...at the same location results also in "F"/"0" output
Suppose the sanity check would be to take the output and apply it in reverse to see if I can generate the original Propeller ROM code
Change:
PropellerROM := long[ Base + WordLineOffset + ROM_Longs ] 'Read LONG value from Propeller's ROM
To:
PropellerROM := long[ Base + ((WordLineOffset + ROM_Longs)<<2) ] 'Read LONG value from Propeller's ROM
Remember we are reading LONGS from the memory and the offset must incremented by FOUR steps each time.
Because of the address alignment (address&0x11111111_11111111_11111111_11111100) we read the SAME address 4 times in a row.
@Beau Schwabe
"Since we don't have a Propeller II yet, what I can do is put you on my radar for any pre-release beta testing when that becomes available."
I would LOVE that.
Then I would make some awesome demos for the prop2 to showcase the power of the chip. I do already have some ideas of what could be done.
Of course running SIDcog in 33100 x 8 = 264800Hz (or even more thanks to the multiplication instructions) for "aliasing free" sound generation would be cool as well.
The SSD is configured as a swap drive, but since it's solid state, it doesn't suffer the speed impact that a mechanical hard drive would, nor the hashing/thrashing that would take place.
The SSD only used about %7 of it's capacity ... The final Prop II design will be about 2.5 times larger than the test DIE so maybe %20 or so will be used then.
It's just nice to have the 'overflow' that goes to the SSD rather than to the Hard Drive.
Here are the notes I used to create the swap drive on my Linux system:
Creating / Adding Swap Partition to system:
First find a partition you wish to use as a swap partition.
Next access the drive we want to make a swap partition on.
i.e.
fdisk /dev/hdb
if the partition already exists, then you may skip this step, otherwise,
you need to create a partition. Type 'n' (for create New), choose the
partition type as primary
Once the partition is created, make sure it is a type 82 - Linux SWAP partition.
To check/change the partition type, type 't', enter, then the partition number
(if more than one), and then the code for the desired type. the 'L' command
displays a huge list of known types.
after double checking that you were editing the proper drive (/dev/hda, /dev/hdb,
/dev/sdc, etc), and using the 'p' command to verify your work is correct, type
'w' to write your changes and return to the root prompt.
now, in this example we created /dev/hdb1 as a swap partition, so it is 'tagged'
as a swap (type 82), but isn't formatted' as a swap.
Type 'mkswap /dev/hdb1' and the partition will have the proper magic numbers
placed in it to signal it is a valid swap partition. BE CAREFUL, MISTYPING THIS
COMMAND CAN BE VERY VERY BAD IF YOU HAVE EXISTING DATA AND SPECIFY THE WRONG
DRIVE/PARTITION!!!!!
now the swap partition is created. We have to add it to the /etc/fstab file so
it will be seen during boot and added to the system.
edit /etc/fstab with a text editor and add this line:
/dev/hdb1 swap swap defaults 0 0
location in the file doesn't matter, although style points are awarded for
keeping the fstab file sorted by drive and partition number.
after you've saved that, type 'swapon -a' and the swap partition should be
added to the system virtual ram cache. Verify it was added by using the 'free'
command. The value under 'total' and 'swap' should be the same as the size of
the partition you created.
As of today, the Propeller Test DIE Database is "FROZEN"! ... This is a good thing :smilewinkgrin: ... it means that the data is fixed and can't be touched.
There are just a few paper work items that need to be addressed the remainder of this week, but the November 3rd tape-out date looks to be a GO!!!
Are there some steps we are missing out on here. Like, given this test die seems to be one third of the finished device surely there has been a lot of simulation of the logic going on at some point to verify operation?
As of today, the Propeller Test DIE Database is "FROZEN"! ... This is a good thing :smilewinkgrin: ... it means that the data is fixed and can't be touched.
There are just a few paper work items that need to be addressed the remainder of this week, but the November 3rd tape-out date looks to be a GO!!!
Wooho! I'm looking forward to this special processor! Please keep us updated!
Must be another one of the great stuff in Christmas season.
"How many test chips will be produced?" - I think minimum is 40 die, but I'm not positive on that.
Heater,
"Are there some steps we are missing out on here. Like, given this test die seems to be one third of the finished device surely there has been a lot of simulation of the logic going on at some point to verify operation?" - I leave most of the simulation to Chip, and insert some constructive criticism where I feel that it is appropriate.
John A. Zoidberg,
"Must be another one of the great stuff in Christmas season." - We should know the outcome of the Test Die results by Christmas, but there still is a nice road in front of us... The Test Die will help determine how bumpy of a road it might be though. ... If things go as planned, we could realistically have Propeller II silicon by this time next year.
As of today, the Propeller Test DIE Database is "FROZEN"! ... This is a good thing :smilewinkgrin: ... it means that the data is fixed and can't be touched.
There are just a few paper work items that need to be addressed the remainder of this week, but the November 3rd tape-out date looks to be a GO!!!
Yea. We're still on the same boat - it's just that fabrication of propeller II test die takes time to be done with. It's basically arts, which is pretty difficult even to predict, leave alone in Beau's capable hands. it may be few more weeks or months before we hear a peep from the test shuttle guys or even Beau himself.
I have a suggestion for the Prop II spin code or the next release of SPIN.
We all know the Propeller can preform as a I2C master. It's software. But there are some issues with this configuration:
#1: There are dozens of drivers, all of which work for their intended device, but not general enough to work with all devices.
#2: It takes a COG or two and additional resources to setup and use.
#3: The Propeller can't become a slave I2C device.
My suggestion is a I2CSLAVE command.
Basically it would place a pin into I2C Slave mode. It would need just a few arguments:
#1: The pin to monitor.
#2: The address to react to.
#3: The same basic parameters found in PBASIC 2.0's I2CIN and I2COUT commands.
This would allow for reduced size in SPIN and PASM programs, Increase it's functionality and reduce the number of custom I2C routines that are in existence. Additionally, this would enable the Propeller to become an accessory to other controllers (like the STAMP's) as a very intelligent I2C device, expanding their functionality as well.
This whole idea came up as I was revisiting my BS2P40 room monitoring project. I need to add additional devices to it, but I can't due to hardware considerations. A Propeller with the ability to respond as a I2C slave on a specified address would add a LOT of functionality at a minor cost to a lot of other devices already in existence; extending functionality where it wasn't able to be extended. This type of expansion would include the Propeller II deep into the realm of smart devices that can be easily embedded into other devices.
The STAMP's I2C commands are much more flexible and functional. If someone could (because it's beyond my ability to) write a I2C routines that could both master and slave an I2C chain(s), and have that fit inside a single COG, then this whole suggestion is mute.
The I2C specs are well known, it's how they are implemented in the current objects that become problematic.
Prior to the release of the Propeller I, Phillips required a license for I2C. By purchasing an I2C device that was considered a 'slave' you were grandfathered in to the license. Which means that in order to implement a 'slave' device on a micro and distribute it, you were required to obtain a specific license from Phillips.
This license requirement was lifted October 1, 2006 as a generic statement from Phillips ... "I2C licenses for standard mode under the remaining patents in the program will be free of any royalties, for any use of the patents after October 1, 2006, without any prejudice to any claims for past use whatsoever."
Some of this information can be found using the 'Wayback Machine' with this address ... http://www.nxp.com/buses/i2c/ ... since this information only seems to have been available between November 2006 and June 2008.
I was hoping to have something in hand that we could test before Christmas... as it is, it looks like the 28th of December we will have something to wiggle the bits on. So... first week of January 2011, we should know more information.
Comments
"the values at the ROM location just happens to contain the same value for 4 longs in a row"
Thanks for looking at this. The "F"/"0" scenario happens throughout the entire ROM pick a row any row. ... If that indeed is the case, then the entire ROM could be represented in 1/4 of the current size substituting every "F" with a "1". I would be extremely surprised if that were the case.
I can 'trick' the output into reporting something other than "F" or "0" by adding a random element after the ROM read. So that sort of rules out reading the 'ROM_Word' improperly
PropellerROM := long[ Base + WordLineOffset + ROM_Longs ] 'Read LONG value from Propeller's ROM If ROM_Longs == 0 or ROM_Longs == 1 or ROM_Longs == 5 PropellerROM?...but because it's pseudo random and the Seed relies on the current value, a simple line of...
PropellerROM := long[ Base + WordLineOffset + ROM_Longs ] 'Read LONG value from Propeller's ROM PropellerROM?...at the same location results also in "F"/"0" output
Suppose the sanity check would be to take the output and apply it in reverse to see if I can generate the original Propeller ROM code
Change:
PropellerROM := long[ Base + WordLineOffset + ROM_Longs ] 'Read LONG value from Propeller's ROM
To:
PropellerROM := long[ Base + ((WordLineOffset + ROM_Longs)<<2) ] 'Read LONG value from Propeller's ROM
Remember we are reading LONGS from the memory and the offset must incremented by FOUR steps each time.
Because of the address alignment (address&0x11111111_11111111_11111111_11111100) we read the SAME address 4 times in a row.
/ Ahle2
Wow thanks!... can't believe I didn't see that.
This really helps!
/ Ahle2
... Since we don't have a Propeller II yet, what I can do is put you on my radar for any pre-release beta testing when that becomes available.
That big SSD, configured as RAM comes into play how then? Do you also have a RAM filesystem, for loading lots of stuff, saving states, blocks?
Or was it just really cool to have that much headroom, or maybe it's needed for the real Prop II?
"Since we don't have a Propeller II yet, what I can do is put you on my radar for any pre-release beta testing when that becomes available."
I would LOVE that.
Then I would make some awesome demos for the prop2 to showcase the power of the chip. I do already have some ideas of what could be done.
Of course running SIDcog in 33100 x 8 = 264800Hz (or even more thanks to the multiplication instructions) for "aliasing free" sound generation would be cool as well.
/ Ahle2
The SSD is configured as a swap drive, but since it's solid state, it doesn't suffer the speed impact that a mechanical hard drive would, nor the hashing/thrashing that would take place.
The SSD only used about %7 of it's capacity ... The final Prop II design will be about 2.5 times larger than the test DIE so maybe %20 or so will be used then.
It's just nice to have the 'overflow' that goes to the SSD rather than to the Hard Drive.
Here are the notes I used to create the swap drive on my Linux system:
As of today, the Propeller Test DIE Database is "FROZEN"! ... This is a good thing :smilewinkgrin: ... it means that the data is fixed and can't be touched.
There are just a few paper work items that need to be addressed the remainder of this week, but the November 3rd tape-out date looks to be a GO!!!
One big milestone passed!
How many test chips will be produced?
Sounds like excellent news.
Are there some steps we are missing out on here. Like, given this test die seems to be one third of the finished device surely there has been a lot of simulation of the logic going on at some point to verify operation?
Wooho! I'm looking forward to this special processor! Please keep us updated!
Must be another one of the great stuff in Christmas season.
"How many test chips will be produced?" - I think minimum is 40 die, but I'm not positive on that.
Heater,
"Are there some steps we are missing out on here. Like, given this test die seems to be one third of the finished device surely there has been a lot of simulation of the logic going on at some point to verify operation?" - I leave most of the simulation to Chip, and insert some constructive criticism where I feel that it is appropriate.
John A. Zoidberg,
"Must be another one of the great stuff in Christmas season." - We should know the outcome of the Test Die results by Christmas, but there still is a nice road in front of us... The Test Die will help determine how bumpy of a road it might be though. ... If things go as planned, we could realistically have Propeller II silicon by this time next year.
We all know the Propeller can preform as a I2C master. It's software. But there are some issues with this configuration:
#1: There are dozens of drivers, all of which work for their intended device, but not general enough to work with all devices.
#2: It takes a COG or two and additional resources to setup and use.
#3: The Propeller can't become a slave I2C device.
My suggestion is a I2CSLAVE command.
Basically it would place a pin into I2C Slave mode. It would need just a few arguments:
#1: The pin to monitor.
#2: The address to react to.
#3: The same basic parameters found in PBASIC 2.0's I2CIN and I2COUT commands.
This would allow for reduced size in SPIN and PASM programs, Increase it's functionality and reduce the number of custom I2C routines that are in existence. Additionally, this would enable the Propeller to become an accessory to other controllers (like the STAMP's) as a very intelligent I2C device, expanding their functionality as well.
This whole idea came up as I was revisiting my BS2P40 room monitoring project. I need to add additional devices to it, but I can't due to hardware considerations. A Propeller with the ability to respond as a I2C slave on a specified address would add a LOT of functionality at a minor cost to a lot of other devices already in existence; extending functionality where it wasn't able to be extended. This type of expansion would include the Propeller II deep into the realm of smart devices that can be easily embedded into other devices.
The STAMP's I2C commands are much more flexible and functional. If someone could (because it's beyond my ability to) write a I2C routines that could both master and slave an I2C chain(s), and have that fit inside a single COG, then this whole suggestion is mute.
Just a suggestion,
Fred
WOW...
Ok... My Sorries...
Jazzed, do you think you can share your code?
Use code from post #18 here http://forums.parallax.com/showthread.php?102839-I2C-Slave
Prior to the release of the Propeller I, Phillips required a license for I2C. By purchasing an I2C device that was considered a 'slave' you were grandfathered in to the license. Which means that in order to implement a 'slave' device on a micro and distribute it, you were required to obtain a specific license from Phillips.
This license requirement was lifted October 1, 2006 as a generic statement from Phillips ... "I2C licenses for standard mode under the remaining patents in the program will be free of any royalties, for any use of the patents after October 1, 2006, without any prejudice to any claims for past use whatsoever."
Some of this information can be found using the 'Wayback Machine' with this address ... http://www.nxp.com/buses/i2c/ ... since this information only seems to have been available between November 2006 and June 2008.
Wayback link:
http://web.archive.org/web/*/http://www.nxp.com/buses/i2c/
To the original request... I don't know if there will be an I2C implementation, SLAVE or MASTER, on the Propeller II or not.
Is there an easy way to convert this into the current forum url message header?
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=355505
The thread in the new forum is http://forums.parallax.com/showthread.php?113267-I2C-slave-example
Very interesting code... I can't want for the PII to start to be tested...