From: Spiro Trikaliotis on
Hello,

just some nit-picking:

Linards Ticmanis <ticmanis(a)gmx.de> schrieb:

> So once every line of characters the CPU has to stop for 40 cycles, so
> that the character numbers can be read and stored. Then during the
> normal video cycles only the character shapes are read. Color numbers
> for the characters, on the other hand, are read in parallel from a
> special SRAM with its own addressing lines going to the video chip.

The color RAM has its own DATA lines, but the same address lines.

It is D8-D11 on the VIC-II.

Regards,
Spiro.

--
Spiro R. Trikaliotis http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
From: Paul Schlyter on
In article <op.s9uev3d6ru4cq2(a)news.t-online.de>,
John Selck <gpjiweg(a)t-online.de> wrote:
>Am 12.05.2006, 04:21 Uhr, schrieb Michael J. Mahon <mjmahon(a)aol.com>:
>
>> And in any case, depending on the peculiarities of a particular chip
>> implementation is just asking to be locked out of future improvements.
>
>Like I stated several times now: You can easily do a processor check and
>use different code. On plain 6502 you use the faster routine with illegals
>and on 65816 etc you use a normal routine. It's 5 minutes work to do that.

....and how do you account for future versions of 6502 in that
processor tests?

That's of course a non-issue for the 6502, where there will be no
future versions. But the issue is still valid for other processors
where there may be future versions.


--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/
From: heuser.marcus on
> LDIR eats 21 clock cycles per iteration, doing the same with other Z80
> instructions can be way faster.
>
> I tried to use the Z80 in the C128 for block copy/fill because I thought
> "hey, it has a block copy command, so I guess it is fast" but it wasn't.
> Then I tried normal opcodes, it was way faster than using LDIR but still
> not faster than copying the stuff with the 8502.

But if the 6502-designers had chosen to implement a block move then
of course it would've been way faster! ;o)

bye
Marcus

From: Bruce Tomlin on
In article <1148126608.168023.119240(a)38g2000cwa.googlegroups.com>,
heuser.marcus(a)freenet.de wrote:

> > LDIR eats 21 clock cycles per iteration, doing the same with other Z80
> > instructions can be way faster.
> >
> > I tried to use the Z80 in the C128 for block copy/fill because I thought
> > "hey, it has a block copy command, so I guess it is fast" but it wasn't.
> > Then I tried normal opcodes, it was way faster than using LDIR but still
> > not faster than copying the stuff with the 8502.
>
> But if the 6502-designers had chosen to implement a block move then
> of course it would've been way faster! ;o)

You could speed up memory moves on the 6809 with the multiple register
PSHS/PULS/PSHU/PULU instructions. They can move up to 10 bytes of
registers plus the PC with only two instruction byte fetches (unlike
LDIR which constantly branches back 2 bytes to read the opcode again),
but for memory moves you need to use the other stack register for your
destination, which means 8 bytes max. The trick is that you have to
either disable interrupts or do things such that you can tolerate
interrupts using either your source or destination memory for a stack.

I dug up some old code of mine which scrolled a bitmap display (6K) by
doing 256 loops, each with four moves of 6, 6, 5, and 5 bytes. (I was
avoiding using the DP register because this code was for OS/9 or I could
probably have done 8/8/6, but I still don't know why I was moving 22
bytes per loop instead of 23.) The difference between that and just
doing a loop of LDD ,X++ / STD ,Y++ (which is still better than the Z80
because of the post-increment or 6502 because of 16 bits at a time) was
enough to make the scrolling tolerable.
From: Laust Brock-Nannestad on
heuser.marcus(a)freenet.de wrote:
> Be careful or Captain Zilog crushes you!

> http://www.milehighcomics.com/cgi-bin/backissue.cgi?action=fullsize&issue=14882664687%201

This was actually an ad for Zilog's Z8000 processor, not the Z80 :-)


Regards,

Laust