I have a feeling that this question has been asked many times before, but here we go. Is there a Famicom OS? Perhaps one that uses the Family keyboard and data recorder.
petik1 wrote:
I have a feeling that this question has been asked many times before, but here we go. Is there a Famicom OS? Perhaps one that uses the Family keyboard and data recorder.
Not without redoing the Nintendo's Internals entirely
There is Doctor PC Junior, or you can make your own NES-compatible FPGA Computer capable of using storage (I may look into making a minimal 6502 DOS in the future)
If the PowerPak I/O were unlocked to open up access to main PRG memory and the CF, then it'd become practical to make a spiritual successor to the Doctor PC Jr.
petik1 wrote:
I have a feeling that this question has been asked many times before, but here we go. Is there a Famicom OS? Perhaps one that uses the Family keyboard and data recorder.
Well, not exactly an OS, but BIOS in the
Famicom Disk System device. It only handles the disk operations and verify errors. There are no options or customization available.
The Famicom itself has nothing.
Hmmm, I was thinking of something cartridge or FDS disk based that used the Famicom's expansion port to load and save games a la Family BASIC.
I know that Windows 2000 was "ported" to the FC and shipped with keyboard based clones.
EDIT: Data is saved through the Family BASIC keyboard onto the data cassette recorder, not directly through the expansion port. My bad.
Someone nicknamed Groepaz was working on an NES port of Contiki. Not sure how far he got.
The Contiki port worked, I remember running it. Groepaz also made the NES library for CC65 but the problem was it was only tested with the (inaccurate) emulators available at the time. If someone was to rewrite the conio library (and whatever else is needed), it would probably be usable.
I don't know if there were any applications for it other than the internet ones, and of course there wasn't a network adapter so it was pretty much a dead end. At the time, I looked into getting it work with an RS232 adapter, but between getting that to work (indirectly through a PC), and fixing the CC65 libraries (when I didn't even know C), I had no idea how to proceed.
That and the developers of Contiki OS retargeted the project toward microcontrollers used in wireless sensors.
What good would an OS do on the NES? Does the PowerPak's menu count?
Dwedit wrote:
What good would an OS do on the NES?
A FAT driver would allow programs to read and write files, for one thing.
I feel like bunnyboy once mentioned that the reason he requires you to put on blank save files beforehand instead of allowing them to be created in the menu is because creating files frequently caused Compact Flash corruption.
Edit: I totally can't find where I read that. Maybe I'm making it up.
Edit 2:
Maybe this is the post I'm thinking of, but I could swear there was another post about this.
I thought it was just too slow.
Kasumi wrote:
I feel like bunnyboy once mentioned that the reason he requires you to put on blank save files beforehand instead of allowing them to be created in the menu is because creating files frequently caused Compact Flash corruption.
Perhaps all that means is that he had things to do with a higher priority than finding and fixing bugs in his FAT driver. At least that's what I gather from bunnyboy's "doing all the FAT searching and cluster allocation was too much at the time." I seem to remember the Doctor PC Jr. having a basic FAT12 driver for its floppy drive, and as I understand it, FAT16 and FAT32 are easier because you don't have cluster numbers split across sectors.
On FAT32 filesystems, especially on big volumes, can be a lengthy operation, because the FAT must be scanned linearly in order to find free clusters... I wouldn't be surprised if it too long for the 6502 to do this...
~J-@D!~ wrote:
On FAT32 filesystems, especially on big volumes, can be a lengthy operation, because the FAT must be scanned linearly in order to find free clusters... I wouldn't be surprised if it too long for the 6502 to do this...
A scan of the free list sounds like something that could be done in the background whenever the main program has nothing better to do. On a FAT16 volume, the FAT is no bigger than 256 sectors (256 clusters per FAT sector, 64K clusters per volume), though it's a lot bigger on a FAT32 volume (128 clusters per FAT sector, 1 to 8 million clusters per volume). And does the scan have to be linear instead of pseudorandom?
Doesn't the powerpak have at least 1MB of RAM for holding copies of disk sectors?
The PowerPak has 512 KiB of PRG ROM RAM* and 512 KiB of CHR RAM. But a 4 GB CF card in FAT format will still have a million clusters, whose links are spread out across 4 MiB. It already takes ten seconds to load a 512 KiB game from the CF card; a free list scan on a FAT32 volume would take at least eight times that.
* Distinguish from the separate 32 KiB PRG RAM commonly mapped to $6000-$7FFF.
tepples wrote:
... as I understand it, FAT16 and FAT32 are easier because you don't have cluster numbers split across sectors.
Yeah, because with FAT12, fat entries are 1.5 octets (12 bits), but sectors are
still 512 octets, so fat entries can cross sector boundaries, which can be a major pain in the butt (it forces you to fetch most of the time 2 FAT sectors). This don't happen with FAT16 of FAT32, because fat entries are 16 bits and 32 bits*.
* FAT32 is really "FAT28" because only the 28 LSBs are used.
tepples wrote:
And does the scan have to be linear instead of pseudorandom?
Perhaps, if you take care to avoid trashing the FAT cache, avoid degenerate cases when file system is nearly full and seed the generator properly.
How about a scheme where you allocate the next free cluster until the FAT cache runs out, then make a single random probe for the next table sector before settling in for a linear scan?
Oh, and I know it sounds obvious but don't re-scan from scratch for every single allocation (Microchip, I'm looking at you..)
The closest thing to an OS on the Famicom is either the FDS BIOS (a basic DOS) or Family Basic (a bootable BASIC). Unfortunately you can't use both at the same time. Why they never made an FDS port of Family Basic is beyond me.
There's also the Contiki port, defunct as it is. Theoretically, any of the OSes for 6502 based home computers could be ported, but I'm not aware of any that have been. (Most of them don't have source code available, which complicates things.)
Then there's whatever the "Ten Dollar Computer" clones run. Graphically, it looks like Windows, and has mouse support, but beyond that, I don't know anything about it. Anyone know anything more about this? Has it been dumped?
I've been thinking about building an NES based computer. (Basically just adding some peripherals and storage). So having some sort of OS would be nice, but I'll probably end up writing my own.
As for reading FAT tables taking too long, the solution to that is simple: Use a non brain damaged filesystem instead.
Karatorian wrote:
As for reading FAT tables taking too long, the solution to that is simple: Use a non brain damaged filesystem instead.
For one thing, as I understand it, the most popular NES to CF adapter (PowerPak) can't read anything but FAT. For another, Windows out of the box can't read and write anything but FAT, NTFS, and MTP, and for MTP, you'd have to rig up a USB to CF adapter that supports MTP and your particular file system. So what non-dain-bramaged file system would you recommend, other than creating fixed-size "disk images" within a FAT volume and reading and writing files in those?
Oh, I was thinking something similar to most Unix filesystems, possibly the Minix FS. Or a block system similar to older versions of Forth. But as I run Linux exclusively, the default Windows situation doesn't matter to me. Sure, FAT is the defacto standard, but it's still a stupid design.
Karatorian wrote:
As for reading FAT tables taking too long, the solution to that is simple: Use a non brain damaged filesystem instead.
I'm curious — what filesystem do you think would be more suitable for something with as little RAM as the NES? AIUI, some of FAT's stupidity was that it needed to be usable with only the 16KB in the first IBM PC.
But back when FAT was being designed to work on 16K PCs, disks were under 2 MB. CF cards are already a thousand times bigger than that.
Sure; I haven't heard any findings on ultra-low RAM filesystems at all. FAT's awkwardness is largely the result of its design decisions being extended to their absurd extremes.
Is EXT2 any better than FAT32?
Ext2 is probably not ideal, because it was designed for 32 bit systems. On the other hand, so was Fat32. The Minix FS wouldn't be too bad, except for the 64MB limit on filesystem size. (Which is fine on a floppy, bus silly on anything else.)
Personally, if I was writing an OS for a 6502 based computer (NES based or otherwise), I would probably review what was used on '02 based home computers back in the day and either design something similar, or implement one of them (if I felt it met my needs). Of course, not using something standard means that I'd need to write an implementation on the PC side too. Which I would probably use FUSE for.
Theoretically, something based on binary trees would lead to faster file access times than something based on linear block lists. So FAT is definitely not idea on a low speed system such as the NES. Filesystems optimized for eight bit systems with limited RAM probably hasn't been an active area of research lately, but I bet there where some imformative papers published during the 80s.
Karatorian wrote:
if I was writing an OS for a 6502 based computer (NES based or otherwise), I would probably review what was used on '02 based home computers back in the day
Then reimplementing Apple's ProDOS file system, used by SOS on Apple III, ProDOS on Apple II, and GS/OS on Apple IIGS, would probably be the best option, despite its 32 MB file system size limit. Perhaps ProDOS disk images inside FAT16/FAT32?
Quote:
Of course, not using something standard means that I'd need to write an implementation on the PC side too.
And the Apple IIGS emulation community has provided plenty of tools to read and write ProDOS disk images.
Quote:
Theoretically, something based on binary trees would lead to faster file access times than something based on linear block lists.
ProDOS is based on 1:256 trees. Each file larger than 512 bytes has a key block, and each sector in the key block can point to either data sectors (up to 128 KiB) or second-level key blocks (up to 16 MiB). The directory entry states how many levels of key blocks (0, 1, or 2) are in use. There's also a "volume bitmap" immediately after the directory stating which clusters are in use, but because it's only 1 byte per sector, it's faster to read that than to read a FAT.