morelenmir Posted June 13, 2015 Share Posted June 13, 2015 I have discussed this idea in passing on several other threads, but I thought it might be worth mentioning here as an 'official' feature request. Is there any possibility of further work on the "FATFS.SYS" driver? The reason I ask is two fold. Firstly it would be extremely useful for the driver to be able to read FAT32. That way we would not need two separate partitions - a FAT16 'External' drive which makes copying files form the PC easier and also a FAT32 partition for the "SIDELoader". This I have discussed at length in another thread, but I think is worth briefly bringing it up again here. Secondly and I think more importantly; will it be possible at some point to make the driver R/W? This feature would be of absolutely colossal use to those with the "Ultimate1MB" and "SIDE2" combination. Were "FATFS.SYS" able to do this then it would be possible to use 'mkatr' to create drive images and save them directly to the FAT32 partition. In turn these *.ATR's could be mounted in the "Ultimate1MB" version of 'SIDELoader' to use as simulated floppy disks - all without leaving the Atari. In one go this feature would do away with the need for any other floppy emulator like SIO2SD, SIO2PC and the others. 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted June 13, 2015 Share Posted June 13, 2015 IIRC, there is a large RAM penalty with FAT32 buffers. It would be a very nice thing to have, even if you had to load FAT32 driver, copy your files, then unload driver or reboot to recover RAM. Any type of R/W solution is better than what we have now. 2 Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 13, 2015 Share Posted June 13, 2015 Ah yes, relocating code wouldn't have a fixed address. I never thought of the DOS code itself being relocating. I guess I always thought it was just device drivers and such that used that since it could vary which ones might be loaded. Learned something. I'll see about checking out the MADS dox as you suggest. Quote Link to comment Share on other sites More sharing options...
+David_P Posted June 13, 2015 Share Posted June 13, 2015 What sort of RAM footprint would the buffers require? SDX has the USE BANKED option; losing a few banks on a 256K (or greater) machine would not be crippling if it gave full FAT32 access, and easier sharing with a PC. Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 13, 2015 Share Posted June 13, 2015 (edited) This is not a question of buffers, the FATFS driver uses the same regular, 512-byte DOS buffers as the rest of the SDX. FAT32 is currently not possible as an SDX FS driver because of the way such drivers work: they make an on-the-fly translation of "their" file system to the native file system (SDFS) and vice versa. The problem is that the SDFS is only capable of addressing up to 65535 logical sectors, and a disk formatted in FAT32 is unlikely to fit within that limit. This is why the FATFS driver handles FAT16 instead. As for the write support, the only problem is my free time which I currently hardly have. @fujidude: the whole point of symbols is that the system routines/structures are not associated with fixed addresses. You use named symbols to reference them and these labels are appended at the end of the binary file produced by the assembler. They are "expanded" (= translated to the actual addresses) by the binary loader. It is not useful to know what is the address of, for instance, the PRINTF function, because this address may freely change from one SDX release to another; as FJC wrote, there are also some symbols defined by loadable system components and the values of these may depend on the order of loading things at startup. It is much better to leave this task to the loader. Edited June 13, 2015 by drac030 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 13, 2015 Share Posted June 13, 2015 @fujidude: the whole point of symbols is that the system routines/structures are not associated with fixed addresses. You use named symbols to reference them and these labels are appended at the end of the binary file produced by the assembler. They are "expanded" (= translated to the actual addresses) by the binary loader. It is not useful to know what is the address of, for instance, the PRINTF function, because this address may freely change from one SDX release to another; as FJC wrote, there are also some symbols defined by loadable system components and the values of these may depend on the order of loading things at startup. It is much better to leave this task to the loader. I get it. Relocatable code, or code that might be relocated with future releases, is incompatible with equates to fixed addresses. I did take a look at the MADS dox, but admittedly, it was of very limited use to me. On the A8, the bulk of any programming I do is with Action!, or perhaps a little bit of BASIC. I don't program a lot even then. I have a passing and marginal familiarity with 6502 assembly. I have only ever made one small routine in assembly and used it as a code block in Action!. Later I learned how to make Action perform the same task directly. Also any assembly stuff I have done was 25 years ago or more. Anyway, this is just a long winded way of saying some of that is presently over my head. If there were say, an Action! based code library for SDX, that would be much more understood by me, not to mention that it could probably used directly for a lot of stuff. I'm not complaining though. I'm just helping you know where I'm at. I appreciate all that has been done, and continues to be done. 1 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 13, 2015 Share Posted June 13, 2015 This is not a question of buffers, the FATFS driver uses the same regular, 512-byte DOS buffers as the rest of the SDX. FAT32 is currently not possible as an SDX FS driver because of the way such drivers work: they make an on-the-fly translation of "their" file system to the native file system (SDFS) and vice versa. The problem is that the SDFS is only capable of addressing up to 65535 logical sectors, and a disk formatted in FAT32 is unlikely to fit within that limit. This is why the FATFS driver handles FAT16 instead. As for the write support, the only problem is my free time which I currently hardly have. Is "FATFS.SYS" your work drac030? I did not realize! Even as it stands it provides an extremely useful function. Moreover, from what you are saying R\W may come in the future when you have a little time to spend on it. Which is totally cool - obviously, it goes without saying - and provides part of the solution. It would certainly be possible to use one FAT16 partition for both 'External' use and "SIDELoader' - although the lack of long file names is a painful compromise. If nothing else that scenario neatly sidesteps the Windows one-partition 'Removable' storage-device problem. I guess one long-term (!) solution is for the underlying SDX filesystem to evolve towards larger volume sizes, which if it ever comes I understand is far, far away and not something I am even remotely agitating for now. I have moved to a dedicated thread to discuss the potential future direction of 'SIDELoader' as that is not on-topic here. Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 15, 2015 Share Posted June 15, 2015 Is "FATFS.SYS" your work drac030? I did not realize! All new programs in SDX and Toolkit are signed by "DLT", so it is not known, who personally wrote this or that. But yes, I am the author of this one. Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 24, 2015 Share Posted June 24, 2015 I have a question regarding Symbols. I read the SpartaDOS X Programming Guide but can't seem to get a handle on how to use built in routines in my own programs. The nearest thing I found was this statement: A list of symbols attached to a program’s binary file is automatically translated to addresses, which in turn are automatically put into the proper places of a loaded program. What does that mean exactly? How are the symbols "attached" to the binary file? What is automatically put into the proper places of a loaded program, and what are the proper places? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 24, 2015 Share Posted June 24, 2015 (edited) The list of symbols is generated by the assembler in the update block, assuming the application is a relalocatable SDX binary (see MADS documentation). The DOS binary loader transparently takes care of fixups when loading a binary of this type. If you wish to access symbols from standard, non-relocatable applications, you need to make use of the relevant page seven kernel call, as previously mentioned. Edited June 24, 2015 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 25, 2015 Share Posted June 25, 2015 The list of symbols is generated by the assembler in the update block, assuming the application is a relalocatable SDX binary (see MADS documentation). The DOS binary loader transparently takes care of fixups when loading a binary of this type. If you wish to access symbols from standard, non-relocatable applications, you need to make use of the relevant page seven kernel call, as previously mentioned. I'm not using an assembler, and the application is not a relocatable SDX binary. I went back again and saw a brief mention of the page 7 kernel call for that, but what address in page 7 or how it works. I did look at the MADS dox (as well as SDX 4.47 dox), and don't remember seeing it. I'll go check again. Can I assume it is within the MADS documentation that I'll find it? I'm going to start with that. Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 25, 2015 Share Posted June 25, 2015 (edited) I think I found it. From the SDX Programming Guide: That procedure, labeled jfsymbol , was first introduced in SDX 4.40. The entry is located at $07EB. The input parameter is the address of a space-padded symbol name in AX registers (LSB/MSB, respectively). When the symbol is not found, the function returns a zero (Z=1), otherwise the AX registers contain the address, and the Y register – the memory index. CAUTION: after a program is started using X.COM, the symbol list and most of the objects registered on it become UNAVAILABLE. You still however can use jfsymbol to search for RAM structures such as the T_ table. Edited June 25, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 25, 2015 Share Posted June 25, 2015 I think understand everything that the programming guide says about the jfsymbol routine located at $7EB, with the exception of "the memory index" which is returned via the Y register. What is the index and why would you need to know it if you already have the address of the symbol you searched for? Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 25, 2015 Share Posted June 25, 2015 A mem index indicates the type of the memory the symbol points to: it may point to the main memory (index $00) or to the ext memory (index <> $00). What they are is described in the chapter 3, esp. section 3.6. Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 25, 2015 Share Posted June 25, 2015 A mem index indicates the type of the memory the symbol points to: it may point to the main memory (index $00) or to the ext memory (index <> $00). What they are is described in the chapter 3, esp. section 3.6. Thank you. That clarifies it. I did wonder about that. What confused me is that in section 1.2 there is a "control byte" which is associated with symbols (and indeed 2 bits of it deals with memory similar to the "memory index". Then in the SL.COM from the TK, each symbol is shown with a corresponding number labeled "magic." Unfortunately, the SL man page makes no mention of what "magic" is. Quote Link to comment Share on other sites More sharing options...
drac030 Posted June 25, 2015 Share Posted June 25, 2015 The SL.COM's "magic" is the raw value out of which the memory index returned by jfsymbol is calculated. That "magic" is equal to the "control byte" the Programming Guide speaks about. It consists of two bits memory index and six bits application number. This byte is divided by 64 to obtain the resulting memory index. That is how it technically works, but since the memory index is in fact now much bigger than it could fit in 2 bits, the symbol structure will probably change somehow in the future. That I hope is not a problem because programs do not need to deal with symbols in the form these have been physically defined. Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 25, 2015 Share Posted June 25, 2015 I can't speak for others who might make programs, but for me I don't have any major plans to develop anything that deals with extended memory. I'll be happy just to make things that work in conventional memory! So I guess as long as there is a zero for the memory area, I'll be happy. Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 1, 2015 Share Posted July 1, 2015 (edited) Hello everyone. I found myself wanting a utility to easily convert text files between ATASCII and ASCII (both DOS/Win and Unix variety). I couldn't seem to find what I wanted. I know Altirra can do it with a copy paste method, but I wanted something to act on files. To that end, I coded up a utility to get the job done. It is command line driven & intended for SpartaDOS X, but probably would work on older SpartaDOSs too. It's called AAC, for ATASCII ASCII Converter. Anyway, I'll attach an .ATR with the program. I would be grateful if some of you can try it out and see if it works for you (or not). I did some testing but I would like to see what happens with more testing. Keep in mind that there is no validity checking of user input or any kind of sophisticated error handling in this early version. That means it's up to you to provide valid device:filename parameters to the program. You can get info on how to you by simply typing this at the SDX command prompt: AAC /H (if you have COMEXE engaged) or X AAC.EXE /H (if you do not use COMEXE) If this works out I'll make a 1.0 version and perhaps, DLT might include it in the SDX Toolkit. Edited July 1, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 1, 2015 Share Posted July 1, 2015 I guess it's working? Quote Link to comment Share on other sites More sharing options...
Marius Posted July 1, 2015 Share Posted July 1, 2015 I guess it's working? At this moment I'm busy testing something that will revolutionary rock the atari 8bit scene. It will be soon a legendary moment. When that happened I'll test your software! Quote Link to comment Share on other sites More sharing options...
Tillek Posted July 2, 2015 Share Posted July 2, 2015 At this moment I'm busy testing something that will revolutionary rock the atari 8bit scene. It will be soon a legendary moment. When that happened I'll test your software! So how long do we have to wait? Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 2, 2015 Share Posted July 2, 2015 At this moment I'm busy testing something that will revolutionary rock the atari 8bit scene. It will be soon a legendary moment. When that happened I'll test your software! Thank you. You are under no obligation but it is appreciated. I threw that comment out there because sometimes silence means no problems cropped up. Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 2, 2015 Share Posted July 2, 2015 So how long do we have to wait? You're free to download it and try it out yourself immediately if you like! Quote Link to comment Share on other sites More sharing options...
Tillek Posted July 2, 2015 Share Posted July 2, 2015 You're free to download it and try it out yourself immediately if you like! Well, I'll be happy to... but my question was about ProWizard's revolutionary thing that will rock the 8-bit world.... Or am I confused that it's about two different things? Quote Link to comment Share on other sites More sharing options...
Marius Posted July 2, 2015 Share Posted July 2, 2015 So how long do we have to wait? Not. Flashjazzcat did put it online. The new bios for U1mb. That's really amazing! 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.