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