6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 8:47 pm

All times are UTC




Post new topic Reply to topic  [ 186 posts ]  Go to page 1, 2, 3, 4, 5 ... 13  Next
Author Message
PostPosted: Thu Jun 18, 2009 2:27 pm 
Offline

Joined: Tue May 29, 2007 1:29 pm
Posts: 25
What are the simplest, most useful improvements you could make, taking the WDC65C02 as a base?

1) 24-bit program counter

This would allow 16MB of ROM code without bank switching. RAM, I/O, and ROM data would be located in the lower 64K.

jsr/jmp/rts/rti redefined for 24-bit operation.

New opcodes:
bsr (16-bit PC relative jsr)
bru (16-bit PC relative jmp)
lda (ptr24),y (load from 24-bit pointer)

2) 16-bit stack pointer and stack-relative mode

Stack-relative mode, when enabled, would redefine zero page addressing as stack-relative. Bit 5 of P indicates stack-relative mode.

New opcodes:
tys (transfer Y to high byte of stack pointer)
tsy (transfer high byte of stack pointer to Y)
ses (set stack relative mode)
cls (clear stack relative mode)
ssp # (subtract from SP)
rtn # (add to SP and return)

3) 1-byte lda/sta zero page

New opcodes:
lda0...lda7
sta0...sta7

4) jsr indirect

New opcodes:
jsr (abs)
jsr (abs, x)

5) Clear A/X/Y

New opcodes:
cla
clx
cly


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jun 18, 2009 5:03 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
I am up personally for a fully addressed branch test. Saves the jump table @#$% I need to do :)

BEQ $4028...for example....

_________________
"My biggest dream in life? Building black plywood Habitrails"


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 8:30 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
Some of what you're talking about is already available in the '816, like the stack-relative addressing modes.  I would like to go further however, with a fairly simple 32-bit version of the 6502.

This is why I was trying to get hold of Rob Finch, the bc_cpu Yahoo forum owner, about six months ago.  That forum was/is geared toward processor design, with a special interest in, or connection to, the 6502 family.  I have not been able to find him.  He is signed up on this forum too, and used to be active here.  I wanted to run some ideas by him for refinement before bringing them here for discussion.  I hope he's alright.  [Edit, many years later:  He has surfaced, and he posts again here now and then.]

Basically I would like to see a 32-bit 6502 that's 32-bit all the way, both in registers and buses, with the possible exception of a 64-bit register for 32*32 multiplies and 64/32 division to avoid losing precision in intermediate results as in multiplying a scaled integer by a rational-number fraction.  (This kind of thing allows high-performance non-floating-point arithmetic to replace most dramatically slower floating-point work.)

To keep the design simple, there would be no 8-bit or even 16-bit operations (just as the 6502 has no 4-bit or 2-bit operations), and it doesn't have to execute legacy 6502 or '816 code.  It would however have offset registers like the 816's bank registers, except that they too would be 32-bit, not 8 or 16, and hold any offset instead of presenting bank boundaries.  The entire 32-bit address range would still be available, just with different starting points for things like multitasking.  For that matter, even indexing with the 32-bit X or Y or using stack-relative addressing can access the entire 4-gigaword address space, as can branch instructions with 32-bit operands.  Gone are the limits of zero page, bank boundaries, etc..  All 32 bits of any address, relative or absolute, are loaded in a single fetch, like a 6502 does a zero-page operation, because the data bus is 32-bit also.

I have a lot of bullet points written down, but I'll save them until we see if this stirs any interest in discussing it further.  At the moment I myself don't have the time or resources to be the one to see this thing through to an actual product in an FPGA or similar.  I did go through a book and attend a seminar on VHDL ten years ago and felt like I had enough understanding to start programming CPLDs, but the work project I planned to use it on got cancelled and I never touched it again.

There was a 65GZ032 project that Ruud was in on.  They were making good progress but got interrupted (for example, I think the top guy had a baby) and they never got it going again.  I watched kind of from a distance; but in my view, they were trying to make it too complex, otherwise it would have been finished up in the amount of time they worked on it.  As I remember, they wanted 6502 backward compatibility but also 32-bit operations and deep pipelining, sophisticated branch prediction, cache, and all in all, I saw little resemblance to the easy-to-learn 6502.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 10:53 am 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 336
I've always admired the 6502's clean design, and after seeing the 65816 with its ugly mode flags, thought there has to be a better way of extending it.

When I had the time, I didn't have the skills/equipment/money to actually make one. Now that there are cheap FPGA development boards and free software for them, I don't have the time.

Still, it'd be nice to see something usable that keeps the classic 6502 feel. I don't imagine it'd be easy to achieve, particularly since everyone has a different idea of what makes the 6502 what it is.

I didn't agree with all of Gideon's design decisions, but the GZ looked fairly decent to me. I'm in two minds about the pipelining and so on. It's necessary to get decent performance, but it makes it much harder to judge how quickly code will run. Cycle-counting on the 6502 was so easy.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 12:10 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
Can you really do away with 8-bit operations? Very useful for string handling!

The '816 almost gives too many choices: I haven't figured out what policy to take on changing the M and X modes (8/16 bits for data and for indexes). I certainly don't want every subroutine to have to PHP/PLP and set the modes itself.

The other drawback of the '816 is that it is almost, but not quite, able to run each bank as an independent 6502. It falls down for stack and direct page. The usual idiom for looking into the stack by indexing into page 1 doesn't do the trick in this case.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 2:44 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
At the very least, we can come up with a "white paper" in here via discussion to create a spec for such a processor.

Some points, let me throw in:

1. the simplicity Garth mentioned is a design goal.

2. Keeping it simpler possibly, a SINGLE mode bit for a 6502 emulation which its own thing, but that would be a kludge for the sake of it.

3. Would it be simpler to implement using the array logic gates or a microcode routine generator for the opcode work in VHDL logic?

4. (my own personal one): plenty of the addressing modes were based on the memory and logic constraints present at the time. A much simpler set of addressing schemes would be used. When you think about it, how any addressing modes do you use in your programming?


Garth, you want to post your bullet points in here for discussion?



figure it this way, once we can get a solid design spec locked down, we can

1. submit to WDC to implement.
2. One of our members with VHDL experience go about making the bugger...

_________________
"My biggest dream in life? Building black plywood Habitrails"


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 9:40 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
Quote:
I've always admired the 6502's clean design, and after seeing the 65816 with its ugly mode flags, thought there has to be a better way of extending it.

After writing my '816 Forth kernel, I have to say it's much easier to program the '816 than the '02 when you're constantly dealing with the calculations of 16-bit values and addresses; but for that, I almost always have the accumulator in 16-bit mode and the index registers in 8-bit. There are very few occurrences of REP & SEP in the whole thing, and when I do use them, I put them in macros named ACCUM8, ACCUM16, INDEX8, and INDEX16, so it's obvious what they're doing and you don't have to remember what REP and SEP mean and what bit positions are what. REP and SEP truly were cryptic, especially since you have to remember the bit positions.

Quote:
Can you really do away with 8-bit operations? Very useful for string handling!

With memory so cheap these days (what an understatement!), you just take a 32-bit word for each string character. You could use the fast barrel shifter instruction and do a lof of shifting to get four string characters in one word, but I don't see any need. I guess you could use the spare bits to indicate bold, italic, underline, more special and foreign characters, etc. if you wanted to.

For interfacing with 8-bit I/O ICs, you just use the lower 8 bits of the address bus. The '816 usually requires making sure you're in 8-bit mode for whatever register (A, X, or Y) you use to read or write the 6522 because a 16-bit access reads or write two addresses, which is not usually desired in this case. The 32-bit 6502 will read just one address, and you just don't pay attention to the top 24 data bits. I haven't settled even tentatively on whether to just follow it with AND #0000:00FF, use passive pull-downs on the upper 24 bits, or what.

Quote:
The other drawback of the '816 is that it is almost, but not quite, able to run each bank as an independent 6502. It falls down for stack and direct page. The usual idiom for looking into the stack by indexing into page 1 doesn't do the trick in this case.

I'm not sure what you mean here, but you could have different stacks and direct pages and go between them by changing out the 16-bit S and D registers at the same time that you change the bank numbers for changing tasks. I have to admit that I haven't needed to do this (and therefore haven't done it) with the heavy use of pseudo-multitasking I do all the time with interrupts, but I don't see any problem with it. I'm much more likely to do round-robin coöperative multitasking than preëmptive though. [Edit, 5/15/14: I posted an article on simple methods of doing multitasking without a multitasking OS, at http://wilsonminesco.com/multitask/index.html.]

Quote:
2. Keeping it simpler possibly, a SINGLE mode bit for a 6502 emulation which its own thing, but that would be a kludge for the sake of it.

There's always the issue of whether or not to try to preserve the ability to run the legacy code of the earlier-generation processor. To keep from worsening our already-poor chances of getting a new processor like this done, I would vote for not trying to run legacy code on the new processor. (I don't want to sound pessimistic here-- I've seen a lot of "dreaming" threads, and, although everyone learned something from them, most of these threads never turned into actual working hardware, because the ideas quickly got too grandiose for the people doing the dreaming to pull them off.)

Quote:
3. Would it be simpler to implement using the array logic gates or a microcode routine generator for the opcode work in VHDL logic?

I think microcode is always slower, and probably has no simplicity benefit in programmable logic. I may be wrong. I know that in several ways here, I'm exposing the fact that I'm definitely not a processor designer.

Quote:
4. (my own personal one): plenty of the addressing modes were based on the memory and logic constraints present at the time. A much simpler set of addressing schemes would be used. When you think about it, how any addressing modes do you use in your programming?

Some are used far more than others, but I do use them all. If everything were 32-bit though, it's like everything is in the 4-gigaword direct page. There's no distiction between zero page, absolute, and long. It could probably be made to run faster if the operand were merged with the op code when you only need say 20 or 24 bits and we used deeper pipelining to separate them, but then the design gets more complex again.

Quote:
Garth, you want to post your bullet points in here for discussion?

I thought you'd never ask. I'll put it below. Actually, I see I've already mentioned a bunch of them, but it'll sumarize them a little more clearly.

Quote:
figure it this way, once we can get a solid design spec locked down, we can

1. submit to WDC to implement.
2. One of our members with VHDL experience go about making the bugger...

I don't expect #1 to go anywhere, since we've been waiting for many years for the Terbium. WDC seems to be resting comforably just licensing the intellectual property of a very solid 65c02 processor design. OTOH, if someone here does help us get this thing going in programmable logic and it looks really strong, WDC might get interested, or, 6502.org can make it available to anyone who wants it. There's not just hardware but also the matter of especially an assembler to take care of. Eventually some will write simulators and compilers. I'll start by writing a 32-bit Forth kernel, since that's my biggest ambition for this, with my workbench applications in mind.

There was a 6532 RIOT (RAM, I/O, and Timer) IC which I did use on a project years ago, so I need a better name; but until someone comes up with one, you know what I mean.
6532 goals
  • 32-bit non-multiplexed address bus, data bus, A, X, Y, PC, S, DP, DBR, PBR (P could be 32-bit but just have a lot of unimplemented bits, or let the programmer use them as desired.) DP, DBR, and PBR are 65816 features I would like to retain for improved capability for relocatable code and multitasking. If the 32-bit address space is thought of as a circle with $FFFF:FFFF being the address right before $0000:0000, then these registers just point to what part of the circle we rotate around to the top for one task or another. (2^32 makes for a 4 gigaword address space, each word being 32 bits. So in essence it will have a 16GB address space, although there will be no operations that are particularly 8-bit.)
  • Some addressing modes will be eliminated, because basically everything is in zero page (or, considering DP offset, direct page).
  • will not run 6502 code directly. No 8-bit operations, vectors at the $FFFF:FFFF end of the memory map, and op codes don't need to match the 6502's. Making it backward-compatible would dramatically increase the complexity. This will not be a 65832, just a 6532.
  • barrel shifter, so shifting right or left by large numbers of bits still happens in one clock
  • fast hardware multiplier (maybe three phase-2 cycles) , maybe fast divider too, possibly with a 64-bit register for 32*32 multiplies and 64/32 divides
  • outputs for vector pull, op code read, data read or write, dead bus cycles (if we can't eliminate them all-- good for invisible DMA)
  • input clock can be a multiple of the bus speed, in order to reduce dead bus cycles and get better control of timing of the things that happen between phase-2 edges (if we even use a "phase-2"), cut MVN and MVP down to 2 clocks per byte moved instead of the 7 the 65816 uses, if we can keep it interruptible.
  • DRAM management, perhaps by refreshing rows during dead bus cycles (Nice to have, but low on the list)

So how is it still a 65-family processor?
  • same registers as the 65816, just bigger
  • nearly the same instructions
  • average instruction will take about three phase-2 clocks (6502 takes about four for the average, but needs two clocks instead of one to fetch absolute addresses)
  • similar memory-map usage, just on a bigger scale
  • phase-2 bus clocking, and one access per phase-2 clock
  • excellent interrupt performance, working the same way as the 6502, although possibly with more IRQ inputs and vectors to reduce polling requirements. Each register will take only one cycle for a stack push or pull, including the PC, and a vector pull also only takes one cycle.

What I don't envision it having:
  • deep pipelining. Only the shallow pipeline of the 6502 where one instruction often gets finished while the next one is being fetched.
  • cache
  • branch prediction
  • multiplexed buses (address bus and data bus are both 32-bit, and there's no latching required for the high address bits)

Envisioned uses:
  • much faster running of high-level languages, with higher-precision default word size (I'm particularly thinking of a 32-bit Forth, with 64-bit intermediate results)
  • much faster running of math anywhere you need more than 8 bits of input and output
  • faster handling of any data exceeding 8 bits, for example, 12-bit A/D and D/A converters
  • much larger data space for tables, files, arrays, etc., without the 65816's bank boundaries. Suitable for audio recordings, possibly video
  • multitasking
  • some will want the better video, but that's not a goal for me personally

Expected benefits over using existing 32-bit processors:
  • easier to learn, easier to code in assembly, easier to count cycles and predict performance, easier to build hardware
  • better interrupt performance

Additional instructions I would like:
  • STF (store $FFFF:FFFF, to set flag variables)
  • Forth's NEXT (very similar to RTS). I believe this is used in some other high-level languages too.
I don't want to go overboard with extra instructions since the more-complex require instruction-decoding logic just means slowing things down.

Samuel recommends clocking on only rising edges, to simplify things in programmable logic. Actually, he has a lot of good recommendations. We'll have to see how much that pulls us away from it being a 6502 with '816 capabilities but just bigger. There are plenty of other processors out there to chose from if it weren't that we want to keep the '02 flavor in both hardware and programming.

When I was talking about the 32-bit bank registers, direct-page resgister (although DP still covers the entire address space), and stack pointer, by the time you consider indexing, it was starting to sound more like a processor with 16 general-purpose registers. Perhaps the transition to something like that becomes more transparent now, at least if the assembler mnemonics are still worked out to be essentially 6502 mnemonics.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Last edited by GARTHWILSON on Fri Jul 17, 2009 4:23 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 10:18 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
Agreed on logic working out better in an array compared to microcode. The 6502 uses the logic array nicely which also allows it the super slow speeds to DC if needed. (not sure why microcode wants speed, go figure0.

Nother comman would be a a biggie but simpler than the double instruction thing

We know the command as is
LDA #$data
STA $address

Combine the bugger.

LDA address, data

and

STA address, data

.... :D

_________________
"My biggest dream in life? Building black plywood Habitrails"


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 11:02 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
As I understand it, the PLA is what enables the 6502 to accomplish so much in each phase-2 cycle, doing, in the example of ADC#, as much five distinct steps in only two clocks. OTOH, the processors with the microcode require huge numbers of cycles to carry out a single instruction.

The combining of op code and operand would save memory, but memory is super cheap now; and although the combining would save a bus access, there's a penalty in more-complex instruction decoding, more addressing modes needed (unless we limit the operand to 24 bits), slowing the clock down to give time for the logic to ripple through bigger instruction-decoding logic trees, plus minor things like losing self-modifying code like I use in Forth's NEXT (inner loop in indirect-threaded code) for double indirection.

On a related note, the PIC microcontrollers use the Harvard architecture which keeps instruction and data space separate, and I find it has some very frustrating limitations. In spite of Microchip's claims to performance, the PIC16 needs about twice as many instructions and twice as many clock cycles to do the same job as a 6502-- if the PIC16 can do it at all. That's not because of its Harvard architecture, but in spite of it which was supposed to improve performance.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Jun 20, 2009 7:50 am 
Offline

Joined: Tue May 29, 2007 1:29 pm
Posts: 25
Regarding "memory is super cheap now"...when it was a struggle to fit a CPU on a chip, it might have made sense to waste memory in exchange for a simpler CPU. But when the entire system, including memory, is on a single chip, it makes no sense to waste memory, since memory is the biggest cost.

Look at how ARM evolved. Originally it used 32-bit instructions only, which simplifies instruction fetch and decode. Current versions use 16-bit/32-bit instructions, which complicates the CPU, but reduces system cost. They've also improved support for 8-bit and 16-bit data handling, and allow unaligned memory access.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Jun 20, 2009 2:58 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
An advantage of using a logic array is indeed in FPGA or CPLD work as a gate series. It is much easier to implement rather than a logic version of microcode.

For a name, 65Org32? or 65Virtual32? (brat here this morning)

And agreed on the Harvard. One thing I found interesting was a friend's library, she has it optimized to keep from using branching test commands since they slow down pipelining. As she puts it, it improves the chances of sucessful branch predicting. Sounds more to me like a hopeless tangle when trying to write straight ahead code with logic tests along the way. (my own dislike of the series comes from trying to access memory simply and easily without using many instructions. I don't think my pinball program would be feasible on a Harvard since I am using something like 2,000 variables :). Sorry, just stupid morning rant on this part.

Barrel shifter: 32 bit as you mentioned, instead of having a loop of shift commands, have an argument of how many times to shift?
LSR data,# of times

6502 would be emulatable by programming, so you get it going there, not a lost feature at all.

RAM refresh: Z80, how does it implement in hardware to work out nicely?

and by keeping the instruction set simple and based on the 6502 syntax and basic scheme, it makes it easier for us to do general design and implementation.



And one I learned from work, is there anything that would help with PCI bus compatibility to allow it to become a product for that market?


While we know and love our 6502 registers, what would be the advantage in a register bank in RAM similar to the hardvard series by setting a block of RAM as a register set? Think about like setting up a stack, but havig it possible to do register manipulation on it. For example, a ROL (register#, repetition) with the register# calculated from the previously set stack location plus the offset?

_________________
"My biggest dream in life? Building black plywood Habitrails"


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Jun 21, 2009 7:37 pm 
Offline

Joined: Tue May 29, 2007 1:29 pm
Posts: 25
Some other random instruction ideas:

sti #imm, zp
sti #imm, abs
cmpeq #imm, rel8
cmpne #imm, rel8
add #imm (without carry)
sub #imm (without borrow)
lda (ind), #
sta (ind), #
push zp
push abs
push #

Also the HuC6280 has swap instructions, useful or not?

sax
say
sxy

----------------------

What are the most common (static) 6502 instructions? Based on some code I had lying around, seems to be roughly:

lda zp
sta zp
jsr
lda #
cmp #
bne
beq
rts
jmp
...

Any disagreement with this list?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Jun 21, 2009 8:48 pm 
Offline

Joined: Mon Oct 16, 2006 8:28 am
Posts: 106
If I were designing my own 16 or 32 bit 6502 variant, I'd take most of the ideas in the 65816 (and what others have suggested in this thread) but I would get rid of the M and X bits. They're a colossal pain to use when dealing with mixed 8 and 16 bit data. The way the 6809 solves the same problem (index registers always 16 bit, separate lda/ldb/sta/stb/ldd/std) is much cleaner IMHO.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Jun 21, 2009 10:16 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
Quote:
Some other random instruction ideas:
. . .
push zp
. . .
push #

The 65816 already has these two.
PEI (DP) is the same as a 16-bit LDA DP, PHA, but without affecting A or P (DP being direct page, like zero page except that you can move it around instead of being limited to the range of 0-$00FF).
PEA is like a 16-bit LDA #xxxx, PHA, again without affecting A or P.
PER pushes a 16-bit address relative to the program counter, again without affecting A or P.

Quote:
Also the HuC6280 has swap instructions, useful or not?

sax
say
sxy

I never really had any reason to actually swap them. The 65816 does have TYX and TXY and a few other transfers not available on the '02.

Quote:
What are the most common (static) 6502 instructions? Based on some code I had lying around, seems to be roughly:

lda zp
sta zp
jsr
lda #
cmp #
bne
beq
rts
jmp

The CMP# gets used a lot by lesser-experienced programmers in the form of CMP#0 immediately after instructions that have it integrated anyway so it's redundant and unnecessary, as in ADC, CMP#0, or AND, CMP#0, as well as in DEY, CPY#0, etc..

I'm sure Bill Mensch had plenty of other instruction ideas when he designed the 65c02, but weighed their benefit against the cost not just in silicon real estate, but also in the fact that the clock would have to be slowed down to give enough time for the bigger instruction-decoding logic tree to do its job, and possibly also that instructions would take more cycles. IOW, adding instructions wouldn't necessarily improve performance, at least back then when processors only ran at 2 or 4MHz.

If we want the extra instructions just to improve readbility and programmer productivity, we can make them with macros. For example, SXY could be defined this way for the 65816, with three instructions, and three bytes (the same number as a JSR):
Code:
SXY: MACRO
     PHX
     TYX
     PLY
     ENDM

or if it's ok to affect A, the following also takes three bytes but only 6 clocks total, even for 16-bit:
Code:
SXY: MACRO
     TXA
     TYX
     TAY
     ENDM

If it's for a 65c02, you'll have to use A (or a variable):
Code:
SXY: MACRO
     TXA
     PHY
     PLX
     TAY
     ENDM

If it's for an NMOS 6502, it gets even longer:
Code:
SXY: MACRO
     TXA
     PHA
     TYA
     TAX
     PLA
     TAY
     ENDM

(This was pretty quick, so just holler if I missed the better way or even made a mistake.) Anyway, when you put SXY in your code as if it were a valid instruction, the assembler replaces it with the code you wrote for the macro, not having any JSR/RTS overhead, and you still have total control. I make very heavy use of macros especially when I do PIC programming, since the PIC assembly language is so cryptic and un-intuitive. Some of my PIC macros have 6502 assembly mnemonic names.

The 65c02 and '816 have gotten fast enough now however that the trade-off may be worth it, accepting a slower clock that the memory can live with, while reducing the number of memory accesses required to get the job done. Still, I think most new instructions should be focused on improving the suitability for multitasking and relocatable code and things that are totally impractical to do on the '02 right now.

More later.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Jun 22, 2009 2:35 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
just for giggles sometime as a help aside would be the schematic on the TTL version of the 6502 as well as the VDHL core. Links to those two projects can prove to be useful references.

_________________
"My biggest dream in life? Building black plywood Habitrails"


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 186 posts ]  Go to page 1, 2, 3, 4, 5 ... 13  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: