tokumaru wrote:
Oziphantom wrote:
The Dendy sounds like a fancy piece of engineering then.
Yes, I'm still impressed that pirates did a better job of adapting the Famicom architecture to PAL than Nintendo themselves.
Quote:
Personally I think getting SEI and CLI backwards was their biggest misstep on the 6502.
What do you mean backwards? Do you think the mnemonics would better match their function if they were switched? The CPU only understands opcodes, not mnemonics, so if this bothers you so much you can always create your own assembler (or modify someone else's) with these two switched. I mean, look at the source code for the NES version of
Magic Floor... It's written in 80XX syntax! You can write source code anyway you want, as long as the resulting binary is comprised of valid 6502 opcodes. Unintuitive mnemonics are NOT hardware design flaws by any stretch of the imagination.
Sure I could easily make my own standard but the standard set down by Chuck and Bill is the standard we all know and use. SEI Set Enable Interrupt - actually disables Interrupts. Not a 6502 design flaw, nothing wrong with the die, but still Chuck and Bill's misstep
tokumaru wrote:
Quote:
PHY/X PLX/Y would have really helped though.
Would them? Maybe it's my style of coding, but I hardly ever use the stack to back up values. Even in the NMI handler, where I need to backup all 3 registers, I use 3 ZP locations I have reserved exclusively for this purpose, instead of using the stack.
If you have a single NMI source and 100% guarantee you won't renter, then sure use the ZP, its faster. But if you have 4 IRQ sources and an NMI source or might re-enter, use the stack or you are could get lots of pain, the adding 1 opcode to this unrelated function causes the whole screen to become a mess kind of pain. Or make 5x3 store areas if you have the RAM to spare.If you want to make lite threads or "peel off" threading on a 6502 the stack helps. Also when you just need to preserve a register somewhere to recall it 3 lines down or so, having the option to use the Stack over the ZP, which might then get trashed by some other function or maybe in an interrupt if its a shared "general ZP store" would be nice sometimes. Rather than a STX Somewhere, LDX somewhere else, it adds a dependency to your code or lib that could be mitigated with a Stack operation. You could even use a PHY PLX to get around not having a TYX for example for when you have to do the I need what is in X to now be in Y but I really want to preserve A docey-do. I would also be handy for parameter passing, that you use in the function but don't need it now. For example something like
Code:
myFunc
STY ZPY
STX ZPX
LDY #4
STA (ptr),y
JSR functionThatModifiesA ; I hope this doesn't trash ZPY or ZPX one day
LDX ZPX
ADC Table,x
LDX ZPY
AND Table,y
LDY #4
STA (ptr),y
RTS
Could become
Code:
myFunc
PHY
PHX
LDY #4
STA (ptr),y
JSR functionThatModifiesA ; can do whatever it wants with things
PLX
ADC Table,x
PLY
AND Table,y
LDY #4
STA (ptr),y
RTS
tokumaru wrote:
Quote:
TXY,TYX also would have been useful.
ByteTable to the rescue:
Code:
ByteTable:
.db $00, $01, $02, $03, $04, (...) $fe, $ff
ldy ByteTable, x ;TXY
ldx ByteTable, y ;TYX
Yeah byte tables are nice things to have around.
tokumaru wrote:
Quote:
Not having LDA(zp) has been thorn in my side many a time.
That I actually miss sometimes, but I often end up finding a way to make Y useful instead of having to load it with 0.
Quote:
LDA (zp,x) is a total waste
I don't know, LDA (ZP, X) can be useful for accessing collections of streams, such as the different channels of a song.
Quote:
and would have been better served as LDA (zp,x),y which would be pure gold.
But then you'd be using all your registers for reading, meaning you could have trouble indexing the destination if not reusing Y or an auto-increment register such as $2007. Not to mention that this would be a pretty slow instruction.
If X is your entity number, and Y is the field you want in the entity then ZP can hold an entity pointer table of which you can easily index into. Gives you the ability to easily make 2 dimensional arrays. It would add 1 clock to the cycle which is a lot faster than doing it the long way at the moment.
tokumaru wrote:
Quote:
JSR (XXXX) would save a lot of pain too.
Working with the attribute tables in an 8-way scroller is a pain. Changing the palette mid-frame is a pain. Doing raster effects without IRQs is a pain. Animating patterns in such a short vblank time is a pain. JSR'ing to a JMP (XXXX) is definitely not a pain.
Doing a push with the address -1 on the stack then doing a jump is cumbersome, and I come from a machine where I can actually just change the JSR params

Still it would be nice if I didn't have to. Also those other things are NES problems not a 6502 problem.
tokumaru wrote:
Quote:
Remember if you really need speed, S is a register too

Specially on the Atari 2600, which doesn't have any interrupts, so S can safely be used to load data faster in display kernels.