6502.org

After three days of experimenting, I have a W65C02 running NOP opcodes. I have achieved this without using a multi-meter or oscilloscope. Indeed, I used a 15W soldering iron, two pairs of pliers, two breadboards, four prototyping boards of no more than 5cm*7cm, telco wire found in street, plumbing solder, about 100 LEDs (really) and a fake Arduino as an LED tester but primarily used as a USB power connector. It runs (crawls?) from a USD2 18650 lithium battery and 5V boost circuit. It uses a 16MHz ceramic resonator connected to one NAND gate and - for testing - uses chains of binary counters and indicator lights of my own devising. I call this Project Snail for many reasons:

• All the good names, like Kestrel, Foenix and Ruby are taken.
• I should have made this a long time ago.
• It runs at 16MHz divided by 256 (62.5kHz) and this may be further reduced if I have to use one the toy USD20 20kHz oscilloscopes.
• It may be expanded to include an optical boot disk. In this case, it'll have a round thing on its back.

The story so far:

• I spent six hours making indicator lights. This was a good re-introduction to soldering after a long absence.
• I spent two hours stripping wire and making chains of binary counters on a breadboard.
• I spent less than five minutes fixing an oscillator circuit.
• I spent a further three hours soldering binary counters to prototype boards.
• I spent about five minutes making variations of oscillator circuits.
• I spent about 15 minutes wondering if I destroyed a W65C02. (Answer: no.)

After two days of breadboarding, I had an LED blinking at slightly less than 1Hz. (16MHz divided by 2^24.) I had also made about 22 idiot-proofed indicator lights, two boards of binary counters. At one point, I had 19 logic chips and 14 sets of indicator lights running with 22pF of decoupling. However, this strains the battery and the lights noticeably dip in unison. That was a good place to pause.

The following day, I removed most of the counter chips from the breadboard and allocated the space for a W65C02. People buying bootleg 6502s are missing the experience of unpacking the genu-wine article. It does not have the gaudy in-your-face branding of Intel but the packaging has an understated class which is rarely mentioned on the 6502 forum.

The following description is not a good example of the art. The following is a "don't touch it - it's doing something" example of the art. My first attempt at getting NOPs was to wire power and ground. I then wired various control signals directly to power. (I know this is definitely wrong but, sometimes, it helps to actually do it wrong and confirm it for yourself. The alternative is to live on superstition and rumor.) I set opcode $69 (ADC#) rather than the standard $EA (NOP) due to the dead cycle which causes NOPping to progress through address-space at half the expected speed. I placed indicator lights on high address lines and powered up. Unfortunately, nothing worked. In particular, my debug boards, constructed a mere day before, both appeared to stop working. There was working power. There was a working oscillator. The first eight bits of the chain of binary counters worked. However, nothing beyond that appeared to work. Well, that's unlikely and that part of the reason why I made multiple debug boards.

I quickly resolved the first problem. I had inadvertently made a chain of eight 4 bit counters. 16Mhz divided by 2^32 will tick very slowly and superficially appears not to work. Placing the 2^24 divider further upstream restored the slightly slower than 1Hz blink of an indicator light. However, I did not obtain a matching blink from the 2^8 division of two counter chips followed by the 2^16 division of a 6502 program counter. At this point, I thought that maybe all that stuff about pull-up resistors might be relevant. After searching through my meager spares I found a 10k resistor. Just one. This led to an idea which should definitely make the experts wince. I connected the control lines on the left side (NMI, IRQ, RDY) via one common pull-up resistor. As I was moving the reset wire on the live circuit, it started working! I initially thought that it was due to mains hum and it only worked when my fingers provided capacitance.

The current configuration (which should not be replicated) has RES, NMI, IRQ and RDY all tied high via one common resistor. BE and SO are tied directly to power. There is no reset circuit. The oscillator is intermittent. I know this is terrible but it is steadily improving. It is also apparent that a lack of components is the limiting factor. Regardless, the current configuration has been sufficient to confirm that $69 (ADC#) cycles through the address-space and double speed compared to $EA (NOP) because the immediate instruction doesn't have a dead cycle.

Obviously, the circuit requires an oscillator module and a reset module. For reset, I purchased a Maxim MCP101, as used in the Gigatron design. Perhaps I should have purchased a Dallas Semiconductors DS1813, although given the heritage of Dallas and Maxim, they are possibly the same thing.

I also require a simple mechanism to get more than 8 bits of program into the system. Therefore, I am concurrently pursuing a computer with no ROM and a computer with no RAM. I intend to keep a NOP opcode behind a 74HC245 or similar. In addition to providing debug, it is also a hook for NOP slide video generation. This can be used concurrently with a hook in the binary counter debug board which can be used for clock stretching.

I enclose a draft circuit diagram which differs significantly from implementation and neither are good examples. I usually publish more formal diagrams but I've been too busy implementing. I hope that a doodle in the style of Forrest Mims, Garth Wilson and Donald Alcock is sufficient.

I end with a message to the lurkers and newbies. So far, my efforts with 6502 hardware are approximately the slowest and least reliable ever mentioned on the 6502 forum. Your oscillator might be a little slower. Your soldering might be a little worse. You might take an extra day or two to get this far. Maybe you get stuck somewhere. However, one thing is quite certain. If you have six pull-up resistors around the value of 2.7-3.3k, a reset thing, an oscillator module and a 6502 from a reputable source then you'll be ahead of me on your first attempt.

Excellent!

And I keep telling myself that as I don't have the test equipment to tell me that my Ruby system isn't working, it must work...
So... given your name here, I propose Shaun ...

(See https://en.wikipedia.org/wiki/Shaun_the_Sheep if not familiar)
Your works though - that's what counts.

Here is a suggestion - you're using a 7404, a crystal and 2 capacitors to make the oscillator... It's good, "classic" and seems to work for you. I decided that I'd opt for a can oscillator from day 1. One DIP-8 sized chip. Might be more expensive (marginally), but it's one less thing to worry about.

You get bonus points for the fuse too.

Cheers,

-Gordon

In your oscillator there's one inverter whose input is floating in terms of DC. This could easily explain the intermittent operation. The crystal does not provide a DC path. There needs to be a high-value resistor to supply input bias for a case like this.

You could try putting a large ( >= 1 MOhm) resistor from the inverter output to its input. This will cause the DC voltage to settle around 50% of Vcc, which is the linear region of the input stage. Ordinarily you'd *avoid* letting an input hover around 50%, but it's an unusual situation because the inverter is being used as a linear amplifier -- not the 'HC04's usual function!

Or, reconfigure the oscillator according to the second attachment (below). Also attached: a 74HCU04 datasheet; this chip is particularly relevant to linear operation, including oscillators. A web search with the terms 74HCU04 and oscillator will surely reveal more detailed info.

BTW, the manner in which you've cascaded the counters isn't entirely appropriate. That's because when the counter increments its Carry output may glitch briefly before assuming a valid state. Check the datasheet to see the proper technique. Carry ought to feed the next stage's Enable input (not Clock). Cheers,

Jeff

Firstly, don't trust anything you read on the Intertubes. I have moderate difficulty with physical constants and arithmetic (most often in more familiar decimal). Adjust your expectations accordingly.

Secondly, thank you for help, especially to GARTHWILSON, Dr Jefyll and, less obviously, BigEd who makes a convincing argument to pursue hardware bug fixing as a distinct practice to software bug fixing. I remain astounded that I was one resistor short of a reliable circuit. I might have solved this eventually by following circuit diagrams more closely. Thank you for saving me from moderate frustration.

I have subsequently devised an unconventional oscillator arrangement, surveyed seven of the dodgiest NMOS 6502 suppliers which I could find on aliexpress (my favorite being the IC chip quality+++ Store selling the obviously legitimate and trustworthy 1pcs Mos 6502 MOS6502 6502AD R65C02AP MOS-6502 DIP-40 Can be purchased directly) and wrote assembly while waiting for components to arrive.

Much more to follow.

GARTHWILSON: It occurred to me almost immediately after publication that I might be out by a factor of 10. I thought "Hopefully, one of the amateur radio enthusiasts corrects it. Otherwise, one of the pedants will jump on it." 6502 assembly programming requires a certain level of pedantry. Therefore, we're never short of pedants. I am far too gracious to mention the details but it is re-assuring to know that more prominent members of the 6502 Forum incur similar problems. (Note to lurkers: Figures cited on the 6502 Forum may be off by a factor of 2, 3, 4, 5, 8, 10, 16, 100 or 1000. Apart from that, figures are usually quite accurate.)

Dr Jefyll: I remain astounded that I omitted one resistor. I really should follow circuit diagrams more closely before "innovating" - and by "innovating" I mean repeating work which has been well known for 30 years. Due to my consistent failure to buy a canned oscillator and my fatigue with 555/556 circuits, I found myself in a situation where I hoped that I could make an energy saving oscillator. Specifically, I hoped to get a DS1813/MCP101 reset thingy to control a P-channel FET and selectively remove the kickstart resistor from a crystal oscillator circuit. This led to a futile attempt to place resistors and capacitors in every permutation to power or ground while steadfastly ignoring the series resistor which is quite clearly shown in multiple circuit diagrams.

drogon: Shawn the Sheep is a legend among cartoon sheep. Off screen, he's a great guy. More seriously, apart from watching a few episodes of Rex the Runt, it appears that I've missed the majority of Aardman Animation and haven't seen any film since Chicken Run (which was a relative dud with poor characters). I really hadn't considered sheep project names. However, I have used planet names for filing systems and horse breeds for search indexes.

--

I strongly considered making a vaguely educational series where I bootstrapped from a NOP test to a 256 byte 6502 system. 64 byte RAM, two I/O ports and 64 byte ROM may be implemented with one half of a 74HC139 for read/write qualification and the other half for address decode. This is more than enough to implement a digital LED mood light. Or a serial port echo test. Or demonstrate functionality of various opcodes. Or principles such as subroutines. However, I understand that The Plagurist has largely covered this with a SAP-1 derivative.

Progress on Project Snail has been unironically slow. However, this has been due to loss of confidence. I've struggled with circuit design. I've spent almost 40 hours on one project with mixed results and at least 160 hours on further projects. I'm working through a small list of analog projects that I've wanted to complete for decades. I'm also working on decorative designs. For example, our sales-sheep have the fanciest business cards in Sheepville.

It has otherwise been draining. I am concerned that my metrics for success are skewed. This itself indicates a lack of aptitude and expertise. One of the many bizarre subplots in Catch 22 is that the generals in the war are more concerned with bombing formations rather than hitting any strategic target. When I concern myself with pads per square inch or vias per chip but my designs don't work, I wonder if I'm a foolhardy armchair general.

There is a directly relevant anecdote involving 6502. When Steve Wozniak was designing an early Apple product, Steve Jobs wanted the chips and the connectors to be aligned in a grid. One revision had the required grid but it was unreliable and quickly abandoned. Worryingly, Steve Jobs never gave up with this requirement. An Apple iMac from 2010 or so has a straight line of connectors. I have no doubt that Steve Jobs would have asked for the components to be similarly aligned.

You may regard alignment as a case of premature optimization. However, I've had the opposite case where a design failed because it was wonky. It is very disheartening to design a PCB for a 24 bit pulse counter, get it manufactured and then find that it doesn't work because the design is mis-aligned. There is, perhaps, a survivor bias, but this problem doesn't seem to be widespread. Perhaps people fail quietly and pursue other interests. I very much like Radical Brad's advice to treat electronics like a wild animal and show dominance. Radical Brad appears to be an outlier and some people wrongly assume claims are false. However, if you look closely, there is a large amount of fastidiousness. The infamous 30 breadboard video blitter has a real aluminum ground plane and a rectangular grid of power distribution which approximates resistance on an infinite plane. The high frequency circuitry is in the middle of the boards where the physics are most favorable. Radical Brad also spends hours ensuring that wires meet specific requirements. They are stripped in a particular manner, tinned in a particular manner and wire of a particular length is orientated in a particular manner. Is this excessive? Possibly, but it works.

Perhaps I am looking too far ahead but I am my own customer and I don't want to fix bad hardware in software. Many of the deficiencies in computing are due to failures being someone else's problem:-

• Hardware bugs require devive driver workarounds.
• Kernels glom together device drivers with no separation of concerns.
• Kernel bugs require application workarounds.
• Application deficiencies require endless updates, consultancy fees or bodges from power users.

When I'm trying to fix deficiencies and there is a closed loop of responsibility, I'm not going to make a stack of bodges. I hoped that circuit design would consist of studying the documentation, creating a design, having the design manufactured and then assembling the components. Due to the long lead times, I hoped that it would be more formal than REPL programming - that type of programming where something is bodged through a BASIC interpreter or the modern equivalent. Y'know, the type of fragile, brittle programming which is often followed by "Works for me!"

I thought that I was quite profligate to have up to four batches of design in transit. However, I now work with printed circuits which are mostly correct and are vastly more likely to work than random wires in a breadboard. If I have five or more boards and the wiring is 98% accurate, that may save one week of work. It isn't quite "proof-reading after publication" but the distinction is sutble. Or possibly an illusion.

I've proposed various schemes over 1.5 years and the most relevant to hardware are:-

• Morse Code - The Debug Protocol Of Champions
• 65816 EMU Pin and WS2812B Digital LEDs
• Apple II Like Memory Mapping
• 65816 Banks Half Filled With RAM For Symmetric Decode
• Clock Stretching Beyond Five Cycles
• Interrupt Priority Encoding
• 65816 /ABORT Pin As General Purpose Interrupt
• Cell Network Hardware which covers I2C and SPI.
• Extra large keyboard for SNES input peripheral protocol.
• Enclosures For 6502 Desktop Computers

Project Snail is where this stream of ideas is assembled. I am most influenced by the memory maps of Apple, Commodore, Acorn, the Commander X16 project and W65C265. Initially, I hoped to implement a 3*16KB bank window scheme which extended beyond 16MB RAM, was 6502/65816 compatible while also simplifying application ports from the majority of legacy systems. Furthermore, early drafts of Project Snail (doodled in OpenOffice Draw) have chip stacked latches. However, I was disheartened that I was wilfully mis-quoted in this matter and I considered other pursuits permanently.

By relaxing pre-65816 hardware compatibility, I found that a 48KB RAM, 8KB I/O, 8KB ROM design may extend across all 65816 64KB banks in an unconventional manner while retaining very good compatibility with legacy software. This arrangement is smaller, cheaper and significantly faster the bank window design. In particular, multiplexed address latching, 8KB segment decode and read/write qualification are fully decomposed and run independently with (optimistically) 15ns latency using one 74HC157, one 74HC138 and one 74HC139. The memory map is as follows:-
I hope you can appreciate how this simultaneously approximates a Commodore VIC20 with optional RAM packs, an Apple II (16KB or 48KB), an Acorn BBC Micro (16KB or 32KB) with banked ROM, a Commander X16 and W65C265 (with I/O on $00DFxx) while allowing considerable flexibility for niche applications. Indeed, in addition to wanting a secure, neo-retro desktop computer which is capable of circuit design, I also want a portable text to speech system. With systems such as the Toynamics Timio (the modern equivalent of Speak 'n' Spell), or suggestions that a handputer may also be a vehicle computer or desktop computer, I do not see these requirements as contradictory. There are limits on power envelope, form factor and expansion but they are reasonable.

C'mon, it was fairly certain that I was going to design *something* unconventional and this extends beyond the memory map, the virtual machine, bytecode decompressor, processor compatibility, operating system compatibility and 64 bit, multi-core designs. Specifically, I've been working on multiple 100mm diameter disc designs with 60mm*60mm M3 fixing holes (TUIT100 format) and a 160mm*100mm rounded extension (EuroLozenge) also using 60mm M3 fixing holes. I sent the designs for manufacture on Thu 30 Dec 2021 and I had no idea prior to Sun 9 Jan 2022 that the Vintage Computer Festival had a 6502 badge with a disc of approximately half the area - and with a proportionately smaller lozenge extension. Regardless, I highly recommend a disc design because it guarantees that the signal paths are shorter while increasing options for off-grid, portable and wearable computing. Indeed, after receiving prototype boards, it occurred to me that I may become a pioneer of hatputing. I suggested that a 65816's EMU output could be used with digital LEDs. plasmo extended this to digital LEDs and UART output from EMU and M/X. I extend this further with one analog servo on EMU and another analog servo on M/X. Hmmm, what can I do with a 65816 computer which fits under a hat and has two servo outputs? Animatronic ears! This wasn't a design constraint. I wanted something more like a kid spy gadget, like a Totally Spies X-Powder. Or maybe a Sony Discman. Servo control is a happy bonus.

I've been studying Raspberry Pi variants in detail. The Broadcom ARM VideoCore chips have some original thinking, including the ability to set I/O pin function in octal. Chuck Peddle pioneered Data Direction Registers and this was a very good idea. However, modern systems make a mess of this idea to the extent that pins may have five unrelated functions in addition to integrated pull-up or pull-down resistors. This may be configured in three or more subsystems. When someone gets back to simplicity, I look in more detail. Apart from digital I/O pins which are primarily to control a DRM DVD tray, the Broadcom VideoCore chips are exclusively serial. They boot from single channel, clocked serial MicroSD. They have digital serial video output. Early models have serial Ethernet connected via serial USB and later models have multiple switchable USB/PCIe interfaces. Even the audio is serial and has parameters to align audio cells with serial DACs. Perhaps someone should make a 6502 system with a few digital pins and every possible serial protocol.

There is a natural affinity with 6502 and ARM given that ARM was an outgrowth of Acorn. I believe that a 6502 and/or 65816 system with serial interfaces would be a natural compliment to ARM systems, such as Raspberry Pi. Although such as system would be less powerful with, for example, 2% of the processing power and 1% of the serial bus bandwidth, there are advantages. For example, deterministic clock cycle counts and DIP scale integration. In particular, low scale of integration of processor, ROM, RAM and I/O is an advantage because each may be scaled separately. It also meets the requirements of Right to Repair. When a RISC SoC fails, you may get adventurous and replace the chip. However, it is more likely to be ground to dust and heated to extract gold and suchlike. More commonly, it is just sent to landfill. While I'd like to exclusively exceed the official ratings of a 14MHz 65816, I remain open to substitution of scrap parts. Specifically, this requires a subset of functionality to work with a crufty NMOS 6502 of dubious provenance. Anyhow, one design may cover a continuum from 1MHz 6502 to 30MHz 65816 and this forms part of a larger continuum.

The system clock may be configured to work with a two pin ceramic resonator, three pin ceramic resonator, 0.1 inch quartz crystal, 0.2 inch quartz crystal or external clock input. One half of the TUIT100 board has DIP processor (inverted so the address and data lines tally), chip stacked USD0.50 skinny DIP RAM (which scales from 8KB to 384KB) and 28C256 EEPROM or similar. The other half of the board uses an arrangement of 6522, 74HC595 serial to parallel shift register, 4052 four channel stereo analog switch (SERMUX) and 74HC238. This is used to implement PS/2 keyboard, PS/2 mouse, SPI (covering MicroSD and SNES input peripheral protocol) and I2C. This arrangement requires approximately four square inches of board. I hope that it is possible to auto-configure between PS/2 and I2C. This would allow the two PS/2 channels to be re-purposed as I2C channels without requiring, for example, battery back-up configuration to be held in the optional I2C clock on the primary I2C channel.

6522 PortA is connected to the reversible, 14 pin parallel port (CA1, GND, PWR, PA0-PA7, PWR, GND, CA2). This may be connected to a XR2800 Series EEPROM programmer, KIM-1 style interface configuration or sburrow's preferred configuration for text LCD output. The yet another 65SIB variant, 7SER, uses a 2*8 pin reversible connector with active high select signals to simplify downstream termination when select signals are exhausted. 7SER devices should Buck convert 12VDC power with either polarity and should ideally be 50VAC tolerant from 33Hz to 400Hz. 7SER devices should use 5V data signals. Firmware may support stacked 74HC238 chips. This allows two or more sets of seven channels. 6522 PortB should be set to range 0-63 for 7SER, 64 for primary I2C, 128 for PS/2 keyboard or secondary I2C, 192 for PS/2 mouse or tertiary I2C. 6522 PortB should be set to 0-13 for 7SER bundle zero, 16-29 for 7SER bundle one, 32-45 for 7SER bundle two (minimal configuration) and 48-61 for 7SER bundle three. 6522 PortB should be set to 46-47 to read SNES input peripherals (minimal configuration). The SNES peripheral extension defines daisy-chaining and covers SP/DIF tunneling and virtual reality (which has a long association with 6502). I could have arranged the decode signals such that MicroSD channel numbers matched Commodore floppy drive numbers. However, CBM had a love/hate relationship with IBM. I suspect that Commodore channel numbers were copied from IBM OS/360 octal channel ranges. I understand that 0-7 was for paper tape, punch card, admin teletype, printer and plotter. 8-15 was for primary storage. 32-63 was for other uses, such as user terminals and WAN. However, I've already got the anachronism of PS/2 keyboard and mouse. I'm not adding octal mainframe channel numbers.

The simplified XR2601 omits clock stretching, address latching and a second tier of (optionally chip stacked) 74HC138 address decode. Jumpers select one 4*8KB bank from one 28C256. Each board may hold up to 4 megabits (512KB) of I2C serial ROM. The vaporware decompressor and cache allows binaries to exceed 64KB while minimizing decompression overhead. The four serial ROM sockets are copied from 6502GPD, although, in limited space, I failed to copy the beautiful, physical symmetry of this design. Nor did I follow horizontal/vertical discipline and the 432 pad design required 18 vias. The 525 pad XR2602 reduced this to 10 vias. The forthcoming XR2603 may reduce this further. A digital thermometer may be located centrally. Unfortunately, the typical LM75 I2C variants are intended to work over a large temperature range and I presume they are not available in DIP because this reduces problems with thermal expansion. Therefore, fitting any variant LM75 will require an adapter.

The base configuration of the XR2602 requires multiple fly wires to function. This is partly because I ran out of space. (This is unsurprising with 25 DIP chips on a 100mm diameter disc.) However, it also allows configurations where partially populated boards may provide additional parallel ports, SNES peripheral inputs, I2C chains (for serial EEPROM), SPI (for bulk storage) or other purposes. Unfortunately, this requires threading the data bus through the pull-up resistor SIL and other craziness. It will also vastly reduce the maximum operating frequency. Regardless, I am now considering a chip stacked cross-over configuration where two or more cores write to each other's RAM. This is intended to be compatible with dual core clock stretching. The XR2602's enigmatic PRIVAB is a 74HC74 where one half implements a privilege bit for the otherwise unused active high 6522 chip select and the other half will hopefully convert a level triggered /ABORT into an edge triggered /NMI1. This may fail to trigger during other interrupt cycles but it is primarily a developer over-ride.

Due to my limit soldering ability, I have devised bespoke DIP footprints. These are like large pads commonly found in the 1980s but they only extend on the inside. This is sufficient for soldering 0.3 inch/0.6 inch mixed chip stacks without unnecessarily extending the width of a footprint. Actually, anything which has more than three pins and isn't an interface connector uses a bespoke footprint. Even the four-way idiot proofed power connector and clock stretching, three position jumper footprint are bespoke.

I have several problems to overcome. XR2602 clock stretching interferes with 6522 periodic interrupts. This is unsolved. The optional DS1307 I2C RTC has a spare pin which may be configured as a periodic interrupt. Or perhaps I'll stack four or five 74HC161 counter chips. However, either option may preclude use of CA1 via the parallel port. If fitted, the 7SER interrupt pull-up resistor restricts use of CA2 via the parallel port. (CB1 and CB2 are used exclusively in a clocked serial configuration.) In the current arrangement, SNES peripherals clash with 7SER but it is sufficient to develop each separately. Audio and video are unsolved. The current recommendation is text LCD via the parallel port, SPI OLED or the (oddly named) Gameduino which is SPI graphical LCD.

This will keep me occupied for a significant period but I hope this will lead to a platform with broad support for SNES hardware, Apple, Acorn, Commodore/Commander/Feonix software and more bespoke hardware and software.

Edit 1: Ongoing struggle with numeracy.

I have a not so brief message to anyone working on their own computer design: Don't despair if it takes years to complete. I joined the 6502 Forum on Tue Aug 11, 2020 and was working on 64 bit extension for 6502 but unable to maintain interrupt performance as address-space scaled. After reading through the forum archive by Sat 19 Dec 2020, I strongly considered making a 6502 computer. Even if I failed, I would learn more about interrupts. Well, shortly afterwards, many ideas percolated including video, compression of executables and various multi-core designs.

On Mon 22 Feb 2021 (one year ago today), I spent about 5.5 hours - highly caffeinated and pacing - while doodling a mad superset of (the now deprecated) Project Proton. My intention was to not implement all of it but to have every conceivable, compatible feature in one place and then trim down the required subset for implementation. So, yes, this doodle does look like a 3*16KB page banking system into a 30 bit address-space, 4 tiers of address decode to I/O, 24 cards on three parallel buses, doorbell strobes to a cube of neighboring cores, dual core bank switching where one core handles video (sadly, incompatible with clock stretching) and a 4 tier privilege system.

I settled on memory map of 48KB RAM, 8KB I/O, 8KB ROM and suggested similar to cbmeeks on Tue 16 Feb 2021. I planned to describe how this arrangement was compatible with an 8 bit Apple style card bus and 4 tier privilege system on Thu 21 Oct 2021. I enclose a tidied diagram of the memory map. Regardless, by Tue 28 Sep 2021 my consideration of a privilege system was public.

plasmo's VGA6448 video in a RAM socket encouraged my mad ideas because I planned to partially decode the 30 bit address-space into 16 segments for 28C256 EEPROM or 62256 RAM. Multiple video displays from the same sockets would be a huge bonus. By Sun 25 Apr 2021, I had discarded all parallel buses but not the 3*16KB bank switching. I was decreasingly influenced by jfoucher's Planck and increasingly influenced by 6502GPD from Thu 24 Dec 2020 which has banking at $1000-$8FFF and incoporates sockets for 4 serial EEPROMs. After a particularly long ramble around the Shannon capacity of clocked and unclocked serial protocols, I found that it is possible to interface SPI, I2C, PS/2 and SNES peripherals using one 6522 and three other chips. This sufficient for interfacing UART, MicroSD - and possibly video too!

I was quite late to watch Dave Murray's My Dream Computer (Part 1, Part 2), although references to it are plentiful. I initially thought that the rather large prototype board was an over-sized prop for the purpose of describing the design with more clarity on camera. This was shortly followed by "Holy Cow! That's the actual board!" Projects on the 6502 Forum are rarely larger than 160mm*100mm and it occurred to me that the prototype Commander X16 could be considerably reduced in size. After one cycle of complicating and simplifying a design on paper, I began another cycle of complicating and simplifying a design in OpenOffice Draw. This would eventually be followed by a further cycle in KiCAD. From Wed 2 Jun 2021 onwards, my doodles in OpenOffice were hilariously optimistic due to an one-by-one error. I wrongly assumed that I could fit 0.6 inch DIP chips at 0.6 inch spacing. I therefore thought that I could fit I2C EEPROMs, processor, bank switching latches, four parallel EPROMs and an LCD interface into 3.7 inches. Regardless, the similarity to the Commander X16 prototype is intentional. Hey, what's wrong with starting from a credible board layout? The major difference is that I omitted stereo sound and placed dual 6522 in a similar location. Around this time, I began to appreciate the dual 6522 configuration found in many legacy 6502 systems. This was aided by 6502GPD's separation of system/user functionality.

By Sat 12 Jun 2021, I had devised a large number of DIP on both sides and mixed chip stack arrangements. Of most importance, I found that it was possible to place clock stretching and address decode under DIP 6502.

On Mon 14 Jun 2021, I switched to a highly optimistic, two storey DIP, 100mm circular arrangement. I wondered if I could arrange all of the chips radially at 12 or more angles. However, after working on numerous decorative and functional projects, it was highly apparent this would be a bad idea. Regardless, I hoped to have many of the chips facing inwards so that the rim would be ground and the inner part of the board would have a short, fat power rail. Actually, a draft version of XR2602 has a snail-like spiral for power. This is very pleasing but quite impractical. With 0.1 inch grid, I was working on points basis where 20 pins * 0.6 inch = 120 points. 100mm*100mm square board is almost 1600 points and 100mm circular board is approximately 1200 points. How hard can it be to layout a computer where each 6522 takes 1/10 of the board? Very.

But first, a back-check. By Fri 3 Sep 2021, I had spent an intense eight days confirming that the memory map was efficient. In particular, 74AC implementation may be faster, cheaper and more energy efficient than CPLD. Unfortunately, it has the very significant impediment that I/O is echoed in all 65816 banks. That isn't a concern when running legacy binaries in a system with a privilege bit. For many other cases, yes, this is a deal-breaker.

Layout started on Mon 29 Nov 2021 and was sent to manufacturing on Thu 30 Dec 2021. One layout attempt took more than 12 hours and this was less than 1/4 of the effort. I assume this is ridiculously slow but I don't intend to repeat this process too often. My design technique was fairly unconventional. I drew the minimum schematic and placed footprints concurrently. Then I kept adding features. I stopped at 25 chips because I ran out of space. Then I trimmed the design. XR2601 is actually XR2602 Version 10 simplified by specifically excluding bank latching, clock stretching, privilege system and second tier of address decode. I've no idea how much of this design works but the intention is to work from the oscillator outwards. This includes NOP test, Morse code, digital LED control and eventually working towards keyboard and mouse using an extension of SNES peripheral protocol. Given the current rate of progress, I expect this to take more than one year.

I've discovered the hard way that circuit board manufacture has a "proof-reading is best after publication" quality. I had no regrets for the first three days. This itself was alarming. And then the first mistake occurred to me. I didn't make the power lines double width. And then the second mistake. I've only clock stretched the 8KB ROM segment of XR2602. I was very concerned about using cheap, slow EEPROM and therefore +2 and +4 inputs of 74HC161 clock stretching are only allocated to $E000-$FFFF. The +1 input is kept high for compatibility with jfoucher's designs. With no other inputs, there is no clock stretching allocated to I/O in $C000-$DFFF. This is contrary to my own advice for making a fast system. The top tier of the address decode should feed back to clock stretching circuitry. This allows strobes to ripple through subsequent tiers of address decode while the processor is paused. Oh well. If two tiers of address decode don't limit performance then dodgy power distribution and ground bounce of a DIP processor will be the limitation. I might be adding bodge wires for power *and* clock stretching in addition to the intended fly wires for address decode.

Memory map for XR2601 (simplified design):
Memory map for XR2602 (full design):
Unfortunately, I had to compromise on bank latching and I hope to correct this in the next iteration. A16, A17, A18 is tied to RAM address lines. Therefore, eight banks of partially decoded RAM repeat. I wanted A22, A23 tied to ROM. This would be upwardly compatible with 63 applications (one per bank of RAM) using multiple ROM ABIs. However, XR2602 only latches four bits of address: A16-A19. Therefore, the top bit of the RAM bank selection is tied to the bottom bit of the ROM bank selection. The scheme is not upwardly compatible. It also creates awkward limitations, such as a maximum of seven Commodore or Acorn applications but never more than four Acorn applications. This gets slightly more complicated when using portable binaries but only when obscure API calls are not available within one bank. I hoped to redundantly implement Acorn ABIs on $xxFBxx and Commodore ABIs on $xxFDxx to avert such cases.

Don't worry about that part. You didn't say anything about the number of layers or about plane layers; but without a ground plane, doubling the width of a trace only reduces its inductance less than 10%. Multiplying its width by five still reduces the inductance by less than 25%. If it is against a ground plane though, it will have a much greater effect on its characteristic impedance, which may or may not matter depending on line length compared to a wavelength of the highest frequency of interest.

Firstly, discussing double width power lines on 2022/02/22 is amusing.

Secondly, I intend to prototype as two layer and deploy as four layer with inner power and ground. Dave L. Jones and GARTHWILSON both recommend that power and ground should run between 0.1 inch spaced through holes.

Thirdly, I only considered via inductance. From the perspective of current carrying, eight times width feels insufficient when considering the return path of numerous address and data lines. (Dr Jefyll's recent advice about inductance and loop area is pertinent.) Even if it made no difference at all, double width power is a very helpful visual indicator when designing a board. In particular, power or ground should never terminate at any chip but should continue to form a mesh of power distribution. My less crowded designs follow this principle wherever it is easy.
Diagrams enclosed.

For boot-strap, I recommended a simplified, one chip version to gmc.
I was overly concerned by this limitation. It is possible for firmware to detect 20 bit/24 bit address-space. It is also possible to latch an extra four bits with 74HC573 on opposite clock phase. Or one additional 74HC157. Or possibly eight output SMD multiplexer. That doesn't fit onto my board. However, others may chip stack these without difficulty.

Between grading papers today, I was eating a sandwich and decided to have a nice read. Thank you Mr. Sheep

When I started reading this post, I immediately knew that I needed to reply to your first line. Before this I read from you, "I've spent almost 40 hours on one project with mixed results and at least 160 hours on further projects" and you were mentioning the bombing formations in Catch-22. I would say you have many feathers in your cap Mr. Sheep, so relax in your armchair. I myself have too many black eyes (and one poked out from a perfectly thrown flower and now I wear an eye patch while playing horseshoes each day). Joking aside, I found this post very encouraging. You have spent only 40 hours with mixed results, and 160 hours on other projects? If I were clocking the amount of time I actually spent sitting at a computer, pacing, drawing, thinking, and mind-coding, it would have sounded as crazy as how Milo can make a profit on eggs from Malta. Well, as long as everyone has a share.

If I seem to have determination and drive even after long surpassing your records, then perhaps I should actually see one of my projects to completion. And after I fail, well, at least it is not as bad as Bologna. In the meantime I will continue walking backwards everywhere I go. Thank you for that Mr. Sheep.

Chad

After going to the Sheepopolis Toy Exhibition, I discovered the improbably named Miraculous: Tales of Ladybug & Cat Noir. In the manner that ARM is a spiritual continuation of 6502, Miraculous is a spiritual continuation of Totally Spies. In particular, both are created by Francophones and are/were drawn in Japanese style, both have seven seasons and a film, both dis-proportionately feature Paris, both have an antagonist who is a mime artist and, most significantly to me, both have protagonists with a circular gadget. Well, I may be holistically researching interesting functionality and design constraints. To the uninformed, this may appear indistinguishable from binge watching cartoons. However, similar research led to the TUIT100 format.

Actually, no-one asked about the four lugs on an otherwise circular design. The cost of manufacturing 100mm circle is the same as 100mm square. Therefore, I placed unrelated circuitry in the corners because it only affects shipping weight. Unfortunately, I couldn't get much more than reversible indicator lights into the corners.
I thought that it would be informative to draw a realistic doodle. This explains some of the finer detail, such as the pull-up resistors for the processor, data bus and four serial buses and the connectors for RTC battery, parallel port, I2C bus, PS/2 keyboard, PS/2 mouse, 7SER IDC and WS2812B/UART/servo outputs from EMU and M/X.

I will explain the oscillator section in more detail. The board area for the oscillator is intended to work with 0.1 inch quartz crystal, 0.2 inch quartz crystal, 2 pin ceramic resonator, 3 pin ceramic resonator or a directly supplied clock signal. Three of these five cases involve blobbing solder across joints. With minor modification, it is possible to include 0.3*0.3 inch canned oscillator or 0.3*0.6 inch canned oscillator. However, that would require more board and it makes half of the 74HC139 redundant. (Yes, 1/2 74HC139 is used to invert crystal. In favorable conditions, this works at 64MHz.) If you include canned oscillator option, I highly recommend connecting the spare pin to power so that a universal oscillator design works with the enable input found on some canned oscillators.

While experimenting with oscillators, I found that connecting the ground pin of a 3 pin ceramic resonator to the input pin causes it clock at double frequency. I do not expect this to be stable and I recommend against this configuration. After success with ceramic resonator, I wrongly assumed that quartz crystal would be a drop-in replacement and at least 10 times more accurate. In particular, I wrongly assumed that the inverting gate's input would start low, high or oscillating and that any state would be sufficient to start oscillation. Apparently, connecting a quartz crystal may place the inverting gate into a corner case where it sits in a midway state with no current flowing. It may spontaneously switch to a ticking state after a reset signal ceases and this will clock an uninitialized processor. Presumably, a ceramic resonator avoids this case because it is leaky and acts as its own kickstart resistor. This makes me wonder if a ceramic resonator should be avoided if they are less accurate and waste energy.
That's only time spent using KiCAD and I've tried to minimize time with that hateful package. Starting from the position where I could write very stilted NMOS 6502 assembly and solder badly, I've spent:

• Seven weeks reading three million words of the 6502 Forum archive. That's how I found Dr Jefyll's trick of using 74x157 as a four bit latch.
• As a mental spritzer, I spent two weeks reading one million words of the Chakat's Den. OMG. How much NSFW furry/brony fiction did I download? This is what happens when you type wget -m and leave it in the background. I remain particularly traumatized by writing and drawing from one of fachat and floobydust's ex-colleagues.
• Two weeks reading one million words of anycpu.org
• A mental spritzer reading the major works of F. Scott Fitzgerald.
• More than six hours making my first batch of reversible indicator lights.
• Eight hours working on the trim of one enclosure.
• 5.5 hours drawing one deprecated diagram.
• 4.5 hours staring at the layout of POC2.0
• Two weeks on one aspect of 6502 with dual accumulator.
• Eight days working on efficient address decode. Note that there are 174 days between my first and second suggested address decode schemes.
• Almost 40 hours using KiCAD to design a quad DAC that I cannot solder.
• 160 hours working on other KiCAD designs. This includes 1.5 hours shaving 0.05 inch from a switch debounce test, 2.5 hours shaving 0.05 inch from the keyboard matrix interface and the best part of one day drawing snowflakes for the Arctic theme of hexmap game tiles.

This doesn't include time spent reading more recent 6502 Forum messages, lurking on other forums (gleaning ideas but also for comedy value), reading data-sheets, finding errors in data-sheets, ordering components, waiting for components to be delivered, organizing components, prototyping, soldering, writing simulators, drawing diagrams or writing messages. It takes a while to write some of the messages. For example, the SNES protocol extension is almost 4000 words. It may surprise you that I discarded at least 1/4 text that I have written for the 6502 Forum and trimmed some of the remainder.

From Dec 2019 to Mar 2022, I think that one working year allocated to 8 bit computing would be an under-estimate. Of this, I made no appreciable progress before Oct 2021. That's almost two years. Good luck to anyone who is learning to program, learning electronics and/or doing this around significant commitments. If you make any progress at all then you're doing well.

There is a belief that 8000-10000 hours of practice is required in many fields. That may be bunkum but it is apparent that I've spent more than 2000 hours on 6502 *after* learning BASIC, 6502 assembly, C and Arduino. There is a joke that some people have five years of experience and some people have one year of experience times five. Hopefully, I am in the preferable group. This is where I'll mention the Dunning-Kruger effect. If I remember the details correctly, Dunning & Kruger introduced 40 newbies to tennis and interviewed them between practice sessions. The participants were ranked in a tournament and this provided a modicum of objectivity and blinding to the experiment. The top 10 participants believed they were good and they had good metrics for improvement. The bottom 10 participants also believed they were good but worked with terrible metrics.

I have a similar sporting experience. I am entertainingly bad at cheerleading but I am a reasonably good coach because almost every mistake is within personal experience. After too many years of Don't Repeat Yourself programming, I am very good at not repeating myself. When working alone, this allows me to surreptitiously find fairly optimal solutions. However, in the middle of a team of 30, performing 2.5 minute sequence of dance and gymnastics, Don't Repeat Yourself is a *huge* problem. Anyhow, during practice, one newbie completed an indistinct move which was neither a cart-wheel nor a back hand-spring - and it was actually quite dangerous. This was resolved very easily. "What were you trying to achieve?" "I dunno." "What did you actually achieve?" "Aaah." "If the thought is not clear, the action is not clear." Top tip: If you throw yourself upside down, have a clear plan of what you're doing. This will avoid broken bones and paralysis.

I like to have objectives; especially if they are numerical. I've seen too many film and music projects go nowhere with no objective outcome. Likewise, there are many examples of managers measuring the wrong metrics or encouraging the wrong incentives. In Catch 22, the generals were more concerned about bombing formations rather than hitting anything. Likewise, my concern about via count and via inductance may be detrimental to designing a board which works. schlachet used via count as a metric for successful auto-routing but this is definitely not an expert's metric. Perhaps more useful metrics are cost, ease of construction, bits of address-space, board area and decode latency? plasmo notes that low cost and low latency are important and correlated. Board area and cost are also correlated.

tmr4 is perhaps the most recent to observe an inverse correlation between parallel bus length and maximum operating frequency. I reduced bus length because it increases component density. If 8 signal lines with 0.05 inch spacing are 1 inch longer than necessary then it requires 0.4 square inch of board. It might be possible to share this across multiple layers of a board and it might be possible to run this under a badly placed component. It is otherwise wasted board area. Indeed, it is worse than unused board because it radiates unwanted EMF. It is a bonus that reduced length aids maximum operating frequency and this may be quite favorable when the data bus is less than 3 inch and the address bus is less than 2 inch. Although, on a 4 inch disc, it requires particular effort to make any signal longer than 4 inch.

There is a noticeable difference in complexity with the parallel buses on one side of 6522 and the serial buses on the other side. On XR2602, all 10 vias are around the edge of the parallel buses. There are zero vias in the proximity of the serial buses. Furthermore, it is really easy to minimize signal skew when there is one uni-directional clock signal and one bi-directional data signal.

It is highly informative of sburrow to note that automated circuit board layout is poor with via placement. I assumed that automated layout was awful due to lack of enumerated constraints but I didn't investigate because I had enough problems with the core of KiCAD. If you auto-route, like Agumander, schlachet, plasmo or sburrow, and get a quick result then you are spending time effectively. If you spend 12 hours on the task but layout more than one chip per hour and have less than one via per chip then you may be working beyond the ability of a constraint solver. The result is personally satisfying but not necessarily productive. If you spend 12 hours on layout and the result has dozens or hundreds of vias then you definitely wasted your time. It would have been preferable to spend five minutes or so auto-routing.

To increase my certainty by whatever means possible, I compute statistics on 6502 Forum topics. From this, I found that WS2812B digital LEDs had grown substantially beyond the 6502 Forum. I believe that plasmo was first to implement on 65816 and AndersNielsen was first to implement on 6502 but others are repeating it on Hackaday, Reddit and YouTube. By May 2022, I'll know if the address decode schemes have gained popularity. Preliminary figures are encouraging.

People are moving away from 65816 Bank Zero Special designs which typically use 4078 or, hopefully, 74HC4078 8 input OR/NOR on the upper, multiplexed address lines. This requires two tiers of logic chips before ROM and I/O decode begins - and both are typically slower than RAM. I bought one alleged 74HC4078 and didn't use it because it is a waste of time. You may expect BigDumbDinosaur to be a keen advocate of 74HC4078. No so. BigDumbDinosaur's designs have increased address-space one bit at a time and have avoided 74HC4078 entirely. In akohlbecker's popular 65816 video tutorials, 74HC4078 is dropped in Episode 16. Even WDC, the designers of 65816, may be in error. The major difference between W65C816SXB Revision B and Revision C is the removal of 4078. SpaceCoaster suggests the timing may be significant.

Unfortunately, I have two further problems which are unresolved. The chip shortage affects my implementation of read/write qualification and crystal inversion. This can be implemented with either 74x00 or 74x139. Supplies of the former are more plentiful but I chose the latter because the critical path is slightly faster. To make matters worse, the affected chip is stacked under 65816. Therefore, any bodge board will have the additional complication of extending under the main board and being mirrored. The other problem is that JMP (abs) works within any 65816 program bank but JMP (abs,X) inexplicably references bank zero. I hoped to use JMP (abs,X) fairly symmetrically for native ABI function calls and error codes. Assuming there is enough space for a table in bank zero, this will work within an operating system. However, each application requires a work-around and this may impede error handling.
To quote Monty Python, "I say! Anyone for tennis?"

The only ceramic resonators I've used were with PIC microcontrollers. You tell the intended type of oscillator in the configuration word. Since the XT (Crystal/Resonator) and HS (High-Speed Crystal/Resonator) modes are both good for either a crystal or a resonator, it took a little digging to figure out the difference. It turns out it's in the threshold for the input high voltage. I've used the three-pin resonators, grounding the third pin, and got the expected frequency, not double.
I think you have that backwards (although I don't have any multi-bank '816 hardware to try it on so far). The Eyes & Lichty manual says,

• On the '816, a jump-indirect operand is in bank zero, but a jump-indexed-indirect operand is in the program bank. There is a different assumption for each mode. Jump indirect assumes that the indirect address to be jumped to was stored by the program in a variable memory cell; such variables are generally in bank zero. Jump indexed indirect, on the other hand, assumes that a table of locations of routines would be part of the program itself and would be loaded, right along with the routines, into the bank holding the program.

There's probably a way you could get what you want with self-modifying code though.

I have two quick items which will otherwise get lost in style, memory map and address decode. If anything bores you then skip to the first memory map.

I forgot to mention the inclusion of six ground test points for the purpose of minimizing loop inductance when viewing signals with an oscilloscope. This required 0.5% of the board area and easily fit around component placing. I don't have an oscilloscope or have access to an oscilloscope an yet I can add functionality to aid diagnostics with oscilloscope. What's your excuse?

Thank you to GARTHWILSON and BigDumbDinosaur for corrections about JMP (abs) and JMP (abs,X). I remain unamused that one refers to 65816 bank zero and I can only presume that it fixed something in Apple IIgs. If you don't care about passing anything via RegX, JMP (abs) in local bank can be simulated when RegX is zero. For my purposes, I'm going to regard JMP (abs) on 65816 broken in the same manner that ROR is broken on 6501 and very early 6502, decimal flags are broken on NMOS 6502 and decimal subtraction is broken on 65CE02. Feel free to argue the JMP (abs) isn't broken. However, any legacy application which uses it may fail to work outside of bank zero.

I've been researching fictional user interfaces and I'm utterly perplexed. Portable, circular devices should be quite common but they aren't. Even for a hobbiest:

• Numerous 6502 Forum members work on battery powered, 3.3V systems.
• Numerous 6502 Forum members work with SPI and I2C.
• For many years, VTech has successfully sold 6502 systems with I2C serial EEPROM.
• Multiple 6502 enthusiasts make circular boards with 4 inch diameter or less.
• Circular, 3.3V, SPI, OLED displays are commonly available.
• Numerous 6502 Forum members are customers of JLCPCB which has offered 3D printing since Sat 1 Jan 2022.

Therefore, it should be relatively easy to make a portable device which is maybe 5 inch diameter and 2 inch thick with connectors, buttons and a display on one side (or both sides) and maybe a solar panel. Actually, I don't understand why circular phones or tablets aren't a common choice. With an accelerometer, high resolution "retina" display and available graphics processing power, it should be possible to hold a circular tablet in any orientation and allow the device rotate the display for the user's convenience. The only circular devices which I can recall are Sony Discman and Motorola Revolve which was dis-continued 12 years ago. Perhaps it is application support? I've found numerous circular devices in cartoons, although they tend to have exotically fictional features, such as DNA analyzer. In contrast, the merchandise you can buy is wholly underwhelming. For example, the Miraculous Ladybug yoyo has one button which plays sound samples from the show. That's only a marginal improvement from the infamous Barbie doll with a pull string which says "Let's go shopping!" The ladybug toy doesn't even work as a yoyo or have a torch function!

A preferable system would have a few dressed-up games from the 1980s Usborne computer books, a few games of skill which are no more advanced than Horace Goes Skiing or Shuffle Puck Cafe (a Pong variant). With a compressor, stuff one or more serial EEPROMs full of bad jokes, ghost stories, a dinosaur reference guide, crypto-zoology (unicorns, fairies, elves, trolls) and whatever else you can devise. It would also be popular if it contained a weak decoder ring type substitution cipher (like Speak 'N' Spell) and a GPS receiver to aid map making. An accelerometer and Hall effect device would aid science experiments. It would be vastly preferable if it plays music, works with a television, has a text editor, has a circuit designer/simulator and allows programming.

My model was a Totally Spies X-Powder and perhaps I should explain how this began and where it departed. I am a fan of the hugely under-rated 1980s cartoon, The Centurions. It is a tad jingoistic but the three protagonists (Ace McCloud, Jake Rockwell and Max Ray) wear specialized suits with fixing points which allows an Dr. Bonnie Barstow type geek girl to teleport vehicles and weapons from a Thunderbird 5 type orbital platform. The hand drawn animation for the transformation sequences are amazing with heavy emphasis on a white-than-white bloom effect. I'm a fan of short form audio/visual and this includes demoscene productions (which often include bloom and lens flare), transformation sequences and James Bond title sequences which I'll watch maybe hundreds of times. You guys may be aiming to play Bad Apple. I'm aiming to play films or at least film trailers.

When I was wandering through an airport for a business trip, some kids were absolutely riveted by a very vivid and colorful cartoon. I made a mental note to investigate when I had time. That cartoon was Totally Spies and it is mix of Charlie's Angels, Scooby Doo, The X-Files, James Bond and Get Smart set in a Malibu high school, drawn by Quebeckers, in a Japanese style. Of particular note, the characters wear suits very much like the Centurions. However, to the best of my knowledge, none of the suit features are ever used. This is hugely disappointing!

Since going to the Sheepopolis Toy Exhibition (partly due to randallmeyer2000's 6502-opoly), I have been investigating similar references and I was initially quite pleased to discover Miraculous which is a mix of Totally Spies, Reboot: Guardian Code and The Tick. It is visually stunning and evokes Paris on a sunny day. The story-boarded fight choreography greatly benefits from motion capture. However, it is "over egged", too fast paced and has no sense of peril. Out of costume, Cat Noir has the eyes of a dead fish. After watching six episodes, I was only inclined to re-watch Season 1, Episode 9: The Dark Owl. This is a Dark Knight parody which features a JARVIS type computer called ALBERT. As someone who worked on motion capture for The Dark Knight, I strongly approve of this parody.

So, onto the next reference from the toy exhibition: Winx Club. This isn't too distant from Eoin Colfer's Artemis Fowl books where multiple species use a combination of magic and technology. Early Winx Club animation is an amusingly cheap combination of hand drawn animation, 3D rendering and video effects. There are also numerous pop culture references. However, like some of the best science fiction, the story has a series arc, a season arc and episode arc in addition to character arcs. It also follows the universal themes of listening to your elders, looking fabulous, using your privilege bit responsibly and resolving conflict with tele-kinetic fire-balls. This makes it surprisingly engrossing and I've watched three films and 64 of the 208 episodes. From this, I've found something quite curious about the fictional technology. The series started in 2003 and some of the junior animators have incorporated cool stuff from their own past. This makes an odd pocket of 1990s retro-futurism/hauntology where a fictional continuation of quinkey keypads and chintzy Nokia phones is mixed with the obligatory holographic displays. This is mixed with 84 minutes of transformation sequences and *hundreds* of upbeat tunes where the early ones typically sound like Belinda Carlisle and the latter ones typically sound like Republica who were popular in the, er, 1990s.

I'm now using animation sequences as a short-hand for how a 6502 system should work. I've often had difficulty expressing myself and, in technical matters, I may take longer to describe an idea than implement it. At the risk of raising expectations too high, I now give a quick explanation using stills or a montage of video clips. The final implementation may differ wildly. Indeed, this might be preferable to avoid being sued.

Initially, my plan was a processor accelerator which could be placed into Apple, Atari, Commodore or Acorn hardware and the accelerator would have a pre-boot sequence before the native host's initialization which would include a check of its extended memory. Rather than the half-finished look of x86 memory check, Wildbow's serialized fiction gives hints of super-villian GUIs which are slightly different to familiar systems. This gave me the idea to have bar graph memory checks. The title sequence for Neon Genesis Evangelion has something similar. This is easily implemented with PETSCII or similar.

In a stand-alone system, a bar graph memory check is only one stage of a larger process. Therefore, I've been looking for further inspiration. Sometimes, that inspiration aids the 6502 Forum. I've already been styling enclosures with stripes. It is worrying that I was able to match the default striped t-shirt of Ladybug's Adrien Agreste without buying more imitation Lego.

A comment by BigEd contributed to the keyboard/mouse extension of SNES joypad protocol and the uni-directional flow of data required a bezel for caps-lock and similar. I thought that 8mm pitch, 2*2 stud hole was sufficient. Assuming 5mm LEDs, this is sufficient for 3*3 grid of LEDs. Switching to digital LEDs, such as WS2812, as implemented by plasmo on 65816 and AndersNielsen on 6502, I assumed that the top left LED would be power, the next LED would be caps lock and the remaining seven would be user defined. After watching Ladybug's typical transformation sequence, power should definitely be in the middle and a dice/domino pattern is highly desirable.

For systems with audio and video, anyone who has seen The Bionic Woman or Automan may appreciate the glowing phosphorous grid and sparkles in Techna's first solo transformation. The solidifying effect is very simple and found in some Commodore 64 demos. Indeed, you might be thinking LDA abs,X // OR #$80 // STA abs,X on a monochrome bitmap display or a similar text mode font effect. This consideration overlaps with power-up testing in Commodore Amiga hardware where the display changes from black to dark gray to light gray to white as testing progresses - or switches to green, red or suchlike if a peripheral chip fails. (This is directly applicable to anyone making video output with four shades of gray.) As tests progress, the optional 3*3 WS2812 matrix and optional text display can be co-ordinated with a series of increasing tones from the optional audio output. When the display is solid white, a non-destructive marching bit test outputs a bar graph to display.

And then what?

After thinking about a particularly glittery transformation of Musa (not to be confused with MUSA), I wondered if anyone has made a window manager with glitter sparkle trails. When I'm finished, the answer will definitely be yes and I almost fell over laughing at the idea. My first idea for a window manager was to follow the default red of vtwm. In a dream where I used my own GUI on a touch sensitive e-ink display, I found that burnt orange is a good default for window borders. I am now considering a window manager which is offensively cute and defaults to hot pink. Or maybe purple. Remember that Jack Tramiel's son wanted playing card suits in PETSCII and therefore anything which faithfully supports PETSCII will display hearts. With minimal constraint on clock cycles to implement trail effects, I'm quite certain that it is possible to create pointless, annoying sparkle effects with sequences of symbols, such as @O*+o-. and maybe a few PETSCII symbols. It will be possible to switch off this effect but if I'm writing it, you can be dang sure about the default setting. Or maybe not because corrupted settings would be more annoying than the return of Clippy. Anyhow, this is currently filed as the Sailor Bubba Window Manager.

These fun but ridiculous considerations lead me to consider a memory map for applications. By default, each application gets its own 65816 bank with a maximum of 48KB RAM. Bulk data, such as display and storage buffers, are placed within an application's bank whereas meta-data is held outside of the application's bank. This arrangement provides a modicum of integrity because an NMOS or CMOS 6502 binary should only scribble over buffers within one bank. This leaves file system, network and windowing unaffected. 65816 bank zero is also used to maintain state for the sparkly effects.
(See stochastic cache and portable binary.)

This is an unusual 6502 memory map because the bottom 1KB may be completely empty. However, care must be taken. Under different operating modes, allocation and re-allocation within the bottom 8KB may become tortuous or contradictory.

The 3KB for display may operate in different modes which may include 40*25 traditional PETSCII, Latin1 or Roman/Greek/Cyrillic with or without accents. Where symbol representation is 8 bit, the other two planes may be RRGGBBII foreground/background. Whereas, 16 bit symbols only allow foreground to be specified uniquely. This is sufficient to implement a serious text editor similar to LocoScript. The 65816 executive may copy and translate symbols to occluded windows on the display; possibly with one cell border RRGGBBII drop shadow via configurable LUT. (This is a variation of Bill Atkinson's window regions.) In the trivial case, RRGGBBII is decremented to make a shadow effect.

Within the 8KB I/O range ($C000-$DFFF), I have derived a tentative solution for high speed I/O after studying Radical Brad's 20MHz, 32 I/O strobe implementation. There is a widespread technique to use multiple 65xx peripheral chips in a configuration where they all share one common active low chip select while active high chip selects are tied to different address lines. See Address decoding (Garth's primer) for recent explanation with diagrams. This type of arrangement leads to asymmetric I/O ranges which decrease in size. It is quite profligate with address-space and invites opportunity for bus contention. However, it is blazingly fast and requires minimal hardware. In particular, one chip, 2ns address decode is possible. Radical Brad applies the same technique to 74x138 chips with their active high and active low chip selects. This has the typical advantages and dis-advantages but allows practical designs with generous I/O to exceed 20MHz. If contiguous memory is unimportant, this arrangement is also compatible with the 74x157 hack to obtain fast 20 bit or 24 bit addressing.

So far, XR2600 Series designs have been a tussle between speed, size and stability where everything lost. They have either:

• Failed to allocate 48KB for RAM.
• Failed to allow multiple SNES peripheral input chains.
• Failed to allow multiple 65xx peripheral chips.
• Failed to allow 6522 to count accurately.
• Failed to implement one fast tier of address decode.
• Failed to apply read/write qualification correctly to raw address strobes. Actually, I only found that error after adapting Radical Brad's ideas.

In XR2601, concern for speed and simplicity clipped the RAM by 8KB to add one shift register without read qualification. In XR2602, concern for flexibility omitted I/O from clock stretching and omitted strobes from qualification. The quickest fix for latch qualification breaks 65xx peripheral support while the quickest fix for I/O fan-out breaks accurate 6522 timing.

After some pre-amble and 1.5 days seriously considering the problem, I found that parallel I/O decode, using 74x138, within the range $C000-$DFFF, must meet simple conditions:

• Leading bits of the address must be 110.
• Two bits must be zero.
• One bit must be one. This is quite trivial, given the leading bits.

With two zeros in every address range, it is possible to divide an I/O range into half-of-a-half-of-a-half in the following form:
This arrangement has W65C265 compatibility because it approaches the internal I/O in page $DF but doesn't reach it. It can also be adapted to the simpler case of I/O starting from $8000 by dropping one leading bit. Unfortunately, for some ranges, the number of significant address lines exceeds the inputs of 74x138. Fortunately, they can be hollowed out such that the *last* address-space echo does not incur bus contention:
With minor modification and future proofing, it is possible to define the I/O range such that each 74x138 provides one, two or four strobes but never eight (like Radical Brad's design) because each range uses one top-level address decoder running in parallel and there aren't enough inputs free:
And the oft neglected clock stretch map:
With sparse address decoding, 16*16 pixel text mode and bank switching into one display line, bus contention will occur when attempting 4K video and erroneous clock stretching will occur when attempting 16K video. This is not a concern for a system which displays 1920*1080 or less. However, software written for this system should work on larger systems.

Although this memory map is primarily designed for implementation with discrete 74x138, several other options are available with differing limitations:

• FPGA with 4 input LUT requires +1 clock stretch across $D000-$DFFF. This affects 6522 timer accuracy. However, if you implement with FPGA, you may not require any 6522.
• FPGA with 5 input LUT works best if I/O spans $8000-$BFFF rather than $C000-$DFFF. Alternatively, Omit A12 from address decode.
• Discrete implementation requires +1 clock stretch for 24 strobe fan-out.
• CPLD with 6 input macro-cell is compatible with discrete implementation but may be slower and consume more energy.

Anyhow, the general principle is that it is possible to run numerous 74x138 in parallel. One decoder provides strobes for six RAM chips, one ROM and provides clock stretching signal for slow ROM. The remainder are sensitive to decreasing spans of the I/O segment. This is achieved in an upwardly compatible manner which superficially appears to defy the six input limit of 74x138. With restrictions, the same memory map is compatible across CPLD and FPGA.

After staring at boards intermittently for almost five months, I will further stare at boards. Ultimately, I think that I'll have to redo about 20% of the layout. That might take about 10 hours.

Edit 1: Moved primary 6522 out of page $DF.

I wasn't ready to design circuit boards. Indeed, I'm still not ready. I don't think that I'll ever be ready but I had time and opportunity to push my limits.

After designing boards in Nov 2021 and Dec 2021, ordering boards in Dec 2021 and receiving boards in Jan 2022, I have only looked at them. Part of my procrastination is that the accompanying EEPROMs are caught in the chip shortage and aren't expected before Jun 2023. The only time that I've warmed a soldering iron this year was to assemble XR1155 5 volt Christmas lights. That was in Feb 2022. Actually, I'm saving the 2021 Christmas programming challenge for Jul 2022.

After further staring at boards, I think that I will only use them to wire power, ground, address and data. This is faster, more compact and more reliable than the equivalent 60 wires on a breadboard. However, it is a marginal use of resources. Superior address decode fits on one 5cm*7cm perfboard. Asymmetric clock fits on the same perfboard. So, for a while, XR2600 Series is going to be a one circle, one rectangle implementation. Even if my work had no error, a board received in Jan 2022 would require bodging to work in a manner more similar to Radical Brad's design published in Apr 2022.

The upside is that I have a coherent plan for video and audio - and even networking. This extends to trunked audio conferencing over LAN. Previously, my plan for video was a "here be dragons" something-on-the-end-of-SPI which was encouraged by Commander X16's VERA becoming available separately. Thanks to insight from Radical Brad, it is possible to have optional, memory-mapped, stereoscopic view-ports for video or simultaneous banks for audio buffer and network buffer.

In the medium-term, I've been thinking about re-designing one quadrant or so of my circular design. The lack of 28C256 and relative abundance of SST39SF040 requires me to replace 28 pin DIP socket with 32 pin DIP socket. This can be achieved by moving the power connector. The difficult part is that optimal address decode requires a minimum of four 74x138: one for RAM/ROM, one for unqualified 6522 and two for qualified strobes. The first 74x138 fits under ROM but the latter three may become a curious example of chip stacking.

I'm considering 3.3 volt only. This reduces energy consumption and simplifies interface to MicroSD. In other places, it makes minimal difference, if any. In the case of 1 volt peak-to-peak output signals, it merely requires different resistor values. Regardless, it is less impressive to have 3.3V CMOS system run at 20MHz when it is equally difficult to make 5V CMOS system run at 30MHz. If you want the most impressive figures, 5V (or more) is essential.
I found some quotes which accurately capture the offensively cute aesthetic.

While shopping: