S-Terminal_v1.0: colored squares...

Does anyone have a terminal working? I have a subject. :)
At the same time, Melon and Dikiy work at 5+. :)

All hardware requirements stated in the description of the program -
are present. I also pressed “CS” when loading - 0 emotions. That is,
as long as you press it (CS) everything is ok, but as soon as you let go - subject. :)
After filling the screen with feces (colored squares), we fall out into BASIC_48.

p.s. The /NMI error has been corrected in the BASIC_48 ROM (which is quite natural for the Haes connection scheme by MK).

Sincerely, Felix.

[I ZX]

One day on Thursday September 23, 1999 at 01:06:23 there was a conflict
Felix Knajzev and All were arguing about S-Terminal_v1.0: colored squares...
I decided to add some heat to this dialogue

FK> All the hardware requirements stated in the description for the program -
FK> are present. I also pressed “CS” when loading - 0 emotions. Ie
[chewed and spat out]
FK> p.s. The /NMI error has been corrected in the BASIC_48 ROM (which is quite natural for the Haes by MK connection scheme).
Have you tried to see if the /NMI is coming to the processor?
Most likely these are hardware problems; for example, my sabje software works without
problems. Write what bells and whistles your car has.

With best wishes, Max Shashkin.

Once Thu 23 Sep 1999 at 02:06:23, while wiping dust from the monitor, I noticed how
Felix Knajzev was arguing with All on the topic of S-Terminal_v1.0: colored squares... and I
decided to join the bazaar:

FK> Has anyone got their terminal working? I have a subject. :)
FK> At the same time, Melon and Dikiy work at 5+. :)

It works absolutely fine. Only there is an unpleasant glitch in it - at the end of the transfer
zed does not detect the end of the file, the automatic activation of
reception does not work when they throw to us.

But in general - not bad. Works somewhat more stable than melon. CPS is approximately
the same for melon and wild.

p.s. Imho, for all this time that the author spent on the terma, it would have been possible to write
a really full-fledged terma, and even with a soaper... S-T is very similar to the
melon remix...

Sincerily yours,LEO/SG.

I got it fixed without any problems. Everything is great and on the 57600 box. True, I haven’t tried to connect.

All the best.
Sincerely, Roman.

FK>> natural for the Haes connection diagram by MK).
Roman Milyukov once had a similar problem. Roman, awww...
Where did you hang the condenser? (Yes, it’s okay if I squeeze this scheme of yours
into the trubshooting in my HP?)

MS> Have you tried to see if it reaches the processor /NMI.
MS> Most likely these are hardware problems, for example, my sabje software works
90% is a hardware problem.

MS> no problem. Write down what bells and whistles your car has.
Wrong. Tell me better, do you have an NMI modem “coordinator” with a standard magic button? Which one exactly? A glitch is possible there too.

Good luck! Evgeny.

■ The night is shorter than the day... The day will kill me... The world of illusions burns down in it. (C) Aria.

I didn’t let Dikogo in (I don’t “like” him) and Melon sometimes glitches :(
LM> It plows absolutely normally. Only it has an unpleasant glitch -
LM> at the end of the transfer zed does not detect the end of the file,
:(
LM> automatic activation of reception does not work when they throw
LM> to us.
:(
LM> But in general - works well. It works somewhat more stable than melon.
LM> CPS is approximately the same for melon and wild.
I realized that this is if the Fifo buffer is not used...

Be healthy, Leonid!
Anton Kriwoshea aka $k1v/M7H (orp.'99.

MS> software works without
MS> problems. Write down what bells and whistles your car has.

Specifically affecting MNI - none. I repeat: with another NMI handler in the subject, everything works. Today I spent the whole day trying to identify the cause of the glucodrome. I placed a 555TL2 in
immediate proximity
to the processor and passed through it (two series-connected gates) NMI - 0 emotions. I thought maybe the front was bad. I changed
the processor: it was THOMSON_Z80A,
I installed ZILOG_Z80B - 0 emotions.

The only noticeable difference between my computer and those where
the terminal works is quartz at 14.5 MHz (I have ('Leningrad-48Kb'
upgraded to 512K + a bunch more total).
On other computers (Scorpio-1MB, and another Leningrad-48 with
512K) quartz was installed at 14.0 MHz.

That's it, I didn't find any other differences...

LM>> It plows absolutely normally. Only there is an unpleasant glitch in it -
LM>> at the end of the transfer
LM>> zed does not detect the end of the file, it does not work
MS> explain in more detail

Let’s say someone throws something to me... It works for me like this: the entire file is received
up to the last byte, and then we hang.... i.e. We still see the z-modem frame on the screen. That's what I meant.

LM>> p.s. Imho, for all this time that the author spent on the term,
LM>> it would have been possible to write
LM>> a really full-fledged term, and even with a soaper... Already
MS> and you’ll try to implement ZMODEM from scratch, no one else has taken it up!

I agree. It's really difficult. (I saw the zed doc %-O )

LM>> S-T is very similar to
LM>> remix of Melon...
MS> in Melon even it was not erased, everything was written from scratch

Still ugly ;)
The design is terrible, although perhaps it is not needed there, but how nice it would be to see
beautiful frames, all sorts of buttons like Send, Receive, HungUp, Answer, etc. in
the top line, and click them with the mouse ;)))) (I certainly want a lot, but...)

Sincerily yours,LEO/SG.

AK> I didn’t let Dikiy in (I don’t “like” it) and Melon - sometimes
AK> is buggy :(

[skip]

*How* is it buggy? If this is version 1.80p (the latest) during auto-dial, then
Melon must be launched from boot, which
does RES_4,(IY+1) before starting BASIC files.

LM> It plows absolutely normally. Only there is an unpleasant glitch in it - at the end of
LM> the transfer, zed does not determine the end of the file,
Which zed? ZModem you mean? And what exactly is not detected there?
The ZEOF frame does not pass? What does it all look like?

LM> The automatic activation of reception does not work when they throw it at us.
It’s just not there yet. You need to read the documents. :)

LM> p.s. Imho, for all this time that the author spent on the term, it would have been possible to write a really full-fledged term, and even with a soaper...
Naturally... S-Terminal was written for almost two years. Only, this is in calendar terms. But in reality... Sometimes, as I wrote in the help, I didn’t go near the computer for months...
And I’m not going to include the soaper in principle in the terms. These are completely
different programs.

LM> S-T is very similar to the Melon remix...
1) Nothing similar. They even have different concepts.
2) When I started writing it in 1997, I had never even heard of Melon. I had
only two IS-DOS terminals.

LM> Let's say someone throws something at me... It works like this for me:
LM> the entire file is received
LM> up to the last byte, and then we hang.... i.e. On the screen we still
LM> still see
LM> the z-modem frame. That's what I meant.
Have you tried pressing enter, otherwise they say it helps? ;)
LM> Still ugly ;)
LM> The design is terrible, although perhaps it is not needed there, but how
LM> it would be nice to see
LM> beautiful frames, all sorts of buttons like Send, Receive,
LM> HungUp, Answer, etc. in
LM> the top line, and click them with the mouse ;)))) (Of course
LM> I want a lot, but...)
there it is written in black in Russian that the interface was made on the basis of Dos
Navigator, and not on the basis of Windows. And it would take a lot of memory

24 Sep 1999 you wrote here:

EM> Roman Milyukov once had a similar problem. Roman, awww...
EM> Where did you hang the condenser? (Yes, is it okay if I squeeze this circuit of yours
EM> into the pipeshooting in my HP?)

By the way, your terma just worked with a capacitor. :)
The problem I had was in the “lazy” (diode) element AND at the /NMI input.

EM> Naturally... S-Terminal took almost two years to write. Only, this is in
EM> calendar
EM> dimension. And in real life... Sometimes, as I wrote in the help, I didn't
EM> go
EM> to the computer for months...

How have you not forgotten what you're even writing? These
EM> are completely
EM> different programs.

It would be nice... ;) Although there is enough of the Wild... that's true, thinking out loud...

Sunday September 26 1999 19:22, Felix Knajzev ─── Evgeny Milun:

EM>> these are symptoms
EM>> of the NMI key not working properly. You keep getting new
EM>> and new
EM>> NMI captures, the stack is filling up, and...
FK> That's what I immediately thought. IMHO, it makes sense to use a slightly modified
FK> NMI handler. See below.
Already fixed. :) Now there is a tricky latch at the input of the NMI handler.

FK> Schmitt (555TL2) - 0 emotions. Changed processors - 0 emotions. In short: globally
FK> re-routed (more intelligently) the power buses for all my upgrades and... Subject
FK> started working. :) That's how things are. I repeat: Wild with DOSX, using
FK> interrupts works for me without problems.
This is because Kondratiev played it safe by making a latch, and I
considered it a waste of bytes and clock cycles, and did not do it.

FK> By the way, do you use RTS UART in the terminal when there is an overflow? buffer
FK> in the program?
Now - no because this should be optional - without sending the corresponding AT command, the modem still ignores RTS. As far as I remember.
Or am I confusing everything?
In any case... What kind of buffer are you talking about? File reception/
transmission buffer? It fundamentally cannot overflow. Internal
software fifo-buffer? So checks for its overflow in general for nowno.
Again, I figured that cases of its overflow would be so rare that
I didn’t even bother checking. Instead, I accelerated as much as possible
the function of entering data from the modem there, and removing them by external procedures.
In principle, of course, the check can be done, but... But not on receiving
data from the modem (where every clock cycle is precious to me), but on scraping them out of the fifo.
And there the program doesn't always fit. For example, when you work with the menu,
it is not called. So...

Why? The usual look of a non-sophisticated standard terminal program.

LM> The design is terrible, although perhaps it is not needed there, but how nice it would be
LM> to see beautiful frames, all sorts of buttons like Send, Receive, HungUp,
LM> Answer, etc.
Yep. And all this will work on machines with at least 512Kb. Yes? No,
thank you. I've already racked my brains over the problem of where to get memory for
macros and scripts that I'm going to make... Yes, and the log and file reception/transfer buffers are not that big... And YModem needs to be done, and a whole bunch of other things. And there is approximately only 10Kb in reserve. (Yes, and it’s also possible
I’ll make support for an extended screen... which means the size of the screen area
will double.)

LM> in the top line, and click them with the mouse ;)))) (I certainly want a lot,
LM> but...)
You want _very_ _a lot_.

RM> By the way, your terma just worked with a capacitor.
RM> :)
RM> The problem I had was in the “lazy” element (on diodes) AND on the
RM> input /NMI.
more specifically, plz message where you connected it, otherwise there is some uncertainty

FK>> buffer overflow
FK>> in the program?
EM> Now - no because this should be optional - without
EM> sending
EM> the corresponding AT command, the modem still ignores RTS.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Imho, by default (at&f) settings, most modems
immediately install hardware flow control (RTS/CTS).

EM> As far as I remember.
EM> Or am I confusing everything?

I meant “stopping” the stream from the com port (RTS=1) at an arbitrary moment
of time (at this moment the modem continues to put data into its own buffer.
if there was one, of course -> I had a 2400/none modem without a buffer and it
didn’t care RTS=1). After all, when receiving a file by some protocol
you dump data onto disk only due to
timeout time?

EM> In any case... What kind of buffer are you talking about? Buffer
EM> reception/
EM> file transmission ?

Exactly. I think you have it located at #6000? ;)

EM> It fundamentally cannot overflow.

I saw this there.

EM> Internal
EM> software fifo-buffer? So there is no check for its overflow
EM> at all yet.

No, not him.

EM> Again, I figured that cases of its overflow
EM> would be so rare that
EM> I didn’t even bother checking. Instead, as
EM> moreaccelerated
EM> the function of entering data from the modem there, and removing it
EM> by external procedures.
EM> In principle, of course, a check can be installed, but... But
EM> not on receiving
EM> data from the modem (there every tick is precious to me), but on
EM> raking them out fifo.

I have the following situation: a modem with a UART 16450 (without FIFO), the maximum speed
lok is 19200. If you “tell” the modem
that it displays a lot of profiles (a bunch of at&v, about 20 in the command
line), then in your term, even at a speed of 9600, sometimes it’s great
it knocks out characters, otherwise and whole lines. There is no such thing in the is-dos terminal by MK using RTS/CTS.

LM>>> It plows absolutely normally. Only there is an unpleasant glitch in it - at the end of
LM>>> the transfer is not determined by zed, the end of the file,
EM>> Which zed? ZModem you mean? And what exactly is not detected there?
EM>> The ZEOF frame does not pass? What does it all look like?

FK> ^^^^^^^^^^^^^^^^^^^^^^^^^
FK> IMHO, according to the default (at&f) settings, most modems
FK> immediately install hardware flow control (RTS/CTS).
Yes, I drove it. Arriving home and checking the documentation, I saw that I was wrong. Sorry.

FK> I meant “silencing” the flow from the com port (RTS=1) at an arbitrary moment
FK> of time (at this moment the modem continues to put data into its own
FK> buffer.
If the modem does not have a UART16550A (and my term recognizes this), then no
buffer simply does not exist!!!

FK> if there was one, of course -> I had a 2400/none modem without
FK> buffer and he didn’t care RTS=1).
No, he didn’t care. The idea is that it should inform the remote modem that it is not ready to receive data. And he, accordingly, must suspend
the transmission...
So, as they say, you asked the right question. :). In any file protocol, sooner or later the transmitter waits for a response from the receiver about normal reception. This is the expectation I take advantage of.

FK>> into its own
FK>> buffer.
EM> If the modem does not have a UART16550A (and this is what my term
EM> recognizes), then no
EM> buffer simply does not exist!!!
^^^^^^
I meant the buffer in the *modem*. What it is there is 100%. ;)

In fact, this was a mystery to me until recently. There are three possible situations here with RTS=1:

1. the modem “stops” the stream and continues to put data
into its *own* buffer.

2. The modem at the protocol level sends a command to stop transmitting to the remote
modem.

3. points 1 and 2 combined. :)

The presence of this very buffer is very well “felt” on 2400 in Wild
(arcmail-files):
immediately after dumping the cache (~4Kb) to disk, the first two
1Kb windows appear *obviously* faster than if this happened on 2400. That is. they
(these 2Kb) had already been received and were sitting in the modem, and as soon as it (the modem) was given
RTS=0, they fell out as quickly as the com port.

Once on Friday October 1, 1999 at 14:46:00, while wiping dust from the monitor, I noticed
Evgeny Milun and Leonid Mishankov arguing on the topic S-Terminal_v1.0: colored
squares...
I decided to insert my word:

EM> Are you sure that it is exactly hangs, but does not report
EM> successful completion and
EM> does not wait for any key to be pressed?

It hangs, but after a while it says that everything is ok and press any key.

LM> I suppose it’s a pity for the memory, huh? :)
Yes, not so much memory, but simply not having this gadget on my computer. :)

LM> P.S. Another “glitch” turned out to be when I enter the Upload menu and read the
LM> directory, the DTR twitches and the momed hangs up...
Wow!!!!!! We need to check. If it is the DTR that is twitching, then most likely I
will quickly find it and fix it!

LM> Apparently, there is something wrong with the settings in the modem, but what?...
No, not with the settings. There really is such a glitch. But, only you were the first to notice DTR. The fact is that if DTR disappears for even a fraction of a second, then the modem will actually hang up because... DTR is nothing more than a signal to the modem
from the computer “I’m here, hanging on the wire. If you need anything, kick me
with an interruption.”
And if it’s really because of DTR, then I know where the problem is!

FK> ^^^^^^
FK> I meant the buffer in the *modem*.
What am I talking about? :)

FK> That he is there is 100%. ;)
Hmm. As they say, you can write anything in the dock, but if a specific piece of hardware does not respond to a specific command, then processing of that command is not built into it. What I mean is that the c-terminal, according to all the rules, identifies the currently known types of hardware. If it finds a device with
fifo (and one that works normally), then it turns on support for this
fifo-buffer.

FK> In fact, this was a mystery to me until recently
FK>. There are three possible situations here with RTS=1:
FK> 1. the modem “stops” the stream and continues to put data
FK> into *its own* buffer.
Nope.

FK> 2. the modem at the protocol level sends a command to stop transmitting
FK> to the remote modem.
Wow! It! That (remote modem), in turn, must reset the CTS signal,
indicating to the remote program that the modem is ready to transmit.

FK> 3. points 1 and 2 combined. :)
Nope, nope. True, I took all this from books. In practice, I have not
checked this...

FK> The presence of this very buffer is very well “felt” on 2400 in the Wild
By the way, IMHO you are mistaken... Fifo-buffers first appeared only in
high-speed (!) modems. Those. on modems,designed for speeds from somewhere around
9600! On 2400, not only did they not exist yet, but they were not needed.

FK> (arcmail files):
FK> immediately after dumping the cache (~4Kb) to disk, the first two windows of
FK> 1Kb appear *obviously* faster than if this happened on 2400.
Well...

FK> That is,
FK> they (these 2Kb) had already been received and were sitting in the modem,
Even the fastest modem with the most advanced UART16550A has a buffer
maximum of 14 bytes!!!! The current size is affected by the sixth and seventh bits in the buffering control register. So, you are clearly confusing something.

FK> and as soon as it (the modem) was given RTS=0, they fell out quickly
FK> com-port locks.
According to RTS=0 they should not fall out at all because this situation means that
DTE (computer) is not ready to exchange data with DCE (modem).
You are clearly confusing something!

EM> Well, as soon as they learn to build a mathematical
EM> coprocessor into the Spectrum,
EM> then right away! :) But seriously, do you know _how much_ time it takes the processor
EM> to calculate the same cps? A lot. If you throw out this calculation, then cps,
EM> which, however, will not be taken into account, will increase...

oooh... Sorry, I didn’t know... But it’s used for drawing. file jump state
it is enough to divide once at the very beginning of the file, and then using
the resulting coefficient, draw a line, even if it is 1 pix thick...
The same CPS... One division for each block... Is it really that long? Although
really long... And if you divide according to the table?

LM> No, no... Tell me! And then I was already interested... All sorts of half-duplex ones, etc. modes are also of interest...
Hmmm... Duplex - when the exchange occurs simultaneously in both directions.
Half-duplex - when it takes turns. Asynchronous mode of operation - to put it simply,
working on events; when a byte is read only when it is known for certain that it has arrived; in this case - when the modem tells the computer
"Well, this... tavo... And they sent you a new byte, go ahead, take it, stop calculating the CPS here. Here you take it, and continue.". Synchronous - accordingly,
in order to receive the next byte, you need to constantly poll the modem “Don’t you have a new byte there, huh? Otherwise, I really want to. Please!”
Well, there you go. :) So, Melon works in synchronous mode, i.e. All the time
possesses the modem. If you went into the menu somewhere and the poll did not happen, then
you risk losing data. As a consequence of all this, as a rule, exchange with the modem occurs in half-duplex mode, i.e. being in the process of transmitting a byte,
it is no longer possible to accept the incoming one. S-Terminl - asynchronous mode. As a consequence... Well, do you already understand? Otherwise, I’ve actually already started giving a lecture. :)

I got confused. RTS=1.

FK>> speed
FK>> com port locks.
EM> By RTS=0 they should not fall out at all because this
EM> situation means that
EM> the DTE (computer) is not ready to exchange data with the DCE (modem).

Well, finally! What am I talking about?! With RTS we control the flow from the modem, allowing or disabling it at the desired *we*
time. By and large, it is not so important to us how
this happens *in the modem*.

EM> You are clearly confusing something!

Have you figured it out already, IMHO? ;)

[skip]

EM> coprocessor, right away! :) But seriously, do you know how much time it takes the processor to calculate the same cps? A lot. If this
EM> calculation is thrown out, then cps, which, admittedly, will not be taken into account in this case,
EM> will increase...

And you ask the demomakers how they calculate 3D on the Z80!
You can calculate from tables, although not very accurately.
And what difference does it make to you - the bytes on the NMI from the momet are pouring in,
calculating time will only take up free bars.

Kirill Frolov. [ZX]

08 Oct 99 18:32, Evgeny Milun wrote to Felix Knajzev:

EM> By the way, IMHO you are wrong... Fifo-buffers first appeared
EM> only
EM> in high-speed (!) modems. Those. on modems designed for speeds from
EM> somewhere around 9600! Not only did they not exist on the 2400 yet, but they weren’t needed.

But I have a momed on the 2400 and it doesn’t need any fifa.
It’s EXTERNAL!!!
Then think for yourself, in the stump where it’s connected there’s a fifo.

FK>> (arcmail files):
FK>> immediately after dumping the cache (~4Kb) to disk the first two windows of
FK>> 1Kb appear *obviously* faster than if this happened on
FK>> 2400.
EM> Well...

Then there is a buffer in Momed, in fossil... On my 2400, 16 kB flies away
instantly, and then wait half an hour until transmitted...

EM> And the memory for it?

Here we go again... Well, install SIMM for yourself and don’t worry... 128kb is too pathetic
for today. 256kb is the minimum, 512kb is normal. Minimum modifications.

[Skipped]
EM> Hmmm... Duplex - when the exchange occurs simultaneously in both directions.
EM> Half-duplex - when in turns. Asynchronous mode of operation - in a simplified way
EM> speaking
[Skipped]

yeah... And it is precisely because of the synchronous mode of operation in Melon that CPS is slightly lower
than in ST1.0?

Isaev made this strip in unzip. No problems/brakes etc...You calculate
to-t, build a table, at the end of each block you go through this table from the end,
compare...

Sincerely,
Renat

KF> And you should ask the demo makers how they calculate 3D on the Z80!
Since our demo, written by Shurik, took 2nd place this summer, and
I know Shurik quite well (from college), then...

KF> You can calculate from the tables, although not very accurately.
“Not very accurately”, that’s how much ?

KF> And what difference does it make to you - the bytes on the NMI are pouring out of the momet,
What difference does it make to me? Yes, just the kind that I want, so that I
have a normal program, not some bullshit...

KF> calculating time will only take up free clock cycles.
S? Did you understand what kind of nonsense you were talking about, or should I explain?

KF> Now think about it - in V42bis data can fly in blocks of 256 bytes,
KF> and you are delusional about 14 bytes.
Sorry, Kirill, but have you ever seen at least one book about
modem programming ?

KF> After all, until the entire block is received, you don’t count anything from the modem,
Where did you pick up such “data” from? What do you care? Give as an example the frame format of your favorite V42bis? Otherwise, it’s easy, the book and the detailed
description are now lying next to me, on my left hand... Come on? Just then
don’t say that it was I who sat you in a puddle of fragrant feces.

KF> There’s no need for fifo here - internal mom
You, I’m sorry, do you actually know what the difference is between internal and external
momed? Find out first, and then talk nonsense...

KF> will be able to give you 256 bytes right away, the external one will slow down with the port.
KF> But it may not be like that.
RTFM, I apologize

FK> We chronically misunderstand each other. I don't mean a fifo-buffer, but
FK> some part of the modem's RAM
Y? Then, we really don’t understand each other... FIFO is one of the
principles of organizing any section of memory intended for storing
any randomly received data.
The hayes modem has memory designed for 14 bytes, and organized according to the FIFO principle (First In First Out - first to come, first to leave). And I'm talking exactly about her. And what are you talking about?

FK> (it certainly exists.
I repeat once again - it is only available on high-speed modems...

FK> The operation of the compression protocol would be impossible without it)
Well?

FK> for storing already received data and gradually “injecting” them into the fifo.
Hmm.... You you're buggy!

LM> Here we go again... Well, install SIMM for yourself and don’t suffer...
Honestly? When I install it, then I won’t suffer. :) In the meantime, I'm struggling
with the production.

LM> 128kb is too
LM> pathetic for today. 256kb is the minimum, 512kb is normal. Modifications
LM> minimum.
...if you have no other modifications.

EM> Y? Did you understand what kind of nonsense you were talking about, or should I explain?

You were talking nonsense. What do you do between interruptions?
Are you spinning around in the loop? Well, hang a strip on personnel interruptions.

Kirill Frolov. [ZX]

EM> And there are simply no others visible to the program!!!

But only the speed of bytes entering the fifo for the external
and internal memory may differ.

Kirill Frolov. [ZX]

KF> You were talking nonsense.
Sorry for the harshness I expressed...

KF> What are you doing between interruptions?
KF> Are you spinning around in the loop? Well, hang a strip on personnel interruptions.
I meant that memory is needed.

EM>>>> 9600! At 2400, not only did they not exist yet, but they were not
EM>>>> needed.
FK>>> Yes, I’m not talking about fifo. 8-)
EM>> And there are simply no others visible to the program!!!

[skip]

KF>> They have at least 32 kilos of brains,
EM> What?????????????!!!!!!!!!!!! Where did you see/read this
EM> ??????? Are you sure
EM> that you didn’t get high before this?

Calm down, Zhenya. There is no need to get so excited. My modem (2400/v42bis) also
has SRAM_62256 (32Kb).
And the other (burnt) modem also has it.
This is the modem RAM for the data compression protocol
(v42bis/LAP-M). The data is placed there before packaging and the unpacked data is stored there as well. It is this buffer that I had in mind, the stream from
which can be controlled by RTS.
The size of the dictionary for packaging (which is also located in these 32Kb), by the way, can also
be changed using modem commands.

EM> S? Then, we really don’t understand each other...
EM> FIFO is one of
EM> the principles of organizing any section of memory
EM> intended for storing
EM> any randomly incoming data.
EM> The hayes modem has a memory designed for 14 bytes, and
EM> organized according to
EM> the FIFO principle (First In First Out - the first to come, the first
EM to leave). And I'm talking about her. What are you talking about?

Are you saying that these 14 bytes of FIFO are the entire memory of the *modem*?! :)
This is a feature of advanced UARTs. There's still a ton of brains in the modem.
That's what we're talking about.

KF>> interruptions.
EM> I meant that memory is needed.

Take the example from Windows.... It won’t fit into 128kb already?

Kirill Frolov. [ZX]

KF>>> What do you do between interruptions?
KF>>> Are you spinning around in the loop? Well, hang a strip on personnel
KF>>> interruptions.
EM>> I meant that memory is needed.

FK> Are you thinking that these 14 bytes of FIFO are the entire memory of the *modem*?! :)
First of all, no, of course. :) This is the memory that is easily visible to the program without using AT commands (the existence of which, by the way, the terminal has no idea about since they are external to it.).
Secondly, we are all terribly glitched. Because I was obviously focused on the FIFO buffer
of the UART because... I'm already so used to internal modems that I've somewhat forgotten that the com port also exists separately. :)

FK> This is a feature of advanced UARTs. There's still a ton of brains in the modem.
FK> That's what we're talking about.
Got it. Did I drive.

FK> to FIFO? Directly from the DSP?!
Got it. :)

FK> I'm crazy, dear editors. :) This, after all, was the whole point of
FK> this flame: the ability to control the flow from the UART using
FK> RTS.
So the funny thing is that I didn’t deny this either. :)) Only I thought in categories, counted/wrote the UART register, and you “how many bytes will one modem transfer to another, and where will they put them.” This is what confused me.

FK> p.s. Okay, shall we replace it? ;)
Well, I screwed up... Big deal.

FK> Calm down, Zhenya. No need to get so excited.
Yes, sorry...

FK> I also have SRAM_62256 (32Kb) in my modem (2400/v42bis).
I slowed down here. You, as I later understood, were talking about which microcircuits
were soldered, but I was talking about what was visible to the program.

FK> And in the other (burnt) modem - it is also there.
FK> This is the modem RAM for operating the data compression protocol
FK> (v42bis/LAP-M). The data is placed there before packaging and the already unpacked data is stored there
FK>. It was this buffer that I had in mind, the flow from
FK> of which can be controlled by RTS.
That's the point, that this buffer is a private matter of the modem, and it is actually impossible to control
it. As I already said, removing RTS leads to removing CTS
on the remote modem.

FK> The size of the dictionary for packaging (which is also in these 32Kb), by the way,
FK> can also be changed using modem commands.
Everything is clear. We were just really talking about different buffers...

EM> It depends what else is there. I can already say that 128Kb may
EM> be not enough.

This already smacks of pissism. Then in the next version of the Z80 it will not be enough?
Turbo mode is required?

Kirill Frolov. [ZX]

EM> First of all, no, of course. :) This is the memory that is easily

Secondly, not 14, but sometimes even 56 bytes.

EM> is visible to the program without using AT commands (the existence of which,
EM> by the way, the terminal does not even know about because they are external to it.).

What other commands?

EM> Secondly, we were all terribly glitched. Because I was obviously obsessed with
EM> UART's FIFO buffer because... I'm already so used to internal modems that
EM> I forgot a little that the com port also exists separately. :)

These are generally different things.

You can see that there are 14 bytes, but if you take 1 from there, it does not mean at all
that there will be 13 of them.

It’s better to tell us if you know how the modem distinguishes “+++” from data.

Kirill Frolov. [ZX]

EM> That's the point, that this buffer is a private matter
EM> of the modem, and it is actually impossible to manage
EM> it. As I already said, clearing RTS
EM> leads to clearing CTS
EM> on the remote modem.

Are you *100%* aware of this?

[skip]