65org16 Interest

ElEctric_EyE · Post by **ElEctric_EyE** » Fri Nov 04, 2011 7:50 pm

Maybe a 40-pin DIP connector in addition for a 6502 core shouldn't be to hard, so it would be multipurpose? Choose 65Org16 or 6502 cores for different future/existing app's? One would have to reprogram the FPGA of course.

Dr Jefyll · Post by **Dr Jefyll** » Sat Nov 05, 2011 7:16 am

BigEd wrote:

The code may not be as freely parameterisable as the verilog is [...]

Nice work, there, lads. At first I didn't quite realize that you had made the CPU width parameterisable.

ElEctric_EyE wrote:

Maybe [...] it would be multipurpose? Choose 65Org16 or 6502 cores for different future/existing app's?

Good idea!

GARTHWILSON wrote:

Is 9-bit-wide memory available in the easiest-to-use types (SRAM and ROMs)? I doubt it.

I stand corrected about the 9-bit memories; indeed they are quite rare (except for dual-port RAMs and FIFOs, for some reason). Maybe it was 9-bit DRAM modules which I recall being not-so-uncommon once upon a time.

GARTHWILSON wrote:

Going in multiples of 8 makes better use of available memory types.

Quite right. Or you could use a set of three 4-bit-wide devices for your 65Org12. But nowadays 4-bit devices are also fairly rare.

Of course you also need some sort of ROM to boot from. In that regard I think a single 8-bit wide device may be adequate even for a 12- or 16-bit processor. You'd use a tri-state buffer (or logic in the FPGA) to put zeros on the high databus bits, and use the ROM to drive the low 8 databus bits. This would yield impaired functionality -- 6502 instructions only, and awkward limitations on operands -- but even under these conditions the boot loader in ROM could copy system code from ROM over to 16-bit RAM, where it could thereafter run without restrictions.

-- Jeff

BigEd · Post by **BigEd** » Sat Nov 05, 2011 7:23 am

Memory modules come in widths such as 36, 72 and 144 to support parity and ECC - that can be abused. In fact, for large memory systems, memory modules may make more sense than soldering up lots of memory chips.

Edit: also, if you needed 8 memory chips, you could use 9 instead, if you take the power cost of clocking all of them for each access. And so on, for various values of 9.

The smallest useful machine might be a 65Org06, I think: 6-bit words and a 4k memory space. 2 (or 3) tag bits for whatever ingenious purpose you like!

Edit: oops, 65Org06 might have trouble packing in the opcodes!

Cheers
Ed

Dr Jefyll · Post by **Dr Jefyll** » Sat Nov 05, 2011 7:29 am

G' morning, Ed! 65Org06, eh? I was wondering about that myself...

BigEd wrote:

we can multiplex with the databus if we have to

Multiplexing is a good solution in some cases, despite the slight delay and the PCB real estate for the external address latch.

Worth mentioning -- and this applies to 65c816 as well as 65Org16 -- is that, with multiplexing, your hardware design needs special attention regarding the ability of memory and IO devices to (slowly) assert and (quickly) release the data bus. I don't recall any mention of this on the forum, so perhaps a note is in order.

With an ordinary 6502, bus-enable timing is very forgiving. There's no threat of the CPU and memory both trying to drive the bus at the same time. That's because there's some built-in dead time between transactions. Ie; during phase one in a properly-built system the memory and the CPU both tri-state the data bus. But multiplexing a la '816 means that the CPU drives the bus during phase one. Phase two (if it is a Read cycle) requires memory to drive the bus; then it's immediately the CPU's turn again for the following phase one. This is a tricky sequence to execute smoothly.

To avoid knocking heads with the CPU, the memory and IO devices should ideally assert the bus slightly after phase two has begun -- and must instantly release it when phase two ends. Otherwise there'll be a few nanoseconds during which the CPU and memory both drive the bus, leading to excessive supply current and ugly issues with noise and ringing.

-- Jeff

BigEd · Post by **BigEd** » Sat Nov 05, 2011 7:32 am

On the topic of using an 8-bit ROM in a wider system: I like it! If one could arrange for the top bit to be connected, either instead of bit 7, or as well, that would allow for negative operands. Changing the opcodes on the verilog side wouldn't be too hard, if necessary - again, the assemblers might be a tricky case.

But, at least a bootstrap ROM is so easy to place on the FPGA, that's probably the way to go: it can load and repack a second-stage image from narrow external ROM into wide RAM. And on-FPGA, width isn't an issue.

Cheers
Ed

Arlet · Post by **Arlet** » Sat Nov 05, 2011 8:12 am

Dr Jefyll wrote:

Worth mentioning -- and this applies to 65c816 as well as 65Org16 -- is that, with multiplexing, your hardware design needs special attention regarding the ability of memory and IO devices to (slowly) assert and (quickly) release the data bus. I don't recall any mention of this on the forum, so perhaps a note is in order.

Actually, the 65Org16 (and my 6502 core it is derived from) doesn't use the old 2-phase clocking mechanism.

There is only a single, positive edge triggered, clock.

BigEd · Post by **BigEd** » Sat Nov 05, 2011 8:27 am

Yes, I've been aware when I've mentioned multiplexing, that I've supposed either that your core can be pressed into a two-phase (or double-clocked) mode, or that a T65(*) could be ported and substituted. (Transforming your core into a parameterisable one was as straightforward as could be wished, so I'm optimistic, or over-optimistic, that another core could similarly be transformed, if there was ever a reason to do so.)

But in fact, it's only any 40-pin limitation which would force us towards multiplexing. And we get 22 address pins before that: 4 Mword. Using a 48-pin DIL footprint might be an easier path - that's a 30-bit address space.

Cheers
Ed

(*) I'm also supposing here that the T65 might be more amenable to multiplexing - I've no particular reason, except perhaps that it aims to be cycle accurate. Could one just put a multiplexing layer around the core? (I'm not intending to do this, it's just a thought.)

Arlet · Post by **Arlet** » Sat Nov 05, 2011 10:15 am

I don't think there's any need for a two phase clock when using standard peripherals. It's only needed when you would like to plug in the core as a 6502 replacement in an old circuit board. When designing a new board, a single clock works just as well (or even better). It just takes a different approach to designing things, so it's something to keep in mind.

Arlet · Post by **Arlet** » Sat Nov 05, 2011 11:47 am

BigEd wrote:

But, at least a bootstrap ROM is so easy to place on the FPGA, that's probably the way to go: it can load and repack a second-stage image from narrow external ROM into wide RAM. And on-FPGA, width isn't an issue.

It's also possible to attach an external EEPROM/Flash with I2C or SPI interface, and have the FPGA copy the data to RAM .

Some FPGAs can even load their configuration bitstream from ordinary serial flash chips. After the FPGA is configured and running, the interface pins turn into user I/O pins, so you could access the device from the core. That way, you only need to put a single (large enough) flash device on the board.

If you don't mind the slow speed, you could even execute code directly from serial memory.

fachat · Post by **fachat** » Sat Nov 05, 2011 12:56 pm

BigEd wrote:

I don't think so - it's just like the move to 16-bit bytes really, you just have to make the mental adjustment that a 'page' is a different size to what you thought it was. There are still two halves to an address. (Anywhere you count up to 8 will need adjusting, and rotates might need consideration.)

Just that your code becomes (binary) incompatible between 65orgXX versions.
Re-assembling the source with an assembler should fix that though, so the code could be source-compatible

André