Hi All

Some of you will know about the homebrew computer I have already built (full details here : https://hackaday.io/project/5789-6502-homebrew-computer)

As you may recall, I had a memory map which was working to a degree but I had been getting away with some poor practice which was put right by folks on this marvellous forum

It now works fine at 5.36Mhz (I don't need faster and the video chip won't interface at much higher speeds anyway). So all good - sort of.

I am under utilising the RAM and ROM capacities I have on board - 128K and 64K respectively - and want to make it better. I have to do this with constraints - the breadboard space is very tight, and I want to use bits that I have in my cupboard.

I have therefore been thinking about how to re-design of the memory map.

The main thing I am concerned about is whether using a 6522 port to drive the bank select lines will be ok - for example does setting the port bits appear straight away so that the next fetch cycle by the CPU is modified by this?

There is also the slight concern of decode logic gate delays, but I think this should be ok for a 5.36Mhz CPU clock.

The main features are as follows:
- Ability to disable ROM to switch in the RAM 'underneath'. Using 1 bit of the 6522 port B
- All writes to ROM actually get diverted to RAM (allows writing without having to switch out the RAM, also can copy ROM to RAM if I wish)
- Move the 4K IO region from B000-BFFF to 1K region 0400-07FF, freeing up more addressable RAM and providing contiguous space through to BFFF or FFFF (when ROM is disabled)
- Switch between 4 banks of 32K for RAM - any address in the upper 32K of the map. Using 2 bits of 6522 port B
- Switch between 4 banks of 16K for ROM - any address in the upper 16K of the map. Using 2 bits of 6522 port B

The design uses 4 logic chips which I have to hand (I have space for 3, will do some rearranging to get the 4th on the breadboard)
- 1x74HCT138 for IO selection logic
- 1x74HC00 and 1x74HC02 for ROM and RAM selection logic
- 1x74HC00 for ROM and RAM banking logic

The attached picture gives the details - views welcome!

** Edit **
Since the above start to the thread, diagram is corrected

Nice idea... I think with a BBC Master (or a Beeb with sideways RAM) it shouldn't be too difficult to check the latency of the VIA outputs. My suspicion is that the next fetch after a write will be affected, but I haven't tested.

Thanks BigEd. Unfortunately I don't have a Beeb I can try this on. Looking at the WDC datasheet, I can't identify the right timing of this. The closest seems to be tCPW which is 'Peripheral Data Delay', which says a maximum of 30ns for a 14Mhz rated 6522S (that's the part I am using). If I am looking at the right thing, then this should be ok, basically adds 30ns before the address lines going to RAM and ROM are reflecting the value of the VIA's ORB.

Or at least, I think so. I'm slightly loathed to rip up the old decoding as I am not sure enough this one will work!

OK, I was able to rustle up a quick test, run it on a Master, and indeed the VIA introduces no extra cycles. The very next fetch after a write to the bank register is from the newly selected bank.

Awesome, thanks for trying that out BigEd, much obliged

I think the rest of the logic looks ok, unless some spots a faux pas somewhere.

I'm curious, how did you test the VIA - does the Beeb also use a 6522 port to act as bank registers?

Oops, I have been very silly, and tested the bank switching on a bad assumption. Unhappy face. Slapping head face.

Sorry: I have no result on the VIA timing, after all.

The 6522 datasheet does include a useful timing diagram on page 22:

The time between the falling clock edge of the write cycle and the peripheral data changing is called TCPW

The datasheet specifies this value as 1us (for a 1MHz part) and 500ns (for a 2MHz part).

I've just measured it using a scope at 120ns, and that's a Rockwell R6522A part (fitted to my Beeb).

The write is normally the last cycle of an instruction, so this will eat into the time available for the opcode fetch of the next instruction.

So you possibly need to run your bank switching code from RAM that's not affected.

Dave

Thanks for doing the measurement Dave! Making a simple 4 bit output port might be the right answer here: the VIA is overpowered and underspeed for this job.

Thank you Dave and BigEd for looking in to this.

Ah, yes tCPW - that is the timing I was looking at in the WDC datasheet. For the 14Mhz rated part I am using, this is 30ns maximum. So much faster compared to the Rockwell part, as would be expected of a modern version.

Looking at the 65c02 datasheet, tADS is 30ns max - the time for the address lines to stabilise after the fall of Phi2. This is the same at tCPW for the 6522. So the VIA output will be ready in time for the next cycle's address, and then it all has to go through the rest of the decode anyway.

I am running at 5.36Mhz, so each half cycle is around 93ns. So not a lot of time to spare before Phi2 goes high, but my rough calculation is that all the decoding will take a maximum of 60ns for the IO section to provide chip select to devices, and more like 40ns for the chip select to ROM/RAM.

I agree the 6522 is overpowered for the purpose I'm putting it to, but I have very little space left and trying to be resourceful where I can and using the last 5 spare bits of port B! The alternative will be to re-do a whole bunch of wiring and moving stuff around to accommodate yet another IC

I think this is looking feasible, on paper at least..?

Fair point that you're using what you have! There seemed to me to be quite a bit of logic depth in your diagrams, but if you've added up the propagation delays and it looks good, that's fine. (I haven't tried to follow the exact logic that you're doing.)

It's fine in your case, most likely, but also interesting to see how a 14MHz part just about serves your purpose in a 5MHz machine.

Hmm, I am estimating 10ns average delay for each NAND and NOR - but should be in the region of 50-60ns. For the 3 to 8 decoders, they are more like 25ns each, so again in the same region of delay. I am using the typical figures from the datasheet at 5V and 25 degrees ambient, so this is not a design for working in the cold!

Yes, quite true, I am taking advantage of using a very fast 6522 to be comfortable at 5Mhz, but that's by accident really because I used the WDC due to general availability. In a very early version, I was using a couple of 6526's from an old C64, but they struggled at 1.34Mhz, so switched over a long time back.

I'm hoping someone will have the time and the inclination to check over the rest of the logic in case of some big flaw in my logic, but timing wise I am feeling more than 50% on the chance of that being ok. If it is all ok, it will really open up more possibilities for my machine as I am running especially short of ROM..

Actually, it's the heat that slows it down. Some computers in the past used Peltier devices to cool the processor way down, and when the temperature was low enough, they'd kick the clock speed up.

74AC/ACT is about three times as fast as 74HC/HCT.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm wondering why the prop delay through the VIA matters ? Won't the effective delay of the VIA be zero since the bank select outputs would be more or less static (the values stable a number of cycles before access), and a NOP instruction could be inserted to handle any prop delays before accessing newly selected memory. I'm assuming the memory being switched isn't the same memory that the program is executing from.

_________________
http://www.finitron.ca

Rob, yes it's a fair point especially from a RAM switching point of view. However the design swaps all 16K of ROM out for each bank, but I was going to anyway ensure that there were a common set of bank switching routines in the same place in every bank, so even if there is a single cycle delay before the new bank is switched in, it won't matter. It's only if I want to switch a code bank 'inline' that any propagation delay could be a problem, but I cannot see needing to do that for code (may want to do it for data though). So let's assume I don't need to worry about ORB to output pin delays.

I have question about the start up state of the 6522. All ports are set to input I believe but what happens if an input pin is connected to the input of a gate - for example port B pin 4 is connected to an input to a NAND gate. Looking at the WDC 6522 datasheet, I think it looks like the pin will read at +5V (logic 1), but I am adding pull ups just in case. Is this understanding correct and do I need the pull ups?

The WDC 22's inputs are high-impedance, and they have bus-holding devices, meaning that they will hold whatever state they last sensed. In the case of power-up, I suppose this is undefined. But after power-up, if you were to connect them to a logic high or low, then disconnect them while they're still in the input state, they'll keep themselves in whatever state they last sensed, not necessarily in a high state. This is what the data sheet says, and I can see how it would work, but I have not tried it myself, and I don't know how effective they might be at holding another CMOS input in the same state if it's connected. I can tell you that other brands of 65c22, in spite of being CMOS, have an LSTTL-like input, meaning they will pull themselves up, and you can't pull them down with a high impedance like you can WDC's. Where you're unsure, it might be good to provide a really weak pull-up, like 1M.

BTW, WDC's outputs a much, much stronger than the data sheet lets on.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?