+9640News Posted April 26, 2019 Author Share Posted April 26, 2019 I will try to test this sometime this weekend. Not sure I can test tonight. Just depends upon what the wife has planned. Beery 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 26, 2019 Author Share Posted April 26, 2019 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: plainasm.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 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 27, 2019 Share Posted April 27, 2019 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@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 27, 2019 Share Posted April 27, 2019 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@ 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 27, 2019 Author Share Posted April 27, 2019 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 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 30, 2019 Author Share Posted April 30, 2019 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 3 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 1, 2019 Share Posted May 1, 2019 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@ Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 10, 2019 Author Share Posted May 10, 2019 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 10, 2019 Share Posted May 10, 2019 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@ Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 11, 2019 Share Posted May 11, 2019 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@ Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 11, 2019 Author Share Posted May 11, 2019 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 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 11, 2019 Share Posted May 11, 2019 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@ Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted May 13, 2019 Share Posted May 13, 2019 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? Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 13, 2019 Share Posted May 13, 2019 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@ Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 11, 2019 Author Share Posted June 11, 2019 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 Quote Link to comment Share on other sites More sharing options...
globeron Posted May 22, 2020 Share Posted May 22, 2020 @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) Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 22, 2020 Share Posted May 22, 2020 (edited) 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 May 22, 2020 by mizapf 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 22, 2020 Share Posted May 22, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+9640News Posted May 22, 2020 Author Share Posted May 22, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
Nick99 Posted May 22, 2020 Share Posted May 22, 2020 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 22, 2020 Share Posted May 22, 2020 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). Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted May 22, 2020 Share Posted May 22, 2020 specifically your dsr needs to read 6-23-2018 in TIPICFG to work with the Geneve Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted May 22, 2020 Share Posted May 22, 2020 1 minute ago, arcadeshopper said: specifically your dsr needs to read 6-23-2018 in TIPICFG to work with the Geneve The patch I gave InsaneMultitasker would be dated last week, and isn't on my website. But the mid2018 one gets past startup. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted May 22, 2020 Share Posted May 22, 2020 The patch I gave InsaneMultitasker would be dated last week, and isn't on my website. But the mid2018 one gets past startup.Yes I was posting that info in response to the other messages about updating the DSR Sent from my LM-G820 using Tapatalk Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 22, 2020 Share Posted May 22, 2020 After nearly an hour of playing with the new DSR thinking my code had an error somewhere (which is certainly possible!) it dawned on me that I programmed the chip with the 2018 image. I am so glad the weekend has arrived. 1 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.