Zero glue logic 6502 SBC?

[BigEd]

Oh there's certainly a point in continuing: it's a puzzle, it's constrained engineering. Many builds, surely have used a single logic chip. No challenge left in that.

As you say, the ROM (seems to) need active select. Although there just might be a way around that. This may not be a puzzle which falls out immediately.

[Martin A]

Is this workable for a rom select?

Use a port pin 65C21 or 65C22 with a weak pull down. Both chips reset all pins to inputs, so the pull down generates a rom select.

The rom then copies part of itself to ram and jumps there where the code sets the pin to output high overriding the pull down.

[GARTHWILSON]

Martin A wrote:

Is this workable for a rom select?

Use a port pin 65C21 or 65C22 with a weak pull down. Both chips reset all pins to inputs, so the pull down generates a rom select.

The rom then copies part of itself to ram and jumps there where the code sets the pin to output high overriding the pull down.

Writing to RAM and then to I/O to override the pull-down resistor requires that the ROM let go of the bus. Wouldn't you still need some other logic to do that? Oh, how 'bout this: You put resistors in series with the ROM's data outputs, so the outputs only have effect if nothing else is driving the bus. (But then you would have to slow the clock way down for that, again needing more logic. Also, the resistors will take as much board space as a 14- or 16-pin IC, so you're definitely not saving any board space or assembly labor.)

[BigEd]

My feeling is that ROM has to occupy only the top 32k of space, to leave some room for I/O. Maybe only the top 16k. As ever, RAM has to occupy the bottom 16k of space, or less. Which leaves the range $4000-$7FFF for I/O, if there's any way to arrange that, or possibly $8000-$BFFF. But temporary mappings involving passive components might be a solution, somehow.

[cjs]

Martin A wrote:

Is this workable for a rom select?

Thank you for repeating that; I guess more than one person had missed that when I proposed it earlier.

GARTHWILSON wrote:

Writing to RAM and then to I/O to override the pull-down resistor requires that the ROM let go of the bus.

I don't think it does if you ensure that, for the address to which you're writing, the ROM contains the same data you're writing to the PIA.

(And yes, this is indeed getting deep into "clever tricks for the sake of clever tricks" territory. But it's fun to play with such ideas, I think.)

[plasmo]

I was greedy; I want RAM to own the entire memory space except where I/O is mapped. But if RAM is active only in the lower half of the 64K memory, the problem simplifies significantly. In the scenario where RAM is 0x0-0x7FFF and I/O occupies some or all of the top half, I can connect the output of a reset supervisor to enable ROM and disable I/O for brief amount of time after reset, enough time to copy ROM to RAM. If a reset supervisor is consider "cheating", it can be replaced with an "ignition button". Press & hold the ignition as power is applied; ROM is active and the same ignition button output also disable the I/O. ROM is programmed such that top 32K is same as the bottom 32K, so ROM copies its top half to RAM and jumps to RAM waiting for ignition button to release. There are no data contention because ROM output is same as RAM output.

Regarding the interrupt vector at the top of the memory. If I/O is mapped to top of the memory and provides consistent output that maps to RAM, all is well. The I/O mapping probably can be shuffled so the data read at top of memory is 0x0, or even better, a slightly different values depending on the internal state of the I/O--a poor-man's vectored interrupt.

If I/O is not enabled at the top of the memory, then 8 resistors can pull up and pull down the data bus to provide an interrupt vector.

Seems like we may have a working solution for zero-glue 6502.
Bill

[BigEd]

Ah, using the human operator to deliver a long time constant - nice!

[Martin A]

If you use a 128k ram like the AS6C1008 where write enable overrides output enable, then output enable can be connected to another I/O pin, but with a pull up on it.

The pull up will prevent the ram outputting until the port is set to output. if the rom enable is set high in the same change that ram output enable set low, there would be no contention.

Can the resistors be overridden fast enough to stop a glitch affecting the following instruction ?

As mentioned before PHI on the active high CE2 would avoid write glitches, read/write on write enable pin would override the output enable if required. A15 as the active low CE would keep the ram from interferring with IO.

Because it has 3 selects, mutliple 65C21's could be present in the 32 to 48k area using A14 (low cs), A15(high cs) and one of the A3 to A13 address lines. A14 on the low CS keeps then out of the way at reset.

[Chromatix]

If you have a "front panel" then you can technically do away with the ROM, entering the bootstrap code and reset vector by hand into a full-address-space RAM.

To do this without logic chips requires 16 SPDT switches to select address, another 8 for data input, yet another one to control the RDY signal (halt the CPU), a large handful of Schottky diodes to avoid shorting address and data lines together via the energising buses, and finally a pushbutton to simultaneously drop out BE, haul R/W low and energise the switches. A second pushbutton may suffice as a Reset signal.

I/O can then be provided through a VIA, which has multiple chip-select lines, or possibly through a UART. The RAM's data lines should be fed through a 1K resistor array so that the VIA can override it from the CPU's perspective.

It all seems like a lot of effort just to avoid using a few jellybeans.

[BigEd]

That's the OSI 300 in a nutshell! It does have logic chips, but they are not glue: either buffers or peripherals.
http://retro.hansotten.nl/6502-sbc/osi-300-trainer/
See also viewtopic.php?f=3&t=3558

[plasmo]

An interesting aspect of the zero-glue 6502 is it can be quite fast using fast RAM and W65C21/22. It can certainly run to 20MHz and likely quite a bit beyond. Building the fastest ever 6502 is worthy of bragging right in its own, but I have a specific frequency in mind: 25.275MHz which I think is realistic with zero-glue 6502. That opens up the possibility of 6502 as a VGA controller which may be an interesting topic.

ROM probably can't run to 25.275MHz, but I know I have programmable divided-by-N oscillator whose frequency can be changed with inputs. The same scheme to load ROM into RAM can also change the clock frequency lower to allow proper ROM operation at lower clock frequency.
Bill

[Michael]

While not "zero glue" logic, I have thought about implementing a sort of 'shadow ROM' idea like yours on a '6303 system design where the /RD signal is routed through half of a '139. The idea is to read ROM and write RAM at startup in order to copy ROM into RAM and then turn off ROM. Of course the '6303 has the advantage of some built-in I/O lines.

Regards, Mike

[Michael]

As for zero glue logic... If I replace the ROM chip with a boot loader / rom emulator chip on a 64K RAM design, might that be worth an "atta boy"?

[plasmo]

Atta boy.

Having said that, I wonder whether there are lowly "retro" single-chip microcontroller to assist the more powerful retro processor? 8051 family has quite a number of single-chip microcontrollers as well as 680x. Just don't want the assistant to outshine the 6502...

[Sheep64]

BigDumbDinosaur on Thu 14 Jan 2021 wrote:

To me the question would be "What's the point?"

I found this to be a very helpful exercise. Of my viable attempts, the doodles look like transistor versions of the Garth Wilson Special NAND gate address decode. For this, I've learned that there might be borderline cases where transistors are more suitable for address decode than a 74x00.

BigEd on Sat 16 Jan 2021 wrote:

ROM (seems to) need active select.

What is the consequence of vectors being absent? If the data bus is pulled high then all vectors load program counter with $FFFF which then executes opcode $FF. This conflates all of the vectors and incurs interrupt latency but it allows ROM select on A15. Unfortunately, this prevents read/write access to page $00 and page $01. Although is may be trivial to move base page and stack on 6502 variants, the conflated vectors make interrupts indistinguishable from reset. This may not be useful in the general case.

I also considered particularly nasty memory maps in which A5, A6, A7 provide differing combinations of ROM select, RAM select and I/O select. Without bus contention, this provides a maximum of 32 bytes ROM, 32 bytes RAM and 32 byte I/O on every page. I presume someone will see that as a programming challenge. However, I could not find a method to get such a system into a stable state.