HDD & SPECCY

DL>>> inside the computer, the IOGE signal is used to sample
DL>>> _all_ ports.
MK>> It’s bad IOGE ports block internal ports :(
MK>> When I installed the GS on my Penta GS I decided to use it to block the
MK>> cache... I started it, everything was as expected, and got a big bang, I didn’t have time IOGE
MK>> block the cache port :((

DL> there is such a cal. GS is to blame, it generates IOGE when IORQ is zero.
DL> competent devices generate IOGE solely based on the address, without
DL> participation of IORQ, RD and WR.

IORQ must be taken into account MANDATORY!
Without it they can blank each other out in the buffer RAM and peripheral buffer.
The computer in this case will not be able to work at all :)

Sincerely, Sergey Karachentsev.

...

SK>> There shouldn’t be anything superfluous on the controller.
SK>> Any circuit needs to be minimized (without compromising its capabilities).

DL> in this case to the detriment of compatibility.

Is it really so difficult to correct the driver?
Why does this same correction need to be done using a soldering iron?

Regards, Sergey Karachentsev.

26 Sep 1999 you wrote here:

[about the circuit from ZX-Next]
RM>> If you throw out everything unnecessary from it, retaining only the logic of working with the HDD,
RM>> then it will be no more than Nemov’s.

SK> But what about the support for automatic input/output commands?

Everything is there, at least and not as cool as in the Sprinter. For writing, it spends 44 bars
per word, but when reading it is not inferior - the same 32 bars.
In Nemovskaya, for comparison, 54 for writing and 40 for reading. True, in Jason's
blocker it takes 37 bars to record, but that's if you mess with the stack.

All the best.
Sincerely Roman.

SK> Is it really so difficult to adjust the driver?

Not every program has a driver. why edit something if you initially
choose the right port number?

All the best.
Dmitry.

... LD..X-TRADE... [ZX]

Once, Tue Sep 28 1999 09:47, Sergey Karachentsev wrote to Dmitry Lomov about
[HDD & SPECCY]:

DL>> there is such a feces. GS is to blame, it generates IOGE when IORQ is at
DL>> zero. competent devices generate IOGE solely on
DL>> based on the address, without the participation of IORQ, RD and WR.

SK> IORQ must be taken into account MANDATORY!

you are wrong. my knowledge and experience testify to the correctness of my statement
;)

SK> Without it, the RAM buffer and the peripheral buffer can extinguish each other.

You must understand that IOGE locks the internal _ports_ of the computer.
for example, when the processor gets into the memory (MREQ=0, IORQ=1), so what if we
if the address matches, we will additionally pull up IOGE by one, after all, it has one on it. if the processor gets into the port (IORQ = 0), we block it if the address is ours.
In any case, IORQ may not participate in the generation of IOGE, and if we take into account the race
of signals, then it _shouldn't_ participate.

SK> In this case, the computer will not be able to work at all :)

but it works for me? ;)
and from hundreds of XTR modem owners. there IORQ does not participate in the formation of IOGE.
at all :)

DL> ‘Ÿ –œ Õ…, fi‘œ IOGE ⁄¡–…“¡≈‘ ◊Œ’‘“≈ŒŒ…≈ _–œ“‘Ÿ_ ÀœÕ–ÿ¿‘≈“¡.
DL> Œ¡–“…Õ≈“, Àœ«ƒ¡ –“œ√≈””œ“ Ã≈⁄≈‘ ◊ –¡Õ—‘ÿ (MREQ=0, IORQ=1), fi‘œ ” ‘œ«œ, fi‘œ
DL> ÕŸ ◊ ”Ã’fi¡≈ ”œ◊–¡ƒ≈Œ…— ¡ƒ“≈”¡ ƒœ–œÃŒ…‘≈ÃÿŒœ –œƒ‘—Œ≈Õ IOGE Œ¡ ≈ƒ…Œ…√’, Œ¡
DL> Œ≈Õ
DL> ◊≈ƒÿ … ‘¡À ≈ƒ…Œ…√¡. ≈”Ã… –“œ√≈””œ“ Ã≈⁄≈‘ ◊ –œ“‘ (IORQ=0), ÕŸ ⁄¡–…“¡≈Õ, ≈”Ã…
DL> ¡ƒ“≈” Œ¡€. ◊ ÿ¬œÕ ”Ã’fi¡≈, IORQ ◊ ◊Ÿ“¡¬œ‘À≈ IOGE Õœ÷≈‘ Œ≈ ’fi¡”‘◊œ◊¡‘ÿ, ¡
DL> ≈”Ã… ’fi≈”‘ÿ «œŒÀ… ”…«Œ¡Ãœ◊, ‘œ … _Œ≈_ƒœÃ÷≈Œ_ ’fi¡”‘◊œ◊¡‘ÿ.

‰≈ ”‘◊…‘≈ÃÿŒœ , Õœ÷≈‘ … Œ≈ ’fi¡”‘◊œ◊¡‘ÿ. Hœ ”ƒ≈á‘ÿ ∆œ“Õ…“œ◊¡‘≈Ãÿ IOGE –“œ›≈ ”
’fi≈‘œÕ IORQ fi≈Õ ¬≈⁄ ≈«œ ’fi£‘¡ ≈”Ã… ƒ≈€…∆“¡‘œ“ –œ“‘œ◊ ƒœÃ÷≈Œ ∆œ“Õ…“œœ◊¡‘ÿ
Œ≈”ÀœÃÿÀœ ¡ƒ“≈”œ◊. ˜ ‹‘œÕ ”Ã’fi¡≈ ∆œ“Õ…“œ◊¡‘≈Ãÿ IOGE –œÃ’fi¡≈‘”— œ¬›…Õ ”
…”–œÃÿ⁄œ◊¡Œ…≈Õ œ¬›≈«œ ƒ≈€…∆“¡‘œ“¡ –œ“‘œ◊ fi‘œ ‹ÀœŒœÕ…fi≈”À… ◊Ÿ«œƒŒ≈≈.
˛‘œ À¡”¡≈‘”— «œŒœÀ ‘œ ƒœ –“…»œƒ¡ ”‘“œ¬…“’¿›…» /RD …Ã… /WR œŒ… Œ≈ œÀ¡⁄Ÿ◊¡¿‘
Œ…À¡Àœ«œ ◊Ã…—Œ…—.

˜œ‘ –œ”Õœ‘“… Œ¡ Õœ¿ Œœ◊’¿ ”»≈Õ’ HDD … ◊”£ ”‘¡Œ≈‘ –œŒ—‘Œœ.

††††††††††††††††††† HDD1.tx .t ††††††††††††††††††

ÇÄÄÉ ÇÄÄÄàÄÄÄÄàÄÄÄÉ
A0 Äá& ÜÄÄÄÄÄáCS2Å DC Å 6 OÄÄÄ#ÄÄÄÄÄÄÄÄÄÄÄÄÄCMOS_GLUK
A1 Äá ÅIORQÄOCS0Å Å Å Å ÇÄÄÉ
ÑÄÄÖ ÇÄÄOCS1Å Å Å #Äá& Å ÎÄÄÄ +5
__ ÇÄÄÉ Å ÜÄÄÄá Å Å ÑÄá OÄÄ‚
M1 Äá& OÄÄÖ Å Å Å Å ÇÄá Å ¸
A2 Äá Å A3 ÄáA0 Å Å Å #Äá Å ÑÄ IOGE
A5 Äá Å A4 ÄáA1 Å Å Å Å ÑÄÄÖ ÇÄÄÉ
A7 Äá Å A6 ÄáA2 Å Å 1 OÄÄÄ#ÄÄÄÄÄÄÄÄ#Äá1 ÜÄCS0_HDD
ÑÄÄÖ ÑÄÄÄâÄÄÄÄâÄÄÄÖ Å ÇÄÄÄÄÄÄäÄá Å
ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÖ Å Å ÜÄÄá
Å ÇÄÄÉ ÇÄÄÉ ÇÄÄÉ Å ÇÄÄÉ ÑÄá1 ÜÄCS1_HDD
__ #Äá1 ÜÄÄÄ#Äá& ÜÄÉ A12ÄÄá& ÜÄ#Äá1 OÄÄÄá Å
RD ÄäÄá Å ÇÄäÄá Å Å ÇÄá Å ÑÄá Å ÑÄÄÖ
Å ÜÄÄá Å Å ÑÄÄÖ Å Å ÜÄÄá ÑÄÄÖ
__ ÑÄá1 ÜÄ# Å ÇÄÄÄÄÖ A9ÄäÄá& ÜÄA0_HDD
WR ÄÄÄá Å Å Å Å #Äá Å
ÑÄÄÖ Å Å Å Å ÜÄÄá
Å Å Å A10ÄäÄá& ÜÄA1_HDD
Å Å Å #Äá Å
Å Å Å Å ÜÄÄá
ÇÄÄÉ Å Å Å A11ÄäÄá& ÜÄA2_HDD
ÇÄÄÄá& ÜÄäÄäÄäÄÄÄÄÄÄÄÄÄ#Äá Å
Å ÇÄá Å Å Å Å ÑÄÄÖ
Å Å ÑÄÄÖ Å Å #ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ#ÄÄÄÄÄÄÈÚ23_WR
ÑÄäÄÄÄÄÄÄäÄäÄäÄÄÄÄÄÄÄÄÄÄÄÄÄÄÉ Å
Å Å Å Å ÇÄÄÄÄÄÄÄÄÄÄÄäÄÉ ÇÄÄÉ Å ÇÄÄÉ
Å Å Å Å Å ÇÄÄàÄÄÄÄÉ Å ÑÄá1 ÜÄäÄá1 ÜÄÈÚ23_RD
Å Å Å Å Å áR ÅT OÄ#ÄÄÄá Å #Äá Å
Å ÇÄÄÉ Å Å ÑÄÄäÄ/C Å Å ÑÄÄÖ Å ÑÄÄÖ
A8 Ä#Äá1 OÄäÄäÄ#ÄÄ#ÄáD Å Å ÇÄÄÉ Å
ÑÄá Å Å Å Å áS Å ÜÄ#ÄÄÄá1 ÜÄäÄÄÄÄÄÄRD_HDD
ÑÄÄÖ Å Å Å ÑÄÄâÄÄÄÄÖ Å ÇÄá Å Å
Å ÑÄäÄÄÄÄÄÄÄÄÄÄÄÄÄÄäÄ# ÑÄÄÖ Å ÇÄÄÉ
Å Å ÇÄÄÉ Å Å ÇÄÄÉ ÑÄá1 ÜÄ·6_OE
Å ÑÄá1 ÜÄWR_HDD ÑÄäÄá& ÜÄÄÄá Å
ÑÄÄÄÄÄá Å ÑÄá Å ÑÄÄÖ
ÑÄÄÖ ÑÄÄÖ

††††††††††††††††††††††††††††††††††††††††††††††††

Û ’◊¡÷≈Œ…≈Õ, Sergey Karachentsev.

One day, Fri Oct 01 1999 10:19, Sergey Karachentsev wrote to Dmitry Lomov about
[HDD & SPECCY]:

DL>> you understand that IOGE locks the internal _ports_ of the computer.
DL>> for example, when the processor gets into memory (MREQ=0, IORQ=1), that with
DL>> the fact that if the address matches, we will additionally increase
DL>> IOGE by one, since it already has one. if the processor gets into the
DL>> port (IORQ=0), we block it if the address is ours. in any case, IORQ may not participate in
DL>> IOGE generation, and if we take into account signal races,
DL>> then _shouldn't_ participate.

SK> Indeed, it may not participate. But it’s easier to make an IOGE
SK> shaper taking into account IORQ than without taking it into account if the port decoder needs
SK> to generate several addresses.

that’s why in most cases they do it poorly :(

SK> Look at my new HDD diagram and everything will become clear.

SK> ═══════════════════ HDD1.tx .t ══════════════════

SK> ┌──┐ ┌───┬────┬───┐
SK> A0 ─┤& ├─────┤CS2│ DC │ 6 O───#─────────────CMOS_GLUK
SK> A1 ─┤ │IORQ─OCS0│ │ │ │ ┌──┐
SK> └──┘ ┌──OCS1│ │ │ #─┤& │ К─── +5
SK> __ ┌──┐ │ ├───┤ │ │ └─┤ O──B
SK> M1 ─┤& O──┘ │ │ │ │ ┌─┤ │ E
SK> A2 ─┤ │ A3 ─┤A0 ││ │ #─┤ │ └─ IOGE
SK> A5 ─┤ │ A4 ─┤A1 │ │ │ │ └──┘ ┌──┐
SK> A7 ─┤ │ A6 ─┤A2 │ │ 1 O───#────────#─┤1 ├─CS0_HDD
SK> └──┘ └───┴────┴───┘ │ ┌──────┼─┤ │
SK> ┌─────────────────────────┘ │ │ ├──┤

[skipped]

yes, I regretted it two elements LL1. Remove IORQ from the decoder, connect LL1 to the output circuit of the decoder, and connect IORQ to the second inputs. on the
IOGE mixer, leave the signals directly from the decoder outputs.

Hehe, but the circuit is meaty ;) IMHO, there will be glitches, short unfounded
activations. I would do it wrong :)

DL> that is why in most cases they do it poorly :(

And why is this bad?

...

DL> [skipped]

DL> yes, I regretted two elements of LL1. Remove IORQ from the decoder, include LL1 in the output circuit of
DL> of the decoder, add IORQ to the second inputs. Leave IOGE on the
DL> mixer
DL> IOGE signals directly from the outputs of the decoder.

Why?

DL> Hehe, the circuit is meaty ;) IMHO, there will be glitches, short, unfounded ones

What kind of glitches?
Give examples.

DL> triggering. I would do it wrong :)

What are the unreasonable alarms?
What is the supposed mechanism of their occurrence?

With respect, Sergey Karachentsev.

DL>> decoder outputs turn on LL1, to the second inputs of which set
DL>> IORQ. on the IOGE mixer, leave the signals directly from the outputs of the
DL>> decoder.

SK> Why?

see. above :)

SK> What are the unreasonable alarms?
SK> What is the supposed mechanism of their occurrence?

See. above :-)

the address appears. your scheme is silent. WR and IORQ appear - your circuit is silent, and
only after ~40 ns it issues IOGE. During these ~ there are address and
sampling signals inside the computer. if a port with simplified addressing is fast (for example, a border or
#FD) - it will be dirty.