For those who don't know this yet!

All authors who write software for SPECCY need to know for a long time
the following:

++++++++++++++++++++++++++
1) Some computers do not have the KEMPSTON interface,
therefore programs that use KEMPSTON without checking for its presence _DO NOT WORK_.
The simplest program for checking for the presence of KEMPSTON, which just needs to be placed at the beginning of your program if
you suddenly want to use it, is given below.
IN A,(#1F)
CPL
AND #1F
JR NZ,M1 ; KEMPSTON exists

;
; all KEMPSTON keys are pressed => it does not exist !
; _DISABLE_KEMSTON_
......

M1 ; program continuation...

++++++++++++++++++++++++
2) Some computers have an unstable data bus, so
if you use the second interrupt mode (IM 2), then just
you need an interrupt table filled with one number 257 time.

++++++++++++++++++++++++
3) Some computers have unstable operation of the disco-
water controller (BETA DISK), so if you use direct programming
VG93, then it is simply necessary that there be a
number in register I _less_#C0_. Thus, taking into account point 2 of this
narrative, as well as the presence of computers with slow memory,
the optimal values ​​for register Iare:
a) for the first interrupt mode (IM 1):
I = #00 or I = #3F
b) for the second interrupt mode (IM 2):
I = #80...#BF - reliable, I = #C0...#FE - not always reliable.

P.S.
Me “lucky”, my computer “reacts” to all these 3 points.
When I see such a buggy program, the best thing I say is:
“Hey and the lamers @#$$%#@$@$.”
----Dla end--------------------------------------------------------
WBR,
Andrey.
... from Another World

13 Mar 98 20:02, Andrey Lysenko -> All:

AL> P.S.
AL> I was “lucky”, my computer “reacts” to all these 3 points.
AL> When I see such a glitchy program, then the best thing is that I I say:
AL> “Hey and lamers @#$$%#@$@$.”

Lamers are those who make buggy computers. And those who write programs on normal computers
that are buggy on buggy computers are lazy people who don’t delve into the idea
of writing software.

I wish you happiness and... good luck.
Andrey.

Hello, Andrey!

It’s quiet outside the window, and I’m sitting and writing a response to a letter written from Andrey Lysenko to
All Fri Mar 13, 1998 at 20:01...

AL> All authors who write software for SPECCY have long needed to know
AL> the following:

AL> ++++++++++++++++++++++++++
[blurred by rain]

Ja-ja... Do you think restaurants and releasers will pay attention to such a 'trifle'? This is below their dignity. An analogy is port 7ffd on Scorp. Scorpio is a very common computer. And coders often write shit without giving a damn about Scorpio users.

Somehow a long time ago, specifically Friday March 13, 1998 at 20:02 Andrey Lysenko
wrote All:

AL> 1) Some computers do not have the KEMPSTON interface,
AL> 2) Some computers have an unstable data bus, therefore,
AL> 3) Some computers have unstable operation of the disc-
AL> VG93 disk controller, then it is simply necessary that there be

4 in register I. Some computers do not have a keyboard, so the program must
be able to read the player's mind.

5. Some computers do not have a monitor. Since without a monitor
the user will not see anything, the program must detect this and display
the game situation on the speaker.

6. Some computer assemblers have unusually crooked hands. And instead
of sitting down and correcting all the above-described defects in an evening, they are trying
to force everyone to write under their _crooked_ iron.

AL> When I see such a buggy program, the best thing I say is:
AL> “Hey and the lamers @#$$%#@$@$.”
And what, are there still “craftsmen” who do not comply with these points?

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.

TY> It’s not the program that’s buggy, but the hands of those who can’t solder and who think like a butt.

AL>> the best thing I say is: “Hey and the lamers @#$$%#@$@$.”

TY> You should turn your humble gaze in your direction... and draw conclusions
TY> appropriate...
I completely agree with what Tim said above, why should a normal coder who writes
his own program on a normal computer be considered a lamer, and also have to listen to
some attacks from some comrades whose, excuse me, computer is in
shit.

TY> Yours sincerely, Tim. [Team Aries - Rulez Forever]

Wiz zE BeSt WisHeZ 2 U!
-=JoCkeR/OmEga HaCkErS Grp/1998year=-

AL>> When I see such a glitchy program, the best thing I say is:
AL>> “Hey and lamers @#$$%#@$@$.”

AT> Lamers are those who make glitchy computers. And those who write programs on normal computers
AT> that glitch on glitchy computers are lazy people who don’t delve into the idea
AT> of writing software.
Also a correct judgment, but a very mild one...

WBR,
Andrey.
... Another copy of SysOp is currently active! Aborting...

AL>> I was “lucky”, my computer “reacts” to all these 3 points.
AL>> When I see such a glitchy program, the best thing I say is:
AL>> “Hey and lamers @#$$%#@$@$.”

AL>> 1) Some computers do not have a KEMPSTON interface,
AL>> 2) Some computers have an unstable data bus, therefore,
AL>> 3) Some computers have unstable operation of the disco controller
AL>> creation of VG93, then it is simply necessary that in register I there be

14 Mar 98 15:51, Igor Gruzdev --> Andrey Lysenko ...

IG> Ja-ja... Do you think restaurants and releasers will pay attention to such a 'trifle'? This
IG> -
IG> is beneath their dignity. An analogy is port 7ffd on Scorp. Scorpio is a very common computer. And coders often write without giving a damn about
IG> Scorpio users.
I completely agree with this, but it’s worth repeating again.

AL>> When I see such a glitchy program, the best thing I say is:
AL>> “Hey and lamers @#$$%#@$@$".

IG> That's why the deme is cool. ;)
_ANY_ demy can be done well. (see Spirius _48/128_ ;)))

WBR,
Andrey.
... The r50 has two problems: lamellas and channels

AL> KEMPSTON,
I never use Kempston (and Sinclairs too, although they have been on my computer since birth), but I still had to attach its port (I didn’t install a connector :).
And all because of some programs that respond to it without looking at its
presence. :E~~

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and how does this relate to what is written at the very bottom?

TY>> Fix it, of course, it's broken? Or do you think that this is how it should be?
AL> About all three points - _SO_AND_SHOULD_BE_,

Oh, well? Why then is this not the case for 95% of Spectrum users? So, all of them have faulty Spectrums?
But their programs work, but yours doesn’t...

AL> and fixing points 2 and 3 is VERY difficult, but probably not for
AL> you...

I don’t see anything complicated. There are a bunch of tests that check the data bus for
stability. As far as I remember, the data in the interrupt confirmation cycle
can be "crapped" by either Kempston (old "Leningrads") or AY (which happens
much more often due to the widespread connection scheme on the 555ID7, in
which the 6th leg is thrown onto the body instead of feeding M1 onto it (27th leg
Z80). Serious alteration, really VERY Is it difficult to throw an extra wire?

Do you even know what exactly is crap on your data bus? If you don’t know,
try taking out AY and checking.

As for TR-DOS, this is an old problem that arose on computers with a separate memory field,
in which, when the screen controller accessed addresses, 4000-7FFF percent was hardware
slowed down by locking the clock frequency on the element OR. As far as I remember, the whole
problemwas that during the regeneration cycle register I was set to the highest address (A8-A15), while during the regeneration cycle the processor's MREQ signal is active (but RD and WR are inactive), respectively, if at the time of RAM regeneration (see Z80 cycle diagram) there is an access to the screen RAM from the display controller, then the processor is locked (although the actual access no to screen memory).
It is not much more difficult to treat - for example, in the “Moscow” and “Lvov” circuits
the -DRAMADR signal (sampling the lower half of RAM) is formed from A14 and MREQ on
the LL1 element, then the resulting signal is inverted on the LA3 element and
logically multiplied (AND) on the next LA3 element and goes to the controller display
and other places. The simplest solution is to connect the inverter (connected inputs
LA3) to a -REFRESH signal (28 leg Z80), which will require raising the leg of the
LA3 microcircuit and throwing a wire on it. Admirable work.

TY> I don’t see anything complicated. There are a bunch of tests that check the data bus for
TY> stability. As far as I remember, the data in the confirmation cycle
TY> of the interrupt can be “crashed” by either Kempston (old “Leningrads”) or AY (which
TY> happens much more often due to the widespread connection scheme
TY> on the 555ID7, in which the 6th leg is thrown onto the body instead of being fed to the
TY> M1 (27 leg Z80). Serious rework, is it really VERY difficult to throw in
TY> an extra wire?

You wrote everything correctly. But you know, not all Spectrum users
know how to hold a soldering iron. And many industrial crafts are characterized by
glitches and the absence of a paper circuit... Data bus instability
is sometimes deliberately sewn into hardware (the famous FF port) so that especially
crooked toys worked...
Hence the moral, the more variants of hardware the program works on,
the more competent is the one who wrote it. And it is best if access to non-standard hardware is realized using drivers...

Sincerely, George

TY> I don’t see anything complicated. There are a bunch of tests that check the data bus for
TY> stability. As far as I remember, the data in the confirmation cycle
TY> of interruptions can be “crapped” by either Kempston (old “Leningrads”) or AY (which
TY> happens much more often due to the widespread connection scheme
TY> on the 555ID7, in which 6 legs are thrown onto the body instead of apply to
TY> her M1 (27 leg Z80). Serious alteration, though it is VERY difficult to throw
TY> an extra wire?

TY> Do you even know what exactly is crap on your data bus? If you don’t know,
TY> try taking out AY and check.
Hey, well.. it’s not that simple. As far as I could understand, for me on the Pentagon this
all 2nd problems occur due to the Beta-diska.

TY> As for TR-DOS - an old problem that arose on computers with a separate field
TY> memory, in which when the controller is accessed screen to addresses 4000-7FFF
TY> the processor was slowed down by hardware by locking the clock frequency on the OR element.
TY> As far as I remember, the whole problem was that during the
TY> regeneration cycle, register I was set to the highest address (A8-A15), At the same time, in the
TY> regeneration cycle, the MREQ signal of the processor is active (but RD and WR are inactive),
TY> respectively, if at the time of RAM regeneration (see cycle diagramZ80)
TY> there is an access to the screen RAM from the display controller, then the processor
TY> is locked (although there is no actual access to the screen memory). Treatment
TY> is not much more complicated - for example, in the “Moscow” and “Lvov” schemes, the signal
TY> -DRAMADR (sampling the lower half of RAM) is formed from A14 and MREQ on the
TY> element LL1, then the resulting signal is inverted on the element LA3 and
TY> logically is multiplied (AND) on the next element LA3 and goes to the display controller
TY> and to other places. The simplest solution is to connect the inverter (connected LA3 inputs) to the -REFRESH signal (28 leg Z80), which
TY> will require raising the leg of the LA3 microcircuit and throwing a wire on it. The work
TY> is worthy of admiration.
This has all been known for a long time, but even if I didn’t have the Pentagon, I wouldn’t
correct it - you can immediately see how the program is written.

Hi, George!

25 March 98, George Shepelev writes to Tim Yunaev:

GS> You wrote everything correctly. But you know, not all
GS> Spectrum users know how to hold a soldering iron in their hands. And many industrial
GS> crafts are characterized by glitches and the absence of a paper circuit...
GS> The instability of the data bus is sometimes deliberately sewn into the hardware
GS> (the famous port of FF), so that especially crooked toys work... Hence the
GS> moral, the more variants of hardware the program works on, the
GS> more competent is the one who wrote it. And it’s best if access to
GS> non-standard hardware is implemented using drivers...

Driver for the FF coming soon port???

With best wishes - Andrey Khristov (ha...@robin.alt.ru)

[Team Horse Aviation] [Team beer, girls & sofa]
[Team Electric Welding Must Die!] [Team Khasan Border Guards]

GS>> You wrote everything correctly. But you know, not all
GS>> Spectrum users know how to hold a soldering iron in their hands. And many industrial
GS>> crafts are characterized by glitches and the absence of a paper circuit...
GS>> The instability of the data bus is sometimes deliberately sewn into the hardware
GS>> (the famous port of FF), so that especially crooked toys work... Hence the
GS>> moral, the more variants of hardware the program works on, the
GS>> the more competent is the one who wrote it. And it’s best if access to
GS>> non-standard hardware is implemented using drivers...

TY>> are corrected with two wires, in the worst case - with another housing
TY>> 555LE1.
AL> No. I have a Pentagon and this is a very cunning glitch, possibly associated with
AL> unstable operation of some microcircuit.

Hm-yes.

AL> You still advise me to change the board.

No, well, I’m just hanging around. And what about FIXING it (since you don’t know how to work with a soldering iron yourself) - weak? Or is this a principle? Repairs of this kind will cost you a bottle of beer.

AL> If you write programs normally, then on _all_ computers everything will be OK.

Well, no. On normal computers, let the programs run normally, but on buggy ones, let them be buggy. Everything is correct. Or eat fish - or .. ... ......

GS>>> You wrote everything correctly. But you know, not all
GS>>> Spectrum users know how to hold a soldering iron in their hands. And many industrial
GS>>> crafts are characterized by glitches and the absence of a paper circuit...
GS>>> The instability of the data bus is sometimes deliberately sewn into the hardware
GS>>> (the famous port of FF), so that especially crooked toys will work...

TY> Well no. On normal computers, let the programs run normally, but on buggy ones, let them be buggy. Everything is correct. Or eat fish - or... ... ......
Yes, let them glitch. And I will laugh at the authors of the programs, because they
do not know how to create a table of interruptions.

WBR,
Andrey.
... Winter. Cold. There is food in the stomach..

Somehow a long time ago, specifically Friday April 03, 1998 at 21:27 Andrey Lysenko
wrote Tim Yunaev:

TY>> To do this, you need to straighten your hands (yourself) and fix crooked hardware, and
TY>> don’t force everyone to adapt to your buggy computer.
AL> I’m not forcing anyone... I’m just stating a fact.

Everything is true. And I state the fact that it is impossible to foresee absolutely all the shortcomings of the hardware. And the author is not obliged to do this (although he _can_ do it
if he has the time and desire - especially for those who do not have the time (or
money) to bring their computer to normal condition - full compatibility
with the _branded_ Speccy-128)

TY> Well, this is where we had to start. It was necessary not to write about “lamers who don’t
TY> know how to write programs,” but about how the authors of programs, whenever
TY> have the opportunity
TY>, should also take care of the “orphan and wretched” who do not have the opportunity to fix their
TY> computer. For you, it turned out the other way around.
And if they don’t care, then they don’t care or they don’t know about such problems,
then: if they don’t care about some computers, then they don’t care about Speccy,
well, and if they don’t know about these glitches, then they found out. In any case, a
lamer is a lamer.

TY>>> Zonova, who is present in the echo), and even the readers of the echo -
TY>>> _should_ be like this or still _shouldn't_?
AL>> There should not be an error, but there should be the possibility of an error.
TY> No. Because there can be a lot of these “opportunities”. And you should not demand that y
TY> authors do “the way I think is correct,” but ask that you
TY> be told how to correct the defect.
No, not a lot. There are only three of them. And no one demands anything from anyone.
If you want your program to be buggy, please do so.

TY>>> programs, if possible, they also took care of the “orphan and wretched” who do not
TY>>> have the opportunity to fix their computer. For you, it turned out the other way around.
AL>> And if they don’t care, then they don’t care
TY> Naturally. Saving drowning people is the business of the drowning people themselves.
We are not talking about drowning people here, but about buggy programs.

AL>> or they don’t know about such problems, then: if they don’t care about
AL>> some computers, then they don’t care about Speccy,
TY> Absolutely illogical. For example, I don’t care about some buggy PCs.
It’s logical. Why don’t you care about Speccy? I noticed a long time ago.

Once upon a time, specifically Saturday April 11, 1998 at 03:43 pm Andrey Lysenko
wrote by Tim Yunaev:

TY>> You have three, and someone else will have three more, and someone else has a hole in
TY>> memory
AL> These three are the most common.

And my opinion is that one of the most common is the curve impulse Int
(length/beginning). Multicolor is pushing, right?

TY>> Now all authors should waste time just because someone
TY>> it may not work?
AL> What time are you talking about? Checking for Kempston and the table
AL> of interruptions can be done in 1 minute.

However, the interrupt table requires a lot of memory - 257 bytes in the most valuable place
- with 5b00-bfff.

And due to the lack of Kempston, sometimes you have to change the program algorithm.

TY> The program is normal if it works on the vast majority of
TY> computers. If
TY> it doesn’t work on a specific computer, it’s not the
TY> program that’s buggy, but this very computer.
And what happens when the vast majority of programs work, but a specific
does not? Which is immediately tailored to Campston and there is no way to reassign
controls?

Once upon a time, specifically Wednesday April 15, 1998 at 01:14 Denis Dmitriev
wrote Tim Yunaev:

TY>> However, the interrupt table requires a lot of memory - 257
TY>> bytes in the most valuable place - with 5b00-bfff.
DD> ^^^^ from #8000! This is where the glitches begin:(

What's wrong with the piece 5b00-7FFF in the _normal_ ZX-128?

TY>> And due to the lack of Kempston, sometimes you have to change the program algorithm
TY>>.
DD> What do you care about, sholi? Are you writing demos with Kempston?

I don’t write demos, I didn’t write and write I will never. Because it is a waste of
time. I never watch them.

And for a normal program/toy, providing for the absence of Campston will result in
writing additional code.

DD> A normal system program should _normally_ support standard
DD> devices.

Then. and a disk drive, a mouse, 256 or more memory, etc. - these are non-standard devices.

DD> And there is no need for excuses, such as the lack of Kempston - the problem of the machine.

Whose else?!?

DD> In your opinion, the Pentagon is a glitch? >8E And Kempston is detecting (If
DD> for you, writing a detector is more difficult than the program itself, then excuse me, I guess
DD> I made a mistake :)

An author who writes a program can generally only focus onyour
computer. And if you want to use it, please, fulfill the requirements necessary for its operation. If you can't do it, don't use the program. Logical?

TY> However, the interrupt table requires a lot of memory - 257 bytes in the most
TY> valuable place - with 5b00-bfff.
This is ~0.627% of 40K free memory - this is insignificant.
TY> And due to the lack of Kempston, sometimes the algorithm has to programs
TY> change.
This is not so. Usually a standard driver is made for everything: keyboard, joysticks,
various mice, etc. Many cool toys disable Kempston polling if
it is not there, although, as you said, the signature should be Kempston - however,
as practice shows, this is not the case.

Somehow a long time ago, specifically Wednesday April 29, 1998 at 07:52 pm Andrey Lysenko
wrote Tim Yunaev:

TY>> However, the interrupt table requires a lot of memory - 257 bytes in
TY>> the most valuable place - with 5b00-bfff.
AL> This is ~0.627% of 40K free memory - this is negligible.

More. From 5b00 to bfff - 25k.

AL> survey of Kempston if it is not there, although, as you said, the brand
AL> should have Kempston - however, as practice shows, this is not the case.

On 48 - it was not. On 128 - it was.

TY> On 48 - it wasn’t. On 128 - it was.

Where did you see him there? There was no Kempston on 128!

WBR, Alex Kovrigin <cre...@online.nsk.su>

... CD32PPC