[0/1] HDD STORER

A utility for hard drive owners.

Andrey aka SAVC.

[ZX] [ATMEL_AVR] [PC_ASM] [ELECTRONICS]

06 Jan 04 21:20, you wrote to you:

AS> Hello, All!

AS> A utility for hard drive owners.

What scheme?
Vladimir

[I ZX] [Sprinter Developer]
[Sprinter UNofficial site: cr0acker.narod.ru]

VK> According to what scheme?
VK> Vladimir

According to Nemo'vskaya.
It is possible to configure port addresses. But the port addressing is 8 bit.

AS> By Nemo'vskaya.
AS> It is possible to configure port addresses. But the addressing of ports 8
AS> is bit.

Can you explain WHAT THIS UTILITY DOES? Or do you need to guess with STS in hand?

Was it really so difficult to place the utility in an archive, inside the archive
attach the file_id.diz file with a brief description, also a README file with a more
detailed description, and include the same README file in the letter along with the
UUE code?

If I were a moderator, I would require this for any UUE code
placed in the echo, only if the file being placed is not intended for
wide distribution and it is clear from the context of the letter what it is about.

...Kirill Frolov ..> Andrey Sergaev:

KF> If I were a moderator, I would demand this for any UUE code
KF> placed in the echo, only if the file being placed is not intended for
KF> wide distribution and from the context of the letter it is clear what it is about.
and it is in the rules, point 5, but for some reason I don’t have the original Mesagi -
disappeared somewhere along the way before me. there is neither the Yuyuk itself nor this “zero” section.
and I cannot give awards in absentia. so from now on I will check the echo once a week through the Internet gate.

...bye.Kirill! ...tigrr//bw::ceg::sclr
... Shmuel Flash - Chilling Moments (Original Mix) ...

AS>> 8-bit ports.

KF> Can you explain WHAT THIS UTILITY DOES? Or do you need to guess with STS in
KF> hands?

KF> Was it really so difficult to put the utility in an archive, inside the archive
KF> attach the file_id.diz file with a brief description, also a README file with
KF> a more detailed description, and include the same README file in a letter
KF> along with the UUE code?

KF> I If I were a moderator, I would require this for any UUE-code
KF> placed in the echo, only if the file being placed is not intended for
KF> wide distribution and from the context of the letter it is clear what it is about.

=== Cut ===

Before posting, the above files _necessarily_
must be packed with Spectrum ZIP (*.$z) or a similar archiver on a PC (*.zip), the archive must contain a description of the contents in a text file (it is desirable that this file have the standard name file_id.diz,
descript.ion or read_me).

=== Cut ===

So I demand. Another question is that I haven’t checked the archives for a long time...

Au revoir.
Tim Kelly [Team Kelly] [ZX]

... np: silence

AS>> 8-bit ports.

KF> Can you explain WHAT THIS UTILITY DOES? Or do you need to guess with STS in
KF> hands?

Kirill, don’t get into the bottle. It will take you a long time to figure it out with STS.

KF> Was it really so difficult to put the utility in an archive, inside the archive
KF> attach the file file_id.diz with a brief description, also a README file with
KF> a more detailed description, and include the same README file in the letter
KF> along with UUE code?

It is difficult for me to create a detailed description.
It was for this reason that the utility lay there for almost three months, because I was
very lazy to document it. In the end, a small file was compiled and
along with the utility it was sent in SCL format to echo.
I’m now cursing myself for not bothering to look at the rules beforehand.
If I had, I wouldn’t have posted it. Now I’m sitting and waiting for a well-deserved plus.
Since I received at least some response from the (dis)satisfied
user, the laziness disappeared. After this letter, I’ll start drawing up a corresponding manual. Then the program will be thrown into the echo again, according to all
rules.
But, so that you don’t wait long:
Scrap is needed
1) to completely clean the entire hard drive, i.e., if you had Top Secret Data on
the screw, and you can’t allow it to evenone surviving cluster fell into the hands of the Enemies, and everything else doesn’t matter, you take this junk and with a clear conscience click the STORE ALL DISK point. All. Nothing
will help the enemies.
2) to clean the first 48 megabytes of the hard drive. This function is needed to erase the entire FAT, and everything that is located before it - treatment for Particularly Evil Viruses. In this case, you poke the STORE FIRST 48M dot. The virus will be killed.
The screw is operated in LBA28 mode, which provides support for hard drives with a capacity of up to 128Gb. LBA48 was not implemented, for obvious reasons: Speccy will fill such screws for a year. But, if there is a next
version, you can also insert LBA48.
The junk has a high write speed:
I have a Scorpion 256, not a turbo. The Maxtor 7270 AV 257Mb screw fills in
8 minutes. 40 sec. This corresponds to a recording speed of 506 Kb/s.
The utility allows you to configure the addresses of the hard drive controller ports. Due to the fact that working with 16-bit port addresses greatly slows down the recording speed, port addresses are 8-bit, as is done in Nemo. In general, the controller is Nemo
rulez. But if you don’t already have it, then maybe yours at least supports 8-bit addressing? Then all is not lost.
All program settings can be saved, click SAVE CONFIGURATION.
Settings are saved in the body of the program. Restore portsYou can use the Nemo controller by clicking the SET DEFAULT (NEMO) checkbox.
When starting, the program determines which hard drives are connected, and
whether they are connected at all. If the drive is not connected, [NONE HDD] is displayed
If it is connected but does not support LBA, [LBA NOT SUPPORTED] is displayed
If it is connected and supports LBA, its name and capacity in
megabytes are displayed. As you know, two
devices can be connected to one IDE controller: MASTER and SLAVE.
The specified procedure can be carried out a second time by clicking on the DETECT DEVICES item
With the EXIT item, everything is clear - exit from the program.
The STORE BYTE item is, in fact, the byte which will fill the screw.
The RETRY COUNT item is the number of attempts to write a sector.
While the recording is in progress, a bar is displayed on the screen indicating
what part of the work has already been completed. It goes from the left to the right edge of the screen. If
you want to interrupt this process, press SPACE.
Upon completion of recording, a sound is issued through AY - a signal to the user who has fallen asleep.
When recording settings to disk, the program works through #3D13. Of course,
an attempt has been made to process at least some of the possible TR-DOS errors, but...
And also, when recording settings, no checks are made for changing the disk,
so be careful, do not change the disk by accident - you can spoil it.
Control is carried out with the keys
5, 6, 7, 8,Enter - move the cursor, select a menu item
in the editing mode, key 0..9 A..F - enter a number, Enter -
skip the number.
in the recording process, the SPACE key completes this procedure.

On Fri, 23 Jan 04 12:35:30 +0300, Andrey Sergaev wrote:

AS> The screw is operated in LBA28 mode, which provides support
AS> for hard drives with a capacity of up to 128Gb. LBA48 was not implemented, for quite understandable
AS> reasons: Speccy will fill such screws for a year. But, if there is a next
AS> version, it will be possible to insert LBA48.

There is a special command - to write a buffer for all sectors. Once
512 bytes you send and that’s it...

ATA_WRITE_SAME equ 0xe9

like this.

And those that are LBA48 also support a password and therefore the function of
destructing data (the 6th version of the specification, it seems).

AS> The utility allows you to configure the addresses of the ports of the hard drive controller. In
AS> connection with
AS> the fact that working with 16-bit port addresses greatly slows down the speed of
AS> writes, port addresses are 8-bit, as is done in Nemo. In general, the controller
AS> Nemo
AS> rulez. But if you don’t already have it, then maybe yours
AS> at least supports 8-bit addressing? Then all is not lost.

Do it through a universal driver. Then all will not be lost.
The driver can be statically linked to the program (loaded at an absolute address), or it can be loaded as a dynamically linked
library. In the latter case, simultaneous loading of
several drivers is possible.

1 Introduction

1.1 Purposedriver

The IDE controller driver provides a software interface to
registers of devices connected to the controller. This is not a
block device driver in the usual sense; its function does not
include interaction with
devices connected to the IDE controller. The driver only provides control functions for the controller, but not for devices that use it.

1.2 Driver versions

The current driver version is a sub-version numbered 1.3.
The version number consists of the version number itself and the sub-version number separated by a dot. The current version number is 1, the sub-version number is 3. Within the same version number, drivers must maintain compatibility at the binary level. Currently, it is assumed that the driver is intended exclusively for computers compatible with the ZX-Spectrum, which is clearly defined in the description of its software interface in assembly language. However, the interface in the
C language is also described in parallel, making it possible to use the driver on almost any
computer.

2 Software interface

All interaction of the driver with the programs
using it is limited exclusively to a few functions (subroutines)
of the driver. The driver exports these functions
to the program that uses it; other details of the internal structure
of the driver are hidden from the program that uses it.

There are certainconventions for using
driver functions. They determine the method of passing function arguments,
the method of returning the result of a function, and determine the use of
microprocessor and memory registers.

It is necessary to pay special attention that when called, the driver can
change the contents of any microprocessor registers, except IX and
except for special registers SP and I. Some drivers can
prohibit maskable interrupts when using TR-DOS ROM and
in some other cases. Therefore, if the IDE_INTEXCL bit in the
driver property bitmask returned by the _ide_info function
is set, care must be taken to restore the
interrupt status after calling the driver functions. Some
drivers can change the computer memory configuration at the time of their
call, as evidenced by the IDE_MEMCONF bit in the bit mask
of the driver properties.

Currently, there is no clear definition of how
the driver can interact with the operating system and
other programs, so there is a question of interrupt handling, and
the question of managing the computer memory configuration, as well as hardware registers currently does not have a clear solution.
Practically, the driver cannot be used in a multi-tasking
environment and in a computer memory configuration different from that used in the TR-DOS environment and the BASIC interpreter. The author is readydiscuss
your suggestions on this issue.

3 Functions of the IDE interface driver.

This section describes all the functions implemented by the driver in
the current version. The interface in assembly language is described, and in addition
prototypes of functions for the C language are given. The driver can
be used both in a program in assembly language and in a program written in C language without any significant
restrictions. The names of the functions are given as they are available
in the assembly language program.

3.1 _ide_init

Function prototype in C: int ide_init(void);

Initializing the interface. Including entering the correct data
into the structure returned by the _ide_info function. The function returns
a non-zero value in the HL register when
errors occur.

Before calling this function, no other driver functions except
_ide_info and ide_probe can be called.

3.2 _ide_info

Function prototype in C: struct ide_info_s *ide_info(void);

Getting information about the driver. The function returns in the register
hl a pointer to the structure ide_info_s with the following content:

{
unsigned ide_caps; // property bit mask,
int ide_channels; // number of channels 1..128
char *ide_string; // pointer to a text string
} // interface description

The structure is packed, for an assembler programmer it looks
likean array of 3 16-bit words. For ease of access
to structure elements, the following assembly language labels are defined:

IDE_CAPS equ 0
IDE_CHANNELS equ 2
IDE_STRING equ 4

The property bit mask consists of the following bits:

IDE_ALT_REGS equ 1 ; alternative register bank
; available
IDE_BETADISK equ 2 ; used by the driver
; Beta-Disk interface
IDE_MEMCONF equ 8 ; the driver can change
; memory configuration
IDE_INTEXCL equ 16 ; driver disables interrupts
IDE_INTERRUPTS equ 128 ; interrupts supported
; from the controller

The contents of some structure fields may be invalid
until the _ide_init function is called.

3.3 _ide_probe

Function prototype in C: int ide_probe(void);

Detects the presence of an interface. The function tries to determine
whether the computer hardware contains a controller serviced
by this driver. The test result is returned in the register
HL:

HL < 0 the function is not implemented or cannot be determined

HL = 0 the interface is guaranteed to be absent

HL > 0 the interface is present

3.4 _ide_done

Function prototype in C: void ide_done(void);

Finishing work with the interface, disabling the interface. After
calling thisfunctions, no other functions except _ide_probe,
_ide_init and _ide_info can be called.

3.5 _ide_channel

Function prototype in C: void ide_channel(int channel);

Set the controller channel. The function activates the IDE controller channel specified in register E. Only one channel is active at one time. Channel numbering starts
from zero, the maximum channel number is limited by the value returned
by the _ide_info function.

3.6 _ide_read_reg

Function prototype in C: int ide_read_reg(int register);

Reading an 8-bit control register. The register number of the IDE
device is transmitted in register E of the microprocessor. Numbers
0-7 encode a bank of control registers, numbers 8-15
a bank of alternative registers.

The value read from the IDE device register is returned
in the L register of the microprocessor.

3.7 _ide_write_reg

Function prototype in C: void ide_write_reg(int register, int value);

Write an 8-bit control register. The register number of the IDE
device is transmitted in register E of the microprocessor. The
value for writing to the IDE device register must be specified in the
C register of the microprocessor.

3.8 _ide_write_command

Prototype of the function in C: void ide_write_command(struct ide_regs_s *regs);

Write a command to the drive registers. The function is used to
send a command with IDE parameters to the device. INregister
DE is passed a pointer to a packed structure ide_regs_s
containing data for all command registers:

{
uint8_t feature; // for writing to the property register
uint8_t count; // to the account register
uint8_t sector; // to the sector number register (LBA address)
uint8_t cyl_low; // to the track number register (LBA address)
uint8_t cyl_high; // high part...
uint8_t dev_head; // to device/head register
uint8_t command; // command code
}

For an assembler programmer, the packed structure looks
as an array of 7 bytes, each of which contains a value
for the corresponding register of the IDE device:

feature: db 0
count: db 0
sector: db 0
cyl_low: db 0
cyl_high: db 0
dev_head: db 0
command: db 0

As a result of executing the function, all registers will be written sequentially, starting with the property register and ending with the
command register. This function is used to minimize the number
of calls to the ide_write_reg function.

3.9 _ide_read_block

Function prototype in C: void ide_read_block(void *buffer, int count);

Reading an array of data into memory from the IDE device data register
16-bit words. The microprocessor's DE register specifies
a pointer to the memory address where the data read
from the data register of the IDE device will be placed. The BC register of the microprocessor
sets the sizearray of read data in 16-bit
words.

3.10 _ide_write_block

Function prototype in C: void ide_write_block(void *buffer, int count);

Write an array of data from memory to the data register of the IDE device
in 16-bit words. The microprocessor's DE register transmits
a pointer to the memory address, from where the data placed
in the data register of the IDE device will be read. The BC register of the microprocessor
transmits the size of the array of written data in 16-bit
words.

3.11 _ide_int_mode

Function prototype in C: void ide_int_mode(int mode);

Interrupt management. Enable or disable the generation of
maskable interrupts by the IDE controller. Whether interrupts are
enabled or disabled is determined by the argument passed
in the E register:

E = 1 enable interrupt generation

E = 0 disable interrupt generation

The function has its effect only if the driver
properties returned by the _ide_info function indicate that
the driver supports the use of maskable interrupts.

3.12 _ide_int_flag

Function prototype in C: int ide_int_mode(void);

Definition of interrupt source. The function determines whether a maskable interrupt was caused by a controller served by a given driver. This is necessary to accurately identify
the source of the interrupts. Function execution resultreturns
in the HL register.

HL < 0 function not implemented

HL = 0 no interrupt requested

HL > 0 interface requests an interrupt

The function can be implemented by the driver even if
the driver does not support the use of maskable interrupts.

4 Interface with the C language compiler

This section describes the interface of the company's C language compiler HiTech Software (http://www.htsoft.com)
with a program in assembly language.

4.1 Passing arguments

A function can accept a number of arguments passed
by the calling program. Function arguments can be variables
(values) of any type.

For functions declared in the K&R style, when the function
arguments are not included in its prototype, all arguments are passed through
the stack as described below. For functions declared in the ANSI-C style,
when the function prototype includes information about the arguments
of the function, the arguments are passed through the microprocessor registers DE, BC and through the stack. In any case, all
8-bit values ​​are pre-expanded to 16
bits; the most significant bits are not used in any way.

If the functiondeclared in ANSI-C style, the first argument of the function,
if it is an 8- or 16-bit value,
is passed in the microprocessor's DE register. The E register passes
an 8-bit argument. Otherwise, the first argument
is passed on the stack.

If the function is declared in ANSI-C style, the function's second argument
if it is an 8- or 16-bit value
is passed in the microprocessor's BC register. The E register passes
an 8-bit argument. Otherwise, the second argument
is passed on the stack.

The third and remaining function arguments are always passed on the
stack. The function arguments are placed on the stack in reverse
order, that is, the last argument is placed on the stack first, and the third argument, if both first
arguments are passed through the DE and BC registers, is placed on the stack last. Arguments that occupy
one byte in memory (8-bit), as already mentioned, are necessarily
always expanded to 16 bits and therefore
occupy two bytes on the stack. Arguments that occupy 3
bytes of memory are expanded to 32 bits and placed on the stack
of 4 bytes. Arguments of greater width occupy exactly as many bytes on the stack as are required to store them,
that is, for example, if there is a certain data type that occupies exactly 5 bytes in memory, then it is on the stackwill take 5 bytes if
passed as a function argument.

Popling arguments from the stack. If a function is declared
in ANSI-C style and at least one argument has been passed through the stack,
then the called function must pop all arguments from the stack
before returning, and the calling program need not
worry about this. When a function is declared in
K&R style, the calling program must pop all arguments
passed through the stack from the stack.

4.2 Returning a result

A function can return a result. The result can be
one variable (value) of any type. The way the result
is returned to the called function is determined by the type of the
result variable. All 8-bit values ​​are pre-expanded
to 16-bits; the most significant bits are not used
and can contain an arbitrary value. If the result
fits into 16 bits, then it is returned in the HL register.
If the result fits into 32 bits, then it is returned
in the HL and DE registers: in the DE register the low-order bits, and in the HL register the most significant ones. The result of a larger capacity (for example
an array or structure) is placed in a static temporary
variable, and a pointer to this
variable is returned in the HL register (it is easy to see that in this case the function
cannot be “reentrant”).

4.3 Microprocessor registers

The function canchange the contents of any microprocessor registers except SP and IX. The SP register is always incremented
by 2 when returning from a function by popping the return address
from the stack. Additionally, it can be changed if
the function is required to pop arguments from the stack. The IX register
stores the stack frame pointer of the calling function, therefore
the called function must restore
the contents of the IX register before returning.

4.4 Examples of function calls

An example of calling a function with two arguments declared in the
ANSI-C style. Function declaration:

void funct1 (long arg_1, int arg_2);

Function call, text in C language:

funct1(0x12345678L, 0xabcd);

Function call, text in assembly language:

ld hl, 0x5678
push hl ; first argument, high part
ld hl, 0x1234
push hl ; first argument, low part
ld bc, 0xabcd ; second argument
call funct1
; program continuation

Popling the first function argument from the stack after calling the
function is not required because the function is declared in
ANSI-C style. The first argument does not fit into 16 bits, so
it is passed not through the DE register, but through the stack. The low part
of a 32-bit word is placed on the stack after the high part
because this is the placement of multi-byte machine words
words adopted in the Z80 processor. Second function argumentis
16-bit and therefore passed through the BC register.

Function example:

push ix ; saving IX calling function
ld ix, 0
add ix, sp ; creating a stack frame
ld hl, -20 ; allocation of 20 bytes of memory for local
add hl, sp ; variables that can
ld sp, hl ; be addressed via (IX-nn),
; and the function arguments through (IX+nn) ...
ld hl, 1 ; return code
ld sp, ix ; freeing memory pop ix ret

All functions, unless otherwise noted, adhere
to these calling conventions.

5. An example of using the IDE controller driver

The example is given for the ZASM assembler.

include "ide.inc" ; including IDE driver definitions
include "ata.inc" ; enable ATA(IDE) definitions
; interface
start:
call _ide_init
ei
ret c
call _ide_info
ei
ret c

...

call _ide_done
ei
ret

6. Supported controllers.

Currently there are drivers for the following controllers
IDE interface:

Controller: Status:
1. ZXNEXT testing required
2. NEMO working
3. SMUCworker
4. SPRINTER testing required
5. PROFI testing required
6. Sergey Karachentsev testing required
7. TURBO-2+(ATM) testing required
8. JTN testing required

24 Jan 04 02:00, Kirill Frolov -> Andrey Sergaev:

KF> There is a special command - write a buffer for all sectors. Once
KF> you send 512 bytes and that's it...

KF> ATA_WRITE_SAME equ 0xe9

KF> like this.

I just looked at the ATA/ATAPI-7 V2 specification, November 5, 2001.
There is no such command.
Nothing like WRITE_SAME.
All write commands require the transfer of recorded data.
The command with code #E9 is designated as retired, if I translated correctly,
retired. And the specification says nothing about it.
If you have any documentation on this command, please provide a
link to it.

KF> And those that have LBA48, they also support a password and therefore the function
KF> of data destruction (6th, apparently, version of the specification).

Naturally, there are such commands. Those who wish can use them on
new screws. But let's say they are not supported on my screws. And what should I
do? Otherwise, the screws suit me.

KF> Do it through the universal driver. Then all will not be lost.
KF> The driver can be statically linked to the program (loaded at
KF> absolute address), or loaded dynamically linked
KF> library. In the latter case, simultaneous loading
KF> of several drivers is possible.

About the driver. As I understand it, by the authoryou are.
How is the recording speed? 500 Kb/s maybe?
And on SMUC? Maybe too?
If this is so, great, we can support your driver.
But it’s very inconvenient for you.
My opinion: devices such as the HDD controller should be strictly
standardized, since the maximum operating speed depends on this with
them.
And also, in my opinion, it is incorrect to tell a person how and what he should
do.

And why, the question arises, litter the echo with documentation for your driver?
I didn’t say that I needed it. And even if it was needed, there is
NETMAIL.

AS> About the driver. As I understand it, you are the author.

Yes.

AS> How is it with the recording speed? 500 Kb/s maybe?
AS> And on SMUC? Maybe too?

Determined by the implementation of a specific driver.

For NEMO, the _theoretical_ maximum is < ~218KB/sec for non-turbo
and < ~360KB/sec for turbo mode. That is, I believe that 32 clock cycles are spent on entering a word:

ini
inc c
ini
dec c
...

Total 8 clock cycles for intermediate operations. And 12*2 for input, if without
turbo mode. Total ~218KB/sec. And for the turbo mode you need to calculate:
the ini command takes 12 clock cycles and consists of 8 cycles of reading the COP,
and about 3 clock cycles for input, the rest is an “idle” cycle. In KAY, on
any I/O cycle, turbo mode is forcibly disabled. That is, the execution time of the ini command will be 9 “fast” clock cycles and 3
slow ones, which is equivalent to 6 fast clock cycles. The total is approximately 360KB/sec. But this is theoretical, in practice it is always less.
In addition, highly expanded loops of the “optimized” driver
take up unnecessary memory.

And 500 KB/sec is *required in turbo mode* and something like
the following code:

ini
ini
ini
ini
...

This is possible for Sergey’s controllersKarachentsev and
Vasily Klimov (aka JTN), controller of Sprinter,
Turbo-2+ (ATM-Turbo) and ZXNEXT computers. For NEMO-IDE, SMUC
and Profi controllers this is impossible.

Think about it: you are talking about insufficient performance
and you are proposing as a “standard” NEMO, one of the three slowest
controllers. Why not Sprinter? Let's all get to grips with the controller, Ivan Mak published the controller circuit diagram a long time ago!

In reality, the driver has nothing to do with delivering the expected
500kb/sec. The overhead costs above the useful code - hundreds of clock cycles per
sector are not very significant.

As for the turbo mode, I would like to warn you: in computers other than
KAY, the I/O cycle in turbo mode is also shortened. This can
lead both to unreliable operation of the electronics, and in a specific
case, when programming ATA-2 devices via an IDE controller,
leads to violations of the standard which states that in PIO mode 0..2
there is a well-defined I/O cycle duration no shorter
than whatever. And in PIO mode > 2, mandatory support for
the IORDY signal is required, which is absent in many controllers, and in NEMO-IDE too.

AS> If this is so, great, you can support your driver.
AS> But it turned out to be very inconvenient for you.

Why is it inconvenient? I/O performance losseshim
small. Reading/writing of long blocks is carried out inside the driver.
Losses for accessing individual registers are large, but this is not so significant.
For writing commands there is a special function that writes all registers in one
call.

The module loading system itself is inconvenient. It requires serious
modernization. But the driver can be used without a module.

AS> My opinion: devices such as the HDD controller should be strictly
AS> standardized, since the maximum speed of working with
AS> them depends on this.

Once upon a time, I also thought so. Now I don't have a Spectrum --
he was killed by a blunt, hot object. No, the question is not at all about repair.
Now I completely agree with Nemo on this issue, about handjob
in relation to electronics. That is why the idea of ​​a driver appeared, not a “hard drive” or “block device” driver, but a layer between
hardware registers and the hardware itself.

As for speed, it practically does not depend in any way on
whether the given code is called from the driver or from somewhere else. Nobody
is stopping you from optimizing a very specific driver for NEMO-IDE.
And besides the functions of reading and writing a data block, which is entirely implemented
in the driver, there are no significant overhead costs for calling it,
you don’t need any significant optimizationyou will achieve it.

The whole question is only in the interfaces...

AS> And why, one may ask, litter the echo with documentation for your driver?

Then, so that other conference subscribers can focus their attention on this, and not do such stupid things (ironly driving in some kind of port addresses into a program, and at the same time, often with errors).
The ZX-Spectrum equipment is not addressed at all by any ports, but by
a very specific combination of control signals on the computer bus,
which _impossible_ to represent by the number of the port address.

I can give one example of what this leads to: for many years
there has been a wonderful program Vega Commader, but for the same
reasons it only works with SMUC, and only with a single
drive. Recently a person complained in this echo.

There is a second, unique and unique CD-Walk program. It
has been around for a shitload of years, but only until recently it was
available only to Scorpion and SMUC users. Now it is also available to
KAY and NEMO-IDE users. And the happy owners of TURBO-2+
(ATM-TURBO), and PROFI, machines in which the “hard drive” appeared long before
any scorpions there, are again in ()(). (no, in fact they can
use a hacked CD-Walk with my driver...)

Here is the result of all this "standardization"...

AS> I didn't saythat I need her. And even if there was a need, there is
AS> NETMAIL for that.

I would like to note that I am not writing to NETMAIL, and not to you personally, but
to teleconference.

KF> Determined by the specific driver implementation.

KF> For NEMO, the _theoretical_ maximum is < ~218KB/sec for non-turbo
KF> and < ~360KB/sec for turbo mode. That is, I believe that it takes 32 clock cycles to enter a
KF> word:

KF> ini
KF> inc c
KF> ini
KF> dec c
KF> ...

I made some errors in the calculations. The actual
theoretical maximum speed for NEMO-IDE is 175 and ~300 KB/sec
for normal processor clock speed and turbo mode
respectively.

KF> Total 8 clock cycles for intermediate operations. And 12*2 for input, if without
KF> turbo mode. Total ~218KB/sec. And for the turbo mode you need to calculate:
KF> the ini command takes 12 clock cycles and consists of 8 cycles of reading the KOP,
^^^^^^^^^^^^^^^^^^^^^^
This is where the error lies. The ini command is executed in 16 clock cycles
(KOP(4,5) + IO(3) + 4).

KF> And 500KB/sec is *required in turbo mode* and something like
KF> this code:

KF> ini
KF> ini
KF> ini
KF> ini
KF> ...

KF> This is possible for the controllers of Sergei Karachentsev and
KF> Vasily Klimov (aka JTN), the controller of Sprinter,
KF> Turbo-2+ (ATM-Turbo) and ZXNEXT computers. For NEMO-IDE, SMUC
KF> and Profi controllersthis is impossible.

~437KB/sec. for Scorpion and ~368KB/sec for KAY, in turbo mode.

_500KB/sec. is not achievable on anything other than Sprinter._

KF> As for the turbo mode, I would like to warn you: in computers other than the
KF> from KAY, the I/O cycle in turbo mode is also shortened. This can
KF> lead to both unreliable operation of the electronics, and in a specific
KF> case, when programming ATA-2 devices via an IDE controller,
KF> leads to violations of the standard which states that in PIO mode 0..2
KF> there is a well-defined I/O cycle duration no shorter than
KF> than whatever. And in PIO mode > 2, mandatory support
KF> of the IORDY signal is required, which is absent in many controllers, and in NEMO-IDE too.

Somewhat there, for PIO mode 0 it is 600 ns. The I/O cycle duration of the Z80 is 2.5 clock cycles, at a frequency of 3.5 MHz - 712 ns.
In turbo mode - 355 ns.

For RELIABLE operation in turbo mode, you need a drive that supports
at least PIO mode 2. Many older drives may not support
this mode of operation. And this only concerns the drive itself, and the Spectrum itself should not be discounted yet. Many people have probably encountered unstable ISA modems, an 1818VG93 disk drive controller that reads with errors, and similar cases. Athere is only one reason - the Spectrum bus is OVERLOADED beyond all reasonable norms. And a short
input-output cycle in this situation negatively affects the reliability
of reading data.

KF>> Sprinter, Turbo-2+ (ATM-Turbo) and ZXNEXT. For controllers
KF>> NEMO-IDE, SMUC and Profi this is not possible.

KF> ~437KB/sec. for Scorpion and ~368KB/sec for KAY, in
KF> turbo mode.

KF> _500KB/sec. not achievable on anything other than Sprinter._

And on GMX? Turbo boost = 179%

AS>> driver?

KF> Then, so that other conference subscribers can focus their attention on this
KF> and not commit such stupid things (iron driving in some kind of port addresses into the
KF> program, and at the same time, often with
KF> errors). The ZX-Spectrum device is not addressed at all by any
KF> ports, but by a very specific combination of control signals on the
KF> computer bus, which _impossible_ to represent by the port address number.

This is a matter of different views on the physical events occurring processes.
The equipment is addressed by ports, hence the word addressing - port address. When a processor command is executed, certain control signals are installed on the bus. The equipment often uses not all
signals for decryption, but only a part. As a result, it is possible to access it using different addresses.
This is widely known - incomplete port addressing.
So, regarding _impossible_ - you got excited.
Regarding errors in port addresses. Nobody forbids you to write programs without
errors.
And errors can also occur in your driver. And then the programmer who uses your driver becomes dependent on your mistakes. And if the program is buggy, it is not clear who is to blame and at whom to throw stones. No endyou will find.
By the way, the situation is typical for a PC.

KF> I can give one example of what this leads to: for many
KF> years there has been a wonderful program Vega Commader, but for the same
KF> reasons it works only with SMUC, and only with a single
KF> drive. Recently a person complained in this echo.

KF> There is a second, unique and unique CD-Walk program. It
KF> has existed for a long time, but only until recently it was
KF> available only to Scorpion and SMUC users. Now it is available
KF> also to KAY and NEMO-IDE users. And the happy owners of
KF> TURBO-2+ (ATM-TURBO), and PROFI, cars in which the Winchester appeared
KF> long before all sorts of scorpions, again in ()(). (no, in fact
KF> they can use a hacked CD-Walk with my driver...)

KF> This is the result of all this "standardization"...

This is precisely the result of the non-standardization of the equipment. And, as a
consequence, writing drivers, breaking programs, unnecessary headaches, which, ultimately, fall on the shoulders of the user. He can no longer just
turn on the program and use it. He must know a bunch of details, how to configure
the driver, how to remove glitches, where to find hardware so that it doesn’t glitch...
And there are more and more drivers...New versions of previous ones are coming out, patches... Good! There is a job for a programmer. Moreover, such a specialty as a customizer appears, to whom the user must pay
money. And he will set up his computer... It will be glitchy in a moment... We've already done this.
Take a look at the PC and you'll see how _not_ to do it.
By the way, your driver is already in its third version! How old is it?
The interface, as you yourself admit, is inconvenient, it needs to be corrected...

NA> And on GMX? Turbo = 179%

ld "c|b", e
ini
ld "c|b", d
ini
...

40 clock cycles/word, all commands are multiples of 4 clock cycles, no delay.
7 million. clock cycles / 40 == 350KByte/sec. With "open ports" of course.

KF> 40 clock cycles/word, all commands are multiples of 4 clock cycles, no delay
KF>. 7 million clock cycles / 40 == 350KByte/sec. With “open ports”
KF> of course.

Then I didn’t understand (see underlined).

NA> Then I didn’t understand (see underlined).

It is not necessary to write to the shadow register every time. The screw is filled with the same bytes. So the speed doubles.

WBR, Jason.

_/(ZX)/_ /*e-mail: jason2000(scary dog)yandex.ru ICQ: 62235830*/

/np:/ *silence*

KF>>>> turbo mode.
NA>>> And on GMX? Turbo = 179%
KF>> 40 clock cycles/word, all commands are multiples of 4 clock cycles, no delay
KF>>. 7 million clock cycles / 40 == 350KByte/sec. With "open ports"
KF>> of course.

On Tue, 03 Feb 04 14:01:48 +0300, Valerij Kozhevnikoff wrote:

VK> It is not necessary to write to the shadow register every time. The screw is filled
VK> with the same bytes. So the speed doubles.

In general, it is not necessary to fill the entire “screw”... I can’t even imagine
what this might be needed for, excluding all sorts of security. :-/

AS> By the way, as far as I know, there is no Sprinter scheme as such at all
AS>,
AS> it is flexible, depending on the contents of its GALs. This
AS> feature
AS> was indicated in the advertisement.

Yes, it is so. But this does not mean that the above scheme, in terms of its operating logic, is fundamentally different from what is there in the FPGA.

AS> The Nemo
AS> controller is one of the very first,

Nonsense and nonsense. One of the first is, apparently, after all
PROFI. Then ATM/Turbo-2+. THIS WAS STILL IN THE EARLY 1990s!!!
Then SMUC for Scorpion - 1994, if I'm not mistaken. Around the same
time and ZXNEXT. NEMO with its controller somewhere in the fall of 1997. appeared
after Enlight'97, the scheme was published back in the 7th ZX-FORMAT.

AS> there is software for it,

List of software for the studio. As far as I know, there is no software other than iS-DOS
drivers. Where is at least basic FDISK? So that the screw can be worn
between the pussy and the Spectrum. And don’t write down the location of
iS-DOS file systems on a piece of paper, which if you lose, write
lost...

AS> the circuit _initially_ was open,

ATM and PROFI were supplied with schematic albums... and for Scorpion too, in
a book about SMUC. There are no “closed” ones at all.it was, in this understanding.

AS> the circuit was developed in such a way that it was possible to connect
AS> to _any_ spectrum. At least to Spectrum 48, at least to Scorpion 1024, at least to
AS> KAY,
AS> at least to Pentagon,

You are mistaken. It is
difficult to connect this controller to any Spectrum, due to the fact that the controller port addresses overlap
with many other ports. Only for a computer with a ZX bus this
does not pose a problem, and only in the case when the conflicting ports are not
located on the device included in the next slot. On KAY, this problem
is effectively resolved by the fact that the slots have different priorities (IOGE signals are combined according to the appropriate logic). For Scorpion and others, this
is not solved in any way...

AS> access is carried out directly through ports that are always available,

Yes, this is a serious advantage over some controllers.

AS> it is simple, accessible for repetition.

And contains circuit design errors... Who doesn’t know, the rake
specific ones - only works with each Nth drive.

= Hardware Spectrum (500:812/1.507) ========================= HARDWARE.ZX =
Msg : 346 of 417 Snt Loc Scn
From : Kirill Frolov 500:812/1.507 22 Mar 01 00:57:36
To : All 22 Mar 01 00:57:36
Subj : WHO HAS NOTDOES THE NEM CONTROLLER WORK? FOR WHOM DID IT NOT WORK?
============================================================================
Immediately click on RESET, All!

If there are (subject) such people or if it didn’t work for someone,
and then after some shamanism it started working, please test my bugfix.
It helped me. Conner screw 210MB. Without a bugfix, the driver froze, and the screw
light blinked. But I can’t test my controller on different models of problematic hard drives. I see the reasons for the problems in the fact that a microcircuit of type
ID7 (series is not important) has outputs that are not very well suited for
working on a long hard drive cable and as a result the cycle of writing to registers
is at least bifurcated, and when writing commands the screw and the driver
become out of sync, the driver hangs in an eternal polling cycle...
There is also a second potential bug of the circuit that I have not identified:
when writing a word In the hard drive, the data in the drive is captured on
the positive edge of the IOWR signal. And the IR22 register, which stores
the contents of the higher half of the address bus, is also controlled by the IOWR signal.
If the hard drive responds to a change in the IOWR signal longer than the IR22 register turns off (plus the signal delay in the loop), then an erroneous value will be written to the high byte of the word
.

All bugs can be fixed (should!) with this bugfix:

1. Return the circuit to original look (so that everything is likeNo,
otherwise it makes no sense).
2. Doesn’t work? This is very good!
3. RESET is applied to the screw directly, bypassing the AP5 chip.
4. Instead of RESET, the IOWR signal is passed through the AP5 chip (to the same contacts)
directly from the ID7 decoder and only then goes
to the rest of the circuit.
5. The HA2 and IORD signals passing through the AP5 are swapped.
That is, HA2 should, as a result, go through the AP5
half controlled by the EBL signal, and IORD through the constantly switched on half.
6. Turn on, test...
7. TEST DISK WRITING ON LARGE FILES, count the CRC, check
whether it’s broken.
It’s better to do it in iS-DOS on a partition of the hard drive that It’s not a pity to accidentally spoil it!
8. We write the report in echo, in soap...
9. For greater reliability (and even more so if there were problems in point 7)
the INVERTED
signal IORD is supplied to the OE input of the IR22 microcircuit (the one that is connected by outputs to the higher
half of the screw data bus) instead of IORW. That is, you will need to put 1533LH1 or
something similar on the board.

10. EVERYTHING.

P.S.: There is also a very easy opportunity to increase the speed of reading
data from the hard drive to 125% of the current one - instead of A0, put A8 on the second decoder
.

Now reading (original circuitnemovskaya) happens like this:

INC C
INI
DEC C
INI
....

And it will happen like this:

INI
INI
....

The recording speed does not change during modification. It is worth remembering that on average,
usually reads many times more than is written - fast reading is much
more important than slow writing.

Refinement does not make sense on machines with turbo mode - the speed increase
will be scanty.

-+- [ZX]
+ Origin: Registered Linux User #204355 (500:812/1.507)

Apparently, Now we can already say that point 9 is not mandatory.

AS> The Nemo controller can be a standard for the spectrum.
AS> Therefore, it is the Nemo controller, and, for example, not SMUC, which accesses the ports
AS> through *ROM*!!! A rare feature.

Imagine, I have SMUC and Scorpion. Or even Sprinter. Are you
suggesting that I take a soldering iron and convert it into KAY? You got off crazy...

On Sun, 01 Feb 04 20:44:14 +0300, Andrey Sergaev wrote:

─ Emulator people hanging out (2:5030/827.2) ZX.SPECTRUM
─
Msg : 1323 of 1954

From : Ivan Mak 2:5030/529.24 23 Sep 99 20:35:00

To : All 24 Sep 99 07:33:52

Subj : Scheme of the HDD controller of the Sprinter computer (corrected)

────────────────── ────────────────────── ───────────────────── ───────────────────

Greetings, All!

=== Cut ===
╔══════════════════════════════ ══════════╦══════════════════════╗
║ ║ Designed by Ivan Mak ║
║ Sprinter HDD controller. Version 1.02. ║ FIDO: 2:5030/529.24 ║
║ ║ (C) 1999 Peters-Plus ║
╠═══════════════════════════════
║ The diagram is intended for possible repetition and installation on ║
║ computers of the ZX-Spectrum type, as well as for understanding the logic ║
║ of the HDD operation of the Sprinter computer ║
╠═══════════════════════════════
║ "Buffers" ║
║ Kr1533AP6 ║
║┌──┬────┬──┐ ║
║ D0──────┤D0│ RG │Q0├───────────────────────────────────┬─WD0 ║
║ D1──────┤D1│ │Q1├──────────────────────────────────┬──WD1 ║
║ D2──────┤D2│ │Q2├─────────────────────────────────┬───WD2 ║
║ D3──────┤D3│ │Q3├────────────────────────────────┬────WD3 ║
║ D4──────┤D4│ │Q4├───────────────────────────────┬─────WD4 ║
║ D5──────┤D5│ │Q5├──────────────────────────────┬──────WD5 ║
║ D6──────┤D6│ │Q6├─────────────────────────────┬───────WD6 ║
║ D7──────┤D7│ │Q7├────────────────────────────┬────────WD7 ║
║ ├──┤ │ │ ││││││││ ║
║ /RD───┤<>│ │ │ ││││││││ ║
║ DIR1──┤OE│ │ │ ││││││││ ║
║ └──┴────┴──┘ ││││││││ ║
║ Кр1533АП6 Кр1533ИР23 ││││││││ ║
║ ┌──┬────┬──┐ ┌──┬────┬──┐ ││││││││ ║
║ D0──────┤D0│ RG │Q0├────────┬──────┤D0│ RG │Q0├────────┘ ║
║ D1──────┤D1│ │Q1├───────┬───────┤D1│ │Q1├───────┘ ║
║ D2──────┤D2│ │Q2├──────┬────────┤D2│ │Q2├──────┘ ║
║ D3──────┤D3│ │Q3├─────┬─────────┤D3│ │Q3├─────┘ ║
║ D4──────┤D4│ │Q4├────┬──────────┤D4│ │Q4├────┘ ║
║ D5──────┤D5││Q5├───┬───────────┤D5│ │Q5├───┘ ║
║ D6──────┤D6│ │Q6├──┬────────────┤D6│ │Q6├──┘ ║
║ D7──────┤D7│ │Q7├─┬─────────────┤D7│ │Q7├─┘ ║
║ ├──┤ │ │ ││││││││ ├──┤ │ │ ║
║ VCC──┤<>│ │ │ ││││││││DIR3──┤WR│ │ │ ║
║ /WR──┤OE│ │ │ ││││││││DIR2──┤OE│ │ │ ║
║ └──┴────┴──┘ ││││││││ └──┴────┴──┘ ║
║ ││││││││ ║
║ │││││││└────────────────────────────WD8 ║
║ ││││││└─────────────────────────────WD9 ║
║ │││││└──────────────────────────────WD10 ║
║ ││││└───────────────────────────────WD11 ║
║ │││└────────────────────────────────WD12 ║
║ ││└─────────────────────────────────WD13 ║
║ │└──────────────────────────────────WD14 ║
║ └───────────────────────────────────WD15 ║
║ ║
╠═══════════════════════════════════════════════════════════════╣
║ ║
║ "Схема, вшиваемая в ПЛМ" ┌─────────────────────DIR3 ║
║ │ ┌──┐ ║
║ ┌───/HDD_ENABLE─────┬─┴───┤1 ├──────────/HDD_CS1 ║
║ │ ┌──┐ │ ┌───┤ │ ║
║ ├─┤1 ├─────┐ │ │ ├──┤ ║
║ /WR──────────│─┤ │ │ ├─│───┤1 ├──────────/HDD_CS3 ║
║ │ ├──┤ │ │ │ ┌─┤ │ ║
║ ├─┤1 ├───┐ │ │ │ │ └──┘ ║
║ /RD──────────│─┤ │ │ │ │ │ └──────┐ ║
║ │ └──┘ │ │ │ │ ┌──┐ │ ║
║ └──────┐ │ │ ┌──────│─┴───┤1 o─┘ ║
║ │ │ │ │ │ └──┘ ║
║ │ │ │ │ │ ║
║ ┌──┐ ┌──┐ │ │ │ │ ├────────────┐ ║
║ /WR───┤& ├─────┤1 ├─┘ │ │ │ │ │ ║
║ /RD───┤ │ ┌─┤ │ │ │ │ │ ┌──┐ │ ║
║ └──┘ │ └──┘ │ │ │ └─────┤1 │ │ ║
║ │ │ │ │ ┌──────────┤ ├─┐ │ ║
║ │ │ │ │ │ WRH └──┘ │ │ ║
║ │ ┌──┐ │ │ │ │ ┌──┬────┬──┐ │ │ ┌──┐ ║
║ A8──────┬────│─┤1 o───│─│─│─┤ ┤S │ TT │ │ │ └─┤1 ├─────DIR1 ║
║ │ │ └──┘ │ │ │ │ ├──┤ │ Q├──│───┤ │ ║
║ │ └──────┐ │ │ │ ├─┤D │ │ │ │ ├──┤ ║
║ │ ┌──┐ │ │ ├─│─┼─>C │ │ _│ └───┤1 ├─────DIR2 ║
║ /IORQ───│──────┤1 │ │ │ │ │ │ ├──┤ │ Qo┐ ┌┤ │ ║
║ │ ┌─┤ ├─┘ ├─│─│─│─┤R │ │ ││ │└──┘ ║
║ │ │ └──┘ │ │ │ │ └──┴────┴──┘│┌──┐│ ║
║ │ └──────┐ │ │ │ │ └┤& ├┘ ║
║ │ │ └─│─│─│─────┬────────┤ │ ║
║ │ │ │ │ │ │ └──┘ ║
║ │ │ │ │ │ │ ┌──┐ ║
║ │ │ │ │ │ └─────────────┤1 │ ║
║ └───────────│───│─│─│───────────────────┤ ├──/HDD_RD ║
║ │ │ │ │ └──┘ ║
║ ┌──┐ ┌──┐ │ │ │ │ ┌──┐ ║
║ A1────┤& o─────┤& o─┘ │ │ └──────────┤1 ├───────────/HDD_WR ║
║ A2────┤ │ ┌───┤ │ └─│────────────┤ │ ║
║ ├──┤ │ ┌─┤ │ │ └──┘ ║
║ A5────┤1 ├─┘ │ └──┘ │ ║
║ A7────┤ │ │ │ ║
║ └──┘ │ │ ┌──┐ ║
║ A6───────────┘ │ A0────────┤1 ├─────────────HD_A0 ║
║ │ ├──┤ ║
║ ┌──┐ ┌──┐ │ A1────────┤1 ├─────────────HD_A1 ║
║ A1────┤1 ├─────┤& ├───────│────────┬───┤ │ ║
║ A2────┤ │ ┌───┤ │ │ │ ├──┤ ║
║ └──┘ │ ├──┤ │ A2────│───┤1 ├─────────────HD_A2 ║
║ A14────────┴───┤& ├───────┘ └───┤ │ ║
║ A2─────────────┤ │ └──┘ ║
║ └──┘ ║
║ ═════════════════════════════════════════════════════════════ ║
║ Здесь прорисованя только логика в ПЛМ. ║
║ Действительная реализация в корне отличается от нарисованной, ║
║ так как ПЛМ позволяет реализовывать сложные функции на одной ║
║ ячейке. Кроме того, адресация портов производится через схему ║
║ распределения портов Sprinter-а, которая позволяет изменить ║
║ все адреса портов винчестера. ║
║ При повторении достаточно повторить только логику и обеспечить║
║ отсутствие "глитчей". ║
║ Кроме того в ПЛМ введена дополнительная задержка от начала /IO║
║ так как в режиме TURBO на 21MHz не успевают устанавливаться ║
║ адреса портов винчестера.║
║ Pins /HDD_WR,/HDD_RD,/HDD_CS1,/HDD_CS3 are fed to the IDE connector ║
║ through 150 ohm resistance. ║
║ The /HD_RES signal can be connected or not connected to the computer reset ║
║. It’s better not to connect, but some hard drives ║
║ can seriously “shut up” if you work with them incorrectly and ║
║ they may need a hard reset. ║
║ An LED is attached to the /PDIAG signal through a 300 ohm resistor at ║
║ +5v to indicate the operation of the HDD. (but sometimes the LED lights up ║
║ at random, especially with old hard drives and in SLAVE mode ║
║ The /HD_RDY signal is either connected or not connected to ║
║ /WAIT of the processor. It is better to connect through the AND element with the signal ║
║ going to this pin of the processor from the computer circuit. ║
║ ══════════════════════════════ ═══════════════════════════════ ║
║ Wiring of 40-pin HDD connector ║
║ ┌──────────┬───────┬────────── ┬───────────┐┌────────────────┐ ║
║ │1 /HD_RES│11 WD3 │21 --- │31 --- ││ │ ║
║ │2 GND │12 WD12│22 GND │32 --- ││ "pins" │ ║
║ │3 WD7 │13 WD2 │23 /HDD_WR│33 HD_A1 ││ on board │ ║
║ │4 WD8 │14 WD13│24 GND │34 --- ││ for cable │ ║
║ │5 WD6 │15 WD1 │25/HDD_RD│35 HD_A0 ││ │ ║
║ │6 WD9 │16 WD14│26 GND │36 HD_A2 ││ 246 40 │ ║
║ │7 WD5 │17 WD0 │27 /HD_RDY│37 /HDD_CS1││ ooo.......o │ ║
║ │8 WD10 │18 WD15│28 --- │38 /HDD_CS3││ ooo........o │ ║
║ │9 WD4 │19 GND │29 --- │39 /PDIAG ││ 135 39 │ ║
║ │10 WD11 │20 --- │30 GND │40 GND ││ │ ║
║ └──────────┴───────┴────────── ┴───────────┘└────────────────┘ ║
║ ══════════════════════════════ ═══════════════════════════════ ║
║ The diagram works on Sprinter, but there may be ║
║ inaccuracies in the drawing itself. ║
║ ══════════════════════════════ ═════════╦═════════════════════ - sector number port ║ LD BC,0050h ║
║ 0053h - sector number port ║ INI..INI ; 512 times ║
║ 0054h - port of the cylinder number, junior ║ RET ║
║ 0055h - port of the cylinder number, senior ╠═════════════════════ ║
║ 4052h - drive port/head number ║ Recording sector: ║
║ 4053h - command/status register port ║ CALL HDD_READY ║
║ 4054h - port 3F6h port ║JR C,ERROR ║
║ 4055h - port port 3F7h ║ LD BC,0150h ║
║ When writing to a port, its address must be ║ OUTI..OUTI ; 512 times ║
║ increase by 100h ║ RET ║
║ ══════════════════════════════ ═════════╩═════════════════════ ║
╠═══════════════════════════════
║ How does the scheme work? ║
║ ║
║ Z80 ┌───┐ ║
║ bus │Buf│ ║
║ ──┬──┤<─>├────────────┬──<─> Low Byte ║
║ │ │ 1 │ │ ║
║ │ ├───┤ ┌───┐ │ ║
║ │ │Buf│ │Reg│ │ ║
║ └──┤──>├──┬──┤──>├──┘ HDD bus ║
║ │ 2 │ │ │ 3 │ ║
║ └───┘ │ └───┘ ║
║ │ ║
║ └────────────<─> High Byte ║
║ ║
║ 1. Reading all registers exceptdata register, A8 = 0 ║
║ Data from the HDD bus through buffer 1 is transferred to the processor. ║
║ Only the low byte, the high byte is not needed. ║
║ ║
║ 2.1 Reading the data register, A8 = 0 ║
║ Data from the HDD bus is transmitted through buffer 1 to the processor. ║
║ Only the low byte, the high byte is needed and it is latched in ║
║ register 3 ║
║ ║
║ 2.2 Reading the data register, A8 = 1 ║
║ Data from register 3 through buffer 1 is transferred to the processor. ║
║ - high byte - HDD is not selected at this moment ║
║ ║
║ 3. Writing all registers except the data register, A8 = 1 ║
║ Data from the Z80 bus through buffer 1 is transferred to the HDD bus. ║
║ Only the low byte, the high byte is not needed. ║
║ ║
║ 4.1 Writing the data register, A8 = 0 ║
║ Data from the Z80 bus is transferred through buffer 2 to register 3. ║
║ Only the low byte, the high byte is needed and it is expected in the next ║
║ cycle. The HDD is not selected at this moment.║
║ ║
║ 4.2 Writing the data register, A8 = 1 ║
║ Data from register 3 is transferred to the HDD bus - low byte. ║
║ - high byte - transmitted through buffer 2 from the processor ║
║ ║
║ Why is paragraph 4.2 different from 3, although the operations in type ║
║ are the same? ║
║ Because before 4.2 there is always 4.1, which sets the ║
║ trigger WRH to one and thus switches the path ║
║ of bytes. This allows you to use OUTI commands ║
║ to write a sector to the HDD ║
║ ║
╚════════════════════════════════ ═══════════════════════════════ў
=== Cut ===

Wow! The Protoss are attacking my Zerlings! It's time to get going. Ivan...data-saferedirecturl="https://www.google.com/url?hl=ru&q=http://www.atlant.ru/peters&source=gmail&ust=1785433079931000&usg=AOvVaw3SdbMp7dQw.petl0planKt>Dmct>www *
-+- GoldED 2.50+
+ Origin: Rectals have lived on the planet Rens for 2 million years. (2:5030/529.24)

AS>> speed 506KB/sec! On _no_ speed! On the _Nemo_
AS>> controller! By the way, precisely due to the fact that I wrote exactly
AS>> _only_ for the Nemo controller, and due to the fact that I wrote all
AS>> subprograms for working with the screw myself, and *did not use a driver*.

KF> Explain. how she manages to exceed the theoretical maximum
KF> speed. As Kozhevnikov said, without recording the shadow register?

1. Yes, without recording...
Or rather, recording is made once per sector.
2. Due to 8bit addressing, it is possible to use the command
OUT (N),A 11 clock cycles
Instead of OUT (C),A 12 clock cycles
Or (God forbid) OUTI 16 clock cycles
3. Recording is done in groups of 255 sectors.
The last group can contain from 1 to 255 sectors.
4. The recording is made by a piece of code
OUT (DATA_HIGH), A
REPT 256
OUT (DATA_LOW), A
ENDR
RET
Naturally, this piece is generated before the start of STORE, and is not stored in the
program.
5. Hy and interrupts, naturally, are disabled...

KF> Only
KF> this is possible, but this is an exceptional case, for nothing other than
KF> writing with one byte, or for idle reading is not suitable. It would be possible
KF> to add such a function to the driver, but it would only bloat the code, and
KF> it would be of little usethere is none.

Exactly, exceptional cases can always appear...
That’s why I don’t like the concept of drivers, that it cuts off these cases.
And as a result, I think, original solutions should disappear. It is no longer possible to squeeze the MAXIMUM out of the equipment... ... and get away with it...
I don’t know what example to give to make it clear.
Imagine if everyone’s keyboards hung not on standard ports, but where
every manufacturer wants - and y some would be generally accessible ONLY
via ROM or by clever_last_int.

You can’t do it like this anymore:
...
XOR A
AKEY IN A,(#FE)
AND 31
XOR 31
JR Z,AKEY
...

Note: By the way, in this prog Iron Driving in Ports! :)
But I wouldn’t call it stupidity...

But I would have to write something like this:
...
XOR A
LD (ERR_NUM),A
CALL
JP C,ERROR
CALL INC_ERR_NUM
CALL JP C,ERROR
CALL INC_ERR_NUM
CALL
JP C,ERROR
...
LD A,BEGIN_ERROR_NUMBER_FOR_KEYBOARD_DRIVER
LD (ERR_NUM),A
CALL GET_VERSION_OF_KEYBOARD_DRIVER
CP #20
JP NC,ERROR
CALL INC_ERR_NUM
CALL INSTALL_KEYBOARD_DRIVER
JP C,ERROR
...
AKEY LD A,KEYBOARD_DRIVER_FUNCTION_XX
CALL KEYBOARD_DRIVER
JR Z,AKEY
...

INC_ERR_NUM
PUSH HL
LD HL,ERR_NUM
INC (HL)
POP HL
RET

case
ERROR LD A,(ERR_NUM)
DAA
LD C,A
AND #0F
OR #30
LD B,A
LD A,C
RRCA
RRCA
RRCA
RRCA
AND #0F
OR #30
LD C,A
LD (MNUM),BC
LD DE,#4000
LD IX,MES_ERR
CALL PRINT_STRING
JP EXIT_TO_SYSTEM
...

MES_ERR DB 'Runtime error number '
MNUM DB 'XX',0
ERR_NUM DS 1

What I like about the Spectrum is that a non-standard approach is possible here,
discoveries are possible. And one of the main roles in this is played by strict standardization. Standardization disappeared - headaches appeared. The code started
blowing...

With best wishes,

February 05, 2004 (and it was 11:52 pm then)
Andrey Sergaev in his letter to Kirill Frolov wrote:

AS> You can’t do it like this anymore:
AS> ...
AS> XOR A
AS> AKEY IN A,(#FE)
AS> AND 31
AS> XOR 31
AS> JR Z,AKEY
AS> ...

Yeah :) If you do this, the program will freeze on the piss keyboards. If you don't insert the halt... Well, and, of course, interruptions will also have to be turned on. So
the idea of ​​a driver, albeit a primitive one, and not as sophisticated as you presented
below, IMHO is justified.

Compare, for example, all sorts of turbo loaders that squeezed the maximum speed out of the drive. With the advent of screws, these programs refused to work for them. I had to rewrite everything back to #3d13. So.

Vega/ex-Style Group.

FIDO: 2:5030/1512 ZXNET: 500:812/19 E-mail: veg...@mail.ru ICQ: 144932679

VS> Yeah :) And if you do this, the program will freeze on the pisish keyboards.
VS> If you don’t insert the halt... Well, and, of course, interruptions will also have to be enabled
VS>. So the idea of a driver, albeit a primitive one, and not as sophisticated as you presented below, IMHO is justified.

Justified... Due to the current crisis circumstances.
Yes, it will freeze.
And not only this.
It is incorrect to make a PC keyboard controller that inserts WAITs in the processor input/output loop.
And many PC keyboards (especially cheap ones) also have this unpleasant
feature - you cannot press, say, 10 keys at the same time, it will bend at the fifth or sixth key and stop transmitting press/release codes. Such keyboard
+ controller incorrectly emulate the _STANDARD_ Specter keyboard.
In fact, without WAIT the controller is not that difficult to implement.
You need to enter a register file between it and the processor.
But with This unpleasant feature is difficult to deal with - I have never seen a PC keyboard without it. Maybe they exist somewhere, I don’t know.

VS> Compare, for example, all sorts of turbo loaders that squeezed the maximum speed out of the
VS> drive. With the advent of screws, these programs
VS> refused to work for them. I had to rewrite everything back to
VS> #3d13. So.

Timonin Maxim akaMaksagor promised to please us with the VG93 emulator. His
Turbo-loaders should work.