today was a pretty good day. after I got the early morning done, I got back in the house about 8:30 and started calling colleges in florida. I got some real good feedback from the people I spoke to, it really helped to solidify what I am working on and why.
Part of NSF Innovation Corps training is customer development, and i-corps training is more than that. After the 3rd or 4th call I started to get my pitch down, and could say "I am wayfarer, and I am working on this device, and it does this."
I used to telemarket a bit, and I did prospecting for a guy that bought and sold as/400s and rs/6000s. I am used to cold calling. It started to come back to me. In i-corps training, they tell you a minimum of 40 interviews. I got 1-2 today out of dozens of calls. I expect to be at this round of cold-calling and talking to people and asking questions for another week or two. I want to make sure I can find a few people willing to at least demo one of these things, and I want to make sure the base device is something they can use in their curriculum. Thats just the ECE side, Ill do a round in computer graphics and in industrial as well, not just colleges, factories. One of my professors is adamant about ladder logic and PLCs, i think its a good market to go after. Just yesterday I was talking to a friend up in Canada that does environmental assurance testing. They support a lot of legacy hardware and said they have tried about 5 PCI RS-232 cards and about half of them work. I immediately thought of you all here. have a module or a few ports or adapters that can talk to and debug or diagnose legacy systems is really a good thing to go after. A 'wired comms' module or such, maybe on the 'scope module, idk yet.

I also got to talk to Dr Y. over at university today, he has done Wire Wrap stuff in the past. Really valuable call there!
He suggested I check out PC/104, and after a bit of reading, I think I want to look into PC104+ "Bus Compatible" rather than "Compliant". This offers both ISA and PCI busses to my device and allows good bench level design too. So, I will be making a thread on busses soon, and discuss aspects to consider there. I already wanted XT/ISA and PCMCIA, and Ti makes a PCI/PCCard chip. the PCI1520 I think. I reached out to Ti support today to get info on if I can down clock it, if its stable, if its static, if it needs a different PCI host controller etc.

I found some really cool GPUs from Epson of all places, certainly an option. Has direct bus access. So does the 4d series from the Au. the bridgetek, the EVE, only has spi/qspi. I now have 3 good choices for a main "GPU". at least 2 if not 3 (there are several epson to choose from) that run at 12MHz. It is looking more and more like 12MHz is going to be my base system clock. One of the epson has killer 2d, the other has oGL ES 1.1. THAT, would be really cool, Im not sure the 65816, or two 65816s. could get much from it, idk. It would be awesome though, and it beats out the EVE here.

Because ISA likes slow speeds, having a 6MHz clock line, is maybe a good idea, however, if we can get the Bus at 32bit max (even if we dont use all of it) with the Ti 1520, then 24Mhz becomes a thought at double our 12Mhz main clock. Most stuff all running at 12MHz is fin too. The GPU will probably run at 60Mhz and be a 32bit RISC unit as above.

msp430 and 65265 and good contenders for the PIC24 position as board controllers. I still think the PIC24 is the best choice so far, though which version is not final.

One of the last calls I made was to MSU, and I called, like 30 people, and the last one, picked up. They had no idea, totally different department, they however suggested I contact the department chair and ask, they would know who teaches what.
So tomorrow, Ill try that. at several dozen colleges, Ill call the chair and ask about who might teach the assembly and mcu and industrial logic classes. I might, try to get an email sorted and send it out to many hundreds of people. start building a list, and get a brochure, well, a questionaire sent out. "do you tech X, if you do, do you use Y?" that sort of thing.

For now, Im going to read up on the PC104+ and PC104 specs and see if it tracks. Later, I might start on some assembly in an emulator/simulator/IDE and try to get going with some basic read/write/copy operations, maybe some math, start playing with each command and watching the outputs. Id like to be using C, though thats a long way away.

I look forward to getting the bench going and get the Core unit working, at this point I think is going to be a 6502 (816 later) and a 6522, a DART (max3100 maybe), a very small ROM and a lot of RAM (and stuff to switch rom/ram banks maybe)
thats really the core itself, CPU, I/O,ROM/RAM CIORR, maybe add 'energy' in there for the E...

this should have mode for headless operation, and with a monitor for normal use.
I might try to get a stylus working here right away.

for HID, Im looking at a small screen in my preferred aspect ratio, and the keypad/button style I want to use, so an onscreen keyboard is probably one of the first 10 things to code. after that, Ill look more at the PIC for a bus and an actual GPU and start getting that working. Once a basic CORE is working, then I want to offload all of the 6522 and UART stuff off to the PIC, they would sit idle now, and only get used as needed. I am considering not having much besides the 65816 really, just CPU and RAM.


The goal is an overall design :

65816 <- top level, does logic and commands
PIC24 <- interrupt handler, I/O handler, DMA, peripherals etc
LCDGPU <- video, PC speaker, stylus interface, maybe SD card 'hard drive' access
SS01G <- audio generation, probably sends to a mixer
PCI1520 <- this might go on a peripheral, does PCMCIA and 32bit bus. not right now.

so the 65816 is just running code, its getting input, and running logic and then it tells the GPU to run routines, and rarely specific pixels.
it tells the PIC to route signals or copy and paste data, it tells the pic to sort the interrupts and handle what it can. It tells the sound chip what songs and effects to play. Really, it tells the RAM what it wants, and the PIC reads that ram, or that RAM was really controls in the PIC, and the PIC does things and uses its I/O to tell everything else what to do. The CPU leaves instructions here, and goes to do other things, the PIC does everything else, and often tells the GPU indirectly what to do,

Lots of DMA I guess, and probably some fast shared video RAM (some epson chips have this built in in nice sizes) for the direct GPU control.
The cpu should not be 'updating the screen', it should update variables to draw on the screen, and the PIC and GPU should draw on the screen. the cpu should not process the stylus, it should get a 'stylus_event' after its been handled by the gpu and may only do periodic checking, or updating an image or variable.

Anyway, I am starting to narrow down what to work on next, I said pages ago I want to focus on just a Core unit of the cpu and some required chips. I have to order those soon, maybe next week, I need to check storage for my chips and wires before I order more

so, I think Ill work on some assembly and see if I can get something started, better to port code to a physical system and fix it, that wait and start later. Id like to aim for an onscreen keyboard and cursor, maybe a prompt, or a set of 4-6 icons you can 'click' with the keypad and button, and go to different screens, after that, Ill start on a calculator and a Hex Editor.

anyway, it's been a very productive day.

Interesting methodology, completely opposite of what I did for 40 years. I was and am a "backroom engineer", mostly talked with other backroom engineers, and "shield up" when dealing with marketing folks. Judging the chorus of comments, I suspect this methodology is also different from others here on 6502.org.

However, it doesn't mean it won't work. It is a different way of making money; start off with a random "word salad" of technical terms; see which terms received positive feedback; make a new bowl of "word salad"; repeat; until people is willing pay for latest "word salad". If 65816 didn't work, try again with a different mix of "word salad".

Walking up to 10 girls at a bar asking for sex right away might got you slapped around 9 times, but it is efficient and the 10th time is worth it.
Bill

"The short successes that can be gained in a brief time and without difficulty, are not worth much." -- Henry Ford
"Satisfaction lies in the effort, not in the attainment." -- Mahatma Gandhi

i-corps training was designed for scientists and engineers. I am not the biggest fan of every aspect of the training, I am certainly no follower of Steve Blank; however there is a lot more to i-corps training than Steve Blank

one of the things is does is take product development and innovation as a process. I am not really in this project to "make a bunch of money", I am trying to create a device and platform that is fun, bridges tech gaps and helps solve problems I see and hear about.
now what i-corps teaches you is to get out there as early in the development cycle and start talking to your potential customers/user before you spend years and countless dollars on designing and developing something that is 'off-the-mark'. Plenty of things out there 'almost work', or solve a problem no one has.
So what I am doing now, while I am in the early stages of saying, "okay, wayfarer, you have this project and people are making all this stuff out of the chips you like, and they are really only taking it, so far. its a good time to try again and see how far you get in this thing." so now while I am still saying, what buss should I use, what kind of chip. how does some of this stuff Ive not looked at in 15 years work again? while I am at this stage, I am reaching out to people I might to use this and asking questions. That way I can make sure to address concerns or caveats they bring up. If I get out there and 25 out 40 people say "I need to teach rs-232 in my class", I will make sure thats on there. If a lot of them say "no, we would never use that feature or protocol, its so outdated now, not even legacy hardware uses it" I might drop it. Part of the modular design is that I can serve different needs of different groups, and I dont have to build this all at once. The primary device, is basically a 'superfied game tablet' and thats fine. There are other products out there, we are going to beat in terms of real capability, and still be using approachable hardware. My goal is a device and platform tht picks up where 'lets make this cool thing and never use it again because there are no more videos and assembly is hard' and goes to, "here are some useful tools and libraries you can work with and port to other hardware later". Some of that is Hardware. some of that is Software, and a lot of that, is Human Beings.

I know I want my device to run a 65816 and a really nice GPU, so it can have a nice screen.
I know I want my device to be expandable to other modules.
I know I want my device to have a good board controller and OS that lets users 'mostly just code for the 65816 and GPU'
I know I want my device to be durable.

I know I want an onscreen and attachable keyboard.

how I do those things, thats not set in stone yet.
I am pretty sure Im using an xt/isa/pc-card type bus, at 6 or 12 Mhz and maybe a pci bus, at 12 or 24 Mhz.
I am probably going to use a PIC for the board controller, and I do want mixed chip types and bit widths so that functionality, that requirement, is built in to the design.

making money is a concern, Im more worried about being solvent. crowdfunding is just one way to do that.
I am looking not only at an open hardware platform, and an open source OS, I am also looking at developing far more complex devices in the future, such as digital logbooks for truckers. This is the simple early project to start on before I do something bigger.

now my next project is to get the breadboard going with a 6502 and a few chips, and try to get a basic screen going, running some simple routines, maybe add a 6522 etc, get SPI going there or through a DART unit. My first experiments include physical RAM or ROM switching. Things take time. Im not really "in this for the money" , though this is one of the ways I am trying to bootstrap my business.

I am in this to create a really cool 65816 based tablet that plays some awesome games, (and probably has at least one port for connecting to and diagnosing legacy hardware) and maybe has some cool modules that expand its functionality. I am targeting education, artists, gamers and techies. I am planning to do a short run of 1000-10000 (or more!), Id like to get these going as soon as possible. I think 1-2 years is certainly possible. I am greatly thinking of launching a desktop project to go alongside this one too, something that can be hand built and start getting a community going. idk. I have to answer emails from chip suppliers and I have a question I wanted to ask here on the board that might help someone as well as myself. We might get PCI, and that would mean PC/104+ bus compatible or compliant designs might work with 65xx chips... idk, I'll see. Ti makes a nice PCI to PC-Card chip, the 1520. its in active production.

Good to see some hands-on activity to complement all the talking and planning! There needs to be a balance, so kudos for getting your hands dirty -- it's bound to pay off. I look forward to further news of your progress with this.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Talking to economic development board in the city, they suggested I use an old canning factory instead of new construction.
The lot I want is still available, though if I can rehab the existing building for less, it already has a rail spur. also talking with the Tech Transfer people for the university, they are saying similar things to what I am hearing here, though not quite the same.

More than 'start small'; they said 'identify a minimum viable product'.
So I agree that the Integrity, while a 'flagship' offering may not be the first project developed.
When we talk about MVP, its not just 'stuff on a shelf a package', its a blank PCB, a specific kind of capacitor, a piece of cable with connectors on it, anything I can sell. I see a lot of "custom PCB" stuff, however, I think I might be able to do something with that, stuff for prototyping and development. Small runs, one-offs and custom work things like that might offer some kind of basic revenue.

I might post a poll later to get a bead on what kinds of things you guys here are after in terms of this and several other forums.

Now from day one I have considered this a multiyear project, and I am now looking at breaking out a very small subset of the system to get working next. I want to focus on the "Red" section of the mainboard here, the CPU, VIA or similar and a clock can, maybe a few other support ICs and glue logic. I am starting to get sold on the idea of using a CPLD for saving board space on the support logic and boot vectors etc.

So, as Ive said before, I plan to go one piece at a time, get the main CPU+support section going, maybe get the "Big RAM Bank" going, add a GPU or the Board Controller, then the other, add sound, add the power unit. so yeah in two years or so I would like to get these made.

For now, I think I might look into some side projects that are easier to get something going.

I have considered a smaller/less feature filled version of this, however things like the DoDo fill that niche.
Unless, I can get decent e-ink or similar displays, it is a really tough call to try to push an 8 or 16 bit gaming, in b&w, device as anything more than a novelty. putting a pen in there, things like that, I am not certain I can leverage this the way I can the Integrity.

I am looking at PC/104 and EBX for desktop development and I am thinking an "integrity desktop development kit" might help with prelaunch.
So, I might make another thread to differentiate the different projects so there is not too much confusion.

Here, it is looking like getting a few things set up for prototyping is a good next step and looking at some PCBs I can build en masse, and to try to find a customer that I can start supplying. Some rare pcb for development or teaching or something I can make and just stay solvent, where a big shop might have too much overhead for it to be viable. I saw a lot of development boards out there for $65 or so, $50, for a bunch holes and pads on a pcb with pins soldered to it. Raw materials on this are under $10, if I have a less than $5000 in machines. I need to see if there is a market here.

Tooling up to make a few custom PCBs will give me the ability to start not only milling boards for development, I will have that mill for production later.

Not a lot to do here on this this week, except a lot of reading and a lot of phone calls. I think I'll start on a dependency list or similar chart, and further break down each section, to get closer to actual schematics and logic diagrams. I am itching to go buy parts, and I am making myself wait and do things in order. My next couple of days are out at the farm, I need to pour concrete in two weeks.

_________________
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?

yeah the market out there is pretty established. I am looking at some really niche products for embedded computing that have a really high mark-up. looking around here in this forum as well as others you can get or even 4 layer boards for under $10. the Tooling up on that is not something I am after right this very second. I have some ideas about how to solve some of these problems, basalt fiber instead of glass, a resin that is not as solvent/chemical heavy, shellac? idk yet, milling instead of etching, or using the new inkjet stuff for printed traces. Im still waiting to hear back on bus speeds and noise in the copper screen printed inks. The tests I am seeing show better copper screen print is about as good as bad copper sheeting. If this improves, a multihead printer for traces and solder paste is a go. Market wise, Im going to try to get my foot in the door on some embedded systems. PC/104 and EPIC/EBX.

right now I want to focus on getting established. I have an ARRL anniversary dinner to attend at the university tonight and I want to do a little networking. I said before the Integrity is going to take a long time and a lot of work to get going.

Smaller pieces are the way to do this, I am not sure if people understand my thinking, based on some things said here. Much of my life has been spent with great misunderstanding about my uh 'process' or whatever; it goes:

Goal: have a computer company, to make jobs for people and feel successful in a positive way
Goal: build the integrity, to show I can build more complex hardware and create a fun, useful tool while learning

Objective: get Integrity Hardware working
--core cpu
--memory
--board controller
--gpu
--soundchip
--peripheral port

Objective: get Integrity Software working
--stable core that system can fault to
--hardware monitor software
--GUI run with controller
--drivers
--memory instancing or multitasking
--API/C binding


Objective: get machines to make as much of the hardware for my devices as possible, to reduce reliance on outside forces
--PCB, buying, making and selling these are all simultaneously advantageous, correct application is key
--'passives' (probably going to be a lot cheaper to buy these in general, stockpile?)
--ICs, Ti has numerous NA factories, 4000 and 74000 are probably cheaper to buy, however 180nm process FAB desired.
--connectors, cases and enclosures, 3d printers, used HVAC sales for sheet metal duct forming machines to make cases and racks
--drills, mills, large format printers
--avoid EPA regulated and heath hazardous chemicals by design

Strategy: utilize university talent pool
Strategy: utilize open hardware and existing standards where possible, why reinvent a wheel (only if you need to roll sideways)
Strategy: have clear end uses and build toward those rather that 'see what you come up with'

Strategy: build what the user needs and wants
--Tactic: call potential end users and interview
--Tactic: attend trade fairs and take notes
--Tactic: read market trends

So, I am a very high level top-down thinker.
Right now, the best thing to do is start small. I agree, and I am shifting to the compucalc project right now, it will end up being half of the Core or "RED" section in the Integrity, along with a 6522 and such. Well a 65816 acting as a 6502 and these two devices will probably have a similar design.

viewtopic.php?f=4&t=7575

Without wishing in any way to denigrate your creativity and ideas here, what you're proposing looks awfully like:

• Idea!
• ???
• $$$

From reading your posts it seems to me as though you want to make a 'something' using a 6502 family part, and expect the world to beat a path to your door. I can't help feeling that while that may have worked in the 1970/80s, it's not something that is going to have a great deal of appeal these days... nonetheless, I do wish you the best of it.

Neil

I really like your vision and design process. You also have a realistic timescale. I started a similar process more than three years ago and I'm only beginning to gain traction. One of the things I really like about your design process is the consideration of different form factors. I particularly like the clam shell designs and the portable music system. These are similar to my own inspirations, such as a Totally Spies X-Powder or magical music player. While my influences are more similar to a Sony Discman, I see that you've had the same considerations regarding placement and function of buttons in a system where video display is optional.

My favorite design on the 6502 Forum (and in general) is Eris. The reason for this is quite simple. In addition to packaging the circuitry between two sheets of laser cut plastic, it defines a robust filing system and is supplied with a comprehensive suite of software which has been adapted to work with an operating interface - and this is defined as a macro. The default macro allows parameters to be passed via a 16 bit stack which grows downwards from memory address $7FFF. This is flexible but slow. Thankfully, it is as simple as could be expected to find faster techniques. I hope this can be used to empirically find the fastest and most flexible operating system interface. Other favorites include Planck for its generality (and idiot proofing), 6502GLD for its ruggedness and ABN6502 for its compactness. However, one complaint that I have with the majority of hobbyist projects is that they lack the Bauhaus School "form follows function". They look indistinct and they don't have a killer application. Whereas, numerous boxed Commodore inspired designs have been successful. This includes the COne, Mega65, Feonix and Commander X16. An Atari 800XL clone or successor may follow. Of particular note, the Commander X16 video system has been designed to implement NES style games and it is unsurprising that an unofficial port of MarioLand exists. If a 6502 design is packaged with more than two sheets of plastic then it has a fair chance of succeeding.

I've noticed a pattern of increasing frequency where someone develops an AVR/ARM/ESP handheld console system with buttons and a small screen. In the most ambitious case, thousands are given to tech conference attendees and a little "app store" is run for the duration of the conference. However, none of these arbitrary systems have gained traction. The most recent example I've seen - announcement in the Arduino section of Reddit - gained three comments and zero users. Educational systems are a greater waste of resources. I hoped that an educational system to teach spelling, read stories and similar might be useful. However, after attending my local trade toy exhibition, I've seen three heavily funded systems disappear over two years. Meanwhile, the Texas Instruments Speak 'N' Spell remains available with a larger screen, larger dictionary and better voice but is otherwise almost unchanged over more than 30 years. Damningly, we haven't advanced beyond PLATO, Speak 'N' Spell and Teddy Ruxpin (a creepy device similar to Chucky and M3GAN). So, your consideration of a clam shell book reader and other forms is essential. One of these will be more successful than the others.

You seek input from the 6502 Forum but you should consider the members as kindred developers rather than customers. Your fellow developers have very opposing preferences. Some strongly prefer bare metal access. Some prefer privilege protection. Many prefer assembly. Some prefer BASIC, Forth or C. Preference for 65816 may be equally split - although I am perpetually amused that people who dislike 6502 decimal mode are more likely to prefer 65816 and run Forth on it. The amusing part is that canonical Forth defines a stateful decimal mode. Regardless, I think that you have the most affinity with RadicalBrad and BigDumbDinosaur.

Among many interests, RadicalBrad developed a discrete processor on 30 breadboards and 80MHz video system on another 30 breadboards before developing a 5 volt, 20MHz 6502 system with 32 I/O strobes. RadicalBrad has also used the SPI output of an 8 pin ATTINY85 microcontroller to output 25.175MHz VGA. This is openly disbelieved by many. You might want to investigate RadicalBrad's philosophy and methodology. RadicalBrad has spent winters off grid and produced phenomenal results. BigDumbDinosaur holds the record uptime for a 6502 SCSI system. BigDumbDinosaur has considerable experience within the logistic industry and is acutely aware of its ad hoc requirements. This is used as a guide to develop a (possibly privileged) 65816 system primarily as reliable filing system, database and network hub for interpreted languages. BigDumbDinosaur is also one of our many musically talented members and may greatly appreciate 65816 with an electric guitar jack. Actually, I'm mildly surprised that your ideas haven't been savaged by BigDumbDinosaur. Consider this as a compliment.

Unfortunately, other members of the 6502 Forum continue the tradition of attacking newbies before they have "set out their stall". Welcome to the bear pit. While you've received some advice to use specific signals in specific circumstances, I advise:

• Read broadly.
• Gather requirements.
• Make a top-down specification.
• Make a bottom-up implementation.

Unfortunately, you have a combinatorial explosion of choices and this will only increase as more options become apparent to you. Given that you are focused on privilege protection, you will definitely require one bit of state - a privilege bit - external to a discrete processor or unprivileged FPGA core. You might find that discrete 65816 is detrimental because it draws more current and its bank switching is on the wrong side of the privilege bit. This may or may not be acceptable if 65816 is used in conjunction with other discrete 65xx peripheral chips. The reason for this may not be obvious to you. The 65xx peripheral chips typically accept multiple chip select signals. These may be used in multiple configurations. Historically, extra signals were used to reduce decode circuitry and access latency. More recently, extra signals have been used to distinguish idle bus cycles. Extra signals may also be used in conjunction with a privilege bit. Indeed, this may be applied selectively. One privileged 6522 may be reserved for MicroSD, banking switching and system timers while unprivileged chips allow fast I/O.

Historically, privilege violations have been handled within one bus cycle or within one instruction cycle. The major reason for cycle accuracy is virtual memory. However, modern systems deprecate virtual memory because it is too slow. Instead, memory is managed cooperatively. An application may receive an event to flush caches and a background application may be advised to serialize state. In this environment, privilege violation can be checked at the beginning of each system call. In this case, one bit of one register indicates privilege violation and the application is terminated before external state is affected. To elevate privileges, a doorbell to NMI is very fast. Indeed, it is even faster if NMI does not have to preserve flags or registers. NMI also acts as a global lock because no other execution occurs during this interrupt. Unfortunately, this type of singleton is unlikely to scale elegantly.

If downward compatibility with legacy software is not a concern then you could choose an unconventional memory map. Assuming 65816, it is possible to implement 257 banks. The EMU pin would select a legacy 64KB or native 16MB. In this arrangement, it is possible to place all I/O in the legacy or native memory map. Although, for your purposes, I'm not sure that either is an advantage. If the EMU pin is tied to clock speed then all access to legacy I/O is automatically slowed. Whereas, if all I/O is in the native memory map then one legacy application will be isolated from I/O. Unfortunately, if you want more than one legacy application, you may require a bank switching scheme in addition to the 65816's internal scheme. A third option would be placing slow I/O in the legacy memory map, fast I/O in the native memory map and using a separate privilege system. This is the type of choice combinatorial explosion that you'll encounter.

I've grappled with these choices and I've found it useful to enumerate then reduce cases. I started wanting to support NMOS, CMOS, 65CE02, 65816 and my own extensions. This has reduced to the subset of opcodes which don't have bugs or undesirable features (NMOS decimal arithmetic, 65CE02 decimal subtraction, 65816 JMP (abs) via bank zero) and processor feature detection to allow optimized sections. I have also chosen a widely hated memory map in which 48KB RAM, 8KB I/O and 8KB ROM appears in every 65816 bank. Following RadicalBrad's technique, I/O in every bank allows 2ns address decode (3ns at 3.3V) while allowing each application to optionally make Commodore or Acorn operating system calls. A slower, alternative address decode scheme allows use of Apple I/O at $C000-$CFFF concurrently with Commodore I/O at $D000-$DFFF. Yes, it precludes contiguous arrays larger than 48KB. However, it allows window manager and menus in one bank, desktop toys in another bank, filing system in another bank, text editor in another bank, compiler and assembler in another bank and application under development to run in another bank. Indeed, it is suitable for 63 compiled or assembled daemons/applications and a greater number of interpreted ones.

Commander X16 is a good example where "best of breed" choices have been combined. Most obviously, SNES joypads combined with Commodore operating system. However, this principle can be greatly extended. I discovered that SNES protocol can be used for keyboard and mouse. With minor changes to Commander X16 memory map, it is possible for Acorn BASIC to work concurrently with SID audio and Apple cards. Likewise, use of the Commander X16's VERA is not mutually exclusive with use of LCD or OLED. For example, visrealm's HBC-56 is a 6502 system with 56 pin bus connected to LCD and TMS9918A NTSC composite video. (Commander X16's VERA has separate memory map, similar to TMS9918A.)

I'm very impressed that you found 800*480 pixel bitmap LCD. However, I don't think that you'll find the perfect controller from existing supplies. I've also had problems with LCD and video output and this has similarly led me to display agnostic design. It is not only hobbyists who are affected. The cost, size and quality of displays has become very commercially sensitive. Given the finite area of display manufacturing capacity, it is easy to tell if Apple is going up-market or down-market with each change of specification. It is also an outsized cost. When version 1 of the Apple Watch was released, several companies produced teardown reports and an estimated bill of materials. I was quite surprised to discover that a hobbyist could make a single unit for less money - if the display is omitted. The result would be a StarTrek Next Generation style communicator badge. Understandably, I investigated capacitive touch sensing and trunked audio using cell networking. For a counter example, see Project Pluto where hobbyists replace the electronics of a Casio watch with 16 bit MSP430 microcontroller and accelerometer. Of particular note, the Casio LCD is typically preserved, although the cost of bespoke LCD is falling while capability is rising. Dave L. Jones of the EEVBlog has a short series of video where 100 units of bespoke passive LCD were designed with Inkscape and ordered from a manufacturer. Cost per unit was less than USD5.

I've sought circular, color OLED of approximately 100mm diameter. While smaller units are readily available, they are typically 300DPI, never less than 200DPI and never less than 8 bit per channel. For my purposes, 300DPI is more than 1 million pixels and more than 24 million bits of data to update the display. Understandably, a shape drawing language is typically used to send updates to the display. Otherwise, the volume of data to send is overwhelming. Unfortunately, most displays use the proprietary MIPI protocol and the cost of the specification is unaffordable to hobbyists. Even if we have access to the raw interface, I require 30 million pixel writes per second to smoothly update my circular display at 30Hz. You require about 40% of this for your rectangular display. (30Hz is a low standard and people now expect 60Hz or even 144Hz.) 65816 at 12MHz performing block copy can update 570000 24 bit pixels per second (19000 sequential pixels per frame at 30Hz) if it does nothing else. In particular, this excludes audio output. This covers almost 24 lines of your 480 line display. Even with a 24 bit blitter writing at 12MHz, 30Hz full screen animation is barely possible at 800*480. To further complicate matters, RadicalBrad recommends that video writes be eight times faster than display. This provides sufficient bandwidth for sprites and polygons to be composited.

A scheme is required which amplifies writes. Various techniques have been developed:

• HAM [Hold And Modify] modes are good for flat polygons and horizons.
• For textures, Quake's ModeX hack concurrently writes to four blocks of memory which are arranged on screen as four interleaved sets of pixels. Subsequent passes correct errors. However, this only works with write-back caching, write aggregation and deliberately blocky textures.
• Sprites allow clusters of pixels to be moved or animated with few writes. Surprisingly, some systems, such as NeoGeo, are sprite only. I've suggested that an 80 sprite system may also be an 80 column text system.
• Or perhaps 16*16 pixel characters overlaying a bitmap display. In this case, coarse updates for 256 pixels require much fewer writes while the remaining bandwidth can be used to update fine detail and provide sound.

Of course, the trick with using a text overlay for video is to find a good set of characters or implement them dynamically. A crude example of this is Bad Apple playing from counters and EEPROM onto the left of 16*4 character LCD (Part 1 and Part 2). This example does not use a microprocessor or similar but instead uses two tiers of ROM to expand common commands which are understood by the character LCD. It also uses the persistence of passive LCD to reduce apparent error. However, it uses a combination of predefined blocks and programmable blocks to approximate the silhouette of a standard video benchmark using an average data rate of approximately 5 bytes per frame. This type of technique can be used to greatly extend the reach of 8 bit computers displaying video.

A further consideration for implementing your own graphics controller is periodic interrupts. If the primary purpose of your device is to smoothly output video in any form then it is extremely helpful if the operating system or application knows when the next frame of video is required. This can be implemented using timer in 6522. However, this technique is subject to video tear if the timer drifts or does not start between frame updates. Furthermore, it is duplicated hardware and is a large, costly overkill when the overflow of the video row counter can be fed to the processor. For this reason alone, I envision you programming an FPGA LCD controller and avoiding CPLD. BigDumbDinosaur recently abandoned 65816 CPLD and this ignores the horrendous programming tools or energy consumption; which generally starts above 100mA for a blank device. Unfortunately, FPGA in production is generally 3.3V (or less). If you aim for 12MHz at 3.3V, this will be as challenging as 18MHz at 5V - something that BigDumbDinosaur achieved with POC 1.1 but not with POC 1.2 or POC 1.3. If you wish to use MicroSD, you will be forced to make some of your system run at 3.3V. It is only a matter of how much runs at 3.3V and for what reason.

There is a subtle problem with accompanying sound. I'm not a fan of FIFO but it would be required for high quality PCM audio. 6502 and 65816 can play audio on interrupt at 100kHz. However, 12MHz 6502 or 65816 playing audio at 48kHz receives interrupt every 250 cycles. Given that instructions take a variable number of clock cycles, there is jitter between interrupts and this changes the length of each audio sample played. With 7 cycle jitter every 250 cycles, audio quality may be reduced to 6 bits. A further problem is that 65816 interrupts in native mode require an extra cycle to save and restore the extra 8 bit of interrupted program address. This requires an extra 96000 clock cycles per second when playing 48kHz audio. That's 0.8% of the processor performance lost in native mode - in addition to 0.4% of performance per cycle of interrupt. Considerable processor performance and audio quality can be gained with an audio FIFO. Indeed, it is the only way to get sound above 10 bit quality.

It is maddening to find serial EEPROM is cheap and plentiful when parallel EEPROM is subject to shortages. Regardless, serial ROM is cheaper because 8 pin packages are cheaper. This is especially true for packages which are smaller than DIP. My plan is to make a system which boots from parallel ROM and provides a serial ROM decompressor. This allows a system which is entirely hosted from ROM without the full cost of a fully parallel ROM implementation. While a decompressor has latency, it provides a differing set of features. Most notably, partial materialization of programs which may exceed 16MB. Others have tried various techniques but all have limitations. drogon boots a microcontroller which populates RAM. This is fast but insecure. It also requires a co-processor which is more complex than the 65816 system, although it can be used for other purposes, such as UART and FPU. Some use CPLD to boot from Compact Flash. This is simple and the interface is fast. However, it uses too much energy for portable use, is insecure and the legacy stock of Compact Flash cards have limited storage capacity. Some obsolete 1 inch harddisks have a Compact Flash interface but this is even more restrictive given that less than 100 units may be available globally.

It is possible to interface serial ROM to 6502 or 65816 using CPLD or FPGA. The simple arrangement will be too slow because every read requires dozens of clock cycles while the serial read/write pointer is set before each byte of data is retrieved. Given that the circuitry is otherwise stateless, two such reads are required to obtain the vector for each interrupt and interrupt processing would be slowed horrendously. See Bad Apple over SunPlus serial ROM interface for example slowness and note that vectors are not retrieved from such interface. Thankfully, FPGA offers more advanced techniques. In this arrangement, the programmable logic holds the processor in reset while it reads and permanently caches all vectors from serial ROM. The processor then starts and obtains the reset vector (or any other vector) without delay.

I can see you designing a conventional 65816/6522 system with parallel ROM. This would be very easy to repair. I also see you implementing 6502/6522 with your own bank switching. Or 65816 with FPGA programmed as LCD/VGA/HDMI/audio/MicroSD/serial ROM interface. Or perhaps FPGA only. Or perhaps Raspberry Pi Pico only. It is too early to tell.

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