ttlworks wrote:
Christian, now to go through your block diagram from left to right:
ADL is implemented with 74161 counters, ADH is not. //Obviously you are going to need this for addressing modes like (IND),Y \ (IND,X) and JMP (ABS).
NMOS 6502 does not increment ADH for JMP ($00FF), 65C02 does, so to me it looks like you are aiming for the NMOS 6502 instruction set.
Correct - I'm implementing only the NMOS 6502 instructions.
ADH is not a Counter Register at the moment. For the (ind, X) and (ind), Y instructions I've written so far the high address goes through the ALU.
Quote:
That arrow from PCL to PCH is a thing I haven't seen yet, I'm interested to see some microcode related to this.
That is simply the carry out from the PCL counter to the PCH counter that increments when PCL goes above 255.
Quote:
About S: the 74191 up\down counter is less good than the
74LS169 (which would better fit to the 74161),
but 74169 is only available as LS from TI, and it's hard to tell for how long the 74169 will stay in production.
The 191 has a horrible pinout, but that aside it could be the chip to use for all the counter registers, since it can be set to count up permanently. I have lots of 161s but they'll be put to good use in the video adapter (more on that later). I'd not even seen the 169, since I've only been looking at the HC and AC flavour chips. Still, might be worth getting hold of a couple of 169s and doing some experiments to see how they might interface with the non-TTL chips.
Quote:
It's an interesting question, if JSR and BRK still would fit into 8 machine cycles when implementing S with 74161 up counters and decrementing S by the ALU.
Definitely worth a look.
Quote:
BTW: when it comes to push/pull, 6502 does pre_increment and post_decrement (like 6800), not pre_decrement and post_increment (like 6809 and 68k).
Means that S will always point to an empty location on the stack.
I wasn't aware about this from the start when building my first TTL CPU.
Checks code... Yes that's what I'm doing. The SP is initialised to $FF and on a push I write to that location then decrement. Therefore to pull I need to increment first before reading from the stack memory.
Quote:
In our 20MHz TTL CPU, we had to bypass the ALU with a buffer for getting cycle\timing compatible to the NMOS 6502.
Whether you are going to need that ALU bypass or not depends on your intentions and on your ALU design.
Speaking of it, I'm interested to hear how you are going to implement the ALU, especially the "shift right" operation at the ALU output.
The bypass buffer is just a convenient way of getting data from the DB to the WB in the same cycle, and seemed like a common sense thing to have. The ALU will be based on your multiplexer design. I've not yet laid out the shifter logic, but I believe it will use an 8-bit buffer (like the 74HC541) with its outputs offset by one bit, and the MSB will either be connected to the carry in, or to ground depending on the instruction. Of course I also need to consider what happens when NOT making use of a shift right operation.
Quote:
In the status register, B isn't really a flag, it's a status Bit from the instruction decoder\sequencer to be pushed on the stack during a BRK instruction or an interrupt sequence.
I wasn't aware about that when building my first TTL CPU, too.
This is something I still need to figure out.
Quote:
Would be better to have some reserved/unused Bits in the outputs of the microcode ROMs, during the building process of Drass's CPU we always seemed to had a few Bits too few there.
Yes, I'm currently considering adding a third ROM to add another 8, or 16 bits of breathing room. Currently for example the shift-right control bit is hacked from the ALU's input bit pattern. As you'll know very well the combination of 4 bits gives various input combinations. I'm not using 0001 so intercept that to set the shift-right bit and then reset the input to 0000. It's a clever hack, but a hack nonetheless, and I'd much rather have a microcode instruction to set this properly.
Quote:
It might be more economical to do an instruction fetch at the end of a microcode sequence,
also it's better (more safe) if the CPU hardware defaults to fetching the next instruction for empty locations ($FF) in the microcode ROM.
At the moment the fetch is done at the start of the sequence. I'll need to get my head around how this would work doing it at the end because how does it fetch the first instruction?
Quote:
If there are bugs in the CPU after building the hardware, they mostly seem to be related to the microcode (but the simulation would catch them),
or to clock generation and timing (so we better take a closer look at these details in your design later).
Because this is a standalone computer I'm thinking about just generating a clock and call every other pulse PHI1 and the other PHI2. I admit that this is a rather naive way of doing it so I'll be interested in investigating this further.
Quote:
Hmm... to me, it looks now like the VGA display generator isn't a part of the CPU core.
Would be nice if you could tell us how you would like to build that part of your computer.
It's been a while since I looked at the video generator, but I do have a working breadboard circuit generating the correct timing for a 320x200 pixel output. Because the MPU clock speed is divided from the pixel clock I think I can read from memory at times when I know the MPU isn't reading or writing. I'll also be overlaying ROM for character/colour generation that only the video generator can read from. It's actually quite simple to do when you've got your head round the front and back porches, etc.
Thanks for the comments. Christian