RIP graphics can work wit FuSiON BBS!

[Shift838]

so I started toying around the idea that the RIP file graphics format could be used to create some really cool graphical screns for use with FuSiON BBS.

 

I have done a preliminary test with a couple of graphics files to determine if they would even load up. And they did. There were a hand ful of garbage characters at the end of the file, but that was as expected. I should be able to find the values and zero them out to make them look good.

 

When I have some test area to throw up that has some i will let you know. Please remember you will need to call into the BBS via a terminal program that supports RIP like Ripterm 1.54.

 

If I decided to put some code to cycle though RIP graphics or utiilize RIP graphic menus then I will put it for download in my section.

 

Any questions just send me a PM.

 

 

Screenshot shows promise!

 

 

[David Baldwin]

Hi Shift838 ill go and try it out

[David Baldwin]

This is what RIP looks like I did a video of my 486 and Ripterm dialing into wabusa.com bbs i think this bbs is now off line.

 

[Shift838]

Hi Shift838 ill go and try it out

 

It was just a quick test, I did not make the code permanent. Really no change in the code, I can already use existing assembly routines that is in the machine language. I just had to manipulate the file a bit.

[+InsaneMultitasker]

I added a routine in the BBS remote management functions to deal with the garbage characters. Essentially, you need to know the -real- size of the file from the PC side, divide that by 128 (record size of the DF128 file), and clear the remaining bytes. There might still be some tweaking you'll need to do. Anyway, here is that routine.

 

 

!Use:  CALL ANSIFIX(pathname$)
!P$ is the period-terminated pathname passed from the main program's remote disk catalog routine
!Note that this subprogram uses its own error handling during file IO, since you should not branch outside of a subprogram.  The main program's error recovery branch point is restored just prior to exiting, with the return stack adjusted if there was an error.
!CALL G is user/terminal input
!CALL C is display
 
7000 SUB ANSIFIX(P$)
7020 CALL G("~~(c/r) or FIX:\"&P$,10,A$) :: IF A$="" THEN 7110
7025 ON ERROR 7104 :: OPEN #88:P$&A$,DISPLAY,FIXED 128,RELATIVE,INPUT :: CLOSE #88
7026 OPEN #88:P$&A$,DISPLAY,FIXED 128,RELATIVE
7030 CALL H("~Total Bytes (PC):",6,B$) :: IF B$="" THEN 7110 ELSE A=VAL(B$)
7040 B=INT(A/128) :: OFFSET=A-B*128+1
7050 CALL M("~Modify Rec#"&STR$(B)&" Offset: "&STR$(OFFSET)&" (y/n):",AJ,"YyNn") :: IF AJ>1 THEN CLOSE #88 :: GOTO 7110
7060 ON ERROR 7105
7070 LINPUT #88,REC B:B$
7080 C$=SEG$(B$,1,OFFSET-1)&RPT$(CHR$(0),128-OFFSET)
7090 PRINT #88,REC B:C$ :: CLOSE #88
7100 CALL C("~File updated") :: SUBEXIT
7104 CALL C("~** FILE ERROR, aborted") :: RETURN 7106
7105 CALL C("~** Processing error, aborted.") :: RETURN 7106
7106 ON ERROR 2670
7110 CALL C("~") :: SUBEND

[Shift838]

 

I added a routine in the BBS remote management functions to deal with the garbage characters. Essentially, you need to know the -real- size of the file from the PC side, divide that by 128 (record size of the DF128 file), and clear the remaining bytes. There might still be some tweaking you'll need to do. Anyway, here is that routine.

!Use:  CALL ANSIFIX(pathname$)
!P$ is the period-terminated pathname passed from the main program's remote disk catalog routine
!Note that this subprogram uses its own error handling during file IO, since you should not branch outside of a subprogram.  The main program's error recovery branch point is restored just prior to exiting, with the return stack adjusted if there was an error.
!CALL G is user/terminal input
!CALL C is display
 
7000 SUB ANSIFIX(P$)
7020 CALL G("~~(c/r) or FIX:\"&P$,10,A$) :: IF A$="" THEN 7110
7025 ON ERROR 7104 :: OPEN #88:P$&A$,DISPLAY,FIXED 128,RELATIVE,INPUT :: CLOSE #88
7026 OPEN #88:P$&A$,DISPLAY,FIXED 128,RELATIVE
7030 CALL H("~Total Bytes (PC):",6,B$) :: IF B$="" THEN 7110 ELSE A=VAL(B$)
7040 B=INT(A/128) :: OFFSET=A-B*128+1
7050 CALL M("~Modify Rec#"&STR$(B)&" Offset: "&STR$(OFFSET)&" (y/n):",AJ,"YyNn") :: IF AJ>1 THEN CLOSE #88 :: GOTO 7110
7060 ON ERROR 7105
7070 LINPUT #88,REC B:B$
7080 C$=SEG$(B$,1,OFFSET-1)&RPT$(CHR$(0),128-OFFSET)
7090 PRINT #88,REC B:C$ :: CLOSE #88
7100 CALL C("~File updated") :: SUBEXIT
7104 CALL C("~** FILE ERROR, aborted") :: RETURN 7106
7105 CALL C("~** Processing error, aborted.") :: RETURN 7106
7106 ON ERROR 2670
7110 CALL C("~") :: SUBEND

thanks. I'll work on getting this in Fusion and see how it goes.

 

So from reading this it looks like it just modifies the files if needed on the fly?

[+InsaneMultitasker]

thanks. I'll work on getting this in Fusion and see how it goes.

 

So from reading this it looks like it just modifies the files if needed on the fly?

Not quite... the BBS remote functions allow uploading files. After uploading an ANSI file using Xmodem, the file is modified by this routine manually. If you use the DFMSG routine, you can look for ASCII 0 as a stop character to avoid printing them. That's a separate function though.

[+arcadeshopper]

I have some rip stuff on thekeep as well in fact one or two online games support it

[Shift838]

I put in some code to have a basic RIP support for the a PreLogin page but that's it.

 

Not sure if I will go all out with RIP or not. It's all about how much time I want dedicate to learning RIP script.

 

So if you have access to a terminal that supports RIP graphics and you call just hit Y when prompted for RIP support and after you login you will see my basic RIP screen.

 

Also after creating it, i ended up not having to modify the RIP binary at all on the TI/Geneve. Just copied it over and it was in the required format already. So i bet with any RIP graphic i find I can just resave it within PabloDraw and it should come out fine.(more testing will be needed of course to make sure)

 

So that part was easy!

[+InsaneMultitasker]

Also after creating it, i ended up not having to modify the RIP binary at all on the TI/Geneve. Just copied it over and it was in the required format already. So i bet with any RIP graphic i find I can just resave it within PabloDraw and it should come out fine.(more testing will be needed of course to make sure)

It is possible/probable the RIP scrip contains its own end of file/end of processing 'marker'. The S&T assembly doesn't interpret the file stream when reading DF128 formatted files, so for ANSI files (or any DF128 transferred files) the last 128 bytes is a crapshoot based on what was uploaded, hence sometimes needing to 'fix' them.

Edited September 8, 2016 by InsaneMultitasker

[+arcadeshopper]

https://blog.cylance.com/cylance-discovers-multiple-critical-vulnerabilities-in-telegrafix-ripterm-v2.3