MSX FPU - coprocessor by TecnoBytes

MSX FPU - coprocessor by TecnoBytes

by snout on 14-06-2016, 10:03
Topic: Hardware
Languages:

Over the past few years Brasil based TecnoBytes have rapidly grown a good reputation as hardware supplier for MSX, with their OPL4 Shockwave sound card and the V9990 PowerGraph as the most well-known products. These cards are compatible with the Sunrise MoonSound and GFX9000 cartridges respectively.

Today, TecnoBytes have announced an upcoming hardware extension for MSX that brings something entirely new to the table: a Floating Point Unit (FPU) for MSX or in other words: a coprocessor that can take the performance of your MSX to the next level, provided there is software written for it. To make that happen, they have teamed up with the team behind the Oldbits Dev Studio who are going to produce a ready-for-use library to support the MSX FPU. According to TecnoBytes, using the MSX FPU should make it possible to do realtime calculations for a game that uses "Angry Birds" physics. Particularly combined with a V9990, this opens a whole world of new possibilities for MSX.

Relevant link: MSX-FPU announcement

Comments (83)

By Lord_Zett

Paladin (734)

Lord_Zett's picture

14-06-2016, 10:59

Wow, but wanna see a demo first

By enribar

Paladin (875)

enribar's picture

14-06-2016, 11:27

ok great, we can go forever to produce greater and greatet devices.
but how big will be the next generation slot expander?
at this point of tech, i hope for a msx3 with all these techs built-in and officially claimed standard.

By rolandve

Expert (113)

rolandve's picture

14-06-2016, 14:12

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.

By rogermm

Master (130)

rogermm's picture

14-06-2016, 16:05

Is it based on ARM processor? It appears to have a 128KByte flash memory(MX28F010), Altera programable logic(CPLD Altera EPM7032 http://www.digikey.com/product-detail/en/altera/EPM7032AETI4... ) and an unidentifiable chip that I think it's a ARM processor with floating point unit. I think this device could use my "Z80/R800 zombie mode" techniques to improve the data tranfer rate between the FPU unit and the Z80/R800. The FPU unit could do high performance data transfer directly to the VDP/V9990 using my "Z80/R800 zombie mode" technique too, minimizing the performance bottleneck between them.

By rogermm

Master (130)

rogermm's picture

14-06-2016, 16:13

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.

By rogermm

Master (130)

rogermm's picture

14-06-2016, 17:15

An open BIOS interface specification (only the the interface. the implementation can be closed) like the Konamiman UNAPI specification: (http://www.konamiman.com/msx/msx-e.html#unapi ) would be nice too. There is a UNAPI ethernet specification (http://www.konamiman.com/msx/unapi/ethunapi11.txt), a TCP-IP specification(http://www.konamiman.com/msx/unapi/tcp-ip-unapi-10.pdf ) and would be nice a FPU UNAPI specification. Using current(a lot of high professional work was spent to do the UNAPI specs) standards in this way, I think it's a path to success ! :). The product name could be" MSX FPU unit UNAPI compatible"

By Sylvester

Champion (325)

Sylvester's picture

14-06-2016, 23:21

By rogermm

Master (130)

rogermm's picture

15-06-2016, 00:20

+1

By Prodatron

Paragon (1776)

Prodatron's picture

15-06-2016, 02:09

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?

By tfh

Paragon (1103)

tfh's picture

15-06-2016, 08:43

So, if we are going to use a new Display card, FPU & audio-card, aren't we more or less downgrading the MSX to a PSU & keyboard?

By Lord_Zett

Paladin (734)

Lord_Zett's picture

15-06-2016, 09:13

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

By Manuel

Ascended (12816)

Manuel's picture

15-06-2016, 09:14

Can someone give an overview on what kind of calculations this card can do and how the interaction with the MSX works? (So, how to give it instructions, how to get the results, etc.)

I had the feeling that in that Angry Birds demo, the calculations could also be done on a Z80, with the usual tricks. I had the feeling I had seen such things before in demos or even games.

tfh: the Z80 is still there, though Smile

By rolandve

Expert (113)

rolandve's picture

15-06-2016, 09:21

@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 Smile

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.

By MicroTech

Champion (367)

MicroTech's picture

15-06-2016, 10:31

Very intriguing Shocked!

If I can suggest I would think this FPU more as a sort of coprocessor working as an external/extended ALU allowing 16/32 (or even 64bit) math using fixed point arithmetic.
And also 3D specific data types and functions like vertex, matrix (calculation, multiplication and application to vertex list), 3D clipping and perspective (but may be obtained again via matrix)... I would go for 3D instead of focusing of floating types.

rolandve wrote:

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.

This is imho the most interesting part of this object: the possibility to be eventually reprogrammed on the fly to "become" something else... though this would make more sense with an fpga based cartridge (which still I'm dreaming as the definitive cartridge for any MSX).

By spl

Paragon (1411)

spl's picture

15-06-2016, 12:38

tfh wrote:

So, if we are going to use a new Display card, FPU & audio-card, aren't we more or less downgrading the MSX to a PSU & keyboard?

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. Cool Big smile

By Daemos

Paragon (1642)

Daemos's picture

15-06-2016, 13:48

I really hope that one day someone will put all those "upgrades" in one nice konami sized megaflashrom like cartridge. You pay for one thing. Plug it in any MSX and enjoy all the cool juice that was ever invented.

But on topic. I really wonder what extra this FPU will provide. Its pretty new and out of the box but I really hope some cool stuff will be shown in the near future. Something that will knock us of our chairs and let us say "if we combine this with that we will get..."

I am not critical just very curious. Smile

By DarkSchneider

Champion (363)

DarkSchneider's picture

15-06-2016, 15:28

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.

By AxelStone

Prophet (2204)

AxelStone's picture

15-06-2016, 14:44

I'm going to be skeptical with this, and in general with any hardware expansion for MSX. I think that the problem of MSX is not hardware, is software. Actually 95% of MSX production is focused to small MSX1 roms, so what advantages are supossed of getting new hardware?

To get a new wave of games we need programmers able to produce bigger games for actual hardware, not games for bigger hardware. I remember great dutch productions of 90's for MSX2, it should be great another similar wave of games. And if you feel MSX2 is not enought, jump to MSX2+ Smile

By Lord_Zett

Paladin (734)

Lord_Zett's picture

15-06-2016, 14:58

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

By PingPong

Prophet (2781)

PingPong's picture

15-06-2016, 21:46

rogermm wrote:

I think this device could use my "Z80/R800 zombie mode" techniques to improve the data tranfer rate between the FPU unit and the Z80/R800. The FPU unit could do high performance data transfer directly to the VDP/V9990 using my "Z80/R800 zombie mode" technique too, minimizing the performance bottleneck between them.

Zombie mode ? how can you avoid electrical conflicts since there is no suitable BUSREQ line on msx?
As far i know, no high impedance state no way to do DMA operations....?

By rogermm

Master (130)

rogermm's picture

16-06-2016, 02:22

PingPong wrote:
rogermm wrote:

I think this device could use my "Z80/R800 zombie mode" techniques to improve the data tranfer rate between the FPU unit and the Z80/R800. The FPU unit could do high performance data transfer directly to the VDP/V9990 using my "Z80/R800 zombie mode" technique too, minimizing the performance bottleneck between them.

Zombie mode ? how can you avoid electrical conflicts since there is no suitable BUSREQ line on msx?
As far i know, no high impedance state no way to do DMA operations....?

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

By AxelStone

Prophet (2204)

AxelStone's picture

16-06-2016, 11:28

spl wrote:

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. Cool Big smile

Is not the same, I agree with @tfh. So much external expansions converts your MSX in some kind of "technological frankenstein". Don't forget that GFX9000 and OPL4 are not MSX complaint devices since they don't implement any kind of BIOS, required for any MSX device (FM-PAC and Music Module has BIOS). They even has it's own outputs, so you have duplicated outputs in your MSX: native and once placed in cartridges.

Daemos wrote:

I really hope that one day someone will put all those "upgrades" in one nice konami sized megaflashrom like cartridge. You pay for one thing. Plug it in any MSX and enjoy all the cool juice that was ever invented.

It would be a laudable effort of MSX hardware comunity and really a very impressive piece of hardware: implement all that devices (GFX9000, OPL4, FPU...) in a capable FPGA in order to expand your MSX only once, not many times.

By rolandve

Expert (113)

rolandve's picture

16-06-2016, 12:52

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.

By rogermm

Master (130)

rogermm's picture

16-06-2016, 16:05

AxelStone wrote:
spl wrote:

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. Cool Big smile

Is not the same, I agree with @tfh. So much external expansions converts your MSX in some kind of "technological frankenstein". Don't forget that GFX9000 and OPL4 are not MSX complaint devices since they don't implement any kind of BIOS, required for any MSX device (FM-PAC and Music Module has BIOS). They even has it's own outputs, so you have duplicated outputs in your MSX: native and once placed in cartridges.

Daemos wrote:

I really hope that one day someone will put all those "upgrades" in one nice konami sized megaflashrom like cartridge. You pay for one thing. Plug it in any MSX and enjoy all the cool juice that was ever invented.

It would be a laudable effort of MSX hardware comunity and really a very impressive piece of hardware: implement all that devices (GFX9000, OPL4, FPU...) in a capable FPGA in order to expand your MSX only once, not many times.

The Procyon Arcade Board is a good choice: https://www.msx.org/news/en/procyon-arcade-board-msx-cartrid...
It has almost same of MSX-ARM hardware specifications: FPGA Xilinx(9k logic elements), ARM CORTEX M4, USB host, HDMI output, sound interface, micro/sd interface. It's a highly advanced hardware that could do advanced FPU calculations(The ARM Cortex M4 has DSP instructions)

By rogermm

Master (130)

rogermm's picture

16-06-2016, 18:00

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

By rogermm

Master (130)

rogermm's picture

16-06-2016, 19:13

DarkSchneider wrote:

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.

With an open BIOS specification all developed apllications/games using the FPU unit could run with other hardware suplliers(as my upcoming MSX-ARM or the upcomming MSX-HDMI device). All these upcomings devices already(Will have) have mostly of the resources ready (MSX hardware integration, software primitivies to exchange data with MSX) to run as a MSX FPU unit. I understand that developing new hardware is really expensive, so I understand suck lock(a library instead of an open BIOS). This is not good for community thow. This is like the open-source versus closed-source versus closed-box(FPU unidentified chip+software library) war. Smile It's the designer choice do it in this way

Interestingly there is a amazing totally opensource retro-computing project going on: http://www.specnext.com/
The lock here is that it is really expensive to produce in small quantities, so it can be opensourced!

By spl

Paragon (1411)

spl's picture

17-06-2016, 00:41

AxelStone wrote:

FM-PAC and Music Module has BIOS

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.

By DarkSchneider

Champion (363)

DarkSchneider's picture

17-06-2016, 11:58

spl wrote:
AxelStone wrote:

FM-PAC and Music Module has BIOS

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.

Hello, there is no change if 80's of 3000, the standard specification must be satisfied to be really considered a MSX standard device. From the technical handbook:

Quote:

* BIOS

The purpose of BIOS is to separate the hardware and the software and to make
the software still valid if the hardware changes. Applications for sale which
manage input and output should use BIOS (except for VDP).

BIOS is called through the jump table which begins at 0000H of MAIN-ROM.
Though MSX2 has a jump table on SUB-ROM, it is used for calling the extended
functions. The branch destination of the jump table or, the contents of BIOS
may be modified for the hardware modification or the extension of the
function, so applications should not call them directly. Thogh this book has
some examples that call addresses other than the BIOS jump table, you should
consider them for information only (see BIOS list in APPENDIX). Applications
can call Math-Pack and internal routines for the extended statements
described above. These will not be changed in the future.

From the peripherals manuals:
http://map.grauw.nl/resources/

Quote:

Commercial applications are required to always use this FM BIOS to access OPLL. The  compatibility cannot be guaranteed if I/O ports are directly accessed.

Quote:

In MSX­AUDIO, extended BIOS and a MBIOS (Music BIOS) call are designed as a service routine  for application software. Using a extended BIOS call, application software queries positions, such as  the slot address, address, etc., and calls them via a jump table using a inter­slot call.

If Music Module hasn't it, then is a big mistake.
With this type of peripherals, there is no standard way to use them in a program, there is no future compatibility warranty, and for each peripheral you want to support say bye bye to its software driver size of your RAM program, because you should to repeat the code for each specific peripheral, even if its functionality is the same (i.e. MSX-Music variants).

The idea of MSX was (mainly) 2:
- Open architecture based on Z80.
- Software friendly.
This is achieved with a HAL way.

No BIOS and standard access, you destroy the MSX concept itself. The disk controller is the best example, if software try to use the disk controller directly, the program will only work in that specific controller (Sony, Philips...), but in all the other ones will crash. If a manufacturer wants to release its own MSX-Music implementation, with a different chip than Yamaha, it could if it offers the same "driver/API" in its BIOS, and this one is the responsible to translate to the specific chipset electrical specifications.

So, in MSX you don't define the "Yamaha-XX" chip, you define the "MSX-Music" and then any manufacturer can release its own if desired. And for that the HAL is needed.

By AxelStone

Prophet (2204)

AxelStone's picture

17-06-2016, 11:56

rogermm wrote:

The Procyon Arcade Board is a good choice: https://www.msx.org/news/en/procyon-arcade-board-msx-cartrid...
It has almost same of MSX-ARM hardware specifications: FPGA Xilinx(9k logic elements), ARM CORTEX M4, USB host, HDMI output, sound interface, micro/sd interface. It's a highly advanced hardware that could do advanced FPU calculations(The ARM Cortex M4 has DSP instructions)

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

spl wrote:

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 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.

By spl

Paragon (1411)

spl's picture

17-06-2016, 13:10

Sorry? There are more than five games that use Moonsound-OPL4 (last game, Life On Mars, 2015-16)... and now a lot of people has bought V9990 cards (two batches at Technobytes) and there is now a near finished project, and several projects that have started now if you read the community forums, even SymbOS supports V9990.

By msd

Paragon (1280)

msd's picture

17-06-2016, 15:36

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.

By AxelStone

Prophet (2204)

AxelStone's picture

17-06-2016, 18:35

spl wrote:

Sorry? There are more than five games that use Moonsound-OPL4 (last game, Life On Mars, 2015-16)... and now a lot of people has bought V9990 cards (two batches at Technobytes) and there is now a near finished project, and several projects that have started now if you read the community forums, even SymbOS supports V9990.

Lost World, Pumpkin Adventure 3, Bombaman, Cat'n Mouses, Sonyc... anymore? Kpi Ball is not finished.

The key is not new hardware, is new software for available hardware. Is my opinion.

By jltursan

Prophet (2058)

jltursan's picture

17-06-2016, 19:16

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.

By Manuel

Ascended (12816)

Manuel's picture

17-06-2016, 20:35

5 games only? Check this: http://www.generation-msx.nl/software/result?q=#/q=&so[]=Moonsound&p=1

(Manually copy that URL...) It's not as much as I thought it would be though! I guess you don't need to buy only Moonsound for the games!

By msd

Paragon (1280)

msd's picture

17-06-2016, 20:37

Besides games there is a lot of opl4 software

By Kai Magazine

Paragon (1045)

Kai Magazine's picture

17-06-2016, 21:52

-Rune Monster is finished (today) and it has moonsound/opl4 musics and sound effects (optional).

-Ghouls n ghosts for gfx9000 will be finished this year (confirmed by the author)

-intruder for gfx9000 will be finished maybe even sooner than ghouls n ghosts.

-unless something horrible happens to me (I die or something similar), I plan to release at least 1 game for gfx9000 (or gfx9000 compatible and optional) this same year.

By Randam

Paladin (718)

Randam's picture

17-06-2016, 22:33

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.

By msd

Paragon (1280)

msd's picture

17-06-2016, 22:25

Back on topic. It would be quite cool if the basic interpreter could use this fpu , speeding up existing basic program. I don' know if basic has some hooks than can be used to redirect the execution path. This would Potentially make it faster than z80 assembly ????

By AxelStone

Prophet (2204)

AxelStone's picture

17-06-2016, 23:15

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

Quote:

Specifications
According to the MSX Datapack, MSX-Audio BIOS and the Y8950 data sheet, these are the specifications:

Minimum configuration

Sound Generator: Yamaha Y8950
Built-in YM3526 FM sound generator (aka OPL1)
9 channels of FM sound without drums or 6 channels of FM sound + FM drums
Single type of waveform: sine
Vibrato and AM oscillators
Two general-purpose timers
Built-in 4-bit hardware accelerated ADPCM (Adaptive Differential Pulse Code Modulation) sample unit. The maximum sampling rate is 16kHz
Built-in 8-bit PCM sample unit
Up to 256KB of SampleRAM for ADPCM data
Up to 256KB of SampleROM for ADPCM data
Mono sound output.
8-bit input/output port for Music Keyboard scanning
Built-in Mute and filtering circuits
General-purpose 4-bit input/output ports
BIOS: 32KBytes (64KBytes on v1.3)
Work-RAM: 4 Kbytes
Up to 64KB of AudioROM for PCM samples

32Kb BIOS is required for MSX-Audio standard.

By syn

Paragon (1429)

syn's picture

18-06-2016, 02:21

read the wiki you linked

By Lord_Zett

Paladin (734)

Lord_Zett's picture

18-06-2016, 13:06

ppl be hapy! more msx hardware!

By Manuel

Ascended (12816)

Manuel's picture

18-06-2016, 13:18

Only the Panasonic FS-CA1 is according to the full MSX-AUDIO standard...

By rogermm

Master (130)

rogermm's picture

18-06-2016, 19:17

msd wrote:

Back on topic. It would be quite cool if the basic interpreter could use this fpu , speeding up existing basic program. I don' know if basic has some hooks than can be used to redirect the execution path. This would Potentially make it faster than z80 assembly ????

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 Evil .

By hit9918

Prophet (2533)

hit9918's picture

18-06-2016, 19:17

@rogermm,
the ARM cartridge really behaves as-if there is a faster motherboard z80?
and there is an openmsx emu of the ARM cartridge? any downloads?

By rogermm

Master (130)

rogermm's picture

18-06-2016, 22:19

hit9918 wrote:

@rogermm,
the ARM cartridge really behaves as-if there is a faster motherboard z80?

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.

hit9918 wrote:

and there is an openmsx emu of the ARM cartridge? any downloads?

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.

By NYYRIKKI

Enlighted (4426)

NYYRIKKI's picture

18-06-2016, 22:13

Sylvester wrote:

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

Mmm... Frankly that was very bad initial demo for this kind of project... I would have rather expected something like this... but naturally with lots of more sprites to actually display that there is a benefit of using the device.

You got me curious, but currently there is so little details available that I think I'll just sit down and wait...

By rogermm

Master (130)

rogermm's picture

18-06-2016, 23:14

NYYRIKKI wrote:
Sylvester wrote:

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

Mmm... Frankly that was very bad initial demo for this kind of project... I would have rather expected something like this... but naturally with lots of more sprites to actually display that there is a benefit of using the device.

You got me curious, but currently there is so little details available that I think I'll just sit down and wait...

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.

By NYYRIKKI

Enlighted (4426)

NYYRIKKI's picture

18-06-2016, 22:55

rogermm wrote:

The question is: A 16 bit PIC microcontroller(see my previous post) running 12.5 milions of RISC instructions per second is capable to do this in this speed ? 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

I have no doubt about performance... I'm sure it is internally faster than anything we will ever need. The big question is, where/if/how the power can be used... I'm thinking it could be great for playing MP3, opening ZIP-files, rendering graphics etc. but I only see something that looks like it was done in BASIC without FPU. This only makes me wonder if the demo is already using the cartridge or not? I'm also a fan of physics games, so this might be the thing I like... It all comes down to the "little details". One of the things I can't help thinking is that this might become "MSX tR problem^2" meaning that there is endless amount of performance and yet we still don't have any faster I/O... Or maybe this can be even first step towards full 3D graphics card that does not require that much I/O from MSX... Ah, so much to speculate, but no... I will now just sit down and start waiting for more info.

By NYYRIKKI

Enlighted (4426)

NYYRIKKI's picture

18-06-2016, 23:22

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

rogermm wrote:

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.

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.

By rogermm

Master (130)

rogermm's picture

18-06-2016, 23:53

.

By rogermm

Master (130)

rogermm's picture

19-06-2016, 00:11

NYYRIKKI wrote:

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

rogermm wrote:

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.

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..."

By NYYRIKKI

Enlighted (4426)

NYYRIKKI's picture

19-06-2016, 01:25

Indeed... but as I said distance & angle are only part of the problem. To prove the point I now removed the ML stuff and the change is hardly noticeable because the floating point stuff is what it is... You can test it your self... (Copy/Paste after "Quote" the forum's read mode does not display the source right)

10 _TURBO ON
20 DIM DX(10),DY(10),X(10),Y(10)
30 DE=.01 'DELTAT fixed time step, no relation to real time
40 SL=10 'SEGLEN size of one spring in pixels
50 SK=10 'SPRINGK spring constant, stiffness of springs
60 MS=1 'Mass
70 XG=0 'Positive XGRAVITY pulls right, negative pulls left
80 YG=20 'Positive YGRAVITY pulls down, negative up
90 RS=10 'RESISTANCE determines a slowing force proportional to velocity
100 SV=.1 'STOPVEL stopping criteria to prevent endless jittering
110 SA=.1 'STOPACC stopping criteria to prevent endless jittering
120 DS=8 ' DOTSIZE
130 BO=.75 'BOUNCE is percent of velocity retained when bouncing off a wall
140 ND=7 ' Number of dots
150 HE=211 'HEIGHT of screen
160 WI=255 'WIDTH of screen
170 SCREEN 5
180 SPRITE$(0)=STRING$(8,255)
190 R=PAD(12):MX=MX+PAD(13):MY=MY+PAD(14)
200 IF MY>HE-DS-1 THEN MY=HE-DS-1
210 IF MY<0 THEN MY=0
220 IF MX>WI-DS-1 THEN MX=WI-DS-1
230 IF MX<0 THEN MX=0
240 X(0)=MX:Y(0)=MY
250 PUT SPRITE 0,(MX,MY),15,0
260 FOR I=1 TO ND
270 SX=0:SY=0
280 IF I>0 THEN Q1=I-1:GOSUB 480
290 IF IHE-DS-1 THEN Y(I)=HE-DS-1:DY(I)=BO*-DY(I)
400 IF X(I)=>WI-DS-1 THEN X(I)=WI-DS-1:DX(I)=BO*-DX(I)
410 IF X(I)<0 THEN X(I)=0:DX(I)=BO*-DX(I)
420 R=Y(I):IF R<-DS-1 THEN R=-DS-1
430 PUT SPRITE I,(X(I),R),I+2,0
440 NEXT I
450 IF STRIG(1)=0 THEN 190
460 END
470 'SpringForce
480 QX=X(Q1)-X(I):QY=Y(Q1)-Y(I)
490 L=SQR(QX*QX + QY*QY)
500 IF L=< SL THEN RETURN
510 SF=SK*(L-SL)
520 SX=SX+(QX/L)*SF
530 SY=SY+(QY/L)*SF
540 RETURN

By rjp

Expert (127)

rjp's picture

19-06-2016, 07:04

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. oO
- 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.

By AxelStone

Prophet (2204)

AxelStone's picture

19-06-2016, 19:56

rogermm wrote:

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 Evil .

+1 . A faster CPU is better option that a coprocessor. Turbo R has a good CPU, R800 is a fast CPU, but MSX2 could get a great benefit of a faster Z80.

NYYRIKKI wrote:
Sylvester wrote:

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

Mmm... Frankly that was very bad initial demo for this kind of project... I would have rather expected something like this... but naturally with lots of more sprites to actually display that there is a benefit of using the device.

You got me curious, but currently there is so little details available that I think I'll just sit down and wait...

Thinks the same, the demo don't show any kind of potential. The video you attach is crearly more spectacular and don't use any aditional hardware. As you say, let's sit down and wait.

By DarkSchneider

Champion (363)

DarkSchneider's picture

20-06-2016, 13:47

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

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

By rogermm

Master (130)

rogermm's picture

20-06-2016, 22:07

DarkSchneider wrote:

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

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

Using my "Z80 zombie mode" tecnique explained in my previous post I THINK(I don't know the eZ80) one could build a eZ80 cartridge that virtually swap
the original Z80/R800 processor. See: http://www.verycomputer.com/111_9176b54ff9bb2d40_1.htm

I choose to use an ARM Cortex M4 processor(The Z80/R800 run on ARM) on a cartridge. The Z80/R800 runs at ~50Mhz on ARM Cortex M4(STM32F4) and at ~80Mhz on ARM Cortex M7(STM32F7, pin compatible with STM32F4), it's almost ez80 speed(100Mhz).This speed was measured on my MSX-ARM simulator & SDK suite. As a plus, using resources available on ARM I created the MSX-LUA interperter totally integrated with the MSX(MSX BIOS,poke,vpoke,...,disassemblers, z80 monitor). Here there is some MSX-LUA samples: https://github.com/rogeriomm/msxarm-filesytem/blob/master/co... . I think(maybe) the LUA interpreter cannot run on eZ80 tho.
Even if it could, it would run very slowly.

Experimentally I coded a 6502(runs at 16Mhz on ARM Cortex M4) emulator in ARM assembly based in this opensource project (https://github.com/BigEd/a6502) . The 6502 processor have access to all MSX memory(mapper,ROM,..) and I/O devices like the VDP. It's is experimental, not fully tested(the Z80 passes all ZEXALL tests,the R800 passes all ZEXDOC.I coded some unit tests too) 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. Very soon I''ll post a video.

By rogermm

Master (130)

rogermm's picture

20-06-2016, 22:04

By hit9918

Prophet (2533)

hit9918's picture

21-06-2016, 02:20

rogermm, I still wonder how it works,
can it run the whole MSX system on the zombie z80, with flipping the slots to diskROM and all that?
I can't imagine how it survives slot flipping, when it is the same page where the motherboard z80 needs to read opcodes from ARM RAM.

By rogermm

Master (130)

rogermm's picture

21-06-2016, 19:58

hit9918 wrote:

rogermm, I still wonder how it works,
can it run the whole MSX system on the zombie z80, with flipping the slots to diskROM and all that?
I can't imagine how it survives slot flipping, when it is the same page where the motherboard z80 needs to read opcodes from ARM RAM.

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!

By rogermm

Master (130)

rogermm's picture

22-06-2016, 01:33

I forgot to explain some more details about the MSX-ARM "host mode". The zombie mode handler (It's the memory area where the ARM generates Z80 opcodes on the fly in real time.if the ARM processor don't have nothing to run on Z80, the FPGA set NOP instruction on bus. Optionaly it can generate a wait state on Z80 Smile ) can run in any Z80 16KB page. The Z80 interrupt run on mode 2(IM 2) so the Z80 interrupt handler can be relocated to any page by changing the "I" register(using the Z80 zumbie mode). The Z80 interrut handler is also a opcode generated by the ARM on the fly and it don't need know that it's interrupt handler rotine! The FPGA senses the interrupt by reading the signal IRQ\ an M1\(IM2 Interrupt vector read), and it generate a high priority(real time) interrupt on ARM. The Z80/R800 running on ARM receives this event. Also keep in mind that the Z80/R800 on ARM can run at 80Mhz with a ARM Cortex M7, so all slow MSX host slot page switches and data transfer can be diluited by the fast Z80/R800 processor on ARM. It be can be even real time throtlled to 100% (not 99.99%) sincronization between the MSX Z80 host and the Z80/R800 running on ARM. All MSX games can run in the trotlle mode. Even load a game from the tape(must be cycle acurrate) is possible

By hit9918

Prophet (2533)

hit9918's picture

22-06-2016, 00:50

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

By hit9918

Prophet (2533)

hit9918's picture

22-06-2016, 01:51

with all the virtual vs real z80, I got problems to ask the right questions Smile
can it do memory mapped IO on the real chip. like floppy controller or SCC.

while with my question about IM2, it could all go on the ARM side.
I got no vector selection thing, I got identic 257 bytes in the whole interrupt table.

By rogermm

Master (130)

rogermm's picture

22-06-2016, 22:35

hit9918 wrote:

with all the virtual vs real z80, I got problems to ask the right questions Smile

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 Smile

hit9918 wrote:

can it do memory mapped IO on the real chip. like floppy controller or SCC.

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

hit9918 wrote:

while with my question about IM2, it could all go on the ARM side.

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

hit9918 wrote:

I got no vector selection thing, I got identic 257 bytes in the whole interrupt table.

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
}

By rogermm

Master (130)

rogermm's picture

22-06-2016, 21:26

hit9918 wrote:

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.

Nice. I didn't figure out exactly what it is, but I planning to use it to validate the MSX-ARM slot management. I'm working now fixing some bugs, so I can't test it, but I'll include p3bios validation process in my next demo video that I'll post very soon.

The Z80/R800 processor was validated by ZEXALL(Z80) and ZEXDOC(Z80,R800). It passes all tests! I'll include these tests on video too.

By hit9918

Prophet (2533)

hit9918's picture

23-06-2016, 18:12

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.

By rogermm

Master (130)

rogermm's picture

24-06-2016, 01:09

hit9918 wrote:

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.

Currently the Z80 "zombie mode" pattern to do data transfer is not optimized: "ld a,n; out (nn),a". The "outi" instruction is faster(only -2 cycles/byte) though.
The "ld hl,nnnn; outi" instruction pattern on "Z80 zombie mode" will be implemented only in the final design(The MSX-ARM works without such optimization. It can convert MSX2+ to Turbor without such optimization). The MSX-ARM 8KB shared memory(Inside FPGA. ARM and Z80 host can read/write in this area) will be used to do this optimization. In this scenario the ARM write the shared memory with the VRAM(can be any device) data and then send the "ld hl,shareMemoryAddess; outi; outi; ..." instructions to Z80/R800 zombie host. Note that the Z80 host HL register("ld hl,nnn") don't need to be setted always!. The ARM can do this optimization.

hit9918 wrote:

Maybe the ZX goblins port is a good example demo.

The MSX-ARM is already a large project, so I don't have spare time and expertise(despiste my low level skills I know only what I need to build the MSX-ARM) to do such big project. I'm only building the tools Smile If I were to do this port to MSX I'd use the MSX LUA. I worked a lot coding Z80/Z180/8031/68000 ... in 198x. It's very hard!!. My choice is an advanced interpreter. LUA is high advanced interpreter language and easy to learn, it's already used as a game language( LUA on games ) , and the current implementation of MSX LUA is totally integrated with MSX.In MSX LUA one can read the joystic, write to VDP,/V9990, write to PSG ..... I think that a timer manager on LUA must be implemented to run games. Anyway the Z80 host interrupt event can be catched on MSX LUA

By rogermm

Master (130)

rogermm's picture

24-06-2016, 00:52

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

By rogermm

Master (130)

rogermm's picture

24-06-2016, 01:50

hit9918 wrote:

Maybe the ZX goblins port is a good example demo.

Sorry, I misunderstood your phrase. You're referring the ZX goblins game that was ported to MSX:
https://www.youtube.com/watch?v=k2Uf-Ht45Ag

The current MSX-ARM "host mode" implementation can't throttle the ARM Z80 to a standard speed(real time host 3,58MHz Z80 syncronization ). It wasn't implemented already. Only games that can run on MSX-Turbor R800 mode will run on MSX-ARM.

By ivke2006

Resident (53)

ivke2006's picture

24-06-2016, 10:07

@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,

By rogermm

Master (130)

rogermm's picture

25-06-2016, 20:28

ivke2006 wrote:

@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,

The MSX-ARM was anounced 4 years ago and despite my effort to build the MSX-ARM simulator & SDK suite and the 3½-inch floppy disk sized board design, the project is on status of "VAPORWARE". I opensourced some untested designs too: https://github.com/rogeriomm . My previous posts describes a tecnique that virtually and efficiently swaps the Z80/R800 host microprocessor on MSX, supposedly impossible on MSX. This tecnique can be used by designers to improve existing designs like the MSX-FPU, or create a new one based on it.

A brazillian designer is planning to use the "Z80 zombie mode" tecnique to build a low cost MSX USB cartridge that works with a modified version of openmsx that run on PC, and exports any existing MSX real device(keyboard,V9990, OPLL, VDP, PSG...) to openmsx. In this scenario, the openmsx do all work to detect the MSX model, I/O ports, etc. The cartridge(could be a FPGA or a microcontroller) is only a general purpose "Z80 zombie mode" USB bridge (no brain. The brain is on openmsx). Using the high quality openmsx C++ source code base one could do this fast. The pitfall here is the dedicated USB kernel device driver on PC(Maybe a USB Linux device driver is more feasible than Windows). Anyway it's a great project :)

I continue to work on MSX-ARM and very soon I'll post a video about my progressions. It'll continue on status of "VAPORWARE", maybe a status of "PLAUSIBLE", thown.

To end-users, the MSX-ARM try to solve the MSX cartridge hell. It's like a NEW Turbor model based on ARM processor. MSX-ARM is a all in one device: 4MB mapper, Ethernet, MIDI, RS 232, a fast Z80/R800 processor running at 80Mhz, FPU. All this features using your existing MSX, not a new one. Others advanced features like the MSX LUA interpreter and the ARM&Z80 (I'll post a video about this feature) 32 bits intruction extension(one can do general purpose advanced integer/float point processing mixed with Z80 instructions, almost the same the MSX-FPU can do, probably faster) are more focused on power users like software developers.

By hit9918

Prophet (2533)

hit9918's picture

26-06-2016, 21:14

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".

By DarkSchneider

Champion (363)

DarkSchneider's picture

27-06-2016, 10:56

Looking at that, it could be more worth a full machine one-chip-MSX like. I mean, the classic MSX is only used to provide the keyboard, and maybe joystick ports?. It is worth a full machine and add new-slots (compatible with classic), joystick and USB/PS2 ports, and plug your keyboard. This machine is like a new and faster MSX and compatible with the old one. Using openMSX layer it could be compatible with the higher one that the ARM CPU used could emulate (MSX2+ with turbo Z80? TurboR?), and the new "Super Fast" mode that is an unlocked mode at full Z80 (or the selected Zilog Z80 compatible processor for implementation) speed that would allow the ARM emulation.

By AxelStone

Prophet (2204)

AxelStone's picture

27-06-2016, 13:16

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.

By rogermm

Master (130)

rogermm's picture

28-06-2016, 00:41

In MSX-ARM architecture there is a north bridge too, but it's internal on FPGA.
New devices being designed inside FPGA to connect on north bus follow the WISHBONE System-on-Chip (SoC) Interconnection Architecture . I know that MSX comunity like unique features like a new Z80 processor with 32 bits extensions, an unique MSX bus, ..... Unique standards means reinvent the wheel, a lot of work too! :)

MSX-ARM devices connected on WISHBONE north bus:
- "Z80 zombie mode" controller, 4KB MSX shared memory, input pipeline, output pipeline
- 32MB RAM
- Opensource PS/2 keyboard controller: http://opencores.org/project,ps2core
- ARM external memory controller. 16 bits data bus, 80Mhz

              +------------------+            +-----------------------+
              |      ARM         |            |     Application:      |
              |  CORTEX M4 or M7 |        |---|  MSX LUA interpreter  |
              |      CPU         |        |   |                       |
              +------------------+        |   +-----------------------|
                       |                  |
                       |                  |
                       |                  |
|------|      +-----------------------|   |   +--------------------------+
| RAM  |      | ARM memory protection |   |   |  Z80/R800 processor      |
| 32MB |      |    unit               |-------|  coded in ARM assembly   |
|------|      |      MPU              |       |  80Mhz on Cortex M7      |
   |          +-----------------------+       +--------------------------|
   |                   |                                                                |-------------------|
   |                   |                                                                | Wishbobe          |
   |- [----- "North bridge" internal open WISHBONE bus       -------]  -----------------| PS/2 KB controller| 
                       |                                                                |-------------------|
	               |
                       |------------------------|--------------------------|
                       |                        |                          |
|-----------|  |------------------|   |---------------------|  |-----------------------|
|ZOMBIE ctrl|  |input PIPE (FPGA) |   | outpupt PIPE (FPGA) |  | 4KB RAM shared memory |
|-----------|  |------------------|   |---------------------|  |-----------------------|
                       |                        |                          |
                       |------------------------|--------------------------|
                       |
     [--------original primary slot #1------]   "south bridge" = one of the classic MSX slots
                       |
	    +---------------------------------+
	    | Your existing MSX 1/2/2+/Turbo R| 
	    +---------------------------------+
                       |
     [--------original primary slot #2--------]   
                       |
                       |
	      +-----------------------------+
	      |  Your existing slot expander |
	      +-----------------------------+

By rogermm

Master (130)

rogermm's picture

28-06-2016, 19:57

hit9918 wrote:

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

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 萌SX 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).

hit9918 wrote:

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.

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.

hit9918 wrote:

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.

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

hit9918 wrote:

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.

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!

By rogermm

Master (130)

rogermm's picture

28-06-2016, 21:02

DarkSchneider wrote:

Looking at that, it could be more worth a full machine one-chip-MSX like. I mean, the classic MSX is only used to provide the keyboard, and maybe joystick ports?. It is worth a full machine and add new-slots (compatible with classic), joystick and USB/PS2 ports, and plug your keyboard. This machine is like a new and faster MSX and compatible with the old one. Using openMSX layer it could be compatible with the higher one that the ARM CPU used could emulate (MSX2+ with turbo Z80? TurboR?), and the new "Super Fast" mode that is an unlocked mode at full Z80 (or the selected Zilog Z80 compatible processor for implementation) speed that would allow the ARM emulation.

Using the MSX-ARM cartridge and existing tools and MSX console/cartridges can improve the MSX without losing the essence . A lot of users have psychology connections(me too) with existing MSX console/cartridges. A totally new MSX break this connection! My badass MSX console is a PC with 32GB RAM + 64 bits/8 cores/4GHZ processor + solid state hard-disk,4 terabyte HD,running Debian Linux with virtualization capabilities! This is my point of view Smile

By rogermm

Master (130)

rogermm's picture

28-06-2016, 22:04

AxelStone wrote:

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.

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 Smile )

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 Smile

By hit9918

Prophet (2533)

hit9918's picture

28-06-2016, 22:33

Quote:

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

I dont understand. The MSX2 can take OUTI.
if you got a 5.4MHz panasonic going, then it will overspeed.
maybe in screen 0 it doesnt overspeed. at 3.57Mhz it works in all modi.
MSX1 needs 29 cycles.
and there is another issue that after setup for vram read the delay is needed BEFORE the IN.
and maybe same it is with MSX2 and INI. it has 18 cycles but its IO is more early in the instruction, more near to the OUT 0x99 that did make read mode setup.
while in write mode 1 byte is buffered, one can start immedeately after port 0x99 setup.

By rogermm

Master (130)

rogermm's picture

29-06-2016, 23:06

hit9918 wrote:
Quote:

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

I dont understand. The MSX2 can take OUTI.
if you got a 5.4MHz panasonic going, then it will overspeed.
maybe in screen 0 it doesnt overspeed. at 3.57Mhz it works in all modi.
MSX1 needs 29 cycles.
and there is another issue that after setup for vram read the delay is needed BEFORE the IN.
and maybe same it is with MSX2 and INI. it has 18 cycles but its IO is more early in the instruction, more near to the OUT 0x99 that did make read mode setup.
while in write mode 1 byte is buffered, one can start immediately after port 0x99 setup.

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 ! Evil 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 Evil

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

By AxelStone

Prophet (2204)

AxelStone's picture

30-06-2016, 22:15

rogermm wrote:

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 Smile )

Perhaps it has more work, but for example in Zemmix / 1Chip / Altera you have Z80@10Mhz implemented. A cartridge that implements that Z80 to use in standar MSXs should be clearly more useful that FPU. If I've understood your explanation, MSX-ARM is something similar, a MSX runing fast.

By rogermm

Master (130)

rogermm's picture

02-07-2016, 21:28

AxelStone wrote:
rogermm wrote:

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 Smile )

Perhaps it has more work, but for example in Zemmix / 1Chip / Altera you have Z80@10Mhz implemented. A cartridge that implements that Z80 to use in standar MSXs should be clearly more useful that FPU. If I've understood your explanation, MSX-ARM is something similar, a MSX runing fast.

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 :)

By rogermm

Master (130)

rogermm's picture

03-07-2016, 17:28

GR8NET internetworking adapter with multimedia = general purpose 32 bits multiplication/division FPGA accelerator. Multiplication/division expected to be executed within 0.2 and 0.3 us Smile
http://rs.gr8bit.ru/Documentation/GR8NET-manual.pdf

Maybe a 32/48bits multiplication accumulator could be a useful operation for multimedia acceleration too :evil:

By rogermm

Master (130)

rogermm's picture

03-07-2016, 19:21

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.

My MSX profile