Passing parameters to a cunning piece of hardware

ZXNet echo conference «code.zx»

From Victor Ronin To All 12 July 2006

Hello hero her> that's the question, let's say you send about 10 identical commands her> they only differ in, say, one parameter, and the parameter in her> the cycle is calculated and the following body movements are obtained her> her> First, select where the thread is a buffer for the command packet her> her> fill it her> using outi we push it into the piece of hardware her> calculate the parameter her> edit the buffer her> and all over again and how do you plan to edit this very parameter when it is already filled in There is a FIFO buffer :) Well, a bunch of pop hl - they also seem to be eating at the same time :) But you can not waste your brains and hang 256 bytes of regular RAM on the high byte (a8-15) port and edit these commands either lengthwise or across.

From Dmitry Demyanenko To All 12 July 2006

Hello fk0 fk0> For slow-witted people: IN THE SPECTRUM, THE LOWER 8 BITS HAVE VALUE. Did you think about what you said? fk0> LD HL, parameters_address fk0> LD BC, #xxyy ; xx is your register, yy is the port. fk0> OTIR fk0> fk0> Slow? Yes, I kind of already came to this conclusion

From Dmitry Demyanenko To All 12 July 2006

Hello, captain cobalt cap> You can listen only to the LD command and take it directly cap> operands. cap> The code will look like this: We were thinking about this option, the trouble is that if you close such a loop in a loop design, then you will have to make self-modifying code, and the result looks like it turns out slower than when using outi (although there is no sign at hand I could have lied). I'm probably leaning towards the option of working with block input/output commands, it has 2 plus 1. there will be no need to pervert much 2. the implementation of hardware will be easier

From Dmitry Demyanenko To All 12 July 2006

Hello Ronin Ron> OUTI is not too slower than stack copy Here’s the question: let’s say you have about 10 identical commands, you need to send them they only differ in, say, one parameter, and the parameter is calculated in the loop such body movements are obtained First, select where the thread is a buffer for the command packet fill it out using outi we push it into the piece of iron calculate the parameter editing the buffer and all over again That is, there are unnecessary body movements, the question is - do you think this is normal (you can can I come to terms with this)?

From Dmitry Demyanenko To All 12 July 2006

Hello Ronin Didn't put it clearly You can simply carry out the necessary manipulations in the register and send the push again hl. In general, the option with outi turns out to be the most optimal.

From van Yu Shinn To All 12 July 2006

Hello hero Purely in terms of clock cycles, memory works faster than ports. Even without DMA, you can simply catch access to certain memory addresses. Then You can combine two methods: LD DE,#xxxx - for passing constants LD (#zzzz),HL - for passing variables For programmers, a programmable device is most convenient. To have your own processor, it is given a program and then it independently works according to this the program and does not interfere.

From van Yu Shinn To All 12 July 2006

Hello hero her> it is planned to minimize the number of ports in the address space her> cars An alternative option is opening/closing ports. When old software is running, which can spoil the ports, the ports are closed and not react. New cool software works with open ports and uses their capabilities. her> 1. The stack is used You can only listen to the LD instruction and take its immediate operands. The code will look like this: ┌─- code ─── LD HL,#xxxx LD HL,#yyyy LD HL,#zzzz LD A,A └── code ─── Another option is DMA. her> 2. if there is an interruption between PUSH HL instructions A smart piece of hardware could listen to them and behave accordingly.

From Victor Ronin To All 12 July 2006

Hello skyther there is no need to be afraid of classic ports :) or shared memory as the fastest option for throwing arrays. sky> Send the command “write data to register N”, then send the necessary command sky> number of bytes in the data reg. This is how v9990 works, by the way - you indicate the starting address, and go away bytes in a row :)))) OUTI is not too slower than stack copying, quite passable. and simple enough to use.

From Victor Ronin To All 12 July 2006

Hello hero I like the memory on ports better ;)

From Kirill Frolov To All 12 July 2006

Hello hero her> Since it is planned to minimize the number of ports in the address her> machine space we add only 2 ports 1-internal index her> register, 2 directly addressable register in connection with this her> it becomes inconvenient to pass parameters her> since the following type of manipulation is obtained her> 1. set the register number for parameter 1 in the first port her> 2. write the parameter to port 2 her> Heresy. Take ONE 8-bit port. There will still be 8 bits left (high half addresses) to address 256 registers of your hardware. For slow-witted people: IN THE SPECTRUM THE LOWER 8 BITS HAVE VALUE. ld a,a // sign of the piece of hardware that the command needs to be executed Stupid method. In the sense that anything can happen spontaneously to be fulfilled. Through ports it is more reliable. [quote] The main requirements for the method are 1. Speed [quote] LD HL, parameters_address LD BC, #xxyy ; xx is your register, yy is the port. OTIR Slowly?

From van Yu Shinn To All 12 July 2006

Hello hero This is, one might say, DMA. And without DMA this is LD (#zzzz),HL The piece of hardware decrypts #zzzz, understands that it is being addressed, and catches 2 bytes. like this the command can be used in a loop with different HL values.

From Dmitry Demyanenko To All 12 July 2006

Hello, captain cobalt cap> Purely in terms of clock cycles, memory works faster than ports. cap> Even without DMA, you can simply catch calls to specific addresses cap> memory. Then you can combine two methods: I understand correctly We give the hardware buffer address (BASE) in 8 bytes (for the command packet) Then we write the parameters there, and let’s say when writing a command to BASE+0 of the piece of hardware takes this as a sign that you can begin execution. That is, it is possible modify one byte and write (overwrite) the code of the command and hardware started performing it

From Mark Antonov To All 13 July 2006

Hello Ronin Ron> OTI Ron> OTI Ron> OTI Ron> OTI outi =) and for modifying parameters, dilute outi with regular out

From Wladimir Bulchukey To Victor Ronin 13 July 2006

Hello, Victor...! 12 Jul 06 19:45, Victor Ronin -> All: VR> this is how v9990 works, by the way - you indicate the starting address, and off you go VR> shove bytes in a row :)))) Well, why 9990 right away... Both 9958 and 9938 were able to do this. This was originally classic access to MSX video memory. With the best - Wlodek # wlblack()newmail.ru # http://wlodeks.narod.ru [ZX] [500:95/462@ZXNet] [2:5016 Forever] [Golyanovo] [Old Russians]

From Victor Ronin To All 14 July 2006

Hello, The Exploited The> outi =) gee ;) her> the same time if the ports are mapped to a memory card Well, we’re going the right way :) it only makes sense to map it as a memory if you large arrays need to be sent. when we are talking about 16 bytes this is not so important. yes and You can map to memory via the bus just anywhere. but only in one place on one single signal without arbitration. those. this is a very valuable tire resource with which need to be handled carefully (unlike ports). although if you map in parallel with regular memory (i.e. only for writing to the device) - it is possible and where whatever :)

From Dmitry Demyanenko To All 14 July 2006

Hello Ronin Ron> although if you map in parallel with regular memory (i.e. write only Ron> to the device) - you can go anywhere Exactly!!! Moreover, this does not depend on the bus architecture. Moreover, with this feint The problem with reading ports is solved. And some commands appear in the interrupt handler (it is enough to save the changeable parameters)

From Kirill Frolov To All 14 July 2006

Hello hero her> At the same time, if the ports are mapped to a memory card for transfer 16 her> bit parameter is enough 16 is ld (xxxx), HL besides her> become Through memory, a couple of clock cycles faster (actually those cycles that are “entered additionally in the I/O loop). The question is where to map. In the Spectrum it is not allowed instead of ROM or RAM damn knows what to "sample". Although it is possible instead of ROM. In the sense that the bus allows. Via RAM no way (meaning addresses 0x4000--0xffff). But this is also a direct path to incompatibility problems and inconvenience for the encoder (you need to track what is there in ROM).

From Kirill Frolov To All 14 July 2006

Hello hero her> Quote: her> Message from fk0 her> For slow-witted people: IN THE SPECTRUM, THE LOWER 8 BITS HAVE VALUE. her> her> Did you think about what you said? "Larchenko and Rodionov" on the corresponding page. Are you going to argue?

From Dmitry Demyanenko To All 14 July 2006

Hello fk0 fk0> The question is where to map. In the Spectrum it is not allowed instead of ROM or fk0> RAM God knows fk0> what to "map". Although it is possible instead of ROM. In the sense that the tire fk0> allows. Via RAM fk0> nothing (meaning addresses 0x4000--0xffff). But this is also direct fk0> the path to incompatibility problems and inconvenience for the coder (need fk0> track what is in the ROM). The piece of hardware monitors the address bus, data bus and nMREQ nWR and when the processor writes to the area we need, we save it inside the piece of hardware and there is no compatibility, then if you map to the ROM area, you lose the ability to read what was written down, and where the registers are located can also be indicated programmer