Re: C64 compared to the Plus 4?

[Dombo]

Op 23-Apr-12 10:00, Jimmy Mac schreef:
>
> Hi All,
>
> I recently acquired a pair of Plus 4's but aside from confirming that one is
> 100% operational, haven't dug very deep into what this little beast can do.
> Does anyone happen to have a quick run-downon how this compares to the C64?
>
> TIA!

Off the top of my head:

- No sprites
- No SID
- (Much) Less software available for it
+ More colors
+ (Much) Better Basic
o Different peripherals

So its a better machine for the more serious stuff, not so good as a
games machine.

[Martijn van Buul]

* Dombo:

> Off the top of my head:
>
> - No sprites
> - No SID
> - (Much) Less software available for it
> + More colors
> + (Much) Better Basic
> o Different peripherals

I'll add to the list..

+ Faster (Considerably so, at 1.76 MHz)
+ Built in machine code monitor
+ Hardware UART (Same one as in the SwiftLink)

--
Martijn van Buul - pi...@dohd.org

[jbones]

> Martijn van Buul - p...@dohd.org

Check out some of the plus/4 demos on youtube to see technical
capabilities. You'll be pleasantly surprised..

[Hg]

On 24/04/2012 00:34, Martijn van Buul wrote:
> * Dombo:
>
>> Off the top of my head:
>>
>> - No sprites
>> - No SID
>> - (Much) Less software available for it
>> + More colors
>> + (Much) Better Basic
>> o Different peripherals
>
> I'll add to the list..
>
> + Faster (Considerably so, at 1.76 MHz)
> + Built in machine code monitor
> + Hardware UART (Same one as in the SwiftLink)
>

Not sure about it being faster - while looking up the machines
capabilities I read a few reports that a double scan happens while
the raster is visible and the clock speed slows to under 1mhz
when the raster is off screen. One particular hardware site states
that because of these factors the overall average speed equals 1mhz
at the end of the day.

Maybe a Plus/4 hardware guru can explain/elaborate the speed issue
in a better reply for you?


--
T

[MagerValp]

On Tuesday, April 24, 2012 4:44:50 AM UTC+2, Hg wrote:
>
> Not sure about it being faster - while looking up the machines
> capabilities I read a few reports that a double scan happens while
> the raster is visible and the clock speed slows to under 1mhz
> when the raster is off screen. One particular hardware site states
> that because of these factors the overall average speed equals 1mhz
> at the end of the day.
>
> Maybe a Plus/4 hardware guru can explain/elaborate the speed issue
> in a better reply for you?

It's about 12% slower while graphics is displayed, but 78% faster when it's not (in the borders). I don't have the details here, but iirc it works out to a PAL Plus/4 having about 40% more CPU cycles than a C64.

[Christian Brandt]

Am 25.04.2012 15:09, schrieb MagerValp:

> It's about 12% slower while graphics is displayed, but 78% faster when it's not (in the borders). I don't have the details here, but iirc it works out to a PAL Plus/4 having about 40% more CPU cycles than a C64.

The C64 CPU also does waitstates while the VIC reads graphic data from
memory. I remember you lose up to 66% of all memory cycles upon every
eigth line displaying data.

All in all the 265/Plus4 is a lot faster than the C64 and sometimes
even faster than a C128 running at 2Mhz (I think this may come from the
slow MMU-Handling of the C128).

Christian Brandt

[Linards Ticmanis]

It has some oddities though. The TED chip is marginal in its cooling and
is prone to burn out at some point, so better fit it with a chip cooler
and/or improve the ventilation of the case. The computer is also said to
be more sensitive than other Commodores to plugging in and removing
cables while it's turned on, since Commodore skimped on diodes and/or
resistors - so never plug in or remove anything, even a joystick, unless
you first power it off.

The built-in productivity software that gives the Plus/4 its name is
supposedly utter crap. I never really tried it for any kind of extended
period, so I can't say if this is true.

There is a special floppy for the Plus/4, the 1551, which plugs into the
expansion port with a giant unsightly plug. It's faster than a 1541. You
can still use all the usual serial port drives, but the 1571 and 1581
will work only in slow mode, as on the C64. A universal software
fastloader for the Plus/4 that works with all Commodore serial drives is
called "One Bit Wonder" and it works quite nicely.

There was (or is?) a bit of a C16 and Plus/4 scene in Hungary and a few
other former Eastern Block countries, which came into being after
Commodore sold their remaining inventory of those machines really cheap
there in the late 1980s when they couldn't find a market for them
anywhere else (it seems that unlike e.g. East Germany and Russia,
Hungary never produced its own computers before the Wall came down, so
for many people there it was their first machine). The people of that
scene produced some decent demos, games, and ports of C64 games. There's
a good Elite port, for example. The German company Kingsoft produced a
couple of low-budget games for the machine, some of which don't suck too
badly.

One oddity I've been told (not sure if it is true) is that the casette
speed tables in the ROM seemingly were created for the fast mode but are
in fact used in the slow mode of the CPU. That means tape loading is
even slower than on the C64 (if that's even possible).

One advantage over the C64 is that you can read the keyboard and
joysticks in such a way that they don't interfere with each other at
all. The standard ROM doesn't do this so you still get strange letters
and symbols when you move the sticks while in BASIC; but some games do
it the right way.

--
Linards Ticmanis

[Dombo]

Op 29-Apr-12 13:03, Christian Brandt schreef:

> Am 25.04.2012 15:09, schrieb MagerValp:
>
>> It's about 12% slower while graphics is displayed, but 78% faster when it's not (in the borders). I don't have the details here, but iirc it works out to a PAL Plus/4 having about 40% more CPU cycles than a C64.
>
> The C64 CPU also does waitstates while the VIC reads graphic data from
> memory. I remember you lose up to 66% of all memory cycles upon every
> eigth line displaying data.

Those are the so-called 'bad lines' used to fetch character pointers,
because there aren't enough cycles in a line to read both the character
pointers and the graphics data. Doesn't the TED chip have 'bad lines'?

> All in all the 265/Plus4 is a lot faster than the C64 and sometimes
> even faster than a C128 running at 2Mhz (I think this may come from the
> slow MMU-Handling of the C128).

When running BASIC programs on the C128 you have bank-switching
overhead, though I would expect that the Plus 4 has the same issue. IIRC
also I/O access on the C128 causes it to slowdown to 1 Mhz.

[dott.Piergiorgio]

IIRC, in an Compute! book (on C-128 ?) the speed issues was also
attributed to the BASIC parsing, the gist of it being that the token
scanning loop takes more time to look up into the larger basic 3.5, 4.0
and 7.0 token list, I don't know if is true (and that I remember well),
but at least makes sense.

Opinion on this ?

Best regards from Italy,
dott. Piergiorgio.

[Anton Treuenfels]

"dott.Piergiorgio" <chied...@ask.me> wrote in message
news:Slenr.163886$GZ3....@tornado.fastwebnet.it...

That doesn't make any sense at all. Scanning the larger token tables matters
only during tokenization (entering program lines), not during execution
(running programs).

However C128 BASIC takes a lot longer to fetch anything at all from RAM than
the C64 or VIC20 because the BASIC ROM is in a different memory space. Every
byte fetch of program text or variable memory has to go through two bank
switches, from the BASIC ROM space and back again. Also the main BASIC
control loop is longer, so statement-to-statement time is a little slower

The BASIC ROMs of the C64 and VIC20 are in the same memory space as program
text and variable memory, so they don't bank switch at all. OTOH, they have
a lot less RAM space than the C128 for BASIC programs. Their main control
loops also don't try to do as much as the C128's.

The 2MHz mode of the C128 covers up a lot of the slowdowns, too.

- Anton Treuenfels

[Tom Lake]

>
> IIRC, in an Compute! book (on C-128 ?) the speed issues was also
> attributed to the BASIC parsing, the gist of it being that the token
> scanning loop takes more time to look up into the larger basic 3.5, 4.0
> and 7.0 token list, I don't know if is true (and that I remember well),
> but at least makes sense.
>
> Opinion on this ?

That doesn't make any sense at all. Scanning the larger token tables matters
only during tokenization (entering program lines), not during execution
(running programs).

Sure it does. Even after the keywords are tokenized, each token must be
found
in a table every time a line is executed in order to be interpreted at
runtime.
The bigger the table, the longer it takes to find the address of the routine
that
executes the function of that token.

Tom Lake

[Anton Treuenfels]

"Tom Lake" <tl...@twcny.rr.com> wrote in message
news:jnukag$6u4$1...@news.albasani.net...

That's true only if the address table is searched each time a token is
found. It isn't. The token itself is used as an index to the address table.
No search involved. If a token has value 'n' then the 'n-th' entry in the
address table holds the routine location. Address table lookups are done in
constant time no matter what value any particular token has.

- Anton Treuenfels

[Questarian]