TIPI BBS

[+InsaneMultitasker]

Sounds like a few of us had similar experiences. Some time ago I came across a disk containing my early work to decode the fidonet packets using unzipped data from a friend's BBS. It was all done in XB as a proof of concept.  ZIP file extraction, Zmodem, manual pulls, and memory constraints were all barriers to pursuing further.

[Omega-TI]

10 hours ago, InsaneMultitasker said:

Sounds like a few of us had similar experiences. Some time ago I came across a disk containing my early work to decode the fidonet packets using unzipped data from a friend's BBS. It was all done in XB as a proof of concept.  ZIP file extraction, Zmodem, manual pulls, and memory constraints were all barriers to pursuing further.

Yeah, again the traffic would be minimal, so I would not even bother with ZIP files, straight text should work fine.  Keeping things simple should be more efficient when you consider how fast the Internet connection sends the stuff now days.  The AX.25 method (ask Corey) would be perfect.

[+InsaneMultitasker]

4 hours ago, --- Ω --- said:

Yeah, again the traffic would be minimal, so I would not even bother with ZIP files, straight text should work fine.  Keeping things simple should be more efficient when you consider how fast the Internet connection sends the stuff now days.  The AX.25 method (ask Corey) would be perfect.

Back then all (most?) of the doorways used ZIP files as part of the process.  I agree that today, clear text would be just fine for our purposes.  Heatwave has coding in place to exchange messages with The Hidden Reef but like many things since my health experiences 4+ years ago, it isn't a priority.  And anyway, Richard and I need to bring THR into a newer version when he is ready...

[+jedimatt42]

@--- Ω --- my Telnet client is only included with TIPI as a fallback if you need shell access to the PI for some recovery/config purpose. 

 

Why would we want....

 

My philosophy on bundling 4A software with TIPI, is that if it isn't necessary, it isn't included.

 

-M@

[Omega-TI]

On 1/22/2020 at 6:53 PM, jedimatt42 said:

@--- Ω --- my Telnet client is only included with TIPI as a fallback if you need shell access to the PI for some recovery/config purpose. 

My philosophy on bundling 4A software with TIPI, is that if it isn't necessary, it isn't included.

 

Understood.

[+9640News]

Modifications are still progressing.  I've done some trimming of the fat, and it is getting really close to fitting in the upper 24K memory without having to use module ram. I am about 100 bytes too big, but I think I can trim all that out when I remove some debugging code routines I am using.

 

I've got the TIPI interface to the time/date clock assembly routine working for my timezone.  I took things too literal in the description of the use to code for assembly.  When I then went back to the extended basic program and followed that logic through, things worked fine.

 

I've also encountered that PuTTy and Window's 10 Telnet clients behave differently.  I thought I had a coding issue, until I switched back to the Windows Telnet client.  Not sure if I have an older version of PuTTy or what the deal was, but backspacing characters and client echoing characters back were an issue.  Lost a lot of time there this weekend.

 

I've got three issues I am trying to resolve now.  One is with I suspect are with interrupts and the KSCAN function.  Can't get local keys seen so a Sysop can access from their TI.  The original unmodified code with RS232 worked fine, so I must have something either flagged differently in a variable or I am bypassing a loop in the character send/receive.  Some debug routines will help clear that issue.

 

Second issue is with the TIPI Server.  First "caller" on a socket, all is well.  Disconnecting the call without issue.  So far, unable to pick up subsequent calls with subsequent Accept inquiries.  Strange thing is that if I exit the program, and reload the program without rebooting, the code works.  I've ran the TIPI powerup code to reset the PI, but that seems to not be the issue that I can tell.  Tonight, I am going to play with the Extended basic server example and see if I can get multiple connections without exiting the program.  It that works, then I know it is some routine with an issue I need to chase down (likely the issue).

 

Last issue is dealing with the clock/timer for online time usage by user.  I may need to rewrite some of the BBSCLOCK code as it has two levels of interrupts within that code tracking minutes online and tracking time.  Code originally used a manually updated date function required by the SYSOP as no clock function was supported.  The documentation hinted something existed for a clock interface, but that must have been in another version of the code.

 

The XMODEM code hasn't been touched, but should not be a significant issue as the RS232 routines to be modified are minimal and I have made those kinds of changes in the past.

 

Once I get the code to a reasonable state, I can then move it off the Geneve under TI-99/4A (GPL mode) to an unmodified TI-99/4A with TIPI.

 

Anyways, just an update.

 

Beery

 

 

 

 

 

[+InsaneMultitasker]

Beery, if it helps your endeavors here is the basis for the tipi pi.clock routine that I am using.  (This should also work for Triple Tech and Classic99 Clocks, possibly others with a level 3 clock routine). 

 

I recommend that you use either a VDP interrupt and/or a simple loop counter to minimize how often the clock DSR read routine is called.   Typically, every second or ever 30-40 seconds for HH:MM:SS or HH:MM, respectively.

 

VMBWD is the same as VMBW, just that it uses DATA statements versus registers.  

 

 

TIPICLK  DATA 0   ;0=no tipi clock, <>0 tipi clock found

 

; For debugging:
;   PAB on screen at address 80
;   Buffer on screen at address 40

TIPICLKPAB DATA >0014     ; open opcode w/file type
       DATA 40     ; read buffer (on screen)
       DATA >5050,>0000,>0008    
       TEXT 'PI.CLOCK'           
       BYTE 0
       EVEN

; Check for TIPI CLOCK @ pi.clock
; If found, device PI.CLOCK is left open for TIPICLOCKDSP routine
; 
FNDTPC CLR  @TIPICLK
       BLWP @VMBWD    ;copy pab to VDP
       DATA 18,TIPICLKPAB,80    ;>1200
       LI   R6,89    ;>1209
       MOV  R6,@>8356
       BLWP @DSRLNK
       DATA 8
;       JEQ  NOTIPC   ;Does not work w/current DSR
       SETO @TIPICLK
NOTIPC RT

 

; Assumes TIPI clock 'file is 'always' open
; Reads the pi.clock
; Once the DSR places the date/time into VDP, you would use a VMBR to pull into memory for manipulation
TIPICLOCKDSP
       LI   R1,>0200          read opcode
       MOVB R1,@tipiCLKPAB    force read opcode 
       BLWP @VMBWD            write pab to VDP
       DATA 18,tipiCLKPAB,80

       LI   R6,89    ; length byte in PAB (vdp)
       MOV  R6,@>8356
       BLWP @DSRLNK    ;read day/date/time to vdp buffer
       DATA 8
; Should check status byte for error and if present, disable
       RT

[+9640News]

I did get the clock code reading the time.  As the modifications are being made to only support the TIPI, I am not worried about the other cards that could display the time.

 

Thanks for the code.  I do need to look it over as I do need to figure out some interrupt driven code as I do not like what is there.

 

Still chasing down some issues as I need to be able to detect a disconnect so I can go back into waiting for a new caller.

Beery