New answers tagged 6502
7
Here are a few further thoughts on the setting of flags and the SO
(set overflow) pin mentioned in the other answers, in response to
Joe's comment,
The fact that there's a direct pin that can set the overflow flag is
definitely a bit of a "i guess someone somewhere had a use case that
needed it". The use of it in the 1540/1541(and I'd guess 1570/1571?)...
22
There is simply no need for setting Overflow. The same is as well true for Negative/Sign and Zero. No operation will be influenced by any of them, it's only used to signal an overflow during ADC and SBC (well, and BIT for testing bit#6).
In fact, the question is rather, why there is a CLV present, as there is no reason, within the boundaries of the ...
44
Setting and clearing carry, the decimal or interrupt flags is useful:
the carry flag because the 6502 offers only add and subtract with carry;
the decimal flag because it changes the mode of the processor; and
the interrupt flag because it masks or unmasks the maskable interrupt.
Conversely, explicitly setting and clearing the other flags mostly isn't ...
2
The Byte Sieve benchmark, in Applesoft Basic took 2806 seconds, according to Byte Magazine, September 1981 issue, page 192. Byte Sieve in 6502 Assembly language took 13.9 seconds, according to Byte Magazine, January 1983 issue, page 292.
That's a factor of 200X between a tokenizing Basic interpreter and hand-coded assembly for the 6502.
200X is in about ...
1
I've had experience with the TRS-80, and there were three programs I wanted to do that I simply could not get good performance in BASIC. All three programs were dealing with the screen.
The first program was to fill the screen with a single arbitrary character (if you used space, it's the same as clear screen, else I could fill it with whatever character I ...
5
[Modern Python compared to C; C64 BASIC compared to assembly.]
is there any comparison I could make? Is it even possible to quantify it this way?
Yes, you have the right idea. That is exactly the comparison you can make.
BASIC was easier to write (don't underestimate the value of that), but "slower" to "dreadfully slower", depending on what you ...
6
if I write a piece of code in Basic, would it be much slower than Assembly?
Well, it's interpreted. So even though it's a simple language, it'll never reach native speed - not even coming close.
If so, is there any comparison I could make?
For most parts like with Python vs. Assembler on a PC (*1). Except of course, BASIC is a way less comfortable ...
43
Yes, BASIC is much slower than assembly for many operations. For an
easy example, try out this program on a Commodore 64 or emulator:
for i = 1024 to 1984 : poke i,peek(i) or 128 : next
You will see each character on the screen reverse, row by row, over
the course of ten seconds. By contrast, the exact same routine in
machine language inverts the entire ...
16
Most implementations of BASIC for 8-bit home computers were interpreters, and in that sense they're similar to the standard versions of Python. You could typically expect simple programs to run 100 times slower in BASIC than in assembly of ordinary quality.
However, it would normally take much less time to write that program in BASIC than in assembly. For ...
2
The specific details of what a 6502 Apple II was doing when it was sitting at the BASIC command prompt or Monitor command prompt is this:
Periodically check for a keyboard key press to be detected at address $C000
If no input, it runs a delay routine to display a blinking white box or a square checkerboard (later enhanced IIe ROM) as a cursor at the current ...
0
I wrote some fairly deep systems code for the BBC Micro, a popular 6502 based machine. The OS for that machine struck me at the time as a lot more systematic than most of its 8 bit peers, in the sense of being well organised and a well thought out overarching design, but that was just my impression, it could be wrong.
Ensure not only that a process can't ...
Top 50 recent answers are included
