MSX HDMI mutlimedia card

Page 2/56
1 | | 3 | 4 | 5 | 6 | 7

By giuseve

Paladin (733)

giuseve's picture

25-01-2014, 11:40

Nice piece.
Let's make an example:
I have a normal MSX2 with 128K VRam.
With your PCB I could ADD to it:
- SCC sound
- MSX-Audio sound
- SD storage (maybe in IDE Emulation? or in what way?)
- IDE Emulation
- V9958 Video
- MSX-Dos 2.3 Bios
Is it right? Maybe your PCB will come with different configuration settings whe can choose?
And what about the final price? Consider that OneChipMSX is ~€500, but MegaFlashSCC Cartdrige is ~€.130 and an FM-PAC compatible is about €60.
So it would cost less than € 200 to be appetible?

Very interesting indeed.

And what aobout the Standalone version? Would be a competitor for the OCM ?

Regards

By bakoulis

Master (166)

bakoulis's picture

25-01-2014, 12:24

Where we can find one?
As I read, it have cost under $50, but where you bought it?
Big smile

By JINsMac

Expert (77)

JINsMac's picture

25-01-2014, 13:04

cool~ nice card!

By maxis

Champion (512)

maxis's picture

25-01-2014, 13:51

Hello Giuseve,

Your outline is absolutely right.
Otherwise, you can use it as a stand-alone machine w/o joysticks and the slot yet. Also, no competition.
I have no intentions to sell this or make any kind of business/money.

The schematics will be published and the layout too. (as all the Novatec projects Wink )

You can visit the web site to see, that this card is a "side effect" of a different development.
The BOM is about 30$, the 2 layers PCB is about 15$ at a quantity starting from 30.
For 3 protos, I have payed per card: 45$ components+50$ per PCB card (the tooling cost is high for small batches).
For small series the automatic assembly, testing and packaging has to be included.

Cheers,

DL

By maxis

Champion (512)

maxis's picture

25-01-2014, 14:08

bakoulis wrote:

Where we can find one?
As I read, it have cost under $50, but where you bought it?
Big smile

Well, it was designed by me, then, small batch of PCBs was ordered together with the components. Then I've soldered one card. It is operational, but requires further FPGA development. This is what I'm doing now

By ivke2006

Resident (53)

ivke2006's picture

25-01-2014, 16:02

Hi maxis,

Performance wise, what can we expect? vdp and z80 speed?

Would-be nice if we can get a msx with equal or more speed then Turbo R Smile

By maxis

Champion (512)

maxis's picture

25-01-2014, 19:56

ivke2006 wrote:

Hi maxis,

Performance wise, what can we expect? vdp and z80 speed?

Would-be nice if we can get a msx with equal or more speed then Turbo R Smile

Well, it depends on the particular implementation of Z80 and VDP. When for the sake of testing synthesized in Spartan6 the high performance multichannel SDRAM controller, the Xilinx ISE static analysis tool with Spartan XC6SLX9 3C target told me that the design can run at 180 MHz. So, if you like, you can download XILINX ISE webpack, take OCM and re-synthesize it with the XC6SLX9 3C target. Take a bigger package in order not to hit the pin count constraints. Then, you can compare the results.

To cut it short, the power distribution system is designed to provide enough amperes with nominal ripple to power the device at 99.9% utilization at the maximum speed. I haven't done the burn-in test yet, but another test design using internal PLLs to synthesize the pixel clock beyond 100 MHz for SXGA (1280x1024) to run HDMI is working. Spartan6 is very capable device (faster than VirtexII for the same benchmarking tasks).

Currently I'm attempting to build the VDP with the tightly coupled multichannel SDRAM memory controller. The datapath is 16bits (same as the SDRAM data bus). Also I have a 16bit Z80 somewhat compatible processor (but not cycle accurate, no I & R registers, IM1 mode only, pipelined, 1 cycle/opcode execution). If this approach is taken, then the execution speed can be roughly 30 Z80 MIPS@ 30MHz comparing to 1 MIPS@4MHz of the original Z80 (0.7 MIPS on MSX). Then, the acceleration can be at least x30 times comparing to the original 3.57MHz machine. But then the question is - how accurate would be the emulation and whether this is needed.

By maxis

Champion (512)

maxis's picture

25-01-2014, 20:07

giuseve wrote:

Maybe your PCB will come with different configuration settings whe can choose?
Regards

The FPGA design can be updated via the USB cable. So you can build as many different wrappers for the different IPs as you like.
The other way of changing rapidly the config is the FLASHROM cartridge. This board has the 14pin flashrom/jtag connector. One of the switches blocks the on-board FLASH and the external FLASH can be connected to this connector.

HDMI port direction change, however, requires the soldering/unsoldering of the termination resistors. IMHO, this is the main shortcoming of this card.

By zPasi

Champion (471)

zPasi's picture

28-01-2014, 14:48

Wow! I think you have a hit in your hands, if you'll start selling this!

I still don't quite understand how that kind of expansion can work, tho. If you stick that to an msx, don't the exsisting vdp etc cause a conflict of some kind?

By maxis

Champion (512)

maxis's picture

28-01-2014, 18:19

zPasi wrote:

I still don't quite understand how that kind of expansion can work, tho. If you stick that to an msx, don't the exsisting vdp etc cause a conflict of some kind?

Well, there are 2 operating modes possible when in MSX slot:
################
I. HDMI Extension mode, where the cartridge DOESN'T REPLACE any existing main board hardware. It only maps the new HW to the non-conflicting I/O addresses (all the slot memory space is also 100% dedicated to the cartridge).
In this case Z80 continues to read/write into the main board v9918/9938/9958. When the port write access to the VDP address occurs, the main board VDP is selected, but the same timing diagram is also present on the MSX slot pins.
The Procyon FPGA runs the VDP model in the write only mode. I.e. the writes from Z80 go simultaneously to the main board VDP and the FPGA based VDP.
However, the reads and interrupts are coming from the original main board VDP only. The FPGA VDP is the order of magnitude faster than the internal VDP. Therefore, it can always replicate the VRAM/register/palette access and command execution (this is the matter of the cycle accurate FPGA emulation).

I.e. same write addresses, but only the main board VDP is selected for read. No HW conflict.

##############
II. Acceleration mode, where the cartridge DOES REPLACE and UPGRADE the existing MSX hardware.
In this case main board Z80 will have to read from cartridge VDP instead of main board VDP. Then, how to avoid the HW conflicts? This is how:
The VDP replacement is quite likely will come with the MSX1->MSX2 or MSX2->MSX2+ upgrade meaning more mapper/memory/ROMs etc. So in this case, the card runs a more complex emulation process.

1. FW redirection method. The main/extended ROM images will be executed from the cartridge memory by the MSX main board Z80 (also the cartridge will provide the mapper and the main memory extension). All the legal software must (and always do) check the locations 0x0006 & 0x0007 of the MAIN ROM for the VDP R/W port address. There, the address will be different - 0x88 for read and write. And this will be the address on which the FPGA VDP resides.

2. HW virtualization method. The "non-compliant" SW which would likely use the direct 0x98-0x9B ports access will be loaded from the disk to the memory (cartridge memory). Usually ROMs respect the MSX standard requirements and use the dynamic access method described in (1).
So, when dealing with the direct port access, since all the execution (whether this is RAM or ROM access) happens to be from the cartridge, the cartridge will prefetch the instruction intended for Z80, on-the-fly decode the instruction flow dedicated for the microprocessor and lookup a different command sequence to re-address the access to the NEW VDP HW. I.e. in the cartridge there would be an equivalent of Z80 instruction decoder & sequencer w/o the rest. This way, the cartridge "knows" the op-code sequence and it's replacement before actually handing over the OP-CODE to the main-board Z80 for the execution.

Example:
instead of issuing IN A, (099h) for example, cartridge sequencer will put LD A,NN OPCODE on the bus. And when the argument for the NN will be looked-up directly from the VDP hardware. The same will happen to the indirect addressing operations and block transfers like INI/INIR, OTI/OTIR.
As long as the code is executed from the cartridge such a "on the fly" code translation is possible. This way the Z80 peripherals are virtualized and can be remapped onto a different physical addresses. Also some acceleration can be achieved on the original non-turbo machine, by replacing the

Also the cartridge can be used for the DEBUGGING purposes by using the method above. Any code executing from the cartridge memory can be patched on-the-fly and breakpoints could be added.

Different physical access methods are used for the original main board VDP and incompatible FPGA VDP. Virtual addresses are the same, but physical address/access is different. No bus contention -> no conflicts either in the case II.

IMHO, this is my vision of the problem. It would be great knowing if there are other methods possible.

Page 2/56
1 | | 3 | 4 | 5 | 6 | 7