GLUE-FREE GLITCH SCHEME

It was 18 Dec 98 and 17:54:15, Roman Milukov wrote to Kirill Frolov
on the topic GLUE-FREE GLITCH SCHEME
Not seeing a moderator nearby, I decided to insert a word:

KF>> P.S. I forgot to add - the clock is not prohibited by bit 7 #еff7.
KF>> Because it is
KF>> sax and masday.

RM> Well, now your program won’t be able to work for me. What kind of
RM> scheme is
RM> Gluck? More likely the FK0 scheme.
RM> :)))
RM> Masdai is not a masdai, but it is desirable to have additional information protection in
RM> CMOS.
RM> There *MAS* hid his watch under TR-DOS...

There will be no protection - if someone wants to deliberately spoil the information, then
he will do it. And in the case of various glitches not related to human hands
damage to information is unlikely, I even believe that it can be
damaged there faster from power problems than from a program that followed the path of
colored squares and 48 BASIC...

Putting _any_ devices into tr-dos, as well as the drive controller, I consider
one very big stupidity. This greatly complicates access to the devices placed there
and makes it almost impossible to work with interrupts,
especially with the Kondratiev interrupt circuit from the modem. I was so frustrated that I made such a mistake with this that without hesitation I decided to remake it to fit the glitch scheme.

RM>I haven’t seen any docks on DALLAS.
RM> (And we can’t find DALLAS ones either.)
RM> But in ZXNews-35, it seems, they wrote that this is a complete analogue of the 512VI1, only with
RM> a battery and quartz. And I saw a very detailed document on VI1.

There are 2 modes of accessing registers. In one, the r/w input is used as
a recording strobe, and in the other as the direction of information transfer. In Dallas
there is only the first mode, and in the glitch scheme the second was used.

RM> So, it has such moments when you cannot access the time cells.
RM> And you ignored this in your time setter for Lara! :-/

I know. This is my glitch. This way you can get the wrong time.

RM> wait, otherwise you will receive incorrect information. If it is reset, then
RM> you have
RM> at your encoder disposal only 244 μs.
RM> (The duration of the time update cycle is 1984 μs with quartz 32.768 kHz.)
RM> The interrupt value must be disabled at any time.
RM> And then it is not necessary to start the /RD signal.
RM> But it is possible. :)
RM> Or add M1 to ID7.

No. Disabling interrupts is not always possible. Therefore, it is necessary to make the hardware
deliberately bug-free, especially since it is not so difficult.

I did not use 7 bit #eff7 for one reason - there is still a screen hanging there,
a latch for the upper memory and a bunch of unknown things, there is even a color palette.
And I haveNothing has gone wrong yet because of this bit. It is difficult to use it in
programs due to the unknown value for #eff7. Although in the case of melon or lara everything is clear.

With best wishes, Kirill Frolov.

RM>> detailed.

KF> There are 2 modes of accessing registers. In one, the r/w
KF> input is used as a
KF> recording strobe, and in the other as a direction for transmitting
KF> information. In Dallas
KF> there is only the first mode, and in the glitch scheme the second
KF> was used.

Oh! 512VI1, it turns out, is cooler than DALAS! ;)
Yes, only the first mode is suitable for DALAS, and both are suitable for VI1. And the second
method requires fewer details.

KF> No. Disabling interrupts is not always possible. Therefore,
KF> it is necessary to make the
KF> hardware deliberately bug-free, especially since it is not so
KF> difficult.

is an extra element!
(...although I still have it left unused for now. Start M1
through it or something?)
:) OK. Convinced. As soon as I get my hands on it, I’ll do it. It was completely bug-free. :)

KF> I did not use 7 bits #eff7 for one reason - there is
KF> still a screen, a
KF> upper memory latch and a bunch of unknown things, sometimes even a
KF> color palette.

What do you care? Let it hang!

All the best.
Roman.

Please explain, Mr. Frolov, your idea:
I understand that you leave interrupts enabled
and read the ready bit. He writes to you that everything is ok.
At this moment an interrupt arrives, runs smoothly,
and your program reads further data from, say, the clock register. But time was lost (And years, years go by! (c)
Chekhov, if I’m not mistaken) and the microcircuit, at my whim,
ceased to be ready for data output (the
Great Moment of Renewal had arrived). Formally, everything will work out,
only we will get incorrect data.
Having calculated the probability of this event, you can
give up on all this, but if you are striving for subj, then
this should not be overlooked...

By the way, according to rumors, your date installer in Laru is guilty of
not checking the data for readiness...

Correct me if I'm wrong...

KF>> I did not use 7 bits #eff7 for one reason - there is
KF>> still a screen, a
KF>> upper memory latch and a bunch of unknown things, sometimes even a
KF>> color palette.

RM> My understanding is that you leave interrupts enabled
RM> and read the ready bit. He writes to you that everything is ok.
RM> At this moment an interrupt arrives, is successfully processed,
RM> and your program reads further data from, say, the clock register
RM>. But time was lost (And years, years go by! (c)
RM> Chekhov, if I’m not mistaken) and the microcircuit, at my whim
RM>, ceased to be ready for data output (the
RM> Great Moment of Renewal has arrived). Formally, everything will work out,
RM> only we will get incorrect data.

It’s not that bad. The bit is set before the start of the update for some
time t1. And if reading data from the clock and processing the interrupt takes less
time than t1, then everything will be successful. Well, or you can check in the interrupt processing procedure whether the ready bit was read from the clock and if so, then read this bit again. The remark about the loss of time is of course
valuable, but disabling interrupts is not the only and not the best way, especially
on the Spectrum, where there are some problems with their loss.

RM> Having calculated the probability of this event, you can give up on all of this
RM>, but if you are striving for subj, then
RM> this should not be overlooked...

What happens if I forget to disable interrupts in a buggy circuit glitch?
I can easily get a flight to 48 BASIC.And the probability here is greater than in
the case of an error with the ready bit.
And finally, the wrong time does not always end in the termination
of programs, as in the case described above.

RM> By the way, according to rumors, your date installer in Laru sins
RM> by not checking the data for readiness...

Sclerosis however. :-(

As I have already seen, you are not striving for this...

KF> What happens if I forget to disable interrupts in the
KF> buggy glitch circuit?

Sorry, but you are going off topic... If a programmer forgot to do something, that is only his problem, and not the hardware
with which he works. Competently written programs
(some of mine, for example :-) do not waste time... The same driver
clock in IS-DOS, as you know, hangs on IM 2, and nothing
problems arise.

KF> I can easily get a flight to 48 BASIC. And the probability
KF> here is greater than in
KF> the case of an error with the ready bit.

If I understand you correctly, are you afraid that VI1 will begin to respond
to an INT request and dump the contents of its register onto the bus?
It is generally accepted that the IM 2 vector must have the full length (257
bytes), so this should not cause a problem...
However, I repeat - desynchronization hours relative to
the frame interruption signal is the worst of solutions.

KF> And finally, the wrong time does not always end
KF> with termination
KF> of programs, as in the case described above.

The already mentioned date installer will set the time incorrectly,
since it passes only once at startup. It's another matter
if the walkers on the screen don't control anything - they just glitch,
although this is unpleasant and is by no meansindicator
of the programmer's intelligence level... :)

RM>> What about you? Let it hang!

KF> What should I write to port #7ff7 to work with the clock???

Anything! :) We are apparently talking about #EFF7...
Here, another solution came to mind - since you are a supporter of
extra cases - make this port readable...
:)

RM> Exactly - later. To avoid it later, you need
RM> to read a copy of this port from the clock ONCE (as I
RM> called on everyone) and then configure all calls to the clock
RM> according to this copy. Naturally, all manipulations
RM> with #EFF7 should be reflected on this copy... But it seems

Does anyone write it there?
Do you know such options when #eff7 is there, but there is no clock?
And on this port they hang from the palette to the memory management bits.

RM> this option is not for you - in my opinion, it’s easier for you to hang a couple of
RM> dozens of extra buildings. I'm sorry.

If you think about it like that, then the circuit (ts) is a complete crap glitch. It requires
installation of 512VI1 (you also need to look for it), quartz at 32768 Hz
worth $1 (!) and a bunch of transistors, resistors, capacitors, etc.
The glitch circuit does not work with Dallas. DALLAS COSTS $1.

To ensure the operation of Dallas, 4 microcircuits were required in the scorpion,
and not a couple of dozen. And the circuit in the general case is simpler - quartz is not needed,
not a single resistor, capacitor, transistor or diode, NO BATTERIES NEEDED.

RM> Well, another solution came to mind - since you are a supporter
RM> of extra cases - make this port readable...

No one will read it. And I'm happy with everything as it is now - all my programs work. And the fact that my programs don’t work
on other computers doesn’t bother me much.

RM>> reading...

KF> No one will read it. And I'm happy with everything as it is
KF> now --
KF> all my programs work. And the fact that my programs do not
KF> work
KF> on other computers does not bother me much.

I can personally promise - everything that I write hourly
in the future will not work for you! :)

I just meant that you are apparently a programmer with a soldering iron;
trying to solve problems (non-existent, however) of hardware
by making it (hardware) more complex. I still don’t understand
why it’s impossible to synchronize clock polling with interrupts...

Never would this problem force me to take up a soldering iron
let alone announce it to everyone...

with RESPECT, Renat.
--- they asked to change the tireline...

KF> If you think like that, then the circuit (c) is a glitch and is complete crap. She

Why did I deserve a mention in my address ^^^^^??? Twice already you have allowed yourself to express yourself in this way in the presence of all the people... I know the words even better. And waaaay more I killed people like
you in childhood with a slingshot :)))) (c) Vadim.

KF> requires
KF> installation of 512vi1 (you also need to look for it), quartz at
KF> 32768 Hz
KF> worth $1 (!) and a bunch of transistors, resistors,
KF> capacitors etz.
KF> The glitch scheme does not work with Dallas. DALLAS COSTS $1.

V1 - they gave it to me. Here I cannot find Dallas (oh trembling! :)) for
the sprinter until now...
Quartz of the specified frequency is available in any (almost) wrist
(and not only) watches...
It was easier for me to find the components I specified and I wrote
a little bit of software for this purpose. True, the situation with the software
has still remained the same... This is where you need to transform your raging
energy :).

KF> To ensure the operation of Dallas, it took 4
KF> microcircuits in the scorpion,
KF> and not a couple of dozen. And the circuit in the general case is simpler - quartz
KF> is not needed,
KF> not a single resistor, capacitor, transistor or diode,
KF> NO BATTERIES ARE NEEDED.

Then I absolutely don’t understand you - if Gluck’s circuit
is so bad - why did you repeat it? If only we could compose our own - so what?swear like scribal carpenters?