SasQ

What? How? I don't get it... ? OK people, look what I found: http://www.6502.org/tutorials/register_preservation.html If only I had found it earlier, I wouldn't have to ask at all... -_- That's too cool! Interestingly, they seem to have a link to an article about multitasking at 6502.org too: http://wilsonminesco.com/multitask/

Whoa! I didn't expect such quick and numerous replies on a forum about vintage computers! You guys are much better than the rulebook nazis from Stack Overflow True, maybe it isn't. But it's definitely a Good Thing To Have™. Therefore my usual approach is to try having it from the start, and only loosen this requirement where I need, or where keeping it would be too troublesome/inefficient. It's one of the requirements if you want your procedure to be a "black box", not affecting the user with some weird side effects. Well, if the values in registers have to be retained, they surely must be stored somewhere, obviously :q Yup, I know, that's what I was asking about in the last line of my original post. I know that there is such a technique, since I use it sometimes on x86, I just don't have much prior experience in how exactly do the same thing on 6502 where the register manipulation seems to be somewhat limited. I suppose that I have to push A and X first, right? Because otherwise, TXS would damage at least X, and I can't push X directly, it has to go through A first. So my guess is that I should start by first pushing the registers (first A, then X and Y through it), and only then I can copy S to X to manipulate it and peek through the stack with it to get the original values of the registers back? Hmm... When I already have a copy of the original S in X for restoring it later, can I then use PLA for reloading the registers instead of LDA/LDX/LDY? (PLA would do that with one-byte instruction instead of three-byte). I mean, is it safe to do that? Because, since it moves the original S down the stack, I suspect there might be a risk of some interrupt overwriting the values above the stack pointer, am I right? If that's the case, I suppose it would be better to leave S where it is, and only peek the values below it through address arithmetics? BINGO! That seems to be the thing I was looking for ? Directly addressing the data on the stack with respect to the original stack pointer (because I suppose it's better to leave it where it is, if interrupts might interfere). Thank you for mentioning that. Definitely something worth keeping in mind. Not a problem, as long as the previous value of X the user has passed is already sleeping nice & tight on the stack where I can reach it anytime with @drac030's technique Why do you save A both in memory and on the stack? Hahah so they realized their fault eventually and fixed it? :J This way it saves not only the registers, but also a lot of headache (and instruction bytes). Well, one of the reasons might be that when a subroutine can mess up the values in X and Y, it cannot be used inside of a loop that already uses X and Y for the loop counters You then have to remember to save these registers yourself before every subroutine call and restore them later, and moreover, you have to repeat the saving/restoring code in every place of a call If you save/restore them inside the subroutine instead, the save/restore code is localized inside that subroutine and doesn't have to be repeated all over the program. With the "caller saves" approach, the caller cannot assume that the subroutine won't mess the registers, so the caller has to always save them before the call and restore afterwards if he wants to keep their values, even if the subroutine actually doesn't mess up those registers. In that case, all that work is wasted. On the other hand, if it's the job of the subroutine to save the registers it actually uses, it can avoid that overhead if it doesn't mess with the registers (and the subroutine knows best which registers it needs to mess with, so it should be its responsibility to save their values in that case). Not to mention that there is a conceptual benefit from treating a subroutine as a "black box", so that the caller didn't have to know what does it do with the resisters inside, or produce any weird side effects. Wow, threading on a machine with no hardware support for it? That's definitely something interesting that I'd like to try one day

I stumbled upon some difficulty regarding a 6502 assembly subroutine that takes a couple of parameters in CPU registers (A,X,Y), but it shouldn't mess them up during its operation as seen from the caller's perspective. On other architectures, normally in this situation I could simply save the values of those registers on the call stack at entry, then restore their original values from the stack in reverse order just before returning from the subroutine. But on 6502, the only register that can be pushed upon the stack, is the accumulator (A) :q So every other register needs to go through A first if I need to save it on the stack too. For example, if needed to save the X value, I would have to do something like this: TXA PHA But then it destroys whatever was there in A :q The obvious solution is to save A first: PHA TXA PHA But then I still no longer have the original value in A, which was the parameter that the caller passed in it ? And I cannot pull it back from the stack either, besause it is buried under the value of X I cannot pull X first, because it would reverse what I just did, and... you get the idea :q Another idea that comes to my mind, is that perhaps I could store those values somewhere in RAM, e.g. on page 0. Something like this: STX SAVEDX STY SAVEDY PHA ... PLA LDX SAVEDX LDY SAVEDY This solves the problem of saving registers without losing their values passed by the caller, but introduces another problematic side effect: the subroutine is no longer reentrant If it gets called again during its own operation (which may happen indirectly – inb4 you say I could simply avoid calling it from itself), then the saved value of the register will get overwritten during the second call ;\ (Another problem might be that such a procedure couldn't be put in ROM anymore, unless SAVEDX and SAVEDY are locations in RAM instead of somewhere next to the subroutine's code.) That's why such things are better to use the stack: because then the same code can be used to save/restore register values at different (subsequent) locations in memory. Are there any solutions of this problem on 6502? Or is it impossible to have callee-saved registers if they are also used for passing parameters into the subroutine? (If A wouldn't be used for parameter passing, just X and Y, then I guess this wouldn't be that much of a problem, because then I could destroy its value when moving them through A onto the stack, as I did before. So A seems to be the only problematic register here that cannot do the double duty.) Hmm... Or maybe there is some way to read those values pushed upon the stack back into their original registers without pulling them from the stack?

Hello. I found an old Atari 2600 console clone in my basement. Seems to be broken, some parts are missing, but the chips are all OK (CPU and ROM, I guess). Therefore I'm wondering about reusing these parts somehow on a breadboard or something. But in order to do this, I need some information on these chips and their pinouts, maybe some datasheets or schematics. The chips are labeled as follows: 6591 9208A 922511 DIP-48 (two rows of 24 pins each, 48 in total) Seems to be the CPU. WB2600-4MP DIP-32 (two rows of 16 pins each, 32 in total) Seems to be the ROM. As far as I know, there was no cartridge slot, so the games must be stored on that ROM. There's an empty place on the PCB for another DIP-28 chip, the silkscreen label says "IC3 512K MASK ROM", but there is no chip there and it seems that it has never been. HD14011BP 2C26 Just four 2-input NAND gates. MC14024BCP FFES9206 Motorola chip, 7-stage ripple counter, I guess for clock division or something, since it is near the quartz resonator. The resonator is: STANDARD 17.734475 (which I guess is its frequency in MHz) I see no separate TV circuit/chip, so I guess the TV signal is generated on the main CPU somehow. Could it be that the CPU has a TV signal generator integrated in it? I can post some photos of the PCB if needed. But I hope the labels on the chips will be enough for the experts to identify them. Can anyone help me with identifying the chips and supply some descriptions of their pinouts? Perhaps some more detailed datasheets? --- I also found an old Atari 65 XE motherboard. Unfortunately it's broken in half so the chips in the middle of the board are broken as well ;/ But other chips on the edges of the board are OK, so I'll try to reuse them as well. But I'll describe that in a separate thread later.