Page 2 of 4

Posted: Fri Apr 15, 2011 6:50 pm
by Arlet
ChuckT wrote:
ARM is nice but it costs several hundreds of dollars based on which version you want.
Not really. Individual chips sell for a few dollars, and small eval boards sell for less than $20:

http://www.embeddedartists.com/products ... 43_qsb.php

Development software is free.

Posted: Fri Apr 15, 2011 7:01 pm
by Arlet
GARTHWILSON wrote:
But I hate the fact that sometimes when I type, the PC won't update the screen for a couple of seconds-- a problem we never had on the Commodore 64! My 5MHz 6502 workbench computer can do real-time work that the PC cannot do.
That's a software problem :)

Posted: Fri Apr 15, 2011 7:32 pm
by GARTHWILSON
Quote:
That's a software problem :)
Sure, but the way the multitasking is carried out on these PCs is a problem we're stuck with. Usually it's not a major problem for typical PC applications, but it's not acceptable for real-time work. A cache miss can also cause thousands of cycles of delay, which is not acceptable in real-time work.

Posted: Sat Apr 16, 2011 5:25 am
by Arlet
GARTHWILSON wrote:
Quote:
That's a software problem :)
Sure, but the way the multitasking is carried out on these PCs is a problem we're stuck with. Usually it's not a major problem for typical PC applications, but it's not acceptable for real-time work. A cache miss can also cause thousands of cycles of delay, which is not acceptable in real-time work.
Depends on the time scale. "Thousands of cycles" is only 1 microsecond real time. If you real time constraints are bigger, it's not a problem.

But yes, that's why smart phones are moving more towards dual core. One core for the real time stuff, which has low latency, low throughput, and another core for the applications with high latency, high throughput.

Posted: Sat Apr 16, 2011 1:38 pm
by e2020
thanks for the
BigDumbDinosaur wrote:
Mr. e2020
, but e2020 is more like a group than a single individual ... so just "e2020" will be fine ...

synchron clock rates (cpu, buses & memory)
Quote:
A contributing factor to the 65xx family's efficiency is the fact that the address and data buses are synchronous to the MPU clock, not a submultiple of it
- yes, right and I need it to stay that way:
so can an 6502 get accelerated up to synchrony to the fastest memory (is it ddr5 meanwhile?) and fastes bus-speed reachable today?

well, maybe it's better to imagine if we all think about a whole c64-system (6510 + vicII + sid) that'll get speed up to the max to keep efficency...

mem
- and that system could only adress 64k (or are there any tricks about getting more mem adressed - what about up to 64 GIGs of ram?)

compiler:
right now I only know cc65

Posted: Sat Apr 16, 2011 1:51 pm
by BigEd
It's worth having a look at the 65816, for at least one way to extend the memory addressing to 24bit addresses. There are many such ways: see here, here, and here.

We've also discussed here (several times...) ways to make extended 6502 architectures including 32bit ones. Edit: See also here and here.

It's worth a read of Ulrich Drepper's big work on modern memory systems. The thing is, these modern RAM chips are not random access at all: they support cache refills, which are bursts of data from sequential addresses.

For the 65816 there's a promising looking compiler.

Posted: Sat Apr 16, 2011 3:38 pm
by e2020
thank you, but which ones are 100% binary-compatible with the c64 / 6510?
(including all illegal opcodes & timings - because the fpga-people seem to have trouble with some timings...)

Posted: Sat Apr 16, 2011 4:01 pm
by BigEd
e2020 wrote:
thank you, but which ones are 100% binary-compatible with the c64 / 6510?
(including all illegal opcodes & timings - because the fpga-people seem to have trouble with some timings...)
Are you perhaps responding to this (in another thread):
BigEd wrote:
ElEctric_EyE ran a survey of 6502 cores for FPGAs.
?
You'd have to check the documentation for each. At least some of the people are not so interested in bug-compatibility, so the undocumented opcodes or even the timings are not important to them. 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.

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

Edit: when I say bug-compatible, I mean something different, because we're talking about behaviour which isn't even specified.

Posted: Sat Apr 16, 2011 5:17 pm
by BigDumbDinosaur
Arlet wrote:
GARTHWILSON wrote:
But I hate the fact that sometimes when I type, the PC won't update the screen for a couple of seconds-- a problem we never had on the Commodore 64! My 5MHz 6502 workbench computer can do real-time work that the PC cannot do.
That's a software problem :)
Actually, it's a Windows problem. It's not a problem in Linux.

Posted: Sat Apr 16, 2011 5:19 pm
by BigDumbDinosaur
e2020 wrote:
well, maybe it's better to imagine if we all think about a whole c64-system (6510 + vicII + sid) that'll get speed up to the max to keep efficency...

mem
- and that system could only adress 64k (or are there any tricks about getting more mem adressed - what about up to 64 GIGs of ram?)
Nothing like reinventing the wheel and attaching it to an ox cart. :D

Posted: Sat Apr 16, 2011 6:59 pm
by GARTHWILSON
BigDumbDinosaur wrote:
Arlet wrote:
GARTHWILSON wrote:
But I hate the fact that sometimes when I type, the PC won't update the screen for a couple of seconds-- a problem we never had on the Commodore 64! My 5MHz 6502 workbench computer can do real-time work that the PC cannot do.
That's a software problem :)
Actually, it's a Windows problem. It's not a problem in Linux.
I do use Ubuntu Linux. I have not used Windows in four years, and I will never go back, not even to save my job. With Linux, 90% of my computer problems went away, but I still get these annoying delays. I have 1.5GB RAM which I got when one of our sons was using the computer a lot and occasionally filled up what I had, but I never get close to filling it now, and the hard-disc light is not flashing when i get the delays so I know it's not disc-swapping. The problem has always been there, and the computer is just as fast as it was brand new. (It came with Linspire Linux on it and has had Ubuntu for the last couple of years, and has never slowed down, unlike a common Windows complaint.)

Posted: Sat Apr 16, 2011 7:03 pm
by BigEd
I would say either a software problem or paging. Or both - it's often both for me on this machine (too little memory, two browsers both a bit old struggling with modern javascript demands)

Posted: Sun Apr 17, 2011 4:29 am
by ChuckT
BigEd wrote:
Arlet wrote:
... available in a wide range of models...
No kidding: the beagleboard is $125, 720MHZ, POWERVR graphics, etc, etc, whereas STM32VL Discovery is 12.14 EUR, 24MHz, 64-pin module.

(Edit: also now the beagleboard-xM at 1GHz)
What kind of Jtag interface can be used with the STM32VL Discovery?

Will it work with the Bus Pirate?
http://www.seeedstudio.com/depot/bus-pi ... 18d432fbb1

Mouser, Digikey, Sparkfun, are companies I'm familiar with because they are in the U.S.

Posted: Sun Apr 17, 2011 8:39 am
by HansO
BigDumbDinosaur wrote:
Actually, it's a Windows problem. It's not a problem in Linux.
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. So response to events will have jitter and a chance of missed respons within realtime windows. Given fast enough hardware it may look good, but it is not by design.
You might be surprised to see how much the design of the schedulers in NT and Linux are in philosophy alike. The Windows scheduler design goes back to Digital Equipments (DEC) OS'es like VAX/VMS and RSX-11, which were regarded as state of the art in their days and close enough to realtime and heavily influenced all modern OS'es including Linux. I know, I have been involved in a deep level of all three of those OS'es.
By changing the scheduler behaviour also Windows NT Embedded (or whatever it is called nowadays) and Linux (many realtime variants exist) can have acceptable realtime behaviour.
But none can beat an OS designed ground up for realtime behaviour.

This may help you understand what I mean:
http://www.ibm.com/developerworks/linux ... ime-linux/
http://www.microsoft.com/windowsembedde ... edded.aspx

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.

Posted: Sun Apr 17, 2011 8:45 am
by BigEd
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.

Having said which, it seems people have succeeded in But to get those working I think you're going to have to do some reading and hit some appropriate forums. I know it can be done because a friend of mine came visiting last week with one of these in his suitcase, and he'd done something of this sort.