Hey all... question of the year this has got to be. I was seriously considering using a 1MB flash EEPROM chip as my BIOS chip. Then I went into a "Click" camera store and saw multiple memory card readers and huge memory cards, then (wam... bang) an idea struck. If I got a 256MB flash memory chip I could not only use it for the BIOS... I could use as(wait for it...) all the memory chips... RAM/ROM, video memory,periferal memory, et al. Could an arrangement of this type work? Just imagine the potential of this if the idea could work.... one of your SBC's would all of a sudden become VERY VERY small. Lets see we'd be eliminating 1/3 to 2/3's of the circuitry immediatly... right? Dang... that really would be a small computer (size wise anyway) wouldn't it? LOL
Lyos Gemini Norezel
BTW... yes yes I know... I'm insane

_________________
Mundus Vult Decipi et Decipiatur

Flash memory cells can only be written to on the order of 100,000 or 1,000,000 times before they "burn out." This makes them fine for mass storage, such as one would use a hard disk for, but inadequate for RAM, which needs to handle trillions and quadrillions of writes. Flash is also a little slower to read, and extremely slower to write than RAM. Write times are on the order of milliseconds.

You probably don't want your BIOS in the same flash memory as your main storage, if at all possible. The BIOS should remain protected from being accidentally written to. Usually if you blast your BIOS, you make a paperweight out of your computer.

You can't use a CF card for a BIOS because CF cards have an IDE interface, not a direct address/data interface. You can desoldier the actual flash chip(s) out of a CF card and use those (or just order them for cheaper). While a 256MB CF card is small in size, keep in mind that there are probably more than just one flash chip inside.

Using 256MB in a 6502 system will require bank switching because of the size of the address bus.

SD cards have a proprietary interface (I believe).

You can make a physically small 6502-based system if you use QFPG and SOIC parts.

Ok... it makes sense, I guess. But it raises one further question from me... could a 4MB flash chip be used to put an OS on? Not BIOS but something a little more advanced (like Menuetos... www.menuetos.org) assumming I can translate the source code to 6502 assembly language w/out losing too many functions. Is this possible? Would it be faster or slower than a H/D? User created files could be automactically be written to an H/D to prevent more than necessary writes... with this as a possibility could the flash chip be written once then have the write function disabled by jumpers? Is this even feasable?
Lyos Gemini Norezel
I'm not insane... ummm... yeah... that's it. *eyes shifting must stop the shifty eyes*

_________________
Mundus Vult Decipi et Decipiatur

> could a 4MB flash chip be used to put an OS on?

Sure.

> Would it be faster or slower than a H/D?

It will probably only be faster than a HD if you're only transferring a small amount of data. The hard disc takes a few milliseconds to get the heads to the right tracks, which is why it might have a speed disadvantage for small amounts of data that you could read off the flash before the HD was ready to give you the first byte; but then especially if it used DMA, the HD would transfer more bytes per second. Interfacing the flash chip would not be nearly as complicated a project

> User created files could be automactically be written to an H/D to
> prevent more than necessary writes

If you're only writing files to flash, its life will be practically unlimited. Where you would run into problems is if you were to try to use it like RAM where some addresses may get written tens of thousands of times per second. The flash memory can't write that fast anyway; but if you just save your work every ten minutes as if to a HD, 100,000 to 1,000,000 writes will go a long way.

> with this as a possibility could the flash chip be written once then have
> the write function disabled by jumpers? Is this even feasable?

If you have more than one chip, you could disable whichever ones you want to, and leave the rest able to write to. Some have pins that allow you to write-disable part of the chip while leaving the rest writable. Here I'm generally talking about individual flash memory ICs, not the small plug-in cards.

This wasn't quite what I meant... I meant write the OS to the chip ONCE then disable the write function of the chip with jumpers. Only connecting the write function to update the OS. Can an OS work that way? or does it need to be able to "write" on itself?
Lyos Gemini Norezel

_________________
Mundus Vult Decipi et Decipiatur

The short answer is yes. You're probably talking about "writing" the chip once by sticking it in an EPROM programmer, or using JTAG. Under normal operation of the system, it is then feasible to not even allow writes to the chip by physically not connecting the write-enable pins.

As for OSes writing on themselves, the short answer is that they only need to do so when updating themselves. A longer answer is that they may "write on themselves" once loaded into RAM by loading new drivers.

For any OS there is usually a tradeoff between "easy to upgrade" and "easy to protect." Filesystem based OSes (DOS/Windows/Linux/etc.)are the easiest to upgrade, but the easiest to corrupt, too. Mask-programmed ROM-based OSes (Commodore 64/Most embedded OSes/etc.) are easy to protect from corruption, but very difficult to update.

> Mask-programmed ROM-based OSes (Commodore 64/Most embedded
> OSes/etc.) are easy to protect from corruption, but very difficult to update.

...it can be done though, if the original OS was made for it with the appropriate software hooks. My HP-71 hand-held computer (which you can see on my pages here on the website) allowed for this. The basic OS is in ROM, but you could load in expansions, updates, or (if it were ever necessary) corrections, in RAM or in plug-in ROMs. Although I have used the feature a lot to add expansions (which I myself did not write), I haven't studied exactly how the insides work. I suspect it goes something like this: The functions in the OS have a variable space to hold an address or token of some kind for a replacement. If there's nothing there, the function, when called, goes ahead as originally written. But if you install an update, then when you turn the computer on the OS reviews everything installed, finds the info it needs to put in that "replacement" variable space for the old function, so execution is deferred to the new. The old is still in the ROM and will again be in effect if the new is removed. However they did it, it works flawlessly.

I know it's a bit off the subject, but maybe it'll give someone some good ideas.

Would the newly written material then have to be "saved" to the OS itself? Or could that modification be stored elsewhere?
Lyos Gemini Norezel

_________________
Mundus Vult Decipi et Decipiatur