Dickie troubles forever ;)

Thu 29 Apr 1999 at 17:06:37, Alex Noman => Oleg Grigoriev:

AN> Something MK shares some strange information with everyone. :)

With this to Mikhail.

OG>> By the way, I would recommend setting 38400. So cps is a little higher.

AN> Interesting...

Yes, in principle, everything is simple. Interrupts are less frequent, the main loop is not interrupted as often, and overall performance improves. A little bit... :) A little
greater result is achieved by optimizing the nmi handler procedure. After
long dances with a tambourine around the dosx source code, I managed to raise cps
by about a hundred... At the same time, I made dosx so that at startup it
maximizes the cache size, thereby increasing the buffer size and reducing
the number of accesses to the device. So cps is still a little higher. :)

WBR, Oleg.

29 Apr 99 you wrote here:

MK>> it won’t work higher ;) but in principle you can install any fifo
it
MK>> is no longer so critical.
EM> By the way, in 16650 fifo is implemented with an error.

So. I have TL16CFM504PJM. What is this? Is there an error there?
The doc says: UART - 16550, Serial Rate - 115.2K or 57.6K bps.

All the best.
Best regards Roman.

OG> Yes, in principle, everything is simple. Interrupts occur less frequently, the main loop is not
OG> interrupted as often, and the resulting performance increases.

Less, but the same. :)) What's the point? And the CPU drops a little...

OG> A little bit... :)

The performance of the IHT processor. :) Not NMI. In fact, I
always closed the key inside the handler, so no time was wasted on processing repeated HMIs and
the port was locked on the drum (115200). No bytes were lost (this is for the
doubters :) ).

OG> A slightly greater result is achieved by optimizing the
OG> nmi handler procedure.

I don’t know how your work with IHT is organized (in the sense that
HMI processing can have a significant influence on the processing of IHT and the latter will
arrive _significantly_ less than 50 times per second), so I admit that that 38400
is a reasonable compromise between an acceptable DSP and the operation of the system itself. :) I.e. you persuaded me. :). So cps is still a little higher. :)

The user is free to choose the cache size, IMHO... I didn’t like all sorts of copiers
that are such chaosarranged... It's not ps...

OG> WBR, Oleg.

With respect, Alex Noman.

OG> the main loop is not interrupted as often and the resulting
OG> performance improves. A little bit... :) Slightly
OG> results are obtained by optimizing the
OG> nmi handler procedure. After prolonged dancing with a tambourine around

RM> Yes. I have TL16CFM504PJM. What is this? Is there an error there?
RM> The doc says: UART - 16550, Serial Rate - 115.2K or 57.6K bps.

In short, define it programmatically. There in the UART register, which is responsible for fifo
(more precisely, EM will tell you after the holidays if I got something wrong, because I’m far from all
this already:( ) when reading, the two most significant bits should be set. If not
so, then you have a mikruha glitch...

RM> All the best.
RM> Best regards, Roman.

Respectful, Alex Noman.

OG>> optimization of the
OG>> nmi handler procedure gives better results. After long dancing with a tambourine around
OG>> dosx source codes, I managed to raise cps by about a hundred...

Then - yes. Exactly in 16550 there is already a fifo-buffer, but with a glitch.

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.

Mon 3 May 1999 at 19:12:39, Alex Noman => Oleg Grigoriev:

OG>> Yes, in principle, everything is simple. Interrupts occur less frequently, the main loop is not
OG>> interrupted as often and the resulting performance increases.

AN> Less often, but the same amount. :))

What is the same amount? Interrupts? Well, well...

AN> What's the point? And the CPS drops a little...

I love theorists. Everything works perfectly for them. I repeat: practical experiments
have shown that when locked at 38400 cps in the subject increases slightly.

OG>> A little bit... :)

AN> The performance of the IHT processor. :) Not NMI.

Performance of suckers/spitters.
By the way, what does the theory say about such a handler?

────[ File 1 .C begins here ]───────────────────────
#0066 push af
push hl
ld hl, (#5cb0)
ld a, h
or l
jr z, #70
jp (hl)
NMI_Proc: ld a, (_page)
ld h, a
ld a, _RAM_PAGE_SYS
call RAMMGR_SelPage
RAMMGR_SelPage: push bc
and 0x07
or 0x10
ldbc, 0x7FFD
ld (_page), a
out (c), a
pop bc
_ret: ret
call _Sio_IntHook
_Sio_IntHook: call Sio_IntHook
Sio_IntHook: push af
push hl
ld hl, _sio_int_flag
inc (hl)
jr z, @@free; ключ открыт - можно обрабатывать.
dec (hl)
pop hl
pop af
ret
ld a, h
jp RAMMGR_SelPage
RAMMGR_SelPage: push bc
and 0x07
or 0x10
ld bc, 0x7FFD
ld (_page), a
out (c), a
pop bc
_ret: ret
pop hl
pop af
retn

────[ Здесь кончается файл 1 .C ]────────────────────────

Каждое прерывание в диком исполняется подобная бандура.

AN> Я вообще-то внутри
AN> обработчика
AN> всегда ключ закрывал, потомуno time was wasted on processing repeated HMIs
AN> and
AN> the port lock was on the drum (115200). No bytes were lost (this is for
AN> doubters :) ).

Have you tried to count broken interrupts? I tried it - after
test pumping in the terminal I was horrified.

OG>> Optimizing the handler procedure
OG>> nmi gives a slightly greater result.

AN> I don’t know how you work with IHT (in the sense that
AN> processing of NMI can have a significant influence on the processing of IHT and the latter will
AN> arrive _significantly_ less than 50 times per second), therefore I admit that
AN> 38400
AN> is a reasonable compromise between an acceptable DSP and the operation of the system itself. :) That is,

Myler works fine at 57600. But at 38400 cps it’s a little higher. :)

AN> you
AN> persuaded me. :))

Nu-nu. :)

When? For example, now it is much lower than in winter. Again, I have Finnish
ATSK and AVU HF. Somewhere ~1600-~1700.

WBR, Oleg.

EM> Then - yes. Exactly in 16550 there is already a fifo-buffer, but with a glitch.

You're scaring people. :)) Let him check first...

EM> Good luck! Evgeny.

With respect, Alex Noman.

OG> I love theorists. Everything works perfectly for them. I repeat:
OG> practical experiments have shown that when locked at 38400 cps in the subject
OG> increases slightly.

Uh-huh... Only the theorists are all sitting in zx.spectrum and tormenting the emuls...

OG> The performance of suckers/spitters.
OG> By the way, what does the theory say about such a processor?

You yourself said everything in the line above...

OG> ────[ File 1 .C begins here ]───────────────────────

[...]

OG> ────[File 1 .C ends here]────────────────────────
OG> Every interruption in the wild is executed like this bandura.

Perversion, of course... And for some reason you didn’t completely throw away the handler, you are
our practitioner...

OG> Have you tried to count the broken interruptions? I tried -
OG> after the test pumping in the terminal I was horrified.

You bet... As long as you remove the interruption (judging by your creation above) -
20 more will come... ;)

OG> Myler works fine at 57600. But at 38400 cps it is a little
OG> higher. :)

Now it’s clear why. ;)

OG> dosx checked the cache in any case and if it was larger than possible
OG> - cut it.

Why checked and even cut it?

With respect, Alex Noman.

OG> When? For example, now it is much lower than in winter. Again, I
OG> Finnish ATSC and AVU HF. Somewhere ~1600-~1700.

You explain yourself wonderfully... About the modem, port, connection, software, protocol -
guess it yourself? But the telephone exchange is Finnish, huh?... ;))

For me it is not higher, but lower:(
OG> dosx checked the cache in any case and if it was larger than possible -
OG> cut it down.
OG> I got tired of setting the cache to unmeasured numbers before starting and I put
OG> this
OG> in dosx. I was too lazy to restore the original size. However,
OG> Mikhail
OG> too. :)
Yeah, that’s the culprit of all my troubles, that’s why the wild one didn’t work for me:(
Return the loot serrrrr:)

From the bottom of my heart Ciao, Oleg. [I ZX]

EM> I don’t understand these bourgeois markings. According to the state of the registers
EM> it is necessary to test...

Here. Do a visual test of the modem in S-Terminal. So that with its help you can test the modem. Or a separate program. :)

One day on Wednesday May 5, 1999 at 19:02:08 Alex Noman wrote to Dmitry Sharikov
on the topic 'Dickie troubles forever ;)':

OG>>> optimizing the handler procedure gives better results

AN>> That is,

OG> Myler works fine at 57600. But at 38400 cps it’s a little higher. :)
Ah moment!!! “At 57600” is the locking speed, or the connection speed?
Even if you set the locking to 115200, this does not mean that the bytes
arrive at this speed. In command mode - at a speed of about 9600,
in data transfer mode - approximately at the connection speed.
And about IHT, he is absolutely right. The experience of my C-Terminal shows that
with a fast connection, the clock actually starts to get a little off.

Friday May 07 1999 12:24, Roman Milukov wrote to Evgeny Milun:

RM> Here. Do a visual test of the modem in S-Terminal. So that with its help
RM> you can test the modem. Or a separate program. :)

EM also determines the uart type in the c-terminal. :)

DS> about cps... What doesn't look like? ;)

No, well, of course, I can make something like 700 or 2500... What does that tell you?
:))

Friday May 07 1999 08:53, Evgeny Milun wrote Oleg Grigoriev:

OG>> I love theorists.
EM> Is he the theorist??? Yes, he was the first to make an NMI handler,
EM> developing a connection speed of 33600. :)))

It was, it was... (shaking a barely noticeable speck of dust from the sleeve of his jacket). %)

EM> It was somewhere in that January.

Here, in general, it is more correct to say not when it was, but what was the state of
the software for the modem. There was only Melon, which was losing bytes even when logging 19200
and beta terminals under is-dos.

OG>> Everything works perfectly for them. I repeat: practical experiments have shown
OG>> that when locked at 38400 cps in the subject increases slightly.
EM> “Experiments have shown” that port locking affects the maximum
EM> possible connection speed. And no more! “Experiments have also shown” that
EM> the lock should be 1.5-2 times higher than the expected speed
EM> of the connection...

This is all true, but he, Zhen, is talking a little about something else. He has very good cumbersome handler and
therefore has a significant impact on the CPU.

AN> No, well, of course, I can cover up like 700 or 2500... O
AN> what does this tell you?
AN> :))

yes, about the fact that cps was equal to 700 or 2500... ;)
Does this mean nothing to you?

With best wishes, Dmitry.

AN>> what does this tell you? :))
DS> yes, about the fact that cps was equal to 700 or 2500... ;)
DS> Doesn’t this mean anything to you?

Absolutely nothing. Without knowing the quality of the line, modem, etc. - this info is an empty phrase.

Thu 6 May 1999 at 18:33:47, Alex Noman => Oleg Grigoriev:

AN> You explain yourself wonderfully... About the modem, port, connection, software, protocol -
AN> guess for yourself? But the automatic telephone exchange is Finnish, yeah?... ;))

DS already knows this. And I stopped myself from answering with soap. Well, since the public
is interested: usr14400, 38400, 14400/arq, subj, hydra, arcmail.

WBR, Oleg.

Fri 7 May 1999 at 05:48:55, Nikolay Maslennikov => Oleg Grigoriev:

NM> Yeah, that’s who is the culprit of all my troubles, that’s why the wild one didn’t work for me:(
NM> Return the loot serrrrr:)

I don’t quite understand, on the basis of what data you made such a conclusion? Only I have that
dosx, or rather it was.

WBR, Oleg.

AN> Perversion, of course... And for some reason you didn’t completely throw away the handler, practitioner
AN> you
AN> are ours...

I threw enough to clarify the issue. And anyone can
see the complete handler in the dosx source code, which was uploaded here twice.

AN> Of course... Until you remove the interruption (judging by your creation above
AN>)

This is not my creation. Mine looks like this:

────[ The zzz .C file begins here ]───────────────────────
NMI_Proc ld a, 1
_sio_int_flag equ $-1
inc a
jp nz, #70

ld (_sio_int_flag), a

NMI_Proc1 ld a, (_page)
ld h, a
ld a, _RAM_PAGE_SYS+#50
ld (_page), a
out (#fd), a
call freeZ
ld a, h
ld (_page), a
out (#fd), a

07 May 99 07:53, Evgeny Milun wrote to Oleg Grigoriev:

EM> Oh moment!!! “At 57600” is the connection speed, or the
EM> connection speed? Even if you set the lock to 115200, this does not
EM> mean
EM> that the bytes arrive at this speed. In command mode - at a speed
EM> of about 9600, in data transfer mode - approximately at the speed
EM> of a connection.

If you set it to 115200, then during TRANSFER the data can fly away at just
that speed. And come too. Only the connection must be with protocols
and the momed must support such a data transfer speed.

Kirill Frolov. [ZX]

RM> Here. Do a visual test of the modem in S-Terminal. So that with its help you can
RM> test the modem. Or a separate program. :)
Test it completely? I don’t even know for the presence/absence of what exactly it
can be tested for. :)))
And if you’re talking about the UART type, then it’s already done. :)

Tuesday May 11 1999 23:22, Oleg Grigoriev wrote to Alex Noman:

OG> DS already knows this. And I stopped myself from answering with soap. Well, since
OG> the public is interested: usr14400, 38400, 14400/arq, subj, hydra,
OG> arcmail.

You see, you have a 14.4 modem, but you advise everyone to set port 38400 without
mentioning this. ;) So who is the theorist there? ;)))

OG> About ordinary ones. The frequency of which is set during locking.

I always thought that when locking, the lock is set, and not the frequency of interruptions. :)
The frequency of interruptions depends primarily on incoming data. If the connection is
2400, then who the hell will the port be: 57600 or 115200. The frequency will not change.
You can check. ;) I already told you why your CPU is higher with less
skill.

OG> I threw enough to clarify the question. And anyone can see the full processor of
OG> in the dosx sources, which were uploaded here as much as
OG> twice.

I persuaded, I’ll take a look. :)

OG> This is not my creation. Mine looks like this:
OG> ────[ The zzz .C file starts here ]───────────────────────

It’s like better...

Fewer cycles. But here, in any case, a stack overflow and an “explosion” of the program are possible. You need a hardware gadget that blocks the NMI
signal before the first access to the modem ports. By the way, in the Kondratieff circuit there is
a free trigger (half of TM2) and everything can be done without adding a single
extra microcircuit.

OG> NMI_Proc1 ld a, (_page)
OG> ld h, a
OG> ld a, _RAM_PAGE_SYS+#50
OG> ld (_page), a
OG> out (#fd), a

BAD. Why - you should know.
There is a Pentagon-512-1024 and this program will fail there.
And not only will it fail, but it will also destroy the ramdisk on which
the system is located.

OG> call freeZ

A piece of the program that is meaningless and has an extra 27 clock cycles.
Or am I wrong? (I know that there is data from momed,
but why CALL? )

OG> ld a, h
OG> ld (_page), a
OG> out (#fd), a

You save cycles not where it is needed.

OG> pop hl
OG> pop af
OG> retn

And who will put it in (_sio_int_flag) value 0ffh ?

Kirill Frolov. [ZX]

AN> Absolutely nothing. Without knowing the quality of the line, modem, etc. -
AN> this info is empty words.

I agree... ;)
USR 14400 modem, we both have... (IMHO 1600-1800, this is steering)

With best wishes, Dmitry.

RM>> it was possible to test the modem. Or a separate program. :)

AN> EM also determines the uart type in the c-terminal. :)

It is necessary that the test results are not only determined, but also reported.

DS> I agree... ;)
DS> Modem USR 14400, we both have... (IMHO 1600-1800, this is steering)

No, well, 1800 when transmitting _non-packable_ data by modem on 14.4 is definitely steering.

%)

RM> It is necessary that the results of the
RM> test are not only determined, but also reported.

What needs to be tested? Just, please, not general words, such as modem, hardware, but specifically: we are testing such and such, the result should be such and such. Because I don't
understand why the test is needed. I've only encountered one problem so far - the modem
is not connected correctly and the computer hangs (the screen fills up beautifully through the stack,
apparently). There is no need for a test here. :)

RM> All the best.

DS>> steering)
AN> No, well, 1800 when transmitting _unpacked_ data by modem on
AN> 14.4 is exactly the steering wheel.

I download arcmail.
You are not confusing anything, as far as I know, if the data is not packed, then cps
more..

With best wishes, Dmitry.

RM> It is necessary that the test results are not only determined, but also reported.
It’s clear that it reports... :) That’s what it says “UART: xxxxx”.
By the way, I checked one scam with connecting to the PC, and now my
cherished dream has come true - I no longer need a second person to do/
check terminal. In. :)

DS> I download arcmail.
DS> You are not confusing anything, as far as I know, if the data is not packed,
DS> then the cps is higher..

Read the letters more carefully. ;) I specially emphasized the keyword. Precisely
_unpacked_, not _unpacked_. ;)