how many instructions is the 6510 able to do in 1 clock?

[BigEd]

HansO wrote:

Windows bashing ... offtopic, irrelevant... I like to come here to read and talk about the 6502 and all technical aspects, based on our technical knowledge ...

I agree with this - although I have perhaps been guilty too.

We should try to stay on-topic, certainly on-topic to 6502 and related processors, to electronics and programming, ideally to the original thread (or start a new one) and certainly to avoid pot-shots at hot topics such as operating systems, current events or any politics or religious issues. This is not the place.

We should also try to stay respectful and polite. We should always assume a misunderstanding or a temporary loss of concentration and should not use insults or put-downs. It's much better to contribute a better suggestion then to criticise a previous one - or just not to post, if the post is purely negative.

Let's keep in mind a sense of community, and keep in mind the tens or hundreds of people who read this forum and have not yet posted. Lets not give them reasons to fear posting a beginner's question.

One thing: we don't answer homework. We refuse, politely.

Cheers
Ed

[Arlet]

HansO wrote:

You are wrong. The nature of these multitasking OS'es, whether Linux or Windows makes it impossible to have realtime behaviour (which I loosely define as having a predictable and repeatable response to events). Things like paging for example can take unpredictable time.

It's not impossible. You can turn off paging, for example, and you can avoid a couple of other things that are hard to predict, and end up with some reasonable upper limits. There are plenty of real-time embedded Linux systems on the market.

[ChuckT]

BigEd wrote:

ChuckT wrote:

BigEd wrote:

... whereas [ARM dev-board]STM32VL Discovery is 12.14 EUR, 24MHz, 64-pin module.

What kind of Jtag interface can be used with the STM32VL Discovery?

It looks like the STM32VL is one of those products made to be easy to use by being made somewhat captive: ST provide some kind of limited web-based or windows-based programming environment for it - USB based, not JTAG based. So one must liberate oneself.

I was even looking at the Leaf Maple (Cortex M3):
http://www.seeedstudio.com/depot/leaf-m ... 774bd3c119

One of the boards isn't accepting new users and another board is not accepting beginners.

Thank you for your help.

[BigEd]

ChuckT wrote:

I was even looking at the Leaf Maple (Cortex M3):
http://www.seeedstudio.com/depot/leaf-m ... 774bd3c119

Now this I like the look of! Thanks for the pointer!

Quote:

Maple is programmable over USB via our provided DFU bootloader, no extra hardware required! Users can also program the onboard program flash via external JTAG interface

It's a 72Mhz ARM on a board with USB JTAG SPI lots of I/O, a cross-platform IDE and also command line tools. For $47.

[ChuckT]

BigEd wrote:

One thing: we don't answer homework. We refuse, politely.

Cheers
Ed

I agree. You shouldn't do other people's homework.

I have the used book:
Programming and Interfacing the 6502: With Experiments (The Blacksburg continuing education series)

The problem is that it is late for people to start with the 6502. It has been a few years since the 6502's hayday. A lot of manufacturers don't produce that stuff anymore. The problem is that new users have a hard time finding current products that would work and because it has been years, I don't always know if I can find all of the parts. People don't know where to find level shifters and so forth as a beginner. It almost has to be in a kit form like Arduino for people to pick the 6502 up again.

[BigEd]

Book recommendations and recommendations for kits and websites are a good thing - as is helping to answer questions about projects or helping to debug problems. (You, or we, could add more books to your thread about wikibooks.)

By not helping with homework I meant that literally: assignments from school or college which are just pasted into the forum with no show of partial understanding. It's one thing to hit a stumbling block; its another thing to expect to get a ready-made answer from the internet - nobody learns anything that way.

Fortunately it doesn't happen often.

Cheers
Ed

[e2020]

BigEd wrote:

I think the one you link to, which was explicitly for games, did take all that stuff seriously, but you'll notice it was for a commercial effort and the source for the latest versions is not freely available.

which/what latest sources do you mean? and if it's not freely available: who owns it (today)?

BidEd wrote:

It's much easier to make a working CPU than to make an exact bug-compatible copy of an existing CPU.

you mean: it's much easier to make new cpus with new unknown mistakes than copy an old ones with known mistakes?

[BigEd]

e2020 wrote:

BigEd wrote:

I think the one you link to, which was explicitly for games, did take all that stuff seriously, but you'll notice it was for a commercial effort and the source for the latest versions is not freely available.

which/what latest sources do you mean? and if it's not freely available: who owns it (today)?

You linked to the FPGA-64 project where they point out that their last two revisions are released binary-only. You'd have to contact that project.

e2020 wrote:

BidEd wrote:

It's much easier to make a working CPU than to make an exact bug-compatible copy of an existing CPU.

you mean: it's much easier to make new cpus with new unknown mistakes than copy an old ones with known mistakes? :D

No, I don't really mean that! I mean that verifying the documented behaviour is a subset of the problem of verifying both the documented and the undocumented behaviour. Designing and verifying the logical behaviour is a subset of doing that for both the logical and the cycle-accurate behaviour. For example, Arlet's core is not cycle-accurate, which is intentional, and that simplifies things. His core is the smallest we've seen, and seems to me the simplest one to understand. But for purposes of running games which demand undocument behaviour and cycle-accurate behaviour, it isn't (directly) useful.

Cheers
Ed

[Arlet]

My core also stores the A, X, Y and S registers in a register file. It works for all the standard 6502 instructions, but if you wanted to implement the undocumented LAX (Load A and X) instruction, it wouldn't be possible with a register file, unless you'd be willing to spend an extra cycle.

For me, the optimization that the register file allows outweighs the disadvantage of not being able to implement LAX properly.

[bogax]

BigEd wrote:

Let's keep in mind a sense of community, and keep in mind the tens or hundreds of people who read this forum and have not yet posted. Lets not give them reasons to fear posting a beginner's question.

With that sentiment in mind ...

BigEd wrote:

One thing: we don't answer homework. We refuse, politely.

Rubbish!

We're just not going to hand them a copy and paste answer.

I'm pretty sure (with out looking for cites) that there have been instances
of some one coming here and saying 'I have this homework problem,
I just can't get my head around it, I need help' and then getting help*.

Thats a good thing. You're liable to scare them off.

And I sometimes wonder if some that get rebuked don't really deserve it.



*And help that was too close to being handed the answer for my tastes,
but for which they would have to have some understanding of what
they're doing to use the answer eg they got a description of an answer
that they would have to translate to code rather than the actual code.

[BigEd]

Yes, it's more nuanced than I put it. And perhaps we have refused when we shouldn't have, and I'm sure we have given canned recipes when the intent was that the student should figure something out for themself.

[bogax]

HansO wrote:

BigDumbDinosaur wrote:

Actually, it's a Windows problem. It's not a problem in Linux.

...
Btw, Windows bashing like your post and signature is for me offtopic, irrelevant and even insulting. I like to come here to read and talk about the 6502 and all technical aspects, based on our technical knowledge, not to be part of your holy war.

BigEd wrote:

HansO wrote:

Windows bashing ... offtopic, irrelevant... I like to come here to read and talk about the 6502 and all technical aspects, based on our technical knowledge ...

I agree with this - although I have perhaps been guilty too.

We should try to stay on-topic, certainly on-topic to 6502 and related processors, to electronics and programming, ideally to the original thread (or start a new one) and certainly to avoid pot-shots at hot topics such as operating systems, current events or any politics or religious issues. This is not the place.

We should also try to stay respectful and polite. We should always assume a misunderstanding or a temporary loss of concentration and should not use insults or put-downs. It's much better to contribute a better suggestion then to criticise a previous one - or just not to post, if the post is purely negative.

I generally agree and IMO BDD is a little to willing too interject that stuff.

(although, I'm not sure how much of that is a just bad first impression)


I really resent people trying to bring that snake in to this garden.

but, come on.

It seems to me to be entirely appropriate for a signature.

You want the elephant man to wear a mask?

That's a problem with you, not with the elephant man.

[BigEd]

bogax wrote:

It seems to me to be entirely appropriate for a signature

The thing about slogans is that they rally people to a cause, or they confront the opposing side. They are more likely to polarise than to enlighten. If a signature is funny, then it's probably only funny once or twice. But then, I've reached that age... I'm a grumpy old man, and my shirts don't fit. On the signature front, one should perhaps only comment if one finds it offensive, which Hans did, or nearly did. And I think BDD has changed it. A bit.

[GARTHWILSON]

e2020, I would expect that the main interest for a wildly sped-up 6510 (and purposely holding onto the illegal op codes and avoiding the CMOS benefits) would be to get much better performance on the old games. However, I'm sure these have software timing loops which would then make certain parts unusable without re-writing; and if you're going to re-write, why not at least go with the CMOS, or a 65816.

Also, the 6510 drop-in replacement in even dozens of MHz, let alone hundreds of MHz, or a GHz or more, will not work on the same C64 printed circuit boards. They are not designed for such high speeds. The entire C64 would have to be re-designed. Even the 40-pin DIP package the 6510 came in will max out at maybe a couple dozen MHz, and is totally useless at 100MHz. You will need at least a PLCC but probably a fine-pitch SMT part, maybe even BGA.

For speeding it way up, the closest thing to a real 6510 that you can reasonably get to would be to take an HDL source for the 65c02 and add the HDL for the 6510's I/O. Then you will have to design the rest of the Commodore 64's circuitry on a multilayer PC board that has ground planes, controlled impedances, etc.. It gets into a different world. You can't just speed up the clock by a factor of 100 or more and expect the PC board to be any good at all. It won't be. Bringing the processor's own buses out on one of the connectors will not work either.

If you want to get into this kind of thing, you have a lot of studying to do on high-speed digital design. Dr. Howard Johnson has a lot of resources available on it. Start at https://web.archive.org/web/20120302193 ... /index.htm and https://web.archive.org/web/20120302193 ... sAlpha.htm .

[bogax]

GARTHWILSON wrote:

Also, the 6510 drop-in replacement in even dozens of MHz, let alone hundreds of MHz, or a GHz or more, will not work on the same C64 printed circuit boards. They are not designed for such high speeds. The entire C64 would have to be re-designed. Even the 40-pin DIP package the 6510 came in will max out at maybe a couple dozen MHz, and is totally useless at 100MHz. You will need at least a PLCC but probably a fine-pitch SMT part, maybe even BGA.

So you give the cpu it's own memory and let it treat the C64 as a slow
IO device.