I've wondered about that myself. Let's all sign a letter to Bill Mensch and ask him to change reset so it puts $FF on the bank address. Think he'll listen?


On my POC design (recall POC means Proof Of Concept), I completely ignore the bank address and have arranged so ROM is visible from $E000-$FFFF at all times. So reset desn't have to do anything hinky. Even when I get to a more grandiose design, I will arrange for ROM to be present at that range.

Something that also has to be considered is that when an interrupt occurs, bank zero is automatically selected, requiring that ROM be present in high addresses or code must be present in high bank zero RAM to service the interrupt. Again, it would have been useful if the bank value had been mapped to $FF but could be ignored if wanted. Oh well!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Pardon me for being a big dumb dinosaur, but what do BA1, BA2, etc., refer to. What is it the processor is seeing? Seems as though you are unnecessarily segmenting RAM, but that could just be because I don't understand it. It isn't like a "normal" memory map where you progress from $000000 to whatever and at certain addresses, RAM, ROM or I/O show up, such as:


etc...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It would probably have to be selectable somehow so the fix wouldn't keep older designs from working. I sure wish they would fix the VIA SR bug regarding shifting with an external asynchronous clock.

It would be enough to even have only the reset vector at FF:FFFE-FF:FFFF. With a little ROM up there close to it to load everything else, the reset routine could load the interrupt vectors into RAM near 00:FFFF, and the ISRs could be loaded anywhere in bank-0 RAM.

I took BA0, BA1, etc. to mean "bank address," although not 64K banks like the '816 has, but just a section of memory.

Exactly it Garth, I was considering the decoded A21-A23 as being bank addresses of 2Mbs (A0-A20) each, not the typical 64Kb bank addresses.

Dimitri

One approach to the vector pull bank address problem I considered back when I was first thinking about the Kestrel-2 was to use the _VP signal to set a flip-flop, whose Q output fed (in parallel) 8 XOR gates. These gates were tied to A16-A23.

Thus, whenever _VP asserted, it'd pull from physical location $FF:FFFx. Likewise, code would execute from $FF:0000-$FF:FFFF upon boot-up. Of course, code must recognize that bank "1" was $FE, bank 2 in $FD, etc., when this happened.

Then, later, it'd use a VIA pin or some such to clear that flip-flop, thus restoring real addressing.

I think it's mostly for the benefit of emulation mode. Remember, the 65816 comes out of reset in emulation mode, and interrupts (BRK, IRQ, NMI, RESET) do not push a bank byte so at least the ISRs have to be bank 0. (In fact if you're running in emulation mode in a non-zero bank and an interrupt occurs, RTI can't find it's way home.) It probably wouldn't have mattered much if IRQ, NMI, and RESET pushed a bank byte in emulation mode, but pushing a bank byte would certainly have broken numerous existing BRK handlers.

A second difficulty is that JMP ($FFFC) is one way to "force a reset" (I've seen it used more than once) via software, so the vector must be located in bank 0, since the JMP ($FFFC) would break if it weren't and JMP (abs) would be broken almost everywhere else if it didn't fetch from bank 0 (or Bank B (i.e. the DBR) or Bank K (i.e the PBR) -- since both those registers would presumably be zero when running non-65816 aware code in emulation mode).

There are reasons (perhaps not terribly compelling reasons, but there are reasons ) to come out of reset in emulation mode, but was it absolutely necessary to do so? I say no, and coming out of reset in native mode probably would have gotten around the difficulties above. Coming out of reset in native mode, you'd have to specifically switch to emulation mode, and you could simply copy the RESET vector to what would presumably be RAM in bank 0. (Unless you ignore the bank byte, as you mentioned, and you wouldn't have to copy anything then of course.)

However, by coming out of RESET in emulation mode, the 65816 has to account for the fact that native mode might be entered at some point (and thus a fully decoded 24-bit address space might be present), but that it might be executing code in emulation mode (without having once switched to native mode) indefinitely.

In summary, the 65816 probably could have located all vectors in bank $FF had it come out of RESET in native mode (or the native vectors in bank $FF and the emulation in bank 0, though that seems needlessly confusing), but to me, it appears that the decision to come up in emulation mode means that there are several tricky emulation mode cases to handle, which can be solved by putting the vectors in bank 0, however inconvenient that may be. IMO, it is unfortunate that emulation mode seems to have wound up restricting the more useful native mode.

I disagree; WDC could have engineered the CPU to hardcode bank $FF just as easily as it hardcodes bank 0 for emulation mode. This would imply that stack and direct-page sits in bank $FF as well, and that JMP (abs) fetches from bank $FF as well.

The 80286 employs an interesting and tangentially related trick. The base address of the code segment is set to $FFFFF0 upon CPU reset until the CS register is explicitly loaded with a far branch of some type. Reloading the CS register resets the base address for the code segment per 8086 rules, which means everything falls back to the 1MB RAM limitation.

So while the 80286 starts up with BIOS sitting in the highest memory regions, it expects you to eventually load an OS into the lower 1MB region if you want to stay in real-mode. (Otherwise, you can enter protected mode directly and avoid the whole issue.)

I'm fairly certain the 80386 works similarly. I don't know about subsequent CPUs though. At any rate, I found the Intel solution to this problem an interesting case study.

I have to admit, I rather like my XOR-gate approach to this problem. It's simple to implement and should be "good enough" for most purposes. It won't be fast though; XOR gates have something close to 4 NAND-gate propagation delays. If your circuit is sufficiently fast to require a CPLD for address decoding, you can probably get away with just using a set of magnitude comparators.

In the 65816 system I have on the breadboard at the moment, I have the high 8 address lines driven from both the normal 8-bit latch and also from an 8-bit buffer with all its inputs connected high. The enable lines for each chip are driven from the opposite outputs of a flip-flop so only 1 is ever enabled at any time.

At reset, the flipflop is reset and the buffer is enabled, forcing all eight high address lines high. The CPU can only access the top 64k of the address map and gets the reset vector from $FFFFFC and starts executing from the top 64K of ROM, although the processor thinks it is running in the bottom 64K.

The first thing the ROM is a jump to itself at its real address, then it sets the flip-flop. This then disables the buffer, enables the latch and the processor can now access the whole memory map.

This method allows the vectors to be in RAM normally. It also has the big advantage that it doesn't add any extra propagation delay to the high address bus over that of the latch that you need anyway. It's also easier to wire up if you are using discrete logic devices!

Also, why oh why does everyone gate phase2 into RAM and ROM chip select logic? The best way is to generate the chip select only from the address lines. You then gate phase2 and read/write' together to get signals that you use to drive the memory chip's output enable and write pins.

This selects the memory chip at the earliest possible time, while not actually reading from or writing to it until phase2 is high. Memory chips select faster from write & output enable than they do from chip select, so selecting the chip in this manner relaxes the timing requirements somewhat.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

That is a good idea. Thanks!

On the module, just to save space, I'm going to go with 32Kbyte RAM ($0-$7FFF), 32Kbyte ROM ($8000-$FFFF), 2Mbyte RAM ($10000-$203FFF).

The user storage space (flash memory that is accessible by the user, its my nickname for that) will be on the mating board.

I put my first order through Jameco, and it seems like they don't want Canadian customers, either put up with UPS's insane brokerage fees, or pay insane amounts for USPS expedited shipping. I told them to drop a item from my order so it will be under the 20$ price point UPS charges brokerage fees and probably wont order again. Not until they offer USPS Priority Shipping in those flat rate boxes cause they are insured, traceable on both sides of the boarder, and are about 1/2 the price of expedited.

Dimitri

Over all the memory map of the system will look something like this:



Each I/O device would be using the 4 lower bits as registers, similar to what I gather the standard I/O items for the 65** series use. The upper bits in the 64K address range will be used to select the proper I/O port required. Giving you up to 4095 I/O ports that are addressable in the 64Kbyte address space allotted to system I/O.

The Unassigned space, is cause I'm making this into a module that plugs into a system using 2 rows of 25 pins, so if a special address range is needed for a device, its available to them.

Dimitri

It seems to me that you could drive the upper lines through a simple resistor net from the flip flop you currently have enabling the buffer. Since the switching isn't time critical (and you only turn it off), rise/fall time shouldn't be an issue.

Just a thought that could save some board space and/or complexity

A 74AC86 has a total prop time of less than 10ns.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I've asked the same question (metaphorically speaking).

With the 816, you have to watch out for address bus diddling during the MPU's intermediate cycles. This poses no special problem for RAM or ROM, provided you qualify a low-going RWB with Ø2, but could cause problems with I/O hardware. That's where the VDA and VPA signals can help, since they will tell you when the address bus truly is valid.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The data sheet for the 65c02 shows that as you close in on the processor's maximum speed, the soonest time that the address is guaranteed to be valid and stable gets mighty close to the rising edge of phase 2. If that's true, I suspect that a major cause of crashing when you go too fast is that the address is not out in time before phase 2 rises. At lower clock rates, yes, you would have more valid address time before phase 2 rises; but at the lower speeds the RAM access time is not difficult anyway. Common 55ns RAM will work fine with the selects qualified by phase 2, and it's fine to do it that way if it simplifies your glue logic.

Another reason to gate chip select logic with phase-2 is to support DMA during phase-1.