I'm contemplating a banked memory system (with no particular aim in mind, just because it's fun). At present, the general idea is:

• A 64k image is broken into three main regions: 0-4k, 4k-56k, and 56k-64k.
• Within the top region, 0xff00 to 0xfff7 is reserved for I/O, and 0xff8 to 0xffff for the reset/interrupt vectors.
• The I/O area breaks down into four VIA spaces of sixteen addresses each and a further sixteen addresses for a 74HC670 register block (though it only needs four).
• The register block provides the top four bits to the RAM address, depending which address is being accessed.
• At reset, the top 8k would revert to an eeprom or flash.

Obviously the main requirement is to keep the decoding delay down to a minimum, but it looks simpler than I first thought. This still requires a way to code the three block addresses into a two-bit binary address, but I think that's just a couple of gates.

Neil

My first reaction is that your decoder is about six gates deep from the address lines. That's OK if you only want to use low clock speeds but if you try to increase the frequency the propagation delay will start becoming a problem.

Assuming you don't want to use PLDs, which would be much simpler, clearer, and faster, it may be better to lean more on decoder ICs and less on individual gates. Or at least consider using wider gates - there are at least two cases there where you essentially have 6-8 input AND but are forming it out of much narrower AND and OR gates. This all makes it clearer what's going on in the circuit and may reduce propagation delay, though wide gates are typically slower.

Also consider whether you really need every byte of address space accounted for. When you have banking this is usually much less of a constraint. Rounding up to 8k instead of 4k for that bottom block would probably make life easier as the main decoding would only need to use three bits.

Other than that, if you really want to ensure little address space wastage due to the I/O decoding, I'd suggest trying to parallelise more of the decoding so it's not just an in a long line. E.g. an 8-input AND can decode the top eight address lines while a 74HC138 decodes the next three in parallel, then you can use a multiplexer to combine the results, so you only have two propagation delays in the longest path. And if your I/O ICs have dual chip select inputs then you don't need the multiplexer.

Note also that the 6522 cares more about when it gets selected than RAM or ROM, which can be selected even after PHI2 rises and still work properly.

Edit: i forgot to add, the CPU can tell you when it's accessing the vectors, so you may not need to bother decoding that from the addresses.

if you goal is to keep decoding latency low, then a CPLD seem like the best option.
an ATF1504 should be large enough to house both the logic and Registers needed for Banking. (which also avoids the need for an external 74HC670)
but the main problem with uneven bank sizes like this is: how do you (efficiently) map them into physical memory?

one idea would be to split memory into the smallest bank (4k in this case) and just have the larger banks refer to the same Register + an offset.
so in this case you would have 3 registers B0, B1, and B2. for the first 4k segment B0 is used. for the next 13 segments B1 is used, and the final 2 segments use B2. or in a more mathmatical way:

$0000 - $0FFF -> B0
$1000 - $1FFF -> B1
$2000 - $2FFF -> B1+1
$3000 - $3FFF -> B1+2
...
$C000 - $DFFF -> B1+12
$D000 - $EFFF -> B2
$E000 - $FFFF -> B2+1

obviously it's more complex as the circuit requires an adder, but it gives fine control over where you place each segment. they can even partly overlap eachother. i made a mockup circuit that uses a slightly different memory map from yours, but should be functional. it does require the 84 pin version of the AT1504 or an ATF1508, but it can address up to 1MB of RAM, and 1MB of ROM in steps of 4kB.

acording to Quartus the worst propagation delay through this thing is around 13ns. which should be fast enough for 16MHz Operation.
i'll attach the digital file and generated verilog.

Using VLC logic, the decode delay is under 20ns. I'm not pushing silly speeds in this iteration, perhaps 4MHz. There are a number of reasons I don't want to use a CPLD, not least of which is 75mA current but also because it's something I know little about and don't have the capability to program them. Using discrete logic has the advantage of transparency, so the logic isn't hidden away.

The point about a larger first block is one to consider; I made it 4k only because at first sight it felt large enough for any of my potential uses; basically somewhere to keep pointers and data structures, with the remaining 52k for things like text storage. But 8k is likely to work as well and to possibly be a few nanoseconds quicker to decode. I envisage that in most cases the base page will likely be constant through he life of a program (if only to keep the zero page and stack intact) and that in general code can be expected to start at 0xe000.

I'm not considering a segment/offset architecture (I had enough of that with the 8086!) and I expect the top block to be eeprom until it's not; likely copied from there to ram page 0 early in boot up.

One of the VIAs will probably be talking to a 128Mb flash serial chip with some basic filesystem (not yet written) on it. As yet undecided: to use a 68B50 or an SPI uart (possibly both).

Neil

A simple through-hole GAL would reduce that to 7ns.

_________________
Bill

what exactly is wrong with the current draw? unless you're running from battery it shouldn't really be an issue regardless of what power source you use (even USB is enough).
learning about Programmable logic is the least issue as it requires the same knowledge as working with discrete logic. if you want to be lazy like me you can just use a logic simulator like Digital, which allows for your circuits to be exported as Verilog or be directly compiled for ATFxx compatible ICs. of course you'd still need a programmer though... the ATF/GAL22Vx series can be programmed using the always amazing to have TL866II plus.
plus with programmable chips the logic isn't "hidden", you still have to design it yourself so it's very much visible, just shifted from your breadboard/PCB to your PC. and that is a pretty big advanatge once you're out of the breadboard phase of a project, as it means any mistakes you made in the logic is easily fixed without having to physically modify the circuitry (cutting traces, running botch wires, or ordering new PCBs).

but as always, each to their own, ultimately it is your system so you decide how to run it.


in that case how do you map the banks into physical RAM? one way would be to just take the whole 16-bit address bus and just slap the additional 4 address lines from the Register File ontop of that, giving you a 20-bit address bus which is easily covered with 2x 512k chips (like the AS6C4008, which comes in a DIP Package but is slightly more expensive as the IS61C5128AL). i think that would also mean that none of the banks can ever overlap.

on a side note, if you have some VIA pins to spare you could in theory use one of those instead of the 4x4 register file, though that would require 2x 74HC153 Multiplexers for the address selection. but it would save you the logic for interfacing the register file (ie writing to it)


hmm, you could go for an SD Card as well. using FAT16 or similar as the file system would allow for interfacing with a modern system to make it easier to get programs and other files onto it. (unless you want your system to be a self contained thing with it's own assembler and such, in which case you could try to get GeckOS or similar running on it as a later project).
and speaking of VIAs, how do you plan to hook up the Interrupt lines from them? just AND them together and have your ISR check each VIA to find the one that caused it? seems like the easiest option to me.

I've spent the last fifteen years designing systems that work forever on batteries... minimal current designs are an instinct now (plus there's the admittedly environmental point of why use more power than you need to?).

There's also the whole designed-by-committee thing which I'd rather avoid if possible - I'm designing to suit me, largely as an intellectual exercise, and if anyone else finds it useful then they're very welcome to use it. But I'm not looking to add bits because a third party might find them useful; I'm trying to design something within a particular (though currently ill-defined) set of constraints and see how useful it is. If I wanted a completely general purpose computer, well, I'm typing on one...

The banking will most likely just switch in and out the middle 48k section of memory; using 8k above and below that plus (say) page zero should be sufficient for data usage - at least in the immediate term.

I'm also considering using an SD card as well - fat16 most likely - but the serial flash is probably the first to be implemented (though now I have SDCC doing largely what I need I don't think it would be too complex to port Elm-chan's Fat-FS).

VIA interrupts are likely to be all chained to the IRQ, yes.

The comments are appreciated even if I appear to be dismissing most of them out of hand, so thanks. It's a good way to persuade me to look at things I haven't yet.

Neil

It's absolutely fine to do the decode with 74 series, if it meets your goals.

I've compiled FatFS for the 65816 before and the binary output was 20-30kB depending on the selected features.
So if you want FAT32 support i recommend porting the commander X16's library for it (since it's already made for the 65C02) : https://github.com/commanderx16/x16-rom ... /dos/fat32
It's almost 8k in program size, so you might be able to squeeze it and a simple bootloader into an 8k ROM.

Reading this with interest - but more from an historical point of view - to see how it compares, maybe (and comparing to some of my own experiences)... Here are some thoughts.

Software - always the crux of these things! Monitor? Operating System? Run multiple programs, or "banks" of applications? Or video in one bank, data in another?

Hardware - it's quite retro but also sufficiently different from anything in the past (that I'm aware of), so see software...

(Although I appreciate that for some, it's the hardware, even if proof of concept more than software - I'm slightly more a software guy, but still want 'real' hardware to run it on).

My own bias would be towards the Apple II and BBC micro - the Apple had essentially the top 16KB as "easily" switchable to RAM via the "language card" and this was put to more use under ProDOS. The BBC Micro had a 16KB block from $8000 switchable - but it also had almost 16KB of operating system from $C000 to control it all. The Apple //e had more banks to give better graphics and so on, but also denser logic to manage it.

One thing I decided on for my own Ruby boards was to try to cut down on complexity and chip count - I share your low-power desires but sometimes (hobby project and all that) ... I resorted to using a 22v10 GAL in my 65C02 system (That has 10 outputs - does the decoding for 2 x 32KB RAM chips and a VIA in the 65C02 system, as well as combining IRQ sources) Power consumption - not massive, but my 65c816 system with 2 GALs, one VIA, 65c816, 512KB RAM and an ATmega with SD card idles at about 120mA running at 16Mhz. (The 2nd GAL in the '816 does the bank latching)

I don't have banking, but with your raft of VIAs, but to save the latch and decode logic, could you not dedicate a few bits of a port to select several banks? (But again, that's my bias towards the BBC Micro as that's how it did it)

Switching out the bottom 2 pages would be the biggest headache - you instantly lose stack and zero page so some very careful code might be needed there.

The question (for me) would them be along the lines of just how big a bank makes sense? 16KB is manageable and would let you keep several programs there, one in each bank. Overlaying ROM with RAM is a good idea - if you need higher speeds than your ROMs (Flash, etc.) an handle, and allows run-time re-direction of the base vectors too, if needed, but again, re-direction via RAM is also an option and done in the Apple II and BBC Micro - showing my bias again...

So there's a few thoughts of mine. Do keep going and it'll be great to see how it turns out.

Cheers

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Ouch - my FAT32 library is tiny in comparison - a test program to read a file and dump its contents to the LCD display is under 1.5k. It's read-only, and admittedly supporting writes is a little more complex, but I can't imagine it would need 8K of code... Though I probably missed some compatibility detail I guess!

it depends on what features the implementation should support and how the code is assembled/linked.
If you have a program that just reads a file then it won't be that large as you only need a few functions, but if you make a BIOS like ROM then you likely want to include everything a program could potentially need so that they don't have to include their own functions.

Unless you meant that your entire FAT32 library, including reading/writing, creating/deleting files and folders, long file names, multiple partitions, etc. Takes up only 1.5k...
Which would be very impressive IMO!

Haha, no of course not, and different people will want different feature sets but for most homebrew computer projects I don't think that's all necessary - my attitude to FAT32 is that it was designed for larger systems, but in the interests of interoperability we can use a subset of it effectively on small 6502 systems. As I said at the moment my code is read-only, and ignores long filenames. I've estimated that adding the ability to write files and folders would add maybe another 1k, but it's just a guess.

I think I'd probably be looking at an implementation which can do a fairly complete implementation of the FAT32; certainly I'd want directories and subdirectories (if only for completeness!). The commanderx16 code is a possibility but I'm nowhere near that yet.

Neil

After kicking the idea around a bit further: use four sixteen k blocks in the memory space. The top block (0xc000...) contains 256 bytes reserved for I/O at 0xc000-0xc0ff; those addresses will include the write address for the 670 register array. The read address for the registers is straight from A14 and A15 and it provides a bank address for each of the 16k blocks, so they don't need to be on the same page.

I still see banks 0 and 3 (0x0000 to 0x3fff and 0xc000 to 0xffff) as generally constant with the other two pages available for easy swapping; I suspect an eeprom will be loaded into bank 3 at start up. I'm also considering whether four pages of bank 2 can be used for video memory to give a pixel-addressable 800*600 SVGA mono output. In that case, it would be convenient to use the standard 40MHz dot clock and a 5MHz ph2 but I still need to look at timings for the counters etc.

This decoding design with VLC runs with a delay of about 8ns depending on other loads and Vcc - curiously, Diodes Inc's version of VLC specifies a Vcc of up to 5.5v while NXP's version claims 3.3v, but gives a Vmax for Vcc of 6.5v. I need to do some testing...

Neil