I've been thinking of ways to implement a way of attaching a module to a 65C02 PCB and have the attached Microprocessor on the module take over the system - including the ability to read/write RAM.
The obvious problem with this is that the 65C02 never tri-states (lets go over) the address bus normally. RDY pin cannot do this as it simply halts the CPU and (as far as I can tell) the BE pin will tristate the buses and flush the read/write buffers - effectively losing it's mind - and requires a reset of the CPU for it to start operating again.

Is my analysis correct? Or have a missed a way of doing this?

On a related note, I was also thinking of designing a diag tool which sits in a 65C02 DIP40 socket. It would have its own DIP40 socket which contains the 65C02 which is buffered (signals, address and data buses) using AC CMOS buffers. A Microcontroller can then intercede by disabling the buffers when needed (on PHI2 transitioning from high to low), test RAM/ROM/IO.
The only thing problem I can see here is the CPU having to be run quite slowly due to the buffers
Sound feasible?

I'm kinda spitballing here, and I'm not an expert, but:
It might be possible to do it by using the 'C02s NMI, wired to a signal coming out of the module that goes low when it wants to take over. Then the NMI handler does something to suspend the 'C02, and indicate to the module that it can go for it's life. The module would probably need some way of releasing the 'C02 from suspension.
If reading and writing to the whole memory space(not just RAM) from the module is on the table, you could set aside a memory location that would toggle a latch when written. That latch controls RDY and BE, to suspend the processor and kick it off the bus. Then, when the module wants to hand control back to the 'C02, it hits that same memory location(which will re-activate the processor), and gets itself off the bus. The 'C02 then continues as if nothing happened.

The diagnostic tool you mention sounds very similar in concept to a thing I called a Bus Bug. I never implemented the MPU socket form of it, though.
My version would have used an Arduino Uno and a few tri-state buffers, so that the Uno can pick up the signals 8 at a time(data bus, address bus, and control signals), without consuming too many pins. The Uno would drive the clock signal, so it has enough time to read all the signals (It turns out that a 1MHz 65c02 is too fast for a 16MHz ATmega, at least if programmed in C). It would then send a message with the 'C02s state down it's serial line.
In this design, the MPU is never disconnected from the system, but the Bus Bug isn't able to write into the system(mainly because I was only after a look into the system at the time).

Have you examined this thread for ideas and/or inspiration? Or am I off track in imagining what you're attempting?

viewtopic.php?f=4&t=3323&hilit=hoglet

Mike B.

In order to allow another bus master to take control, you must first halt the 65C02 by negating RDY and then free up the buses by negating BE. Returning control to the 65C02 requires that you drive BE high and then drive RDY high. It does work if you do things in the right order.

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

Excellent . This was the information that I was after as I was under the impression that once BE went low a reset was required. Cheers

If you don't especially need lots of speed then you can save significantly on resources -- two octal tristate buffer IC's, perhaps, and certainly 16 pins on the attached device (eg: microcontroller) -- by NOT providing direct control of the 65xx address bus. The attached device would take over the 65xx data bus, plus a few control signals, but not the address bus.

Six cycles are required for each byte written to the 65xx's RAM. The attached device places dummy instructions on the data bus, faking a LDA immediate and a STA absolute. For example, in order to write $12 to $3456 the bytes $A9, $12, $8D, $56, $34 are faked (placed on the data bus just as if they'd been read from RAM). The 6th cycle is a write cycle, and on this cycle the RAM is allowed to participate, storing the byte we wanted stored.

Rinse and repeat! Just be aware that, as you proceed, the 65xx Program Counter will be blindly counting through the entire 64K space. After the very last STA you'll probably want to restore PC to a meaningful value, either by faking a JMP or by applying a reset or interrupt.

Reading from the RAM can be done in a similar fashion, but each byte needs only four cycles (for a LDA absolute). The first three cycles are faked ($AD, $34, $12); then on the 4th cycle the attached device takes a peek to see what appears on the bus. On this cycle the RAM is temporarily allowed to participate -- ie, to read what's at $1234. [Enabling reads requires the nOE signal to be wiggled. Enabling writes is potentially simpler, as you may choose to let resistors be the default bus masters. During write cycles the CPU will override the resistors automatically. More on bus control in the posts below ].

You can also take control of the 65xx's I/O devices, since they read and write in the same way as RAM. You could arrange to copy bytes from RAM to a UART, or vice versa -- IOW, a level-2 bootloader. Initializing the UART isn't a problem because that too can be faked with the cycle-by-cycle technique.

In fact, except for conditional branches the code-fake thing can do pretty well whatever you want! Just remember when you're done to restore PC to a meaningful value.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Here's one possibility for wiring in regard to that code-fake trick (details in the previous post). This is more or less what I used for a test computer I threw together recently. (Working title: "Throw-Together Computer." I've really got to come up with a better name! )

This drawing is of the skeleton, so to speak, with a lot of detail stripped off. The glue logic in TTC includes a triple SPDT mux/demux, which is fast and compact. But for reference I've added an equivalent drawing without that feature.

In both drawings all the components pertaining to the code-fake aka bootup interface are shown with colored shading. Not a lot to it, really. And it also gives single-cycle capability.

It'd be easy to make a ROM-less 65xx system by attaching this setup to a (fairly) low pin-count microcontroller. But in TTC's case the attached device is a UART-ish CPLD contraption that never transmits, only receives. In other words, a UAR.

I used 10K resistors to connect the 65xx data bus to the attached device, mainly because that's a foolproof (also quick 'n dirty ) way to prevent excessive current from bus contention! During bootup the attached device generally keeps the nOE signal high, which during read cycles means the RAM can't drive the data bus. The CPU is still able to do so, however, as happens anytime there's a write. No extra logic is required for this. Always at the correct time the CPU automagically overrides any opinion expressed by the 10K resistors! But on read cycles the resistors prevail as the default bus master.

The resistors offer an additional benefit in cases where the attached device is not physically nearby. Because of potential ringing problems it's undesirable to directly extend the 65xx bus. But the resistors don't constitute a direct connection (nor even series termination as might be used with a transmission line, which this isn't). Just be sure to locate the resistors at the 65xx end of the extended bus.

One slight drawback is that the resistors necessitate rather slow bus cycles (ballpark one microsecond, depending), but it's easy to go that slowly -- and yet be acceptably fast -- by single-cycling. One final caveat: Only high input-impedance chips (eg, NMOS and CMOS) may connect to the data bus. The resistors wouldn't be capable of driving any TTL or LSTTL loads.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Many thanks for the idea & detailed explanation . I'll have a think. BTW couldn't you replace the resistors with bidirectional octal buffers? Maybe with the dir pin hooked up to the RWB pin of the 65C02? Was thinking that this would prevent prevent contention and also reduce capacitance on the bus?

There are various ways the idea could work, but the key point is not having to attach to the 65xx address bus. This eliminates 16 connections which otherwise would have to be controlled by the attached device. (For an '816 it might eliminate as many as 24 connections. )

For my own project I only need a boot-loader, so it's all about writing to RAM. But, as noted, reading is also possible, and likewise operations on the 65xx's I/O devices.

Yes an octal buffer could replace the resistors, but in most scenarios resistors are actually better. The buffer would add more capacitance than the resistors do, and resistors don't have any control signals (OE, DIR) that need to be administered. Not so with a buffer. Also (re control signals): if the buffer is used bidirectionally then remember you have to mind your P's and Q's re contention with the attached device (as well as contention with the 65xx bus, of course).

The resistors side-step all of that -- at a price in speed (due to the RC delay of driving the capacitance of the 65xx, the RAM and peripherals). If a buffer were used then the RC delay would almost disappear. But then the onus for speed would be on the attached device. Unless it's fairly nimble you wouldn't actually be able to accelerate things much (compared with using resistors).

If there aren't many bytes to move then the overall time may be quick even though the rate is slow. Perhaps there aren't many bytes in the intended application. Or perhaps all you need is enough to fire up the Level Two Loader -- one that's a lot faster and more capable. Even if you do opt for a bootup that's quite slow overall it may be an acceptable tradeoff.

-- Jeff

PS: if the resistors were replaced with a bidirectional buffer it unfortunately would not be feasible to drive its DIR pin from RWB of the 65C02. The only time you'd want to DIR to reverse is when data travels from the 65xx system to the attached device -- and that never happens except in the final cycle of the four-cycle ditty for reading RAM. But the ditty is just a LDA absolute, and the CPU treats all four cycles as reads.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Bingo! As you mentioned, it's possible to extend the capabilities of a "blind loader", as I call it, to effectively have full "ROM Emulator" capability in 64K RAM-only system designs. That is, you could implement a "blind monitor" with memory view/edit, memory move, mini-Assembler, mini-Dis-Assembler, x-modem, flash, single-step, and go commands that doesn't require or take up any 65C02 address space.

Imagine, no more burning E/EPROMs as you develop and test your operating system code. Simply enter the "blind monitor" at startup and transfer your code via the 65C02 serial hardware into RAM (or use the mini-Assembler), issue "go" or "step" commands to test it, and use a "flash" command to copy it as a pseudo ROM image from RAM into microcontroller flash memory. Thereafter you would normally go directly into 65C02 operation with your monitor and operating system code in RAM after the "loader" operation, or you can choose to enter the "blind monitor" at startup.

All this capability using as little as 11 pins (8 data, 1 clock, 1 reset, and 1 RAM or Decoder enable) plus one pin on the microcontroller for a reset switch input. Coincidentally, these are pretty much the same eleven pins you identified long ago in this boot-loader post.

While I don't believe this is exactly what Mike (banedon) is looking for, I hope it provides some useful insights. I hope to order a PCB or two (examples below) to test this method more thoroughly in the near future.

Cheerful regards, Mike, K8LH

Thanks for your response, Michael. I recently edited my first post (upthread), and I think this bit you've quoted is new. At any rate the clarity of the post is improved, I hope. And tonight I edited my second post, adding a new drawing.

Sounds good! Keep us posted.

Yeah, it's a whole different world, alright. I'm finding it kind of eerie to have bypassed the EPROM step! I don't miss it, though!

And not only is this new machine easier to bring up. No (E)EPROM also means the design is simpler in some ways -- doesn't need wait-states or address decoding for a xxROM.


You remember that, do you? Yeah, if I get time I wanna test that bootloader, too -- regarding which there are a couple of improvements I haven't posted yet. But it's a different animal, with different strengths and weaknesses. BTW you seem to have forgotten that bootloader uses just three lines from the microcontroller or host (not eleven). It's slower (and it's untested, so far). But it'd allow the use of a really tiny (8-pin DIP?) microcontroller.

Insights, exactly. The "blind loader" is relevant but probably unexpected. It wasn't my intention to hijack the thread.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Some very intriguing ideas here, Michael, especially the part about commands that don't take up any 65xx address space. It means even a tiny system could have an expansive set of commands available.

Conditional branches don't work, because they express their result by conditionally altering PC and conditionally changing what instructions get fetched. But the blind loader (as described so far) sends the same instructions unconditionally.

Maybe that limitation is acceptable, but if not it could be overcome, with hardly any extra hardware. All you need is to sense whether the branch got taken. To do that you could feed address line A0 back to the attached device -- or monitor the timing of SYNC instead. (For '816 I think it'd be sufficient to monitor VPA.)

On some systems this might disturb the I/O devices. But it'd be easy enough to periodically fake a JMP back to a location well away from the I/O. Even the "plain vanilla" loader I proposed might benefit from this. Of course rogue reads won't matter if you're downloading to a system whose I/O hasn't been initialized yet. Also: the I/O devices won't get the rogue reads if you qualify their Chip Select signals with the nOE signal (which is false when they occur).

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Should we start a different thread? Do you think anyone else would be interested in this discussion?


I'd love to try this method for a Tiny-BASIC computer using a CMOS 6504 (below), an 8K RAM, and a 65C51 or 63B50P ACIA. If you need a very small PCB you could place the narrow micro-controller and 8K RAM chips under the wide socketed CPU and ACIA chips.



So far, blind operations are limited to pushing LDA imm, LDA abs, STA abs, and BRA or JMP instructions (that may change as I develop single-step code). All conditional logic is handled in the micro-controller code.

Here's how I do it... The micro-controller disables the address decoder and steps the CPU through a reset cycle. Then it intercepts the reset vector and pushes the address of an unused 16-byte block in I/O address space (see listing excerpt below). Then it enables the address decoder and pushes instructions to the 65C02 in order to identify and then initialize the serial hardware (65C51, 63B50, or 65C22). A BRA instruction at the end of each instruction transaction sequence limits blind operations to that 16-byte block. The micro-controller then pushes instructions necessary to produce an inventory/status screen showing current clock speed setting and I/O address range setting and a timer prompt to either enter the blind monitor or time-out into the blind loader for normal 65C02 operation.

Okay, interesting. We know RAM and other devices mustn't be allowed to drive the bus when fake instructions (and the fake reset vector) are being applied.

With your approach the address decoder is inhibited (and all reads and writes are impossible) while the CPU accepts the fake vector. After that you keep PC pointed into an unused chunk of I/O address space. The decoder is re-enabled, but fake instructions can still be applied because you're in unused space. Cool! Hope I got all that right. It's only those cycles which read or write outside the unused space which "connect" to a real device.

My approach is to let PC go anywhere. Writes always "connect" but reads will or won't, depending on the nOE signal. And I leave nOE false until the RAM loading is complete -- that's what allows the "reading" of fake instructions.

I used 10K resistors, but the value isn't critical. 47K or even 100K would work alright as long as you allow for the RC time constant re charging and discharging the capacitance of the data-bus lines. Values lower than 10K could work, too, but then bus contention current starts to become significant, and there's a risk RAM or other devices on the bus may not be able to produce valid logic levels due to loading from the low-value resistors.

In my setup a CPLD receives a 115.2 kbaud serial signal from a remote host PC and converts the bytes to parallel. The byte-wide parallel output drives the 10K resistors full-time; I don't tri-state the outputs.

The CPLD also accepts serial commands which control single-bit outputs for driving nOE and RESET as well as STEP_CK and STEP / nRUN. There's an external 1.8432 MHz oscillator but the clock circuit is internal; I'm not using an actual 74175 and so on.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yes, there are some differences between our loader methods. I eliminate the resistors on the data bus in favor of enabling or tri-stating that port on the micro-controller. I also clock the CPU directly from the micro-controller manually during loader, single-step, and monitor operations and then I connect one of the micro-controller PWM peripherals to the clock output pin to generate the full speed clock (1/2/4/8-MHz) for normal 65C02 operations. Also, the existing serial port on the 65C02 system is used for both blind monitor (ROM emulator) and normal 65C02 operations.

While my loader can boot-up the 65C02 with a ROM emulator image, it sounds like you need a PC along with your CPLD loader to boot-up and start your 65C02 system? Is that correct?

Both of our methods push 'fake' or 'blind' instructions to the 65C02 which requires knowing what's expected during each cycle of an instruction, without having to drive 16 address lines. I believe this is a significant advantage for reducing the amount of hardware required in a RAM-only system. And, while it could easily be used to provide a full featured monitor for something like a 3-chip OSI-300 type system (65C02, 65SC32, micro-controller, keypad, and LCD), I'm not sure it's worth the effort for a 128-byte RAM system when all you have to do is add a 64K RAM chip for a much more capable system.

What's really exciting (to me) is that the 11-pin 'blind' interface might be implemented on a little $5 Pi Zero which could (after 'blind' operations) provide 'bare metal' file system and 'bare metal' terminal functions (keyboard & video) via serial port interface. Imagine a 1/2/4/8 MHz system complete with USB keyboard, HDMI video, and SDcard file system that fits in the palm or your hand using little more than a Pi Zero, a 65C02 CPU, a 64K/128K RAM chip, a VIA chip, and an ACIA chip...

Food for thought. Cheerful regards, Mike