4Andy

I also know at least one other guy with a Geneve and an SGCPU with a EVPC who will never see this post.

Yes, Scramble didn't work, I think it just hung. Unfortunately I can't re-test at the moment, as I changed my monitor and need to build a new cable. :-/

Oh, it looks like you've already tried it and it doesn't work. It was Multi Disk Commander http://atariage.com/forums/topic/233609-i-have-a-question-for-corcomp-rtc-owners-that-use-4a-dos-if-any/

There's already an XTree type program for 80 column cards. I think it was written by Oliver Arnold of TI-Club ERRORFREE (in Germany). http://www.errorfree.de/index-e.html . I seem to remember it was quite large though, and written in C99. If you want it and can't find it, I will probably be able to dig it out.

I understand. I was trying to create something for standard XB that may or may not have 32K available. I'll be able to use it for my own progs though, so thanks again for this.

Thank you, again. :-) I guess my ASM progs will be ok, but my XB ones will have to use context, even if it may not be 100% accurate. It's frustrating.

Pants. That's disappointing. Cheers guys, but if any of you have any flashes of inspiration, please let me know!

Hi, sorry for the delay. Thank you for all your responses and for taking the time to respond with such detailed suggestions. I don't think I asked my question clearly enough, but Casey is correct. I am trying to get as much information as possible about the I/O error, which I've already trapped (with ON ERROR), so that the program can give remedial advice. I don't think it's enough for the program to say "I/O error", as it could mean anything. I know 130 and 70 are the same error, but the 70 version has more information that I could use to improve the error handling and advice greatly. Presumably the VDP Stack that RXB refers to, is in VDP ( :-) ) and I'd also forgotten that the standard Extended Basic doesn't have POKEV and PEEKV, so I can't get at that from Extended Basic without Assembly as indicated above and I'm trying to keep the error handling Assembly free. :-/ . Is the FAC that RXB refers to the same FAC in the PAD? Although, it's unlikely that value will still be available by the time my code is executed, due to re-use. Is there something in PAD, that I can use with CALL PEEK()? I've looked at the content following an error in Classic99 and cannot see anything, but that doesn't mean that nothing is there, as I don't know it well enough to know what I'm looking for.

Hi, does anyone know if it is possible to get the same Error Code that the Command Mode issues for an I/O error, but from within an Extended Basic program? There seems to be two error codes returned for the same thing, depending on whether you are in Command Mode or Run Mode. For example: DELETE "XXXX.XXXX" if you execute the above in Run Mode, CALL ERR() returns: error = 130, file = 0, and whichever line number that the statement occurred in. However, if you execute the same command in Command Mode, you get a potentially more useful code of 70. 7 = error in DELETE routine, 0 = BAD DEVICE NAME. Is there some method of retrieving this code, for example is there a reliable location I can peek? I'm happy to use PEEKV, but I want to avoid an Assembly routine if possible as I want this to be Assembly free. I am trying to write some decent error handling where the messages are clear and helpful and any unhandled errors will allow a data save, so that no data is lost. Finding out if a Save failed due to the disk just being write protected would be more helpful than just displaying "I/O ERROR, GUV'NOR". Failing that, I will have to use precious RAM to set up some variables to define context, but it still doesn't help with the Write Protection issue. :-/ Andy.

Speeding up the p-System would definitely make me use it more. I like the editor and convenience of the OS, but probably only you can determine if it would be worthwhile typing in the code again. OCR software is a lot more reliable these days, than it used to be.

Many thanks. :-)

Yes, please. :-) Cheers! I'll give it a go too!

A99EXE, seems like a no-go, then, if it's difficult to obtain. Tursi - from your video, gcc looks like a hassle, but I'll bear it in mind if I ever want to develop on the TI in C. I'm going to give xas99 a try as I'd forgotten I already have Python installed for Reaper. Thanks again all.

Hi guys, thanks for your replies and I'm sorry for the delay, I was getting some 'easy to communicate' examples together. The version I am using is V3.010. The first bug is only a small one, and that is that the "-" prefix on TEXT opcodes, which negates the last character is not supported. I was using that in my TI code to detect the end of string, but I can deal with that issue. The one that is causing me a major issue is that some addresses become Absolute when they should be Relative. I'm a firm believer in one version of the source code and executable that'll run anywhere, so I am working on code that is in a Relocatable Program Image format, for want of a better term. The code detects where it's running from (nothing new there) and all BL's and BLWP's use an offset register that contains the LOAD address of the program segment and this is used to access a bunch of core routines and all program segments can be paged into / from VDP when required (especially on 9938/58) to maximise the 32K or 4K (if running from MM). That's all working, but just to be awkward, I also want to be able to use exactly the same source code contained in my standard routine libraries without modification in a more traditional way for other programs that don't need the dynamically relocatable shenanigans. When I started this I thought I would just use labels and use their offset from the beginning of the program and when I wanted to use them in a more traditional way I would just make sure the value used to calculate the offset from the beginning would be zero. I discovered that this worked on the original TI Assembler, but didn't work in WinAsm99. I'm using Classic99 for most of the development, so I need to assemble on the PC. The following code shows basic examples of the approach and the second exhibits the problem. Example 1) When used as Relocatable. (BASE is defined at the beginning of the source code of the program segment. Each segment is assembled as an individual program (which cuts assembly time on the TI). ME is obviously just a register that contains the LOAD address of the program segment and the code can be moved around in memory, as long as ME is adjusted) ** main program BASE ... ** Get LOAD address here and place in ME register BL @STARTP(ME) ... ** routine contained in source file library STARTP EQU $-BASE ... RT Example 2) When used in the more traditional way of TI Assembler coding. (BASE is set to zero and as long as STARTP is a Relative address will be adjusted when it is loaded by the Object Loader.) ** main program BASE EQU 0 ... BL @STARTP ... ** routine contained in source file library STARTP EQU $-BASE ... RT In example 2, STARTP is flagged as a Relative address in the original TI assembler (correctly, in my mind) but flagged as an Absolute address in WinAsm99, so when the program loads, the machine code copy of BL @STARTP contains a destination that just consists of the offset, and so is not being correctly resolved by the Object Loader by adjusting it to the location it is loaded into, i.e. it becomes BL @>00FE, instead of BL @>A0FE.

Thanks! I found that earlier, but I was put off by the Python requirement, but I'll try it out. Are there any others, so I can weigh up the pro's and con's?