Gavin Smith wrote: I don't like option 1 at all, BDOS is excellent but if you start to make it incompatible with software, I don't think it will remain as popular :( Option 2 sounds better, but that doesn't mean that you will stop development of BDOS itself does it? (i.e. You aren't talking of abandoning the current DOS with the CDROM functionality in favour of the MSDOS one are you?)
No, I will stay programming on B-DOS with CD-ROM functionality. If I choice option 2, there will 2 dos programs: 1: B-DOS 1.6, which has SAM floppy/harddisk & CD-ROM support 2: MS-BDOS, which has SAM/MS-DOS floppy/harddisk support Umm was RGB that demo that was on Fred a while ago, that didn't work first time...so they produced a patch in the next issue, and that didn't work either? :) Or am I thinking of something completely different? The RGB demo on FRED is my demo. As something went wrong during the copy process of the FRED disk, the RGB demo was corrupted. So, I send a patch that fixed the problem. This patch should work, as I tested it myself!!! I'd better convert all my Speccy 128k demo conversions and SAM demos to .dsk files and send them to Andrew Collier's download site. Frode Tenneboe wrote: How about using overlays? Or DSO? Ie. have parts of the code as modules and use the remaining 300 bytes as a module swapper? The modules could reside anywhere in memory. Using overlays is a good idea, but what is DSO? (Dynamic software overlay or something?) Loading a module from harddisk is a better option than swapping between modules in memory, I think. Aufwiederschnietzel, Martijn Groen
