It is planned to be based on one of the existing 65c832 cores already available, though thoroughly enhanced.
The COP instruction will be replaced to be a vectored jump table with 256 vectors that intelligently know where they are jumping and sets the processor mode (8 16 32) and return to the mode it was in when it exits the routine.
This will allow for fast trampolining between modes and easily be able to call 8 bit code from 32 bit and vice versa.
It will also allow for minimal 8 bit ROM (since you can easily trampoline in and out), right now only 2kb of 8 bit kernel is planned, and 2k of IO in the first 64k, mostly trampolines to 16 bit space. This maximizes the RAM you can use in 6502 mode.
The WDM instruction will also be fully utilized, mostly for 32 bit instructions that can be used in any mode, so even if you are in 8 bit mode you can still touch every RAM address.. In general, if you want to use an instruction in 32 bit form, instead of lda #$80,x, you would do lda.l or lda.32 #$80,x. They do the same thing in 32 bit mode but the latter will always execute 32 bit in any mode (and will compile as it's 8 or 16 bit equivalent but with a $42 prefix).
OK back again.. I want to go over the planned hardware capabilities thus far, which I believe are fully reachable with the MiSTer FPGA or dedicated FPGA/ASIC mainboard config (which would in theory have all sorts of expansion options, from C64 expansions to PCIe devices (tho only if it reaches more than an FPGA implementation)..
The 65x832 (Expanded 65832) will not have multiplexed lines, as there is no real reason to try to stick it into a 65816 slot. If a hardware implementation to put one in a slot is desired, i'd rather have adaptive circuitry to do the multiplexing.
Instead there will be 32 real address and data lines, and 4x byte enables.
Expect this to have cycle exactness for 6502 mode only. 65816 and 65832 instructions will be optimized to execute "as fast as possible".
Expected speeds are 33mhz (for 133mhz rated chip ram) or 40mhz (for 160mhz rated chip ram). with lower compatibility speed modes.
The coprocessor line will still exist, but the instruction to invoke it will now be 42 02 xx (COP $xx), 42 xx Will be for vector jumps but have not decided what to call it yet, probably SVC $xx.
A partially functional MMU can protect memory pages (in 256 byte blocks) by treating them as ROM (ignore write), throwing an interrupt, or loading a block off disk and mapping it to a DDR3 location.
Multitasking and fast context switches will be implemented though the plan for that is not complete yet.
A VIX chip (Video Interface Expansion) for handling all modes, currently planned max resolution is 1280x720 with RGBA color, but this could become larger with more RAM expansion options.
It will also feature 256 sprites of arbitrary size (the whole screen if desired) which can also be used as parallax planes, the only limit is the amount of chip RAM available (standard size is 32m minus what is used by OS, programs, etc)
A SID extreme chip featuring 9 voices, 3 center/mono, 3 left, and 3 right. A compatibility memory map will allow you to use the center channels just like a regular 6581. It has your standard SID waveforms and ADSR, and all SID channels also have a 'sampled waveform' setting which will play back up to 64KB of raw PCM data at a time, and can be directed to play more by setting a continuation register. It also lets you record samples in a raw PCM format.
Options for emulating devices by trapping exceptions in the I/O area is available.
Hard disks, SSDs, and flash media of sizes up to 256TB will be supported. TRIM will be supported by the hardware.
Floppies with up 2 heads, 128 sectors and 256 tracks are supported. Sector sizes of 64KB are supported.
Theres much more, if you read the memory map, it changes often as I plan, so hit refresh once in a while.
i don't think its that much more complex than an Acorn Archimedes or an AGA Amiga. Somewhat more than an SNES though. It can be done on a MiSTer for sure. Alot of the new instructions for the CPU are the same as for the existing 65832 cores, just with an automatic promotion to a 32 bit mode.
That being said, if it does get too complex, theres a host of things that I can leave out (in fact the PCI/Zorro stuff is more of a plan for if it becomes an independant board, they can't be done on the FPGA. Perhaps I need a list of "definitely doable" stuff. The 6502, VIX, SID Extreme and MMU are all doable. And for I/O. well much of that stuff is supported by the ARM core on the MiSTer, so if it became a production board, it'd probably get a $5 tablet chip from China with 4 ARM cores and stuff..
I believe I will need more help when I have a little more to show (such as a processor core that actually works). Primarily I will likely need help developing the BIOS. The hardware design around the CPU is described here: https://public.kitsunet.net/832/Fox832MMAP.txt
As per the memory map, this is what I'd like to implement in ROM (for the 16/32 bit OS space)
GUI (Likely OpenGEM based at first): $F00000 $F5FFFF 384K ROM: 16 bit GUI (Workbench16)
The OS (Most work will be here): $F60000 $F9FFFF 256K ROM: 16 bit Kernel
Fonts (To just be stuck in the ROM): $FA0000 $FA3FFF 16K ROM: Amiga Topaz font (A1200/WB3.1 version) - Default font
$FA4000 $FA7FFF 16K ROM: Macintosh 68K Font
$FA8000 $FA87FF 2K ROM: Apple II font 256 8x8
$FA8800 $FA8FFF 2K ROM: NES font 256 8x8
$FA9000 $FA97FF 2K ROM: Atari ST font 8x8
$FA9800 $FA9FFF 2K ROM: VIC 20 font 256 8x8 PETSCII
$FAA000 $FAA7FF 2K ROM: Commodore 8 bit font 256 8x8 ASCII
$FAA800 $FAAFFF 2K ROM: Fox832 Extended character font 256 (accented chars)
$FAB000 $FAB7FF 2K ROM: Fox832 Window glyphs (for drawing GUI, ctrl chars)
$FAB800 $FABFFF 2K ROM: Fox832 Animal glyphs (Unicode 9.0 animal set)
$FAC000 $FAFFFF 16K ROM: Various in ROM Icons
This should be a port of BASIC 10.0 from the C65, with 32 bit POKE/PEEK: $FB0000 $FBFFFF 64K ROM: 16/32 bit BASIC (BASIC 10.0 based)
This should be the code supporting full screen editing of text files or programs. $FC0000 $FC3FFF 16K ROM: Full screen editor
A port and enhancement of the C128 sprite editor: $FC4000 $FC7FFF 16K ROM: Sprite editor
A capable SID player and composer with support for SID Extreme: $FC8000 $FCBFFF 16K ROM: SID player/Composer
A port and enhancement of the C128 monitor with code assembly: $FCC000 $FCFFFF 16K ROM: 8/16/32 bit Machine language monitor / assembler
Commodore compatible 1541/1571/1581 drive code, and other filesystems: $FD0000 $FDFFFF 64K ROM: DOS (Disk utils, DOS wedge, LL access routines, fat32, ext4, Amiga PFS)
A port of Forth (GNU Forth or other Forth): $FE0000 $FE7FFF 32K ROM: FORTH interpreter
Port Comal-80 straight from the cart: $FE8000 $FEFFFF 32K ROM: COMAL interpreter
CPU Memory (no porting needed): $FF0000 $FFFFFF 64K CPU memory / ROM bootstrap
The hard part about designing this is that I keep changing it up. While all of the components above are likely to exist in the final core, their memory addresses change all the time as I fit things together in memory..