Here is a thought.

I have a few DILDAR boards (http://forum.6502.org/viewtopic.php?f=10&t=2638) still available for US $20.

I am thinking about programing them to act as a 65Org16 'chip', if there is any interest.

These boards can be easily wire-wrapped or soldered down (the pins are on 0.1" grid).

ON-BOARD HARDWARE
65Org16 core
1K x16 stack memory (top of page $0001). Code can be loaded here.
1K x16 boot rom (top of page $FFFF)
2K x16 RAM somewhere else (OPEN ISSUE)
UART (might as well have it)
SD card SPI port (?)
Address decoders generating external select signals for IO or RAM chips

PINOUT
CLK (normally crystal output, but may be jumpered to be clock input)
32 address lines (maybe 24 is enough)
16 data lines
WRITE
2 UART lines
4 SD card SPI (a possibility)
A few pre-decoded RAM or IO select lines

There are a few open issues. The main one is whether anyone is interested in messing around with a raw 65Org16 chip. Perhaps a 65Org16 system with some RAM like CHOCHI is more interesting. Or perhaps no one cares about this at all?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Great idea! It will give us an idea of how much interest there is in 65Org16. What you describe is both a "chip" and a minimal system, ready to go once you hook up a serial connection.

I would suggest hanging around for a little bit to get ideas and feedback - although you may well reject many of both, at least it may help converge on the best set of things to do.

How to place the 4 RAM blocks of 1 k-word each is a bit interesting. It's not much RAM, so making the most of it seems attractive. I'm tempted to say, offer one of two schemes and use an input pin/jumper to select - the pin can have an internal pullup or pulldown so a no-connect will be a valid choice.
- Option 1: One contiguous block of 4kwords, repeated endlessly throughout the memory map, with just the i/o ports overlaid. Maximum flexibility and simplicity.
- Option 2: One block assigned to page 1 for stack, the other 3 blocks repeated endlessly but not in page 1. An overlay for the i/o ports, and another overlay of a tiny distributed ram for the top 6 words - the vectors. Memory will look like 3k populated then 1k unpopulated, all the way from 0 to ffffffff.

External RAM should be mapped in at 0, repeated all the way up memory, overlaid by the i/o ports and the internal RAMs in one of the above options. So, for example, with external RAM and option 2, you'd have some fast zero page, some fast stack, and the rest of zero page and stack falls through to slower external memory.

Speaking of external RAM, I'm pretty sure you'll need
- RDY input to stall the clock for external access

It might be worth building a little internal shift register and offer an internal RDY-generating circuit to give 1, 2, 4, 8 cycles of access time to the external RAM.

If you do offer any facility to hook up external RAM, it would be good to see what experiments you've tried and with exactly which RAMs - whatever you get working, a close copy would be a good bet for anyone but an expert.

Hooking up to Garth's RAM module would be nice!

Cheers
Ed

BigEd, many good points. This thread is very much to see who wants what, so please contribute your ideas, everyone. Any sensible ideas will be considered.

Deciding on whether it's a minimal system or a micropricessor has been an issue. I think something like a microcontroller (with some common peripherals) that can stand alone, but with an external address/data buses and some pre-decoded IO/RAM selects seems like a solution that could work for everyone.

I haven't even thought of using LUTRAMs for the vector space. That is a strong possibility.

BigEd, your RAM layout looks promising. I need to think of how to mux the data bus in a way that would allow external RAM to be added without interfering with the BRAM and IO.

I am away from my lab and don't remeber what 65Org16 offers in terms of RDY signal, but sure, any important signals must be wired out.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Just reading the Xilinx app note on distributed RAM I notice
- you can initialise this RAM to some contents, just as with block RAMs
- if you want ROM instead of RAM you have twice as many bits available

If the bootstrap loader, or the monitor, are small enough to fit into distributed ROM, that could free up a block memory for RAM. (I think a few hundred words of ROM might be available.)

About the vectors: we do need 6 words at the top of memory, but they could be ROM. In fact, they could point into zero page - we have so much zero page that losing a few words is no issue, and we run so fast that a few cycles for a JMP is hardly worth worrying about. In fact, the bootstrap could even be placed in zero page. At power-up it is automatically in place, and then after loading a user program the memory can be re-used if needed.

I'm torn between putting the bootstrap into ROM, so it can't be damaged, and putting it in RAM, so it can be patched, upgraded or extended. A compromise would be to have a write-protect bit, controlled by an I/O location or even by a jumper.

But this is starting to look like feature creep!

Cheers
Ed

You can also pre-init the block RAM. You could put a small bootstrap loader in the stack space, and after it's done, it could be overwritten by the user application.

Good point.
In a 65org16 system with very little memory, the stack is quite awkward. You'd like to put as little RAM there as you can get away with. I'm not sure whether or not to worry about keeping the stack memory separate from other memory. If it's not a worry, then Option 1 is fine.

It's nice to have the bootloader be either read-only or at least really out of the way of normal code. That way you can reset back to the bootloader. In an earlier CHOCHI bitstream I put the bootloader into page 0 without thinking too much, and was sorry right away....

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I wonder if there's a useful difference between a bootloader (run once at powerup) and a monitor (can return to it to debug your program or load a new version)
Some kind of write-protect would help to keep the monitor intact. The top of page 0 might be a good place for it - or the top of memory. It probably doesn't matter much, but I like the idea of having the remainder of memory being a big contiguous chunk. The nice thing about the bottom of page 0 is that it will always be populated, and unambiguously. With a 64k page 0 space, and with nearly 4k populated, a few hundred words for a minimal monitor should be affordable. (I see Daryl's monitor is just under 1k.)

Without any actual 65Org16 experience (except for blinking an LED), I would think the code density is much higher. Doing simple 16-bit pointer math and counting took up most of the CHOCHI loader's 120 bytes (no attempt to make it really small was made).

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I don't know, but it seems to me that you wind up with roughly twice the capability per clock for the same number of instructions (which are twice as wide). I think that it would be more difficult to get the same capability in 1/2 of the instructions. If you want a program that takes full advantage of the wider 'bytes', it will probably not be more space-efficient than the '02, just more capable. Where the advantage comes into play is when translating 16-bit address programs to 'Org16, and keeping them 16-bit address for compatibility reasons. That's where the 'Org16 would shine, like in a translation of Woz' Integer BASIC interpreter or SWEET16 interpreter that remains 16-bits and keeps everything in 64K 'bytes', since everything would be in zero-page, and all variables and registers would each fit in a single 'byte'.

Mike

I still haven't given up on my idea of a 6502-compatible 16-bit processor... But all in good time.

In the meantime, I placed an order for a DILDAR-compatible 'shield' for a 64K x 16 SRAM:

As per Garth's advice back in the 6502 Playground days, the layout is compatible with 256K x 16 SRAMS. I currently don't have any of these, but I have a number of ISI61LV6416 chips. These are 12ns, and I am very curious about how they will stack up against the CHOCHI's 10ns SRAMS. I imagine it will be close, and I am hoping for a 40MHz 65Org16 system.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Oh yeah? You guys know that the core you're speaking of has the original 8bit 6502 accumulators/registers right?
And that some work and troubleshooting in a real hardware system has been put into another chapter of this core that has 16 accumulators and another indirect register identical to Y?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I don't express myself as well as I would like, but I was trying (without actually translating any code) to speculate on how many instruction bits it would take them to do the same thing. Naturally, the 'Org16 throws away half of its op-code bits, so it's not really a fair comparison. I'm assuming that the 16-accumulator version does useful things with these extra op-code bits, and that could give it a significant advantage.

Of course, efficient translation of '02 code to that machine would be more of an effort, at least for me, because my old brain doesn't think that way. Jeff and I were talking privately about the advantages of more registers, and I agreed that they're nice, but also pointed out that they change the look-and-feel into something that doesn't work like '02 code anymore.

The translation of MS-BASIC from the 8080 to the 6502 is an example of a 'translation' that worked more efficiently than the original, because the person(s) involved in that translation didn't really do it instruction-for-instruction or subroutine-for-subroutine, but rather started almost from scratch, composing new code that did the same thing, but took better advantage of the 6502's unique qualities. I don't have that gift, so I am much more likely to code and translate 6502-style for the rest of my days, because that is how I learned to speak 'machine' many years ago. Changing the width of a 'byte' or register doesn't really change the coding style, but adding a bunch of registers does, at least IMO.

If you can link me to your 16-accumulator design, I'd love to read about it, but I don't know if I would ever be comfortable coding for it, not because I don't think that it's cool (I'm sure that it is), but due to my own personal limitations.

Mike

Hold on there, 65org16 has 16 bit registers, not 8 bit accumulator/registers.

The other chapter of this core that you are using is a fantastic effort. I will definitely take a look at it in very near future. I don't know how big it is and whether it would fit into an XC3S50. I also would like to get my hands a little dirty with the plain 65Org16 core first.

I have mixed feelings (well, actually somewhat negative feelings) about having a lot of registers, being a Forth nut. With many registers, you wind up stacking/unstacking a whole bunch of registers every time you spit. I know for a fact that I truly hated programming the ARM chips. A stack machine is probably more my speed.

Anyway, let's not get excited about any of this. We are all in this together

What I was saying at is that even throwing away the top instruction byte, being able to count and increment 16-bit pointers should make the code a lot smaller and easier.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Extra registers are cheap, because they're implemented using 16->1 LUT RAM. So, you basically get 16 registers for the price of 1. All you need is a few extra wires from the opcode to the address input of the RAM.