Post by thread:[PIC]: PIC IDE competition schematic

I originally posted this with an [OT] subject by mistake probably meaning that the people who may have what I'm looking for didn't read the message. Further to the original, it seems that Andy doesn't actually have the schematic himself anymore either, so now theres 2 of us who would be extremely grateful. Please forgive the repost, I'll pay more attention next time. Jon Baker spam_OUTjonTakeThisOuThayseed.net > Hi, > > I was working on the PIC IDE design contest run by Andy Kunz > http://www.montanadesign.com/contest.html but since his ISP was vandalised > he no longer has the schematic on the site. He said that thousands of people > downloaded it so I wondered if somebody on the piclist had a copy of it > lying around that they could either mail to me or put on a web site so I can > download it. Thanks for your help. > > Jon Baker -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

simple! Just follow this link for the schematic. His website has 5 archived copies on line and available. http://web.archive.org/web/20010826220431/montanadesign.com/contest/ideschem.gif Follow this link to download all of the last five versions of his website. http://web.archive.org/web/*/http://www.montanadesign.com/contest.html Jon Baker wrote: {Quote hidden}> > I originally posted this with an [OT] subject by mistake probably meaning that the people who may have what I'm looking for didn't read the message. > Further to the original, it seems that Andy doesn't actually have the schematic himself anymore either, so now theres 2 of us who would be extremely grateful. > > Please forgive the repost, I'll pay more attention next time. > > Jon Baker > .....jonKILLspam@spam@hayseed.net > > > Hi, > > > > I was working on the PIC IDE design contest run by Andy Kunz > > http://www.montanadesign.com/contest.html but since his ISP was vandalised > > he no longer has the schematic on the site. He said that thousands of > people > > downloaded it so I wondered if somebody on the piclist had a copy of it > > lying around that they could either mail to me or put on a web site so I > can > > download it. Thanks for your help. > > > > Jon Baker > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

This has been 1 year now, no winners yet? Is there any entrants? I really want to see some do this in 8K of code and NOT done in assembler! Seems a bit out there..... But I am ready to be proven wrong. Richard. >> simple! Just follow this link for the schematic. His website has 5 >> archived copies on line and available. >> web.archive.org/web/20010826220431/montanadesign.com/contest/idesch >> em.gif >> Follow this link to download all of the last five versions of his >> website. >> http://web.archive.org/web/*/http://www.montanadesign.com/contest.h >> tml >> Jon Baker wrote: >> > >> > I originally posted this with an [OT] subject by mistake probably >> meaning that the people who may have what I'm looking for didn't read the >> message. >> > Further to the original, it seems that Andy doesn't actually have the >> schematic himself anymore either, so now theres 2 of us who would be >> extremely grateful. >> > >> > Please forgive the repost, I'll pay more attention next time. >> > >> > Jon Baker >> > jonKILLspamhayseed.net >> > >> > > Hi, >> > > >> > > I was working on the PIC IDE design contest run by Andy Kunz >> > > http://www.montanadesign.com/contest.html but since his ISP was >> vandalised >> > > he no longer has the schematic on the site. He said that thousands of >> > people >> > > downloaded it so I wondered if somebody on the piclist had a copy of >> it >> > > lying around that they could either mail to me or put on a web site so >> I >> > can >> > > download it. Thanks for your help. >> > > >> > > Jon Baker >> > >> > -- >> > http://www.piclist.com hint: The list server can filter out subtopics >> > (like ads or off topics) for you. See http://www.piclist.com/#topics >> -- >> http://www.piclist.com hint: The list server can filter out subtopics >> (like ads or off topics) for you. See http://www.piclist.com/#topics __________________________________________________________ The Mind Factory INC Richard Sloan (613) 825-4758 phone (613) 825-7758 fax .....rsloanKILLspam.....themindfactory.com * Custom MP3 Development * Custom Smart Cards * Electronic Manufacturing * Hardware/Firmware/Software Design * Schematic and PCB layout * ALL PRICES QUOTED IN USD UNLESS OTHERWISE NOTED -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Thanks Richard - Yeah I noticed it had been about a year since the competetition actually started. Aparently there have been about 20 people who expressed an interest / are 'working' on it. Rules say it has to be in C unless you can justify exactly why it cant be done, my answer is that assembler is free and most likely makes better use of space.. In effect its got to be done in less than 8k.. or theres no room for a program to actually do anything with the hard drive ! Jon Baker EraseMEjonspam_OUTTakeThisOuThayseed.net > From: "Richard Sloan" > This has been 1 year now, no winners yet? Is there any entrants? > > I really want to see some do this in 8K of code and NOT done in assembler! Seems a bit out there..... > > But I am ready to be proven wrong. > > Richard. > > >> simple! Just follow this link for the schematic. His website has 5 > >> archived copies on line and available. > > >> web.archive.org/web/20010826220431/montanadesign.com/contest/idesch > >> em.gif > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Wed, 5 Dec 2001 08:18:04 -0000, Jon Baker <jonspam_OUTHAYSEED.NET> wrote: >Thanks Richard - Yeah I noticed it had been about a year since the >competetition actually started. Aparently there have been about 20 people >who expressed an interest / are 'working' on it. Rules say it has to be in C >unless you can justify exactly why it cant be done, my answer is that >assembler is free and most likely makes better use of space.. In effect its >got to be done in less than 8k.. or theres no room for a program to actually >do anything with the hard drive ! > Unless the rules have changed, I believe that the program must not only be written in C, but specifically in HiTech C. Regards, Bob -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Wed, 5 Dec 2001, Bob Barr wrote: > On Wed, 5 Dec 2001 08:18:04 -0000, Jon Baker <@spam@jonKILLspamHAYSEED.NET> wrote: > > >Thanks Richard - Yeah I noticed it had been about a year since the > >competetition actually started. Aparently there have been about 20 people > >who expressed an interest / are 'working' on it. Rules say it has to be in C > >unless you can justify exactly why it cant be done, my answer is that > >assembler is free and most likely makes better use of space.. In effect its > >got to be done in less than 8k.. or theres no room for a program to actually > >do anything with the hard drive ! > > > > Unless the rules have changed, I believe that the program must not > only be written in C, but specifically in HiTech C. ...thus disqualifying the vast majority of PIC developers, especially those who don't do it for a living with employer money. I could very well be wrong, but isn't HT PICC by far the most expensive compiler you can find for the PIC? I'm sure it's a nice product (though I do prefer CCS), but at $850 the price is simply too steep for me. Dale -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I know what you mean, I don't think it is worth the effort to try. Heck, the Hi-Tech compiler costs 5x the value of the hard disc reward. Another reward is a copy of Salvo. Pardon my indifference, but: big deal. For the effort it takes, if I were to do this (not saying I can do it), I'd want a more fair compensation for the time spent. Those that can afford the HTCC probably have better things to do with their time using it (i.e. more assured paying work), those who can't afford it probably don't have the software! Jeff At 11:50 PM 12/4/01 -0500, you wrote: {Quote hidden}>This has been 1 year now, no winners yet? Is there any entrants? > >I really want to see some do this in 8K of code and NOT done in assembler! >Seems a bit out there..... > >But I am ready to be proven wrong. > > >> > web.archive.org/web/20010826220431/montanadesign.com/contest/idesch > >> em.gif > > >> Follow this link to download all of the last five versions of his > >> website. > > >> > http://web.archive.org/web/*/http://www.montanadesign.com/contest.h > >> tml > > >> > > >> > > I was working on the PIC IDE design contest run by Andy Kunz > >> > > http://www.montanadesign.com/contest.html but since his ISP was > >> vandalized > >> > > he no longer has the schematic on the site. He said that > thousands of -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> > Unless the rules have changed, I believe that the program must not > > only be written in C, but specifically in HiTech C. > > ...thus disqualifying the vast majority of PIC developers, especially > those who don't do it for a living with employer money. I could very well > be wrong, but isn't HT PICC by far the most expensive compiler you can > find for the PIC? > > I'm sure it's a nice product (though I do prefer CCS), but at $850 the > price is simply too steep for me. > I agree, its nice, but way too expensive, and I'm suprised HTsoft didnt offer some prize as an incentive for people to buy their compiler- not that I would though. I was going to give it a go with some kind of C.. rules or not, I dont really have much desire for a RTOS for my pic collection or a 40Gb hard drive.. just more stuff to loose when it all goes wrong :) .. but most likely it will ultimately be written in assembler so any and all can use it regardless of the language they use. No prizes, but it would be neat anyway. If anyones interested on making this a collaborative project ( assembly language) feel free to email me KILLspamjonKILLspamhayseed.net and maybe we can get this working... I look forward to masses of emails tomorrow :) Jon Baker RemoveMEjonTakeThisOuThayseed.net -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Re: > > Unless the rules have changed, I believe that the program must not >> only be written in C, but specifically in HiTech C. > >...thus disqualifying the vast majority of PIC developers, especially >those who don't do it for a living with employer money. I could very well >be wrong, but isn't HT PICC by far the most expensive compiler you can >find for the PIC? Yes, PICC is expensive, but good tools are expensive (e.g. Salvo, PICC, PICC-18, IAR compilers, etc.), or they're free (gcc, etc.). I don't mean to demean other low-cost compilers, it's just that with the price comes performance, flexibility, support, etc. I won't disagree that employer money helps when purchasing these products. That's why we offer Salvo Lite, a fully-functional freeware version of our RTOS. You do still need a compatible compiler, though. Here's why we offered a free copy of Salvo to the winner of the contest (under its original rules, of course): Not a single line of your Salvo code would have to change to port the application from PIC16 to PIC17 to PIC18 (and to several other platforms, coming up in v3.0). Writing the rest of the application (IDE interface) in C would result in similarly easy portability. With Salvo, we left the assembly-language realm a long time ago (Salvo v1.0 was in PIC17 assembly), and our customers have put that to great use. With the cross-platform portability that Salvo offers, if your employer decides that an alternative processor (e.g. an 8051) is going to replace a PIC, you can take your Salvo app with you ... -- ______________________________________ Andrew E. Kalman, Ph.D. spamBeGoneaekspamBeGonepumpkininc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Jon, I too have thought seriously about making it work using assembly. I don't see the need for anything to have to be absolutely coded in 'C'. Regardless of the application. And I have been using assembly for a long enough time to be able to make the PIC do just about anything I want it to with only a little trouble. So, if you want to work on this, count me in. Let me know how you need me to do, and we'll go from there. Regards, Jim {Quote hidden}> > Unless the rules have changed, I believe that the program must not >> > only be written in C, but specifically in HiTech C. >> >> ...thus disqualifying the vast majority of PIC developers, especially >> those who don't do it for a living with employer money. I could very >> well be wrong, but isn't HT PICC by far the most expensive compiler >> you can find for the PIC? >> >> I'm sure it's a nice product (though I do prefer CCS), but at $850 the >> price is simply too steep for me. >> > I agree, its nice, but way too expensive, and I'm suprised HTsoft didnt > offer some prize as an incentive for people to buy their compiler- not > that I would though. > > I was going to give it a go with some kind of C.. rules or not, I dont > really have much desire for a RTOS for my pic collection or a 40Gb hard > drive.. just more stuff to loose when it all goes wrong :) .. but most > likely it will ultimately be written in assembler so any and all can > use it regardless of the language they use. No prizes, but it would be > neat anyway. > > If anyones interested on making this a collaborative project ( assembly > language) feel free to email me TakeThisOuTjonEraseMEspam_OUThayseed.net and maybe we can get > this working... I look forward to masses of emails tomorrow :) > > Jon Baker > RemoveMEjonTakeThisOuThayseed.net > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Wed, 5 Dec 2001, Andrew E. Kalman wrote: > Re: > > > Unless the rules have changed, I believe that the program must not > >> only be written in C, but specifically in HiTech C. > > > >...thus disqualifying the vast majority of PIC developers, especially > >those who don't do it for a living with employer money. I could very well > >be wrong, but isn't HT PICC by far the most expensive compiler you can > >find for the PIC? > > Yes, PICC is expensive, but good tools are expensive (e.g. Salvo, > PICC, PICC-18, IAR compilers, etc.), or they're free (gcc, etc.). I'm not trying to start a holy war about whose compiler is better (honest), I was merely making the point that this particular requirement is a restriction that eliminates the vast majority of PIC developers from participation in this particular project. I'm not saying it's right, wrong, good or bad, just that's the way it is. I do take issue with your statement, though. If your claim is correct, then there is no room to admit that a low priced tool can be a good tool. I think this is incorrect, and many years of tool use (tools of all kinds) proves this incorrect. I have seen many lousy expensive tools, many lousy free tools, some good expensive tools, a few good free tools and plenty of good inexpensive tools. I don't see a direct correlation between price and quality or utility, mostly a correlation between price and manufacturer support. > I don't mean to demean other low-cost compilers, it's just that with > the price comes performance, flexibility, support, etc. I won't > disagree that employer money helps when purchasing these products. > That's why we offer Salvo Lite, a fully-functional freeware version of > our RTOS. You do still need a compatible compiler, though. Which in the case of this particular project, would be an $850 full version of PICC -- unless of course you can complete the whole thing in less than 21 days. As for performance, flexibility and support, I can only speak to my own experiences with the product I use or those I have tried. I can say that I am completely satisfied with my choice. In fact, I think I got quite a bit better flexibility and performance for quite a bit less money. Of course, that's my opinion. If I felt differently I wouldn't have bought the product. Having never had a need to use an RTOS like Salvo, I don't really know much about it. Again, though, I wasn't trying to make a point about whether PICC is a good product for the money or aything else. Simply pointing out that the "entry fee", if you will, is probably the primary reason that particular project has not come to completion in a year. Dale -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Dale Botkin wrote: > I don't see a direct correlation between price >and quality or utility, mostly a correlation between price and >manufacturer support. That's probably a better way of saying what I had intended to say. I also use low-cost, good tools, too (like Creative Softworx Capture Professional, WS-FTP, etc.) A complex product like a compiler for multiple targets requires good support, and that costs $$$. Salvo actually ships with many _more_ libraries than any of the compilers we support (because there are variants for each target processor, all in the name of providing the smallest possible memory requirements for a particular set of features), and all of that generation, maintenance and testing costs money and time. One of the measures we've employed in terms of picking compilers to certify for Salvo has been the quality of _their_ support. We work closely with compiler vendors to ensure that our end-users' experience with Salvo is as trouble-free as possible. We have a very good working relationship with Microchip and HI-TECH, and are developing ones with others. We also support free compilers, mainly those in the GNU C toolchain (gcc for x86 is scheduled for Salvo v3.0, and gcc for 68hc11 is also planned.). and: >Having never had a need to use an RTOS like Salvo, I don't really know >much about it. Again, though, I wasn't trying to make a point about >whether PICC is a good product for the money or aything else. Simply >pointing out that the "entry fee", if you will, is probably the primary >reason that particular project has not come to completion in a year. From a business perspective, the "entry fee problem" is probably one of our biggest challenges when marketing Salvo. We are not a compiler vendor, so all we can do is offer Salvo Lite as a stepping stone to the full version of Salvo. In general, the 21- or 30-day or application-size-limited eval versions of the compilers are good enough to try with Salvo Lite to get a feeling for what Salvo / RTOS programming is all about. I didn't mean to hijack this thread into an RTOS discussion. I just wanted to point out our (vested) interest in seeing the IDE competition done in C. Salvo in assembler was a dead-end. Salvo in C is blossoming. Regards, -- ______________________________________ Andrew E. Kalman, Ph.D. aekEraseME.....pumpkininc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Jeff DeMaagd wrote: >I know what you mean, I don't think it is worth the effort to try. Heck, >the Hi-Tech compiler costs 5x the value of the hard disc reward. [...] >For the >effort it takes, if I were to do this (not saying I can do it), I'd want a >more fair compensation for the time spent. [...] The real reward is that then you (and everyone else) would have a PIC/hard-disk interface to use! That would be cool! But I agree with you completely about the restriction of using hi-tech C. The whole thing would be more useful to everyone, I think, if written in assembly. The contest rules do allow for that, if you can argue the point sufficiently well. Michael V Thank you for reading my little posting. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservmitvma.mit.edu with SET PICList DIGEST in the body

At 06:42 AM 12/6/01 -0800, you wrote: >The real reward is that then you (and everyone else) would have >a PIC/hard-disk interface to use! That would be cool! > >But I agree with you completely about the restriction of using >hi-tech C. The whole thing would be more useful to everyone, I >think, if written in assembly. The contest rules do allow for that, >if you can argue the point sufficiently well. How well is sufficiently well? As far as I'm concerned, beggars can't be choosy. Getting someone to code this project in any programming language for the chance at getting dirt (vs. the real value of such code) would be a feat in itself. Of course, I wouldn't want to code something so massive in assembly language anyway. Frankly, for a project that is on that large of a scale I don't see the payback as being worthwhile. While it may not be the case, it just appears to me that they are trying to sucker people into doing their hard work for them. I don't think 21 days is enough to get acquainted with the HT compiler in demo mode and complete such a massive project, so that would mean owning the compiler, others did note that it was probably the most expensive compiler for the chip. Jeff -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservEraseMEEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

> I don't think 21 days is enough to get acquainted with the HT compiler in > demo mode and complete such a massive project, so that would mean owning > the compiler, others did note that it was probably the most expensive > compiler for the chip. I stand corrected -- there is one (IAR) that goes for over $2K at the low end. I believe that's for their product that will cross-compile for just about anything though, not just PICs. I s'pose that might be justifiable if you had to work with several different processors. Dale -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservspam_OUTKILLspammitvma.mit.edu with SET PICList DIGEST in the body

> How well is sufficiently well? As far as I'm concerned, beggars can't be > choosy. Getting someone to code this project in any programming language > for the chance at getting dirt (vs. the real value of such code) would be a > feat in itself. Of course, I wouldn't want to code something so massive in > assembly language anyway. I've given this a REALLY good looking over the past few days- the IDE side of things really isn't difficult to implement- slightly more complex than talking to an 8 bit LCD, the real killer in the whole thing is implementing the file system. I've already got a pic talking to an IDE drive to retrieve number of heads etc.. and it will read and write sectors- although only uses the first half of every 512 byte sector becuase I'm using any external ram. What I'm a bit stuck with is how to implement some kind of API so that once we've got all these nice functions in place for reading and writing files- people can actually use it easily- whether the pic-ide box becomes a device on an i2c bus, or if its serial or.. whatever- I really cant think of the best way to do this bit of the project. I probably shouldnt even be thinking about it at the moment. The other thing is is the pic-ide unit going to be standalone and then directed by some other microcontroler or do we really want to be able to run our own software on the same pic thats doing the IDE stuff. I'm keen on doing this in assembly language because Its not going to be finished in 21 days and I can't afford to buy the compiler. > Frankly, for a project that is on that large of a scale I don't see the > payback as being worthwhile. While it may not be the case, it just appears > to me that they are trying to sucker people into doing their hard work for > them. I get that feeling too. Jon Baker RemoveMEjonTakeThisOuTspamhayseed.net -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

On Thu, 6 Dec 2001, Jim wrote: > Gee - with a mass storage device you > could potentialy do 'task swapping' out > to disk and actually utilize the same > PIC for 'user' tasks ... ('cept the > PIC doesn't execute a pgm from RAM does > it?) > > Memories are coming back of time spent on > the TI 960 and 990 series of microcomputers > with apps (on the 990) running under DX10 > (and later DNOS) where user tasks were > regularly swapped 'out' to disk in order > to utilize what memory there was for other > tasks whose 'time' had come to execute ... Well, yeah, that still happens on pretty much any multitasking OS, especially those using virtual memory, no? If not, I'm reclaiming all those swap partitions! 8-) Dale -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

The FAT isn't really that tough, it's just deciphering the spec, and a LOT of overhead in the PIC. I've got existing assembly code which will read the data of a file, given the actual filename and direcory path stored as strings in a buffer. Just haven't had time lately to implement the writing side of things. -Mark At 04:39 PM 12/6/01 +0000, you wrote: {Quote hidden}> > How well is sufficiently well? As far as I'm concerned, beggars can't be > > choosy. Getting someone to code this project in any programming language > > for the chance at getting dirt (vs. the real value of such code) would be >a > > feat in itself. Of course, I wouldn't want to code something so massive >in > > assembly language anyway. > >I've given this a REALLY good looking over the past few days- the IDE side >of things really isn't difficult to implement- slightly more complex than >talking to an 8 bit LCD, the real killer in the whole thing is implementing >the file system. I've already got a pic talking to an IDE drive to retrieve >number of heads etc.. and it will read and write sectors- although only uses >the first half of every 512 byte sector becuase I'm using any external ram. > >What I'm a bit stuck with is how to implement some kind of API so that once >we've got all these nice functions in place for reading and writing files- >people can actually use it easily- whether the pic-ide box becomes a device >on an i2c bus, or if its serial or.. whatever- I really cant think of the >best way to do this bit of the project. I probably shouldnt even be thinking >about it at the moment. > >The other thing is is the pic-ide unit going to be standalone and then >directed by some other microcontroler or do we really want to be able to run >our own software on the same pic thats doing the IDE stuff. > >I'm keen on doing this in assembly language because Its not going to be >finished in 21 days and I can't afford to buy the compiler. > > > Frankly, for a project that is on that large of a scale I don't see the > > payback as being worthwhile. While it may not be the case, it just >appears > > to me that they are trying to sucker people into doing their hard work for > > them. > >I get that feeling too. > >Jon Baker >jonSTOPspamspam_OUThayseed.net > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >email spamBeGonelistservSTOPspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body ------------------------------------------- Mark Samuels ARMA Design Tel:(858) 373-1320 Fax:(858) 373-1325 Email: KILLspammarkspamBeGonearmanet.com Web: http://www.armanet.com The information contained in this electronic message is private and may contain privileged, confidential or inside information. Any distribution, copying or forwarding or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

Mark Samuels wrote: > > The FAT isn't really that tough, it's just deciphering the spec, and a LOT > of overhead in the PIC. I've got existing assembly code which will read > the data of a file, given the actual filename and direcory path stored as > strings in a buffer. Just haven't had time lately to implement the writing > side of things. Disclaimer: I haven't looked at the contest rules. Does the file system have to be FAT? There are other formats that might be simpler to implement. Could you invent your own, simpler, format? -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email @spam@listserv@spam@spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

> The competition rules say its got to be FAT- though I dont think I'll > be following all the competition rules anyway- I really do think FAT > is a good way to go even if there are more simple file systems. Afaik there are several people on this list who have made FAT16 filesystems work on small IDE drives and CF cards a long long time ago (and several times), separately, and almost definitely not in C (assembly). > For one thing I like the idea that I can just swap my drives in and > out of my PC and not need any extra software- we also have a pretty > solid standard to follow- and wouldnt have to write os specific > software to read the pic-ide drives. Hint: There is no specification about reading or writing subdirectories at all. Therefore reading and writing to root only is not excluded ;-) Hint2: If there is not enough room to hold a FAT16 fat table in memory then you can implement a Turing machine that reads and writes at the same time, on a multi session capable drive, with a single modification per pass, to link in the newly written sector. This method is applicable ingeneral to any read/modify/write where there is not enough room to hold things in RAM. good luck, Peter -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

On Fri, 7 Dec 2001 21:46:04 +0200, "Peter L. Peres" <TakeThisOuTplp.....TakeThisOuTACTCOM.CO.IL> wrote: > >Hint2: If there is not enough room to hold a FAT16 fat table in memory >then you can implement a Turing machine that reads and writes at the same >time, on a multi session capable drive, with a single modification per >pass, to link in the newly written sector. This method is applicable >ingeneral to any read/modify/write where there is not enough room to hold >things in RAM. > As I recall, the original schematic of the board does have an external RAM chip for storing the FAT. Regards, Bob -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

Any references to this design? R. >> On Fri, 7 Dec 2001, Peter L. Peres wrote: >> > >> > Afaik there are several people on this list who have made FAT16 >> > filesystems work on small IDE drives and CF cards a long long time ago >> > (and several times), separately, and almost definitely not in C >> > (assembly). >> > >> And they decide to share their work ? >> Because I found this one an extremely interesting subject... >> Thanks, Vasile >> -- >> http://www.piclist.com hint: The PICList is archived three different >> ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> Any references to this design? There were people on the piclist who said they did this. Less than one year ago. I do not have a direct reference. I have interfaced a Conner laptop drive to a PIC16C64 in 1996 or 97. I cannot publish the design. I did not use FAT(16) although I could have. I used a direct chained 'file system' that did not require RAM to process a FAT in the host (PIC). It was easy once I got the register file issues cleared, and all the strange delays (timeouts) required to catch drive errors, but I don't think I'd do it again in assembly (see Xinu OS & other older Unix related file system implementations). Imho FAT sux. In duplicate (for both copies of the FAT). The project that interfaces a CF to a PIC is also pertinent to hard drives because a CF is a ATA(PI) device with some extensions. I think that he said that he used the 8 bit mode of the CF to save pins. hope this helps, Peter -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body