Good points Guus. So, I can count on you if want some PCB design ?
Doing some 150 KB code in ASM is actually not something that extremely large thing. Here I calculated with 196 KB ROM size of 1.04, where there are some font definitions, RSC data, what takes approx. 30-40 KB.
There are games with 100 or more KB pure ASM code. But that took really lot of time, and they did not it all at once - they used some old rutines, complete sections, maybe with smaller modifications.
I had long time ago some discussions at AF. Some C coders said that I will never be able to make FAT16 filesystem code in assembler. Yes, I was thinking about this about 10 years ago. Of course, all I can say is that it is bad idea to say to someone that will not be able to do something. You never know ... And I really don't know why they said it - because thought that I'm not good coder, or just thought that it is generally (practically) impossible.
Well, I done already some little longer ASM code - like HAGA, hard disk drivers, some video playback code - where it needed to be cycle accurate ... If I put all it together, I'm already over TOS 1.04 size
But that was made over 14 years.
Actually, I made FAT16 code in my Windows SW, Drive Imager http://atari.8bitchip.info/drimus.php
That's coded in C, of course - well not exactly for me. My C code is not exactly by rules, what they teach in schools. It is more like some ASM code in it structure, since I'm ASM coder. There is plenty of goto, for instance.
So, all it depends from available time, motivation, public interest for it. Doing FAT16 filesystem in 68000 ASM, and important is that it be as much possible compatible with existing TOS code - considering RAM usage - buffers, workspace, system variables ... Some of mentioned may take a lot of time if no proper and well commented C sources available. For instance, we have good description of main system variables for TOS (all versions). But other ones, mostly located in area $800-$Cxxx are TOS version specific. Same stays for TOS workspace. To have max. possible SW compatibility it should not use more workspace as original TOS versions - as main condition. That's not hard to achieve, but need special care to do it right.
Then, something what I certainly know better than most: hard disk driver support. It is little strange in TOS - like TOS (AHDI) BigDOS solution self is strange - hard disk driver SW needs to provide necessary buffer space for partitions larger than 32 KB, even it driver self doesn't need those buffers, FAT16 filesystem of TOS needs them (because solution with so called big sectors, instead 32-bit sector addressing) .
If I'd do same as EmuTOS team: making own hard disk driver solution, not compatible with what is in regular TOS versions, that would mean lot of compatibility problems. And that people who paid some commercial driver will be not able to use them.
I say that we need to assure compatibility level high as much it is possible. People wants to run old good SW in first place. And we are in era when floppies just becoming really problematic, together with drives ...