Jump to content
BeeryMiller

TIPI - Geneve 9640 to Raspberry PI interface development

Recommended Posts

Waiting for the oven to preheat, and realizing the assembly creates a listing for me... which de-macros the code pretty much...

 

TSRSET	EQU	>F100
TSRB	EQU	>0600

TCOUT	EQU	>5FFD
RDIN	EQU	>5FFB
RCIN	EQU	>5FF9



; Register usage:
;   R0 - receive buffer size. Result is number of bytes loaded into buffer.
;   R1 - cpu address of buffer
;   Destroys R0 - R8  ( Looks like I cleaned it up at some point to do less damage, R0 - R4 looks more accurate )
recvmsg
	LI	R2,TSRSET

	MOVB	R2,@TCOUT

RM1	CB	@RCIN,R2

	JNE	RM1
	LI	R2,TSRB		; set read mode

	MOVB	R2,@TCOUT

RM2	MOVB	@RCIN,R3

	CB	R2,R3
	JNE	RM2
	AI	R2,>0100

	ANDI	R2,>0100

	ORI	R2,TSRB

	MOVB	@RDIN,R4	; read MSB of data size

	SWPB	R4
	MOVB	R2,@TCOUT

RM3	MOVB	@RCIN,R3

	CB	R2,R3
	JNE	RM3
	AI	R2,>0100

	ANDI	R2,>0100

	ORI	R2,TSRB

	MOVB	@RDIN,R4	; read LSB of data size

	SWPB	R4
	CLR	R0		; reset byte counter
	CI	R4,>0000	; if size is 0, then be done

	JEQ	rrt

rnext
	MOVB	R2,@TCOUT

RM4	MOVB	@RCIN,R3

	CB	R2,R3
	JNE	RM4
	AI	R2,>0100

	ANDI	R2,>0100

	ORI	R2,TSRB

; Change to attempt avoidinga problem copying to fast mem on PEB bus
;	MOVB	@RDIN,*R1+	; copy byte from tipi to RAM
: replace above line that directly copies from TIPI register to external MEM
; with this that holds it in a scratchpad register first
	MOVB	@RDIN,R3	; assuming R3 is in TMS9995
	MOVB	R3,*R1+
; end of Geneve experiment

        INC     R0		; count the read ops
	C	R0,R4
	JNE	rnext		; if not done then go back and read next
rrt
	RT
also attached: attachicon.gifplainasm.txt

 

 

Matt,

 

So far, the above code example moved off the TIPI DSR chip and used as is straight into the XOP, things are working on all the pages I have thus far tested on the GenMod Geneve and Memex.

 

Beery

  • Like 2

Share this post


Link to post
Share on other sites

Perfect. Good to hear... my next suggestion would have been worse... it would have been try the vrecvmsg -- using an intermediate VDP buffer... ick!!!

How about I fix the DSR ROM build, so image 2 ( selected with TIPI cru bit 1 (not 0) ) stops doing the WDS1 thing, and does this fix instead...

That'd work on 4A's too, but would probably slow them down... I will test... And write up some documentation for Geneve on the TIPI wiki...

[email protected]

Share this post


Link to post
Share on other sites

So to note, what I did in that code was add the intermediate copy to internal memory... before copying back out to the target buffer.

 

This would probably still break if your workspace pointer was set to one of those external PEB pages.. but even at zero wait state, those aren't as fast as on-chip TMS9995 memory, so I expect that isn't very common practice.

 

[email protected]

  • Like 1

Share this post


Link to post
Share on other sites

Perfect. Good to hear... my next suggestion would have been worse... it would have been try the vrecvmsg -- using an intermediate VDP buffer... ick!!!

 

How about I fix the DSR ROM build, so image 2 ( selected with TIPI cru bit 1 (not 0) ) stops doing the WDS1 thing, and does this fix instead...

 

That'd work on 4A's too, but would probably slow them down... I will test... And write up some documentation for Geneve on the TIPI wiki...

 

[email protected]

 

You can try it and then I can test things out to see how things go.

 

Beery

Share this post


Link to post
Share on other sites

Matt/Tim,

 

Just wanted to drop you and Tim a note about my progress with MyTerm (Mdos terminal emulator) I have modifed to use TIPI instead of RS232 with the WiModem 232. I am using the XOP code as an interface that can be expanded as needed.

 

Nice thing about the TIPI is I do not have to worry about dropped characters, so the interrupt code for separate keyboard/RS232 can be pulled. I know right now I have pulled over 4K of code from the original program thus far.

 

Right now, with just handling a single character recvmsg from TIPI I am displaying, I am guessing it looks like I have an apparent 19,200 baud rate equivalency. It is not as fast as the 38,400 baud MyTerm could run because I am now allowing MDOS to use it's normal keyscan xop and leaving all interrupts on. Basically, the code tests for a single character received, then tests for a keyboard key, before looping back. That was keeping in line with original framework of the program.

 

I need to get the single character key response with all the other details working first before I increase the buffer size and test the other code I wrote in the XOP which should blow the 38,400 "equivalent" baud rate out of the water. When I do that, I should be able to buffer to something like an 8K limit, probably will keep to less than 2K for a screen's worth of information, that I would get back from the recvmsg, display it, then test for a key. Should be quite a bit faster.

 

I still have a quirk with an extra key popping up during a screen clear command I need to chase down, then tweak the XModem code and then do a bit of rewrite on the URL "phone" directory as I now no longer have dialing strings to worry about.

 

Anyways, things are progressing.

 

Beery

  • Like 3

Share this post


Link to post
Share on other sites

That's good news! Sounds better than my luck...

 

I also tried putting that 2 line change to recvmsg in my ROM and all hell broke loose on my 4A. So I tabled it for a few weeks.

 

Probably wore out the eprom... IDK.

 

Probably not worth any more effort beyond documentation.

 

[email protected]

Share this post


Link to post
Share on other sites

Matt,

 

I've been working on my calling URL routine in MyTerm and have a question. I would call it a phone directory, however it is really a URL directory First, it could very well be a programming issue on my end I haven't chased down, but want to make sure my understanding is correct on the operation of the TIPI and PI.

 

OK, if I have an open socket and I have been communicating through it to a URL, if I then send a RESET command, followed by an OPEN socket command to another URL but using the same socket, I would think that socket should be available and would connect??? Or, do I need to send a CLOSE command first?

 

My thoughts are that a RESET command should close all connections or am I mistaken?

 

Right now, I am trying to debug where it is hanging and it looks like it is getting hung up somewhere in the second call to the same function connecting with a different URL. I still need to test a few things out first as I could be using a pointer incorrectly somewhere as I am a couple of layers deep into some BLWP instructions, but want to make sure I understand the RESET, OPEN, CLOSE message commands on what happens on the PI side of things.

 

Thanks.

Beery

 

 

 

 

 

Share this post


Link to post
Share on other sites

The socketIds you pass to the TIPI message are fine to reuse... In my TELNET I made a mistake, and never close the socket from the 4A side... but I reuse, if you disconnect from a server, and send a byte like ' ', until you get an error...

 

In my FTP client code, I added close... and re-use sockets... each 'dir' opens socketId:1 to facilitate a new data channel to get the directory listing (how FTP passive works)

https://github.com/jedimatt42/fcmd/blob/master/b7_ti_socket.c

 

I don't 'reset' in between connects... reset doesn't actually close the sockets... it 'kill -9' the tipi services... and eventually the underlying linux OS will close the sockets...

 

but TIPI socketIds are just a key in a python map to an open socket object. The actual socket numbers are ephemeral. Looking inside the tipi TiSocket.py, the handleOpen is coded to close the socket associated to that socketId if one exists, before proceeding to connect a new socket.

 

[email protected]

Share this post


Link to post
Share on other sites

Also, if you call things URLS, here is the specification for telnet URLS:

 

  telnetaddress           t e l n e t : / / login 

  login                   [ user [ : password ] @ ] hostport 
                         
  hostport                host [ : port ]   
                         
  host                    hostname | hostnumber  

  hostname                ialpha [  .  hostname ] 
                         
  hostnumber              digits . digits . digits . digits 
                         
  port                    digits   

example:

 

telnet://sombody52:[email protected]:9640

So, will the dialer allow entering strings like that? You are going to parse login prompts from varied remotes, and submit user names and passwords for folks? That'd be cool.

 

I remember some pc term programs allowing scripts for various BBS's to execute after connection, and would fill in login and password.

 

[email protected]

Share this post


Link to post
Share on other sites

At least the BBS's I am familiar as far as telnetting into, display some text, test for ANSI (or ask), then they prompt for name/password. I do not think passing a username and password is possible.

 

Beery

Share this post


Link to post
Share on other sites

At least the BBS's I am familiar as far as telnetting into, display some text, test for ANSI (or ask), then they prompt for name/password. I do not think passing a username and password is possible.

 

Beery

Oh, well the terminal programs used to offer a scripting language or delay mechanism to automate sending things... Seems like I recall people doing that with delays in dial strings too...

 

Anyway, if not bothering with all that then I wouldn't recommend use of URL. TIPI doesn't understand URLs for sockets, so why bother with the 'telnet://' schema prefix required to be a URL?

 

You just need a hostname and optional port.

 

[email protected]

Share this post


Link to post
Share on other sites

I have a possible error with the latest update.

 

After I updated to the latest version, I found I was unable to connect to Chatti, Chess or Snek at myti99.com in the normal manner, but I was able to check the Chess and the group chat via the browser, so I decided to load up TIPI to see what was up and I see the scrambled URI entries below. Has anyone else experienced this as well?

post-35324-0-93816600-1557715308.jpg

Share this post


Link to post
Share on other sites

I have a possible error with the latest update.

 

After I updated to the latest version, I found I was unable to connect to Chatti, Chess or Snek at myti99.com in the normal manner, but I was able to check the Chess and the group chat via the browser, so I decided to load up TIPI to see what was up and I see the scrambled URI entries below. Has anyone else experienced this as well?

Wrong thread, this is the GENEVE library development thread...

 

but it is just a long standing defect in TIPICFG when the value of a URI mapping is long... When you ran the GAMES005.TXT off my web server it remapped URIs for it's purposes, as I previously promised software eventually would. You can reset them using the tipimap command in your Force Command AUTOCMD file if you want.

 

[email protected]

 

Share this post


Link to post
Share on other sites

Matt,

 

Just a head's up on a question I asked earlier I think I proved to myself. I was connecting to a BBS downloading a file. In this case, downloading a file I am doing a single byte transfer. The program completed the file transfer and was waiting for a key response. As I was distracted, the connection timed out waiting for me to press a key. So, during this time, text should have been still coming into the PI. By the time I got back to pressing a key, the connection was dropped. There was nothing in the buffer.

 

To me, this suggests once a connection is dropped, any subsequent buffered bytes the PI may have had will not be retrieved. I'm not asking for any changes, etc. Just reporting my observation.

 

Beery

Share this post


Link to post
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.

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