I've mentioned my 65020 project here a few times in the past. It's finally ready(ish) for release: https://github.com/John-McKenna/65020

The 65020 is an imaginary successor to the 6502, which might have competed with the 68000, but is (mostly) binary compatible with the 6502. It extends the width of each memory location from 8 bits to 16. That means opcodes, which are 8 bits on the 6502, are now 16 bit. Addresses, 16 bits (two locations) on the 6502, are now 32 bit. The three registers A, X, and Y have become 12: A0, A1, A2, A3, X0, X1, X2, X3, Y0, Y1, Y2, Y3. The P, SP, and PC registers are also accessible to many instructions (in particular, PC and SP can be index registers). All registers are 32 bit.

If the top 8 bits of the opcode are all 0, it will behave like the 6502 original: performing 8 bit operations on the low 8 bits of registers, and accessing the low 8 bits of each memory location. The new features are unlocked by setting the top 8 bits (the 'extension') of the opcode to other values.

Taking opcode $6D (ADC abs) as an example: On the 6502, this adds the contents of an 8 bit memory location to the 8 bit A register, along with the C flag. For this instruction the format of the opcode extension is PAAZZZDD. If P is 1, the instruction becomes ADD: add without carry. AA selects which of the four A registers is used: A0, A1, A2, or A3. ZZZ selects one of 8 index registers. Here the default is P (processor status), which always reads as 0 when used as an index. The other options are Z, SP, PC, or one of the four Y registers. Finally, DD selects the data width: 8, 16, or 32 bits. The 8 and 16 bit options read the operand from a single memory location. 32 bit reads from two.

32 bit values are stored in an unusual way. The low 8 bits of the first location form the low 8 bits of the operand. The low 8 bits of the second location are the next 8 bits of the operand. Then comes the high 8 bits of the first location, and finally the high 8 bits of the second. If the two memory locations contain AABB and CCDD, the resulting number is CCAADDBB. This is to keep compatibility with 16 bit addresses used by the 6502: if the top 8 bits of each location are 0, the result will be a 16 bit value.

The 65020 re-interprets some of the 6502's instructions to make them more general. In the above example, a non-indexed addressing mode becomes indexed, with an index of 0. Bits in the opcode extension can be used to select other index registers, giving Y, SP, and PC as possible index registers on previously non-indexed instructions.

A more drastic example of re-interpretation is the CLC, CLD, CLI, and CLV instructions. Each of these clears a different bit of the P register. The opcode extension gives each a choice of 8 bits to clear, in any of the 16 registers. Between them they form the CBT (Clear BiT) instruction, which can clear any bit of any register. CBT is also given an indexed addressing mode (with 32 bit base register) for clearing bits in memory. Finally, if the top bit of the opcode extension is set, CBT becomes TBT, which sets the Z flag according to the state of the bit. Similarly, SEC, SED, SEI, and SEV (which didn't exist on the 6502) combine to make the SBT instruction, which becomes XBT (toggle bit) if its top bit is set.

The TAX, TXA, TAY, ... instructions have gone through a similar extension, together allowing any register to be copied to any other register.

A few other instructions use the top bit of the extension to provide a different operation. LSR becomes ASR (arithmetic shift right), which duplicates the high bit instead of shifting in 0. ASL becomes ESL, which duplicates the low bit. ROR and ROL become RRB and RLB, which shift within the 8, 16, or 32 bit word (the bit shifted out still goes into the C flag, but the bit shifted in comes from the other end of the operand). All of these can shift by any number of bits, and the shift amount can be given in a register.

Branch instructions get a lot of new options. In addition to 8 new conditions (including 'always'), they can select a short (16 bit) or long (32 bit) offset, any register as the base (including P, which is read as 0), a 'link' bit which tells it to push the current PC before branching (giving conditional JSR instructions), and finally an 'indirect' bit.

New versions of the arithmetic and logic instructions have been added which work on the X and Y registers. And there are versions that take another register as the second operand. These are small (1 memory location) and fast (1 cycle).


The implementation is in VHDL, and intended for the Spartan 6 FPGA. It uses a number of Spartan 6 primitives, and would need a bit of work to re-target to another family. No attention has been paid to speed: I wanted something that worked first. I don't even know how fast it will run, as the system it was created for is limited to 5MHz for other reasons. I have a few sketch-plans for a pipelined 65030 that would allow significantly higher clock speeds. But that's in the future.


Included is a MicrocodeBuilder which is used to generate the ROMs for 'microcode' and 'nanocode'. These names come from a very early design. 'Microcode' is more like instruction decoding, providing information about the instruction that applies on all cycles of its operation. 'Nanocode' is what is usually called microcode. It controls what happens on each cycle.


And there is the assembler. It has grown with the CPU, and isn't very pretty. Error handling is particularly weak. But it works. Labels can be anything that isn't recognised as an instruction, and can be followed by an optional :. The syntax of instructions is as given in 65020.pdf.

Expressions can contain the binary operators + (add) - (subtract) * (multiply) / (divide) % (remainder) ^ (bitwise xor) & (bitwise and) | (bitwise or) << (shift left) >> (shift right) < > <= >= == != (comparisions, producing 1 for true and 0 for false) and unary operators < (high byte - bits 8 to 15) > (low byte) - (negate) and ~ (bitwise not). The 'high byte' and 'low byte' operators are for assembling old 6502 code.

Numeric literals can be preceded with % for binary or $ for hex. Any other base can be used by putting a number before the $. For example, 8$135 = $5d = %1011101 = 93.

Directives:

.include "<filename>" include the contents of another file.
.byte val, val, "string", val, ... inserts a sequence of 16 bit values as one memory location each. Strings are inserted one character per location, without a terminating 0.
.word val, val, ... inserts a sequence of 16 bit values as two memory locations each. It's mostly for assembling old 6502 code.
.long val, val, ... inserts a sequence of 32 bit values as two memory locations each.
.space n reserves n memory locations without storing data.
.section name starts or resumes a section of output with the given name. Only sections that contain code or .byte/.word/.long data will be placed in the output binary.
.org val sets the assembly address. It can also be written * = val
.if cond
.else
.endif allow conditional assembly. These can be nested.

Sorry, no macros or local labels yet.

Assembler command line options:

-o <filename> write a binary file
-om <filename> write the output in a format suitable for Xilinx's data2mem utility
-i <path> sets the path for .include files
-l <filename> writes a listing file
-x <filename> writes a cross-reference file

I still don't have a comprehensive test suite for any of this, so there will be many bugs. But it has been used to write and run a decent amount of code. I'm finding it a pleasant CPU to use.


Here's some sample code for a 32 bit unsigned integer division routine, taken from the listing file of my main development program


PSH.l A2 is the 6502 PHA instruction, with bits in the extension to say "32 bit" (the .l), and "A2 instead of A0". LDR X0, #32 is just a different way of spelling LDX #32. CMP.l A2, A1 uses a new opcode ($dc) for CMP with another register as operand.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thank you so much for sharing, John ... it looks great, but I'm doing my best to not be envious of your productivity in an area of creativity that has been a brutal struggle for me in recent years with my 65m32.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Very interesting, thanks John.

When you use short addressing, is that zero-extended to form a full address, or is there a base register?

Perhaps related, I'm wondering what you mean by Z in this bit:
> Here the default is P (processor status), which always reads as 0 when used as an index. The other options are Z, SP, PC, or one of the four Y registers

There are several next steps. It was built for my 'C640' computer, an imaginary successor to the Commodore 64, and that still needs a lot of work in both hardware and software. I'd like to get to the point where I can play games on it.

I'd also like to continue development of the CPU itself. I've given no attention to performance on this version, and the maximum clock speed will be limited by the huge amount of logic on the path through the registers and ALU. It would be both interesting and challenging to make it pipelined, and to add a cache. There is also space left in the instruction set for floating point.

And there's a few things I wanted to do on this one but haven't yet: the PSH and PUL instructions (PHA, PLA, etc) are supposed to be able to use any register as their stack pointer. That's not working, as SP has abilities that other registers don't. But it'd be very useful for fast memory copies and fills (PSH can write to two memory locations and update the pointer in 3 cycles). It's also supposed to have multiply and divide instructions.

And of course, documentation. The CPU and assembler need proper manuals.

I should try writing a FORTH for it. I imagine FORTH would appreciate having multiple stacks, and I'm hoping the branch instructions are flexible enough to make an efficient NEXT.


Yes, it's zero-extended. We usually think of the 6502's indexed addressing as a small (8 bit) variable offset from a large (16 bit) fixed base address. Here it's more useful to think of it as a small (16 bit) fixed offset from a large (32 bit) variable pointer. Or since I'm a long way from running out of memory, it can be seen as a 64KW 'zero page'.


Z is the extra register that I keep forgetting exists. A0-3 are registers 0-3, X0-3 are registers 4-7, Y0-3 are registers 8-11. P is register 12, SP is 14, and PC is 15. The gap in the encoding is filled with Z, which can be used as an index, and the source or target of a MOV instruction. But it can't be loaded or stored, and doesn't work with the arithmetic and logic instructions. It might be useful as a "this" pointer in code generated by a compiler for a C++-like language (I'm never going to write a C++ compiler), or maybe a pointer to thread-local variables. None of the code I've written so far uses it.

Edit: on the subject of productivity. It's taken 34 years to get to this point. I think it's about 4 years (maybe 5?) since I started working on it seriously.

I mentioned 65020 to randyhyde although I was unaware of the similarity to barrym95838's 65m32. Indeed, I had to check that barrym95838 wasn't reporting a significantly re-formulated 65m32.

The middle-endian arrangement is extremely clever. For about two days, I considered dropping my own architectural extension and adopting yours. Your solution solves a large number of problems. Most significantly, it allows the address-space to be significantly increased without compromising interrupt cycle time. This solution has eluded me for years.

While the 65020 architecture may be viewed as a byte to word conversion, it may also be viewed as an insertion of hidden bytes *between* each byte of the legacy architecture. If implemented correctly, it averts the necessity for quadruple pointer increments and suchlike. Unlike MC68000, it may be possible to implement 65020 without selectively loading lower portions of a register or selectively reading/writing bytes of a data bus. Most significantly, the middle-endian arrangement may allow a 32 bit operating system to pass a "16 bit" pointer to a legacy application and have the legacy application correctly pass back the "16 bit" pointer without corruption or perform pointer arithmetic within a 16 bit range. I've partially implemented pointer stretching where, for example, library calls can be scaled by a few bits. Pointer doubling would be a significant boon.

I presume that operations such as pointer increment of the middle-endian encoding lead to the 16 bit bus/32 bit register arrangement rather than the obvious choice of a matched bus:register width architecture. Even if I am incorrect here, does any deficiency of the middle-endian format hinder further doublings? In particular, does it hinder further doublings in the target C640? In some applications, a 6502 variant (with 16 bit data bus) in a Commodore 64 (with 16 bit data bus) would surpass a Commodore Amiga 500 (with 16 bit data bus). This is especially true if interrupt response time is critical. However, the latter Amigas had 32 bit data bus and 64 bit PA-RISC system was planned. With a contemporary FPGA, you could easily breeze past the performance limit of an Amiga 3000. However, this may be difficult if you have to work around your own 16 bit quirks.

Either way, it might be desirable to re-arrange your opcode format such that 32 bits are FFFFFFFF FFFFFFFD DPAAZZZZ LLLLLLLL where F represents future expansion and L is the legacy opcode format. This arrangement allows 16 bit extension, 32 bit extension and further extensions. Splitting the data size field across the 16 bit word boundary allows a 16 bit register, 16 bit data bus, 16 bit opcode extension with strict 8/16 bit stateless selection. Although it reduces register size, it adds one bit to your operand field such that any of your 16 registers may be sourced without restriction. Given that you have four accumulators and given that add with carry works across all of them, the restricted case of 16 bit registers is already able to perform 64 bit addition with minor performance penalty. You may find that occasional use of multiple accumulators may be preferable if the architecture may be widened with ease. Actually, you may be interested in my experiment with multiple accumulators where a draft version of 6502 with RegB is extended with details known about the failed 16 bit Atari/Synertek 6516. It is removal of RegB created the xxxxxx11 "illegal" opcodes. I tried putting RegB back. I found symmetric RegA/RegB opcodes to be convenient for utility functions and applications but poor use of the instruction-space in the general case. While it is easy to perform eight ALU operations over eight addressing modes over two accumulators, register transfers and register width extensions don't fit easily into the remainder. This was most easily resolved with a RegB prefix instruction and I believe one of the 6809 variants does something similar. Your wider opcode and your allocation of opcode fields averts all of these problems.

You may gain an additional bit of register indexing by dropping your alt instructions. Be brutal about the best choices - even if it creates asymmetry. For example, it is possible to implement 8 bit ADC with decimal mode and 16 bit ADD without decimal mode. 8 bit ADC allows arbitrary precision arithmetic in binary or decimal while 16 bit ADD works like MC68000. Furthermore, 16 bit carry look ahead incurs less latency than 8 bit decimal adjust. At worst, this arrangement only introduces one multiplexer in the ALU - and one multiplexer for the additional indexed registers.

I investigated the asymmetry of CLV but the corresponding SEV doesn't fit in any obvious place if binary compatibility is required. I appreciate that you've created quite an edifice on top of symmetric flags with clear bit, set bit, test bit and toggle bit for registers. This is very clever but it is far too 8051 for my liking. Ignoring my personal prejudice, your register bit operations may not be used often enough to justify loss of cycle speed. It might be preferable to build upon asymmetric CLV. For example, overloaded CLV may reduce processor privileges.

The one unused permutation of your 2 bit data size field could be used to specify 32 bit float operations. Alternatively, it could be used for saturation arithmetic. The obvious choice for this permutation would be a 64 bit extension. However, it may be easier to implement nested virtualized environments if 64 bit extension can only be specified outside of 32 bit opcode. Specifically, instructions which only use 8 bit data bus/16 bit address-space may be virtualized within 16 bit data bus/32 bit address-space. Both of these may be virtualized with 32 bit data bus/64 bit address-space. Judicious design choices allow all of this to run within 64 bit data bus/128 bit address-space.



The are a large number of unremarkable RISC designs which all implement multiply and divide. As I understand, a notable exception was ARMv1 which had multiply and no divide. Nowadays, multiply is almost universal and we have designs which come with or without divide and modulo as a pair. However, two cycle integer multiply covers most cases, a divmod routine is easy to implement and the loss of performance is minimal if you're doing multi-media. If you want to implement divide in hardware, you may want a divide by zero vector. However, if you want C640 to have any compatibility with Commodore 64, you'll have find somewhere for your divide by zero vector which doesn't clash with the Commodore ABI. You could place additional vectors in $0001FFxx. Or do something horrible with the upper bytes of the vector words. However, for C640, a divmod routine may be preferable.

I advise against 16 registers and I also advise against mapping flags, stack pointer and program counter into a general register file. This design is beneficial for implementing SWEET16 and has been widely propagated in RISC designs but it under-utilizes the instruction-space. It also implicitly assumes that the program, data and stack segments are the same size. Admittedly, it solves many problems. In particular, you may have chosen this option because it simplifies stack relative and program relative addressing. However, if these addressing modes are required infrequently, it may be preferable to overload the TSX opcode such that program counter, call stack, data stack or alt stack may be moved to any instance of RegX prior to abs,X addressing. If you overload TSX to implement program relative and stack relative addressing then you have the option of a completely symmetrical register file with A0, A1, A2, A3, X0, X1, X2, X3, Y0, Y1, Y2, Y3, Z0, Z1, Z2, Z3. Also, it may be desirable to overload PHA, PLA, PHX, PLX, PHY, PLY with bit fields such that four or more registers may be transferred to a specified stack.

As I mentioned to Proxy, I am a great fan of extending 65CE02 abs addressing to abs,Z addressing. If this is applied to 65020, you'd have eight registers which all function like RegY. Actually, if you don't mind some asymmetry, the relatively hidden Z0 could be used as a base address for legacy 8 bit applications.

While 65020 has passing resemblance to 65Org16, 65020 retains *full* binary compatibility by using a data size field. The 65Org16 variants specifically excluded this possibility. This led to, for example, gleeful exploration of TAX from 16 instances of RegA to 16 instances of RegX. Or 16 bit shifts over 16 instances of RegA. Or 16 value increments. These were easy to implement and didn't slow the design significantly. However, with hindsight, a byte/word flag bit might be the most beneficial for further 65Org16 variants. Although, admittedly, that leaves an awkward 7 bits for other purposes.

65020 may have better instruction density than 65Org16 or 65m32. However, empirical tests may find better encodings. This is complicated because multiple bit fields can be split across words. Therefore, bit fields may exist in abbreviated forms across multiple encodings. For example, I found that it is possible to encode 7 bit instructions with two register destinations, 14 bit instructions with eight register destinations and 21 bit instructions with 3-address operands.

Potentially, for 65020 or 65Org16 extensions, 32 bit instructions could encode 3-address multiply accumulate. For example, A0-=A1*A2. Or 32 bit instructions could encode prescale and post-increment. For example, abs,X3++ << 6. Or 32 bit instructions could encode conditional execution. This could be achieved such that restricted encodings work within 16 bits and legacy encodings are 8 bit binary compatible - and none of this precludes a more exotic 64 bit instruction encoding. I presume that prescale and post-increment are relatively unimportant and can be relegated to the 32 bit instruction encoding. However, the addressable size of the register file may be fine balance. I understand that AVR and RISC-V hedge with register file size. It may be acceptable to do likewise. For example, it may be preferable for some or all instructions to source from two choices of four registers and the destination be restricted to two accumulators. This may be relaxed in longer encodings. The exact choices require profiling and this may be a long process.

I like to be wowwed but in this case, I've been dazzled with 16 bit data bus, full downward compatibility (which potentially includes cycle accurate interrupt response), very original byte ordering and huge potential for future expansion. I look forward to further development, especially C640.

barrym95838 and John West: Have you considered collaborating? I think you'd make a good team. John West may be further ahead with FPGA implementation but barrym95838 may have considered Forth and C compilers in more detail. barrym95838 is quite particular about opcode naming but is otherwise quite agreeable. Actually, I quite agree about naming. If you're going to build a house then make sure that all of your bricks are the same size. (And we've all seen barrym95838's house.)

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

OOF! In my current circumstances, I would be an agreeable weight tied to the waist of anyone swimming to reach the goal.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

barrym95838: I would not have mentioned this publicly if I did not think it was easily within your ability. After reading through the 6502 Forum archive in full, it is apparent to me that your considerable talents often fall outside of the scope of 6502. Of particular note, you exceed most 6502 Forum members with C programming and Unix administration. You are also very adept with vehicle maintenance. I presume you have many other skills which you practice to a high caliber. Within the scope of 6502 extensions, your recent contribution regarding 65m32, Forth, program stack and data stack is exquisite.

I am under the impression that 8/32 bit source compatible 65m32 is snagged on two issues. The first is downwardly compatible flags. I believe this can be resolved with appropriate handling of Z flag, one tier of multiplexers on the NV flags and this omits no cases. The second case is relative addressing. It would be most useful to make PC relative signed and all other cases unsigned. I mention this within 65020 discussion because many of the design decisions for 65m32 can be applied to 65020.

65m32 has more regular instructions by breaking binary compatibility and the wider bus provides superior interrupt performance. However, 65020 is fairly regular, is never cycle inferior to 6502 and the binary compatibility is intriguing.

Assuming that John West seeks any additional contributors, I hope that it allows John West to spend more time working on peripherals. For example, yet another VIC-II extension with 16*16 pixel tiles and extended tile numbers would be very welcome.

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

Some days things just don't go to plan.

I've continued working on the larger project that the 65020 is part of, and recently hit the best bug I've seen for a long time.

When you write some code and it doesn't work, it's usually best to assume that there's a mistake in the code you just wrote. And in this case there was. The 65020 extends the 6502's set of conditional branches to include conditions for the full set of <, <=, >, and >= on both signed and unsigned numbers. I was using a signed condition after comparing two unsigned numbers, and it wasn't working.

The two numbers were relatively small, so the signed comparison should have still worked. And switching to the unsigned comparison didn't fix it.

In investigating the problem, I discovered that the assembler didn't recognise one of the branch instructions (it turns out I'd never used it in any of my test code), and emitted the wrong opcodes for a couple of others. So I fixed that, and it still didn't work.

It turned out there was a further bug in the microcode sequencer, which was evaluating the conditions for a couple of branches incorrectly. So I fixed that, and it still didn't work.

The signed condition that I was using uses the V flag, and although that was being generated correctly for addition, the method I used didn't work for subtract or compare. So I fixed that, and it still didn't work.

Then I noticed that the CMP instruction wasn't setting the V flag. That's because the microcode that I'd written for it a long time ago didn't request that the V flag be set. And that's because the 6502 (whose behaviour I was copying) doesn't set V after a CMP. So I broke that (it's one more minor incompatibility), and finally my code worked.

AIUI, flipping the high bits of both operands before comparing has the useful effect of turning unsigned branches into signed branches without involving the V flag, but this strategy can really muck up the works when you're trying to mix and match those modes.

@Sheep64: you are far too generous with your praise, but I humbly thank you for the kind sentiment.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

That's an excellent collection of bugs and fixes John! I think these kinds of stories are very educational - we can learn from each other. And entertaining too!

and now we get to the actual 'producing a chip' part... wth is 'super-q the wafer' ? or a 'morning machine' and where to buy one and where does one even obtain 'virgin wafers' or all those chemicals in larger quantities hmm. think it's simply time to make a good offer on texas instruments or microchip inc. with everything that's in it. and move it over to our facilities. see the part that is often overlooked by computer people... is that microchips. are more of a chemical industry product... than a 'computer thing'. don't so much see the urge to make a 16 bit version of it all... do see the urge to bring a wide selection of military/space rated 6502 based products -and- their up to date auxiliary chips (network and video controllers mostly) on the market. in the usual 5 volt dip fully static sos-cmos -45 to +125C rated proven-to-work-forever quality (none of that rohs or smd nonsense) it does not have to be a 'c64' (in fact, preferably not. the c64 is a pretty messy design that doesn't scale or modify very easily but the problem is not the hooking the logic gates together part in a drawing.. the problem is actually producing the thing. without resorting to lame (and unreliable, both mechanically, electrically and supplier dependancy wise) things like programmable grid arrays. cleaning out one of our buildings, sealing it completely off, etc is one part. chips don't seem to like dirt. the place has to be clean. ok... but then what machines to buy and what to put in it

for a 16 bit 6502... would not it be wiser to simply take the 65c816 and just give it more pins (no more time multiplexed busses, just put it in a dip 80 package there. true 16 bit. retaining full compatibility with everything. still 8 bit opcodes and parameters capable. (kinda like the 8088 also has the 8086. same thing. without all the additional pain. (although that still has a time multiplexed data and address bus like everything intel has see that part is not the hard part... 'i want 5 million of them by next week' is the hard part. would not even know what machines to search for on alibaba other than that it seems to involve a lot of regulated temperature ovens 'baking' stuff all the time at weird temperatures for defined times (but then again, a 16 bit accumulator and registers don't do much for most things we'd put them in anyway... hardware encryption engines and such are of more use. and 8 bit optimized network controllers) the 8 bit 6502 is just fine. it should not do 'too much' or it gets hacked again anyway. (like happens with pc's all of the time the nice part of the 6502 is that you can pretty much nail it down to just the few things it should do. and nothing else. no virusses. no finfisher. and that it then nicely does what it's supposed to do for 50-60 years in a row before needing replacement or maintenance. besides that a 14 mhz 6502 already outperforms a 68000 or in fact, most other cpu cores running at the same speed by a factor 2.5 or so. 32 bit processors and such are all nice and well if your network address size and checksum size just so happen to be 32 bit too. and offer no advantages on any other activity than that in fact they are usually slower (than their native 8/16 bit counterparts) when they have to do things byte by byte instead (see the packet headers maybe containing some 32 bit fields which maybe even are 32 bit offset aligned, doesn't imply the payload is 32 bit aligned too to move it around and process it . which is 'most stuff'.

I've just noticed it's exactly two years since your initial post on 65020, which, btw, is a great project and - as mentioned in some comments - an actual implementation of what some here thought about, but never managed to go with as far as you. Have you been working on it recently and - if so - what's the current state? I see no new commits on GH...

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?