I'm working on a microcoded 6502 for the Xilinx Spartan3 familly and just
wanted to get peoples thoughts on a few issues. I'm aiming for less than
300 LUTs, 150 slices. So far it's at < 100 slices and I still have to do the
status register and interrupt logic

It is NOT intended to be a cycle accurate 6502 drop in replacement, well
at least not at the moment. For the time being I will use a x2 clock and
tri-state the FPGA pins, it makes the hardware interfacing a lot easier.

The design is not cycle accurate, branches take two cycles and an extra
cycle is never used for page crossing for example. In addition, JSR and
RTS store the (return address - 1) on the stack whereas BRK and RTI
use the true return address.

It would be nice to use the true return address for JSR and RTS.
Any thoughts on this ?

I've been working hard to reduce the "microcode" instruction length
and it's around 15 to 16 bits at present. The microcode is also written
in "micro-assembler" so it is easy to read but slow and prone to errors
when assembling by hand

Best regards
Chris

Not storing return address -1 on the stack following JSR would break many programs that depend on that behavior.

BRK on the real 65xx MPUs results in PC+2 being pushed to the stack. Again, there is a lot of dependency on that behavior. If it were me, I wouldn't tinker with it.

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

Hmmm... Very good comment.

The only programs that I think of that would use this behavior would be
something along the lines of stack tracing. It literally decades since I've
done any 6502 programming. Best not to mess with it and store PC+1.

My 65C816 M/L monitor uses the address+1 behavior of RTS to dispatch execution according to the entered command. The execution address-1 is pushed and a JuMP is made into the parameter evaluation subroutine. When the eval sub exits via RTS the command execution address-1 is pulled, incremented and off we go.

BRk is officially a two byte instruction, $00 followed by a signature byte. Hence, when the MPU pushes the resumption address it adds two to it to get past the signature byte. If you want to maintain full compatibility you really shouldn't change that behavior.

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

I agree that it's best to keep with the present stack behaviour.

Good to hear about your project - I hope you intend to open source it! Even if not, it would be interesting to see some snippets of the micro-assembly.

Cheers
Ed

Modern 6502's do have a BE (bus-enable) input pin, as well as a ML\ (memory-lock-not) output pin and a VP\ (vector-pull-not) output pin. Without being a microprocessor designer myself, I have thought that if the input clock were a multiple of the output clock, you should be able to remove most of the dead bus cycles.

and
I have often used subroutines with literal data immediately following the subroutine call, and then made a macro for it, like:

which would assemble

so the subroutine uses the return address on the stack to know where to find the string to display, and its first byte is the length byte which the subroutine uses also to know where to jump back to to pick up the next instruction after the string. Anyway, there are a lot of things that would be affected by changing the return address.

As for the BRK, there are multitasking/multithreading systems that depend on BRK. Better not mess with it.


+1.

Hi everyone again. Thanks for the replies, best not mess with the
return address.

Well my last two rather lengthy posts disappeared somewhere. Grrr

Yes the project is open source and I will write it up and put it in the
documents section when done.

The first iteration is going to the "Fast" version without extra cycles for
branching and page crossing simply because the hardware required to
do this was a mess so I took it all out. Also, the way it worked was to
stall the microcode program counter and effectively add in the extra
cycle as and when required. Works really well as a "KIL" instruction.

I will come back to the "cycle accurate" version at a later date.

The forum doesn't leave you logged in long enough to complete a long post if you take breaks or whatever. One of several ways around it is to click "Preview" frequently. If you click "Submit" and it already logged you out, you can probably click your back button to get the post back, open another tab and log in, then click "Submit" again in the earlier tab. At the time I'm writing, it looks like it might have been an hour since you tried. If you're still up and can click "back" enough times, you might still get your lengthy posts back.

Thanks Garth, I figured that might be the problem.

I will write up in a text editor next time and cut and paste. I have to make
some notes anyway, the paper scriblings are getting out of hand

While we're on the subject of FPGAs, does anyone have any ideas as
to how you could tokenise a line of test using the the textio package ?

I'd like to write a simple one pass assembler in VHDL to generate
the microcode.

Hi Chris,
Bumping this thread, because it would be interesting to know how you are getting on, and also because MichaelA mentioned a microsequenced FPGA core - maybe you two could compare notes.

The microcoded/microsequenced approach might be an easier one to amend or extend - for example for addressing modes which better support Forth, or relocatable code.

Cheers
Ed