flashjazzcat Posted July 2, 2015 Share Posted July 2, 2015 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? So I was right about the chronology comment... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 2, 2015 Share Posted July 2, 2015 (edited) I guess it's working? It appears to work quite nicely (just converted a source file to ATASCII without using any switches). It would probably be best to use the ZCRNAME (crunch) routine to get the command line parameters, however, since the SDX kernel device names (A:, B:, etc) are not recognized at the moment. I assume you're parsing the raw content of the command line buffer. That's fine, but it's much easier (and backwards compatible) to use the method described in the SDX user manual, in the "Programming" section. Oops... just noticed tabs (ASCII $09) are completely filtered out as well. Maybe convert those to ATASCII $7F. Edited July 2, 2015 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 2, 2015 Share Posted July 2, 2015 Not. Flashjazzcat did put it online. The new bios for U1mb. That's really amazing! Yeah it looks really promising form the description. I'm going to "pop" it in my emulated U1MB today! Quote Link to comment Share on other sites More sharing options...
drac030 Posted July 2, 2015 Share Posted July 2, 2015 Here it does not work as expected, e.g. whatever I type at the command prompt: AAC X AAC.EXE AAC /H X AAC.EXE /H there is no response, the program just returns to DOS without doing anything visible (there is no difference whether I run it from the SC or from the CP, in 80- or 40-column mode). Having no further documentation, I cannot proceed. By the way, such a conversion utility would certainly be appreciated, even if it does not go to the Toolkit directly, we still have the Add-on section available on the main website, where third party programs are made available without necessity to disclose the source code by the author. So there are no objections as long as it is proved that the program works as expected. By the way, the ASCII->ATASCII conversion (but not the other way around) can also be made using the LESS.COM utility: LESS FOO.TXT >>BAR.TXT will convert ASCII text file FOO.TXT to ATASCII file BAR.TXT. This was done because of the (partial) support of the CP/M diskettes: using the CPMFS.SYS driver one can mount CP/M 2.2 disks under SDX and also view the *.TXT files there using LESS. The same applies to the FATFS.SYS and its disks, btw. 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 3, 2015 Share Posted July 3, 2015 (edited) It appears to work quite nicely (just converted a source file to ATASCII without using any switches). It would probably be best to use the ZCRNAME (crunch) routine to get the command line parameters, however, since the SDX kernel device names (A:, B:, etc) are not recognized at the moment. I assume you're parsing the raw content of the command line buffer. That's fine, but it's much easier (and backwards compatible) to use the method described in the SDX user manual, in the "Programming" section. Oops... just noticed tabs (ASCII $09) are completely filtered out as well. Maybe convert those to ATASCII $7F. Thanks FJC for your feedback. You are right I am doing my own parsing of the command line (LBUF). I actually did code up a way to use the ZCRNAME or "CRUNCH" routine in Action!, but wasn't happy with the way it worked. That's why I rolled my own. I planned to get some kind of improved hand-holding on the filename usage, and kept the option to return to ZCRNAME in the back of my mind. There are also newer ways I think that are specific to SDX. I was having a squizz (thank Dave Jones for that phrase) at the SDX programming manual and that's what prompted those questions you saw earlier egarding SDX symbols. The code I use to translate currently uses combinations of "IF" logic. I have already rewritten those functions to use lookup tables instead. The tables make the program larger, but would be less execution time. Since the program is not so large as to require scrounging space, and the translation logic is engaged for every byte of the file, I think the lookup tables are the way to go here. I over-looked tab. I will update my tables with that. Also, this current version does not use buffering. It reads, converts, and writes each byte immediately. Prior to this version I posted, I had coded up a buffering system which was much faster. However it was not working right. I kept going over and over the code and kept not seeing what the problems all were. I did find a couple which I fixed, but anyway I got into a stuck spot. I can have a go at that again after I get other stuff working well. Without buffering, this process would be hideous acting on a source and destination file on say the same physical (real) floppy disk, with a real read/write head. Anyway, I think I'll give this program its own topic so as not to put too much noise in this topic. It is related to SDX but separate. Edited July 3, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 3, 2015 Share Posted July 3, 2015 (edited) Here it does not work as expected, e.g. whatever I type at the command prompt: AAC X AAC.EXE AAC /H X AAC.EXE /H there is no response, the program just returns to DOS without doing anything visible (there is no difference whether I run it from the SC or from the CP, in 80- or 40-column mode). Having no further documentation, I cannot proceed. By the way, such a conversion utility would certainly be appreciated, even if it does not go to the Toolkit directly, we still have the Add-on section available on the main website, where third party programs are made available without necessity to disclose the source code by the author. So there are no objections as long as it is proved that the program works as expected. By the way, the ASCII->ATASCII conversion (but not the other way around) can also be made using the LESS.COM utility: LESS FOO.TXT >>BAR.TXT will convert ASCII text file FOO.TXT to ATASCII file BAR.TXT. This was done because of the (partial) support of the CP/M diskettes: using the CPMFS.SYS driver one can mount CP/M 2.2 disks under SDX and also view the *.TXT files there using LESS. The same applies to the FATFS.SYS and its disks, btw. Thanks for the feedback. I will look into that. Since I posted the program originally, I too ran into that once. I rebooted and it worked the next time. I have no idea why it would do that but I will try and see if I can figure anything out. I may need some guidance from some of you uber Atari programmers from time to time to get me on the right track to get this made into something handy and useful. I appreciate you checking it out. Thanks again for the feedback guys. Edited July 3, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 3, 2015 Share Posted July 3, 2015 DRACO30: By the way, such a conversion utility would certainly be appreciated, even if it does not go to the Toolkit directly, we still have the Add-on section available on the main website, where third party programs are made available without necessity to disclose the source code by the author. That's good to know. I do plan on making the source available down the road when it is in a more finished form. Heck, I might even put it a posting now and then before then if needed to assist anyone who is trying to help me fix bugs. Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 6, 2015 Share Posted July 6, 2015 (edited) Question: how large exactly is the COMFNAM buffer at COMTAB/DOSVEC + 33? The 4.47 User's Guide says 28 bytes, while the 4.47 Programmer's Guide says 30 bytes. Given the next COMTAB entry is at +63, I would guess it is the 30 bytes that the PG says. Edited July 6, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
trub Posted July 7, 2015 Share Posted July 7, 2015 It is 30 bytes indeed. The User's Guide mentiones 28 bytes for backward compatibility, however it should be corrected in the next revision. The two bytes at COMTAB+61 (referred as RUNLOC) were used by SpartaDos 3.x to store the run address of an executable started from the command processor. This has been dropped in SpartaDOS X, so the COMFNAM is now two bytes larger and joins LBUF (as stated in Programming Manual). 2 Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 9, 2015 Share Posted July 9, 2015 Update on the AAC program. See it here. Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 10, 2015 Share Posted July 10, 2015 I started thinking about this SD CL utility I'm making and that it compiles at an address that is based on my MEMLO. If it were run on another machine whose MEMLO was too much higher, I'm guessing that could be trouble. What is a generally safe address to compile at for the majority of SpartaDOS X users do you guys think? Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 10, 2015 Share Posted July 10, 2015 IMO, $2000 should be safe for most users. 1 Quote Link to comment Share on other sites More sharing options...
mono Posted July 10, 2015 Share Posted July 10, 2015 (edited) SDX has got own relocatable format. It is quite simple to use, so maybe you could simply try to make your program relocatable? In most cases you need replace two things: First - replace LSB/MSB addresses loaded immediately by ldx #<point ldy #>point as ldx pointad ldy pointad+1 ... pointad .word point and second thing to change is replace org $xxxx to blk reloc main In most cases there is all you need to do. Sparta DOS X will move all program blocks to MEMLO and fix automatically all absolute addresses and you don't need longer to take care of valid loading address od your code. Edit: After loading in runtime you have first free location afer your relocated code in MEMLO, so you can get it to load any data from file or stream. You can generate relocatable code with FAS (atari) and MADS (PC). Edited July 10, 2015 by mono 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 10, 2015 Share Posted July 10, 2015 SDX has got own relocatable format. It is quite simple to use, so maybe you could simply try to make your program relocatable? He could, were his program not written using the Action! language. In any case, $2000 is the magic number, as said above. Quote Link to comment Share on other sites More sharing options...
mono Posted July 10, 2015 Share Posted July 10, 2015 Of course I thought it's asm one. Sorry. Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 10, 2015 Share Posted July 10, 2015 Of course I thought it's asm one. Sorry. No apologies necessary! It was good to see the info you provided anyway. Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 10, 2015 Share Posted July 10, 2015 The MEMLO I have going for me these days is $134E. Strangely, Action! will choose $2597 as a origin on its own. As I'm working on this, I went ahead and forced the origin to $3000 just because I can and why not. Anyway, I have just a couple more features I want to incorporate yet before version 1.0. Anyone try out the latest test I posted, v0.92? Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 13, 2015 Share Posted July 13, 2015 Hey guys. I just posted my freshly minted version 1.0 of ASCII ATASCII Converter (AAC) over in this post. It seems to work reasonably well but I did run across one more bug I have not been able to figured out. It's doesn't seem to work right after SC (Sparta Commander) has been run. For example, if you just issue the command AAC, you are supposed to get a usage summary. Instead you just get another SpartaDOS command prompt. To work around, I noticed that if I enter BASIC, issue a GRAPHICS 0 command, then return to DOS, it works as expected again. Of course one can always issue a COLD command. But I would like to eliminate this bug if I can. The thing is, I don't know if the issue lies with Action! and/or my program, SDX 4.47. I'm emulating a VBXE and doing the 80 column mode. Note though, that the same problem comes up if I issue a CON 40, or a CLS /F. I even modified my program to issue a GRAPHICS 0 command near its start. No change, bug persists. I did not bother to package and post that new change in the program since it had no effect. What do you guys think? Quote Link to comment Share on other sites More sharing options...
fujidude Posted July 30, 2015 Share Posted July 30, 2015 Okay... version 1.1 of AAC is ready! Bug is fixed. You can get it over here. Quote Link to comment Share on other sites More sharing options...
fujidude Posted August 12, 2015 Share Posted August 12, 2015 (edited) Question: is the last parameter of this XIO command needed, since the device/file has already been set up via a previous OPEN command on the same IOCB channel? See XIO command description from the SDX 4.47 UG. 6.3.8 Get File Length Purpose Determine the length of the currently open file. SyntaxXIO 39,#IOCB,aux1,aux2,"Dd:"A=PEEK(844+IOCB*16)B=PEEK(845+IOCB*16)C=PEEK(846+IOCB*16)LNGTH=A+B*256+C*65536RemarksThis will return the length of the currently open file. IOCB, aux1, and aux2 should be thesame values used for the preceding opening of the file. If something is needed in the quoted last parameter, what exact format should it take? Edited August 12, 2015 by fujidude Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 12, 2015 Share Posted August 12, 2015 Yes, it is needed (required by CIO, not SDX itself). It should be simply "D:". Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted August 12, 2015 Share Posted August 12, 2015 Yes, it is needed (required by CIO, not SDX itself). It should be simply "D:".Actually, nothing in CIO requires this. If the channel is already open, the buffer pointer is something that the handler *may* require, but CIO itself does not. The handler lookup is at this time already done, and the handler index is already recorded in the IOCB, so it is not needed again. The only thing that requires a string argument here is BASIC. If the DOS does not require it, it can be an arbitrary string. Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 12, 2015 Share Posted August 12, 2015 That is right, if the channel is already open, the CIO does not lookup the device name. I overlooked that. So, the last parameter in case of this XIO is not required. Quote Link to comment Share on other sites More sharing options...
fujidude Posted August 12, 2015 Share Posted August 12, 2015 Thank you guys for clearing that up for me. Quote Link to comment Share on other sites More sharing options...
sanny Posted August 13, 2015 Share Posted August 13, 2015 Is the source code somewhere available? 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.