Apocalypse
Edo Express Delivery Guy
- Joined
- Sep 16, 2015
- Posts
- 331
Hi,
This is a project I've started ~7 years ago. I've never had the time to finish it. Yesterday cleaning some HDD I've found pictures about it.
I've already built an homemade MVS to AES converter (to play MVS games on AES) which works fine :
- PROG part is completely passive
- CHA part contains only latches and MUX
Then I tried to build an AES to MVS converter (to play AES game on MVS). Some may think that's a stupid idea since AES games are a lot more expensive than MVS.
Anyway I love to play games on a cabinet (yes I know I could wire JAMMA on an AES but to me It's horrible to modify this great machine).
So...
I have already made some tries with a prototype converter which is completely passive :
1) First try: EVEN, H, LOAD, DOTA, DOTB, GAD0~3 and GBD0~3 left unconnected.
The game boots with sound but without graphics excepted simple texts or life bars (which is normal because there is no access to C ROM) as shown below :
Start-up screen :
Main screen :
Stage select screen :
In game screen :
2) Then I tried this: EVEN and H are grounded, LOAD is connected to PCK1B (I know it would be better to connect a 1 cycle delayed signal here), GAD0 to CR0, GAD1 to CR8, GAD2 to 16, GAD3 to CR24, GBD0 to CR1, GBD1 to CR9, GDB2 to CR17 and GDB3 to CR25 and obtained this:
Start-up screen :
Main screen :
Stage select screen :
In game screen :
The game is almost playable but is very ugly due to fact 1 out of 4 pixel is decoded and the other 3 are left black (0h0).
3) In fact during each cycle 2 pixels are decoded and only 8 bits need to be well routed to PRO-CT0 chip. In total it needs 4 cycles to decode the 8 pixels from CR0~31:
- first cycle reads CR0, CR8, CR12, CR24 for pixel A1 and CR1, CR9, CR17 and CR25 for pixel B1
- second cycle reads CR2, CR10, CR18, CR26 for pixel A2 and CR3, CR11, CR19 and CR27 for pixel B2
- third cycle reads CR4, CR12, CR20, CR28 for pixel A3 and CR5, CR13, CR21 and CR29 for pixel B3
- fourth cycle reads CR6, CR14, CR22, CR30 for pixel A4 and CR7, CR15, CR23 and CR31 for pixel B4
The system doesn't care of the other bits state during a cycle as It doesn't route them.
So I wired like in 2) but GAD0 to CR0+CR2+CR4+CR6, GAD1 to CR8+CR10+CR12+CR14, GAD2 to CR16+CR18+CR20+CR22, GAD3 to CR24+CR26+CR28+CR30, GBD0 to CR1+CR3+CR5+CR7, GBD1 to CR9+CR11+CR13+CR15, GDB2 to CR17+CR19+CR21+CR23 and GDB3 to CR25+CR27+CR29+CR31 :
Start-up screen :
Main screen :
Stage select screen :
In game screen :
...I forgot that PRO-CT0 latches C ROM data on the first of 4 cycle of decoding pixels. So, as you can see, pixels are the same 4 by 4.
4)Now I think the solution to achieve a perfect decoding is to buffer the data (with four 8 bits latches) before the system reads CR0~31 bits. This would mean doing the 4 read cycles on one cycle of 12M, but will PRO-CT0 chip work fine at 48Mhz (48Mhz can be created simply out of 24M signal with XOR and RC)?
Does anyone out there have an opinion of the best way to follow?
This is a project I've started ~7 years ago. I've never had the time to finish it. Yesterday cleaning some HDD I've found pictures about it.
I've already built an homemade MVS to AES converter (to play MVS games on AES) which works fine :
- PROG part is completely passive
- CHA part contains only latches and MUX
Then I tried to build an AES to MVS converter (to play AES game on MVS). Some may think that's a stupid idea since AES games are a lot more expensive than MVS.
Anyway I love to play games on a cabinet (yes I know I could wire JAMMA on an AES but to me It's horrible to modify this great machine).
So...
I have already made some tries with a prototype converter which is completely passive :
1) First try: EVEN, H, LOAD, DOTA, DOTB, GAD0~3 and GBD0~3 left unconnected.
The game boots with sound but without graphics excepted simple texts or life bars (which is normal because there is no access to C ROM) as shown below :
Start-up screen :
Main screen :
Stage select screen :
In game screen :
2) Then I tried this: EVEN and H are grounded, LOAD is connected to PCK1B (I know it would be better to connect a 1 cycle delayed signal here), GAD0 to CR0, GAD1 to CR8, GAD2 to 16, GAD3 to CR24, GBD0 to CR1, GBD1 to CR9, GDB2 to CR17 and GDB3 to CR25 and obtained this:
Start-up screen :
Main screen :
Stage select screen :
In game screen :
The game is almost playable but is very ugly due to fact 1 out of 4 pixel is decoded and the other 3 are left black (0h0).
3) In fact during each cycle 2 pixels are decoded and only 8 bits need to be well routed to PRO-CT0 chip. In total it needs 4 cycles to decode the 8 pixels from CR0~31:
- first cycle reads CR0, CR8, CR12, CR24 for pixel A1 and CR1, CR9, CR17 and CR25 for pixel B1
- second cycle reads CR2, CR10, CR18, CR26 for pixel A2 and CR3, CR11, CR19 and CR27 for pixel B2
- third cycle reads CR4, CR12, CR20, CR28 for pixel A3 and CR5, CR13, CR21 and CR29 for pixel B3
- fourth cycle reads CR6, CR14, CR22, CR30 for pixel A4 and CR7, CR15, CR23 and CR31 for pixel B4
The system doesn't care of the other bits state during a cycle as It doesn't route them.
So I wired like in 2) but GAD0 to CR0+CR2+CR4+CR6, GAD1 to CR8+CR10+CR12+CR14, GAD2 to CR16+CR18+CR20+CR22, GAD3 to CR24+CR26+CR28+CR30, GBD0 to CR1+CR3+CR5+CR7, GBD1 to CR9+CR11+CR13+CR15, GDB2 to CR17+CR19+CR21+CR23 and GDB3 to CR25+CR27+CR29+CR31 :
Start-up screen :
Main screen :
Stage select screen :
In game screen :
...I forgot that PRO-CT0 latches C ROM data on the first of 4 cycle of decoding pixels. So, as you can see, pixels are the same 4 by 4.
4)Now I think the solution to achieve a perfect decoding is to buffer the data (with four 8 bits latches) before the system reads CR0~31 bits. This would mean doing the 4 read cycles on one cycle of 12M, but will PRO-CT0 chip work fine at 48Mhz (48Mhz can be created simply out of 24M signal with XOR and RC)?
Does anyone out there have an opinion of the best way to follow?