and before I do, a short disclaimer. Some people may want to avert their eyes.

Years ago, I switched from 6502 to z80.

BUT WAIT! I'm thinking of switching back!! With that out of the way, I'd like to tell you a bit more about some of the projects I've worked on over the years and what I'm working on now..

My main interests lay in designing hardware that rekindles my recollection of the 1980s arcade experiences. I therefore tend to create hardware that resembles some of the arcade machines of that era: Tile based, fixed size sprites, 8-bit CPU's and PSG generated audio ('chiptune').

For reasons I still don't understand, my first project was to build my own arcade board out of CMOS parts (74hcxx), wire-wrapped with love. This particular monstrosity has 8 sprites, 256 tiles and 64 palettes of 4 colors. The little board on the side is my rom emulator which allows me to use the dos command 'copy' to re-load content. Nothing fancy but does what it says on the tin.

Anyway, I've long since moved on to FPGA's and while my latest project is z80 based, I'm considering moving to the 65c02. While I've done surface mount stuff before, I don't really enjoy soldering 0.5mm pins so this one's through-hole and based around an Altera EPF10K10, which is a 5v FPGA in an 84PLCC package, giving me a whopping 576 LE's and 768 bytes of RAM. Enough to be able to generate a multiple tile-based layers, a bunch of sprites and some sound.

So erm, yeah.. I'll post some pictures later of that if anyone's interested. Anyway, I hope to get a website up and running at some point but in the meantime.. Hi!

Yvo

Thanks. This post would go well in the "Introduce yourself" sticky topic under "General discussions." It's nice to have you join! As I was going through the archives again last month, I was impressed with how much the expertise on the forum has increased over the last ten years. It is becoming more and more valuable to the 6502 community, due to its many very knowledgeable members and their contributions and the good network of links. The non-forum part of the website has a ton of good materials also, and then there's the 6502.org wiki, and the many related personal websites of the members too.

_________________
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?

Yeah, sorry about that.. I actually joined in 2002 but haven't been here for a looooong time. Good to be back. And yes, knowledge has increased tremendously!

Yvo

Cool!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yeah man, welcome! That's some cool stuff!

BTW, feel free to post in the Programmable Logic section as well. It's never too crowded in there.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

So here's a question...

I had a brief look at the 65c816s, which looks a lot beefier. Kinda like a 6809.. For moving my design from a (cough) z80, would you guys touch the '816 or stay with the tried and tested 65c02s at a higher clock rate.

Yvo

The '816 has a lot of advantages, although they take effect at different thresholds of what you want to do with it.

Even if you totally ignore the high address byte that opens the way to a 16MB address space, if you're constantly doing 16-bit operations, it is far more efficient. I showed a little code comparison at viewtopic.php?f=9&t=1505&p=9705#p9705. My '816 Forth runs two to three times as fast as my '02 Forth at a given clock speed. If you want relocatable code or multitasking, the '816 is far better suited. Some related things it can do are ones that the '02 is basically incapable of, not just clumsy by comparison.

If you do latch the bank byte, you have 256 times as much memory-map space. Programs written by single individuals (as opposed to professional teams) seldom get anywhere near long enough to need that; but you might want it for data. Another use is for math performance, with the 16-bit tables I published at http://wilsonminesco.com/16bitMathTables/index.html for trig, log, square-root, inverse, square, and other functions. In some cases, looking up the value is nearly a thousand times as fast as actually having to calculate it; and every answer is there, with no interpolation needed, accurate to all 16 bits. It does take up a couple of megabytes for the tables though, and although you can implement them on a 6502, being able to do it directly using the 816's 24-bit addressing modes is much more efficient, which is of course where the best performance comes from.

_________________
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?

In my upcoming article on 65C816 interrupts, I list some instances where the 65C816's 16 bit registers confer significant performance advantages. Also, once you get familiar with the PEx instructions and stack pointer relative addressing, you'll wonder how you ever managed without those features. I use all of that stuff extensively in my POC unit's firmware and managed to both shrink the code and speed it up in many places.

I'd make the leap to the '816, if I were you. That's what I did with my POC unit. Building a unit around it is only a little more more involved than a 65C02-powered unit, but the payoff can be big.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks guys! I'm planning to go 16-bit mode only, which makes it a heck of a lot easier. I vaguely remember colleagues bitching about having to switch back and forth between the two modes on the SNES

Yvo

Unless you're running something like an OS that has to run both '816 programs and '02 programs at the same time, you can mostly just put it in native '816 mode at boot-up and leave it there and never touch that emulation-mode bit again.

As for register widths, my '816 Forth leaves the accumulator in 16-bit mode and the index registers in 8-bit mode almost full time. There are very few places in the code where it gets changed; and after a few instructions, it gets put right back. Those REP and SEP instructions are terribly cryptic and those two by themselves probably scare a lot of people away. For 8- versus 16-bit A and index registers, it only makes sense to make macros that are far more clear than REP and SEP. I called mine ACCUM_8, ACCUM_16, INDEX_8, and INDEX_16, which are far more clear and assemble the appropriate REP or SEP instruction. I think BDD called his LONG_A, etc.. I use the Cross-32 (C32) assembler, and instead of having to tell it LONGI ON etc., it just gives 16-bit unless you preface the operand with "<", like LDX #<$20 which lays down A2 20, not A2 20 00.

_________________
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?

REP and SEP may be cryptic (at least until you get comfortable with them), but they open the door to some interesting programming, as they may be used to clear (REP) or set (SEP) any desired combination of status register bits. There's no such instruction as SEV (set overflow bit), but you can write a macro that does the equivalent:

Code:

sev      .macro                ;set overflow bit in SR
         sep #%01000000
         .endm

Lots of flexibility with REP and SEP.

LONGA = SEP #%00100000 = 16 bit accumulator
LONGX = SEP #%00010000 = 16 bit .X and .Y
LONGR = SEP #%00110000 = 16 bit everything
SHORTA = REP #%00100000 = 8 bit accumulator
SHORTX = REP #%00010000 = 8 bit .X and .Y
SHORTR = REP #%00110000 = 8 bit everything

Something to keep in mind is that 16 bit loads and stores occur "serially," meaning that memory access is a byte at a time without regard to the settings of the m and x bits in the status register. The '816 uses an extra clock cycle to read/write the most significant byte, something that has to be kept in mind in the 8 vs. 16 bit debate. Also, indexing in which .X and .Y are set to 16 bits incurs a one clock cycle penalty. Combine that with a 16 bit load/store operation and LDA SOMEWHERE,X becomes two cycles more expensive than it would if all registers are set to eight bits.

You have to evaluate execution speed against other program factors in deciding whether to process 8 or 16 bits at a time. In most cases, the extra clock cycles involved with 16 bit loads and stores and 16 bit indexing are more than offset by the smaller and generally faster code that results.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!