+9640News Posted November 25, 2018 Share Posted November 25, 2018 Tim, Got a few questions. 1. What did Tony's Geneve 1.00 eprom code do with respect to the SCSI card? Will 0.98 code (not sure if that is what I have), locate LOAD/SYS on the DSK1 subdirectory of the SCSI controller and load MDOS? 2. What kind of space do you have left in the CLI memory range for new code? I suspect very little. Can it handle a new command ("TI") and parse with a command line option with a call to a UTIL library routine? 3. What kind of space do you have in the memory mapped range that holds the UTIL library? What I am looking at doing, is replacing the Swan/RSBug code with the EXEC code. Then, from the command prompt, one would type "TI MYWORD" and it would parse the option, and filepath, then a subsequent call to a new library routine would move from pages >F0 and >F1 in the Eprom the EXEC code to two available ram pages. Might not need the parse code in the CLI as I would have to follow if the code moved from the Eprom can pick it up. I've not verified, but I am assuming the EXEC code can not be run from ROM on the Eprom. I have around 13,900 bytes I can use that could also be loaded with something other EXEC, however, that is the one program I think most people would use. Beery Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted November 25, 2018 Share Posted November 25, 2018 According to the notes that I got from Tony when he sent me the EPROM .bin file, it adds a menu and allows for loading from a SCSI device. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 25, 2018 Share Posted November 25, 2018 Space is at quite a premium in the CLI. I would suggest considering an alternative: determine what would be required to modify the MDOS task loader to detect the TI program image header and if found launch the EXEC code. The routine would need to disable itself if EXEC wasn't found in the EPROM or invoke EXEC as if the user typed it manually. I would not be opposed to allowing an 8k page of RAM to be reserved for EXEC at OS startup, like a TSR (and similar to Tony's GPL routine) in place of the EPROM. Keep in mind that some of the memory management routines are also in premium space. geneve EPROM 0.98 boots only from the three standard floppy controllers, the Myarc HFDc, and the Horizon RAMdisk. Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 25, 2018 Author Share Posted November 25, 2018 OK, let me flesh this out with you Tim to see if it is possible. My first thought is to try and not use any additional RAM further limiting available memory after booting. Let's say we add a new XOP in the task header pages and page >00 if it detects a specific Eprom version. The new XOP maps in code from the Eprom pages of >F0 and >F1 when called. The Util Library Load Task opcode is opcode 9. We have "dummy" opcodes from >00 to >08 with >09 "identical" in the new XOP as the Util equivalent of XOP opcode >09 except looking for a TI-99/4A program image file. The thought here is if one XOP Library call fails, then test against the other XOP library before finally aborting. Maybe just a couple of instructions in the CLI. The big question here is how many bytes are available in the CLI that can be used. I know you said premium. One time, I thought I remember there may have been 20(?) bytes. If we are in single digits of available bytes, there may not be the space to clear the error code and test against the new opcode. I already have the basis of a TSR written so testing with the actual eprom modification can come later. The big question is identifying where access can be coded without consuming additional RAM memory pages for MDOS. Beery 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 27, 2018 Share Posted November 27, 2018 Sorry, I need a little more detail and 'fleshing out', specifically what you think would happen with memory pages and workspaces. I think I know where you are heading but can't give you an answer without a little more discussion. Quote Link to comment Share on other sites More sharing options...
+9640News Posted August 17, 2022 Author Share Posted August 17, 2022 On 11/25/2018 at 3:06 PM, 9640News said: OK, let me flesh this out with you Tim to see if it is possible. My first thought is to try and not use any additional RAM further limiting available memory after booting. Let's say we add a new XOP in the task header pages and page >00 if it detects a specific Eprom version. The new XOP maps in code from the Eprom pages of >F0 and >F1 when called. The Util Library Load Task opcode is opcode 9. We have "dummy" opcodes from >00 to >08 with >09 "identical" in the new XOP as the Util equivalent of XOP opcode >09 except looking for a TI-99/4A program image file. The thought here is if one XOP Library call fails, then test against the other XOP library before finally aborting. Maybe just a couple of instructions in the CLI. The big question here is how many bytes are available in the CLI that can be used. I know you said premium. One time, I thought I remember there may have been 20(?) bytes. If we are in single digits of available bytes, there may not be the space to clear the error code and test against the new opcode. I already have the basis of a TSR written so testing with the actual eprom modification can come later. The big question is identifying where access can be coded without consuming additional RAM memory pages for MDOS. Beery The topic of some TSR code I wrote almost 20 years ago for the Geneve came up in a discussion between @InsaneMultitasker and myself in the last couple of weeks. I pulled out my code and while the code still actually runs under MDOS 7.30, it should not be used in MDOS 7.30. The code installs a bit of code at the end of the last page of the Keyboard/Video XOP pages. The install code as written now overwrites one or two of the very last Video opcode routines. I haven't placed it out exactly, but the Get Tables (>0037> and the Get Pallette Register (>0038) opcode calls are all or partially overwritten. I think there is very little, if any use of these calls in any programs individuals may have written for MDOS so unlikely any program would be impacted, however, it is still not something that is preferred. I am investigating to see if there is any place within MDOS where a "hook" can be created, but not sure if it is possible. That hook needs to be captured and then processed in the 3 x 8K pages where the keyboard and video XOP's live. Right now, I think there are fewer than 40 bytes of memory left. Anyways, just wanted to post a note on the subject. Myself, I have been playing with some TSR code to do screen captures for potentially some kind of slide show file capture and display for presentation purposes. In the end, I would like to be able to have something that can be implemented without concern for corrupting any of the opcode calls. Beery 3 Quote Link to comment Share on other sites More sharing options...
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.