Another *really* off the wall idea: a discrete processor using some sort of fast ram for the microcode/pal/sequencer logic and using a chain of 8153s to program the microcode - it could be different processors on different days. You might also use a couple of fast rams for the ALU - Digikey has hundreds of fast cheap parallel ram chips with better than 20ns access times, and could be faster than discrete logic. It's unlikely to be as fast as e.g. the ideas being explored in the discrete ALU thread, but a processor running at several MHz should be possible.

Neil

Cool idea! I doubt the designers of the 74lv8153 anticipated this application, but there's no reason the chip should be confined to merely driving LEDs, solenoids and relays!

There are purpose-built chips specifically for initializing a Writeable Control Store. For example, the CY29FCT818T -- apparently an update of the 80's-vintage AM29818; see datasheet attached -- is still an active product. It incorporates various functions in addition to the serial interface, but the '8153 is smaller and probably easier to obtain -- also easier to drive, as it understands async and it needs no clock.

And, besides the Control Store, it's a good point that RAM could also be the basis for an ALU (to look up results rather than compute them). And I suspect it's an idea that could approach the speed of ideas being explored in the discrete ALU thread. Last time I looked (and it's been a while), some of those parallel ram chips you mention had access times of less than 10 ns.

-- Jeff

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

I've used eeproms as ALU slices in homebrew micros previously but the limiting factors were memory size and speed - around 32kB and 250ns at the time.

A 16 function ALU with eight bit inputs and a carry input needs 256*256*16*2 (2^21 = 2MB) bytes but 11 outputs - the 8-bit result and carry, zero, and sign outputs (though sign could simply be the output top bit) so a 2M * 16 part would work. I used smaller parts to build a 4+4 bit input with two carry inputs (one for normal use, one to allow left shift) and so each only needed 7 outputs and fits nicely into a 16kB eeprom.

The disadvantage with the smaller part is that it needs the output from the carry on the first ALU before the second can finish adding up. So two access times in series. A bigger (32kB) part can take the zero out from the first one and avoid external logic. I have a vague idea though that no matter how I wanted to have two identical parts there was some reason why this didn't work.

Neil

a RAM based ALU seems pretty doable. 512kx8 ICs are very common, cheap, and fast (usually 10-20ns).
Parallel Flash would also be an option, 55-70ns is not that bad if you aim for single digit MHz speeds. (plus while you don't need to preload Flash, you could still make it in-system-programmable via the 8153)

using 2x SRAM ICs in parallel to form a single 512kx16 chip (19 Inputs, 16 outputs) allows for a very basic 8 function ALU (Add, Subtract, Shift Left, Shift Right, AND, OR, XOR, Negate) with 2x 8-bit inputs, a 3-bit function selector, 1x 8-bit output, and up to 8 output flags. (i'd go with the basic Zero, Carry, Negative, oVerflow, and Signed Flags).
(the "Sign Flag" is from AVR and is just N XOR V, which makes some branches easier)

which should be more than enough functionality for a basic discrete Processor. main downside is that you have no carry input for rotates, Add/Subtract with Carry.
so those would have to be done in software or via special instructions.

alternatively, if you add 2 more 512kx8 Chips to get 1Mx16 (20 Inputs, 16 outputs) you can fit another selector bit, which can be used a pseudo Carry input when the selected function is Add, Subtract, Shift Left, or Shift Right. in which case the upper bit is used the carry input. but for all other functions the upper bit is just another selector bit, giving you the carry functionality as well as 4 additional slots for new functions.
in my case i added 8x8-bit Unsigned Multiplication and Division (which are very fast single cycle operations because there is no logic to run, only Memory to read from).

here an image of the described "2MB ALU" i built in Logisim, including a counter and some RAM components that were used to generate the binary files that could be written to Flash/RAM chips to implement it in a real circuit. (flags are described at the top, and selector bits at the bottom)

also it uses the 3 unused flags for basic input comparisons. no idea if it would be useful, but if you got extra bits you might as well use them.

The snag with big memories used in this way, of course, is that for all practical purposes they _have_ to be non-volatile. Even though with a bit of thought you can write very wide memories with the 5813, you're still sending a lot of bits at only 20kbs, and a lot lower once you add the addressing overhead. It'll take an awfully long time to fill a couple of megabytes. Probably not helpful if you want to load an entire microcode: maybe fifty bits by 32k or so, and moreso if you want to load an ALU (easier with two small ALUs).

It's an issue I've had with SBCs since the seventies: if you want something other than what came in the box, you need to reprogram the eproms that came with it. So a UV eraser and a programmer; it's not conducive to a one-line change, recompile, and test methodology. And with any memory other than DIP a socket is generally impractical, so it needs to be programmed in situ. And the 6502 needs parallel memory... hence this approach, which is the closest I've come to something along the lines of AVR, PIC, or ARM controllers.

I appreciate that the 6502 (and friends of a similar age) is a computer, not a controller, but it would be really nice if it could work in a similar way to load software. Option (a) is the method discussed in my recent neolithic romless thread, using the 5813 - it's volatile at the moment but there are ways that could be resolved. Option (b) is the neolithic romless STM approach (or similar) using a more powerful processor primarily as a boot loader - restricted to a single program at present but could select from a small repertoire held in flash or even external SPI flash. Option (c) of course is a small boot loader, either from eprom or a method like (a) or (b) above, with an external system providing the actual run files. Issues might be handling the reset/interrupt vectors, but they're surmountable. Option (d) would use an on-board but externally programmable (SPI) chip to hold the boot code or OS. Getting the code out the SPI chip and into ram runs into the same problem; you need something in place before you get there. One point: most SPI memory will rely on a single command (0x03) to start reading, with a couple of bytes of setup. I've kicked around a few ideas there but not resolved anything yet; the main issues are starting as expected and finishing and transferring control when loaded.

No doubt there are other approaches that I haven't thought of yet. My basic desire is to be able to load once and run often, which (b) does out of the box, but at the moment with restricted choice, and (a) does if non-volatile ram is used.

Still thinking about it...

Neil

Good discussion of various ways to bootstrap 6502 and the desired flexibility to change/update the flash. My approaches to rapidly changing/updating operating environments are
1., bootstrap from parallel loader (FT245) to program the on-board flash, then change mode to boot from the flash. This approach is simple enough not to require programmable logic. This is a combination of your option a) and b).
2., The second approach (if you can stomach CPLD) is having a small bootstrap in CPLD that loads and runs whatever is in the master boot record of the CF disk. This way, different operating environment is possible by inserting different CF disks. However, the CPLD does require an external programmer, but it only need to be programmed one time. This is like your option c) except CF disk is integral part of the SBC working as the mass storage device.

I have not tried option d) in 6502 environment, but did have a bootstrap serial eprom for a 68000 SBC so I don’t have to deal with space requirement and reprogramming hassle of 16-bit boot flashes.
Bill

The 74LV8153 certainly is an interesting chip. Thank you for bringing it to our attention, Jeff. I also like your idea of using an '8153 to load a set of 74HC574's and I wonder if the timing would support loading them in cascade?

Hi, Michael. Nice idea! And I don't see any problem in regard to timing.

I like how this setup doesn't need any logic to individually address each of the 574's! On the downside, you will of course be obliged to send a full, 16-bit address every time, whereas with individual addressing you'd typically be able to increase speed by omitting the update to ADH 255 out of 256 times. But, depending on circumstances and priorities, this minor disadvantage may be deemed unimportant.

-- Jeff

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

Good points, Jeff. Thanks.

<Slightly off-topic, but...> is there a listing or data book somewhere describing the 'LV8000 series chips? I came across the 74LV8154 "dual 16 bit binary counter" IC a few years ago which, like the '8153, is also quite intriguing (to me) and now I wonder what other interesting ICs may be in this series.

Sticking "74lv8" into the search box on TI's website yields the following:

Shift Left, Shift Right, and Negate only require one operand + Carry. Frees B to select of 256 Subfunctions.
Moving them all to one function frees a pair of dual operand tables for 6502 Decimal mode Add and Subtract.
AND, OR , XOR can ignore Carry or let it select of three other functions. Perhaps DIVide, MODulo, NOR.
May want a circuit to override or invert raw Carry input. Sometimes a Carry flag, sometimes a Fn select.

Have fun figuring use for all of B's alternate subfunctions.
Every conceivable shift and rotate, not limited to 6502 style.
Converting back and forth between signed and 2's comp.
Reversing 76543210 to 01234567
Copy or swap any two bits within a byte + Carry.
Count all the ones, count all the zeros.
Count only leading or trailing ones or zeros.
Note frequencies (half wavelength at color burst).
Fonts. Quartersquares for multiplication. Cosines.
Subs that don't ref Carry might host yet another subsub.
And not my complete list by a longshot...
Most don't merit a unique instruction, but allow lookup programmatically.