Addressing logic

[Lorin Millsap]

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

[jbaum81]

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. 

 

[Sean]

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.  

[jbaum81]

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. 

[Sean]

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.

[BruceMcF]

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.

[jbaum81]

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. 

[Sean]

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.

[picosecond]

55 minutes ago, jbaum81 said:

The latches I've chosen require OE to be off when latching,  

Why do you think this?

[jbaum81]

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.