On Tue, Apr 26, 2011 at 4:58 PM, Chris Pile wrote:
> Besides, there's something *pure* about having a chunk of RAM and a CPU -
> and not much else!
While it's pure, and the basis for some of the great machines — the
Spectrum, obviously, but also the ST, sort of the VGA-era PC and the
original Mac
I'm not sure having only a basic ability to shift the screen around would have
been much use without
additional hardware support. Such as sprites for example. Having to render
lots of software sprites
over nothing more than a shiftable 24k lump of RAM would get very messy code
wise. Especial
On 26 April 2011 15:55, Thomas Harte wrote:
> And we're told that a selectable screen start address was considered but
> not
>
possible in the current design
>
I'll be honest: until someone actually gives a proper reason why it couldn't
be done I won't really believe that that's true. Maybe no-o
> Umm... Well you can't read and write the same byte in the same cycle; but
> you're right, if the 79000 frames figure is correct that would be usable.
> However I'm not sure it is: system clock is 6MHz, so 6M T-states per second,
> that's 120,000 every frame (6M/50). That's about 30,000 memory cyc
On 26 April 2011 15:11, Tommo H wrote:
>
> On 26 Apr 2011, at 14:38, Geoff Winkless wrote:
>
> On 26 April 2011 14:23, Tommo H <
> tomh.retros...@gmail.com> wrote:
>>
>> The 25fps is based on a hypothetical chip having the same access as the
>> CPU does currently.
>>
>
> But would still take up
On 26 Apr 2011, at 14:38, Geoff Winkless wrote:
On 26 April 2011 14:23, Tommo H wrote:
>
> The 25fps is based on a hypothetical chip having the same access as the CPU
> does currently.
>
But would still take up the majority of the bus time, meaning you couldn't
do anything _else_.
And at pres
On 26 April 2011 14:23, Tommo H wrote:
>
> The 25fps is based on a hypothetical chip having the same access as the CPU
> does currently.
>
But would still take up the majority of the bus time, meaning you couldn't
do anything _else_.
> I also disagree about the significant amount of electronics
On 26 Apr 2011, at 13:47, Geoff Winkless wrote:
On 26 April 2011 13:15, Thomas Harte wrote:
You end up having to contend with the video during the move so you're still
talking about significant slowdown. You might get 25fps scroll but that
would take most of your bus time, leaving you not much t
On 26 Apr 2011, at 12:46, Geoff Winkless wrote:
> On 26 April 2011 10:55, Chris Pile wrote:
> Some sort of blitter to chuck large blocks of data around at high speed would
> have been
> a *very* nice addition. That 24k screen really is too much for the old Z80
> to cope with!
>
> Eugh... _an
On 26 April 2011 13:15, Thomas Harte wrote:
> Apart from a desire for part uncontended memory (ala the Spectrum) and
> a hardware scroll, a simplified blitter would have been advantageous
> (eg, give it start address, end address, length, tell it to go and
> then it replaces the z80 on the bus un
Apart from a desire for part uncontended memory (ala the Spectrum) and
a hardware scroll, a simplified blitter would have been advantageous
(eg, give it start address, end address, length, tell it to go and
then it replaces the z80 on the bus until the copy is complete; even
with the CPU having to
On 26 April 2011 10:55, Chris Pile wrote:
> Mmmm, not sure I would have like hardware scrolling to be honest. It would
> probably
> have meant a glut of scrolling marioesque platform games. Which - for me -
> is a whole
> lot less desirable than infinite ball demos!
>
Yes, scrolling platformer
Mmmm, not sure I would have like hardware scrolling to be honest. It would
probably
have meant a glut of scrolling marioesque platform games. Which - for me - is
a whole
lot less desirable than infinite ball demos!
Some sort of blitter to chuck large blocks of data around at high speed would
On 26 Apr 2011, at 10:25, Geoff Winkless wrote:
> Would it have been better to have 48kB of more expensive display memory,
> giving only the live display and a secondary (for double-buffering) but
> losing the ability to use any page in RAM as the screen?
> For me the real mistake, though, was
On 26 April 2011 10:08, Chris Pile wrote:
> Hi Si,
>
> Yep - clear as mud! :-)
>
> Seriously, many thanks for the explanation - even my hardware-limited brain
> managed
> to understand all that! I take my hat off to hardware designers, it's
> certainly a black art!
>
> Mmm. I often used to wond
Hi Si,
Yep - clear as mud! :-)
Seriously, many thanks for the explanation - even my hardware-limited brain
managed
to understand all that! I take my hat off to hardware designers, it's
certainly a black art!
I've always tried to keep as much as I can in registers, so I've always been on
th
David Brant wrote:
> Just to put a spanner in the works. JP's are faster in external memory.
JR and JP will both be 12T in external memory, which is the same speed as they
are in internal RAM during the border area. External RAM gives the same speed
boost as disabling the display, by avoiding
Chris Pile wrote:
> In short, then, I guess I should ignore what Zaks is telling me
> regarding T-states and simply try to use single/double byte
> instructions wherever and whenever possible?
As a very rough guide, round the official instruction timings up to the next
multiple of 4, then doubl
Hi sent this directly to Chris by mistake so sending again.
Just to put a spanner in the works. JP's are faster in external memory.
On 25 Apr 2011, at 21:44, Chris Pile wrote:
> Hi Si,
> In a word... Wow! I hadn't realised there was such a performance hit using
> JP over JR!
> A 24T JP is pai
19 matches
Mail list logo
