Port and WiModem232

[+9640News]

 

 

If you are in Port, you can sit in terminal mode and ACKnowledge the records manually. Ctrl-F is an ACK, if I remember correctly. You'll be able to see the Ymodem header that way. You might also need to provide the "C" to kick off the CRC handshake.

 

Ah, nice. Might be a way for me to see what is happening in the file transfer process. Had not thought of that trick.

 

I'm pretty sure the version of Port I am using is the one you uploaded to this group about a month or so ago.........

 

Beery

Edited January 23, 2018 by BeeryMiller

[+InsaneMultitasker]

 

Ah, nice. Might be a way for me to see what is happening in the file transfer process. Had not thought of that trick.

 

I'm pretty sure the version of Port I am using is the one you uploaded to this group about a month or so ago.........

 

Beery

 

I think Shift838 uploaded the version you are using. I have not figured out where the code to my latest updates is located... nor have I had time to do so. Oh, you can also enable the hex view (Fctn-10 I think) to show what is coming in. Check the help screen Fctn-7 for the right keypress. I use that mode to debug some of the Telnet issues in conjunction with packet inspection.

[+InsaneMultitasker]

Beery, in one of the other threads you asked me about interrupts and PORT. I am replying here just to keep the PORT items together. In MDOS each task has its own page 0 which, in the first 0x400 bytes, contains much of the inter-task information, paths, etc. The 9995 interrupt vectors start at 0x0000 so you can replace the interrupt vector address at 0x006, provided you intend to re-use the interrupt workspace (0xf080 in mdos, IIRC) for your routine.

 

PORT handles all interrupts directly and re-orders the testing priority as follows: RS232, then keyboard, then video. Buffering happens within the interrupt routine the RS232 is tested for a pending interrupt before leaving the interrupt handler, although I am not sure this is necessary. I don't recall if I test video/keyboard prior to exiting, or if I allow the interrupt to occur at the next allowed interval.

 

I do not process sound or sprites unless I specifically call for them, in which case I patch the routine(s) into the handler. This allows for maximum interrupt processing availability (and speed) while PORT does all of its other work. Of course, this means the program will not play nice with multitasking unless PORT controls it

 

To add to the post... the most recent (so far) version of source I can find is flawed, and adds an extension after shortening the name with a crude 8 character limit. I really wish I had a PC back then. Anyway... for reference, this is probably what is biting you while transferring files.

 

Seems a quick patch to replace the '8' with '10' would disable the filename limit, though it would retain the extension. The version I am looking for made the extension optional - it can be handy for sorting/filtering the file entries.

 

 

 

 

LI   R0,PARSEDNAME
       LI   R1,HEADERBUFFER
       CI   R2,8
       JLE  BATHIG
       LI   R2,8
BATHIG DEC  R2           6.03 correct number of bytes to avoid bad char.  sigh..
BATHIH MOVB *R0+,*R1+
       DEC  R2
       JNE  BATHIH
*      MOVB @EXTEXT,*R1+      * PERIOD '.'
*      MOVB *R0+,*R1+         GET TWO LAST CHARS
*      MOVB *R0+,*R1+
       LI   R0,4              ADD EXTENSION FROM WHERE WE LEFT OFF ABOVE
       LI   R2,EXTEXT
BAT205 MOVB *R2+,*R1+
       DEC  R0
       JNE  BAT205
       BLWP @SNDISP             'sending header'
       DATA POSSTATUS,XFM01

 

 

Edited January 24, 2018 by InsaneMultitasker

[+9640News]

Tim,

 

Thanks for that information. I had some time last night and was reviewing the task header information between >0000 and >0400. It's been such a long time since I have looked at MDOS source code.

 

As far as multitasking, I wasn't planning on going down that route <grin>.

 

Later,

 

Beery

[+9640News]

Hey Tim. I dug into the Task header page and did some debugging looking to see how Port was manipulating the interrupt routine and it was not as much of an issue as I first thought. I still need to do some more digging though.

 

Thanks for the idea, as if in my mind I need to do what I think I need to do, I can do some simple testing to confirm it can be implemented with just a few lines of code.

 

Beery

[+InsaneMultitasker]

Hey Tim. I dug into the Task header page and did some debugging looking to see how Port was manipulating the interrupt routine and it was not as much of an issue as I first thought. I still need to do some more digging though.

 

Thanks for the idea, as if in my mind I need to do what I think I need to do, I can do some simple testing to confirm it can be implemented with just a few lines of code.

 

Beery

 

Yep, it's not that bad, mostly just saving the vector and hooking into it just like you would with the TI's user interrupt. I can probably find the source to my interrupt routine handler if you need some more info. Hooking into the routine is simple enough and you can still use the OS routines depending on what you do. The MDOS interrupt handler is a good source of info as well, and that code is in part what I used to keep things consistent.

[+9640News]

Well, if you have the interrupt routine handler available, I will not turn it down. MyTerm has its own VDP routines and it's own keyboard routines outside MDOS. The patch in is simple enough. I am just not sure what happens with the keyboard and video if I patch that interrupt into the existing RS232 code.

 

All I can do is test it out to see what happen(s) at this point. That will be something I do this evening, probably later than sooner. I suspect the wife will want to go out to dinner rather than have a third night of leftover venison chilli.

 

Beery

[+InsaneMultitasker]

I'm guessing you'll want to (or need to) repurpose the existing routine to extract data from the circular buffer. The interrupt routine's sole purpose would be to fill the buffer. The two would then work together so long as MyTerm leaves interrupts enabled during most of its processes. And of course, there are many ways to skin the proverbial cat.

Edited January 25, 2018 by InsaneMultitasker

[+9640News]

Yeah, MyTerm has a pretty sizeable buffer. Just a matter of mapping into it.

My first try of pointing the RS232 capture of incoming data resulted in something that did not work with no keyboard response.

Beery

[+InsaneMultitasker]

So.., PATCHISR is called only once to patch the replacement ISR into the vector table and set up the ring buffer. Repatch/Unpatch are used for all subsequent changes.

 

The R12 addresses and offsets are all pre-loaded by RCVON.

 

The RS232 interrupt tests for another received character before exiting. This could be changed to return to the interrupt entry to test all interrupts again before returning control to the main program. Note how the video and keyboard interrupts must be managed if you completely replace the interrupt routine. If you chain the MDOS interrupt to follow your interrupt, you can achieve roughly the same effect, though the OS might capture an RS232 interrupt in between another interrupt, in which case it would try to process the byte outside of your control.

 

 

********************************************************************************
*
* entry point for 9640 mode interrupt
*
PATCHISR
       LIMI 0
       MOV  @>0006,@SAVEDVECTOR         Save original vector
       LI   R0,INTENT                   get address of new INT routne
       MOV  R0,@>0006                   and patch us in!
       LI   R0,BSTART
       MOV  R0,@RFIRST
       MOV  R0,@RLAST
       LIMI 2
       RT
REPATCH
       LIMI 0
       LI   R0,INTENT         Patch our routine
       MOV  R0,@>0006
       LIMI 2
       RT
UNPATCH
       LIMI 0
       MOV  @SAVEDVECTOR,@>0006              Give MDOS control of ints
       LIMI 2
       RT
*
*
* Turn on RCV ints on the correct card; adjust code for correct CRU address
*
RCVONR1  DATA 0
RCVON  LIMI 0
       MOV  R1,@RCVONR1
       MOV  @COMPORTNUM,R1
*      CLR  R1           arrghh..hardcoded!  found 11-29-95
       SLA  R1,1              adjust it
       MOV  @BASETAB(R1),@BASE1+2
       MOV  @BASETAB(R1),@BASE2+2
       MOV  @BASETAB(R1),@BASE3+2
       MOV  @BASETAB(R1),@POLL1+2
       MOV  @BITTAB(R1),@BUSINT+2
       MOV  @BITTAB(R1),@BUS2+2
       MOV  @BITTAB(R1),@POLL0+2
BASE1  LI   R12,>1340    modified inline base=1300, port=>0040
       SBO  >12          enable RS232 RCV Int
       SETO @INTFLAG
       MOV  @RCVONR1,R1  gotta restore what we changed!
       LIMI 2
       RT
RCVOFF LIMI 0
BASE2  LI   R12,>1340
       SBZ  >12
       CLR  @INTFLAG
       LIMI 2
       RT
*
* Modified Geneve Interrupt routine
*
*      Uses WS=>F080
*      Eliminates Geneve OS from the interrupt handler
*
INTENT LIMI 0
BUSINT LI   R12,16*2+>1340    modified inline
       TB   0
       JEQ  GET2
       CLR  R12
       SBO  25
       LDCR @H0106,0
*      TB   1            RS232?
*      JNE  BUSINT       yippe!
       TB   8
       JNE  KEYINT       change order, otherwise ever-pending vid int will
       TB   2            over ride key ints!
       JNE  VIDINT
KEYINT
NOTRS
       BL   @KINT        Let's look for keyboard ints
       JMP  DISCRD
* NOTRS  MOV  @SAVEDVECTOR,R0   let OS handle anything else(can we remove bus in
*      B    *R0
VIDINT
       SBO  2            get rid of vid int?
       ABS  @COLORFLAG
       JEQ  SHORTVID
       LI   R12,>008F
       MOVB R12,@>F102
       SWPB R12
       MOVB R12,@>F102
SHORTVID
       MOVB @>F102,R12   clear int flag!
*
* add code for a timer here!
* TIMERLOW   DATA 0       to restart,
* TIMERHIGH  DATA 0
* COUNTSIXTY DATA 0      use to track seconds
*
*      INC  @COUNTSIXTY
*      C    @COUNTSIXTY,@SIXTY
*      JL   DISCRD
*      CLR  @COUNTSIXTY
*      INC  @TIMERLOW    KEEP track of >FFFFFFFF / 60 seconds!!!
*      JNC  DISCRD
*      INC  @TIMERHIGH
DISCRD RTWP
*******************************************
BASE3
GET2   LI   R12,>1340    changed by RCVON
       STCR R3,8
       SBO  RIENB        reset now, so if another char comes in we pick it up!
       C    @RBYTES,@BMAX     buffer full?
       JEQ  RSINX             YES
       MOV  @RLAST,R1    no, lets get it
       CI   R1,BEND
       JL   ADDROK
       LI   R1,BSTART
ADDROK MOVB R3,*R1+  get byte before another one forms!
       MOV  R1,@RLAST
       INC  @RBYTES
BUS2   LI   R12,16*2+>1340    modified inline by RCVON
       TB   0
       JEQ  GET2
       RTWP
*
RSINX  SBO  RIENB             Char recieved/continue to interrupt if needed
       RTWP                   since we got a character, DON'T look for other int

[+9640News]

Thanks for the Interrupt routine. Just got it late this evening. Will have to code tomorrow night.

​Beery

[+9640News]

Tim,

 

I've looked over the code. Pretty ingenious using some self modifying code. Not sure anyone else will ever have a need for this code, but if they do, there were a few pieces I had to dig into to figure out.

 

BASETAB is a data table of 4 CRU addresses being >1340, >1380, >1540, and >1580

BITTAB is another data table of 4 CRU's of >1360, >13A0, >1560, and >15A0.

RIENB is defined as >0012.

COMPORTNUM is a word either 0,1,2,3 for RS232/1, RS232/2, RS232/3, and RS232/4.

 

I do have a couple of questions.

 

Your KEYINT routine does a BL @KINT. The KINT routine was not part of this code and right now, I am assuming this is where you are getting all of your keyboard presses??? I've got code without using the XOP to grab any keypresses.

 

There are two instructions I am not sure what you are modifying since they are not part of the code listing. It is in RCVON where you move a CRU address indexed from BITTAB into @POLL1+2 and @POLL0+2. Can these lines be deleted, or is there another piece of code needed? Just want to make sure and not make any bad presumptions.

 

Looking over the code, it is my understanding you would do a BL @RCVON, then do a BL @PATCHISR in that order to get everything setup.

 

Thanks again for your assistance.

Beery

[Shift838]

I received mine yesterday and set it up with a standard cable, I was able to successfully upload/download on heatwave at 9600. 19200 did not work for file xfers for me.

[+9640News]

Chris,

 

I'm guessing since the topic of this group was Port and the WiModem232, you were using PORT? Emulated Geneve or real Geneve? Just want to confirm your setup.

 

I had an earlier post on page 1 where I was able to successfully download at 38.4K with PORT and the WiModem232 AFTER that latest firmware update. Since you just got your unit, you may need to confirm you have the latest firmware update. If not, that would likely explain your issue. You would need to be using AT&K1 and AT*T0. Keep in mind, if you do an ATZ after issuing those commands, you will reload whatever is in the default saved set of parameters. You need AT&K1 and AT*T1 for 9640News BBS since it is running in Telnet mode through the servers.

 

If you were using PORT, and if you were using the right AT settings on Heatwave, I believe the first message in this topic has my cable pinouts. That was for Hardware #1 configuration in Port. I also noted on that first page of this topic, I was also able to download at 38.4K using the Interrupts setting. There was a note somewhere on that first page downloading was done with interrupts regardless of the cable configuration setting in PORT.

 

Anyways, I hope this information helps. I've got a few test files over on Heatwave in the Telnet category where I tested uploading and downloading.

 

Beery

[Shift838]

Chris,

 

I'm guessing since the topic of this group was Port and the WiModem232, you were using PORT? Emulated Geneve or real Geneve? Just want to confirm your setup.

 

I had an earlier post on page 1 where I was able to successfully download at 38.4K with PORT and the WiModem232 AFTER that latest firmware update. Since you just got your unit, you may need to confirm you have the latest firmware update. If not, that would likely explain your issue. You would need to be using AT&K1 and AT*T0. Keep in mind, if you do an ATZ after issuing those commands, you will reload whatever is in the default saved set of parameters. You need AT&K1 and AT*T1 for 9640News BBS since it is running in Telnet mode through the servers.

 

If you were using PORT, and if you were using the right AT settings on Heatwave, I believe the first message in this topic has my cable pinouts. That was for Hardware #1 configuration in Port. I also noted on that first page of this topic, I was also able to download at 38.4K using the Interrupts setting. There was a note somewhere on that first page downloading was done with interrupts regardless of the cable configuration setting in PORT.

 

Anyways, I hope this information helps. I've got a few test files over on Heatwave in the Telnet category where I tested uploading and downloading.

 

Beery

 

I was using PORT and a real Geneve. I did try the AT&K1 and AT*T0 to try on heatwave and still was unsuccessful with Hardware Configuration #1 (Jeffs cable) and then tried with No interrupts.

[+InsaneMultitasker]

downloads seem to work fine at any speed but uploads are still a problem for me. I can't get beyond 9600 - with either handshaking or interrupt mode. The results are similar when I connect the wimodem to a PC, though I think there is a different issue there with the terminal emulator I am using. I shared my findings with Jim but haven't had time this week to finish the testing I was working through.

[+9640News]

 

 

RS232/1 WiModem232

1 <--------------> 1

2 <--------------> 3

3 <--------------> 2

7 <--------------> 7

5 <--------------> 4

8 <--------------> 20

20 <--------------> 5

 

 

 

With the above cable configuration for the WiModem232 with no solder cuts on the board, am I able to use RTS/CTS ? Seems like without Pin 6 being connected to pin 6, the DSR to DTR is not possible? Am I getting this right?

 

I'm trying to piece together this handshaking business and I am having to teach myself quite a bit.

 

Thanks for any feedback.

Beery

[Shift838]

With the above cable configuration for the WiModem232 with no solder cuts on the board, am I able to use RTS/CTS ? Seems like without Pin 6 being connected to pin 6, the DSR to DTR is not possible? Am I getting this right?

 

I'm trying to piece together this handshaking business and I am having to teach myself quite a bit.

 

Thanks for any feedback.

Beery

 

I think you are correct about Pin 6 to use DSR to DTR..