Starting with my first SBC Project, Plans and Confusions

[BigEd]

> making my own expanded 6502

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

[Proxy]

drogon wrote:

Proxy wrote:

my main problem with that is that the status register is just confusing me really hard and i'm not 100% sure on what to put in it.
but I'll put that in it's own thread, not here.
I assume the "Emulation and Simulation" sub-forum would be the fitting place for that?

Maybe Programming? viewforum.php?f=2

The status register is just a bit of the chip that is almost fully automatic. Every time you do a load or arithmetic or logic operation the status register is automatically updated although the choice of mnemonics can be confusing to newcomers - check for zero is the same as check for equal (BEQ) or not zero (BNE). Some assemblers duplicate mnemonics or if using a macro assembler you can define your own, so you could define BZE to be BEQ and BNZ to be BNE and so on. (the ca65 'generic' macro package does this for example)

The automatic update of the status register saves you doing explicit checks in a lot of cases. It's also why you may see loops counting down to zero than up to a number too - when you decrement a register and it hits zero, then the zero flag is automatically set, so you don't need an explicit compare, so you save both clock cycles and code space.

-Gordon

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.

Chromatix wrote:

Tell you what, when I get a spare moment I'll post a thread in the Programming section, to discuss the status register in detail.

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...

BigEd wrote:

> making my own expanded 6502

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

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.

[Chromatix]

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.

[Proxy]

Chromatix wrote:

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 flip-flops, not a parallel latch.

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.

[Chromatix]

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.

[John West]

Chromatix wrote:

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)

[Proxy]

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.

[BillG]

John West wrote:

Chromatix wrote:

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.

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.

[John West]

BillG wrote:

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.

[Chromatix]

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…

[BigEd]

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.)

[GARTHWILSON]

As I put in the 6502 interrupts primer,

Quote:

BRK was mainly used for patching code in PROMs back when re-assembling and programming was a long, slow process, and each iteration could be quite expensive if the PROM was not erasable. The BRK instruction seems to mostly have outlived its usefulness. There is some use for it in multitasking operating systems, but the 6502 is not generally very well suited for that anyway. The 65816 as other capabilities that make it better suited to multitasking, relocatable code, etc..

I have never used BRK since that first 6502 class in 1982, so I never test that bit either.

[BillG]

GARTHWILSON wrote:

Quote:

BRK was mainly used for patching code in PROMs back when re-assembling and programming was a long, slow process, and each iteration could be quite expensive if the PROM was not erasable. The BRK instruction seems to mostly have outlived its usefulness. There is some use for it in multitasking operating systems, but the 6502 is not generally very well suited for that anyway. The 65816 as other capabilities that make it better suited to multitasking, relocatable code, etc..

BRK is used by debuggers for breakpoints.

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

[GARTHWILSON]

BillG wrote:

BRK is used by debuggers for breakpoints.

I've done that with just JSR BREAK, with BREAK being my own routine that allows examining and altering registers and memory locations, etc.. It takes one more byte (3 versus 2), but the status is preserved anyway, and then you don't have to saddle the ISR with overhead to check for BRK every time it runs.

Quote:

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

True, again for saving a little memory each time, particularly if you want the OS to be able to change entry-point addresses without having to update the software that uses them, so you could do BRK <$xx> rather than JSR <addr> where <addr> remains the same but the target contains a JMP <another_addr> which can change without concerning the end programmer. Still, the BRK saddles the ISR with extra overhead.

[BigDumbDinosaur]

GARTHWILSON wrote:

BillG wrote:

BRK is used by debuggers for breakpoints.

I've done that with just JSR BREAK, with BREAK being my own routine that allows examining and altering registers and memory locations, etc.. It takes one more byte (3 versus 2), but the status is preserved anyway, and then you don't have to saddle the ISR with overhead to check for BRK every time it runs.

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