!!! ìÉÎÅÊÎÁÑ ÁÄÒÅÓÁÃÉÑ ÜËÒÁÎÎÏÊ ÏÂÌÁÓÔÉ
ZXNet echo conference «real.speccy»
RA> - the transition to an adjacent familiarity is carried out by incrementing the high
RA> byte, to the line below - by increasing the low byte. Such addressing
RA> combines the advantages of standard and linear addressing, while
RA> the addressing is linear not in columns, but in rows.
What will happen to the convenience of scrolling, compared to linear? Block commands are a breeze, and are they needed for graphics at all? With small sprites, as I understand it, everything is fine.
KIA
On Thu, 24 Jun 04 17:05:58 +0400, Ivan Kuvshinov wrote:
IK> And what will happen to the convenience of scrolling, compared to linear?
Where to scroll? Up and down the entire screen? Now this is
192-8 calls of 32 LDIs.
IK> Block commands are a breeze, and are they needed for graphics at all?
Oh well? Now they only work not with rows, but with columns.
And the difference is not that big...
IK> With small sprites, as I understand it, everything is fine.
Cramp with checking for the intersection of a third of the screen.
KF> Cramp with checking for the intersection of a third of the screen.
As I understand it, the person suggested getting rid of these thirds, and leaving the rest
about the same.
I still think that you can’t think of anything better than linear addressing. No
screen address shifts are needed on the speccy either, its address space is not so big that it can unpack the video into memory and run on the screen
on it :). But if you make a new screen mode, then it must be with buffered output, so as not to copy to the output, but to immediately build on screen addresses and get rid of memory braking, and we will also get a free screen clearing in time, that is, ClrScr. And it’s always possible to make sure that the same buffer page is displayed as is available for writing, but first you need to
solve the issue with the control ports that are multiplying like mushrooms, drive them into a page or something, on the BC, it seems like this initially, and leave a few in the address
space forever, so that the same pages can be clicked by writing to memory.
Yes, by the way, in 128 mode also has a buffer, right (otherwise I only had 48, I somehow missed this point)? Only the people are dissatisfied that it takes so long
to click?
KIA
IK> As I understand it, the person suggested getting rid of these thirds, and
IK> leaving the rest
IK> about the same.
Yes...
IK> run :). But if you make a new screen mode, then it must
IK> must
IK> be with buffered output, so as not to copy to output, but immediately
IK> to be built according to
IK> screen addresses and get rid of memory braking, and we will also get
IK> free
What should I copy where??? There are now two screens. You build one, you show the other.
What other memory slowdowns? The Soviet Spectrum, with rare
exceptions, never had them...
IK> time-based screen clearing, that is, ClrScr.
CLS is not needed. In general...
IK> And to make sure that the same
IK> buffer page is displayed as is available for writing is always possible, only first
IK> you need
IK> to resolve the issue with the control ports that are multiplying like mushrooms, put them on the page
IK> or something
IK> on the bookmaker, it seems like this initially, and leave a few in
IK> address
What are we even talking about? I have completely lost the idea.
IK> (otherwise I only had 48, I somehow missed this moment)?
It looks like that...
IK> Only people are unhappy that it takes so long to click?
Screen? 12 bars.
KF> Explain your idea. In particular, WHAT is linear
KF> addressing worse or better in this case? As it was (192-8+23)*32 LDI, so
KF> will remain...
but what to do with the beam?
Goodbye, write letters.
IK>> have to cost a lot, there's always something to load the processor with, even
IK>> if we're talking about banal text output.
KF> Explain your idea. In particular, WHAT is linear
KF> addressing worse or better in this case? As it was (192-8+23)*32 LDI, so
KF> will remain...
Good. I actually wanted to say that all sorts of “new formulas”, as a rule, are good in special cases, of which there are not very many. Linear addressing has been tested on many machines and no one has complained. I think that the Spectrum
screen, although well designed, is not very convenient, at least for
scrolling and with its divisions into three parts. It is possible that the proposed
model will be a little more convenient than the linear one - let it be so, then I am for it, but only because
it is also “tested” on the Spectrum and is also quite convenient, although I think
that you still need to find out the opinions of others on this matter.
KF> What should I copy where??? There are now two screens. You build one, the other
KF> you show.
I see. But I just don’t understand why a person needed to change the address of the screen
area arbitrarily, I think that with two pages at one address
it’s very convenient - while it’s displayed, build whatever you want, and then set the order?
RA> this can be implemented.
So far, there has been no interest in such a thing yet.
And there are a few words about the graphics on Speccy. I believe that it is impossible, and simply
impossible, to overwhelm its graphical capabilities, regardless
of whether it is a super-duper lotion for two bucks on six Pentium Pro processors
or loose stuff for 800x600 TrueColor.
If you look at the much-unloved PC platform, in retrospect, you can
see very well that as soon as they appeared, you can say traditional
resolutions then the volume of programs, and in particular games, has grown by orders of magnitude and system requirements have grown by the same amount. Moreover, even now graphics are the main “engine” of progress. If at 256 colors there were quite reasonable limits -
40MHz, 4-8Mb RAM, 1-20Mb program, then further: 233MHz, 4-8Mb Video!,
150-640Mb program. In order for the Spectrum to be able to move such volumes, it needs to be remade in such a way that nothing remains of it. :(
I think that it is still necessary to raise the resolution, but 512x384 and a byte of color per byte
is quite enough so that text capabilities do not suffer and it is better with
colors, but then this is nonsense. Just look at the size of the addressable
space so that there would be no desire to turn the z80 into a coprocessorby
clicking pages to a super cool graphics accelerator.
And in general, most of the bells and whistles are not needed. Why do you need DMA? As I understand it, they are going to use it to run bits from memory? LDIR is not enough,
then connect it to some Altera, Crusoe or whatever it is, the processor itself
and it will be 40 MHz, and another microcosm will appear, so the same firmware and please - 200.
And it will be enough, and it can be used for other needs, but the architecture
will remain the same, just don’t go crazy and improve the processor itself,
including bars on the command. At the logical level, everything should remain
as close to the original as possible, including I am against adding bit depth to
address more memory.
KIA
VK> what to do with the ray?
1. Hammer (in a text editor).
2. Use double buffering in 2 screens.
3. Output from left to right and top to bottom, as expected:
ld (hl), x
inc h
ld (hl), x
inc h
...
ld (hl), x
ld a, h
and 0xe0
ld h, a
inc l
...
Yes, there are inconveniences when using LDI. So we can still
argue about which screen is more profitable.
25 June 04 03:23, you wrote to Kirill Frolov:
IK> you can’t think of anything to address. No screen address shifts are needed on the
IK> speccy either, its address
IK> space is not so large to unpack the video into memory and run across it
IK> with the screen :). But if you make a new screen mode, then I will definitely disagree a little - you will get very beautiful full-screen scrollers with very
low processor load. like ATARI 800 for example.
/_*──────────────────────────────────── ───────────────────────────[80`s]────*_/
IK> We are talking about a banal thing - when some incompatible modifications are made,
IK> they
IK> must be switchable, that is, there must be a configuration port or
IK> byte, in
There has been talk about this here since 1998. That's why EFF7 was
invented. But it looks like it’s already run out of bits. There is also a port for "switches" - CFF7 (supported by MadROM). But with the use
of its bits there is no certainty at all.
IK> memory. In general, I suggested mapping ports to memory and putting
IK> them into
IK> a separate page, then they can be used like regular
IK> memory.
Especially if it is a memory switching port...
IK> This can provide benefits for such critical things as fast transfer
IK> of data
IK> through the port. But make several of the most important ports not on the page, but
IK> in
IK> regular memory or so that they are not switched at all, for example pieces
IK> 256.
Why is it so difficult?
KF>
KF> 1. Enter (in a text editor).
say it -=LD=- with Dark ;)
KF>
KF> 2. Use double buffering in 2 screens.
you can get by with the old screen
KF> 3. Output from left to right and top to bottom, as it should be:
then that makes sense gets lost, push/pop goes through the woods...
KF>
KF>
KF> Yes, there are inconveniences when using LDI. So you can still
KF> argue about which screen is more profitable.
in my opinion, it doesn’t even make sense to argue. By the way, it seems to me that there will still be problems with memory regeneration.
Goodbye, write letters.
VK> then the meaning is completely lost, push/pop goes through the forest...
Here. I completely missed this. A serious disadvantage of this linear addressing.
Really, it’s not worth arguing...