Jump to content

Addressing logic


jbaum81
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

 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. 

cx16 memory map.PNG

Edited by jbaum81
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

You are basing that on obsolete information. The X16 uses addresses $00 and $01 for banking control freeing up the VIA for better uses.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

25 minutes ago, Sean said:

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.

 

Yes, his addressing scheme is rather simple and requires very little logic to accomplish. Also, Yes, ram/rom banking has been moved off the VIA and down to 0000 for Ram and 0001 for Rom banks. 

I attached a rough draft of my HiRAM, ROM, and IO logic, the plan would be to enable LowRam when ZP, IO, HiRam, Rom are all high. If I add in some AND and NOR gates I might be able to trim some timing out by not having to invert so much. It's a puzzle, I feel like there has to be a better way. 

 

cx16 logic.PNG

Link to comment
Share on other sites

30 minutes ago, Lorin Millsap said:


You are basing that on obsolete information. The X16 uses addresses $00 and $01 for banking control freeing up the VIA for better uses.


Sent from my iPhone using Tapatalk

Thanks for clearing that up.  

Link to comment
Share on other sites

14 minutes ago, Lorin Millsap said:


You are basing that on obsolete information. The X16 uses addresses $00 and $01 for banking control freeing up the VIA for better uses.


Sent from my iPhone using Tapatalk

The C64 uses a PLA, is the CX16 using programable logic?

With the removal of other devices out of the IO area why not just stick a couple D Flip-flops there? Hell, you wouldn't even have to sacrifice any of the expansion banks, you could stick them right next to the VIA's since they don't use all of their address space. Seems to me it would be a hell of a lot easier to divide the space allotted to the VIA's considering the majority of the logic is already there for that, rather than dividing up low ram address space. What is being gained by this? It certainly can't be just for the one measly clock cycle gained for ZP when bank switching. 

 

@ 8mhz the clock cycle is 125 ns, 30ns for address setup time and it appears data is latched in on the falling edge of the cycle leaving 95ns for read. As far as I can tell Ram and Rom are going to be the slowest devices on the Bus. Wouldn't it be more advantageous to try to reduce propagation time and see if you could get a couple more mhz out of the clock? @10mhz you have 70ns after address setup in the clock cycle, not enough to write out on the rising edge of the clock, but the ram I found is 55ns from address valid, that's more than enough time to bring enable and write down with the address and not use the clock, no? I'm pretty sure there are SMD ROM's that can match that performance and adapters are available to adapt between smd and dip. 

I don't know, I'm just thinking aloud here having fun going through this stuff. I'm curious to know the reasoning behind the design decisions, I'd like to learn something. 

Link to comment
Share on other sites

9 minutes ago, jbaum81 said:

I don't know, I'm just thinking aloud here having fun going through this stuff. I'm curious to know the reasoning behind the design decisions, I'd like to learn something. 

On that note, for your build, maybe a 15-input diode OR gate with an inverter on the output could indicate writes to $00 or $01 without needing lots of gates.

Link to comment
Share on other sites

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

You can split the high 32K and the bottom 32K, since the ZP banking only happens at the bottom and the ROM, High RAM and Device IO only happen in the top 32K. So one select circuit is driven when A15 is high, a different one when A15 is low.

For the ZP, you might have a low select 2x4 decoder with A15 and A0 as inputs, selected at $0000/$0001 when $A1-$A14=0, with a couple of hex drivers wire-ored at the output lines, so select is only low when A1-A14 are low. That leaves two free line driver inputs for the upper 32K select circuit. The $0000 is selected as one latch, $0001 as the other and the $8000 and $8001 lines are don't connect. The 2x4 decoder may be available as a dual, so you also have one to split up $80/$90, $A0/$B0, $C0/$D0, and $E0/$F0. Or if it's more stable, A15 is the select line, and the input from the wired-or hex drivers and A0 pick the two valid select lines for the latches.

Edited by BruceMcF
Link to comment
Share on other sites

6 hours ago, BruceMcF said:

You can split the high 32K and the bottom 32K, since the ZP banking only happens at the bottom and the ROM, High RAM and Device IO only happen in the top 32K. So one select circuit is driven when A15 is high, a different one when A15 is low.

For the ZP, you might have a low select 2x4 decoder with A15 and A0 as inputs, selected at $0000/$0001 when $A1-$A14=0, with a couple of hex drivers wire-ored at the output lines, so select is only low when A1-A14 are low. That leaves two free line driver inputs for the upper 32K select circuit. The $0000 is selected as one latch, $0001 as the other and the $8000 and $8001 lines are don't connect. The 2x4 decoder may be available as a dual, so you also have one to split up $80/$90, $A0/$B0, $C0/$D0, and $E0/$F0. Or if it's more stable, A15 is the select line, and the input from the wired-or hex drivers and A0 pick the two valid select lines for the latches.

I think I follow, but what have you gained by first splitting the upper 32k out? If we acknowledge that a1-14 still have to be evaluated? 

The latches I've chosen require OE to be off when latching, the logic I came up with there was AND the clock pulse with write and the logic that addresses the chip then invert OE as I bring the cp high. Not in that exact order of course, I do bring OE high well before CP going high. I attached my diagram above if your interested. 

Link to comment
Share on other sites

9 minutes ago, jbaum81 said:

I think I follow, but what have you gained by first splitting the upper 32k out? If we acknowledge that a1-14 still have to be evaluated? 

The latches I've chosen require OE to be off when latching, the logic I came up with there was AND the clock pulse with write and the logic that addresses the chip then invert OE as I bring the cp high. Not in that exact order of course, I do bring OE high well before CP going high. I attached my diagram above if your interested. 

If I'm following right, the advantage to splitting the upper 32K out is that you don't need to power/use the rest of that decoding logic for ZP if A15=1, only if A15=0.  

As for Bruce's suggestion to wire OR the hex drivers' outputs, I find that a more elegant solution than my suggestion of a diode OR gate, because voltage levels are likely more stable with Bruce's approach vs. diodes.

Link to comment
Share on other sites

54 minutes ago, picosecond said:

Why do you think this?

Well, Since input and output are on separate pins it's not to prevent shorts or bus conflicts. It's not really necessary in my use case, I don't think the circuit itself requires it. The only reasons I could think of is for signal stability or the ability to have CP hooked directly to the clock without the need of additional logic there. I opted to apply logic to CP in my case primarily to balance the logic load for select between it and OE. 

Link to comment
Share on other sites

1 minute ago, picosecond said:

Nope.  It's neither necessary nor helpful.  Just ground the OE.

The datasheet was a little confusing to me. It did say that OE doesn't affect the flipflops, but it does say that new data can be entered or retained while output is in high impedance state (OE high) . I wasn't sure if the output would remain locked to old values if left low, so I decided to take the safe route and bring it high while I latch in the new data. I'd definitely prefer to just tie it to ground though if the output will literally just echo the state of the flipflops as they change. Here is the datasheet for the latch I chose. 

 

https://www.ti.com/lit/ds/symlink/sn74f574.pdf

Link to comment
Share on other sites

55 minutes ago, jbaum81 said:

It did say that OE doesn't affect the flipflops

Right, CLK and D are the only inputs that affect flop state.  OE only connects or disconnects the flops' outputs to the '574 outputs.  The logic diagram on page 2 of the data sheet illustrates this pretty well.

Link to comment
Share on other sites

14 hours ago, Lorin Millsap said:


You are basing that on obsolete information. The X16 uses addresses $00 and $01 for banking control freeing up the VIA for better uses.


Sent from my iPhone using Tapatalk

To be fair, "obsolete information" is the information in the master branch of the CommanderX16 Documentation GitHub repo. The Readme.md does not hint that the information is obsolete. The zero page RAM/ROM banking documentation is in the board_r2 branch. The emulator master branch still uses the VIA for bank control and the x16_board_r2 branch of the emulator has been dormant for 8 months and is now behind the master (notably the latest SD card support appears to be missing). From what we've been told something is wrong with the r2 board and an r3 prototype is being planned - it isn't clear that the r2 board documentation or emulator is anything that could be relied upon. By all appearances, the obsolete information is the most up-to-date information one could expect to use when developing for the X16.

Link to comment
Share on other sites

32 minutes ago, Wavicle said:

To be fair, "obsolete information" is the information in the master branch of the CommanderX16 Documentation GitHub repo. The Readme.md does not hint that the information is obsolete. The zero page RAM/ROM banking documentation is in the board_r2 branch. The emulator master branch still uses the VIA for bank control and the x16_board_r2 branch of the emulator has been dormant for 8 months and is now behind the master (notably the latest SD card support appears to be missing). From what we've been told something is wrong with the r2 board and an r3 prototype is being planned - it isn't clear that the r2 board documentation or emulator is anything that could be relied upon. By all appearances, the obsolete information is the most up-to-date information one could expect to use when developing for the X16.

Gets better, I seen a video going over changes in the 2nd revision and it appears they're completely moving around the IO area as well. Looks as if both Via's will now co-exist at the top of the range. I definitely like those changes, it's a lot more comprehensive. None of it is updated in the wiki.

 

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use