1 (edited by WoS 2013-09-05 09:38:45)

Topic: Phoenix test setup

I checked in my test binary of Phoenix in the hw\replay\cores section.

Please note this setup is NOT yet for public redistribution, it is solely to check the arm loader and other stuff.
ROMs located there are for convinience of TESTING and as reference and not at all for public redistribution!

Some comments (!!!):
- keep the whole bunch of files in a subdirectory on the SDCARD for the Replay board
- joystick mapping is NOT final, also mapping for keyboard is missing (idea: keep it similar to MAME)
- DIP switch configuration in OSD menu works, also the audio volume setting
- HDMI/DVI digital and composite/SVHS video does NOT work yet
- ONLY analog via via VGA adapter on a VGA monitor works yet
- thus the video setup in OSD should NOT be changed yet, will not work
- any Phoenix ROMs from usual MAME sources should work

/WoS

Re: Phoenix test setup

Can we have a picture wink

Re: Phoenix test setup

The quality is quite limited, my development setup has a small 7' monitor thus it is hard to get a good focus and avoid aliasing effects of the picture. In reality it looks much better wink

http://www.pin4.at/tmp/replay_boot_6sep13.png
http://www.pin4.at/tmp/replay_menu_6sep13.png
http://www.pin4.at/tmp/replay_file_6sep13.png
http://www.pin4.at/tmp/phoenix_replay_6sep13.png

/WoS

Re: Phoenix test setup

Whoa! :-D

My software: [url]https://github.com/m6502[/url]
My music: [url]https://soundcloud.com/m6502[/url]
My work: [url]http://www.linkedin.com/in/manuelmontoto[/url]

Re: Phoenix test setup

But still does not sync on HDMI/DVI-D yet   sad

/WoS

Re: Phoenix test setup

...and you have to rotate your monitor (or play it sideways!)  But it works perfectly!

7 (edited by WoS 2013-09-18 19:40:53)

Re: Phoenix test setup

Updated the Phoenix design using the new Replay_VideoConverter library module I made. One can directly use the sdcard subdirectory after SVN checkout, it contains the latest binaries from the build (no need for re-synthesis).

The game core now works on HDMI/DVI-D and VGA/DVI-A. Please do some testing, I get rarely some sync losses on my monitor and I'd like to know if it is a problem with my equipment or still a general problem with the setup (either PLL setup topic or still some frame sync issue in the VHDL code)...

I'll do some DSO / DLA analysis this weekend as well...

/WoS

Re: Phoenix test setup

I'll give it a go Wolfgang. Excellent work.
I guess you calculate the clock dividers to give the correct ratio and stuff these in the .ini file?
/Mike

9 (edited by WoS 2013-09-18 19:52:42)

Re: Phoenix test setup

Yes, it uses the "long" PLL setup line in the INI.

I'd like to set up an script to calculate the optimal ratio, for now I just found the setup by hand (better: trying some values until I got a difference to the required clock of less than 0,5% - this might not be enough...).

The script will/should also calculate the generics required for the converter module (length of line buffer, start line where to start the line output, ...). This will make life much easier for new cores.

By the way: I did a small ARM sw update as well (in the config.c, the default values were already in) and added "HD74" as default PLL setup (beside "PAL" and "NTSC") - I required this for some experiments with 1080i modes...

/WoS

Re: Phoenix test setup

Can't you calculate the ratios exactly using the total pixel count ratio between the two standards?
You would need to take into account any dividers in the FPGA as well.
I'll sync and take a look.
/M

Re: Phoenix test setup

I will update my files and give it a go too on my DVI-D setup.

12

Re: Phoenix test setup

admin wrote:

Can't you calculate the ratios exactly using the total pixel count ratio between the two standards?


Yes I did take everything into account (I prepared an Excel sheet I'll release as  well), but finally the PLL settings may require some update, this divider values ( with m and n) are still "handmade" and thus (imho) suboptimal...

/WoS

13 (edited by WoS 2013-09-29 15:37:07)

Re: Phoenix test setup

Mike, your calculations are fine. Modified the INI file for the Phoenix core, now vidclk and sysclk are perfectly synchronous and video works fine (DVI-A and DVI-D thus also VGA and HDMI). So good enough as initial release I'd say, checked in the new version...

Next I will go over the user input stuff (keyboard, serial, joystick) for the ARM - and adding a proper mapping section in the INI file...

I'll take the classic MAME keyboard layout as reference and don't invent something new - I suppose this makes most sense for arcade...?

/WoS

Re: Phoenix test setup

Great news.
Yes, MAME layout would make most sense I guess. Are you supporting the joystick input as well?
I /we need to make some modifications to the mouse/keyboard input block.
The picoblazes controlling the ps/2 mouse and keyboard signal to a mux if there is a mouse or keyboard plugged in - so you can plug them in either way round. I want to extend this to support amiga/atari mice on the joystick connector and keyboard emulation of 1 (2?) joysticks as well. 

It would be most efficient to modify the picoblaze assembler to do this but I might hack it together in VHDL first.
/Mike

15 (edited by WoS 2013-09-29 17:00:23)

Re: Phoenix test setup

Yes, I was about to check all input sources:
- keyboard on ps/2 (or USB)
- mouse input on ps/2 (or USB)
- serial/debug input (especially useful for development)
- joystick input ports (as regular joystick or commodore mouse - I've got an amiga and a c64/geos to try)
- future JAMMA extension (might require e.g. an i2c extender as there are not enough I/O lines for the whole JAMMA pinout)
- optional analog in of ARM (as further extension)

There are some use cases which might be useful and should/might be controlled via the INI file:
* a joystick could be emulated by keyboard/serial (MAME layout)
* a joystick could be emulated by a "digitized" mouse
* a PS/2 mouse could be also emulated by a joystick or commodore mouse
* the replay menu might be controlled by mouse and/or joystick as well
* the second joystick may be mapped to other arcade function (coin input, player select, ...)
  (my goal is to ideally play arcade games w/o mouse and keyboard)

There might be more, just a quick shot of ideas...

I'd like to play a little with the components and try some things - e.g. if it would be fast enough (in terms of gaming experience) to interpret keyboard input on the ARM and feed it back to the arcade game as joystick. We could also do the mapping task in the picoblaze and provide just a download of picoblaze code from ARM/SDCARD to the FPGA, so to directly map the channels on the FPGA then...?

/WoS

Re: Phoenix test setup

@ Wolfgang.

I'm planning on picking up a second FPGA Arcade to put into a gaming cabinet and using it to play stuff like your Pheonix core and any other classic Arcade games that come along.

My question is, how should I deal with the orientation of the screen for different games?  Should I buy a 1920x1080 HDMI/DVI monitor that I can mount to rotate between "landscape" and "portrait"?  Would that work so that I can turn it 90 degrees to play Pheonix and then put it back again to play (for example) Defender?

Also, what plans are there for controls for Arcade games?  I've seen some posts discussing something for the expansion port which I assume means being able to hopefully attach something like this:
http://images.gizmag.com/hero/x-arcade- … ystick.jpg

17 (edited by WoS 2014-02-28 18:36:04)

Re: Phoenix test setup

Good question. Frankly, with the 8 bit cores I lost a little focus on the arcade setup sad

What Mike plans is an expansion board which will have a JAMMA standard connector for such arcade setups, which is already available in many cabinets (except the early ones and the late ones I'd call "PC based" cabinets).
http://www.jammaboards.com/jcenter_jammaFAQ.html

There are plans for a full framebuffer mode allowing storing the whole picture in the Replay DRAM and displaying it rotated on the video output. But frankly I didn't dig too deep into this topic yet - but technically there is no reason why it should not work.

I have got such an universal JAMMA cabinet which can rotate its monitor. But it is quite some work to change its orientation (it uses a good, old and heavy type with a real tube). A modern flat TV is much lighter than this. Thus I am looking for a second cabinet for my party room big_smile

You can of course directly use the Replay connectors in your cabinet - nothing speaks against it.

If you are interested in such expansion board for the Replay you may want/need such a JAMMA harness:
http://www.arcadeshop.de/popup_image.php?pID=301
and then use such arcade controls like:
http://www.arcadeshop.de/popup_image.php?pID=1098
http://www.arcadeshop.de/popup_image.php?pID=558
http://www.arcadeshop.de/popup_image.php?pID=226

The links are from a German shop where I do order some times, there are of course similar US shops like:
http://www.mikesarcade.com/
http://www.arcadeshop.com/

It seems the control board you found uses similar components.

Another question is if you also would like to use "real" arcade boards as well in your cabinet (as I do), so you might also want a strong enough arcade supply (this is of course not needed when using only the Replay board):
http://www.arcadeshop.de/popup_image.php?pID=338
and to run this boards you would probably take a flat TV with additional RGB (SCART) in instead of a computer monitor, as old JAMMA boards use mostly 60Hz (NTSC-like) interlaced video.

/WoS

Re: Phoenix test setup

@ Wolfgang:

Thanks for the reply and links.

I was planning on making it as simple as possible and just using a standard PC LCD display with the FPGA Arcade (no real arcade boards) and then placing a keyboard & mouse above or below some "arcade" joysticks/buttons to make a standup games cabinet for my games room that would play either "arcade" cores or other games via the Amiga/C64/etc cores.

I'd thought about doing this before using a PC and MAME/WinUAE/VICE, but the FPGA seems a much nicer solution.

Building a wooden cabinet out of plywood would be a fairly simple task, as would mounting the display and controls.  I'm not a bad artist so painint the cabinet with a custom games design would be a bit of fun.

Re: Phoenix test setup

If you don't mind me asking, how does your Pheonix core setup work at the moment?  Will it display on a standard PC widescreen (rotated) monitor and how do you control the movement and firing of the ship?

20 (edited by WoS 2014-02-28 22:07:13)

Re: Phoenix test setup

It did work on VGA screens only with a joystick on the lower joy port. But honestly I have not worked on it for a while, I think I had the coin entry and start button on the other joystick port...

Ok, this weekend I'll have a look and adopt the code to the actual framework again wink


EDIT:

Just fixed the core and checked it in again, builds with the actual replay_lib. Uses the Replay video scaler, so it works with VGA or with SVIDEO/composite (use _SD ini or select in OSD). HDMI should always work (especially on TVs). And it properly scales on the screen (16:9 displays must be set to 4:3 mode now).

This core is NTSC, so "_SD" mode will not work on pure PAL monitors (just the opposite to the VIC-20).

Oh, and control is left/right/fire and down for the shield. Up is used as coin-insertion, down is also re-used to start a single player game.

/WoS

Re: Phoenix test setup

Thanks for that info.  If I can get my FPGA Replay reflashed when I get home in 2 weeks then I'll take a look at it.

Are the controls hard-wired into the core or is there a config file?  The shield might be easier to activate if it could be assigned to something like the space bar on a keyboard.

I've got all sorts of monitors in the house and being British, but living in the USA, I have a couple of TVs that do both PAL and NTSC.  I have a nice 40" plasma going spare that is PAL/NTSC and has HDMI, VGA and S-Video inputs.  A bit of overkill, but what the hell.  big_smile

22 (edited by WoS 2014-03-01 10:04:04)

Re: Phoenix test setup

Yes, EU-type of TVs usually support all TV modes for quite a long time already, nearly impossible to find a "PAL-only" device. Would not call it overkill, but freedom to choose tongue

About the controls: Joysticks are yet hardwired and I did just connect the "player one" port (so no cocktail mode with 2P possible yet).

But I finished already a generic keyboard mapper for the VIC-20 which allows an INI based setup and can map even a keyboard to a joystick port. I intend to do the same with the joystick ports (so one could finally also map joystick inputs to key strokes). This mapper would be then really universal in all directions. But before I dig into that I'd like to check out the video rotation idea (using a framebuffer). So enough left to work on...

/WoS

Re: Phoenix test setup

wolfgang wrote:

There are plans for a full framebuffer mode allowing storing the whole picture in the Replay DRAM and displaying it rotated on the video output. But frankly I didn't dig too deep into this topic yet - but technically there is no reason why it should not work.

I've had experience with frame buffers in DDR3 and whilst they haven't been capable of rotation, they have been used for scaling and clipping which are less deterministic and potentially more bandwidth-intensive.

Typically I've found that in the above applications, you need FIFO's capable of storing several scan-lines at least, on both the input and output ports. Obviously these FIFO's will consume on-chip RAM; exactly how much depends on resolution and bit-depth.

We also used a simple frame buffer in SDRAM for rotating a DOOM port running on a soft-core and output to a display that was actually rotated (240x320 of all things). I can't recall the sizes of the FIFO's there but in that case the buffer had to compete with CPU access, not strictly a rotating component.

I don't see why it wouldn't be possible either! wink

Re: Phoenix test setup

Is the analog joystick supported?

I maybe will create the re-implementation of late 70s TV games with AY 8500 during the first experiments with the video.I have the detailed description of this chip timming somewhere. It runs at 2MHz.

This will be the good introduction to the board.

25 (edited by WoS 2013-09-10 11:28:48)

Re: Phoenix test setup

No, the original game even just used 4 buttons: left/right and fire/shield.
http://www.arcade-museum.com/game_detai … me_id=9004

Btw: None of my "early" arcade boards I own (and I did port / going to port) use analog inputs - and I know only a few from that time (most famous one is Pong...)

/WoS