Jump to content
IGNORED

TIPI - Geneve 9640 to Raspberry PI interface development


9640News

Recommended Posts

Matt,

 

By this weekend, I will have a GenMod Geneve and Memex in hand, so I plan on doing some development with the TIPI-PEBox setup.

 

I have a program (MyTerm) I plan on modifying to use the TIPI instead of serial RS232 routines. Pretty much, I will be using the same routines I used for Mass Transfer, except it will be in a MDOS environment instead of a TI-99/4A environment. If I can implement TIPI, I should be able to implement color ANSI within the program.

 

My intent is to communicate with the TIPI DSR, but using a new XOP library. This way, I can avoid having the program map the DSR into the appropriate memory space of the running program. Rather, the XOP will be behind the scenes mapping memory pages and moving information without the running program doing the work. This will also serve to not having to move code, buffers, etc around in the existing program. This will also be useful for anyone else wanting to modify existing MDOS programs by calling a built in subroutine without having to move their code around as well if they have something in MDOS they want to tweak.

 

My question for you is this, Each XOP has their own powerup routine. Is there a powerup routine that is necessary to be run on the TIPI for any initialization purposes when the computer is turned on prior to programmed access from a running program of the TIPI DSR? If so, I just need to make sure I call it when the XOP is installed into MDOS.

 

My second question, I need to understand what the TIPI DSR may do outside of its >4000 to >5FFF DSR space. Is there anything written/modified/used/etc. in the TI-99/4A enviroment in the >8xxx memory range, or elsewhere? If so, I need to understand if there is anything written or read because within MDOS, this would be program space and I would not want code being corrupted, etc. Again, easy to control if written, maybe more of a challenge if the DSR reads any information thinking it was running with a TI-99/4A program.

 

At this point, there is no intention of any file access, rather just accessing a telnet connection and maybe mouse functions. Just trying to lay out the initial groundwork and go from there.

 

Beery

 

 

 

  • Like 3
Link to comment
Share on other sites

This is why the source code is available to you... It's a new era, not like the TI world you came up in... No closed IP... just open TIPI...

 

https://github.com/jedimatt42/tipi/tree/master/hardware/dsr

 

Nothing happens to TI memory space that isn't in the DSR code... The message routines are indexed in the header file. Where they write in the TI address space should just be up to the caller, but read the code and check my work.

 

The DSR ROM has a powerup routine, in the powerup file.

 

It is important for good user experience since the PI has a longer lifecycle than the client machine. You should be able to read that and determine what actually matters for your use case.

 

-M@

Link to comment
Share on other sites

Matt,

 

I've edited this message. Scratch the request. I used a DATA instruction instead of a BYTE instruction, and had an extra null character. I'm connecting now with an open connection so no issues.

 

Beery

Edited by BeeryMiller
  • Like 1
Link to comment
Share on other sites

Matt,

 

Just a FYI.

 

Got my XOP from MDOS to the point now where it is memory resident upon installation, and with three instructions from a calling program, opening up a connection to a URL no matter where in the 64K memory space the string is located. Next step, pass the status back then start on the Send/Receive message components.

 

When I get the TIPI XOP completed, I will release the source so if anyone else wants to update it, etc. it can be done.

 

Beery

  • Like 5
Link to comment
Share on other sites

There is another advantage to using the XOP's for existing programs.

 

With an existing program, I can in 3 or 4 lines of code send a character or receive a character without having to add all the other BLWP code that would be part of the program. A program that is up against tight memory constraints could delete a bunch of serial code handling and free up memory for other buffers, code, etc. For the MyTerm program, I am anticipating I may be able free up 1 or 2 K between all the code I am expecting to delete.

 

If it weren't for a TIPI_OPEN connection where a full string of text must be sent at once where one would want to have an Input routine for backspace, etc to establish a URL name, I am pretty sure the Geneve would allow a non-ANSI basic Telnet connection and program with less than one full page of source code. One could probably pass the URL on the command line and it would be very tight to get the whole client on one page of code.

 

With three lines of code on a Geneve, one can set any video mode. Another four lines of code with a pointer to a text string, one can write text to the screen in any text or graphics mode.

 

That's a lot of the power of the XOP's with the Geneve. That's why I like it.

 

Beery

  • Like 2
Link to comment
Share on other sites

Yes, exactly. The routines are saved on a memory page and the task that loaded the routines is put to sleep on the Geneve. Basically, a program with no time slices to run. The XOP in this case is Library "C" of the XOP table list with code mapped mapped into the >2000 to >3FFF boundary when called. When the XOP is called, page >00 (common for all XOP's) is mapped at >0000 to >1FFF, the TIPI XOP code at >2000 to >3FFF, and I am mapping page >BA into >4000 to >5FFF so I can access your DSR code for the communication. This is only for the MDOS side of things.

 

The XOP itself handles mapping the pages depending upon where a pointer and/or workspace may be located on the other memory pages. When the routine is done, a RTWP restores all the memory pages back to their original order.

 

On YahooGroups in the Geneve section, I have code that lays out a TSR I wrote about 15 years ago for someone that had made an inquiry how it could be done. My Windows XOP, and the GEME XOP, were a bit more complicated. I would have done things differently now as some of my coding skills have gotten better seeing other people's examples.

 

Right now, I have written the XOP as a single socket handle. With a bit of ingenuity, it would in principle be possible to a have a single program accessing two BBS's simultaneously with a split horizontal or vertical screen. BBS callers are so few, so even though it can be done, I really do not see any actual value for the time invested to make it happen.

 

Beery

  • Like 4
Link to comment
Share on other sites

Can existing XOP's be overridden by loading installing another XOP library?

 

Is it technically possible to override XOP 0 library 8 to intercept DISK IO, for use with extremely well behaved MDOS applications?

 

I don't see anything in 'GenREF' about installing XOP libraries.

 

I do see that Beery? or someone has at one time relocated these tables, so I imagine it is possible to find, overwrite, and chain to these system routines...

 

-M@

  • Like 1
Link to comment
Share on other sites

Yes, it is possible to override the XOP libraries, however one may need to be very careful with something like the DISK IO library. Not saying it can't be done, but it is possible. If the DISK IO library was going to be TIPI modified, not sure if you would want to go in a direction where you drop all floppy/MFM/SCSI code and replace with TIPI only code, or not.

 

GenREF never spoke about user installed libraries. That was something I figure out on my own back in the early 90's from a comment Paul Charlton made. Libraries 5 through 10 are spoken for as "built it" by the operating system. I'm using >0C library that is empty and available for use. If I recall correctly, Library 11 (windows library user installed), and the TIPI library (>0C) is where I am going with my work. Few people use the Library 11. I would have to look at the code, but I believe the Mouse Driver may have set itself up as a library, but not 100% sure. Again, not sure if anyone is using anything with the Mouse Driver anymore anyways. One could either install the Bus mouse driver, or the serial mouse driver. No reason one could not modify the code for a TIPI Bus mouse driver. I think libraries up to >0F are available.

 

The mouse driver code and documentation is out there should you want to look at it. If interested, let me know and I will chase it down. I know I have stuff on my MAME hard drive image. One thing I would need confirmation is to make sure with the later evolutions of MDOS if things moved around in MDOS for some of the hooks it required. I recall seeing some comments in some MDOS source code that lead me to believe those hooks may not be there, or may have moved.

 

Beery

  • Like 1
Link to comment
Share on other sites

Just some words about the concept of system calls; I learned about the details some time ago when I prepared slides for my lectures. This was when I finally understood the rationale behind XOP. Beery is certainly right with his observation that XOPs offer a quite efficient method to call routines.

 

Multi-user systems and generally those that make use of access control (e.g. to protect the operating system and low-level devices) define two modes of operation: one or more privileged modes, and an unprivileged user mode. This has nothing to do with the authorisation of an administrative user; quite a different party. The difference between both modes is that some instructions can only be executed when in privileged mode, some addresses or ports may only be accessed in privileged mode. There is an interesting issue, though: You cannot allow a program to simply switch on the privileged mode and continue executing, because this would make any kind of access control useless (because the program could simply turn off the access control). On the other hand, you must allow a program to turn it on at certain times so that e.g. devices can be accessed.

 

The solution is in "...and continue executing". Thus, the switch from user mode to kernel mode must also imply a branch to another address. This address, again, must not be under control of a user program, because the program would then be able to privilege itself. This means you need a branch to some predefined address including a switch to privileged mode, and then on return, the privileged mode must be turned off again. This is commonly called a system call.

 

Typical operating systems do the following: On startup, the CPU is in privileged mode. When the operating system boots, it installs a handler at the predefined address of the system call. Then it sets this memory area as restricted (can only be changed in privileged mode). Finally, it turns off the privileged mode, so that a user program always starts in user mode. Since the only way to enter the kernel mode is by doing the system call, the program loses the chance to gain control after switching. The handler eventually returns control to the user program, and re-enters user mode.

 

That said, we may have a look at XOP:

  1. It performs a branch operation with context switch (similar to BLWP).
  2. It returns to the caller via RTWP.
  3. The branch address is predefined by the vectors in 0040..007e.
  4. You can pass data to the XOP routine.

In the 99000 CPUs, there is another point: XOP sets status bit 7 to 0. This is the "PRV" bit (active low), undefined for our TMS9900. When this bit is 1, some operations trigger a level 2 interrupt when executed (PRIVILEGED VIOLATION):

  • CKOF, CKON, IDLE, LREX, RSET
  • LIMI
  • LDCR, SBZ, SBO (when the CRU address is in 1C00..7FFE and 9C00..FFFE)

In privileged mode, the instructions LST (load status) and RTWP can change all 16 bits of the status register (including the PRV bit). In user mode, LST can only change bits 0-5 and 10 (leaving PRV unchanged), and RTWP can only change bits 0-7 (again, keeping PRV untouched).

 

Hence, in an operating system for the TMS99000, after startup, status bit 7 is set to 1, entering user mode, and anything you run afterwards will be in this user mode jail.

Edited by mizapf
  • Like 3
Link to comment
Share on other sites

I've been going through that code you posted as well. In addition, the code I had written for MXT, MXT does not run on the Geneve for the TIPI because the KSCAN function is wrong for the Geneve. The Geneve requires a modified KSCAN function.



Your Telnet client works fine on the GPL side of the Geneve with a Memex on my system. I'm thinking the issue is on the MDOS side of things and possibly with timing. I am including a copy of the file archive. Before I archived the file, I assembled the file on my floppy disk just to confirm a good copy, etc. I inadvertently typed the filename TIPI planning on doing something else, but my hands were so quick, I would have swore it displayed the logon screen of my BBS before I hit the power switch not realizing it actually was doing what I was expecting. Could not repeat it, so not sure what the deal was. I do not think it was my imagination, but not betting either way.



The TIPI program is two source files. SETUP installs the LIB source code. After the SETUP (TIPI) installs the LIB (TIPJ) source code, it runs through some routines testing the various opcodes. If you see something is wrong, please let me know.



The Reset opcode is trimmed down from what I saw you had implemented. When I went to set some reset bit(s) for the RPI, the system hung so I removed that code.



Everything I can tell, I get >33 back from the routines in question. I was trying to test for a valid open connection, but could never resolve it. The code will automatically connect with my BBS as written.



The attached file is not a ZIP file. Had to add the ZIP extension to get the forum to allow me to upload.



Beery

TIPIARK.zip

  • Like 1
Link to comment
Share on other sites

Beery,

 

Are you calling TIPI DSR routines with the system set for 4A mode or 9640 mode? I assume the latter based on your description, so there area few things that come to mind you might want to look into.

 

1. VDP ports in the TIPI DSR will reflect the TI addresses; if you are in 9640 mode, those addresses won't be correct.

2. If TIPI is expecting GPLWS or any of the related pointers, like 0x8370 or R15 of GPLWS to be set, you'll need to do that yourself.

Link to comment
Share on other sites

Beery,

 

Are you calling TIPI DSR routines with the system set for 4A mode or 9640 mode? I assume the latter based on your description, so there area few things that come to mind you might want to look into.

 

1. VDP ports in the TIPI DSR will reflect the TI addresses; if you are in 9640 mode, those addresses won't be correct.

2. If TIPI is expecting GPLWS or any of the related pointers, like 0x8370 or R15 of GPLWS to be set, you'll need to do that yourself.

 

He's not calling a DSR, just code in the ROM. The messaging routines used underneath the Device Service Routines.

 

recvmsg: https://github.com/jedimatt42/tipi/blob/2096b4238bb5845937375229ed4e25caccc3aec0/hardware/dsr/tipi-io.a99#L107

 

sendmsg: https://github.com/jedimatt42/tipi/blob/2096b4238bb5845937375229ed4e25caccc3aec0/hardware/dsr/tipi-io.a99#L53

 

Neither of these use VDP... or assume they are in GPLWS. should be safe, unless I made a mistake. Its just that I've not tested them except with WP set to >83E0. The only fixed addresses I see used are:

 

 
TDOUT	EQU	>5FFF		; TIPI Data output
TCOUT	EQU	>5FFD		; TIPI Control Signal output
RDIN	EQU	>5FFB		; TIPI Control Signal output
RCIN	EQU	>5FF9		; TIPI Control Signal output 

 

I make these routine addresses well known immediately after the DSR header, so they are in a fixed location. TCP, mouse, and other extensions are driven through this messaging.

 

-M@

  • Like 2
Link to comment
Share on other sites

Beery,

 

Are you calling TIPI DSR routines with the system set for 4A mode or 9640 mode? I assume the latter based on your description, so there area few things that come to mind you might want to look into.

 

1. VDP ports in the TIPI DSR will reflect the TI addresses; if you are in 9640 mode, those addresses won't be correct.

2. If TIPI is expecting GPLWS or any of the related pointers, like 0x8370 or R15 of GPLWS to be set, you'll need to do that yourself.

 

1. Calling from within MDOS mode (9640 mode).

2. I was not using those workspaces with the TI-99/4A with Mass Transfer. I've seen nothing in the DSR to indicate the send/receive message routines depend upon those workspaces.

 

Beery

  • Like 1
Link to comment
Share on other sites

One thing:

 
RESETTIPI
 
       MOV  @CRU,R12     SET CRU
       SBO  0            TURN ON CARD
 
       CLR  @TDOUT       CLEAR TIPI DATA OUTPUT
       CLR  @TCOUT       CLEAR CONTROL OUTPUT

;;;;;; Your reset is forgetting the part that actually resets the TIPI... this pulls a line LOW on the RPi that triggers the services to be killed and restarted. 
; trigger reset signal to RPi
	SBO	1		; turn on the second cru bit
	LI	R1,>0600
!	DEC	R1
	JNE	-!
	
; turn off the reset signal so RPi service can finish starting
	SBZ	1 
 
       SBZ  0            TURN OFF CARD
 
       RTWP              RETURN
 
TDOUT  EQU  >5FFF        TIPI DATA OUTPUT
TCOUT  EQU  >5FFD        TIPI CONTROL SIGNAL OUTPUT
 
Link to comment
Share on other sites

 

He's not calling a DSR, just code in the ROM. The messaging routines used underneath the Device Service Routines.

Yea, semantics. When I looked at the routine code, I saw two 'variants' of the "recmsg" routines - recmsg and vrecmsg. I only intended to point out a few things that are not obvious when trying to use any DSR/ROM code written for the TI that relies upon the common video port addresses.

  • Like 1
Link to comment
Share on other sites

InsaneMultitasker: All good

Beery: (I'm a bit uptight with semantics, so here are some more) Before this library is released to the world, I'd like the opportunity to discuss reading more than 1 byte at a time. And re-expressing things as TCP operations not TIPI message operations, cause the XOPs are not TIPI message operations.

I don't spot the trouble with getting a byte back to the caller... I saw R13 being messed with in some 'entrance code' or what I think was entrance code... And then R13 is being used as a lever to write results back into the caller's workspace. I am not practiced enough to tell if R13 represents an address that is in the memory map correctly or not...

I would ssh into your PI as the 'tipi' user (from a real computer), go into /home/tipi/tipi/services
vi TipiService.py and add a line of code immediatly after:

LOG_FILENAME = logpath + "/tipi.log"
logging.getLogger('').setLevel(logging.INFO)

add:

logging.getLogger('TiSocket').setLevel(logging.DEBUG)

Then tail -F /var/log/tipi/tipi.log

It should then tell you what the PI is doing with your requests... (It'll log all the bytes probably... so don't paste logs with iteractions that had BBS passwords... )

 

NOTE: make sure you stay the 'tipi' user when editing files in /home/tipi

NOTE: to undo your change you can use git:

cd /home/tipi/tipi/services
git checkout -- TipiService.py

-M@

Link to comment
Share on other sites

I'm pretty sure what I am doing with R13 works, however I will say I am not 100% sure. That is why some of the code in the SETUP file references the data in the LIB code and I print out the hex values from there as well.

 

I'm going to go back and look at some MDOS source that passes information back out of the video calls to double check. I know it is tricky.

 

As far as the logging and ssh into the RPI, gonna have to figure out how to do that. The RPI is mounted on the card and inside the PEBox.

 

It's getting late here, and I am going to turn in after I look at some MDOS source to check a few things. Tomorrow is going to be a long day, especially since my team is playing in the afternoon in the Final 8.

Beery

InsaneMultitasker: All good

Beery: (I'm a bit uptight with semantics, so here are some more) Before this library is released to the world, I'd like the opportunity to discuss reading more than 1 byte at a time. And re-expressing things as TCP operations not TIPI message operations, cause the XOPs are not TIPI message operations.

I don't spot the trouble with getting a byte back to the caller... I saw R13 being messed with in some 'entrance code' or what I think was entrance code... And then R13 is being used as a lever to write results back into the caller's workspace. I am not practiced enough to tell if R13 represents an address that is in the memory map correctly or not...

Link to comment
Share on other sites

Matt, got no problem if wanting to expand the code into more than one byte. Easy to also have another opcode where length is specified of buffer and deal with that as well.

 

Another thing I was thinking about was a version opcode for that very reason if the XOP were expanded. As far as single or multiple byte transfers, I was thinking along the lines of terminal emulation in the mindset of of single byte transfers where existing programs could be modified. The code I am working with (MyTerm, and subsequently Mass Transfer), I personally do not want to request a string not knowing how many characters I am going to get and decipher how many characters I need to buffer for processing. As I am writing this, it may actually be easier than I originally thought since I do not have to deal with character loss if I do not poll frequently enough.

 

Beery

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...