All of the CHKxxx instructions seem like overkill and wasting transistors and an opcode for something that is probably never on a critical timing path and can easily be done in software.
I was going to suggest that, now that we have hubexec, perhaps these can be moved to the monitor. But as ctwardell suggests these may be for use by the monitor, implying that it's a ROM space saving measure.
About the controversial CHKDEC/CHKHEX/CHKLET/CHKSYM instructions: Of course, these can be done in software, but having instructions handy in PASM will make textual interfaces really simple to code. The logic expense to implement these is less than 0.1% of the silicon.
Today I got the following new instructions implemented:
TOPONE D 'Get top-most '1' bit position in D
TOPZER D 'Get top-most '0' bit position in D
BOTONE D 'Get bottom-most '1' bit position in D
BOTZER D 'Get bottom-most '0' bit position in D
These return D=0..31 and C=0 if a bit was located, or D=0 and C=1 if no target bit existed.
I wanted to get these in before the next release.
I think, at this point, we've got a really rich set of bit, logic, and math ops.
The branching and addressing instructions seem pretty complete, as well, to me. In updating the ROM Monitor, I was able to simplify the heck out the string/table handling because of instructions like LOCPTRA. I don't think it could be any simpler.
We just need to get some USB-helpers and the SERDES done after this next release.
About the controversial CHKDEC/CHKHEX/CHKLET/CHKSYM instructions: Of course, these can be done in software, but having instructions handy in PASM will make textual interfaces really simple to code. The logic expense to implement these is less than 0.1% of the silicon.
Today I got the following new instructions implemented:
TOPONE D 'Get top-most '1' bit position in D
TOPZER D 'Get top-most '0' bit position in D
BOTONE D 'Get bottom-most '1' bit position in D
BOTZER D 'Get bottom-most '0' bit position in D
These return D=0..31 and C=0 if a bit was located, or D=0 and C=1 if no target bit existed.
I wanted to get these in before the next release.
I think, at this point, we've got a really rich set of bit, logic, and math ops.
The branching and addressing instructions seem pretty complete, as well, to me. In updating the ROM Monitor, I was able to simplify the heck out the string/table handling because of instructions like LOCPTRA. I don't think it could be any simpler.
We just need to get some USB-helpers and the SERDES done after this next release.
Those sound quite useful for allocation bitmaps among other things.
In updating the ROM Monitor, I was able to simplify the heck out the string/table handling because of instructions like LOCPTRA. I don't think it could be any simpler.
Did the ROM get smaller, or did you pack more into the ROM area ?
I like all the new instructions that take 4 or 5 or 10 lines of PASM down to one. Even with HUBEXEC, cog RAM is still a valuable commodity. If you are multitasking multiple features into a cog, those saved longs will become important. This was shown with the beauty of SERIN/OUT where you can replace 62 lines of PASM with 4 lines! Yes, it's a lot of new instructions to keep in mind but I think they will get used by the PASM coders.
[H]aving [text] instructions handy in PASM will make textual interfaces really simple to code. The logic expense ... is less than 0.1% of the silicon.
You go, Chip! Text is king! Follow your instinct. No precedent is necessary; blaze a trail. And position that P2 to meet a variety of needs (yes, some of them narrow but cool/useful), making the chip something to be proud of (for all of us in many way). It's a delicate balance you're composing, and it sounds like it's going to be just what the doctor ordered (unless the world needs another "me-too" ARM chip).
You go, Chip! Text is king! Follow you instinct. No precedent is necessary; blaze a trail. And position that P2 to meet a variety of needs (yes, some of them narrow but cool/useful), making the chip something to be proud of (for all of us in many way). It's a delicate balance you're composing, and it sounds like it's going to be just what the doctor ordered (unless the world needs another "me-too" ARM chip).
Watching those UNIX videos that Heater posted reaffirmed to me the significance and beauty of 7-bit ASCII. Some concepts are timeless and may matter forever.
It was providence in the Western world that we had alphabets that could be encoded, along with numerals, in only 6 or 7 (with lowercase) bits. The Chinese would have needed to wait for 16 bit systems to store their characters, plus large memories to hold their bitmaps. That was no place to be bootstrapping from.
FYI The mini I worked on (Friden/Singer/ICL System Ten circa 1969-1980) used 6 bit Ucase ASCII from columns 2-5. To get control characters you used a WriteControl instruction that converted cols 4&5 to cols 0&1. Worked extremely well for the era. Core memory was $$$ at ~$10,000 per 10Kx6bits - ouch!
My mini (yes I owned one) took the length of my garage (a/c etc of course) and had the maximum core memory of 110Kx6b and 3x 10MB H/Disks. we have come a little way since then
FYI The mini I worked on (Friden/Singer/ICL System Ten circa 1969-1980) used 6 bit Ucase ASCII from columns 2-5. To get control characters you used a WriteControl instruction that converted cols 4&5 to cols 0&1. Worked extremely well for the era. Core memory was $$$ at ~$10,000 per 10Kx6bits - ouch!
My mini (yes I owned one) took the length of my garage (a/c etc of course) and had the maximum core memory of 110Kx6b and 3x 10MB H/Disks. we have come a little way since then
Did you acquire that setup 'used'? That would have been more expensive than a house.
Watching those UNIX videos that Heater posted reaffirmed to me the significance and beauty of 7-bit ASCII. Some concepts are timeless and may matter forever.
Seeing that made me happy.
Actually, I'm also reminded of computers where some handy, basic things are built in, usually the ROM, Here, we've packed good ones into instructions.
Did you acquire that setup 'used'? That would have been more expensive than a house.
It was 18mths old when I bought it. Yes it was very expensive. Come to think of it, yes, it was more expensive than my house.
I was writing commercial software for customers as well as developing hardware interfaces to it, so it saved me having to get time on someone else's mini at unreasonable hours. BTW I kept it running until 2000 when I sold it for scrap (gold).
It was 18mths old when I bought it. Yes it was very expensive. Come to think of it, yes, it was more expensive than my house.
I was writing commercial software for customers as well as developing hardware interfaces to it, so it saved me having to get time on someone else's mini at unreasonable hours. BTW I kept it running until 2000 when I sold it for scrap (gold).
That must have been pretty neat. You're used to having fun.
That must have been pretty neat. You're used to having fun.
Yes, it was fun!
You would not believe the similarities between the System Ten and the P1... Dual operand instructions, JMPRET style instruction, all instructions memory to memory, equivalent hub and cog memory, up to 20 cores (but hardware time sliced).
I've got the FPGA compiling well now with all the new instructions and new ROM. I just need to get the docs updated to get the next release done. This has taken longer than I thought it would.
I have a question for you all:
In contemplating that each Prop2 will connect to an 8-pin SPI flash chip that it can boot from, and that these chips provide 8MB for under $1, or 16MB for less than $2, we effectively have a local solid-state drive that holds 32x or 64x the RAM of the Prop2. This amount of memory warrants a FAT scheme, so that actual files, aside from just boot data, can be realized. Is there any reason to stick with some standard FAT system for an application like this, where the media is not removable? Couldn't we make up our own FAT scheme and then have simple utilities to shuttle files between the Prop2 and larger systems?
I'm just realizing that this issue ought to be addressed so that we'll have a common basis for file storage in that 8-pin Flash chip.
If we do this right, we should have a significant basis for UNIX-like operability - in the original sense of the concept.
I've got the FPGA compiling well now with all the new instructions and new ROM. I just need to get the docs updated to get the next release done. This has taken longer than I thought it would.
I have a question for you all:
In contemplating that each Prop2 will connect to an 8-pin SPI flash chip that it can boot from, and that these chips provide 8MB for under $1, or 16MB for less than $2, we effectively have a local solid-state drive that holds 32x or 64x the RAM of the Prop2. This amount of memory warrants a FAT scheme, so that actual files, aside from just boot data, can be realized. Is there any reason to stick with some standard FAT system for an application like this, where the media is not removable? Couldn't we make up our own FAT scheme and then have simple utilities to shuttle files between the Prop2 and larger systems?
I'm just realizing that this issue ought to be addressed so that we'll have a common basis for file storage in that 8-pin Flash chip.
However flash fs's have to be somewhat different than FAT for two reasons:
1) minimum erase grain is 4K, so "clusters" should be 4K in size
2) it is possible to write '0' bits to '1' bits in existing sectors
Possibly a modified version of the minix file system would be good.
p.s.
I have written a NOR-flash-optimized Unix like filesystem for my projects, however I cannot open source it as wifey would kill me if I gave away man-months of work.
I've got the FPGA compiling well now with all the new instructions and new ROM. I just need to get the docs updated to get the next release done. This has taken longer than I thought it would.
I have a question for you all:
In contemplating that each Prop2 will connect to an 8-pin SPI flash chip that it can boot from, and that these chips provide 8MB for under $1, or 16MB for less than $2, we effectively have a local solid-state drive that holds 32x or 64x the RAM of the Prop2. This amount of memory warrants a FAT scheme, so that actual files, aside from just boot data, can be realized. Is there any reason to stick with some standard FAT system for an application like this, where the media is not removable? Couldn't we make up our own FAT scheme and then have simple utilities to shuttle files between the Prop2 and larger systems?
I'm just realizing that this issue ought to be addressed so that we'll have a common basis for file storage in that 8-pin Flash chip.
If we do this right, we should have a significant basis for UNIX-like operability - in the original sense of the concept.
Flash file systems normally don't use the FAT standard because of the requirements of the flash chip, which are the limited number of writes that can be done to a block and the fact that a block must be erased to change a value in it. A flash file system must provide a method for wear leveling. The only flash file system I'm familiar with used a linear file system where files are written linearly one after another, and the file name and attributes are written contiguous with the file's contents. When a file is changed, its original version is deleted by clearing a bit in its file descriptor, and writing the new version of the file at the end of the string.
A file system like this will eventually fill up the flash chip with lots of deleted files, so a reclaim operation must be done at some point to eliminate the deleted files and compact the file system. Some file systems partition the flash into two halves, and perform the reclaim into the unused half, and then switch over to that half after the reclaim is completed. This allows for the reclaim to run in the background, and also allows for recovering if the reclaim fails.
It would be nice to have code for a flash file system that everybody could use, but I don't think there's an immediate need for this. However, it would be nice to have one even for P1 boards that contain flash.
In contemplating that each Prop2 will connect to an 8-pin SPI flash chip that it can boot from, ...
I could see and advantage to use a FAT scheme: in the case that someone makes an adapter between SPI and USB mass storage (PENDRIVE) or any other kind of mass storage (MMC, Compact Flash, IDE/ATA, SATA, etc ...).
Imagine a USB pendrive with a selectable interface: USB or SPI ( USB <=> Flash <=> SPI ). I think this can be easily done with current commercial usb controllers (if there is anyone that can use serial SPI) by adding just a multiplexer. Or even better, a DUAL PORT mass storage !
Flash file systems normally don't use the FAT standard because of the requirements of the flash chip, which are the limited number of writes that can be done to a block and the fact that a block must be erased to change a value in it. A flash file system must provide a method for wear leveling. The only flash file system I'm familiar with used a linear file system where files are written linearly one after another, and the file name and attributes are written contiguous with the file's contents. When a file is changed, its original version is deleted by clearing a bit in its file descriptor, and writing the new version of the file at the end of the string.
A file system like this will eventually fill up the flash chip with lots of deleted file, so a reclaim operation must be done at some point to eliminate the deleted files and compact the file system. Some file systems partition the flash into two halves, and perform the reclaim into the unused half, and then switch over to that half after the reclaim is completed. This allows for the reclaim to run in the background, and also allows for recovering if the reclaim fails.
It would be nice to have code for a flash file system that everybody could use, but I don't think there's an immediate need for this. However, it would be nice to have one even for P1 boards that contain flash.
I could see and advantage to use a FAT scheme: in the case that someone makes an adapter between SPI and USB mass storage (PENDRIVE) or any other kind of mass storage (MMC, Compact Flash, IDE/ATA, SATA, etc ...).
Imagine a USB pendrive with a selectable interface: USB or SPI ( USB <=> Flash <=> SPI ). I think this can be easily done with current commercial usb controllers (if there is anyone that can use serial SPI) by adding just a multiplexer. Or even better, a DUAL PORT mass storage !
FAT would wear out a flash chip spectacularly quickly.
That is the reason that I talked about a BRIDGE between mass storage (eMMC, SD, CF, whatever) and SPI. With this bridge you don't need to worry about wear leveling or ECC correction, they already have a controller integrated.
The BRIDGE between this and SPI can be made with some new microcontrollers with integrated high speed storage (Cortex-M3, AVR, PIC) or even with CPLD/FPGA.
1. Does it make sense to socket the flash device? They will get worn out.
2. Is another type of device possible / practical?
3. What needs to be on chip, if anything? (ROM)
I'm inclined toward keeping the ROM small, meaning simple, really simple FS, if any.
4. How does this relate to on chip development?
It also seems to me, the whole works can be on a formatted flash. How practical is this related to storage? Having a flash device setup to offer development seems a no brainer. It's the product of it I wonder about. Having alternative storage, which can be as simple as, "dump to terminal" would get data out to just about anything.
There is no way to make memory cards as cheaply as SD cards and USB flash bought from Asia, so any new memory card would cost more - and therefore sell only in tiny numbers (if that).
Since it would not sell, there is no point in designing/building them.
For P2, there is sense in making a simple file system for the boot flash, but it makes no sense to make it FAT as that would wear out the flash extremely quickly.
Something like the minix file system, modified for 4k blocks and wear leveling, would work reasonably well.
Using a bridge microcontroller would only add to the costs and increase development time.
For the P2, we should leverage off cheap SD cards, and add a simple file system to the boot flash. Making new bridge devices, programming them etc does not make sense economically. As a hobby project it would be interesting, however BOM costs prohibit using such a bridge design on the vast majority of P2 boards that will be built.
That is the reason that I talked about a BRIDGE between mass storage (eMMC, SD, CF, whatever) and SPI. With this bridge you don't need to worry about wear leveling or ECC correction, they already have a controller integrated.
The BRIDGE between this and SPI can be made with some new microcontrollers with integrated high speed storage (Cortex-M3, AVR, PIC) or even with CPLD/FPGA.
1: yes, or at least .05" spacing SOIC8 (fairly easy to replace)
2: NAND flash, but more expensive, needs more pins
3: first X KB on flash is like /boot, fixed area at the front, then loads rest from simple file system, yep keep ROM KISS
4: makes it easier, as long as FS has enough features (need directories, do not really need various time stamps)
The chips can be queried as to capacity.
Biggest item to keep in mind is 4K is the minimum erase grain.
Keep wear leveling in mind.
In the past I had 'fsck' reclaim deleted 4k sectors.
KISS principle. Needs only MINIMUM required functionality, does not need to clone FAT / extfs / existing FS.
1. Does it make sense to socket the flash device? They will get worn out.
2. Is another type of device possible / practical?
3. What needs to be on chip, if anything? (ROM)
I'm inclined toward keeping the ROM small, meaning simple, really simple FS, if any.
4. How does this relate to on chip development?
It also seems to me, the whole works can be on a formatted flash. How practical is this related to storage? Having a flash device setup to offer development seems a no brainer. It's the product of it I wonder about. Having alternative storage, which can be as simple as, "dump to terminal" would get data out to just about anything.
Comments
I was going to suggest that, now that we have hubexec, perhaps these can be moved to the monitor. But as ctwardell suggests these may be for use by the monitor, implying that it's a ROM space saving measure.
Not all interpreters. Only for languages that define "symbol" the same way CHKSYM does.
Today I got the following new instructions implemented:
TOPONE D 'Get top-most '1' bit position in D
TOPZER D 'Get top-most '0' bit position in D
BOTONE D 'Get bottom-most '1' bit position in D
BOTZER D 'Get bottom-most '0' bit position in D
These return D=0..31 and C=0 if a bit was located, or D=0 and C=1 if no target bit existed.
I wanted to get these in before the next release.
I think, at this point, we've got a really rich set of bit, logic, and math ops.
The branching and addressing instructions seem pretty complete, as well, to me. In updating the ROM Monitor, I was able to simplify the heck out the string/table handling because of instructions like LOCPTRA. I don't think it could be any simpler.
We just need to get some USB-helpers and the SERDES done after this next release.
Did the ROM get smaller, or did you pack more into the ROM area ?
The ROM still ends at $DFF, but the ROM Monitor is slightly enhanced. There are several longs free now.
You go, Chip! Text is king! Follow your instinct. No precedent is necessary; blaze a trail. And position that P2 to meet a variety of needs (yes, some of them narrow but cool/useful), making the chip something to be proud of (for all of us in many way). It's a delicate balance you're composing, and it sounds like it's going to be just what the doctor ordered (unless the world needs another "me-too" ARM chip).
Watching those UNIX videos that Heater posted reaffirmed to me the significance and beauty of 7-bit ASCII. Some concepts are timeless and may matter forever.
It was providence in the Western world that we had alphabets that could be encoded, along with numerals, in only 6 or 7 (with lowercase) bits. The Chinese would have needed to wait for 16 bit systems to store their characters, plus large memories to hold their bitmaps. That was no place to be bootstrapping from.
My mini (yes I owned one) took the length of my garage (a/c etc of course) and had the maximum core memory of 110Kx6b and 3x 10MB H/Disks. we have come a little way since then
Did you acquire that setup 'used'? That would have been more expensive than a house.
Seeing that made me happy.
Actually, I'm also reminded of computers where some handy, basic things are built in, usually the ROM, Here, we've packed good ones into instructions.
RWWygWm#HHqWxVW@gW##WgNmF"]"W"--g"_==A==_$_=*-*^T_?{*|*{m$&*&_mm&&*G&&*****4*&*1$=e"="_=$$W----"C&T"TjWXWXW@GMNX#WQ@mWE@am tWeW#A+QWD=$HDV#@RQ@WEpm&@XE@S!)7""-@4=-~7==_(6=@J"#^>`'>"*`f"G$VgW#I=/b/3 i-")*)%C>:C<~>-"/-#!EU="@%sI(!XOQ@"WpT@+@W%W#m# $@Zs4s#yGFW##V+A#j@WqXWR*|fPC\</9mS)"?]>-&__~f==` ` , i_ `;)*_` ,(!:>-:_i\=-d)_+"(ZJ"rEb*I($-1g""=%"WJ4W$@@UHSQ#@## XxM-%u#B5mm@@WbP+j+MbWWE@W"B"~=P7i:)="'"J_|.__j_a@pg]Vjgp>ih_i_ _Ag__@wWgj+gi';i`%~`V"+"v[-=%-r(_(@"EJ$9Om&WQV==B$@TjWyTHb m*@gM#Ei$*IDp#WAF@gA[H@(*+-C-"%=-N9s"z"6j#qQW##qq##Q#AQ###RHHRmg$pm##qQp#$M###jm *^c'j:=="$]4i"N*"Y=--sm=VT#W"D@>aV"K&|WmB m/T@MXA*@W">@>x@gXmH$$E9<"VD`*$v$!;!-V*qW##W##W########R######H#WA##M####Q#WMMMQp%/(%_sB"(xa@j*J_@j=L!_|P<A*Amp$$#j@Gy#W@I JkM&@TA*wLAm-WyT$gW@bjWDe_--`jJv/ ^"gp#######R##################W#######H######HW##r`/ Wj@@@xgXyN9@m@_Spap4j@XWaEgmq@E@vNx A"WXW@=)SeiIvDjW@sM4"KNgL_7@S-_j;(_q#W#####W#########H########################O#####m_`*RV$gH##AQg#H#p##WNqTWGQq#qAApNgHQ@ W=WNVF=aA@aFWsNcf5XWp@#e@je$4"+($xq###########q##############################W#QM#mQ#WQ_|M#A@WQM@@#BWWqAH###Q#D#q##MWH#N## jh+#jA@6@Cg$@F=W=Vx=Vk*=*-y""s.mq######W##H######################################Wy####A@QQ@#H#@jRpHVw##HMWWHMR###WW###WWq MMF*V7!XxXg$SD@4(Va&p@$s""-&-`##########W##Q#######################H#############BMQANW#A@GR@@mmMdQHQA#@HqR###RM##A##QW### QEA@"OLs"5F@|-+W"=4W@P_ujJ*"_##########HqH#HW###############################W#B##HMH@%$H#@QM&g8WMQQDEHHW######H#N#####q### gGG|j"GW)@>G&<j_#W"HvQ%c?a=<M#############WOmM#E##W####################H#####Wp####KmmNNpQGByQA##QQW@gJMWQH#M##WHW#H#####H PT"QXG@+"<V"W~o*_G@V#jy[!=qg#############@Ep@#@#N#########H##########Q########A#M#FVVNM#QxV2gWMNmRXAEHWB#H#WBH#####WH#W### @_+JW=]x}SP"(EWX-"vLbWL?y_####################AX#Q#####W###########HW###H###NQ@@ZNm}W#####@wZ@$WN##QM@#M#W#######Q####W#A# $&V"!k4J$%toJE7"@ATJ$QOE!qW#############B@E#Q#NWd##WH#WWW##H###q###QW###H##H@NQ@$#NH#W######jk#NGNmW#X#NR##HBHA#W##WW#M### -"'R=!_VP*y=c#p@4Kx9-"T?d###############H#H###MWeWMB@#XWWBH##HqW##W##H##$WNT*_]Hg@#########&@m##gPMG#AHERW#########H##H##Q jj'f!@vP{_~"F|sEr-sO$mJ*a########Q######HA#q#W#MVO#nWWWWM#dWQQM#%R%MWN*6|eV>_H@###W#########RTMm#X#NTZWMM##HN#W#####WWWM#H L"wE*5$_e-`["|@)[>sW"Wj2########M########WW##W#WpE#pR#MMvjIm@>+0BMFH@"D#@E$%qM####Q##QWW!###Q&#MWKQ##mq#M#Q#qM#Q##R#QQ#### +-\>`wt|f?@";"@T*Fj$&%@_#######BH#H#H##Q###MQ@W#HHQ#########QpT@W@-mIgM#@#MW##W#####B*`` JW#QH#W#$#mZ#V#W##Q##T####Q###A#M @"j)-$V;=!<uA@r#Wfx4"@|m#####W#AH#WQ#Q####QEQQq#AW#H#q#WQQ#H####A@QqW##Q#RW####H#E" ` -FW#Wp#Q#kRHRN@pW##W#M###WQMWMRQ#M @]-Vfi="j-'_r@E5m$"}W$-E#######W#####W###Q#Hq#E###W###Q##Q##M#####QM##H####WHW=>`` ` ` `#W#R#Q##HBVqEHAQ########QHq#qKQ# j-,*-m)`\~$_ji@9"C*fkO!W##############q##WMN##D###QHWW##W##R#A##W##QWg#HE$V>` ` ``,`XWWHq@#mPWWjV2##WRqW#PMHQ######M 7-"~-_=`b=`~(@$$W"(Fnb*"#########Q######M#vDOX=MFNM$WWHVVBJPWX*FF*"F"'`` `` di'####NVTHqQNmXQAQ##BW#BW##@A#### '<*jS-``%!'_(***i$_Ww^$`#######W#########SMWA$eF=L"`'7'-_- ` ` ``@s WQ#BF`=##AHdWKq###QG###AB#NB#M# `!``>3S'j<`_-O@i$={p-i"(######WHqW#####RmD"W=aU-~*"`~~`>;*` ``,-"mD ^##GT- V#NQqP$M#MB#K#QA@O##E##Q ^*~~wj^"i*" $=j*aO@@egB*Z#############B#BGHW#=if&!>w`- ` aG#QRP" ` @#N&` @8##@@VH##EqQsXqA####N## `$j-W; o``i,-j#=C@^&\"-`O#######M#####HVXKm##$u@|>!j`- `; ` fW@@M=JN*`-j V##B` _qHHNmO#M#M@m#gWAQBBK#HW ! -? `<(! *'">G$5_>{)) q########H######IW$VA@MVmCj;~') _ _ ; ` `mpWW|"?:ko"_'` MD# `G%T@9mQ#M#AQ##W#DMHg#W# `!"*",!```=72J?==y<!'{W H#######W#######Z#W#@M@g$#qp=qj$p@p@J,,,_` ~ ` ``=$pMR@qhL__a4s`-` N#$ MWGN@m@#MMQ@AEq#@#WHQM# !'b--'$,* [j`$!weX"_e(`a############Q#Mm@@4NqVG@T?Y@#####W###q&e__Fs`` `;=@V@@HR###QMWp__ `*#b @Wq@%WhQ#WgWW@GRGHWK##@Q -!z+ o`` -"s<--agW"<;gfm#H#######W#W#W]iT@@T@T@*Xjy)"""WWDM#Q##MQKmL` ``4! WMH#W'Df/ ``RT @TWMA@WT#WWR###QWV###MB@ 9* $'=:`*``(8-5_"""i$"WXNW###########qN74WOWa#W@Jm"L/WgjjA##HW#MaT4s' ` `-"` "V%'"= ^` ` =Rjy##AH#T@@MNWQQWW@##W##q#@ _wr"`(j8\!w`aOj-VW"J@G"MmH#########W#g69/@bDDTm{$@+xup#A#$'*VXyXWX=V= ` ` ` 7 ` ` `` %Ea##p@VWx#W#HDm#q@#WGX#K#Q !(~*5`:^`=,_isD6NsBv=v>AU@M#W#AQ###Q#WA$M_W"W@%#N&#WTVaRW` -'-@=V*"` ``` ` ` ~` ` `` ` *Eg#BN@VW@#WW#NGNW&W#WgQQQW !>_` 7)`-"!`%"N>e7*|;A>e@BNM###QW###WBPWF-EixI@V8#W@yjm*~;" ```ZWFRA` ` ```` ` @HH#BN#NQ$H###@m#Qm%A#RN#K `**_*_w`-;--P_@*j=-j--)"m$GD]M#######mWO$#MWR>WGN:,m"-i"` ` ````$X@W`` ` ` ` `- Z#WNHm*DaGHAWHGRq##8#p#U#A ``){`~w-``'"s-_ca|(T^|` #WQD0Dm#M####my=/WX7O-*?(J=`!~=`` ` ` _s"|F_` ` ` |#UN@HUqNRM#W#@MH#ImGWmN## -(;^[<j' "()5rv?W@F_&-`*&VXX$p]KW##H@@Vms"EW*!``!`~' ` ` ` -*-V@_`` ` ` `` qeNH#EW5Ng##RA#HWHND#AQ#qH %! '|_``T --L--+*aeV$;-``*#N##@w@m#BQW>@GE>+2`),` ```` ``` `y@W*s*" ` ``NA#HAxWQj####BQ###WWmG@### !`i ` `%<_">I<I=x"sW(j!` j6ZEMqM8$HB#EJW@AA>&$I, ` ~ ` `` *F|WI("" ``` `` ` `ENW&@3M$@R@#B##WmHM@#HW### ' =!"!n~!_i"7->FWl">(-*=` mmEA@@Hp@##ADsM@VgW,",'``` ` *5=g#=$ ` ` - `YNA#9gWgWN##q#B#@WM##EW@#HW ``i,"!:=- i(a_o+jV]X$`,` ~^TGWmQ#WWxqEWX=@WW"=s~ `_ ` ` Gg"@[P$- ``` ``~~`V@@8@@@mXMQ##qd###MM#AyHRW '`"W`^Y -":=*$-$s("B,"` ` "B#N#MY9"PH#W$=%mV%Lj ` ; ` ```` 2=m_-J@F-` ` ` ``` ````, wa#W#@@#NEW#W#M#Nmm#gG9K#ET _"i'`ri"~ ~;_j!)l~_"=TP `<`cW$#NBB4#yW#$@3yOV@@3@'`` , ` ,vaWv+"W$}@ ` `___` ,_`*_A#A@#QmZp##Q#WWE#pQ#MMWmH@ !"!=i^Y` -yjD$");-B4?` ` qD###Mp0mR@EH#@@v@eeD=JC`` `` ` _VXH]W@qR#@vo_-__MB$ ` ``~```>``.-GAWVWTW9@@QM#A#E@WRHH#@TWW *" '"==W`,`ch?$D*Vj4^ji * -AM#####N#W#@MQNX]q@NX4_@~! ! ,'jMEExhW##NMpm;%- ;F `` ` ==-j@##XkN@m##M##HH#DgQqWQNQ# -`s,="=`~" V_T=;-U-7F=! ``(`)QeH#H#pmW#Ws%WX@W$U!$&-$+"_<`2<FPp#&W@@=H&DI" ` ````- ` !`"7@m#qqHB]###Q#Q#Wq#@#q@BHW# -"Y`=W===,`!.|_^"]-s7``` ````4WHq@#gHpVxDm=AiH2++"""mFA-````4$O$TN%IX#*%'` `` ` , ,`=([#NKWHpm#H#Q#Mgq#@#M#BWWM#q `=``oVw,;^`Fe*G`s_'T;" ` `wWW###%#R@MmAEU*$f+"_9jJV@];) `(WW@kW"^`*` -` ` ` ` ` ``^`_mWAM#RM###R@###HqNW#BHqyRW )`,,``"^`,'`@\j"yW=3"-'`~` - ~Hgpg&WH9QIWg+#WxW|,7__SW`= %``'l` `` ` `` `-` `` ```- W=3VA@VWWy4BDH@WH#g#M&MH#EME# *'"i`e`==i\=Q>A-%(i-|^` `, ~`-""H@mP&H4qWTM#VZX@_;*JVW-_e%_- i',;`-``` ``` `` ` `` `,`( j`EggWEWQQmB#M@D#BRM##H#EW@#A =|<`="j<Y^(5_3P v|%**^```` ~` ` )HWTC,"WDkwmMaR@%@]Q|dG_---|,j ,-; , ~` `` `` ` `` ` ~ ``,wWgAB@#MmQQ#W#GGWWgAW#H##@QW `:>;`"i:"!`/<P?j=<C7=`,,` , `-`,````!` WVA#R@@j<Bjg"W@"l!*J="4"_ _``` ` ` ` ``-!`_`(@$mEUM@nSm#d#Aq#AQq#B##X### !`-`*' `-Y -;v_Vv$9p*:( , ~ ,`````wWHVDaGVx6DEW@mVQ_`he"I?-=*, ___[/p.wi|jus*s,,` _ -`*`3@VP@gR@mWmHWHHmdW@M@#HWgqH# ! ! `^*! =>jMJ@(--+:& ` , ` ~```- ;` ``DaRSjWXXB#F1VS@F+=7_/as_L_a]xkJW*#w='")*""C`7`` ` * !@@V#N#B@#KAWWHmA@MW##NMqAWEW ! s`"~_' (`<@==O`LJ*="'```` ' `` `` !ZyMm+mWWDI=k@pLc"i("\dp@W$(="<? ` ` ``` ` %`-,- xHWHT@mm#@HAHWH#M##WW#MEHNdQW j =*"` ='=("4V%>g<sW=C` `` `` `` ` (apmkEm#P@a=bR@)=s<``iJ"$I,^" `__- _j,_ ` ' `` (j-%JNG=@@WTAW###MDQ#MWW#HMMMT@WM = "%"` ```j4J=*7$-I+%,``` ` `-`` ` - ~TaNggWxaW#kj@yGC"=^*";\/IFaWj>-+mmaBW$&=` ,` (`-r_O##mg$M#M@%GWQNHMHRyW#qHWH#### `-_`"_,`?``!jR=[",*9)-`-`;```~ -``'` ` ```aNWWW#@WW%@7Ky4mV. `:,W"=FA$=W+A7*@@-A$=-*=``` ?o@@@WAmT#HQTyI$##M@QHp#B@NXBR#RB `_ '"_ ` ` (-Iw=-rJ=">_=('- ` `` ``` ` jKXT##md-WWyTmXK"*`== j(r"s"_>!`)="`^j`;`!") ~``-@7NM9jHWB@ZpWQ##NW@BN#g8GW#p#AW `-*"!_!"`=(^v=l_"(w;** ^` `~`````^` ` 4WAIjW@s%pVjT@WgD=~'(*=A~(`!``,` `` `` ` ` ``=_Xmm#AH##e@aj##M##HB8WHAm#dBWWW _- -' '"` *_e="*<`=^`^'` ` ,~ ,` ``XjMj#WMWAXja9V#@s~Y`w `=`*`, ` ` ```` `,3j"HFNSQ##A%M]Hm%#Wq@UMqHHqQMQW#m _` _'/ " `-(!@t@<4"@%:` , ```_ ` ` ~ `` - WWqAxMyM#HA@fWBSe__;` ,` , ` ` ` ~``(L_'*X@$W#AqWA#$##WMWpPWWmE@Z#8Z@q# !_%-^;"`` "-j=("!$-s=`, ~,;` ``' ` ! =`6HI@mppKOaGS@QWTt*g_*"_`-,`` ; `` -`,'`` ~ %QHKX#KWHWwH@#N#Wf#X@mRWqmH#%W (`>`),"``=j'"x*"BWifWr'` ,`^, ` ` `` ``_|@5@fWZ@#HM#%GmI#ms-!4c `A ?_-:``` ` !>--`L``c``?d#WGHHMBWX+@BWWEQ#g#4DN###Q##W U_',|"^"`"'c!rA-*-j"]:`` ! `'```` `,`-__qpp4aMmHg#RhRA&MMA#WqQWQ-A\3c> @a`c-j$""^j:%- ` ~``H#HQg($NesMHpW#mBWH##NH#W#NQM = "'*-:`%`_--_-C#$-@-^_ ` ' `~ ` ````_qp###$vX#DHV3=#H#MBGq@#@gVUXjG{-%s|+J|!VE_WW$@A" ` ~` SW####gp"j7@QD##W#@WGWq###Wq# ,!`,~`i` P_Cae]W`s5K#=_`` ``` ` ` ~ qq#####m-%f@]WBKHmmA##H%WHGAq@WBWHX@@W@#qM#w@T/` ` -V#######A_;!FMQH@M#MH#Hm@WHM# -f`$""o `s='+=jc"O3a7'- `,`(` ```*q#######5=$I]gQs#N@=@W@ymMaA#BMqp##g##H#A#D ` o ~=,^ _`_q####p###@_-O9*A#TM#kW#A#q### -`& ,^"*);j=y`V"mW~a3;*````' `',*[-########MWa@%@-0ee@E#Wy@#@@T@UH#####W###Q" `'`` '`` ~, m##Q#H#####By >;>SgWsN#QH#@###W )!-`"='`''-3-d=-@@j!=_`~',-`!,aIWp@########p@#1gDbMDNWMgpTMW@amWV$#WH##W##B\ `)` !`` , (@#W#######H#AQ,:Tm=$!W[Y_6HG#W#Q j~=""*!-)Cs,+=@|W({vj$"-_i&gu~-@$TH#########p@*@#P#A#@QQ#HBAk@NN#m@W###AH"''`~` ``)( * _q###########HWEDVJ|@jDC@'#*S@wqW#@ )jJC<_";=,((@GF|$$W"FsA*<jD@[W@@Qt###########pQM$MpqNgQWTW01%@@@QMWR#GMj"_ `=, ,`)(`!g############W#QH\jz|j"2$7|m4"ms$=>WA =!?-<_^-si=fF"|Dj_k$@IjkWWWWQa$kym###############g@jdp#WN#Nmp@WRWWAW""J`_-* `` `_'Imq##############HrWcV"_v_@$WgN=GIg)[R@] _;"!w*oi`vsvj"D&V*G$Xa=$#F$VaW@KA#R################QWqm@QNBZ#H#V@Vj-V`_-~[`"= _jqgq#########H##H#B8"|_cF@g"_QTN{W<eUW$CF-E "T($,'=-^ts"_@=@-W$p=As@SQoWa@W#B@M###################AqAT#W#T#q@"-=''~[>',$q#M#############q##WWC_*ArJ!*#j@G$SD3W@N#EFrS# el*("}^jtf+J~%xW=WA=#y#WqHq#Sq#NHpH#g#####################gq###T1@@j>"$=_m@g#H############H#Q#W5-x(W;_YWF%@*rWWJQEjWX@Ki$- W*_}cU!WZg@~jw_;:^==A_"kW#BWm#####WRW#R######################H###q#pgpq################A####W%\_!I=c|-kTWsQT"-_%t=sWV]NQA# o-);B{_g-(==W&=+PWB_j@G38WEWAWMMWAM#Q####WH###################Q#####################H##A###Bk-:saa`a""='E-@y_!4TW===VMYMAm @"cd-2yVI"i@-=J9,ei*%@P"W$EFJHTU##@#U###@A#W#######W#################W##################HWC_"=I=-p,"|_>F-*"@(Wg(WF=sNW"+e# jJ=x@"|@aaWiZ@$Vv9r*HTDi*"K=$%VXID@NH#W#%@#GBNVW###########W#######################H#W#@*>`%'\`Wym=SL_X@r\@Ts!A##gW)"6KAVM #W_J@($%"pPeRbO@@+@eTFT&>*W[|j5j=$"[NwVZ%Q@@h@&@a####H###Q###########################I was writing commercial software for customers as well as developing hardware interfaces to it, so it saved me having to get time on someone else's mini at unreasonable hours. BTW I kept it running until 2000 when I sold it for scrap (gold).
Actually the first ones I saw were on teletype machines as used by telecoms to enter telegrams. Oooh - is my age showing
That must have been pretty neat. You're used to having fun.
You would not believe the similarities between the System Ten and the P1... Dual operand instructions, JMPRET style instruction, all instructions memory to memory, equivalent hub and cog memory, up to 20 cores (but hardware time sliced).
I have a question for you all:
In contemplating that each Prop2 will connect to an 8-pin SPI flash chip that it can boot from, and that these chips provide 8MB for under $1, or 16MB for less than $2, we effectively have a local solid-state drive that holds 32x or 64x the RAM of the Prop2. This amount of memory warrants a FAT scheme, so that actual files, aside from just boot data, can be realized. Is there any reason to stick with some standard FAT system for an application like this, where the media is not removable? Couldn't we make up our own FAT scheme and then have simple utilities to shuttle files between the Prop2 and larger systems?
I'm just realizing that this issue ought to be addressed so that we'll have a common basis for file storage in that 8-pin Flash chip.
If we do this right, we should have a significant basis for UNIX-like operability - in the original sense of the concept.
That possibility can we test on new update.
However flash fs's have to be somewhat different than FAT for two reasons:
1) minimum erase grain is 4K, so "clusters" should be 4K in size
2) it is possible to write '0' bits to '1' bits in existing sectors
Possibly a modified version of the minix file system would be good.
p.s.
I have written a NOR-flash-optimized Unix like filesystem for my projects, however I cannot open source it as wifey would kill me if I gave away man-months of work.
A file system like this will eventually fill up the flash chip with lots of deleted files, so a reclaim operation must be done at some point to eliminate the deleted files and compact the file system. Some file systems partition the flash into two halves, and perform the reclaim into the unused half, and then switch over to that half after the reclaim is completed. This allows for the reclaim to run in the background, and also allows for recovering if the reclaim fails.
It would be nice to have code for a flash file system that everybody could use, but I don't think there's an immediate need for this. However, it would be nice to have one even for P1 boards that contain flash.
I could see and advantage to use a FAT scheme: in the case that someone makes an adapter between SPI and USB mass storage (PENDRIVE) or any other kind of mass storage (MMC, Compact Flash, IDE/ATA, SATA, etc ...).
Imagine a USB pendrive with a selectable interface: USB or SPI ( USB <=> Flash <=> SPI ). I think this can be easily done with current commercial usb controllers (if there is anyone that can use serial SPI) by adding just a multiplexer. Or even better, a DUAL PORT mass storage !
FAT would wear out a flash chip spectacularly quickly.
I went through this exercise years ago, and wrote my own flash fs (with wear leveling, etc).
Here are some links on flash file systems:
http://en.wikipedia.org/wiki/Flash_file_system
http://en.wikipedia.org/wiki/F2FS
http://www.linux.org/threads/flash-friendly-file-system-f2fs.4477/
http://www.yaffs.net/
http://www.ibm.com/developerworks/library/l-flash-filesystems/
http://www.spansion.com/Support/Pages/DriversSoftware.aspx
Yes, there is no interest in giving cheap, mass storage, high speed and easy to implement protocol to the masses.
So you are right, actually is not as easy as using just a multiplexer.
This reminds me a thread I started about how to get a huge storage, with high speed and free: http://forums.parallax.com/showthread.php/151150-Add-on-card-for-IDE-Drive-to-P2-DE0-nano.-Any-interest
That is the reason that I talked about a BRIDGE between mass storage (eMMC, SD, CF, whatever) and SPI. With this bridge you don't need to worry about wear leveling or ECC correction, they already have a controller integrated.
The BRIDGE between this and SPI can be made with some new microcontrollers with integrated high speed storage (Cortex-M3, AVR, PIC) or even with CPLD/FPGA.
[1] http://www.linkedin.com/groups/SPI-mode-in-eMMC-Devices-37565.S.77338175
[2] http://www.toshiba-components.com/memory/emmc.html
[3] http://www.latticesemi.com/~/media/Documents/ReferenceDesigns/SZ/SPIFlashControllerwithWearLeveling.PDF
1. Does it make sense to socket the flash device? They will get worn out.
2. Is another type of device possible / practical?
3. What needs to be on chip, if anything? (ROM)
I'm inclined toward keeping the ROM small, meaning simple, really simple FS, if any.
4. How does this relate to on chip development?
It also seems to me, the whole works can be on a formatted flash. How practical is this related to storage? Having a flash device setup to offer development seems a no brainer. It's the product of it I wonder about. Having alternative storage, which can be as simple as, "dump to terminal" would get data out to just about anything.
Since it would not sell, there is no point in designing/building them.
For P2, there is sense in making a simple file system for the boot flash, but it makes no sense to make it FAT as that would wear out the flash extremely quickly.
Something like the minix file system, modified for 4k blocks and wear leveling, would work reasonably well.
Using a bridge microcontroller would only add to the costs and increase development time.
For the P2, we should leverage off cheap SD cards, and add a simple file system to the boot flash. Making new bridge devices, programming them etc does not make sense economically. As a hobby project it would be interesting, however BOM costs prohibit using such a bridge design on the vast majority of P2 boards that will be built.
2: NAND flash, but more expensive, needs more pins
3: first X KB on flash is like /boot, fixed area at the front, then loads rest from simple file system, yep keep ROM KISS
4: makes it easier, as long as FS has enough features (need directories, do not really need various time stamps)
The chips can be queried as to capacity.
Biggest item to keep in mind is 4K is the minimum erase grain.
Keep wear leveling in mind.
In the past I had 'fsck' reclaim deleted 4k sectors.
KISS principle. Needs only MINIMUM required functionality, does not need to clone FAT / extfs / existing FS.
I don't think any of this should be in the P2 ROM.
Too many things pulling Chip in too many ways and being in the ROM puts it on the critical path.
IMHO the file system should be part of the code initially loaded from the FLASH chip using the P2 current boot mechanism.
C.W.
The rom should know enough to pull a second stage boot loader from flash. That's all. (that was the like /boot reference in my reply above)
That way we can have different second stage boot loaders for SD cards, flash fs, rotating magnetic drum memory, paper tape, punched cards, etc.