SuperCPU?
Müller
I've read that JPX runs on a SuperCPU. I never heard of that. Is this a
tuned up C64? Or is it another rare Commodore Computer?
Greetings
Carsten Mueller
Hernan Vergara
On Fri, 1 Oct 1999, Müller wrote:
> I've read that JPX runs on a SuperCPU. I never heard of that. Is this a
> tuned up C64? Or is it another rare Commodore Computer?
If you want to know what a SuperCPU is go to...
Hernan
BigRed
Müller wrote in message <37F4C8BF...@t-online.de>...
>Hi th.ere
>
>I've read that JPX runs on a SuperCPU. I never heard of that. Is this a
>tuned up C64? Or is it another rare Commodore Computer?
SuperCPU is a C=64 accelerator made by CMD in the USA - which poor Ozzies
like me will never be able to afford !? :-(
>Greetings
>Carsten Mueller
Greetings to all out there in *the* best newsgroup of them all!
Programmer, technician and general C= and Amiga nutter -
Rick.
ps - I am half way through putting a C=64 into a desktop case, and have
recently built my own A1200 tower - anyone else out there as nuts as me ?!?
Müller
In fact that you are an Amiga user i have a question.
Do you have any links to good Amiga-Emulation pages?
My Emulator-Page needs some more links in the Amiga-Section.
the Adress is: http://miller.ist-super.de
Thanks.
Greetings Miller
BigRed schrieb:
j...@mich.com
> tuned up C64? Or is it another rare Commodore Computer?
The Super CPU is a daughter board that contains a very high speed CPU,
additional memory, and a few other features... As
Hernan Vergara <hver...@accessnv.com> Wrote
>If you want to know what a SuperCPU is go to...
If you think of the basic 64 as about an 80486 sx/33 (Which is not much faster
than a basic 64) then the super CPU would be about a pentium 1000 or better.
In short, IT ROCKS
John Davis, Still using his back up usenet service in Delightful Detroit
Marko Mäkelä
John> If you think of the basic 64 as about an 80486 sx/33 (Which is
John> not much faster than a basic 64)
The validity of the above statement depends on your definition of
"much". The 80486 has a 32-bit data bus, i.e. it can move 4 bytes in
one bus cycle. For instance, the fastest block copy routine for the
6502 takes 14 bus clock cycles per byte or more. I don't remember how
many cycles per word the block-copy instruction (or maybe it was a
loop of 2 or 3 instructions) of the 80486 takes, but I don't think
that it can be even 10 cycles. So, the 80486 will shovel at least
4/10 bytes per bus cycle, and if its running at 33 MHz, you get a
factor of (33*4/10) / (1/14) = 185 for this simple operation. Of
course using the REU would do the same thing in 1 cycle per byte (or 2
cycles with the swap operation), but that's not the stock C64.
Believe me, the 80486 is much faster than the 6502. It's just the
applications that make it seem slow. Either the applications are more
sloppily coded and bloated (look at M$ software) or they have much
more functionality (just compare e.g. some archaic-looking Unix text
editors like "ed" and "vi" to any editor on the C64: you won't find
regexp operations in the latter). Applications on the 6502 have to be
hand-coded in machine language; compilers that are used on more
powerful systems make them slower by a small factor. If you want a PC
that is roughly equivalent to the C64 in performance, you will have to
go back to a 8086 or 8088 running at 4.77 MHz.
Marko
Jonas Bevren
>
> >>>>> "John" == jfd <j...@mich.com> writes:
>
> John> If you think of the basic 64 as about an 80486 sx/33 (Which is
> John> not much faster than a basic 64)
>
Enter the expert of Commodore64 (bows to the great presence) hehe =)
> The validity of the above statement depends on your definition of
> "much". The 80486 has a 32-bit data bus, i.e. it can move 4 bytes in
> one bus cycle. For instance, the fastest block copy routine for the
> 6502 takes 14 bus clock cycles per byte or more. I don't remember how
> many cycles per word the block-copy instruction (or maybe it was a
> loop of 2 or 3 instructions) of the 80486 takes, but I don't think
movsb is a neat instruction. It does the following, all within 3 cycles:
1: load a source byte into the temp register
2: store the same byte into the destination address
3: check whether to increase or decrease the index register
4: do so
Now, if you combine said instruction with the REP instruction, a 5th and 6th
action is added:
5: decrement the CX register
6: provided CX is not zero, it repeats the movsb command.
This will thus move one byte every 3 cycles.
MOVSW moves one word (two bytes) every 3 cycles.
I'm certain there's a move string long (4 bytes every 3 cycles) in there
someplace.
That, at 33mhz, gives you 11megs, 22megs, or 44megs/sec block move at 33mhz.
The SuperCPU's processor rests on an 8-bit bus (its a 16bit cpu, right, but it's
only 8bit wide data bus.. look at the chip documentation from WD). With Marko's
said 14 clock cycles/byte, you're not getting much beyond 1meg/second. Using a
65816 native command, MVP or MVN, you can do the same move in half the clock
cycles, lending almost 3megs/sec.
> that it can be even 10 cycles. So, the 80486 will shovel at least
> 4/10 bytes per bus cycle, and if its running at 33 MHz, you get a
> factor of (33*4/10) / (1/14) = 185 for this simple operation. Of
> course using the REU would do the same thing in 1 cycle per byte (or 2
> cycles with the swap operation), but that's not the stock C64.
>
> Believe me, the 80486 is much faster than the 6502. It's just the
the <<80386>> is much faster than the 6502. Therein, its much faster than the
65816.
> applications that make it seem slow. Either the applications are more
> sloppily coded and bloated (look at M$ software) or they have much
> more functionality (just compare e.g. some archaic-looking Unix text
> editors like "ed" and "vi" to any editor on the C64: you won't find
> regexp operations in the latter). Applications on the 6502 have to be
> hand-coded in machine language; compilers that are used on more
> powerful systems make them slower by a small factor. If you want a PC
I'll debate that 'small' with you sometime Marko =)
> that is roughly equivalent to the C64 in performance, you will have to
> go back to a 8086 or 8088 running at 4.77 MHz.
Right. Raw block moving is about that speed.. Overall functionality, however,
is guessed by me at somewhere between 286-12 and 286-33 (no such beast existed,
but you get the idea)
-JB
Jonas Bevren
I hate replying to my own posts, but this must be noted: The 80486 has more
than one execution unit.. It can parallelize this move twice (it has two integer
execution units).. Hmz.. makes 22, 44, or 88megs/sec if you get two rep movsl's
in the EU at once.
Marko Mäkelä
Jonas> With Marko's said 14 clock cycles/byte, you're not getting much
Jonas> beyond 1meg/second. Using a 65816 native command, MVP or MVN,
Jonas> you can do the same move in half the clock cycles, lending
Jonas> almost 3megs/sec.
You forgot that the cartridge port's bandwidth is limited to 1 MB/s.
Accelerator cards similar to the SuperCPU (I know of a 4 MHz card and
of an 8 MHz card) use a write-through cache and keep the internal
memory in the C64 up-to-date, because that memory is used by the video
chip for graphics output. So, the accelerator will have to wait for
the bus. If there's no blocking video DMA (the screen is blanked),
then the raw speed would be around 1 MB/s, the same you will get with
an REU.
Marko> Applications on the 6502 have to be hand-coded in machine
Marko> language; compilers that are used on more powerful systems make
Marko> them slower by a small factor.
Jonas> I'll debate that 'small' with you sometime Marko =)
Of course this factor depends on the type of the processor. A RISC
processor with lots of all-purpose registers is easiest to generate
code for. On the 6502 it is practically impossible to beat a machine
language programmer with a code generator; on architectures with
delayed branching and other things that are difficult for the human
but easy for the computer, the performance penalty is negligible.
Jonas> Right. Raw block moving is about that speed.. Overall
Jonas> functionality, however, is guessed by me at somewhere between
Jonas> 286-12 and 286-33 (no such beast existed, but you get the idea)
Of course, I should have said that block moving is not everything.
But this explains why compressors (also called crunchers) are so slow
on the Commodores compared to the performance on even 286 PCs.
Marko
macb...@my-deja.com
> Jonas> With Marko's said 14 clock cycles/byte, you're not getting much
> Jonas> beyond 1meg/second. Using a 65816 native command, MVP or MVN,
> Jonas> you can do the same move in half the clock cycles, lending
> Jonas> almost 3megs/sec.
>
> You forgot that the cartridge port's bandwidth is limited to 1 MB/s.
> Accelerator cards similar to the SuperCPU (I know of a 4 MHz card and
> of an 8 MHz card) use a write-through cache and keep the internal
> memory in the C64 up-to-date, because that memory is used by the video
> chip for graphics output. So, the accelerator will have to wait for
> the bus. If there's no blocking video DMA (the screen is blanked),
> then the raw speed would be around 1 MB/s, the same you will get with
> an REU.
Well, both of you folks are right - when the C64's main 64k is
being accessed, the limit would be 1 MB/s. When moving memory
around in extended memory (up to 16MB in the SCPU's case), it
can approach 3 MB/s, particularly if the memory access is linear.
--
Robin Harbron mac...@psw.nu
http://www.psw.nu/
Sent via Deja.com http://www.deja.com/
Before you buy.
arc...@delphi.com
4 megs of data around within the SuperCPU's SuperRAM. That's
the results I get when opening up a hole in a large text file
that requires moving about 4 megs worth of text.
-
-Maurice
Clockmeister
BigRed wrote in message ...
>>tuned up C64? Or is it another rare Commodore Computer?
>
>
>like me will never be able to afford !? :-(
Are you in WA ?.
Just wondering...
Regards,
Clockmeister.
Jonas Bevren
> Jonas> beyond 1meg/second. Using a 65816 native command, MVP or MVN,
> Jonas> you can do the same move in half the clock cycles, lending
> Jonas> almost 3megs/sec.
>
> You forgot that the cartridge port's bandwidth is limited to 1 MB/s.
> Accelerator cards similar to the SuperCPU (I know of a 4 MHz card and
> of an 8 MHz card) use a write-through cache and keep the internal
> memory in the C64 up-to-date, because that memory is used by the video
> chip for graphics output. So, the accelerator will have to wait for
> the bus. If there's no blocking video DMA (the screen is blanked),
> then the raw speed would be around 1 MB/s, the same you will get with
> an REU.
Of course. Those things are taken for granted in my mind, as is the ISA bus
access delays required to get tho their I/O devices, and the video memory on any
given video card. While ISA can do 16 bit accesses at 8mhz or so, there are
more cycles taken for a single access. Sad, methinks.
> Marko> Applications on the 6502 have to be hand-coded in machine
> Marko> language; compilers that are used on more powerful systems make
> Marko> them slower by a small factor.
>
> Jonas> I'll debate that 'small' with you sometime Marko =)
>
> Of course this factor depends on the type of the processor. A RISC
> processor with lots of all-purpose registers is easiest to generate
> code for. On the 6502 it is practically impossible to beat a machine
> language programmer with a code generator; on architectures with
> delayed branching and other things that are difficult for the human
> but easy for the computer, the performance penalty is negligible.
Agreed. This particular CPU (the 65816) is nearly the same as the 6502, and
doesnt have any fancy delayed-branch and multiple-function opcodes. All I can
do here is agree totally with what you said =)
Just one comment needs be made.. Why is this: The faster computers get, the
slower they run. ??=)
> Jonas> Right. Raw block moving is about that speed.. Overall
> Jonas> functionality, however, is guessed by me at somewhere between
> Jonas> 286-12 and 286-33 (no such beast existed, but you get the idea)
>
> Of course, I should have said that block moving is not everything.
> But this explains why compressors (also called crunchers) are so slow
> on the Commodores compared to the performance on even 286 PCs.
Of course. in fact, comparing the SCPU to any machine equipped with a
dissimilar or more advanced CPU is unfair, and impossible to back up without
much argument. Something that needs to be kept in mind, is the fact that this
is, in fact a simple CPU, as covered above, and all applications so far written
for the c64 are written to run as well as absolutely possible. That makes a c64
equipped with a superCPU feel more responsive than a 600mhz pentium running
windows.
-Jonas
ps: sorry, marko, I was off CSC for a few days.
Jonas Bevren
(offtopic)
text? Do I smell and editor? =) I'd love to see an editor that uses superRAM.
I was, in fact, pondering trying to write one this evening.
-Jonas
arc...@delphi.com
>text? Do I smell and editor? =) I'd love to see an editor that uses superRAM.
Yes, my new SUPERTEXT editor can handle however much free ram
you have available in your SuperRAM. SUPERTEXT is a part of a
much larger application called PostPrint 2 which will be available
from Dale Sidebottom (luck...@iglou.com) when it's ready. Currently
it's in beta testing and 15 different users are testing it for me.
PostPrint 2 requires Wheels 64 or Wheels 128.
-
-Maurice
Jonas Bevren
Maurice saves the day!!! =)
Maurice - does this save regular petscii text files? I'm working on an editor
cause nate's ram devices all died in the same week, and he cant edit his 100k
source file for modplay64. Do you have it around for download any place?
requires wheels? I'm all ears =)
-jb
arc...@delphi.com
>Maurice - does this save regular petscii text files? I'm working on an editor
>cause nate's ram devices all died in the same week, and he cant edit his 100k
>source file for modplay64. Do you have it around for download any place?
>requires wheels? I'm all ears =)
PostPrint 2 is designed to work with PostScript files which are
always in true ascii. It can send data to the printer, or it can
save the data to either a geoWrite file or to another plain ascii
file. It also automatically recognizes any end of line character
style (CR,LF, or CR/LF) and converts them to carriage returns for
internal editing. When saving a file, you have the option of selecting
the desired end of line depending on if you plan to share the file
on another type of machine.
As stated, SUPERTEXT is currently a part of PostPrint 2 and is only
available through Dale Sidebottom when it's finally ready. I might
do a stand alone version with more compatibility options later, but
currently its main purpose, as stated, is for PostScript editing.
And some PostScript files can get quite large.
-
-Maurice