Sketches please: a fewest-chips logic-only 816 system

[BigEd]

Other than creative usages, I'd hope that a 'fewest-chips' 816 system would make no use of these special-purpose pins:
RDY, VPA, VDA, VPB, ABORT, MLB, MX, BE, E

These pins certainly have their uses, but I would expect a minimal system not to need them. (In related news, I think they should be introduced as late as possible in the journey of educating or evangelising about the 816.)

Using E to distinguish boot-time from run-time is a nice creative use, which I applaud!

[GARTHWILSON]

Using VDA and/or VPA might be free if you have left-over gates in quads like the 74xx00 quad NAND or a 74xx04 hex inverter.

[BigEd]

Sorry, I don't mean to derail the thread...

[Chromatix]

I spent some more time working on just the glue logic and decode section, resulting in the following 3, 4, and 5-chip setups with correspondingly increasing functionality. These chip counts include the glue logic, address decoding, and bank address latch, which is what these diagrams show.

In each case there are no gates left over, and the Phi1 signal is deliberately one gate-delay advanced from the Phi0 signal intended for the CPU. This matches the signal hold time required by the latch to that provided by the CPU.

Beware of extreme cleverness in the 4 and 5-chip glue logic, particularly in the area handling the RDY signal. The Phi0 and Phi2 signals are generated in what might be termed a conventional manner, but there are actually two copies of the positive oscillator signal feeding the NOR gate generating Phi1, one of which is delayed by two gates and qualified by RDY, the other straight from the oscillator. It's probably worth a few extra eyeballs making sure there are no glitches here and that the timing I think will result is correct.

[mikeblas]

Chromatix wrote:

It's probably worth a few extra eyeballs making sure there are no glitches here and that the timing I think will result is correct.

Have you built these? I'm wondering how the transition from emulation mode to 16-bit mode works. If code is executing at a ROM memory address when the transition occurrs, the memory address will change and the ROM is gone because it's un-mapped. What happens?

(I don't know ... I haven't read that far in the data sheet just yet. Maybe there's some reboot-ish transition that happens and so it's fine. But ...?)

[Dr Jefyll]

mikeblas wrote:

If code is executing at a ROM memory address when the transition occurrs, the memory address will change and the ROM is gone because it's un-mapped.

Luckily, things are much more orderly than that.

It's the Program Bank Register (PBR) and Data Bank Register (DBR) which by default are in charge of what appears on the eight most-significant address bits, A23 - A16 (aka the Bank Address). PBR and DBR are both initialized to zero upon reset, and that's why a 65816 seems to have only a 16-bit address range (ie, 64K, like a 6502) after reset. But in reality it is *always* emitting 24-bit addresses, even in Emulation Mode. It's just that the highest 8 address bits may be zero.

At some point the programmer may choose to alter PRB and/or DBR, but it'll be at his/her convenience -- there needn't be any hazards or contortions involved. Programming the 65816 Including the 6502, 65C02 and the 65802 may be the easiest path for boning up on this stuff.

cheers,
Jeff

[GARTHWILSON]

mikeblas wrote:

I'm wondering how the transition from emulation mode to 16-bit mode works.

Note that just because it's not in emulation mode does not mean it's in "16-bit mode." When it's in native mode, ie, not 6502-emulation mode, you can make the accumulator either 8- or 16-bit, and separately from the accumulator, you can make the index registers together either 8- or 16-bit. There's nothing preventing you from having it all 8-bit in native mode if you want to. The bits to control this are in the status register. The emulation bit is not. Jeff's recommendation to read the Lichty & Eyes programming manual is a good one.

[mikeblas]

Dr Jefyll wrote:

At some point the programmer may choose to alter PRB and/or DBR, but it'll be at his/her convenience

I'm looking at the decoder and clock manager at the bottom left of Chromatix's schematic.

It's not too clear to me what the 573 latch is doing becaues the latch inputs and outputs aren't labelled. The description says that the emulation line "swaps A15 with A21. so ROM mapped at $200000 in native mode appears at $008000 in emulation mode (ie, out of reset)"

From that, I'm inferring that the inputs to the 573 are the data lines, and are latching the the D lines when they carry A16..A23 during the low phase-zero clock. (Right?)

When I look at that book, page 61 has info about switching from emulated mode to native mode. The data sheet says that the PBR is initialized to 0 at reset.

And we reset. We know what we're doing, so we've got some ROM at 0x8000 and the reset vector points into it, and here we go.

First thing we do is try to switch into native mode. We clear the carry, CLC, then shove that into the emluated flags rack with XCE. Emulation bit is set:

Code: Select all

; booted in emulation mode
; vectored here at reset
8000:  CLC					; clear carry
8001:  XCE
; now in native mode
8002:  JSL  HelloWorld		; print hello world!

So this is what I don't get. After XCE at 0x8001 is executed, the emulation line will go high. The lower-left schematic will move the ROM, with this code (including the JSL instruction we're about to execute) from 0x8000 to 0x200000.

PBR is zero, so the PC just widened from 0x8002 ot 0x008002. But the ROM isn't mapped there anymore.

What happens now? More likely, what am I mising? Is there a way to set the PBR to 0x20 before switching?

Maybe the trick is in section 7.8.2, which says PHB and PLB are available in emulation mode, even though emulation mode forces the bank address to 0x00. Does the code above to accommodate switching while the ROM mapping decoder moves the ROM address then become:

Code: Select all

; booted in emulation mode
; vectored here at reset

8000:  LDA 0x20				; bank 0x20 for ROM is steup in PBR
8002:  PHA
8003:  PLB

8004:  CLC					; clear carry
8005:  XCE
; now in native mode
; remapped to bank 0x208006
8006:  JSL  HelloWorld		; print hello world!

Is that it?

[Chromatix]

My recommended sequence would be to copy the contents of the ROM into the area of RAM that will appear in high bank 0 before switching to native mode. The transition will then be seamless from the CPU's perspective, as the data found at both possible physical addresses is the same.

Code: Select all

Copy32K_ROMtoRAM:
  ; initialise source address, Bank 0
  STZ $00
  LDA #$80
  STA $01
  ; initialise destination address, Bank $20
  STZ $02
  STZ $03
  LDA #$20
  STA $04
  LDY #0
  ; loop for 32K, until high byte of source address wraps
: LDA ($00),Y
  STA [$02],Y
  INY
  BNE :-
  INC $03
  INC $01
  BNE :-
  RTS  ; it is now safe to switch to Native mode if desired

Another possibility is to copy code into an area that is always RAM (eg. the low half of Bank 0), and execute from there during the transition; it could be in a high bank, even in Emulation mode. It is then possible to copy data into the high half of Bank 0. This method, however, leaves a short window in which the interrupt vectors will be uninitialised, and RTI cannot return to a high bank in Emulation mode (because the 6502-compatible interrupt stack frame doesn't include the bank address). IRQ is easily masked and BRK/COP avoided in software, ABORT is normally tied inactive, Reset reverts to Emulation mode and maps the ROM back in, but any NMI sources will need to be disabled externally.

[mikeblas]

Chromatix wrote:

My recommended sequence would be to copy the contents of the ROM into the area of RAM that will appear in high bank 0 before switching to native mode.

What's the rationale for your recommendation? Takes a little while to copy 32K, avoided by initializing the PBR before the switch (if that works ...? maybe your point is that it actually doesn't work?)

[Chromatix]

It'll take about half a million cycles, which is an eighth of a second at 4MHz, and it's a one-time cost at reset, after which the CPU is in native mode, and the memory map is flat and convenient to work with. You probably wouldn't even notice it happening; you could interleave it with some other lengthy tasks such as initialising an LCD controller. You could also reduce the cost by copying a smaller area; the BBC Micro's Second Processor uses a 2KB ROM in a similar way.

There are alternative approaches, yes, but you have to take more care about setting them up, and there are circumstances in which some particular approach won't work. I will say that setting the PBR before or after switching to native mode is not a viable approach - either way, at least one instruction has to be read from an address that does not (yet, or any more) have the ROM mapped to it. At minimum you must copy the relevant program bytes to the RAM area first. The easiest way to set the PBR, incidentally, is to execute a JML instruction (JMP with a 24-bit address).

[mikeblas]

Chromatix wrote:

The easiest way to set the PBR, incidentally, is to execute a JML instruction (JMP with a 24-bit address).

That does set the PBR, but I don't think it works well in the context of the mapping switcher hardware that you're designing.

Chromatix wrote:

It'll take about half a million cycles, which is an eighth of a second at 4MHz, and it's a one-time cost at reset, after which the CPU is in native mode, and the memory map is flat and convenient to work with. You probably wouldn't even notice it happening; you could interleave it with some other lengthy tasks such as initialising an LCD controller.

That introduces development complexity, which is usually best to avoid.

Chromatix wrote:

I will say that setting the PBR before or after switching to native mode is not a viable approach - either way, at least one instruction has to be read from an address that does not (yet, or any more) have the ROM mapped to it.

Can you please help me understand why that's true? In my example above, I think that ROM is mapped to the zero 0x00 bank by your decoder until the emulation line is un-asserted. That happens when the state changes, so the next instruction would be fetched from the PBR:PC address. PBR == 0x20, since that's what PBR was set to, and then PC is PC+1 from the previous instruction so the wide PC ends up where we want ... inside the newly mapped ROM.

What am I missing? Maybe the fetch for the next instruction is happening at a different time than I expect?

[Chromatix]

The new registers in the '816 - PBR, DBR, DPR - are active and effective even in Emulation mode. Their default values out of reset give the same behaviour as a 65C02, but if you change them, they take effect immediately, even if you haven't switched to Native mode. Hence, if you execute LDA $20 : PHA : PLK : CLC : XCE, the CPU will try to fetch the CLC and XCE instructions from Bank $20 instead of the current bank, but there is still RAM mapped up there which hasn't been initialised yet.

What the routine I listed above does is to copy from the ROM into the segment of RAM that will appear in its place upon the mode switch. Hence the same bytes will be read regardless of mode. After the mode switch, there is contiguous RAM throughout the first few banks, and contiguous ROM in some higher banks.

[BigDumbDinosaur]

Chromatix wrote:

The new registers in the '816 - PBR, DBR, DPR - are active and effective even in Emulation mode. Their default values out of reset give the same behaviour as a 65C02, but if you change them, they take effect immediately, even if you haven't switched to Native mode. Hence, if you execute LDA $20 : PHA : PLK : CLC : XCE, the CPU will try to fetch the CLC and XCE instructions from Bank $20 instead of the current bank, but there is still RAM mapped up there which hasn't been initialised yet.

Uh...there is no PLK instruction. In fact there is no direct programmatic means by which PB can be modified.

A kludge that will work after a fashion is to push new values for PB and PC, push SR and then execute RTI to make the '816 load those values into the respective registers. Doing a JML is less hassle.

[Chromatix]

Right, I think this scenario actually serves as an illustration of why there isn't a PLK instruction; it wouldn't be very useful.

Ultimately the method of copying out part of the ROM is the most reliable one. But with careful coding, I think we can cut the amount of data that needs to be copied down to 256 bytes, a single page containing just the vector table and the reset handler. On the '816 the vector table is 32 bytes, containing separate vectors for native and emulation mode interrupts, much more than the mere 6 bytes that the 6502 needs. This still leaves 192 bytes for the reset handler, which could look like this:

Code: Select all

.org $FF00
ResetHandler:
  LDX #$FF   ; initialise stack pointer to $01FF
  TXS
  INX
: LDA $FF00,X    ; copy 256 bytes from ROM to RAM at top of bank 0
  STA $207F00,X
  INX
  BNE :-
  CLC    ; switch to native mode, which swaps ROM/RAM mappings
  XCE
  JML $20xxxx  ; to ROM now mapped in high bank

This is just 20 bytes, so there is also room for skeleton interrupt handlers (with the vectors in RAM, they can be steered to real handlers once the hardware is initialised) and perhaps some more hardware initialisation. A skeleton interrupt handler can just be an RTI instruction, or it can be a STP instruction if that particular interrupt is a "can't happen" in your system.