MSX FPU - coprocessor by TecnoBytes

Wow, but wanna see a demo first

What would be the use of MSX3? What would the advantage of a MSX3 standard be?
MSX is way to limited by:
- the 8 bit architecture
- the slow processor speed
- limited graphics
- number of useful applications (games, and .... )
- number of serious users

I really respect the people that make extensions for these computers, but they will not solve the listed fundamental situation that MSX is a 30+ year old architecture that has never been modernised. I do like my MSX system: but there is no future in it, thats my opinion.

It would be nice if this device could do floating point and integer(16/32/64 bits) matrix operations like: multiplication, inverse, adition, determinant, ... https://en.wikipedia.org/wiki/Matrix_multiplication.

small demo movie: https://www.youtube.com/watch?v=LUNgGoDa-vI

Is it an FPU or a Microcontroller based "Co-Processor" which can be reprogrammed from MSX side?
The Demo itself in the video above seemed to show just some sine wave based movements?

Nha this is progress. Love v9990. Hope for a good way to use it in basic

@tfh, that proces started the moment the external hardware got faster and smarter than than the actual machine. From a performance perspective, we are abusing electronics that can run at GHZ speed so that it can do something for a 3.85 (or 7 or 20 Mhz) system.

I still remember my first upgrade on my Amiga 1200. Connecting a PPC, a PCI system bus, an AMD card and a SB Live card. All components together degraded the Amiga motherboard to the biggest cartridge ever designed. MSX has gone the same way

I like Prodatron's remark: "can be reprogrammed from MSX side". I can imagine a flash operation that turns a piece of programmable hardware in to a MP3 player or another function that is usable over the connector.

Is your PC downgraded if you put a new soundcard and a new graphic card? No. Even you put a new processor... is still your PC.

Same happened in my Amiga 1200, I had a 68030 50 MHZ, 68882 FPU and 64 MB RAM expansion card. Also a Compact Flash reader PCMCIA and the Indivision AGA graphic enhancer... was my Amiga 1200 downgraded? NO, it was UPDATED.

Good if it add BIOS accessing and the appropriate MSX standard extensions. OPL4 and GFX9000 lacks of them, are not really MSX compliant peripherals.

@Daemos FPU is really for accurate vector working. For 2D standard work fixed-point is enough. Even Nintendo DS has no FPU with so many polygon games. So FPU is more really for accuracy.

If it becoms cheap hardware more ppl wil buy and faster software will be made

In fact I've explained this tecnique several times in this forum.This technique is a out of box(The box is: MSX cannot do bus request, so an external processor cannot be the master processor. DOT) way of thinking,very simple like the Colombo egg. To fully understand the possibilities one must think as a software and hardware tecnique bonded together. Thinking in the other way don't work.Thinking in the conventional way we learned on books(The processor run IO instruction as a master) don't work too. The external processor (for example the ARM on MSX-ARM architecture or the MSX FPU processor) generates the MSX Z80/R800 instructions on the fly. Doing this way using optimizations we can achieve high transfer rate(very close as Z80 DMA). See below some examples.
This techinique can be spreaded even more. In my MSX-ARM architecture the ARM processor ONLY emulates the Z80/R800 processor. All data transfers to real peripherals like VDP,PPPI generates Z80 opcodes(real time) on MSX host(Z80/R800 zombie mode). This even can sincronize both real Z80(3,58Mhz) and the Z80/R800 emulator on MSX-ARM, so one can load cassete(Z80 cycle must be accurate) data running the Z80/R800 on ARM! I've tested all this "Z80 zombie mode" tecniques on MSX-ARM prototype and on my MSX-ARM simulator software development kit (AKA Konami HP64000). In some weeks I'll post a video demostrating a MSX 2++ running as a MSX Turbor on MSX-ARM SDK by using the "Z80 zombie mode" tecnique.

Here (http://www.symbos.de/sf2.htm) is another example where the "Z80 zombie mode tecnique" could improve the data transfer rate: See the specs where the author claims that this hardware can transfer data at 162KB/sec using the fastest LDI/LDIR(On all Z80 books the fastest I/O instructions is LDI/LDIR) instruction. Using my tecnique this could be even faster.

This is a another MSX card that could be using the "Z80 zombie mode" tecniquie: http://msx.deneb.nl/page10.HTM (Z380 card)

---+ Here some simple examples:
-- Output port without optimizations
ld a,#0
out (nn),a
ld a,#1 ; 7 cycles
out (nn),a
ld a,#1
out (nn),a

-- Out port, above with optimizations. The ARM processor do this optimization
xor a ; "xor a" is faster than "ld a,#0"
out (nn),a
inc a ; 4 cycles "inc a" is faster than "ld a,1"
out (nn),a
out (nn),a ; Same value

-- Input port
in a,(#98) ; the device capture 1 byte on bus. On MSX-ARM the FPGA capture this
in a,(#99) ;

-- Read memory
ld a,(nnnn) ; the device capture 1 byte on bus. On MSX-ARM the FPGA capture this
ld a,(nnnn) ;
ld a,(nnnn) ;

-- Write memory
ld a,11
ld (nnnn),a ;
inc a
ld (nnnn) ,a;
xor a
ld (nnnn),a ;
xor a,b ; the ARM know the Z80 registers so it can do some optimization
ld (nnnn),a ;
ld (nnnn),a ; Same value

-- Busrt mode write memory
ld sp,destination
ld hl,data
push hl
ld hl,data
push hl

-- Busrt mode write memory. memory set (memset) as fast as Z80 DMA
ld hl,deviceAddess
ld a,value
ld (hl),a
ld (hl),a
ld (hl),a
ld (hl),a
ld (hl),a
ld (hl),a
ld (hl),a
ld (hl),a
ld (hl),a
ld (hl),a

---+Here some advanced examples:
------+ Burst mode: Read memory
High performance data transfer from Z80 to device. Only 4 cycles/byte(on MSX 5cycles/byte)! The MSX-ARM uses this high performance tecnique to get the MSX ROM's

di ; On MSX-ARM we don't need this
ld sp,buffer
pop hl ; the device capture 2 bytes on bus. On MSX-ARM the FPGA capture this
pop hl
pop hl
pop hl
.
.
.
pop hl
ei ; On MSX-ARM we don't need this

-- Busrt mode: write memory with optimaztions
ld sp,destination
ld hl,data
push hl
inc hl
push hl
push hl ; Same value
push hl ; Same value
push hl ; Same value
dec hl
push hl ; Same value
push hl ; Same value
push hl ; Same value

If someone is going to design such a thing, it would be better to internalise this cartridge, because of the connector you need: midi, VGA,stereo etc.

The ultimate MSX is called PC and it has all the hardware ever designed for MSX integrated. There is no market for major upgrades to MSX.

It appears that the unidentifiable(see my previous post) chip is a high performance RISC CPU, 68 pin PLCC package PIC18FXXXX, 16 bits PIC microcontroler from Microchip. I think it could use one with DSP extensions(Like the Intel Streaming SIMD instructions). It's a good processor to be a MSX FPU unit! PIC microcontrollers are comparatively inexpensive and easy to find and is 5 volts ready like the MSX.

Reading the dataheet , it appears to be a PIC18C658 chip. See the MSX FPU board layout. Pin 40 is the oscilator input (RC1/OSCI) and the board layout show this! The powered(VCC,GND) pins appears to be on the right pins. I think the processor is OVERCLOCKED because the max frequency specified on datasheet is 40Mhz and on board there is a 50Mhz crystal. This is a 25% performance boost!

This processor (PIC18C658 ) executes 12.5 milions(with 50Mhz crystal. OVERCLOCKED) instructions(16 bits RISC) per second. The MSX Z80 executes only <1 milion (3,58 Mhz, 8 bits CISC) instructions per seconds and R800 executes <7 milions instructions(7Mhz, 8 bits CISC) per second.

Micrcontroller Datasheet:
http://www.microchip.com/design-centers/16-bit
http://ww1.microchip.com/downloads/en/DeviceDoc/30327b.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/30475a.pdf

Awsome Integrated Development Environment :
http://www.microchip.com/mplab/mplab-x-ide
http://www.oshonsoft.com/pic.html IDE with PIC simulator. One can program the PIC chip on simulator exactly the same way I'm developing on my MSX-ARM simulator suite SDK

PIC 16 bits math libraries:
http://picfloat.sourceforge.net/ : Open source(BSD license) PIC 16 bits math libraries

Philips Music Module has not MSX AUDIO bios...

Anyway, are you really telling me that a hardware update and expansion is not MSX? We are now on 2016, not in the 80s.

I'm following it, I thinks that it's more promising upcoming hardware for MSX :)

I feel that MSX expansions are more oriented to users than developers, simply look at figures: after 20 years of GFX9000 and OPL4, no game finished for GFX9000 and only 5 finished games for OPL4. More figures: practically no games for MSX2+ made by comunity.

I mean, MSX don't need new hardware, we allready have unused hardware waiting to use it. A good example: a big adventure for MSX2 using hard disk. Clearly a step forward in software taking advantage of a underused device as interfaces IDE / SD readers. This aproach to making of games could generate a new wave of great games for MSX2.

The main problem is the lack of time, not the lack of hardware.

The opl4 is a different story. It is for the most part register compatible with the msx-audio . They share the opl1 registers. Even the hardware can be set on the same ports. Also the audio bios has been adapted for opl4.

Both UMAX titles support Moonsound; but are they available?, since the demise of Sunrise I'm not sure if they have been freed or must be purchased from anyone.

Besides games there is a lot of opl4 software

Kai Magazine: if that's all true then that is great news.

To get back on topic: if anyone/ any group is interested to work with this FPU on an application or game, i'm willing to sponsor 1 for that purpose.

@spl Are you sure that Music Module lacks of BIOS? https://www.msx.org/wiki/MSX-AUDIO

32Kb BIOS is required for MSX-Audio standard.

ppl be hapy! more msx hardware!

From MY designer point of view, it's more pratical to improve the MSX Z80/R800 processor speed(improved BASIC speed) by running the Z80/R800 on an external processor hosted in a cartridge. All applications would run faster without any hook/patch and almost(I/O device speed like the original VDP throughput cannot be improved) all MSX performance issues would be fixed only one time(the app could run on a fast Turbor or a 3,58 Mhz Z80 without such accelerator device too. no hardware lock).
For example, a Z80/R800 hosted in a cartridge, running at 80Mhz would improve BASIC float point/integer processing speed by >22 times. From some users point of view, this can be evil .

Yes, the ARM cartridge behaves as a faster Z80/R800/RAM memory. Keep in mind that only the processor speed is improved. All input/output device access behaves in the same way.(In fact even here can be slightly improved.see my previous post about the "Z80 zombie mode" tecnique).

I already have a working Z80/R800 running on MSX-ARM SDK suite. It passes all ZEXDOC(Z80/R800)/ZEXALL(only Z80).
Experimentally I coded a 6502(run at 16Mhz) emulator in ARM assembly based in this opensource project (https://github.com/BigEd/a6502) . The 6502 have access to all MSX memory(mapper) and devices like the VDP. It's is experimental and I'm not intended to be a MSX-ARM feature(only for fun). I've added a Z80/R800/6502/ARM disassembler on MSX LUA shell interface.
I'll post a demo in some weeks.

There is MSX-ARM simulator + software development kit.

This tool is intended to be a low level software development kit to the core developers and collaborators. At this time only popolonky2k is a collaborator.

It simulates:
- MSX host and the MSX-ARM cartridge interface (implemented on FPGA on the real cartridge)
- Serial RS232. It appear as a "COM4" on Windows. :)
- MIDI serial. It appears as a "COM5" on Windows.

The MSX-ARM simulator + software development kit is composed of two high advanced/modern tools:
- openmsx http://openmsx.org/ MSX emulator.
- ARM KEIL MDK: http://www2.keil.com/mdk5/simulation/: ARM Cortex M4 simulator + IDE

In fact, the openmsx is a modified 0.12 version (https://github.com/rogeriomm/openmsx/commits/cartridge_plugi...) that supports dynamic libraries (DLL) generic cartridge plugins. One can develop a emulated cartridge without knowing the openmsx internals(tons of high quality C++ source code). I've coded a MSX-ARM DLL plugin that exchange data with the ARM KEIL MDK using a "shared memory". The youtube video description show more about he technical details.

The question is: Is a high performance 16 bit PIC microcontroller(see my previous post) running 12.5 milions(comparatively an ARDUINO UNO runs at 16 MIPS - 8 bits) of RISC instructions per second capable to do this in this speed ? In this video there are 8 independent objects running fast. We need 8 independent physical calculation? I don't know exactly how to do this but my bet is that it can. I think the team is working on a more advanced demo like this one.

Ah, it might be that I got you a bit wrong...

The demo was made mostly on BASIC using standard MSX tR... On 3.5MHz MSX you can run 4 objects at about same speed using same BASIC program. The calculations are pretty much just calculating angle, distance and multiplying by forces of neighbor items, gravity & inertia. Even without any boost cartridge this kind of stuff can be made quite a bit faster by using correctly optimized algorithms and less BASIC floating point numbers... but naturally with a FPU this kind of stuff becomes a piece of cake.

In the facebook there is a comment from "Timo Soilamaa":

ell... actually "physics engine" is quite a bit over advertisement. :-) At the moment it is only a ML code to return distance & angle between any given points as fast as possible (input 8bit). The thing is that these are the things that you need in physics calculations, but they take A LOT of time in BASIC to calculate... How ever I'm not finished yet..."

All the guys from Tecnobytes are closed friends of mine, one of them lives near my home, so I have some "inside information" that I can't reveal yet.

But there are some info which can be told to you:
- it's a FPU, it isn't an ARM processor. And if I tell you which is FPU is that, I will need to kill you all.
- I suggested them about something like the Apple II Pi project, it would be nice, and they said: "Oh, great idea, maybe we can think about it in the future!" *_*
- they think about the FPU be sold in affordable cartdriges, so everyone can buy it. :)
- maybe we'll all need slot expanders. :D
- we'll have new info about FPU soon. As I have been told, Tecnobytes wanna tell the specs soon, in order to help software development (and emulators, like OpenMSX and BlueMSX).
- Tecnobytes is working on hardware (almost done), and the guys behind Old Bits Dev Studio are doing all software part. The FPU's idea started when they were talking and drinking after a MSXRio meeting, in 2013. But it's something that I say since 1998: "Why not we have some powerful processor running as a coprocessor for Z80?" Maybe our praying would be answered soon. :RNFF:
- As a mathematician and a Pascal programmer (but a very rusty one), I offered my help, even got some (a lot of) math libraries, in order to develop math libs who really want to use all FPU's potential.

Maybe we'll have some interesting news in the near future.

Ricardo.

Maybe a eZ80 implementation? https://es.wikipedia.org/wiki/ZiLOG_eZ80.

It would be something similar to improved Motorola expansions launched for Amiga.

LUA interpreter VM for Z80? https://www.cemetech.net/forum/viewtopic.php?t=11194

I don't explained all "Z80 zombie mode" tecniques. The initial concept like I explained in my previous post is very simple, but more complex issues like this one requires more complex solutions.

Let me build a scenario to answer your question more precisely(sorry about my dirty english):
---+ Host Computer: Panasoniq MSX 2+ WSX, 64KB RAM
-------+ Cartrige slot 1: MSX-ARM running in "host mode". MSX-ARM can run in "slave mode" too but I'll not explain here in details. In slave mode the Z80/R800 don't run on ARM. The ARM is a slave from MSX, but it can run the MSX LUA too.It can use the MSX-ARM peripherals like the SD/MMC and others! Here there is a example of MSX-ARM running MSX-LUA in "slave mode": https://www.youtube.com/watch?v=bEIdZhM_kcA
Since the MSX-ARM "host mode" is seen as EVIL to some users, the "slave mode" is more attractive to then.
One can think the MSX-ARM "host mode" in the same way this Padial Z380 cartridge card works
-------+ Cartrige slot 2: Sunrise IDE - There's a ROM BIOS and some I/O ports mapped on slot memory.

---+ Algoritm
The Z80/R800 that runs on ARM:
1- uses the MSX2+ ROM BIOS and RAM/mapper that is mapped on ARM memory area. This work in this way because the MSX host memory is very slow. On MSX-ARM boot, the ROM's are filled. External ROM cartridge access like the Sunrise ATA is managed in other way.
2- redirect all IO ports (IN A,(NN), OUT (NN),A) to MSX host(MSX Panasoniq 2+ WSX) using the "Z80 zombie mode" tecnique. There is an EXCEPTION. The out/in port that changes the slot(PPI port A) is not redirected to MSX host host, since threre is ROM/RAM/mapper RAM mapped on ARM memory area.
3- Runs the Z80 code on external Sunrise IDE ROM. Since the Sunrise IDE ROM is mapped on a slow memory the ARM transfer this ROM to ARM memory(CACHE, See too: https://support.microsoft.com/en-us/kb/78528 ) on the fly, on the ARM/Z80 first access(almost same tecnique used on a modern operation system to swap memory on disk). This is done efficiently/transparently by the ARM MPU and using the high speed "Z80 zombie mode" burst mode data transfer(Using POP HL instructions, AT SAME SPEED OF A Z80 DMA CHIP , 5 cycles/byte ). Currectly I have done some tests and it's works on my MSX-ARM simulator & SDK suite, but it needs improvements.

4 - redirect all cartrige slot 2(Sunrise IDE) access to MSX host(Panasoniq WSX) using the "Z80 zombie mode". If the memory access is a Z80 opcode, then the ARM writes the Sunrise ROM on CACHE(1 KB granularity ), otherwise it's a I/O port(in this case Sunrise IDE) mapped on memory (no cache). This algoritm works dynamically and don''t need to know what device is on the cartridge!

-----------------------------------------------------------------------------------------------

Yes I know. It's really complex to manage all these tecniques. Almost all these tecniques was already coded/tested though. But keep in mind that other complex MSX projects like the Procyon,OCM, ... are on the same(maybe more) level of complexity! Very soon I'll post a video about these tecniques in action.

I think all MSX-ARM "host mode" core tecniques was explained. Let me know if these all tecniques was understood :) Maybe there is some flow in these tecniques too. Let me know!

can it run p3bios
https://sites.google.com/site/tueftlerlabs/home/downloads/p3...
the diskette boots into a slotviewer.
it runs an IM2 server in page 3.

Most of MSX devices until now uses tecniques that are well known, so it is more easily understood. The MSX-ARM architecture is a mixture of these well known tecniques + modern concepts of virtualization. Anyway my bad english don't help either

My previous post describes this in details. All I/O mapped in slot/subslot memory and i/o instruction(in a,(nn)) can be redirected to real chip. The only exception is the PPI port A that controls the slot on MSX host and the memory 0xffff that controls the subslot on host.
The Slot/Subslot on host is managed by ARM using a carefully coded algoritm.
The MSX-ARM can manage cartridges on subslots, but the MSX-ARM itself cannot be in a sub slot! It was done in this way because it's more efficient to work on a primary slot in "Z80/R800 zombie mode".

All memory mapped MSX host I/O devices are mapped on the ARM memory by using the protection unit unit(MPU) to improve performance. It's almost some tecnique used on modern operation systems to swap memory on disk

The MSX Z80/R800 host works on IM2 mode, but the Z80/R800 running on ARM can work on IM0,IM1,IM2 transparently. The Z80/R800 on ARM don't need to know that it's running on ARM. The MSX ROM's on ARM don't need patches!

I think that it's possible to work on zombie mode without enabling the Z80/R800 host interrupts(the IM2 table is off) as you suggested. The ARM interrupt could be connected(The FPGA can do this) on cartridge interrupt pin. I have to do some tests on real hardware to know if this work on all MSX(I think that Tecnobytes have the answer, because they know the MSX hardware very well). The MSX hardware wasn't designed to allow(I think it was a strategic business policy, since a BUSREQ/BUSACK pins could be in the cartridge without extra costs) an external processor do most of work(UNTIL NOW) as MSX-ARM do. My current solution using the IM2 is more safe and I know that it's work on all real MSX hardware

The MSX-ARM cartridge has a 8KB RAM(within FPGA) that is shared(on MSX-ARM simulator it's a Windows shared memory) with ARM. On boot the MSX-ARM write 4 tables of 256 bytes on shared memory. The zombie mode handler (See previous post) page (0,1,2,3) can be fastly relocated by changing the register I(using the zombie mode tecnique).

Here there is small ARM C code snippet of IM2 intitalization rotine. It also shows the MSX magic numbers 0x41,0x42 beeing filled by ARM

/**
* MSX cartridge initialization code. Preparation for MSX zombie mode operation
*
* @See File "TH-5B.TXT" line 679
*/
static uint8_t msxCartrigeRom[] =
{
// MSX cartridge header
N(0x41) // 4000 |
N(0x42) // 4001 |-> Catridge header: ID, magic code 0x4142
// In the case of ROM cartridges, these two bytes
// have codes "AB" (41H, 42H). For SUB-ROM cartridges,
//the ID is "CD".

NN(Z80ADDR_ZOMBIE_PROC_INIT) // 4002 |
// 4003 |-> Catridge header: INIT

NN(Z80ADDR_ZOMBIE_PROC_STATEMENT) // 4004 |
// 4005 |-> Catridge header: STATEMENT
// The statement expansion routine should reside at
//4000H to 7FFFH. FIXME Z80ADDR_ZOMBIE_STATEMENT #error

NN(Z80ADDR_ZOMBIE_PROC_DEVICE)// 4006 |
// 4007 |-> Catridge header: DEVICE

NN(0x0000) // 4008 |
// 4009 |-> Catridge header: TEXT none

0x00, // 400a Reserved should be filled with 00H.
0x00, // 400b Reserved should be filled with 00H.
0x00, // 400c Reserved should be filled with 00H.
0x00, // 400d Reserved should be filled with 00H.
0x00, // 400e Reserved should be filled with 00H.
0x00 // 400f Reserved should be filled with 00H.
};

/**
* MSX host was reseted
*/
bool onCpuReset(void)
{
// Copy MSX ROM cartridge initialization code
// Preparation for MSX "zombie mode" operation
if(!memShareCpy(msxCartrigeRom, sizeof(msxCartrigeRom)))
return false; // Failure

// Set 128 Z80 interrupt vectors that point to same interrupt handler
memShareSet16(0x0100, 0x0080, 128);

// Set 128 Z80 interrupt vectors that point to same interrupt handler
memShareSet16(0x0200, 0x4080, 128);

// Set 128 Z80 interrupt vectors that point to same interrupt handler
memShareSet16(0x0300, 0x8080, 128;

// Set 128 Z80 interrupt vectors that point to same interrupt handler
memShareSet16(0x0400, 0xc080, 128);

// Page 2: 0x4000
zombieHandlerPage = 2;

return true; // Success
}

It could need some rotzoomer demo videos.
The flair at first sight is "something is going on over there in a lonely chip".
If you could demo the motherboard z80 ending up with OUTI OUTI vram transfer speed.
Then the whole thing turns into a different story.
Maybe the ZX goblins port is a good example demo.

Congratulations hit9918, about asking the "OUTI" instruction implementation on "zombie mode". it's a key concept, since it's the fastest data transfer instruction

@Rogermm,

Probably due to my lack of technical knowledge, but I don't understand what MSX-ARM exactly will bring from end-user perspective.

Could you explain what your end product will do? What am I (user) able to do with it?

Thanks,

a cpu cartridge has good potential
faster
easier to make
the slots dont go wrong
as a bonus it can be plugged into classic MSX

fpga makers dream of making it with pimping the timings of all chips.
but look at this

	+------------------------------+
	|gfx 9000 original 9990 timings|
	|memory mapped dual ported RAM |  in zombie mode this appears like plugged as cartridge into classic slot
	+------------------------------+
                       |
        [-----new generation slot-----]
                       |
              +------------------+
              |      SUPER       |
              |      FAST        | ------ RAM + zombie softwares
              |      CPU         |
              +------------------+
	               |
               |little pipe  RAM|         shared z80 acess without main cpu slowdown. main cpu needs atomic acess, minimum 16bit on even address, to patch looping JR opcodes.
                       |
        [--------original slot--------]   "south bridge" = one of the classic MSX slots
                       |
	      +------------------+
	      | classic MSX arch |         no pimping. slots dont go wrong.
	      +------------------+

whether this is in one fpga or a cartridge plugged into a classic, it's the same arch.
a cartridge could have the new generation slot connector, too.

the zombie idea enables a pile of wonders.
prime example, the big woes of TurboR is that it has MSX1 speed vram transfer.
if cpu cartridge feeds OUTI OUTI to z80 then an MSX2 gets beyond TurboR vram speed. While still having a fast cpu.

in 32bit mode the arch does more wonders.
the z80 is running PARALLEL. it can do all the classic "south bridge" jobs while the ARM runs free.
meanwhile the ARM could do realtime mpeg decoding in parallel.

development efforts:
use all the existing nice flash cartridges etc and the same old diskROMs.
a giant pile of work of the project "32bit turbo, 32bit OS" was saved.

observed effect:
"the 32bit MSX with DMA".

At this point, I'm missing the conversation. One question to hardware designers: do you have asked developers to their needs? I mean, making a hardware because if has no future, sorry for being so negative. The first step to design a new hardware is to ask developers what are the lacks on MSX standard.

I can't imagine any real usage of adding FPU to a slow Z80 3,58Mhz CPU, it should be clearly better option to improve Z80 by itself with a faster implementation.

An implementation of Z80 "zombie mode" and a Z80 cpu core totally in FPGA is possible, but I think it's more easy to implement the zombie mode handler on another cpu core that do the bridge between the host MSX and Z80 core. A Z80/R800 FPGA core with 32 bits extensions can be done too.

Using an ARM instead of FPGA Z80/R800 core,easier a lot the implementation. Extending the Z80 8 bits instruction set to 32 bits, can be done using a invalid Z80 opcode to change the CPU to ARM. Since the ARM registers are mapped on Z80/R800 registers, the ARM code can thinked as a Z80/R800 32 bits extension. Below there's a mapping table of MSX-ARM Z80&ARM 32 bits extension:

|ARM register    | Z80 register  |
|r6                    |  PC               |
|r9                    |  BC              |
|r10                  |  DE               |
|r11                  |  HL               |
|r12                  |  SP               |
|r7                    |  A                |
|r8                    |  Flags           |

Running an invalid Z80/R800 opcode change the CPU to ARM. Running the ARM instruction "bx lr" change back to Z80/R800
Coding small snippets of Z80/R800/ARM opcodes can build powerfull instructions like floating pointing/integer. It can be coded as a macro using a powerfull macro assembler TNIASM in the same way 萌ＳＸ is planning to do on FPGA Z80 with 32 bits extension. Using the existing tools mixed with new ones, and MSX console/cartridges can improve the MSX without losing the essence(my point of view).

The zombie mode handler have to be smart to know the VDP screen mode beeing used by MSX application, to slow down some VDP data transfers, in the same way Turbor do . But since the ARM have a lot more resources than the Turbor S1990 chipset, it can done in an optimized way. This is a key concept :) .Note that the Z80/R800 application running at 80Mhz don't need to worry about VDP data transfers limitations!
I didn't implement this optimization yet. ! MSX-ARM can run without optimizations!

The Z80 running on ARM can be 100%(not 99.99%) syncronized(Not implemented yet) with the real Z80(3.58Mhz) on MSX host. This enable existing games to run o MSX-ARM "host mode" 100% speed compatible. The zombie mode handler VDP optimizations as described above are disabled, since the application must coded to do VDP data transfer in the right way.

MSX-ARM already do in this way(See my previous posts). The Z80 out port write on output pipe on FPGA and don't wait the instruction execute on Z80/R800 host. It runs the next instruction while the FPGA is feeding the Z80/R800 host. The pipeline is broked when the Z80/R800 on ARM run the instructon IN A,(NN).

The realtime mpeg decoding can be implemented using the MSX-ARM Z80/R800 32 bits extension as I described above. A FPU library can be builded in this way too. The only application I planning to be running on internal ARM Flash is the MSX LUA

You're describing to work on this new MSX 32 bit operation system in the same way the legacy DOS 32 bits extender or the Windows 3.1 that run using the existing 16bit operation system Microsoft DOS!

I don't planning to provide a full 32 bits MSX OS.
I implemented the Z80/R800 & ARM 32 bits extension and the MSX I/O host primitives that one could use to code a new 32 bits operation system! A developer can feel safe(no lock on hardware) to waste time coding on MSX-ARM since the application could run on another MSX cartridge running on ARM and using the Z80 zombie mode tecnique already described in details :) Note that the ARM Cortex M4 or M7 don't have a MMU(it have a memory protection unit thown), then it cannot do physical /logical memory translations as the modern operations system can do!

It demands a lot of work to build a faster Z80. A FPU cartridge demands less work and have more chance to be a successful product instead being a "VAPORWARE" project.(my point of view )

Anyway, even a faster Z80 8 bits processor cannot (MSX-ARM can use the Z80 32 bit extension to run float point intructions thown) do floating point operations at same speed of a dedicated FPU unit as MSX FPU is supposed to do! I don't know how advanced physics engines works and the performances issues involved, so I can't tell if such power could be used efficiently with a slow Z80 8 bits microprocessor and an advanced V9990 VDP

I think that when Tecnobytes team post a really fantastic demo video, the slow Z80 CPU issue will be forgotten and even you(and me) will buy it

It's my fault. I don't master all aspects of VDP data access temporization. I did some researches only to know that it's possible do data transfer to/from VDP in an efficient way. My current implementation don't do these performance optimizations since MSX-ARM can run without it.

Even on MSX-ARM running on MSX2/2+/TurboR host, the data transfer MUST be slowed down since the Z80 zombie mode handler can optimize to an even more fast instruction than OUTI. The ARM knows the Z80 host register, so it can be used to do some optimizations! See bellow some examples:

|--------------------------------------------------------------------------------|-----------------------------------------------------|
|Z80/R800 80Mhz on ARM                   | Z80 3.5/5.4 MHz   zombie on MSX host  | Comments                                            |
|----------------------------------------|---------------------------------------|-----------------------------------------------------|
| ld a,1 ; out (nn),a; ld a,2 out(nn),a  | ld a,1 ; out(n),a ; inc a; out (n),a  | ARM tests several Z80 instrucions to get the result |
| ld a,34; out (nn),a; ld a,0 out(nn),a  | ld a,34; out(nn),a; xor a; out(nn),a  |                                                     |
| ld a,66; out (nn),a ld a,66 out(nn),a  | ld a,66; out(nn),a; out(nn),a         |                                                     |
| ld a,00; out (nn),a ld a,ff out(nn),a  | xor a; out(nn),a; cpl; out(nn),a      |                                                     |
| ld a,00; out (nn),a ld a,20 out(nn),a  | xor a; out(nn),a; add a,e; out(nn),a  | ARM know that register E=20                         |
| ld a,1;  out (nn),a ld a,2  out(nn),a  | ld a,1 out(nn),a; rlca out(nn),a      | ARM tests several Z80 instrucions to get the result |  
|--------------------------------------------------------------------------------|-----------------------------------------------------|

The MSX-ARM can speed up a the V9990 data transfer(faster than OUTI) if the data patterns sent to the "Z80 zombie mode" handler can be optimized in this way ! I think games work in this way(example: a wall being displayed on V9990)

MSX-ARM running on Panasoniq at 5.4MHz + V9990 + "Z80 zombie mode" pattern optimization = a lot of performance using a standard MSX hardware

All MSX LUA commands that send/receive data to MSX host can use the "Z80 zombie mode" pattern optimization as described previously

MSX-ARM can run on MSX-1, so it must slow down the VDP data transfer in TURBO MODE(Z80/R800 80Mhz). It can be done inserting NOP's between out (nn) instrucions and/or using wait states. The current "z80 zombie mode" FPGA core implementation cannot handle wait states. I'm planning to improve this on final design

MSX-ARM is an accelerator cartridge that can be used on a standard MSX, but note there're WEAKNESSES in this architecture. The Z80/R800 processor/memory on MSX-ARM is fast(Z80/R800 80Mhz), but all devices(VDP,V9990,IDE,sound,..) on standard MSX continues to work in a standard speed. MSX-ARM try to do the work in parallel( pipeline ) with MSX slow devices, even slightly speeding up it. MSX-ARM solves the R800 VDP slow down on MSX TurboR architecture!

To OVERCOME these weakness the MSX-ARM 3½-inch floppy disk size board have several high speed interfaces: micro sd card reader, USB host, ...

For example, one can speedup the MSX by using the micro sd card on MSX-ARM board, instead using the original slow Sunrise IDE cartridge. There is a HDMI connector on board too, but I don't planning on designing a VDP on it. OPENING the MSX-ARM FPGA SOURCE CODE, I think other designer could do the work, in the same way the OCM team do customizations on it. For example, one could import the VDP(other device too) FPGA source code from Procyon Arcade Board or the OCM VDP on MSX-ARM FPGA. I know it's a lot of work on FPGA side but it can be done without much work on ARM side. Note that the user can choose what side is better: the slow legacy MSX side(original console,cartridges) or on fast and modern side! The fast Z80/R800 processor is in the midlle of these two worlds! This is the MSX-ARM architecture beauty, in my opinion :)

The MSX-ARM board uses a general purpose(one could use it to connect on a general purpose FPGA board) MSX cartridge breakout board that I opensourced on github. I opensourced the general purpose CPLD HDL source code to be used on breakout board. The CPLD HDL source code that was tested on MSX-ARM prototype is slightly different thown.

I'm building a new device that is on "VAPORWARE" status, but I sharing new general purpose designs/ideas/architecture that can be used on other projects. I think this is how modern opensource software/hardware designs are done. Several brains(brainstorming) think much better than one :)

GR8BIT accelerated to 12MHz :)

I THINK this MSX V9938 video test can be improved(speed) by the Z80 zombie pattern optimization as I described previously. I thinks since there're data patterns repeating(look the clouds), the Z80 zombie mode handler optimizer can do the work(maybe > 4 full frames per second)! Maybe not because of VDP temporization constraints (ld a,nn; out(nn),a ; out (nn),a ; out (nn),a rlca out (nn),a out (nn),a ....) ? V9990 temporization constraints ?

I expect one day I also can do this on MSX-ARM on real hardware(not MSX-ARM simulator ) running R800 at 80Mhz and a standard MSX console.

sorry for the refloat
but it would be a good idea if something like this was applied to a flashrom cartridge like the ones from rbsc or pazos
a copro built into the flashrom like a snes DSP-1.
cheap candidates can be an ATMEGA and / or a stm32

BIOS with BASIC Rom is missing a lot. Kanji Rom and superimpose too. Kanji Rom should at least be optional. In the meantime, they are not MSX compliant peripherals for another reason. BIOS or not, it changes anything. Moonsound and GFX9000 are not in standard MSX agreement just because they use I/O ports reserved for the system.

Having said that, I think they were right to use these ports. Some others made bad choices, like the Francky cartridge for example.

As for the FPU, I think it's a good idea but not alone. It is better to integrate this in a disk interface for example in order to speed up file management. There are already one or two interfaces that do that I think.