Jump to content
IGNORED

TIPI - Geneve 9640 to Raspberry PI interface development


9640News

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

-M@

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

 

-M@

  • Like 1
Link to comment
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...

 

-M@

 

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

 

Beery

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

 

-M@

Link to comment
Share on other sites

  • 2 weeks later...

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

 

 

 

 

 

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

 

-M@

Link to comment
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:secret@thekeep.net: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.

 

-M@

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

 

-M@

Link to comment
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

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

 

-M@

 

Link to comment
Share on other sites

  • 4 weeks later...

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

Link to comment
Share on other sites

  • 11 months later...

@jedimatt42 

(I am fairly new to the Geneve 9640, I still have issues with RGB-signal loss, but I can now work on it

and see what is happening in the OS).

 

Not sure if I understand it correctly:

* I prepared the startup floppy on DSK1 on the TIPI 

   (this floppy works as I made a 5.25 disk of it)

 

* Is it possible for the Geneve to start directly of the TIPI with DSK1. ? 

   (mine goes everytime to the FDC DSK1.)

* I also tried GPL mode on the TI with CALL TIPI   (results in BAD NAME)

 

(or do I need something what is call GenMod? not sure how to do this, probably a chip upgrade?)

 

(My goal is to download the disks of ftp.whtech.com  geneve directory to get these disks to the

TIPI and then try the programs on the Geneve and in the GPL mode)

 

Otherwise to do troubleshooting to see for example

the DSR / CRU addresses,which program do I use in MDOS then I copy that to a floppy)

 

 

Link to comment
Share on other sites

You'll need a new boot EPROM; the 0.98 ("Swan") only boots from floppy or HFDC, the later ones can also boot from SCSI and RAMdisk. I once suggested a whole new boot process with only a minimum of built-in drivers, but as always, too many ideas for too little time.

 

Maybe the PFM extension could be a good way to go (replace the boot EPROM with a Flash ROM).

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

TIPI is not accessible as a storage device from MDOS, or the boot ROM. 

 

DSK mapping on a TIPI does not emulated a floppy controller. The boot ROM expects a floppy controller. 

 

TIPI seems to work fine in GPM ROMPAGE mode... 

 

I won't speak to any future regarding TIPI and the Geneve... That is all up to all of you... 

 

Oh, and InsaneMultitasker found a bug in the TIPI DSR rom last week... the setdir lvl2 operation...   I gave him a patch, but I don't know if it fixed it.  I didn't test on my Geneve... I can't find any Geneve specific software worth risking turning it on for.

  • Like 2
Link to comment
Share on other sites

In GPL mode on the Geneve 9640, with Rompage Mode active (F5 - Function 5 from the GPL menu screen), the Geneve will use the on-board DSR code for device access.  This means with the TIPI, you can dir/read/write.  There is not a program yet that allows you to copy a file from the TIPI to the Geneve at any path (DSK1, WDS1, HDS1, etc.) at present.  Force Command that Matt released works on the real TI-99/4A to accomplish this, but it is too big for the Geneve and requires the FinalGrom 99.

 

I move files from the Geneve to the TIPI or vice versa through a Geneve -->SD-card Lotharek DSK1 HFE file > SD-Card HFE Reader in Windows > SC-Card DSK file save > TIDIR > TIPI networked Path on the TIPI card.  To take things the other way, it is done in reverse.

 

Not a simple process, but I have done it enough now that once I pull the SD card from the Lotharek setup on the Geneve, I can have all the contained files on the TIPI in 1 to 2 minutes.

 

Beery

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, globeron said:

@jedimatt42 

(I am fairly new to the Geneve 9640, I still have issues with RGB-signal loss, but I can now work on it

and see what is happening in the OS).

 

Not sure if I understand it correctly:

* I prepared the startup floppy on DSK1 on the TIPI 

   (this floppy works as I made a 5.25 disk of it)

 

* Is it possible for the Geneve to start directly of the TIPI with DSK1. ? 

   (mine goes everytime to the FDC DSK1.)

* I also tried GPL mode on the TI with CALL TIPI   (results in BAD NAME)

 

(or do I need something what is call GenMod? not sure how to do this, probably a chip upgrade?)

 

(My goal is to download the disks of ftp.whtech.com  geneve directory to get these disks to the

TIPI and then try the programs on the Geneve and in the GPL mode)

 

Otherwise to do troubleshooting to see for example

the DSR / CRU addresses,which program do I use in MDOS then I copy that to a floppy)

 

 

Does your TIPI has the needed update to function with the Geneve, mine didn't´t, so I had to send it back to Greg for an update.

Link to comment
Share on other sites

1 hour ago, jedimatt42 said:

TIPI is not accessible as a storage device from MDOS, or the boot ROM. 

 

DSK mapping on a TIPI does not emulated a floppy controller. The boot ROM expects a floppy controller. 

 

TIPI seems to work fine in GPM ROMPAGE mode... 

 

I won't speak to any future regarding TIPI and the Geneve... That is all up to all of you... 

 

Oh, and InsaneMultitasker found a bug in the TIPI DSR rom last week... the setdir lvl2 operation...   I gave him a patch, but I don't know if it fixed it.  I didn't test on my Geneve... I can't find any Geneve specific software worth risking turning it on for.

 

I found my Atmel 29C256 flash EE so my goal is to use one of them in place of an EPROM as I cannot burn the latter.

As for Geneve support, I'll know more this weekend. Pretty sure I've mapped out the remaining changes to provide both level 2 and level 3 within GPL.  The only challenge I see is that the well-known addresses may need to be cached and internally redirected by the OS.

 

Does the TIPI set the current directory for level 2 operations based on the most recent level 3 file IO?  I ask because Fred's DM2K is able to copy files from sub-folders to a non-conflicting device (e.g., DSK5), which suggests that the current directory is updated during the level 3 catalog read.  (DM2K doesn't use opcode >17, which leaves few alternatives).

 

 

 

 

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