You might have noticed a general theme of unification in my recent messages. This includes Feature Tests, Project Mossberg: 65C02 Simulator On 6501 or Clock Stretching Beyond Five Cycles.

I love various aspects of the 6502 processor design. The 63 regular opcodes, the 88 irregular opcodes and the numerous extensions are composable in unexpected ways. The discipline to design a processor which uses alternate bus cycles is beyond my grasp but wholly welcome. Designs around 6502 processors are also unexpectedly varied. But, BUT, BUT, designs around a processor often lack the composability found within processor. In particular, choice of major features is often restricted to one or maybe two choices from a long list.

For example, processor agnostic systems don't tend to have video. Video, DMA or dual core are often mutually exclusive choices (and anything beyond dual core is vanishingly rare). Dual core, clock stretching and page banking are often mutually exclusive. Even within clock stretching, a restricted ratio made 16MHz systems mutually exclusive with 6522. And, am I the only one to consider 70MHz FPGA with Apple card bus, Acorn 1MHz bus or Planck Bus?

I have worked to collapse these cases into a lesser number of cases. I encourage others to do likewise. We are very unlikely to reduce everything to one case. Regardless, partial success has compounding network effects. Likewise, I don't expect every doohickey to be present on every system but I hope that people cross previous barriers - or have the confidence to make design decisions knowing that they have not excluded others. To aid this process, I published a negative result regarding expansion ports. Expansion ports are needlessly considered in detail. BigDumbDinosaur shows that expansion can be retro-fitted, as required. Likewise, plasmo's work with VGA6448 confirms that any RAM socket (or processor socket) is an expansion socket. Please continue this theme.

Unfortunately, I am astounded by the level of incompatibility between 65C02 and 65C816 systems - despite them being broadly socket compatible. For 65C816 systems, it is mostly restricted to extra opcodes and wider registers. Some of these choices are unavoidable. Others work with fall-backs. Many people have investigated the merits of mode bits versus prefix instructions. Some have also investigated the merits of memory mapped mode registers or a second accumulator. However, only one of these options is immediately available from your local component distributor. Use it or lose it.

For the 65C02 hardware hacks, it takes a peculiar talent to break compatibility with a binary, cycle and socket compatible upgrade. Dr Jefyll has shown that a surprising amount of 65816 functionality may be back-ported to 65C02 and that minimal hardware is required to make bespoke instructions for niche applications. (Video drawing might be a suitable niche.) However, I am concerned that other people mis-apply this pioneering work to obtain quick wins. If possible, make designs 65C02/65C816 agnostic because, ridiculously, it is becoming easier to make designs which are 6502/6809 agnostic.

In a world where an executable may also be a PDF and 32 bit applications run on 64 bit operating systems, we are unable to run the same binary console application on the same processor across two ABIs - even when the full set of required system calls is GETCHR, PUTCHR, LOAD and SAVE. drogon has multiple applications running across multiple ABIs - but only if the ABI is specified in advance. This can be generalized.

One application which only uses GETCHR, PUTCHR, LOAD and SAVE is EhBASIC. People may think that BASIC on 6502 is a dis-service and Microsoft BASIC particularly so. Regardless, EhBASIC has been a unifying effort. In particular, it is binary compatible with Microsoft BASIC, floating point performance is faster and more accurate, expression evaluation is faster, it has the very natty feature that interrupt handling can be written in BASIC and it works on 6502 variants without decimal mode. Yes, it has bugs but the general principle is a reduction of mutually exclusive cases. Just don't ask about EhBASIC's license. That's a *huge* mutual exclusion.

Suggestions for a common memory map and I/O range have been ongoing for decades. However, I find systems such as Z80 CP/M and Z80 Pascal to be frighteningly conformist and I definitely don't want a standard memory map with standard I/O to access a standard filing system via standard device drivers written in a standard high level language with standard indentation and a standard variable naming convention. If I want that type of experience, I'll pursue accountancy. Or Linux kernel maintenance. Regardless, I believe there is room for something more similar to MSX or LSB minus the vendor interference. Experimentation and non-conformity is encouraged and the best ideas will be recommended. It won't be too prescriptive. It'll be more like "A Level 4 system has zero or more 65SIB ports." You may already have a Level 4 system! Likewise, you may already have a Terbium system!

When I see Ben Eater's acolytes using GARTHWILSON's designs, when I see active user groups around legacy platforms, when I see drogon and cbmeeks exploring ersatz designs, when I see contemporary microcontrollers, when I consider designs beyond 30MHz, I see a common theme. It is possible to make a system which works for the first time hobbyist following a video tutorial, has a modicum of compatibility with legacy systems, works on a W65C265 microcontroller and offers the possibility of multi core beyond 30MHz. It works with or without page banking. It works with or without a privilege system. It works with 65C02 or 65C816. It works with or without keyboard and screen. It works with or without sound. It works with optional legacy hardware support. It works as a single tasking console system or possibly a multi tasking windowing system. And it is likely to run EhBASIC and Acorn BASIC. Apologies in advance.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!