Very interesting! Rather than using the first byte of each page as a link to the next, you could use a page as a link map - each byte represents a page and it’s content is the number of the next byte in the chain. Firstly this would allow file pages to use the full 256 bytes (better alignment with data in RAM) and secondly the page map would double as an allocation map; an entry of zero indicates the end of a file chain as before, no need for the bitmap in the header. Also, a single 256-byte page map is faster to navigate and easier to cache in RAM than following the chain all across the 64K disk space
Great work. I'm enjoying all of these retro z80 projects and already embarked on making a very simple z80 game console project, with my 8 year old son, called the 'pip80'. Very inspiring .. thank you 👏
Thank you for your support! I find that these retro projects are very good for learning our computers work and mainly to learn assembly. Is pip80 something you came up with?
Just discovered your channel.Watched several previous episodes. Awesome job on whole system! A few years from now, I would like to conduct some computer science experiments on the process of system and software creation. I would like to explore the choices made in the early decades of 8 bit systems, and see what could have been done to exercise more wisdom in making use of previous generations of hardware technology. The goal would be the creation of an index of thousands of standardized software components that would make bug free system and application creation easier for makers who do not have PhD level programming skills. I am thinking of the world of amateur built aircraft. There is a sophisticated system of education, training, standards, specifications, blueprints, fasteners, components, tools, and techniques that have been developed to insure the success of the owner/builder/pilot.
Thanks for your comment! That sounds like a very cool and interesting project, if you start doing it, give us some pointers so that we can follow your progress!
I believe was better to use allocation table like fat does but one byte instead of 12bits, 16bits or 32bit, you can use 0x00 as marker for empty block, pointing to itself if block is used and file is smaller than a block, and point to next block if file continue with another block. Or 0xFF as empty block, 0x00 as single block file, and from 0x01 to 0xFE that point to page 0x00 to 0xFD, page 0 being used by FS descriptor, and page 1 as allocation table, this version will make it easier in case of SPI FLASH memory in case of single page files and directories. And you don't need a dedicated table of empty block to count free space, you count the allocation table with value as 0 you can read entire allocation table and count realtime EEPROMS and FLASH support delayed read. I propose that because this way you avoid dividing the file size by 255 for seek but you can use divide by 256 or >> 8 to get the page from seek byte and you can add a backup allocation table for example with a check sum in the FS header for both allocation tables.
Z80 were first home kit computers in the 80s where you had to soldier all the parts to a motherboard. The OS of the day was CPM.. So it already had an OS. The even supported disk drives. The first ones being single sided/single density 8" floppy
I find CP/M igreat but limited for a modern 8-bit computer. For example, it doesn't support directories nor multiple filesystems. It did inspire me for Zeal 8-bit OS though 😉
Thanks for your comment! It is possible indeed to use a FAT to store the "linked-list" of pages used by a file/directory. However, keep in mind that I have to implement it in Z80 assembly by hand! Using a FAT would not only add several more reads/writes to different locations on the EEPROM, but also lift some restrictions that would make the code slower. For example, the number of entries per directory, today, it's limited to 8, so it is easy to browse through a single directory, if I use a FAT instead, I would need to perform a supplementary read and check every time I reach 8+ entries while reading a directory. Moreover, when using an I2C EEPROM, you really want to reduce the number of transactions that you make on the bus because it is slow (100KHz in my case). So you want to read more data that are contiguous. All these changes sounds light and easy to make in C, it is not the same thing in assembly. But I don't exclude the possibility of having a FAT in future versions 😄
I liked this idea! I think you should keep it as simplistic as possible, after all you can have multiple filesystems, so having a really simple baseline one would be a good start. The only thing I wasn't mad keen to see was stuff that was reserved. I'm assuming that was just the way the memory boundary turned out tho? Looking very nice. Eight folders should be more than enough for anyone! ;)
Thanks for your comment! I agree with you, this is what I am trying to do here, keep it simple even if not optimized. Plus a small change in the FS may imply significant changes in the ASM code. The reserved area I talk about in the video is more of a padding, so keep the entries/elements aligned on a value that makes it easier for me to handle. For example, having a 28 bytes entry doesn't really make sense, it makes entry offset calculations more complicated on the Z80 and doesn't give me any benefit. That's why there is a 4-byte "reserved" area that will in fact be ignored and used as padding
Good for what it is. I suspect that the size limitation will come back to bite you sooner or later. Storage is cheap nowadays. I'm thinking here about easy to drive & use formats like Compact Flash. I wonder how big the Z80 assembler is for the CP/M 2.2 disk format? You might be able to find an extant implementation that just requires a bit of porting work. This would give you a common format with so many other Z80 systems.
Thanks for your comment! Indeed, the size limitation is a drawback, but it makes the implementation much simpler and smaller. In fact, I plan to also have FAT16 in the future, as Zeal 8-bit Computer video board will have a micro SD slot. As such, CF cards will also be able to use FAT16. If I recall correctly, CP/M disk format doesn't have directories nor timestamps, which is quite limiting.
Thank you for your comment! Fragmentation at which level? The only fragmentation is the fact that files are divided into 256-byte pages. At the I2C EEPROM level, there shouldn't be any further fragmentation as the hardware pages are smaller than that (32 or 64 bytes). In theory yes, It can, as it has 512KB of RAM, 256KB of ROM, VGA output, and a PS/2 keyboard input. But I haven't tried porting it, it is closed source if I am not mistaken. I am concentrating on Zeal 8-bit OS kernel.
@@Zeal8bit I think I have a far more basic understanding of file systems than you do! I remember back in the days of MS-DOS, running a defrag and watching as each file's parts were moved so it was as sequential as possible to avoid the OS from having to look at various parts of the disk every time it was accessed. I understand that this isn't really an issue with solid state media, so is that the same situation with EPROMs? I didn't realise that SymbOS wasn't open sourced - that seems like a mistake on their part. I've been looking to build an 8 bit computer that is compatible with SymbOS for a while, so perhaps I will go down the "make your own MSX" route. I completely understand you focusing on your own OS, though. It seems to be coming along nicely, and I appreciate that you are taking the time to document each stage, even if I don't always fully understand it! 😉
Defragmentation was mainly required because on hard disks, there was a mechanical head that moved around to read the sectors that contained data. By moving file's chunk to make them contiguous, you reduces to physical distance between the chunks of data. On SSDs, Flashes, ROM, EEPROM (etc...), this problem doesn't exist because there is no mechanical head, retrieving the data take the same time, regardless of its address. Thank you for your support! Ifyou have question about the OS or the project you can ask or even join the discord, we often discuss about other 8-bit computers. Maybe your 8-bit computer can be compatible with Zeal 8-bit OS😄😄
The current hardware leaves out the VGA covered in previous videos. Is the plan to release the VGA separately? Are you going to make a board that has both? I would love to buy this, but don't want to purchase this now if a combined VGA version is coming soon.
Thanks for your comment! Indeed, I plan to release the VGA board separately. At the moment, I don't have any plan to release a board that has both the video board and the motherboard, as the motherboard is only using THT component while the video board has SMD components. It is true that I haven't talked a lot about the VGA board recently, it's because I was concentrating on the software. Once I'll reach a stable point on the OS (provide APIs for writing text software, include an editor or an assembler) , I will resume my work on the FPGA.
Cool! :) And perhaps just right for such a small storage device. 16-byte filenames is a luxury. :) Is it helpful with Chinese characters? There is only 1 thing I don't like: If I used it, the limited number of directory entries would confuse me. It would be difficult when making a new file unexpectedly fails because I wasn't watching the number of entries. I was would have to move a file to a different directory to make space, create the dubdirectory, move the previously-moved file into the subdirectory and update any references to it, create my new file in the new subdirectory, and finally update any references i had made to the file I planned to create. (Often, I make a reference to a file before creating it.) Having written it down, I see it's really too much for me to work with. Here's a proposal for large directories: Make them linked lists just as files are. To create space for the link byte, remove one of the reserved bytes from each entry, making them 31 bytes long. That gives us more space than we need but that's no bad thing; we weren't using the reserved bytes. The root directory can also have a linking byte. As the entries are shorter, we can also cut into the 28 reserved bytes so we can have a 7th entry in the header.
Sorry for the late reply, indeed 16-byte can be helpful for Chinese characters, if we use a 2-byte encoding for each character, we would be able to have 8 characters per name, which is more than enough in Chinese Mandarin. I understand that the entries count limit is a problem, in fact, as it was suggested to me, it would be easier to have a FAT, a 256-byte table where the value at index i represents the next page of entry i, in code it would give something like `next_i = fat[i]`. As such, we wouldn't have any limitation on directories or files, it would also simplify the way entries are browsed. This is something I would like to implement in a future version.
@@Zeal8bit Interesting! I admit I've never properly learned about FAT filesystems. The last time I looked at them was in the 90s when I understood much less in general. It's really interesting to hear they can be even easier than your simple filesystem.
If I integrate a FAT that can fit in a single 256-byte page, it will become simpler and lift dome restrictions. FAT12/16/32 use the same concept (well their name is taken from that), but they are a bit more complex.
Haha thanks for your comment, I am only motivated to work on this project I would say 😄 I haven't publicly presented the latest prototypes after the "Latest prototype of my 8-bit computer [Zeal 8-bit computer]" video, because now the changes are minor. I still add the new ones to my website however, so you might want to check the website. (zeal8bit.com)
You could probably have infinite directories entries, if you allow a directory entry to be a 'continued' directory. Such a directory would be the same as a link to another directory, but it has a flag of some sort set (or you could indicate it by making the name all zero-bytes) to indicate that instead, the content of the linked directory entry should be 'appended' to the current directory.
It's a pleasure to see you here! This is a very good idea in fact, it would flatten a sub-directory with its parent at the expense of a single entry. The only complexity I see here would be that we would need to manually move up the sub-directory's entries to the parent when removing entries in the parent.
@@Zeal8bit Hi, your video inspired me. I also need a retro FS that can accomodate several block sizes for different devices. I have an implementation working in C on linux with FUSE, it is very similar to yours but I added some important improvements. I am finishing documentation and will be publishing it soon. I have directories working, I am able to extend a directory block to another one. When deleting a directory, you can just zeroize the dir entry and skip over it when enumerating. You can also do optimizations, like replacing the deleted entry with the last one and erasing the last one, this makes it easier to shrink directories. I'll write again when you can read the spec.
It's the order that multiple-byte data is stored. So if you have to store a 16bit number you could store it low then high or high then low. Little endian is low-then-high
Wow, that’s a lot of dedication to get just 64KB of storage properly organized (sounds like something I would do). But the max volume size of 64K does make this mostly useless for all of my 8-bit computer projects, which always use SPI Flash ROMs in the 128K - 64MB range. Any chance this limit can be upgraded in the future?
Haha, yes it's a lot of dedication. I have been thinking about having page numbers to be 16-bit. But this adds a lot of complexity to the Z80 code and a bigger overhead for smaller chips. One possibility would be to keep the exact same structure but each page would be 64KB but of course that would only work on big ROMs. Maybe for 8MB and above FAT12/16 is better?
It just requires more code to maintain the checksum, with no real use. If the code corrupts the directory entries, there are fundamental coding problems that need to be solved.
Thanks your your comment! There are several reasons that lead me to choose an 8-pin IC for the mother board: - I don't have any I2C or SPI hardware IP. I am using GPIO bit-banging to simulate I2C. I can currently reach around 100KHz using this method - If I had to implement SPI, it would be even slower because I would need to manage more GPIO pins. - I also have an RTC on the board that is using I2C, so I can use the same pins to manage both devices. If I was using SPI, I would need 1 pin per device (CS), plus the shared pins: CLK, MISO, MOSI. I don't have any spare GPIO pin at the moment. - SD card protocol is more complex than I2C EEPROMs protocol. However, if you noticed, there is a microSD port on the video board (right one), so I do plan to add SD support to the board, but as an extension. The Z80 will "simply" read and write bytes to the FPGA. The latter will perform the transactions.
It would! The ez80 is also much faster (in ADL mode at least) but it is not available in DIP nor PLCC package unfortunately. The goal of my project is to make an educational board with easy-to-replace components. Soldering an ez80 is way harder than soldering a PLCC or DIP socket. Moreover, the ez80 is more an MCU as it has peripherals, if something goes wrong internally (UART for example), you have to replace the whole chip.
@@Zeal8bit I would call it an MCU. There are models with RAM and/or flash, even. However, unlike many (most?) MCUs available these days, it also has an external address and data bus for interfacing directly with external RAM as any standard MPU would.
It's "ZealFS", not "ZFS", because the computer is called Zeal 8-bit Computer but I understand the confusion, it's very close to the ear indeed. I will try to find something else
On which OS would you like to use it? I realize 64KB is not a lot, but supporting bigger sizes makes the assembly code more complex and bigger. Moreover, for bigger sizes (4MB+), ZealFS may not be the best choice
@@Zeal8bit I am a Windows user, like I imagine many people are here. I realize that the only truly feasible next step for increased storage would be to increase the sector pointers to 16 bit, which would allow 64K each but at the cost of complexity.
Which CLI? If you are talking about the one on Zeal 8-bit Computer, it's running its own Z80 operating system which has its own CLI. The display is done through VGA thanks to the video board (powered by an FPGA).
I think I would have gone with using a FRAM as the storage device. You can get them up to 2megabytes but at $5.00US it is more like 200K. I would also have made the empty space a linked list of its own. This would save some space. If the links were 2 bytes, you could handle up to about 16 meg file systems.
Thanks for your comment! I love the fact that FRAMs are just regular RAM, very easy to write and read to/from. I planned to use an FRAM on the board, in my first videos, you could even see the empty FRAM spot on the PCB. I encountered on major issue: there are no brand new 5V FRAMs in DIP/PLCC format, both parallel and I2C interface.The brand new FRAM are all in SMD format. Out of curiosity, which 200KB FRAM costs $5? The ones I have found on Mouser are more like 256kbits (32KB) for $5. So FRAM that supports 5V is bigger than that. The 2MB ones support at most 3.3V
@@kensmith5694 It's not hard, but it costs a lot of I/Os. I have 8 GPIOs dedicated to the system: 1 for keyboard, 2 for UART, 3 for I2C, 2 for input video signals. If I want SPI, I need at least 4 pins. Moreover, on my board I also have an I2C RTC chip, I don't need to use more GPIOs for it. Finally, bit-banging is slow on my Z80, I reach I2C standard speed, 100KHz, but if I had to manage for pins, for SPI, the speed would get lower than that, around 80KHz I would say. As you can see, SPI is not the best choice in my case.
Maybe. If you have a handwritten Z80 implementation of a FAT file system (FAT12/FAT16) that is "compatible", simpler than mine, and takes around 1KB once compiled, please send it to me, I would be very happy to integrate it inside Zeal 8-bit OS.
![Interfacing a CompactFlash on homebrew 8-bit computer! [Zeal 8-bit Computer]](http://i.ytimg.com/vi/B_ADYc3EVzc/mqdefault.jpg)
![Interfacing a CompactFlash on homebrew 8-bit computer! [Zeal 8-bit Computer]](/img/tr.png)
Very interesting! Rather than using the first byte of each page as a link to the next, you could use a page as a link map - each byte represents a page and it’s content is the number of the next byte in the chain. Firstly this would allow file pages to use the full 256 bytes (better alignment with data in RAM) and secondly the page map would double as an allocation map; an entry of zero indicates the end of a file chain as before, no need for the bitmap in the header.
Also, a single 256-byte page map is faster to navigate and easier to cache in RAM than following the chain all across the 64K disk space
That's really promising. I like the way you're going with this.
Thank you for your comment!
I'll continue until Zeal 8-bit Computer and its OS are fully functional😄
wow, can't believe that Zeal 8-bit computer is ready to buy. The board seems to be so well hand-soudered. I would like to order one and try ZealFS!😊🎉
Thank for your support! I hope you like it, I did put a lot of efforts 😄
@@Zeal8bit now make it run gta 1 from 1993
@@bulldog8080 GTA 1 never ran on 8bit computers and won't
@@cockatoofan with a few changes it will
I think
That's a nice simple file system. And it looks like it is really easy to recover data from a corrupted disc. Great work
Thank you very much! Indeed, it is easy to recover deleted files or directories, it can even be done with a hex editor by hand.
Great work. I'm enjoying all of these retro z80 projects and already embarked on making a very simple z80 game console project, with my 8 year old son, called the 'pip80'. Very inspiring .. thank you 👏
Thank you for your support!
I find that these retro projects are very good for learning our computers work and mainly to learn assembly. Is pip80 something you came up with?
Just discovered your channel.Watched several previous episodes. Awesome job on whole system! A few years from now, I would like to conduct some computer science experiments on the process of system and software creation. I would like to explore the choices made in the early decades of 8 bit systems, and see what could have been done to exercise more wisdom in making use of previous generations of hardware technology. The goal would be the creation of an index of thousands of standardized software components that would make bug free system and application creation easier for makers who do not have PhD level programming skills. I am thinking of the world of amateur built aircraft. There is a sophisticated system of education, training, standards, specifications, blueprints, fasteners, components, tools, and techniques that have been developed to insure the success of the owner/builder/pilot.
Thanks for your comment! That sounds like a very cool and interesting project, if you start doing it, give us some pointers so that we can follow your progress!
I just bought mine! I can't wait! I'm extremely excited for your OS!
Thank you very much for your support!!
The OS is getting more and more mature, I just published two softwares for it: a text editor and an assembler!😄
Very cool and extremely clearly presented! Thank you
Thank you very much for your comment!
I believe was better to use allocation table like fat does but one byte instead of 12bits, 16bits or 32bit, you can use 0x00 as marker for empty block, pointing to itself if block is used and file is smaller than a block, and point to next block if file continue with another block.
Or 0xFF as empty block, 0x00 as single block file, and from 0x01 to 0xFE that point to page 0x00 to 0xFD, page 0 being used by FS descriptor, and page 1 as allocation table, this version will make it easier in case of SPI FLASH memory in case of single page files and directories.
And you don't need a dedicated table of empty block to count free space, you count the allocation table with value as 0 you can read entire allocation table and count realtime EEPROMS and FLASH support delayed read.
I propose that because this way you avoid dividing the file size by 255 for seek but you can use divide by 256 or >> 8 to get the page from seek byte and you can add a backup allocation table for example with a check sum in the FS header for both allocation tables.
Outstanding work! Thank you for your efforts. All good wishes.
Thank you very much for your support!
Z80 were first home kit computers in the 80s where you had to soldier all the parts to a motherboard. The OS of the day was CPM.. So it already had an OS. The even supported disk drives. The first ones being single sided/single density 8" floppy
I find CP/M igreat but limited for a modern 8-bit computer. For example, it doesn't support directories nor multiple filesystems. It did inspire me for Zeal 8-bit OS though 😉
If you stored the linked list in a FAT instead of in the file data pages you could remove the directory size limitation
Thanks for your comment!
It is possible indeed to use a FAT to store the "linked-list" of pages used by a file/directory. However, keep in mind that I have to implement it in Z80 assembly by hand! Using a FAT would not only add several more reads/writes to different locations on the EEPROM, but also lift some restrictions that would make the code slower. For example, the number of entries per directory, today, it's limited to 8, so it is easy to browse through a single directory, if I use a FAT instead, I would need to perform a supplementary read and check every time I reach 8+ entries while reading a directory. Moreover, when using an I2C EEPROM, you really want to reduce the number of transactions that you make on the bus because it is slow (100KHz in my case). So you want to read more data that are contiguous.
All these changes sounds light and easy to make in C, it is not the same thing in assembly. But I don't exclude the possibility of having a FAT in future versions 😄
@@Zeal8bit That makes sense. Different trade-offs make sense with such a restricted environment.
I liked this idea! I think you should keep it as simplistic as possible, after all you can have multiple filesystems, so having a really simple baseline one would be a good start. The only thing I wasn't mad keen to see was stuff that was reserved. I'm assuming that was just the way the memory boundary turned out tho? Looking very nice. Eight folders should be more than enough for anyone! ;)
Thanks for your comment! I agree with you, this is what I am trying to do here, keep it simple even if not optimized. Plus a small change in the FS may imply significant changes in the ASM code.
The reserved area I talk about in the video is more of a padding, so keep the entries/elements aligned on a value that makes it easier for me to handle. For example, having a 28 bytes entry doesn't really make sense, it makes entry offset calculations more complicated on the Z80 and doesn't give me any benefit. That's why there is a 4-byte "reserved" area that will in fact be ignored and used as padding
Its crazy that you build all that from Scratch! I appreciate your work :D
Glad you enjoy it!
Good for what it is. I suspect that the size limitation will come back to bite you sooner or later. Storage is cheap nowadays. I'm thinking here about easy to drive & use formats like Compact Flash.
I wonder how big the Z80 assembler is for the CP/M 2.2 disk format? You might be able to find an extant implementation that just requires a bit of porting work. This would give you a common format with so many other Z80 systems.
Thanks for your comment!
Indeed, the size limitation is a drawback, but it makes the implementation much simpler and smaller. In fact, I plan to also have FAT16 in the future, as Zeal 8-bit Computer video board will have a micro SD slot. As such, CF cards will also be able to use FAT16.
If I recall correctly, CP/M disk format doesn't have directories nor timestamps, which is quite limiting.
Great implemetation !! nice job !!
Thank you fixou for your support!😉
That is fantastic!
protogens go beep boop
*boops Zilog on the beep*
@@elphive42 Beepity boop! ^~^
Very nice. How will you handle file fragmentation? Or is this not an issue on EPROM? Also, can the Zeal run SymbOS?
Thank you for your comment! Fragmentation at which level? The only fragmentation is the fact that files are divided into 256-byte pages. At the I2C EEPROM level, there shouldn't be any further fragmentation as the hardware pages are smaller than that (32 or 64 bytes).
In theory yes, It can, as it has 512KB of RAM, 256KB of ROM, VGA output, and a PS/2 keyboard input. But I haven't tried porting it, it is closed source if I am not mistaken. I am concentrating on Zeal 8-bit OS kernel.
@@Zeal8bit I think I have a far more basic understanding of file systems than you do! I remember back in the days of MS-DOS, running a defrag and watching as each file's parts were moved so it was as sequential as possible to avoid the OS from having to look at various parts of the disk every time it was accessed. I understand that this isn't really an issue with solid state media, so is that the same situation with EPROMs?
I didn't realise that SymbOS wasn't open sourced - that seems like a mistake on their part. I've been looking to build an 8 bit computer that is compatible with SymbOS for a while, so perhaps I will go down the "make your own MSX" route.
I completely understand you focusing on your own OS, though. It seems to be coming along nicely, and I appreciate that you are taking the time to document each stage, even if I don't always fully understand it! 😉
Defragmentation was mainly required because on hard disks, there was a mechanical head that moved around to read the sectors that contained data. By moving file's chunk to make them contiguous, you reduces to physical distance between the chunks of data. On SSDs, Flashes, ROM, EEPROM (etc...), this problem doesn't exist because there is no mechanical head, retrieving the data take the same time, regardless of its address.
Thank you for your support! Ifyou have question about the OS or the project you can ask or even join the discord, we often discuss about other 8-bit computers.
Maybe your 8-bit computer can be compatible with Zeal 8-bit OS😄😄
The current hardware leaves out the VGA covered in previous videos. Is the plan to release the VGA separately? Are you going to make a board that has both? I would love to buy this, but don't want to purchase this now if a combined VGA version is coming soon.
Thanks for your comment! Indeed, I plan to release the VGA board separately. At the moment, I don't have any plan to release a board that has both the video board and the motherboard, as the motherboard is only using THT component while the video board has SMD components.
It is true that I haven't talked a lot about the VGA board recently, it's because I was concentrating on the software. Once I'll reach a stable point on the OS (provide APIs for writing text software, include an editor or an assembler) , I will resume my work on the FPGA.
Cool! :) And perhaps just right for such a small storage device. 16-byte filenames is a luxury. :) Is it helpful with Chinese characters?
There is only 1 thing I don't like: If I used it, the limited number of directory entries would confuse me. It would be difficult when making a new file unexpectedly fails because I wasn't watching the number of entries. I was would have to move a file to a different directory to make space, create the dubdirectory, move the previously-moved file into the subdirectory and update any references to it, create my new file in the new subdirectory, and finally update any references i had made to the file I planned to create. (Often, I make a reference to a file before creating it.) Having written it down, I see it's really too much for me to work with.
Here's a proposal for large directories: Make them linked lists just as files are. To create space for the link byte, remove one of the reserved bytes from each entry, making them 31 bytes long. That gives us more space than we need but that's no bad thing; we weren't using the reserved bytes. The root directory can also have a linking byte. As the entries are shorter, we can also cut into the 28 reserved bytes so we can have a 7th entry in the header.
Sorry for the late reply, indeed 16-byte can be helpful for Chinese characters, if we use a 2-byte encoding for each character, we would be able to have 8 characters per name, which is more than enough in Chinese Mandarin.
I understand that the entries count limit is a problem, in fact, as it was suggested to me, it would be easier to have a FAT, a 256-byte table where the value at index i represents the next page of entry i, in code it would give something like `next_i = fat[i]`. As such, we wouldn't have any limitation on directories or files, it would also simplify the way entries are browsed. This is something I would like to implement in a future version.
@@Zeal8bit Interesting! I admit I've never properly learned about FAT filesystems. The last time I looked at them was in the 90s when I understood much less in general. It's really interesting to hear they can be even easier than your simple filesystem.
If I integrate a FAT that can fit in a single 256-byte page, it will become simpler and lift dome restrictions.
FAT12/16/32 use the same concept (well their name is taken from that), but they are a bit more complex.
Great work, man you are genius! btw, how could i miss the new board?? :O
Haha thanks for your comment, I am only motivated to work on this project I would say 😄
I haven't publicly presented the latest prototypes after the "Latest prototype of my 8-bit computer [Zeal 8-bit computer]" video, because now the changes are minor. I still add the new ones to my website however, so you might want to check the website. (zeal8bit.com)
You could probably have infinite directories entries, if you allow a directory entry to be a 'continued' directory. Such a directory would be the same as a link to another directory, but it has a flag of some sort set (or you could indicate it by making the name all zero-bytes) to indicate that instead, the content of the linked directory entry should be 'appended' to the current directory.
It's a pleasure to see you here!
This is a very good idea in fact, it would flatten a sub-directory with its parent at the expense of a single entry.
The only complexity I see here would be that we would need to manually move up the sub-directory's entries to the parent when removing entries in the parent.
@@Zeal8bit Hi, your video inspired me. I also need a retro FS that can accomodate several block sizes for different devices. I have an implementation working in C on linux with FUSE, it is very similar to yours but I added some important improvements. I am finishing documentation and will be publishing it soon. I have directories working, I am able to extend a directory block to another one. When deleting a directory, you can just zeroize the dir entry and skip over it when enumerating. You can also do optimizations, like replacing the deleted entry with the last one and erasing the last one, this makes it easier to shrink directories. I'll write again when you can read the spec.
I like the way you explain the File system,although I am not sure fully understand all the content. What is little endian?
It's the order that multiple-byte data is stored. So if you have to store a 16bit number you could store it low then high or high then low. Little endian is low-then-high
So cool
Thank you!
You could slightly modify ZealFS to use 16 bit page numbers, for 16MB volume
A small change for the FS, a big change for the implementation 😄
Wow, that’s a lot of dedication to get just 64KB of storage properly organized (sounds like something I would do). But the max volume size of 64K does make this mostly useless for all of my 8-bit computer projects, which always use SPI Flash ROMs in the 128K - 64MB range. Any chance this limit can be upgraded in the future?
Haha, yes it's a lot of dedication. I have been thinking about having page numbers to be 16-bit. But this adds a lot of complexity to the Z80 code and a bigger overhead for smaller chips. One possibility would be to keep the exact same structure but each page would be 64KB but of course that would only work on big ROMs.
Maybe for 8MB and above FAT12/16 is better?
Cool but the name zfs already exists, may cause confusion
Naming things has always been a problem in computer science, I will try to look for something else😄
You could call it ZZ80, or Z8FS.
@@elphive42 I like Z8FS! It follows the same pattern as Zeal 8-bit Computer/Zeal 8-bit Bootloader/Zeal 8-bit OS
wow, awesome! but sad that you don't send to Belarus :(
Any thoughts on adding an 8bit checksum byte to the directory entry?
That's a very good idea, not very hard to implement too!
It just requires more code to maintain the checksum, with no real use. If the code corrupts the directory entries, there are fundamental coding problems that need to be solved.
Nice job, but why an 8 leg IC for storage, rather than say an SD card etc.
Thanks your your comment!
There are several reasons that lead me to choose an 8-pin IC for the mother board:
- I don't have any I2C or SPI hardware IP. I am using GPIO bit-banging to simulate I2C. I can currently reach around 100KHz using this method
- If I had to implement SPI, it would be even slower because I would need to manage more GPIO pins.
- I also have an RTC on the board that is using I2C, so I can use the same pins to manage both devices. If I was using SPI, I would need 1 pin per device (CS), plus the shared pins: CLK, MISO, MOSI. I don't have any spare GPIO pin at the moment.
- SD card protocol is more complex than I2C EEPROMs protocol.
However, if you noticed, there is a microSD port on the video board (right one), so I do plan to add SD support to the board, but as an extension. The Z80 will "simply" read and write bytes to the FPGA. The latter will perform the transactions.
@@Zeal8bit While I cannot directly comment, I've seen them so often used in similar projects elsewhere that I took it to be fairly simple
interesting...
Thanks!
Wouldn't things be MUCH easier with an eZ80 processor these days?
It would! The ez80 is also much faster (in ADL mode at least) but it is not available in DIP nor PLCC package unfortunately. The goal of my project is to make an educational board with easy-to-replace components. Soldering an ez80 is way harder than soldering a PLCC or DIP socket.
Moreover, the ez80 is more an MCU as it has peripherals, if something goes wrong internally (UART for example), you have to replace the whole chip.
@@Zeal8bit I would call it an MCU. There are models with RAM and/or flash, even. However, unlike many (most?) MCUs available these days, it also has an external address and data bus for interfacing directly with external RAM as any standard MPU would.
Now… can you make an SSH client that runs within the 64K confines.
That's doable, or even simpler: an FTP client. In both cases, I need to make a Wifi extension board for it 😄
I think that the name "ZFS" is already taken...
It's "ZealFS", not "ZFS", because the computer is called Zeal 8-bit Computer but I understand the confusion, it's very close to the ear indeed. I will try to find something else
I was extremely interested until I realized it''s Linux only. The 64KB disk size limit doesn't help much either.
On which OS would you like to use it?
I realize 64KB is not a lot, but supporting bigger sizes makes the assembly code more complex and bigger.
Moreover, for bigger sizes (4MB+), ZealFS may not be the best choice
@@Zeal8bit I am a Windows user, like I imagine many people are here.
I realize that the only truly feasible next step for increased storage would be to increase the sector pointers to 16 bit, which would allow 64K each but at the cost of complexity.
You can name this with this(sorry for my English i am Italian): Z-FS
It is possible but sounds similar to the already existing ZFS filesystems 🙁
Ok
did you use curses library for cli?
Which CLI? If you are talking about the one on Zeal 8-bit Computer, it's running its own Z80 operating system which has its own CLI. The display is done through VGA thanks to the video board (powered by an FPGA).
@@Zeal8bit awosm i was talking about z80 one thanks.
I had a z80 cpu too didnt catch gime to gothrough it
0:10 In what way is that a "motherboard"? What daughter boards are there?
The video board is a daughter that can be plugged in the dedicated connector. Similarly the extension port lets us connect any complementarity board.
I think I would have gone with using a FRAM as the storage device. You can get them up to 2megabytes but at $5.00US it is more like 200K.
I would also have made the empty space a linked list of its own. This would save some space.
If the links were 2 bytes, you could handle up to about 16 meg file systems.
Thanks for your comment!
I love the fact that FRAMs are just regular RAM, very easy to write and read to/from. I planned to use an FRAM on the board, in my first videos, you could even see the empty FRAM spot on the PCB. I encountered on major issue: there are no brand new 5V FRAMs in DIP/PLCC format, both parallel and I2C interface.The brand new FRAM are all in SMD format.
Out of curiosity, which 200KB FRAM costs $5? The ones I have found on Mouser are more like 256kbits (32KB) for $5.
So FRAM that supports 5V is bigger than that. The 2MB ones support at most 3.3V
@@Zeal8bit Take a look at
digikey
FM25V20A-PG-ND
I wasn''t thinking of 5V operation
This is a 2Mbit FRAM, not 2MBytes, which is still pretty good actually. But it supports at most 3.6V, and uses SPI, not I2C.
@@Zeal8bit BTW: Bit bashing SPI is not hard at all
@@kensmith5694 It's not hard, but it costs a lot of I/Os. I have 8 GPIOs dedicated to the system: 1 for keyboard, 2 for UART, 3 for I2C, 2 for input video signals. If I want SPI, I need at least 4 pins. Moreover, on my board I also have an I2C RTC chip, I don't need to use more GPIOs for it. Finally, bit-banging is slow on my Z80, I reach I2C standard speed, 100KHz, but if I had to manage for pins, for SPI, the speed would get lower than that, around 80KHz I would say.
As you can see, SPI is not the best choice in my case.
Can it run TempleOS?
TempleOS is an x86_64 (64-bit) OS, so no it can't
@@Zeal8bit Little cringe aignt it, you'll have to port it...
Pleeease call it ZFS as in Zeal FS. xD
ZFS is already taken (used to be "Zettabyte File System") 😆
Suddenly some letters disappeared in 10:35. When you rm file
This is due to the FPGA connection. I will get to these graphical issues once I resume my work on the FPGA
So you created a FAT filesystem but made it extra complicated and inkompatible.
Maybe. If you have a handwritten Z80 implementation of a FAT file system (FAT12/FAT16) that is "compatible", simpler than mine, and takes around 1KB once compiled, please send it to me, I would be very happy to integrate it inside Zeal 8-bit OS.