 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stefan Viljoen wrote:
> Warp wrote:
>
>> Stefan Viljoen <pov### [at] polard com> wrote:
>>> Warp wrote:
>>
>>> > The first 32 bytes in the screen memory represented the first line
>>> > of
>>> > pixels (256 of them). The next 32 bytes represented the *eigth* line
>>> > of pixels. The next 32 bytes represented the *sixteenth* line of
>>> > pixels, and so on, until you get to one third of the screen, ie. 8
>>> > such groups of 32 bytes, after which the next 32 bytes represented the
>>> > second line
>
> Which ZX Spectrum video mode was this?
>
> 'pedia says there are / were lots and lots of them - what mode does this
> arrangement refer to? The lowest res one?
>
> Or were all the modes arranged similarly to this way, only with longer
> lines and "quicker" jumps?
From http://www.worldofspectrum.org/faq/reference/sereference.htm:
---
Memory is paged in 8K banks from either the DOCK or the EX bank, but these
banks are mutually exclusive - you cannot page in a bank from both
simultaneously. Bit 7 of port 0xff determines which bank to use (0=DOCK,
1=EX-ROM). Port 0xf4 determines which banks are to be paged in with each bit
referring to the relevant bank (0-7 or 0'-7'). When memory is being paged,
interrupts should be disabled and the stack should be in an area which is
not going to change.
On a TC2048, BASIC is contained in the 16K ROM area and banks 0-7 and 0'-7'
are not normally available, while on a TS2068 part of the BASIC is stored in
an 8K ROM in bank 0' and cartridges plugged into the dock use banks 0-7. On
the SE each of these banks is connected to 64K of RAM, providing an
additional 128K in addition to the base RAM.
The contended memory timings for the SE are unknown but should be similar to
that for the 48K machine, except that the pattern starts at a different
number of T-states after the interrupt, than the usual 14335. Odd banks in
the 128 scheme are contended.
---
"Memory is paged in 8K banks from either the DOCK or the EX bank, but these
banks are mutually exclusive - you cannot page in a bank from both
simultaneously."
and
"The contended memory timings for the SE are unknown but should be similar
to that for the 48K machine, except that the pattern starts at a different
number of T-states after the interrupt, than the usual 14335. Odd banks in
the 128 scheme are contended."
What does that imply? It seems as if the reason for the knit-one-slip-one
video RAM approach was the way the Speccy handled interrupts, and / or the
hardware being incapable of paging more than 8K at a time? (8192 bytes / 256
bytes per line = 32 ?)
I. e. on one interrupt tick you can get the first 32 columns of line one, on
the next tick the first 32 columns of line sixteen, etch. - due to the
limitations of the architecture's memory handling paradigm of "max 8k
blocks" only?
--
Stefan Viljoen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stefan Viljoen <pov### [at] polardcom> wrote:
> Which ZX Spectrum video mode was this?
The ZX Spectrum has exactly one video mode.
> 'pedia says there are / were lots and lots of them - what mode does this
> arrangement refer to? The lowest res one?
I don't know which article you are reading, but it's definitely not about
the ZX Spectrum.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stefan Viljoen <pov### [at] polardcom> wrote:
> From http://www.worldofspectrum.org/faq/reference/sereference.htm:
> ---
> Memory is paged in 8K banks from either the DOCK or the EX bank
This talks about the RAM, not the reason why the pixels are arranged as
they are.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Stefan Viljoen <pov### [at] polardcom> wrote:
>> Which ZX Spectrum video mode was this?
>
> The ZX Spectrum has exactly one video mode.
>
>> 'pedia says there are / were lots and lots of them - what mode does this
>> arrangement refer to? The lowest res one?
>
> I don't know which article you are reading, but it's definitely not
> about
> the ZX Spectrum.
>
http://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes
?
--
Stefan Viljoen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Stefan Viljoen <pov### [at] polardcom> wrote:
>> From http://www.worldofspectrum.org/faq/reference/sereference.htm:
>
>> ---
>> Memory is paged in 8K banks from either the DOCK or the EX bank
>
> This talks about the RAM, not the reason why the pixels are arranged as
> they are.
Hmm. Wouldn't it make sense? The video display is just visible RAM by
definition... isn't it? Or am I mistaken?
I. e. if you can only address an 8K page at a time, and access to memory is
limited by the last-triggered interrupt, and the limitations / maximum word
size of your architecture.
I. e. on one tick you can address even lines.
On the other you can address odd lines.
Given that 8K paging is your "chunk limit", wouldn't that explain why the
video pixels are arranged in such a way as you describe?
Everything fits if you assume you can only address 8192 bytes at a time
during any given interrupt - you CANNOT address the whole screen, because
your word size is too small.
Contrast with an IBM PC with a VGA card. You can comfortably get a linear
address into the entire 320x200 screen (64000 bytes) with any of the CPU's
16 bit address registers. With an 8 bit address register you can't?
So you arrange your video RAM (which you can't all address at once with an 8
bit address register) to "give" you alternating blocks on an interrupt which
is acted upon by your memory controller, effective switching contexts with
each tick?
--
Stefan Viljoen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stefan Viljoen <pov### [at] polardcom> wrote:
> http://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes
The "ZX Spectrum clones" are not ZX Spectrum. The standard ZX Spectrum had
only single video mode.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Dude, I thought this was just an urban legend! O_O
Nope. When your clock speed is in the kilohertz range, it's pretty easy.
--
Darren New, San Diego CA, USA (PST)
Is God willing to prevent phrogams, but not able?
Then he is not omnipotent.
Is he able, but not willing, to prevent phrogams?
Then he is malevolent.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Dude, I thought this was just an urban legend! O_O
>
> Nope. When your clock speed is in the kilohertz range, it's pretty easy.
Perhaps you mean "when your clock speed is in the kilohertz range and
all opcodes take a deterministic number of clock cycles to fetch and
execute"?
Even then, it seems highly unlikely to me that anybody would actually
work out which opcodes yield which EM intensity and somehow produce a
carrier wave of the exact right frequency and precisely modulate its
intensity... This would surely be a vast engineering task.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Perhaps you mean "when your clock speed is in the kilohertz range and all
> opcodes take a deterministic number of clock cycles to fetch and execute"?
>
> Even then, it seems highly unlikely to me that anybody would actually work
> out which opcodes yield which EM intensity and somehow produce a carrier
> wave of the exact right frequency and precisely modulate its intensity...
> This would surely be a vast engineering task.
With the ARM processor it would be easy, as all the "standard" instructions
take the same time and all are 32 bits. You can easily look up how each
part of each instruction maps to each of the 32 bits and then decide what
patterns to send. You could even probably keep 4 or 6 bits the same (eg to
do an ADD instruction) and then just set the rest to whatever you want to
make your pattern (it would just mean random registers got added and stored
in other ones etc).
I would imagine after a bit of trial and error of different 00000111111 and
000111 type patterns you could get it working.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> intensity... This would surely be a vast engineering task.
>
> With the ARM processor it would be easy, as all the "standard"
> instructions
> take the same time and all are 32 bits. You can easily look up how each
> part of each instruction maps to each of the 32 bits and then decide what
> patterns to send. You could even probably keep 4 or 6 bits the same (eg
> to do an ADD instruction) and then just set the rest to whatever you want
> to make your pattern (it would just mean random registers got added and
> stored in other ones etc).
>
> I would imagine after a bit of trial and error of different 00000111111
> and 000111 type patterns you could get it working.
Granted, doing something like that would be technically brilliant in my
book.
But to what end?
There are ways to waste time and then there are WAYS to waste time...! ;)
The only people you might impress with something like that would be your D &
D buddy whose got skin like a mole and never leaves his basement and his PC
except to DM your newest AD & D session or chair the local Warhammer club's
meeting.
Most other people would probably just go "dude WTF!"
--
Stefan Viljoen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
