SYNCHRONET--------------- < Пред. | След. > -- < @ > -- < Сообщ. > -- < Эхи > --
 Nп/п : 1 из 100
 От   : Fzf                                 1:103/705         25 мар 24 14:18:58
 К    : Digital Man                                           25 мар 24 00:59:02
 Тема : SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 51502.sync@1:103/705 2a67f1e1
@REPLY: 51438.sync@1:103/705 2a55bd98
@TZUTC: -0700
@PID: Synchronet 3.19b-Win32 master/a2a9dc027 Jan 2
2022 MSC 1928
@TID: SBBSecho 3.20-Linux master/f2a017ec6 Mar 24
2024 23:24 GCC 12.2.0
@BBSID: FQBBS
@CHRS: CP437 2
@NOTE: SlyEdit 1.75 (2021-12-11) (ICE style)
  Re: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
  By: Digital Man to Fzf on Mon Mar 11 2024 07:32 pm

 DM> The latest and greatest sbbsexec.dll and dosxtrn.exe can be find in the
 DM> nightly builds of Synchronet for Windows:

 Thank you for looking into this. I apologize for taking all this
time to get back to you. Real life sometimes intrudes.

 DM> How did you determine the read/writes were "nonsense"?

 As I looked into what was going on I moved to lower and lower
level diagnostic programs until I finally just wrote my own to know
exactly what was being done on the program side.

 DM> Would happy to try address whatever issues with the UART emulation aren`t
 DM> working for you, but please update to the latest and get new/updated debug
 DM> log output and share with me.

 I had downloaded the latest SBBSEXEC.DLL the morning after you made
the initialization change and have tried it out. It`s working 100% along
with the version downloaded today! Pushing the UART hard also no longer
creates any errors or even any unusual debug log entries. Thanks again for
fixing this.

There are a couple of other issues I would like to mention.

 1. When SVDM uses an inherited socket (the -h option) no telnet
negotiations are done. As a result, the connection is assumed to be in ASCII
mode and server side CR characters are translated to CR/LF. Since most
programs are already transmitting a CR/LF this gets translated to CR/LF/LF
with the expected results. When using an external socket in telnet mode,
could SVDM set the
telnet.local_option and telnet.remote_option variables as so:

  A. Assume both remote and local have already suppressed GA and set the two
     options accordingly

  B. Set the remote telnet echo option to off and set the local telnet echo
     to follow the ServerEcho option from the .INI file

  C. Set both remote and local BINARY_TX options to follow the
ServerBinary option from the .INI file

 I don`t think it`s unreasonable to assume these have already been
set up when the telnet connection was initially made. If someone really
wants to change the behavior they could still do so by using the .INI
file options mentioned. The GA and echo options probably make no
difference now but leaving them unset might cause trouble somewhere down the
line.

2. Can anything be done to reduce the CPU usage?

 3. The VDMODEM isn`t importing target_ia32.props and thus is using
SSE2 instructions. SSE2 has been around for a little while now and it`s
fair to assume most everyone has it available. However, BBS users tend
to be more likely than the average person to be using what I`m going
to lovingly call `period correct hardware`. Many of the CPUs from that
era don`t have such advanced instruction sets. Could the instruction set
extensions be changed by using the target_ia32.props file? I do realize this
may be in slight conflict with #2 above.

 Thanks yet again for all the work you`ve done on this and for
fixing the issue I was having.

---
 ■ Synchronet ■ The Fool`s Quarter - fqbbs.synchro.net
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 50/109 103/705 154/10 218/700 221/1
240/1120 280/464 301/1 113
SEEN-BY: 341/66 463/68 467/888 712/848 3634/12
5000/111 5005/49 5019/40
SEEN-BY: 5020/715 848 1042 4441 12000 5030/49 1081
5054/8 5060/900 5061/133
SEEN-BY: 5075/128 5083/444 5090/958
@PATH: 103/705 301/1 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх