How is the survey carried out? — ZXNet «code.zx»

From Konstantin Sviridov To All 28 November 2005

Hello,GriV If we talk about HDD (ATA), then back in 1994 the problem of accelerating data transfer in the IDE controller for ZX-Next, I decided to arrange the ports (for high and low halves of a data word) in the address space so that when executing INI (OUTI) commands were searched sequentially. As a result, 44 clock cycles were spent on writing a word (16 bits), and 32 clock cycles on reading (more than 200K per second). Even faster in turbo mode. Of course, if there is only one port (or are located “at random”), then there is not much you'll speed up...

From Valery Grigoriev To All 28 November 2005

Hello, All external "fast" devices? For example, a hard drive?? If we take standard lab1:in a,(c) rra jr nz,lab1 in a,(c) ld(hl),a inc hl jp lab1 This text doesn’t even contain any checks as such, but it roughly turns out 12+4+7+12+7+6+10 = 58 clock cycles, which gives a theoretical speed :D up to 60 kb per second :D (that’s why the word “fast” is in quotes), or is it done like this otherwise?

From Chunin Roman To All 28 November 2005

Hello Conan Con> If we talk about HDD (ATA), then back in 94 there was an acceleration problem Con> data transfer in the IDE controller for ZX-Next I decided by placing Con> ports (for the high and low halves of the data word) in the address Con> space so that when executing the INI (OUTI) command they Con> were searched sequentially. Con> As a result, writing a word (16 bits) took 44, and reading 32 Con> clock cycle (more than 200K per second). Even faster in turbo mode. Con> Of course, if there is only one port (or are located “at random”), then there is not much Con> you will accelerate... Yeah, the same thing is done in ATM.

From Konstantin Sviridov To All 29 November 2005

Hello,GriV Gri> I don’t understand, you mean because register B is reduced? Yes, that's right. Gri> i.e. if B=1F Gri> C=FD Gri> then the first outi went to 1ffd Gri> and the second one is at 20fd Gri> ? Everything is correct, only the port addresses were different. Gri> and then each read command of the corresponding port creates Gri> automatic recognition as readiness to accept and accordingly Gri> does the controller produce all the data itself?? There is no need to fence anything there: the sequential arrangement of ports is banal decryption in which A8 is involved (he selects senior/junior data word bits for IDE). We do not use addresses older than A8. Gri> Or you can do this Gri> take 256 commands Gri> INI Gri> and before them the same initialization line - it turns out 16 clock cycles Gri> bytes (faster in software is not possible - hardware limitation), total Gri> about 200 kb for normal mode, 400 kb for turbo!!! And so it was done. 32 clock cycles per word is 16 clock cycles per byte. Just don't you have to delude yourself about the turbo mode: the speed will depend on the specificimplementation, because there is also a slowdown when working with RAM, and for some clones and during input/output operations.

From Valery Grigoriev To All 29 November 2005

Hello Conan Con> If we talk about HDD (ATA), then back in 94 there was an acceleration problem Con> data transfer in the IDE controller for ZX-Next I decided by placing Con> ports (for the high and low halves of the data word) in the address Con> space so that when executing the INI (OUTI) command they Con> were searched sequentially. Con> As a result, writing a word (16 bits) took 44, and reading 32 Con> clock cycle (more than 200K per second). Even faster in turbo mode. Con> Of course, if there is only one port (or are located “at random”), then there is not much Con> you will accelerate... I don’t understand, you mean because of the reduction of register B right? those. if B=1F C=FD then the first outi went to 1ffd and the second at 20fd ? But you can’t somehow do semi-block processing - i.e. let's say the percentage gives out on port waiting to read and then each read command on the corresponding port creates an automatic recognition as readiness to accept and, accordingly, the controller produces everything data yourself?? Those. just makes INIR to 256 values and before it there is a sector selection command, for example ld bc,#fefe ld a,1 (command reading) out (s),a and onwards ld hl,mem_addr ld bc,#00fd inir then (pseudo-block exchange) the speed would be very decent.When reading ports, an IORQ is formed - together with the address, it is purely theoretically possible How about making a controller like this? The logic is simply that in this case the increase from a hard drive is not so much obvious (except, of course, for size and reliability) - at best 10 times faster compared to beta. But if you use the presented circuit, you get roughly 21 clock cycles per bytes - the speed is already decent, but for a turbo it’s generally the same. Or maybe so take 256 teams INI and before them the same initialization line - it turns out 16 clock cycles per byte (it’s impossible to do it faster in software - hardware limitations), a total of about 200 kb for normal mode, 400 kb for turbo!!!

From jtn To All 29 November 2005

Hello Conan Yeah! Well, let's start in order: 1) there is no need to make any expectations - sector (512b) from HDD/CDD is read and it is written without any delays or checks. 2) the implementation of controllers varies. in the worst case it's fifty thousand bytes per second (only the flop drive would be worse =), and the best is 200kb per second without turbo and 400kb with turbo (in ROM/shadow RAM 200%). this is exactly what was done in mine controller and sprinter controller, i.e. reading - 512 ini commands (or 2 inir) and recording 512 pieces of outi (two otir). and the sprint version is somewhat easier =) 3) I remind you once again - in the commands outi, otir, outd, otdr first reg.B is decremented and only then written to the port. There is no need to raise this issue again, it has already been actively discussed on the forum =)

From Valery Grigoriev To All 29 November 2005

Hello jtn jtn> there is no need to raise this issue again, it is already active on the forum jtn> discussed =) wow, where was it discussed?

From jtn To All 29 November 2005

Hello jtn jtn> there is no need to raise this issue again, it is already active on the forum jtn> discussed =) I'm talking about the third point http://www.zx.pk.ru/showthread.php?t=1360&page=9&pp=10

From SMT To All 10 December 2005

Hello,GriV Gri> I would say even more - the most shabby propeller gives a speed of 10 meters Gri> per second which RU5 will reach 10 m/s, with simultaneous maintenance of video and processor :) even with a DMA controller (then what, an interrupt controller is also possible hang it up at the same time to screw up the computer once) 1.75 m/s is not enough for a screw, and it won't be a Spectrum anymore

From SMT To All 10 December 2005

Hello SMT and most importantly, what kind of Spekov tasks do 400 kb/s lack?

From Valery Grigoriev To All 10 December 2005

Hello SMT SMT> and most importantly, what kind of Spekov tasks lack 400 kb/s? 400 kilometers per second (for a turbo and for a good controller and for a good optimized program) is just a figurative figure, in fact the speed will be lower. And that 400 kb per second is fast??? Although I was probably too carried away, in fact, the yellow scorpion has everything I need 256 KB of memory, 1.5-2 seconds conventionally to load all the memory - not so much bad.

From Valery Grigoriev To All 10 December 2005

Hello SMT SMT> which RU5 will pull 10 m/s, with simultaneous service of video and SMT> processor :) even with a DMA controller (then well, you can SMT> hang up the interrupt controller at the same time to screw up the computer once) SMT> 1.75 m/s is not enough for a propeller, and it will no longer be a Spectrum There is already a DMA controller, albeit in small quantities - DMA USC. And 10 meters per second is just an indicator of how little we have compared to that what could be done.