So, how close is a Propeller Demo Board
cbmeeks
Posts: 634
to a single-board computer? lol
Seriously, would this work:
1 cog for video
1 cog for audio
1 cog for keyboard/mouse
1 cog for OS (C=64 style)
1 cog for storage device (via breadboard)
cbmeeks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Metroid Classic:
http://metroidclassic.com
Metroid Forums:
http://eblarg.com/bbs/mc
=========
DMCA Sucks
RIAA Sucks
Seriously, would this work:
1 cog for video
1 cog for audio
1 cog for keyboard/mouse
1 cog for OS (C=64 style)
1 cog for storage device (via breadboard)
cbmeeks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Metroid Classic:
http://metroidclassic.com
Metroid Forums:
http://eblarg.com/bbs/mc
=========
DMCA Sucks
RIAA Sucks
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
Some regions of the world are struggling because of their linguistic heritage not being very adaptible to computer encoding. Sanscrit, Arabic, Chinese, non-written languages.
I really miss good ol' Wordstar as ASCII is compact [noparse][[/noparse]compared to Unicode] and doesn't have to fuss with GUI. It was highly ergonomic in the editing mode and I suspect the code was quite compact too. For much of the world, the alphanumeric languages, it can provide nearly all that is needed to comprehending computing. Of course, character based languages and more esoteric scripts are left to catch up or learn Western languages and keyboards.
So, I suspect much hangs on the question of revisiting an exended 256 byte ASCII and a Wordstar-like program for documents or supporting fully modern UNICODE with world languages and mulitple keyboards. Spreadsheets, databases, and IDEs can simply follow whatever.
The obvious solution is to just repete the evoloutionary steps of the early days of personal computing, but set aside all the deadends and distractions.
It would make the Propeller a superior teaching machine for younger learners as it would be able to re-visit all the problems of file management, sorting and searching, and so much more. I recall the early Dr. Dobbs Journal [noparse][[/noparse]and Ortidontia], while it really was covering this material there were many, many blind alleys that were presented by very compelling writers.
Chip's Propeller will do wonderfully to blend the useful and need-to-know principles from the earlier days with the innovative, creative use of less silicon and newer tools to show that there are many ways to achieve the same thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
to the board, assuming the cost of the socket is sufficiently low. Having that much nonvolatile mass-storage on the demo
board can enhance its use as a prototyping system significantly!
The other post piqued my interest in small persistant storage devices which is a requirement for a stamp based controller that I am working on. the same website has a SD Card Breakout Borad and a link to a SANDISK document that describes the porotcol used to access SD memory Devices.
Additionally, there is an IBUTTON device (1 wire) that provides 64kbits of ram in a button size package.
pnp
p.s. my Propstick is on backorder. I have no idea when i will get it. Parallax ought to note this fact on their website.
The problem is all the support overhead of a FAT [noparse][[/noparse]File Allocation Table] and the fact that Mr. Bill Gates seems to claim part of this to be owned by him [noparse][[/noparse]longer file names]. Apparently the '8 character - dot - 3 character' format is in the public domain as it was used by at least CPM [noparse][[/noparse]another disk operating system], other companies, and maybe even the early Apple II's.
uALFAT has provided a great little 3.3volt board that handles all this and can interface via an RS-232 format, an SPI format, or an I2C format. In some ways it is like the hard disk requiring a 'hard disk controller'. These can even be combined to have two in an IDE Master/Slave relationship.
Having the controller outboard is a bit less compact, but it does free the Propeller to be dedicated to more important real time tasks. Having a real time clock that is outboard is another appealing add-on that just disapates the Propeller's resources.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
You DON"T NEED a PC complient file system (FAT, NTFS or other!). In fact, all you really need is access to the raw sectors/ bytes. From there, a simple command set, and simplified sector map and you have mass storage. For up/downloading, it would just have to be part of the PROGRAM using a serial connection and a simple program on the Host. Heck, even the USB2SER works well. The host pc can deal with the FAT and it's overhead. THis is quite simple and very "dooable". In fact, I already started working on the FS commands (I'm calling it PFS Propeller File System), and it will reconize HUGE drives. Again, just to reiterate; the media used won't be directly readable by any other system (excluding another PFS). With 1" glass drives at 18Gig for less then $180 on a USB jack,things like this is where things are heading. It's just a matter of selecting the media interface (USB, SD, CF, IDE, SATA, ect.) and coding the low level drivers that give raw access. Heck, give it a real short time and it will be here. If not by me (most likely not, I don't get that much dev time), someone else will be there. And, just for the sake of adding it; If you code for the USB interface, that includes over 80% of the SD, CF interfaces as well. I havent even gotten the details on the SATA specs yet, so I don't know if the propeller can handle that interface yet, which is the only reason why I'v included in this list.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
me and am working on the FAT16 interface. Truly, supporting basic FAT16 root directory 8.3 read/write is not hard
at all, not much overhead. I'll probably have something to post by Monday.
What I really do NOT like about the ALFAT is that there is not any true CRC of the data packets, only a simple Checksum. At some point, I suspect that would become an issue. After all, transfers of data might become huge as this evolves.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
I'm new into this sd card stuff but i get the feeling that there really isn't a need for a FAT16 type of driver code. I'm getting the notion that the driver on the OS formats the data to comply with FAt16 structures. So maybe this concern about the size of code and the RTU fees are a mute point.
of course i just may be having a Blonde moment
pnp
possible way to do this (if you ignore long file names and subdirectories). It's not *the* simplest, but consider even for the single-file-only case
you still need to store the length of the file somewhere. Note that we still rely on a different OS to initially format the card for us; we don't
need to write a fully legal FAT16 volume header and the like, we only need comply with what's already there.
Look at the code I have on Monday and I'll let you judge if it's overly long or complex for what you need.
There's a *lot* of utility to be had by using a standard file system.
rokicki, your dead right on the requirements for needing a FAT system. And with a simple FAT that doens't deal with sub directories and long filenames, it will take care of 99% of every ones needs. Me, I'm still waiting on $$$ for some stuff, and more dev time for what I was calling the PFS. Right now, I have no low level drivers in place, just the upper level FR (File Read), FW (File write), FI (File Info), FD (File Delete) and a FP (File Pack) commands in pesdo code. Again, this is all outside of any PC file system, and is intended to be a object with no asm code, and to export or inport data from the propeller (up or download), a serial connection to a pc and a program on the pc is needed. IF you have a FAT16, will, that really superseeds what I'm working on. I'm very interested in seeing it. Even with a max of 512 entries in the rood directory (as imposed by all the FAT systems), its better then what I was woking on, only because you don't need another program and a serial connection to ul/dl data / files to it.
Yes, I'm very interested in seeing what you have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
There's the one used on the Psion Organiser II datapaks which is interesting as it is made specifically for EPROMs(8/16/32KB or larger, the types that needs to be erased by UV-light)
And then there's the 1-Wire file-structure which is made to deal with even smaller storage-spaces.
What they, and FAT, have in common, though, is that none of them are really suited for small files on LARGE media. And lets face it, most files handled by the Propeller(when used as a general-purpose computer) will be small files.
What we need is a FS that can be scaled from units as small as 8KB(64Kbit iButton), 32/64KB EEPROM/FRAMs up to Multi-megaByte SD-cards.
Defining a decent FS and formulating the IO-functions(Create/Open/Read/Write/Close/Delete file) is the difficult part. As soon as that is done, the low-level functions will tend to fall into place almost by themselves.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Well, the litations of any FS are imposed by the file containing the maping.
Microsoft tried to do the scaling thing starting with FAT32 and with NTFS.
The main issue is, altimatly, how the information about the data on the storage unit is its self stored.
Predefined Size mapings (like microsoft does) could do it.
Editable predefined size mapings would make it even better.
My idea was make a predefined File Alloc File (ie, a file with a fixed format),
and make the FS determin by the length of the file how it's stored. Along the lines of RLE, only with editable prams.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Let's say you have a data logger that fills the SDcard, you swap it with an empty card, and then you want to use Excel to reform and analyse the data which you have gotten.
Further, it would be nice to plug in via my USB read and note that this card was used by my Propeller system (because I would recognize the file name) rather than thinking it was empty because no file was recognized. And, it would be nice to be able to prepare and transfer large blocks of data to the Propeller via the SDcard for use in video, audio, or machine control files.
Historically, the original 8" floppy disks were proprietarily formated and there were dozens of different formats. The computer companies then charged a mere $25 to $50 USD per floppy to the customer. You can do it that way and charge for your card reader software and for the conversion. But, I suspect everyone loves the more generic, universalized approach.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Parallax developed SPIN as an OOP because that is really what allows large systems to be developed in pieces and in parallel by many people. For a start, I suspect we should really be trying to find the Objects that must work together rather than counting Cogs. At some point, an Object may be written in a more compact form that uses one less Cog.
My personal first goal is a full duplex RS-232/RS-485 Monitor and Keyboard to be used with BasicStamps. Since it would be all ASCII, why would I immediately need sprites and such? I doubt that I even need the Mouse.
Another easy and useful application may be an Advertizing Display that runs through a series of attention getting images and then an informative presentation. A mouse might be useful for the viewer to work through menus.
If you really want to make a video game machine, Andre LaMothe is doing that on a huge scale with the Propeller and it will be coming out a few months from now.
If you want a graphic video drafting terminal, I wonder how you are going to encode and save the images. After all, I can easily spend a few days on a technical drawing. But without the means to save my work, I have little interest in beginning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Post Edited (Kramer) : 5/21/2006 7:18:22 AM GMT
you might want to check out www.sddatalogger.com which is manufactured by Bean (of SX fame)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College
I think the simplest FS to implement and use would be a file system which does not support fragmentation. This allows the complete elimination of a FAT. Instead you maintain a file table and use it more like a heap. The data is allocated from the bottom address, and the file table is created from the top address. Each file entry is a fixed width and is organized in the exact order as it appears in the data allocation. IOW the first file entry is at MaxAddress - size(file record). The data for the file is located at address 0·to size(file0), the second file entry is located at MaxAddress - 2*size(file record). And the data for the file is located size(file0+1) to size(file0 + file1).
Each file record would contain the name of the file, the start address, the end address, and status bits (including a delete bit). Every file is continously allocated and in the exact order as dictated by the locaion in the file table. The disk become full when the allocated space exceeds the bottom address of the file table which is determinable during the file allocation process. Whenever a file is deleted, the bit in the file record is marked, and that is all thats done. Whenever it is determined that there is not enough space to allocate for a new file a garbage collection routine is entered, this goes through searching for deleted files, and accordian collapses both the file records and the data portion. Append mode makes things a little complicated, but heres how that is done: if the file exists at the end of the allocated data (ie it is the last file created), it simply updates the file record and expands the file as needed. If the file is not the last file, it copies the existing file into a new file located at the end of the allocated data, creates a new file record at the end of the file records, then proceeds as above. The old file's record has the delete bit marked, to be reclaimed during a garbage collection process.
You would likely want to keep the smallest allocatable unit to be the block size of the device, but you could break it down to the byte level if you really wanted to, it would make some operations such as garbage collection a little more time consuming, but not·impossible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
Post Edited (Paul Baker) : 5/20/2006 6:48:30 PM GMT
If you add a block at the beginning, chich contains a FS-identifier(in case another FS is also created), unit name(label) and block/total -size information, you should have a good one.
Byte-level allocation tends to get 'messy'. I believe that the smallest practical allocation-unit in an EEPROM is 16Bytes(it would be nice if filename and attributes also fit in 16Bytes).
As that is a nibble-size it might be easier to work with.
But 32 or 64Bytes is probably a more realistic size?
The Psion FS is made to access both Applications and Data, stored on a EPROM, which is made so it is very easy to read sequentially, but which may be a bit more difficult to do random access to. (Basically, the address is set using one or more 4024 or 4040 counters and just pulsed to read the next address)
It also deals with deleted records as its EPROMs, not EEPROMs(they introduced FLASH and RAM modules later), and you need an UV-light to erase the chips.
(Psion ran a mail-in erase service back then, in 1986 when they introduced that series)
As the computer only has a hitachi 6303 8bit processor running at .9MHz, a 32KB ROM(which also contains an Agenda, Editor, Translator, OPL-interpreter and a few other utilities), they had a lot of the same constraints as we have.
A curious thing, though, is that when you save a file on the Psion, you can hear it ticking...
(There's a 22V charge-pump step-up generator in there to create the programming-pulse of the EPROM, and its that which ticks)
The FS they used in internal RAM, though...
Yes, they had dynamic allocation of files and running programs on it.
As the first of the series the Organiser II CM only had 8KB, you start to wonder...
Ooops... Rambling...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Stan Dobrowski
Your comments are very close to what I was thinking about, only yours make some better sence then mine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
I can also see the possibility of implementing a directory structure within this methodology. There would be a special directory structure which could actually be comprised of only the directory name, and two pointers: a·pointer to the next "same level" structure which is either a file or another directory, and a pointer to the first "sub level" structure. Doing this can create chains across the flash drive preventing the need for rearrangement to insert a file or directory. Of course there would need to be a special "end of chain" value to be stored in a pointer to indicate it is the last in the chain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
Post Edited (Paul Baker) : 5/23/2006 6:47:13 PM GMT
A double linked list on the first sector of each file, and a double linked list in each sector for pointers to the correct previpus / next sector...
Dooable.. and fast... I've coded many double linked lists... and as far as fragmentation... well, that's still either a seq re-write of all the files to remove it... or a shuffle, which, btw, is real simple in a DLL (Double Linked List)... Hmmm... Yes..... very dooable, fast, accurate... and self "defragmenting" almost...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·