MSX HDMI mutlimedia card

Page 5/56
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

By maxis

Champion (512)

maxis's picture

01-02-2014, 20:44

luppie wrote:

Count me in for an assembled one Big smile

Yobi wrote:

Also count me in for an assembled one Murdoch

legacy wrote:

You can count me in for an assembled one too.

x-nen Aivalahostia wrote:

Hello!! You can count me in for an assembled one too. Hannibal

Pencioner wrote:

Count me in for assembled one!

Bottom line: mostly the assembled boards are requested.

Once debugged, it would be necessary to find the faithful manufacturer (better in China to reduce the assembly cost) and also define the way how to rise up the funds and then make a collective order with the individual delivery....

Logistically speaking it would be excellent to get all the boards assembled in China to reduce the costs. But then, it is important to program & test the cards. I can do that, but it might take quite a lot of personal time (debugging of the bad ones). So, in order to optimize it all, PCBs must be ordered with the electrical testing, components must be also pre-ordered with the incoming Component Test (CT) whenever possible.

Plan A: The yield can be fixed at 90% (1+ card per 10 cards) for example and then manufacture under the above conditions. The cards can be delivered to me first (shipping from China or the US to me + customs taxes for the import), then programmed and tested. Then I can send the cards individually to all the participants (+shipping from me to the requesters).

Plan B: outsource the funding, assembly, quality check and programming to China. Shall we risk this in the first round?

Plan C: outsource the funding, assembly & quality check to the US. The quotes must be obtained, but could be more $$$ for assembly + PCB costs.....

What would be your suggestions?

Does anyone have an experience in building small series, testing and configuring them and sending to the individual addresses?

Last thing: do we need the plastic box for the card in these "beta testing" series?

By msxegor

Master (183)

msxegor's picture

02-02-2014, 19:23

I do not mind chinese manufacture but this depends on contacts.
Unfortunately people in china i know (really good asembly line, reasonable prices) will not move a finger for orders less than 2-3K devices. Maybe try to contact igorx?
There was a hot discussion about 'supercartridge' circa 2 years ago and your device covers all features people requested + more.
PS. I told you larger FPGA will be better.
PPS. Strange that ram buffers did not synthsize as blockrams. quartus seems to understand that right from the box. Maybe some settings for optimization were set to move registers to LUTs?

By maxis

Champion (512)

maxis's picture

03-02-2014, 13:37

msxegor wrote:

PS. I told you larger FPGA will be better.
PPS. Strange that ram buffers did not synthsize as blockrams. quartus seems to understand that right from the box. Maybe some settings for optimization were set to move registers to LUTs?

Well, replacing OCM is not the main purpose of this card.

IMHO, still this is what can be done to get the OCM like design into it:

1. Here we are at the limit of TQFP144 in Xilinx Spartan6 family already (no alternative). The next stop is BGA -> 4 layers board. But since the majority willing to get the card assembled, BGA can be also considered, but penalty is the cost and assembly complexity.

2. Regarding Altera and Xilinx differences, I was talking about the OCM memory buffers mapped into Altera BLOCK RAM and using up all the Xilinx distributed LUT RAM instead.
The problem is in the OCM asynchronous memory buffers design architecture, which is incompatible with the Xilinx synchronous BLOCK RAM interface (Mentor Graphics RED BOOK design & reuse guide).

3. So, the OCM must be either stripped off the features to fit Procyon or being re-designed to be compatible with Xilinx technology (same for ASIC).

I prefer the second path (re-design), since already the memory scheduler, memory controller and VDP must be redesigned anyway in order to increase the bandwidth to at least 200MB/s in the page/bank interleaved burst mode. The OCM memory controller unfortunately doesn't know about banks, bursts and interleaves .

What is left of OCM can be re-used as is (respecting the license), for exception of the PWM DAC, since inhere there is an AC97 codec instead. Also would be cool to place the PSG/SCC waveform memory directly into SDRAM. This way, for example, 5+3 stereo 16 bit sample channels can be organized.

Also the new design can be compatible with the MentorGraphics RED BOOK design guidelines for easy porting from one silicon manufacturer to the other (same for the license).

msxegor wrote:

I do not mind chinese manufacture but this depends on contacts.
Unfortunately people in china i know (really good asembly line, reasonable prices) will not move a finger for orders less than 2-3K devices. Maybe try to contact igorx?

Well, building up the funds and finding one stop shop is essential. Preferably no BGAs in the first round, otherwise the boards must go through the oven to be repaired. Also prefer somewhere in Europe or the US, but not China, since setting up the tooling and communicating would be difficult for small series as you have mentioned too.

By luppie

Paladin (854)

luppie's picture

03-02-2014, 14:12

You can probably get the taxes back if you import a card from China and then export the card outside the US.
This makes more sense because the card will only be passing trough the US and it's not it's final destination.

Tax Refund

By msxegor

Master (183)

msxegor's picture

03-02-2014, 15:58

maxis wrote:

Well, replacing OCM is not the main purpose of this card.

Sure. BTW if you strip CPU (which we have in MSX anyway) I think it could fit even without re-design.
On the other hand re-design looks like necessary. In this case we should start with a simple configuration, say VDP mimic for video and PSG mimic for sound test.

By maxis

Champion (512)

maxis's picture

03-02-2014, 19:21

msxegor wrote:

On the other hand re-design looks like necessary. In this case we should start with a simple configuration, say VDP mimic for video and PSG mimic for sound test.

I'm currently debugging 9938/58 light implementation (fully 9918 compatible) with sprite mode 1 only and no command engine. This is to check the memory scheduler. Then, SegaMasterSystem Mark3 is on the plate for the stand-alone mode check.
And then full 9958 implementation. For instance, the pattern name table in GFX MODE 2 the VDP reads in bursts, approx in 200ns for 32 patterns. Then multibank page mode takes place to access the pattern generator & attribute tables. I.e. in the worst case, when working in GFX mode 7 there are 75 % of the memory bandwidth (150 MBytes/s) is left for additional multicolor sprites, bit planes, CPU & audio access etc...

By maxis

Champion (512)

maxis's picture

03-02-2014, 22:37

luppie wrote:

You can probably get the taxes back if you import a card from China and then export the card outside the US.
This makes more sense because the card will only be passing trough the US and it's not it's final destination.

Tax Refund

Thank you,

I'm leaning more and more towards the one stop shop in the US (backup - Europe) to get the PCBs manufactured and all the components sourced. If we pay 200% - doesn't matter for the beta testing, IMHO, better to get something working than a complete flop. Can't be more expensive, than I've payed already for the 3 US made PCBs and 3 sets of components. There are many companies, especially in the US with the great PCB quality, offering the assembly and sourcing too. IMHO, this could be a possible solution. This way we will not pay the transit tax. US company will manufacture the PCBs and stuff the components from the US source. Quite likely all the cards can be operational then. The only problem I see is the post-assembly configuration & test.

As a possible solution, maybe I can supply FLASH EEPROM ICs already being programmed with the POST(Power On Self Test) design, such that the manufacturer will be able to plug the card to the DC source and LCD monitor, and check whether the card is operational.
Then, once tested and posted to the end user, the user him/herself will re-program the card @HOME with the target configuration.
Procyon supports the basic DFU mode via:
1. the MSX slot being in the MSX computer (MSX DFU application is still to be designed)
2. onboard USB link (PC application is not ready yet either).

The other three more hard core configuration methods are:
3. JTAG USB XILINX cable
4. SPI FLASH<->USB/parallel port cable from arduino
5. SPI FLASH cartridge biggyback board.

By msxegor

Master (183)

msxegor's picture

04-02-2014, 08:42

maxis wrote:

I'm currently debugging 9938/58 light implementation

I realized yesterday that write-only VDP configuration has a big flaw - since native VDP and emulated VDP will be out of frame sync, all programs that use scanline interrupts (many, many games and demos, even MSX2+ logo) will not display correct picture. However for first tests, this will be ok. Later, we have to use backup VDP ports with full access - just like MSX->MSX2 adapters did.

By maxis

Champion (512)

maxis's picture

04-02-2014, 09:40

msxegor wrote:
maxis wrote:

I'm currently debugging 9938/58 light implementation

I realized yesterday that write-only VDP configuration has a big flaw - since native VDP and emulated VDP will be out of frame sync, all programs that use scanline interrupts (many, many games and demos, even MSX2+ logo) will not display correct picture. However for first tests, this will be ok. Later, we have to use backup VDP ports with full access - just like MSX->MSX2 adapters did.

Actually 3.57MHz VDP->CPU clock + RESET lines are used to genlock the H/V sync counters and keep the synchronous operation of the write-only cartridge VDP and the main board V9938/58. If the VDP and CPU clocks are asynchronous, then this solution will get into the trouble you are describing.

Then to get better performance w/o waitstates or to run a different VDP model, yes the other set of ports and a shadow bios have to be used (see ACCELERATION mode description at the beginning of the thread).

By MicroTech

Champion (384)

MicroTech's picture

04-02-2014, 10:55

Hi maxis,
first of all congratulation for your excellent work, I'm really interested in procyon.
I have a couple of questions about reconfiguration option 1:

maxis wrote:

Procyon supports the basic DFU mode via:
1. the MSX slot being in the MSX computer (MSX DFU application is still to be designed)

I imagine that DFU means Device Firmware Upgrade.
If I understand correctly, it should be possible, when a procyon is inserted in an MSX slot, to use MSX as host to load fpga contents "on the fly".
During configuration, all fpga pins should be in a sort of high impendance state and should not interfere with other MSX-bus operations.
Hence Procyon should feature an fpga reconfiguration device/mechanism selectable by MSX slot signals (memory or I/O mapped) and should be possible to install (theorically) a procyon board in every slot.
Is this scenario correct?

Page 5/56
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10