> making my own expanded 6502

Sounds interesting! Depending on how you might build it, that could be emulation, or hardware, or programmable logic...

i forgot to mention that i want to do the CPU in a logic simulator first, like Logisim... that is why i mentioned the "simulation and emulation" subforum.

also what exactly throws me off is that up until a week ago everytime i implemented a flags register in a CPU i just made it a single multi-bit register in the ALU that would automically update all of it's bit every time an arithmetic instruction is done...
so even when you did an AND instruction it would still set the carry flag and such, even when that specific instruction doesn't even effect that specific flag. (in this case the AND would for example always set the carry flag to 0 because it can never output a carry)

but on the 6502 different instructions effect only specific flags and ignore others completely. plus not only arithmetic instructions effect flags, loads for example also effect flags.

which is not that bad, it just means i have to completely rethink on how i build and wire up that register.
and as far as i saw it can only be effected by 3 things, the Control Unit of the CPU (instructions like: CLx and SEx), the ALU (standard arithmetics), and the Internal Data bus (LD instructions).
so my idea was to just have some kind of multiplexer to the input of the Status Register that selects between those 3. and then a bit-mask that basically only changes specific flags while leaving others unchanged.
overall that circuit should hopefully work for all cases.


that would be pretty nice, maybe also a list of how each instruction effects each flag?
it seems like useful information for anyone making an emulator, or like me building the circuit in a simulator.
sites like these show what flags are effected but not directly by what they are effected.
for example somtimes the Z flag is set by the contents of the A register, sometimes it's set by the output of the ALU...



thanks, i first want to build it in a logic simulator to get it working at all, and later try to put it on an FPGA.
so i think it would be better to start on the Emulation thread since it won't be on any programmable logic until it works.

Don't think of the status register as a byte register. Think of it as six individual bits. In hardware, you would implement them as individual JK flip-flops, not a parallel D latch. You would then put a tri-state buffer between their outputs and the bus, solely for the purpose of pushing it onto the stack.

yea that was my idea for the design. if i were to use a single register i would need to do weird loops around with single bits and other complex things, which would be weird.
i know there is one ignored bit in the Status Register (i assume it returns 1 when reading from it?) but what about the break flag? is it unused or somehow unimportant for the function of the CPU that i can just leave it out?

EDIT: after i wrote this i found your thread on the registers. the Break flag is strange.

The Break flag isn't actually implemented in the status register. It's only manipulated to zero during the stacking sequence of a hardware interrupt. The two unimplemented bits (including B) always read as set when stacked by PHP or BRK.

That makes sense for the original 6502, because those are the only ways the values of those bits can be made visible. The desired behaviour can be implemented without spending transistors on storage for them, so there is no storage.

In my work-in-progress extended 6502, there are other ways to access the contents of the status register, so I've chosen to implement is as a full register. The BRK instruction sets or clears B in the register early in its execution (depending on whether this is a real BRK or an interrupt), then pushes the contents of the register without modification. An interrupt handler could read the flag directly from the register if it wanted.

This approach does complicate implementation. Because I'm using an FPGA, and 6-input logic functions come free with every bit of storage, I have a multiplexer in front of each bit of the register to select which source to use. The current value is fed back as one of those sources, so I can have bits not change even though they are all updated.

(Yes, this project is continuing. Very very slowly)

i finally made the topic on the extended 6502. viewtopic.php?f=8&t=6116&p=75474#p75474
only took me like a week or something, on the plus side i'm already quite far with the project.
circuit is almost done and i'm nearly ready to start implementing the basic 6502 instructions.

Are you never allowing hardware interrupts while a BRK handler has control?

If a hardware interrupt was to happen, the B flag will always be clear after it returns. Meaning that an interrupted BRK handler cannot depend on the B flag being set.

Like this?

BRK happens. B is set to 1, B=1 is pushed to the stack. Code in the handler sees B=1.

Then an interrupt happens (assuming the handler has enabled interrupts). B is set to 0, B=0 is pushed to the stack. Code in the handler now sees B=0, because this time it's an interrupt.

The interrupt handler returns. B=0 gets popped from the stack. The BRK handler now sees B=0.

That's a good point. It only happens if you look at B after enabling interrupts in a handler, so my 'fix' will be to say "don't do that". One of my other extensions is to let BRK select which vector to use, so B isn't really needed. I'm only implementing it because the 6502 does. I doubt I'll ever use it.

Yes, the B flag is strange. It's one of the uglier corners of the 6502. Couldn't they have just given BRK its own vector? They did with reset, so it's not like they couldn't.

It is definitely odd that the 6502 overloaded the IRQ vector to cover BRK. It would have made more sense to include a fourth vector in the table.

The 65816 does have a larger vector table, and in Native mode BRK gets its own vector. Among other things, this frees up the B bit for one of the register size flags. COP and ABORT get their own vectors in both Emulation and Native modes. Reset only has a vector for Emulation mode, because the CPU is forced into Emulation mode during Reset. So there are holes in the table…

I just checked: the 6800 has the expected set of 4 vectors. I wonder if the 6502 people felt that merging two of them was in some way an optimisation. It could barely have been cheaper to do it as they did (and die size, as a measure of cost, was high on their list.)

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

BRK is used by debuggers for breakpoints.

It may also be used by some operating systems for system calls (as a software interrupt).

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

Yet another reason to use the 65C816 in native mode.

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