MSX HDMI mutlimedia card

Page 9/56
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12 | 13 | 14

By PingPong

Prophet (3460)

PingPong's picture

30-03-2014, 14:20

maxis wrote:

Well, there are 2 operating modes possible when in MSX slot:
################
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:

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.

Hi, first sorry for bad english, but I do not think this last method is possible always. Of course this can work if you have something like:

ld a, something
out (0x99),a

It's easy to replace out(0x99),a to out (newaddress),a

the problem is register based access, out(c),xx inir, otir, ini, outi etc.

How can this simple code sequence be replaced?

ld c, 0x99
dec c         ; points to data port
ld b, 0x10
loop1:
outi
outi
outi
outi
djnz loop1
; after the loop i need to write an extra byte to data port, that is always 0x98. It's tricky, but i cannot rely on the 
; assumption that C is already holding 0x98. so i do not reload C with the same value and i simply do
out (C),c ;

at each outi, you need to figure what is THE CURRENT value of C register then change C to point to the correct address. you get problems:
- the sequence LD C, newaddress you inject causes timing problems on original z80
- C register is changed, you need to figure when to restore to its original value, because you do not know if the original sw rely on the original C value or always reload C.
- To know when to restore original register you need some smart behaviour that you cannot achieve with a simple hw logic. You need to understand the routine, something computers cannot do.
- if you inject some extra code to the original z80 one, its Program Counter gets also incremented. this can have side effects on relative jumps.

The hw address virtualization is attractive but i think can be done only on a FPGA z80 core when you can say
'virtual address A is physical address B' at the CPU / MMU level.

By maxis

Champion (512)

maxis's picture

30-03-2014, 16:08

PingPong][quote=maxis wrote:

How can this simple code sequence be replaced?

ld c, 0x99
dec c         ; points to data port
ld b, 0x10
loop1:
outi
outi
outi
outi
djnz loop1
; after the loop i need to write an extra byte to data port, that is always 0x98. It's tricky, but i cannot rely on the 
; assumption that C is already holding 0x98. so i do not reload C with the same value and i simply do
out (C),c ;

at each outi, you need to figure what is THE CURRENT value of C register then change C to point to the correct address. you get problems:
- the sequence LD C, newaddress you inject causes timing problems on original z80
- C register is changed, you need to figure when to restore to its original value, because you do not know if the original sw rely on the original C value or always reload C.
- To know when to restore original register you need some smart behaviour that you cannot achieve with a simple hw logic. You need to understand the routine, something computers cannot do.
- if you inject some extra code to the original z80 one, its Program Counter gets also incremented. this can have side effects on relative jumps.

Hello, PingPong. You are right that there is no simple lookup possible, when using indirect addressing.
If running the software directly accessing to the 0x98...0x9B is the must, then the HW instruction sequence lookup must be implemented. The I/O space virtualization is possible only when running the FW from the expansion cartridge RAM cause the instruction flow then can be 100% controlled. It is not an easy task, but feasible. So, instead of having a full blown Z80, the cartridge could have a program sequencer, load/store unit and the register file of Z80 core. Every command sent to MSX internal Z80 can be prefetched and pre-decoded locally.

Also it is assumed, that the HW logic is performing the read-look-ahead access to the local SDRAM, and the data is cached and available well before the next instruction fetch.
For instance even without a complex mechanism, this is how the OUTI instruction can be tranlated on the fly without even a context knowledge (no dataflow tracking):
Z80 is attempting to read OUTI, instead it will receive:
- PUSH BC ---- Here the cartridge will take the content of B&C pair, Z80->SP++, but there is no physical write to the memory. Cartridge sequencer will check the content of the C register. Let's say it is 0x99
- LD C, #0x89 --- Cartridge will lookup the re-calculated access address.
- OUTI
- RET --- Here the cartridge will LOOKUP the proper return address to re-adjust the virtual and physical execution addresses, SP previous value will be restored

I entirely agree, however, that this method will have a big impact on the execution speed.

BTW, this is how quite often in the semiconductor industry we test the new extension to the ISA of the microprocessor. While the new CPU core is not ready, by using an inline emulation hardware we can emulate the non-existent instructions on the standard CPU. And this would be still somewhat 10x faster than the most modern softcore implementation on the FPGA (talking about MIPS or ARM7TDMI cores).

Once again, the above approach is necessary if there is a legacy software not using the BIOS VDP base entry 0x6 & 0x7.

By PingPong

Prophet (3460)

PingPong's picture

30-03-2014, 17:58

maxis wrote:

I entirely agree, however, that this method will have a big impact on the execution speed.
BTW, this is how quite often in the semiconductor industry we test the new extension to the ISA of the microprocessor. While the new CPU core is not ready, by using an inline emulation hardware we can emulate the non-existent instructions on the standard CPU. And this would be still somewhat 10x faster than the most modern softcore implementation on the FPGA (talking about MIPS or ARM7TDMI cores).
Once again, the above approach is necessary if there is a legacy software not using the BIOS VDP base entry 0x6 & 0x7.

I agree, and now, i full understand. My problem is the insufficient knowledge of today's electronics. That's because while i've a solid base background of electronics, i've 'leaved' the pratical field 25 years ago. So, as you can understand, a relatively complex circuitry like the one you described seems to me too complex to worth the effort. This is because, 25 years ago, a thing like you described would required a lot of sequential/combinatory logic circuitry to be developed by hand...
(using flip-flops, logical gates etc.). Actually you can rise a lot the complexity by using a kind of somewhat imperative programming language and having those on the real metal. cool! (for my era).

By o.geerdink

Hero (543)

o.geerdink's picture

31-03-2014, 21:27

Make the HDMI a 4 mb memorymapper and allow to select from which address vram is used for the screen. Then you can simulate a v9958 from normal vdp ports and allow extra options (2048pixels, extra video/memory operations even jpg/png/mpeg decoding from other I/O port)

Thats how I would make it if I was smart enough.

By maxis

Champion (512)

maxis's picture

01-04-2014, 00:08

o.geerdink wrote:

Make the HDMI a 4 mb memorymapper and allow to select from which address vram is used for the screen. Then you can simulate a v9958 from normal vdp ports and allow extra options (2048pixels, extra video/memory operations even jpg/png/mpeg decoding from other I/O port)

Thats how I would make it if I was smart enough.

Hello, Onno. Yes, certainly, any extension to the standard 9958 architecture is possible. On my side, I'm now fighting with the 99x8 simulated architecture to make sure, that it will be more-less cycle accurate from Z80 standpoint, but still will take an advantage of 166MHz SDRAM clock rate and asynchronous video interface running from 25MHZ (VGA) up to 1280x1024@162MHz. And the additional bandwidth is more than enough to add multiple transparent backplanes, tiles, sprites, etc....
Yet, the sacred problem is the SW/FW support, and someone will need to write the software to use these extensions.

However, personally, I'm more interested in expanding MSX software library by making the machine compatible with another gaming hardware. For example JAMMA ARCADE boards, having already Z80, SMS, NEOGEO, why not NINTENDO... The internal FPGA would be big enough to put 6502 + all the peripherals onboard.
For example, could be cool running "Prince of Persia" without the color clash on the good old MSX, of course for educational purposes only...

The plan is the following:
1. fully compatible 9918
2. Sega Master System/NEOGEO stand alone implementation
3. SCC+PSG (just to test the sound circuitry & TOSLINK)
4. fully compatible 9938/58
5. ...

Also, I prefer NOT TO REPLACE MSX by this card, but use your existing machine in conjunction with this card in a new context. It would be really cool to take an advantage of having 30 years old Z80 and running arcade native code on it. If single FPGA is not big enough to fit both 68000 and JAMMA graphics, then you can install two Procyon cards into the both slots and connect the cards together by HDMI link(for the fast data exchange). Many ways to have fun.

By o.geerdink

Hero (543)

o.geerdink's picture

01-04-2014, 07:32

But a msx already has a v9938/v9958. Imho it's not nescecary to make it compatible at all, it can be a 2nd screen with it's own specifics. The real important thing is: high resolution. The biggest wishes are: direct memory access, decoding of modern internet data (pictures and videos). Then MSX can be used to do what I need a PC for. NSA free Cool

By maxis

Champion (512)

maxis's picture

01-04-2014, 20:31

o.geerdink wrote:

But a msx already has a v9938/v9958. Imho it's not nescecary to make it compatible at all, it can be a 2nd screen with it's own specifics. The real important thing is: high resolution. The biggest wishes are: direct memory access, decoding of modern internet data (pictures and videos). Then MSX can be used to do what I need a PC for. NSA free Cool

Well, in fact the main purpose of Procyon was connecting your MSX to the monitor via HDMI interface and extending video, sound and storage capabilities. However, if you would like to turn your machine into the fast internet terminal and to get any decent performance even when comparing to Raspberry thing, the one will have to design:
- PHP & Java HW interpreter;
- OpenGL compatible graphics controller.

Would it be still MSX? Cool

By maxis

Champion (512)

maxis's picture

01-04-2014, 20:39

Thanks guys for clarifying the CPUCLK subject.

The second question:
Are there any "large" cartridge plastic boxes readily available? Where to buy them? Any possibility to get the internal photos/drawings?
I'm looking for the approximate size of the JVC/PHILIPS FDC.
Also I remember that YAMAHA EEPROM programmer was also available in the same sort of box.

By o.geerdink

Hero (543)

o.geerdink's picture

01-04-2014, 21:37

I can program php and java but those are serverside. One would need to parse HTML/css on the MSX side (or PC proxy simplefying it to more MSX friendly files) if you want to browse.

I don't need to browse but a youtube player or skype client for MSX is possible and ofcourse MSX could have it's own www standard as far as page layout (and scripting) goes. The images/video is unavoidable.

Big smile I want my MSX to serve high resolution, the rest I can make myself Hannibal once I retire

By maxis

Champion (512)

maxis's picture

01-04-2014, 22:16

o.geerdink wrote:

Big smile I want my MSX to serve high resolution, the rest I can make myself Hannibal once I retire

Ok then, very likely you will have your hi res MSX video card before that Wink

Page 9/56
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12 | 13 | 14