Second Steps (Building R0)

[cr1901]

Sadly, I don't have a PLD programmer (and really don't have the funds/time to buy/build one, in addition to making this circuit). Even if I did, it does seem a bit like cheating. On the other hand, my question about whether a "14MHz design can be run with all DIPs" is a resounding yes. I just found Joachim Deboy's website tonight. So that burden has been lifted.

Re: NVRAM:
I came to the conclusion a few nights ago that a design with EPROM at 14MHz is simply not possible, unless I want to halve the speed of non-volatile accesses. So I've been thinking of other solutions. One thing I've thought of doing is to break my rule of "no serial buses", and have an all-RAM design. Like chessdodger mentioned, I would disconnect /WE for that specific address range, so writes do nothing. A microcontroller with an I2C bus, I/O expander, and serial EEPROM would write the RAM from serial EEPROM while de-asserting RDY, and then go into standby. I could expose the I2C either through the PIA/VIA or have a parallel-to-I2C chip on the main address bus.

I didn't know NVRAM it was made in DIP format. I didn't look hard enough; Cypress, my first choice for memory, seems intent on removing all DIP packages- neither dual port or NVRAM is available in DIP form. Perhaps the microcontroller bootstrap might work with either type of RAM, though it would be redundant on NVRAM if /WE was disconnected.

Another update: I missed something about address decoding on Garth's primer that solves my BANK0 8-input OR gate problem: Simply replace it with a comparator such as the 74ACT521!

[Michael]

Hi cr1901,

Depending on the size of the pseudo ROM image you want to copy into RAM, you might not need the I2C EEPROM. The little 28-pin PIC I'm using (18F26K22) has about 60K (of 64K total) flash memory available for a ROM image. I suspect there are many other microcontrollers available in DIP packages with as much or more flash memory.

You also probably don't need the I/O expander. If you connect the microcontroller directly to the data bus and use it to control the CPU reset and clock lines you can use it as a "blind loader" to copy a ROM image from flash memory into RAM by letting the CPU do all the work. This requires either a small unassigned block in memory space or a method for turning your address decoder circuit off during the clock cycles when the loader is pushing instructions or data to the CPU over the data bus. A blind loader can be a bit slow, taking up to several hundred milliseconds to copy a large image, but only you can decide if the savings in hardware and PCB real-estate is worth it. After loading the ROM image into RAM during power-up the microcontroller disconnects itself from the data bus and simply supplies a full speed clock before releasing the reset line.

A ROM-less system makes sense (to me) and not just for the sake of using high-speed RAM. If I could develop a small ROM image with a monitor and an SDcard-OS bootloader, I could load any one of a number of disk operating systems (variations of Apple DOS, ProDOS, Pascal, etc.) and languages (Apple Integer BASIC, FP BASIC, Forth, Pascal 1.1, etc.) from an SDcard.

Good luck on your project.

Cheerful regards, Mike

[scotws]

Michael wrote:

If I could develop a small ROM image with a monitor and an SDcard-OS bootloader, I could load any one of a number of disk operating systems (variations of Apple DOS, ProDOS, Pascal, etc.) and languages (Apple Integer BASIC, FP BASIC, Forth, Pascal 1.1, etc.) from an SDcard.

I've been thinking about something along the same lines for my 65816. After accepting that a PLD for glue logic makes more sense, current design envisions using a 512k RAM chip (or more than one), and invoking PLD magic to mask out 00:e000-efff for I/O stuff and 00:f000-ffff for 4k of "boot ROM". That would set up the SPI interface (65SPI) and load up to 64k of an OS (Forth in my case) from a SD card to Bank 1. Control would then be transfered there by a simple long jump in native mode to 01:0000.

That way, I can develop and test stuff on the big computer, save it on an SD card, and not have to burn EEPROMs all the time.

[cr1901]

I realized last night that using a bootstrap loader has it's own peculiarities, both '816-specific and general concerns.

First the '816: As with a number of other comparisons to the '02 (VDA/VPA qualification, demuxing bank address and data), the '816 has some behavior that requires extra interface circuitry for a bootstrap/reset circuit to work properly. According to the '816 datasheet, if RDY is de-asserted, the data bus holds the data for the current transfer- i.e. PHI2 is high. This means that the input to the bank latch must be gated, so that it ignores PHI2 if the processor is not ready (Now I'm beginning to appreciate BDD's advice).

Now for more general concerns:
The whole system needs a default state to go to on power on and reset- RDY must be de-asserted so that the processor doesn't try to do a read before the microcontroller is ready to load the program into RAM. According to Garth, on power on in the 65xx series, the first few clock cycles are internal operations before the reset vector is loaded, so I suspect it's not a big deal if a bootstrap microcontroller takes a few microseconds to assert RDY.

However if that assumption does NOT hold, then I need to gate/mux the system clock with an IO pin on the microcontroller, and ideally find a way to ensure that the microcontroller runs once at power-on, and then sets a flip flop such that the microcontroller clock is never chosen again through the mux (run-once circuit). If the 65xx is reset, it should be able to just jump to the reset vector from the program loaded from the microcontroller during power-on. The important thing is- there must be a way for me to distinguish power-on and reset (without touching memory), and I'm not sure what the best way is yet.

[Dr Jefyll]

cr1901 wrote:

the '816 has some behavior that requires extra interface circuitry for a bootstrap/reset circuit to work properly. According to the '816 datasheet, if RDY is de-asserted, the data bus holds the data for the current transfer- i.e. PHI2 is high. This means that the input to the bank latch must be gated, so that it ignores PHI2 if the processor is not ready

I don't quite see what you're getting at. What problem would result if the input to the bank latch were not gated? RDY on the '816 is the same as on the 'C02 -- it instructs the cpu to re-run the current read or write, and keep re-running it until RDY goes false. Only the final iteration "counts."

As for arranging a default state for power-up, one option is to start by resetting the microcontroller in whatever fashion you like -- such as an RC powerup delay circuit or a purpose-made chip intended for powerup detection. Have one of the microcontroller IO pins dedicated as an active-high reset output. This output, which has a pullup resistor attached, drives an inverter which in turn drives the 65xx /Reset input. Upon reset or powerup of the microcontroller, its IO pins become inputs. The pullup resistor prevails, the IO pin goes high, and the 65xx /Res goes low. It stays that way until after the microcontroller wakes up and initializes the pin as an output. When all is ready, the IO pin gets set low and the 65xx /Res goes high. This arrangement resets both processors immediately on powerup, and from there leads you to a controlled outcome.

Quote:

there must be a way for me to distinguish power-on and reset (without touching memory), and I'm not sure what the best way is yet.

So, you want to be able to reset the 65xx without necessarily doing a boot-load every time, is that right? IOW, have the option to reset the 65xx while keeping whatever's already in memory? If you don't wanna touch memory then some sort of IO is your only option. But is it really crucial to avoid touching memory?

All you need is one byte -- one bit, actually -- set aside for the purpose. The bootloader sets the bit. Whenever the 65xx initialization sequence runs, it reads the bit then clears it. The first 65xx initialization sequence following a boot-load will read the bit as one. ("Yes -- I've just had a boot-load.") Any subsequent 65xx initialization sequence will read the bit as zero.

cheers,
Jeff

[cr1901]

Dr Jefyll wrote:

I don't quite see what you're getting at. What problem would result if the input to the bank latch were not gated? RDY on the '816 is the same as on the 'C02 -- it instructs the cpu to re-run the current read or write, and keep re-running it until RDY goes false. Only the final iteration "counts."

The system clock doesn't stop counting just because RDY goes false. So each cycle that RDY is held low, even if the bus transceivers are disabled (/BE asserted), the bank address latch will latch a garbage value.

Dr Jefyll wrote:

All you need is one byte -- one bit, actually -- set aside for the purpose. The bootloader sets the bit. Whenever the 65xx initialization sequence runs, it reads the bit then clears it. The first 65xx initialization sequence following a boot-load will read the bit as one. ("Yes -- I've just had a boot-load.") Any subsequent 65xx initialization sequence will read the bit as zero.

I was working under the assumption that the bootstrap loader loaded the entire program into "ROM" (in reality, RAM with the /WE attached only to the boostrap microcontroller). So while indeed, this helps speed up the 65xx by letting it skip certain housekeeping by checking a flag, I also need this flag to be routed to the microcontroller as well. This is so that during reset, the microcontroller's sole purpose is to check that "bootstrap loading is not needed", ensure RES is not held low, and go back to sleep.

[Dr Jefyll]

Oops, I may've misunderstood your proposed setup. Are you intending that the microcontroller control the address-latch outputs as a means to set the high address lines (A16, A17, A18... ) as desired? There is another alternative worth considering. Have the uC tie directly to A16 etc. (with the latch's tristate output floated, just as are A0 to A15.) This'll cost you some extra pins (on the the uC), but I'll throw the idea out there anyway.

J.

[cr1901]

Check my edit- two separate problems. The microcontroller need not touch upper addresses in my setup. "ROM" is bank 0 only. The bank latch problem is because the bank address is latched during PHI2's rising edge, and the system clock keeps running when RDY is deasserted, since it's a completely separate IC. Therefore the value latched on the bank bus is lost, UNLESS the 65xx also redos the first half of a cycle.

Re: my edit- during reset, I was thinking I should reset the microcontroller as well, just in case some housekeeping beyond "load program during initial power-on" is needed.

[Michael]

I'm confused about what circumstances you think would cause a "garbage value" in the bank latch. Could you elaborate, please?

Mike

[cr1901]

RDY needs to be deasserted before PHI2 falling edge. During this half of the clock cycle (PHI2 high, which precedes the falling edge), the bank/data bus (BA0-7) will either have data to write or data to read from an accessed peripheral. While RDY is deasserted, the bank/data bus will retain the value that is to be written or read to/from a peripheral (through the data transceiver) during the PHI2 low.

Normally, the '816 will place the bank on the bank/data bus during PHI2 low, which the bank latch will latch on PHI2 rising edge. But because deasserting RDY causes the bank/data bus to reflect PHI2 high during subsequent bus cycles, the bank latch will latch unintended data.

[Michael]

Ah, now I understand. Thank you very much for taking time to help me to understand the problem.

Mike

[BigDumbDinosaur]

cr1901 wrote:

But because deasserting RDY causes the bank/data bus to reflect PHI2 high during subsequent bus cycles, the bank latch will latch unintended data.

You are correct. The circuit shown on page 46 of the 65C816 data sheet will not work as intended if RDY is negated for at least a full Ø2 cycle, as it fails to account for the fact that D0-D7 will hold data, not a bank address, during the next Ø2 low. Avoiding this contretemps is accomplished by arranging the glue logic so RDY is not negated until Ø2 goes high during a valid memory cycle (that is, when the expression VDA || VPA is true), and by arranging for the latch to remain closed while RDY is low. This sequence is practical because the MPU doesn't sample RDY until late in the Ø2 high part of the bus cycle. As the glue logic will "know" before Ø2 goes high if a wait-state is required, there will be ample time to set up the system to negate RDY after the rise of Ø2.

[Dr Jefyll]

cr1901 wrote:

... deasserting RDY causes the bank/data bus to reflect PHI2 high during subsequent bus cycles ...

BigDumbDinosaur wrote:

if RDY is negated for at least a full Ø2 cycle [...] D0-D7 will hold data, not a bank address, during the next Ø2 low.

No, I don't think so -- although I guess it's an easy assumption to make. In reality I think you'll find that (assuming BE is high) Ø2 low always means the Bank Address is present on D7-D0 -- even with RDY false. IOW, RDY false causes the entire bus cycle to repeat -- and all the repeat cycles will be identical to the original cycle, with two different types of activity on D7-D0.

I wasn't able to find any statement in the datasheet to confirm my view -- or to refute it! The text fails to be explicit on this point. But the diagram BDD mentioned is a significant clue. If Ø2 low always means the Bank Address is present, then the diagram is alright as is, and needs no correction.

Edit: it turns out my hunch is incorrect, according to experimental evidence noted later in this thread.

cheers,
Jeff

[BigEd]

I believe we've visited this question before, but I don't think we've heard from anyone who's done the experiment.

Has anyone tried to latch the high address of an 816 system, without using RDY to qualify the latch, in a system which uses RDY to stall the CPU?

Ed

[cr1901]

Dr Jefyll wrote:

No, I don't think so -- although I guess it's an easy assumption to make. In reality I think you'll find that (assuming BE is high) Ø2 low always means the Bank Address is present on D7-D0 -- even with RDY false. IOW, RDY false causes the entire bus cycle to repeat -- and all the subsequent iterations will be identical to the first, with two different types of activity on D7-D0.

I wasn't able to find any statement in the datasheet to confirm my view -- or to refute it! The text fails to be explicit on this point. But the diagram BDD mentioned is a significant clue. If Ø2 low always means the Bank Address is present, then the diagram is correct as is, and needs no correction.

cheers,
Jeff

Page 53 of WDC's current datasheet (Caveats):
7.6 DB/BA operation when RDY is Pulled Low
When RDY is low, the Data Bus is held in the data transfer state (i.e. PHI2 high). The Bank address
external transparent latch should be latched on the rising edge of the PHI2 clock.

In any case, I don't think RDY would be a very useful signal if my understanding of it from this blurb was correct- RDY is only checked near the end of a bus cycle, so no matter what, a full bus cycle is guaranteed to be performed after RDY is reasserted. This would mean that losing the bank latch data would be unavoidable if this were true.
EDIT to the above paragraph: I believe the bold is incorrect after thinking about this more. See below.

Now that I'm thinking about it, I think I'm supposed to interpret this blurb as: Bank Latch should be latched as normal when RDY is low, Data Bus (and other signals such as RWB) will retain it's value. The latter is to be expected, as the whole point of a wait state is to extend setup time (hold time can be made arbitrarily long by external circuitry)! But the data value isn't latched- it's passed through a transceiver, and so this is also a contradiction!

ARGH!


EDIT: I'm thinking about this more. If RDY is reasserted during PHI2 high, and the prop delays from RDY to '816's internals are satisfied before falling edge, then the '816 should complete the bus cycle during the same phase. So, BDD's suggestion is correct.

RDY must be asserted during PHI2 high, and RDY must be deasserted during PHI2 high of a subsequent cycle. Alternatively, RDY must be latched during rising edge of PHI2, so that the 65xx/bus interface circuitry only sees the new value of RDY after the rising edge- in which case, RDY must be asserted during PHI2 low, and can be deasserted at any time. In the latter case, RDY will indeed always last a full bus cycle or more.

The CLK must be gated with RDY so that the bank latch doesn't accidentally latch the data bus when RDY is deasserted during PHI2 low. Extra prop delay on the clock line is unavoidable :/.

I'll make a new topic for this after I work out some kinks.