Denial

Your alternative solution is?

as said before, i would add the original CPU for non accelerated mode. since most existing stuff doesnt benefit from an accelerator anyway (games would usually just became silly fast and unplayable) it doesnt matter much if the accelerated mode is 100% compatible.

I may not know a lot of things but other than (maybe... a BIG maybe) Bandits I don't know of anything on the VIC-20 who might be affected by inexact cycle instructions.

bandits, capture the flag, squish em...and a few others (all that are marked "ntsc only" in megacart). and ofcourse every single half decent demo ever written for the vic20. mikes fli stuff too, i guess

groepaz wrote:bandits, capture the flag, squish em...

Funny you would say that because they all work fine with the R65C02 which doesn't seem to meet your criterias.

and ofcourse every single half decent demo ever written for the vic20. mikes fli stuff too, i guess

pffwa... demos again...

At what point exactly are you going to tell us the only valid 6502 substitute is the one found in Turbochameleon ?

I have a R65C02 in my "cold" 1541 and another in my NTSC VIC-20cr. I can't find ANYTHING at all which doesn't run on both of them.

And said 1541 is also equipped with the a pair of W65C22N, you know the ones adapted to fix the IRQ problem with CMOS VIAs ?

I think you're turning this into some sort of religion.

darkatx wrote:[instead of trying to make a SuperCPU why not just conecentrate on one thing and make a SuperGPU. A cartridge that could possibly implement Mike's VFLI or Hursts Software Sprites...

(snip)

The CPU would be freed up to concentrate on everything else instead of rendering and 3D math, etc. That in itself might be a huge performance boost when running apps or games.

Interesting idea. I never thought about that method of speed-up.

Happy New Year,
Robert Bernardo
Fresno Commodore User Group
http://www.dickestel.com/fcug.htm

To very briefly thread-jack...

I have an MD65SC22 (Mitel) salvaged from something years ago. Can I safely use it in a VIC-20, or is it likely to have the IRQ problem mentioned?

Also years ago, someone told me tried a CMOS '22 in his VIC and it worked in one VIA socket but not in the other, but I've forgotten which was which. Any thoughts on this?

http://www.datasheetarchive.com/dlmain/ ... 015763.pdf doesn't say anything any different from the old NMOS parts.

Thanks

Funny you would say that because they all work fine with the R65C02 which doesn't seem to meet your criterias.

so? plain luck then. that doesnt mean all and everything will work in any way. all i said was that these use timing critical code.

At what point exactly are you going to tell us the only valid 6502 substitute is the one found in Turbochameleon ?

at what point exactly will you understand those fpga cores are not designed for this and will not work?

I have a R65C02 in my "cold" 1541 and another in my NTSC VIC-20cr. I can't find ANYTHING at all which doesn't run on both of them.
And said 1541 is also equipped with the a pair of W65C22N, you know the ones adapted to fix the IRQ problem with CMOS VIAs ?
I think you're turning this into some sort of religion.

i prefer to describe it as "paying attention to details at an autistic level". its the only way to make a proper emulator, or substitute for that matter. ignoring some seemingly unimportant stuff here and some other seemingly unimportant stuff there always leads into an halfassed wannabe implementation that will fail on this or that randomly. no thanks.

but ofcourse, if all you want is to run your favourite software and you dont care about "pfff demos" or whatever else someone who isnt you wants to run - go ahead.

groepaz wrote:i prefer to describe it as "paying attention to details at an autistic level". its the only way to make a proper emulator, or substitute for that matter.

Oh please... its a matter of 20% effort, 80% results vs 80% effort for 20% results. The SuperCPU for the 128 and 64 do not include another CPU for improved compatibility. If you're not happy then you disconnect it.

ignoring some seemingly unimportant stuff here and some other seemingly unimportant stuff there always leads into an halfassed wannabe implementation that will fail on this or that randomly. no thanks.

Well, this project is in limbo because its too complex for what I want to invest and I have other projects that require more attention and yield greater results. PLAnkton is only one of them.

I'm not exactly moved by your comment since according to your standards and criterias the 1541 Ultimate 1/2 is a "halfassed wannabe implementation". I feel its a very good solution specifically because Gideon elected to invest energy and time where it is really needed.

If you think you can achieve better then by all means stop telling me what I should or shouldn't do, stop being an armchair digital designer and make a SuperCPU VIC of your own. I certainly won't object.

but ofcourse, if all you want is to run your favourite software and you dont care about "pfff demos" or whatever else someone who isnt you wants to run - go ahead.

My point of focus is legacy software but I suspect the main use for a SuperCPU VIC would be new specialized software or stuff compiled with the likes of Austro compiler or various C and assembly compilers.

Oh please... its a matter of 20% effort, 80% results vs 80% effort for 20% results.

that is true for *any* development really. werent you the one writing countless pages of lamenting over how some little detail problem with a certain PLA replacement is unacceptable?

The SuperCPU for the 128 and 64 do not include another CPU for improved compatibility. If you're not happy then you disconnect it.

sure. if it can be disabled easily like a SCPU (flipping a switch).... but if i understood correctly, it would have to be an internal thing and cant be disconnected so easily.

If you think you can achieve better then by all means stop telling me what I should or shouldn't do

i'm not trying to tell you what you should do at all. i told you what i would do, big difference. if you dont want to hear things like that, you shouldnt start threads like that. that said, i find any kind of cpu acceleration for classic computers utterly pointless, especially if they are not 100% compatible. mostly because "new specialized software" will not really happen (just look how much of that exists for the SCPU, like 5 programs in 25 years or so). (and there wouldnt be a turbo in the chameleon either if it wouldnt be needed for the menu system)

stop being an armchair digital designer and make a SuperCPU VIC of your own. I certainly won't object.

armchair, eh? good you tell me. lol - but no thanks, i'll be occupied with those last 20% of development on a certain other project for a while

and no, i'd never say something like that about gideon or the 1541u - because its complete nonsense, and he spents a lot of effort on those last 20%. the difference to your project is that you cant update real hardware anymore once its done, so that kind of considerations must be done before the hardware is made.

i'm not trying to tell you what you should do at all. i told you what i would do, big difference

Then by all means do it then.

if you dont want to hear things like that, you shouldnt start threads like that. that said, i find any kind of cpu acceleration for classic computers utterly pointless, especially if they are not 100% compatible

So according to you:
1. Its pointless to accelerate
2. Nothing is ever really going to be 100% compatible when accelerated so nobody should consider your advice or point of view anyways...

So what exactly can you contribute to this thread other than nagging?

It was started so people could make a contribution, Mike did. have you?

I don't consider saying its pointless to be a highly positive contribution...

You suddenly have a lot of consideration for Gideon but you consider his 6502 VHDL code to be flawed and the same for his VIAs... go figure.

Do you consider the 65XX code of the Chameleon to be 100% compatible? If not, why are you whining at me?

I initially considered using a W65C02 but then I realized there were problems with that chip so this thread was mothballed, IMHO.

As for what you said about PLAs, PLAnkton right now is the only PLA substitute which is true 100% compatible. SuperPLA V3 will not run on a 326298, it will not run FastLoad and it will not run on a KU-14194; Because I paid attention to 5 specific details. Why you and Schönfeld didn't baffles me; he even balked at me saying I was thinking too much in analog terms yet that's what made it possible.

i have nothing to do with any PLA replacement, keep me out of that please. i just mentioned it because your fastload example is pretty much those 20% you find useless. and as you figured out, its not.

Then by all means do it then.

no, why would i? as said, i am not interested. VIC20 is pretty much "bandits" and "skramble" to me. besides that all that matters to me is demos - which dont need nor want acceleration by definition.

So according to you:
1. Its pointless to accelerate
2. Nothing is ever really going to be 100% compatible when accelerated so nobody should consider your advice or point of view anyways...

what i said was that there should be a way to make it so its 100% compatible when its _not_ accelerated. ie there should be an easy way to disable the whole thing - which in this case would mean including an original CPU. if i personally find it useless or not is irrelevant (a lesson i had to learn myself over a couple of years...)

You suddenly have a lot of consideration for Gideon but you consider his 6502 VHDL code to be flawed and the same for his VIAs... go figure. Do you consider the 65XX code of the Chameleon to be 100% compatible? If not, why are you whining at me?

suddenly? do you realize i was one of the first ppl who worked with gideon to improve what he had done? no i dont consider chameleon 100% - its even documented in the icomp wiki for that matter. (there is one annoying bug left) and i am not whining, i am just giving advice. and yes, i consider anything broken that fails any test program, be it VICE, or 1541u, or chameleon. "we" are working on fixing all of these. as said, the difference is that a hardware using an actual CPU is what it is from day one, with no chance to fix it.

groepaz wrote:... why would i? as said, i am not interested.

Well, at this point in time, neither am I. I guess that pretty much settles it.

My Vic already have a SuperCPU

I thought there was a convenient hotkey to enable / disable SuperCPU on the VIC. Try ALT+W and watch magic happen!
Or, the supreme developer can add a 'hidden feature' to make the game run faster for the supreme player.

@rhurst
About 10 years ago I did exactly the opposite. I placed a 4 bit counter that divided the CPU speed by 16 inside my "experiments" VIC-20 with a switch to toggle this feature on and off.

Was quite nice on a few games like Shamus. Much easier to finish a few levels.

I guess one could call it the "SlowerCPU".

Sidenote: The SuperPLA V3 is incompatible with more than only the Fastload cartridge. It also will not work with C64 board 326298 and PAL only board KU-14194.

PLAnkton works will work well with all of the above because only 5 specific details were taken into account.

vs the following

According to Groepaz Gideon's implementation of the 6502 is not 100% compatible but nobody could indicate a specific piece of software it has problems with. The same is true for the Rockwell R65C02 both on the VIC-20 or in the 1541 drive.

I have a lot of legacy software for the VIC-20 and I have been using a rockwell R65C02 in one of my VIC for more than a decade and I have yet to find any piece of software at all which has problems with this processor.

The main reason is probably that a lot fewer legacy software use undocumented features of the CPU on the VIC-20 than on the C64, if any at all.

@Mike
Can you tell me if you often use illegal opcodes when you program stuff for the VIC-20?

I know that Kweepa's Doom-port uses illegal opcodes for speed-up in at least one place and I use SAX in a few of my FLI-modes to save 2 cycles as well (setting $900e and a color-RAM-position with the same X-register would otherwise lead to buzzing noise when setting $900e. With X-register set to $f0 I can mask out the lower 4-volume-bits of $900e when setting with SAX).