Jump to content
IGNORED

Geneve MDOS New Call


9640News

Recommended Posts

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

 

 

 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

  • 3 years later...
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

  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...