6502.org

I was very active in the 65xx world up until the Apple // GS finally died off. Made a couple pilgrimages to WDC. Talked to Bill Mensch quite a bit about what should happen after the 65c816. About the time the 65c832 faded off into oblivion, I finally gave up and switch to Intel PCs and Macs. Even had a National Semiconductor NS32532 I built way back then (PC532:https://en.wikipedia.org/wiki/PC532).

Every now and then I dig out my // GS, start it up. Think "holy cow this is slow." and put it away for a few years.

All the time I kept thinking, "gee, what if there was a better 65xx instruction set to play with."

Though I've messed around with ARM assembly language (the "spiritual successor to the 6502" as I like to call it), it was just a lot of work and never as much fun as 6502 (or even x86, for that matter).

I kept thinking "wouldn't it be nice to have something that falls somewhere between an Atmel and an ARM running on an Arduino class board? (No, RISC-V isn't it). Something that has compact code (unlike the ARM) and a bit more oomph than the AVR. So I thought back to the 6502 days again and decided to play (a very popular, it seems) mind game: designing my on instruction set based on the 6502.

Well, after several hours' work, I banged it out. Thought I'd share it with this group.
Now I've just got to grab one of those Sparkfun/Alchitry FPGAs and see if it's possible implement any part of it.

https://www.randallhyde.com/FunProjects ... 65000.html

Cheer,
Randy Hyde

That slowness was intentional on Apple's part.

Welcome, Professor Hyde! I have admired your work for many years, and look forward to the possibility of seeing you become a regular poster here.

TLDR;

Attached is an Excel spreadsheet with the instruction set description and encoding.
A little more compact for those who don't want to go through the whole web page I put up. Also, this one has lots of updates (haven't adjusted the web page yet--working on it).

Cheers,
Randy Hyde

Well, I'm going to (at the very least) write an interpreter and simple assembler for this thing. So I'll be around a bit to provide updates on that. Would love to get a little emulator running on a Teensy 4.x or Raspberry Pi Pico for use as an embedded controller, just to see how it works out (shoe-horning on the Teensy might be a bit of work with only 256K RAM; the 65000 needs 128K for the code and data spaces). The Teensy 4.x runs at 600 MHz, so the performance would be much more respectable than the Pi Pico).

Cheers,
Randy Hyde

There's a not-too-much-work way to get a really nice macro assembler for a processor of your own design, and that is Cross-32 (C32 for short), originally from Universal Cross Assemblers, now being sold by Data Sync Engineering and by MPEforth. It's $99, and for the one price you get an assembler that works for dozens of processors, and they tell you how to adapt it to new ones. Supposedly it would take about 40 hours.

A little off topic...

Some work done to upgrade an Apple IIgs/65c816 with a 65c832 but not completed:

https://wiki.reactivemicro.com/GSBarnDoor

Cheers,
Andy

p.s. a warm Welcome Mr. Hyde!

Welcome, Randy, and congratulations on a substantial invention and document.

If all works out as you hope, that'll be a machine with a similar feel to the 6502, much more orthogonal, supporting at least byte and two-byte datatypes, possibly also larger ones, and with only a modest increase in code size.

A common tactic these days is to write an emulator in a high-productivity language of choice (maybe python, or golang, or javascript) to explore the running of microbenchmarks and to see what might be missing or superfluous. (This is probably what you mean by an interpreter...) As soon as you have that, you realise how useful it would be to have an assembler.

Anyhow, I very much look forward to updates!

Instead of BULE and BUGT, may I suggest stealing BLS and BHI from the 6800?

There are at least 10 groups who have proposed a 32 bit extension or larger. This would include 65k, 65000, 65020, 65GZ032, 65Org32, 65832, 65E4, 65m02 and tentative steps separately from Proxy and I to extend 65CE02. It is apparent that many of the proposals have common themes and they typically lean towards TMS9900 by instruction encoding, registers or both. Indeed, we should establish a taxonomy of extension proposals. Ignoring that, your proposal is possibly the most similar to mine. Your proposal differs from mine by emphasising access to zero page. Your proposal also has hints of simplified 65E4. I believe that your proposal might benefit from the Hudson T flag, although, by graph coloring, there is diminishing return when a 3-address machine has more than six symmetric registers.

About six months ago, I proposed atomic instructions without much success. After reading the forum archive in full and creating a shockingly similar duplicate (compare grid processing diagrams from BigEd and I), it is apparent to me that there is a general preference for CSP rather than SMP. This is especially true for the Acorn enthusiasts who have made some exotic heterogeneous systems. Ignoring that, forum experts are disproportionately hardware hackers and are strongly empirical. A sticking point for my own development is the hard deadline of 500ns (seven clock cycles at 14MHz) to push state and begin interrupt execution. You can add as many modes and registers as you like. You can include atomic instructions, integer division or FPU. You can implement with any arbitrary technology. However, if your design incurs more latency or jitter than it is inferior to a shipping product and unsuitable for known use cases. It would also be extremely beneficial if any implementation used less than 100,000 gates (30 times more than the original) and can be packaged for rugged deployment.

I strongly agree that an Arduino class device is desirable and especially so after recently reading of success with MCL65+. We are both less keen about FPGA. However, if you pursue this path, your design must exceed 50MHz otherwise it will be inferior to existing choices. Indeed, it is quite easy to make an 8 bit design which exceeds 50MHz. However, the frequency predictably drops as the design grows. Most predictably, distances double or worse when gates quadruple. There is also the under-appreciated problem that binary addition is, at best, O(log2 n) for n bit registers. Adding more than three numbers may also be a problem. It is for this reason that I recommend avoiding arbitrary segment offsets.

I cannot find any significant problems with the technical details of your proposal.

Some people strongly dislike mnemonics of differing lengths but this is easily rectified.

You might want to provide operand sizes which are binary and/or Fibonacci length. Specifically, 0, 1, 2, 3, 4, 5 and 8 byte.

You might want to scale zero page locations to register width. This would make your design very competitive for running Forth, running Java or rendering PDF. It would also utilize more bits in the instruction stream if zero page locations do not overlap - or at least do not overlap more than historical levels.

I am impressed that you do not add user registers but instead improve connectivity of existing resources.

I am particularly impressed by the originality of applying UTF-8 style encoding to branch offsets. I considered and rejected BER encoding which is much the same thing but with the extension flags spread over each byte. Each encoding has advantages and disadvantages. Bunched flags may be preferable for software implementation. Spread flags may be preferable for micro-coded implementation. However, bunched flags may also be preferable for more advanced hardware implementations. White Flame is the expert for seven bit encodings and may have considered this in much greater detail.

The real power of 6502 is the no prefix, one byte operand, impure load/store architecture where one operand may be sourced from eight or more places, where a load may be overloaded with six ALU functions and all of this may be intermixed with a smattering of irregular instructions. This would appear to make read-modify-write instructions mostly redundant. However, definitely don't remove read-modify-write instructions. Yes, they go against good design. Yes, they're lousy for IPC. However, they are very good for arbitrary precision counters, arbitrary precision bit rotation and bit mixing.

Some people with similar designs suggest removing zp,X. Definitely don't suggest this. If device driver authors don't stab you over the Internet then Forth enthusiasts will. Substitutions are acceptable if they range strictly from neutral to positive. For example, I suggested replacing the absolute addressing mode with abs,Z. However, multiple guarantees to clear Z make it 100% downward compatible.

I strongly recommend Arduino for implementation. It is suitable for testing ideas in a concise and accessible manner which may be easily replicated. Efficient representation of 8/16/24/32 bit values will be challenging on all targets. Thankfully, this would be a minor consideration if you start with 600MHz MCL65+ as the basis for your work.

I wonder if a big part of that is that the IIGS's interrupt system is so bloated.  It seems like every time an interrupt hits, they made it run up a cycle count that rivals the national debt.

(For those who might not have recognised the name, Randy is notable enough to have a Wikipedia page.)

As Sheep64 notes, this forum does have a few people with an interest in new instruction set architectures, and a few offerings or ideas have come to various degrees of fruition, but the majority here tend to work at the level of boards and systems. Hence the commentary picking up on the offhand comment about the IIgs.

Anyhow, it's nice to have another proposal written up - hopefully it will be taken through the stages of emulator, assembler, benchmarks, perhaps HDL code.

To quote from Randy's page linked above: It's a good point: my own adventures in this area concentrated very much on minimal effort, and as a consequence we got low code density and a minimal step forward, but we did get to running code on FPGA. The more energetic and enthusiastic you are, the more ambitious you can afford to be. Oh, and you need free time too!

We're a year on from the head post - let's hope for good things!

Yeah, when I saw your 65Org16 design I smiled and thought "Ed put a top hat and fancy coat on Arlet's Mona Lisa!" Amen! Hope springs eternal.

Perhaps I should expand on what I was thinking here.

Although the Apple management (I think Jobs was gone by then, so it wasn't him) held the IIGS clock speed down so it wouldn't make the new Macs look bad (as BDD alluded to, above), I didn't particularly think of the machine as a whole as being terribly slow—after all, its clock speed was still nearly three times that of '02-based Apple II's, and for anything frequently dealing with 16-bit numbers, the '816 is quite a lot more efficient, meaning the IIGS should be, let's say, four to eight times the speed of the IIe, if the '816 is allowed to run, in native mode, software written to take advantage of its strengths.  randyhyde started the topic off with wondering how a better instruction set would do.  So the goal of my brief comment was to get the mental gears turning by leading to questions like:

• Where is the real bottleneck?  Will the envisioned instructions fix that?
• If the bottleneck really is in the way interrupts are serviced, can changing just a few things go a long way in remedying that, rather than starting over on the instruction set?

When I present what I think is a complicated problem in need of a complicated solution, it's a relief when someone points out that there's a shorter route to the solution, and I don't have to find a way to get over that rugged mountain I was looking at.  It has happened quite a few times.  One might think it's off-topic; but it is nevertheless helpful in a way that totally staying on-topic might not have been.