Text screen or sprites
ZXNet echo conference «hardware.zx»
Hello, All
From: Kirill Frolov
Date; Mon; Apr 2 2001 3:48 pm
Area; fido7.zx.spectrum;
> Press RESET immediately, All!
>
>
> Now many people install SIMM modules and even instead of memory in the Spectrum
> they manage to overclock them to 7Mhz instead of 3.5Mhz. It turns out that the processor
> and the video controller can read twice as many bytes per second
> from memory. The processor uses this, but the video controller does not. But
> you can try. When overclocking memory, each byte is read
> one more additional byte can be considered a video controller. That is
> for a standard Spectrum screen for every 1/8 part
> there are 4 bytes of familiarity: a monochrome image, a color byte and
> two unused bytes. These two unused bytes can be
> use as a memory address from which two will be read
> next byte of image and color. Then if you split the screen by
> 8x8 familiarity spaces and the three least significant bits of the address are taken directly from the counters
> and the most significant bits from the two "unused" bytes, and in addition> disable the curb signal, you can get a screen size 56x40
> familiarity (on the Pentagon, where there are 320 lines), and each familiarity
> is addressed by some sprite whose address is stored in
> "unused" bytes. Thus, the size of the information describing
> the screen content in sprites will be only 4480 bytes. A
> the size of sprites can be very large (at least 64kb). Acceleration
> when working with graphics up to 4 times. Probably relevant for games.
>
>
> When the 512x192 mode is enabled and the border is disabled, the same
> this way you can get a text screen of 112x40 characters
> capable of simultaneously displaying 256 different characters in
> monochrome mode.
From a software point of view it looks attractive. To update a site
screen, the number of operations will be proportional to the perimeter, not the area. Then
what is needed for higher resolutions.
Hello, captain cobalt
The question is, where are you doing with the synchronizing row areas and, accordingly,
sync lines? Or rather, not you, the author of the quote :)
Hello hero
her> where are you doing the synchronizing row areas
There is no need to quibble over unimportant details. Screen size is a thing here
tertiary, the main thing - the actual essence of the idea - is to address the sprite (which
the video processor must substitute a familiar place for this) using 2 unused
bytes of attributes and 3 low addresses. In general, a very worthy idea on the topic
"The idea of a simple extension of the standard video mode." For fans of v9990 it’s more likely
no use :smile; .;
Hello, Black_Cat
I can’t imagine solving this problem using the method of cutting paths and
soldering of mikrukh, this method assumes quite seriously modified
video controller. Although the idea is naturally not bad