Xilinx targets

[tcdev]

I'm focusing on the Xilinx targets atm, due mainly to the fact that I now have an Apple II Carte Blanche card (3E250 variant) in my possession! :D

As a result, several platforms may undergo a bit of an upheaval as I attempt to accommodate Xilinx targets in more of the PACE projects. There's also a chance some of the changes will affect the repository as a whole.

For the most part, the changes will be minor. If you're attempting to build one of the platforms and it won't build, it should be a minor fix. If you can't guess what needs to be done from the error message, check out the CB/RC10 version of the platform_pkg.vhd for the project - that should hopefully supply the required information.

[tcdev]

Finally - Pacman running on a Xilinx target (RC10)!!!

Sound not working for some reason though... :(

Xilinx has this habit of optimizing-out the variables I use for delay/unmeta pipelines... which I use quite frequently. In this case, it was the vblank unmeta pipeline in the VBLANK interrupt code - no pipeline = no vblank interrupts = no game code running. :mad:

I had a similar issue in the TRS-80 tilemap controller, which is now running on both RC10 and CB.

Now to look at Galaxian...

[FrenziedEngi]

With the resurrection of the Xilinx targets I have started to paw through some of the sources. I was able to get rc10 pacman to build with relatively few problems. I did notice there was a slight problem with PACE_HAS_SRAM constant missing from the project_pkg. Might want to look into that. So I looked at cb as a model and stole what was in there. I was able to get it to build.

With that, I don't have an RC10 board. So I am going to try and port to a S3AN starter kit (S3700AN part). First thing I ran into is that the cores used to generate the roms (sound, sprites, etc) aren't compatible with S3AN parts... its a completely different core (block memory generator vs single port memory generator... it's more generic I guess). To top it off the cores aren't backwards compatible!!!! Xilinx cores really annoy me endlessly. Although, if this is as simple as a ROM, can't it just be straight up behavioral and have the tools infer the ROM? Then you can skip needing the cores altogether...

[tcdev]

I did notice there was a slight problem with PACE_HAS_SRAM constant missing from the project_pkg. Might want to look into that. So I looked at cb as a model and stole what was in there. I was able to get it to build.
OK, thanks. It's a product of only recently having SRAM emulated on the RC10, and having an option for pacman roms in SRAM...

With that, I don't have an RC10 board. ...Although, if this is as simple as a ROM, can't it just be straight up behavioral and have the tools infer the ROM? Then you can skip needing the cores altogether...
Go for it! I don't have much experience with Xilinx tools, so I'm not confident that the correct primitives will be inferred. Feel free to give it a go.

It shouldn't take too much time to replace the xilinx_mem.vhd file with a 3AN equivalent though?!?

[FrenziedEngi]

It shouldn't take too much time to replace the xilinx_mem.vhd file with a 3AN equivalent though?!?

When cores are necessary, one thing that I have done in the past with Xilinx cores is create a generic wrapper for each core type, and then as you generate cores add them to the wrapper. For example, you might have a wrapper for a FIFO. Then inside the wrapper you place the VHDL generated when you generate a core. Then by using a bunch of generate statements, you can use generics on the wrapper level to select the core you want to use.

I think all of this is completely avoided by Altera because of the "superblocks" they have, which are basically generic to begin with. This is basically the same idea as that, except you need to go and generate the core yourself ahead of time and put together this file.

As I have said previously though, if I can figure out how to go with behavioral, that seems ideal.

[FrenziedEngi]

As an update...

Spent some more time trying to port Pacman tonight. I decided to take the "hard" route. Instead of trying to fuss with the cores, I decided to go right for a behavioral model. What I ended up with was instead of having different entities for sound, code, tile, sprite, I merged it all into one generic entity specified by width, depth, and init file. It uses VHDL to load up/initialize the ROM (on synthesis time). In order for this to work I needed to convert the coe/hex files yet again to a slightly different format (binary-ascii representation).

For some reason the PLL/DCMs are having some trouble... I started to play around with things, but it is getting late. I was able to get a build to go through where the LEDs are blinking (with the clock), and the VGA monitor activates (in sync)... But it is just black. So it is completely possible I haven't figured out the ROMs to get the appropriate code to load.

Updating the Update:
I was able to finally get Pacman to load. Yay. Graphically the title screen looks great. Ended up I needed to play around with how some of the constants were set... My game code rom wasn't being generated, and then the window ram (wram) wasn't being generated. After I figured that out... seems to work. I am going to keep tweaking from here. Alright, well... Tested the game. Plays fine. Turns out I'm not that great at pacman. I am going to venture forth again and see if I can figure out some other platforms now.