Addressing logic

[jbaum81]

Hello All! 

Recently got the bug to get back into electronics and decided to have a go at building an 8-bit computer. After a successful attempt I decided to switch things up and try to remain compatible with the specs for the CX16 so I'd have more options with the machine without having to develop all the software myself. 

As I venture further down the rabbit hole I'm beginning to doubt myself, mainly in the logic for zero page banking and IO surrounding the low memory area. To identify the zero page area I'm using a ton of OR gates on a1-a15 which isn't an issue for latching the banks as those IC's are pretty fast and if I bleed over into high clock for my address and chip select/enable/etc isn't as big of a deal as it leaves plenty of time for the latches. for the IO area I'm using Nands and an inverter, for Rom I only need a single Nand, for upper RAM requires a 3 input Nand and an inverter. All of this is fine until I get to low ram, which I'm essentially identifying when I'm not zp,IO, or upper ram/rom. I guess what I'm getting at here is with the current addressing layout identifying low ram addressing is becoming costly as there are so many layers of logic that need to be fast to Accommodate the best ram I could find @ 55ns. Currently my logic chips out number all other IC's and it just doesn't seem right. Am I doing something wrong, is there a better way?

[JimmyDansbo]

I am by no means an expert on electronics, but first thing that comes to mind is that you might be able to use some EEPROMs to "program" your logic circuit and maybe save some of the propagation delay?

Feel free to shoot me down if I am completely off base, I just remember Ben Eater saying that any discrete logic gates could be replaced by ROM (or something along those lines).

[Lorin Millsap]

I am by no means an expert on electronics, but first thing that comes to mind is that you might be able to use some EEPROMs to "program" your logic circuit and maybe save some of the propagation delay? Feel free to shoot me down if I am completely off base, I just remember Ben Eater saying that any discrete logic gates could be replaced by ROM (or something along those lines). 

In theory sometimes you can but if you are thinking it’s faster you are very mistaken. Our logic on the x16 has propagation delays under 10ns. An EEPROM is going to be in the 50-150ns range depending on the speed.  On your logic chip choices, understand at the speed and timing we are running at you need stuff much faster than the LS and HC series. Also trace routing, proper power delivery, ringing, etc are all factors that will hurt your project.   Sent from my iPhone using Tapatalk

[Sean]

8 hours ago, jbaum81 said:

Hello All! 



Recently got the bug to get back into electronics and decided to have a go at building an 8-bit computer. After a successful attempt I decided to switch things up and try to remain compatible with the specs for the CX16 so I'd have more options with the machine without having to develop all the software myself. 



As I venture further down the rabbit hole I'm beginning to doubt myself, mainly in the logic for zero page banking and IO surrounding the low memory area. To identify the zero page area I'm using a ton of OR gates on a1-a15 which isn't an issue for latching the banks as those IC's are pretty fast and if I bleed over into high clock for my address and chip select/enable/etc isn't as big of a deal as it leaves plenty of time for the latches. for the IO area I'm using Nands and an inverter, for Rom I only need a single Nand, for upper RAM requires a 3 input Nand and an inverter. All of this is fine until I get to low ram, which I'm essentially identifying when I'm not zp,IO, or upper ram/rom. I guess what I'm getting at here is with the current addressing layout identifying low ram addressing is becoming costly as there are so many layers of logic that need to be fast to Accommodate the best ram I could find @ 55ns. Currently my logic chips out number all other IC's and it just doesn't seem right. Am I doing something wrong, is there a better way?

If you take a look over at the 6502.org forums one of the first things you learn is that ROM is too slow at even moderate CPU speeds.  Accessing that ROM directly requires techniques like wait states or clock stretch to accommodate.  There are techniques that get around that, such as copying the ROM to RAM then banking it out, or skipping ROM and populating RAM externally via microcontroller at boot, or using a CPLD to do something similar. 

Rather than an EEPROM, address decode logic may be sped up by switching to a faster family of 74-series chips, or replacing them with programmable logic like a GAL, a CPLD, or even an FPGA.  A FPGA or even a large CPLD would be something of a waste if all it was used for address decode logic, but there's plenty of other things it might potentially help with, like an SPI controller, an MMU, etc.

I recommend taking a look at Garth Wilson's 6502 primer (http://wilsonminesco.com/6502primer/) if you're serious about building a computer based upon a member of the 65XX family of CPU's.

[jbaum81]

8 hours ago, Lorin Millsap said:

In theory sometimes you can but if you are thinking it’s faster you are very mistaken. Our logic on the x16 has propagation delays under 10ns. An EEPROM is going to be in the 50-150ns range depending on the speed.



 



On your logic chip choices, understand at the speed and timing we are running at you need stuff much faster than the LS and HC series. Also trace routing, proper power delivery, ringing, etc are all factors that will hurt your project.



 



 



Sent from my iPhone using Tapatalk

Are you saying your propagation time is 10ns each clock for all gates? I've attached my schematic (referencing the selected ic's) for my Zero Page ram banking logic arrays using sub 10ns gates but they are chained and I have 5 layers in low clock approaching nearly 50ns. The chaining of the OR gates for ZP is fine, but having to use the output of that logic for selection of low ram space is killing my timing. Do you have a better set of IC's? If I could find a fast OR gate that had 16 inputs that'd be a dream come true lol. 

As for the ringing and power, I've been pondering it and planned my traces to allow space for 2 caps at each IC, and will likely populate with one .1uf cap and scope it once it's running to try to determine what else it will need. I've also left enough space for larger traces and possibly some extra electrolytic's near IC groups... Haven't totally ironed that one out. 

On the subject of EEPROM's, I'm curious to know what 512KB (4Mb) rom chip you guys found that's through hole that will handle the speeds. The best I came up with was the W27C010-70 I had to get out of China, it's 70ns and only 128KB (1Mb), fortunately the logic gates for the ROM address space is easy and fast so I'll have plenty of time address and enable output during low clock to make sure output is stable by the end(ish) of high clock. 


JB6502 RAM Bank Logic2.pdf

[Sean]

10 minutes ago, jbaum81 said:

Are you saying your propagation time is 10ns each clock for all gates? I've attached my schematic (referencing the selected ic's) for my Zero Page ram banking logic arrays using sub 10ns gates but they are chained and I have 5 layers in low clock approaching nearly 50ns. The chaining of the OR gates for ZP is fine, but having to use the output of that logic for selection of low ram space is killing my timing. Do you have a better set of IC's? If I could find a fast OR gate that had 16 inputs that'd be a dream come true lol. 



 

Your approach looks to be running all sixteen address through a set of gates.  Most approaches to address decoding I've seen are using far fewer bits, often the upper 1-4 bits (A12-A15).  Given the memory map I've seen for the Commander X16 shows a 256-byte I/O space, and all other areas being in the 4K-32K size range, I'd guess they're decoding the upper 8 bits of address.  Fewer bits of decoding results in fewer and shorter sequences of gates. You might want to take a look at the examples at http://wilsonminesco.com/6502primer/addr_decoding.html.  I think it was the inspiration for the approach Ben Eater took in his videos; if not, it is at least very similar.

[jbaum81]

4 hours ago, Sean said:

Your approach looks to be running all sixteen address through a set of gates.  Most approaches to address decoding I've seen are using far fewer bits, often the upper 1-4 bits (A12-A15).  Given the memory map I've seen for the Commander X16 shows a 256-byte I/O space, and all other areas being in the 4K-32K size range, I'd guess they're decoding the upper 8 bits of address.  Fewer bits of decoding results in fewer and shorter sequences of gates. You might want to take a look at the examples at http://wilsonminesco.com/6502primer/addr_decoding.html.  I think it was the inspiration for the approach Ben Eater took in his videos; if not, it is at least very similar.

Bingo! That's my issue, Ben specifically states he designed the memory map to make it simple and cheap. 

The CX's 16 map is far from that. To isolate IO you literally have to evaluate all 8 of the upper bits. upper ram requires 2 bits, ROM 3, ZP banking involves all 16, and ram is essentially what's left over after it's not anything else. Unless I'm missing something or doing something wrong it seems to be a tad overly complicated. Also, what was the point of the ZP banking? I get moving it off the 6522's, but having it down at zero only seems to save a single clock cycle per bank switch by not having to load in the having to load the full 16bits. 

Sorry if I sound as if I'm knocking it, I really don't mean to, I'm just trying to understand. I do want to buy into the ecosystem, and will. I just want to follow along and build my own from scratch. 

[jbaum81]

 I wanted to visualize this so I wrote up something that makes this visually a little more comprehensive. I highlighted the unique patterns in red, for IO devices it's only 3 bits and perfect for a 3-to-8 decoder, for Rom it's only 2 bits requiring a single 2 input NAND, the High Ram is only 3 bits requiring a NOT and a single 3input Nand. 0000-0001 for the ZP banking has no uniquely identifiable patterns, and thus would require evaluation of all 16 bits, Similar with IO I can't find a unique pattern without evaluating all 8 upper bits. Low ram I can't even wrap my head around other than just process of elimination (IE not anything else). 

If banking took place in the IO area I think it would be easier from a logic perspective. I think 8 bits would still be needed to split IO and Ram though. 

[Sean]

27 minutes ago, jbaum81 said:

 I wanted to visualize this so I wrote up something that makes this visually a little more comprehensive. I highlighted the unique patterns in red, for IO devices it's only 3 bits and perfect for a 3-to-8 decoder, for Rom it's only 2 bits requiring a single 2 input NAND, the High Ram is only 3 bits requiring a NOT and a single 3input Nand. 0000-0001 for the ZP banking has no uniquely identifiable patterns, and thus would require evaluation of all 16 bits, Similar with IO I can't find a unique pattern without evaluating all 8 upper bits. Low ram I can't even wrap my head around other than just process of elimination (IE not anything else). 



If banking took place in the IO area I think it would be easier from a logic perspective. I think 8 bits would still be needed to split IO and Ram though. 

I think the banking does ultimately take place using I/O.  From the programmer's guide, VIA #1 is dedicated to banking control, with port A controlling RAM bank and port B controlling ROM bank.  The Commodore 64's 6510 processor reserved addresses $00 and $01 to control banking, but I  don't think the Commander X16  is mimicking that in it's address decoding.

[Sean]

1 hour ago, jbaum81 said:

Bingo! That's my issue, Ben specifically states he designed the memory map to make it simple and cheap. 



The CX's 16 map is far from that. To isolate IO you literally have to evaluate all 8 of the upper bits. upper ram requires 2 bits, ROM 3, ZP banking involves all 16, and ram is essentially what's left over after it's not anything else. Unless I'm missing something or doing something wrong it seems to be a tad overly complicated. Also, what was the point of the ZP banking? I get moving it off the 6522's, but having it down at zero only seems to save a single clock cycle per bank switch by not having to load in the having to load the full 16bits. 



Sorry if I sound as if I'm knocking it, I really don't mean to, I'm just trying to understand. I do want to buy into the ecosystem, and will. I just want to follow along and build my own from scratch. 

Ben Eater's address decoding scheme is simple, but IIRC it divides the 64K of address space up into 32K of RAM, 16K ROM, and 16K of I/O space.

Did I miss a move of the banking control from the VIA to zero page?  If so, the programmer's guide is out of date.  I suppose that should be no big surprise if they're still in the midst of making changes still.