DE1 and broken projects

[tcdev]

I've gone through and done a very quick 'port' of most of the projects to the DE1 platform. Anything that wasn't a cut 'n' paste job was ear-marked for future effort.

There's a *lot* of broken stuff now, in all platforms - not just DE1. :(

I'm going to go through and try to get everything working again. Top of my list is a new video controller and sprite controller, which should fix most of the problems. I'm also going to push a flash interface through the top layers so more platforms are supported on the DE1 target.

Stay tuned for some significant improvements.

[tcdev]

It's probably going to be a few weeks until you can check out any working projects from the repository atm.

I've started some wholesale changes from the top-level down - hopefully the last time I'll have to do something this drastic. The idea is to use VHDL records as far as possible in all the upper level entity port maps for 2 reasons:

1) to allow future changes to entity port maps without having to edit several files in each of dozens of different projects

2) in theory, a single project can redefine the records by replacing pace_pkg with a local variant to add custom port maps for special builds.

Time will tell how well this works out.

My guinea pig is the DE1 build of Space Invaders.

[tcdev]

The new video controller is coming along nicely.

The new controller can now handle multiple video modes, so no need for a unique implementation for each mode. All the timing information is stored in registers and configured at reset, so new modes simply require a new set of numbers. Currently I have tested 640x480, 800x600 & 1024x768 60Hz modes. Composite video modes should also be supported and be equally trivial.

Space Invaders looks spot-on, and vertical scaling (x2) is implemented. You can also set the border colour for displays that do not fill the screen.

T.B.D. is horizontal scaling and a minor fix to the pipelining of vertical trace signals and hsync which should make it perfect.

This should, once and for all, fix all the niggly video imperfections in all the PACE projects that I've ignored up until now. I'll persevere with the controller implementation until all existing PACE projects have perfect video.

Finally, there's the wrapper around the module that (hopefully) will allow support of TFT screens using the same basic core.

[tcdev]

I've fixed the 'minor pipeline problem' I eluded to in my last post.

The borders look perfect now.

Need to implement horizontal scaling, and the controller should be done, except to add programmable pipeline delay for the sprite/bitmap/tilemap controllers.

Then I need to work out why TRS-80 graphics (and perhaps a few others) look so crap. Obviously it's timing related to the combinatorial logic in the tilemap controller. Need to register a few output stages...

[tcdev]

Horizontal scaling and programmable pipeline delays have exposed a few minor "corner conditions" in the controller that I'm still addressing.

SI looks good in both x1 and x2 modes.

Galaxian looks OK in x2, but the r/hand pixel column is stretched and the pipeline delay value seems way too large?!? Need to take a closer look at the simulation to understand/fix these problems...

The TRS-80 video is *definitely* a problem that I can fix with pipelining of some combinatorial logic in the tilemap controller - I've seen a similar problem now with galaxian in x1 mode...

[tcdev]

Still tweaking the video controller - or more correctly, the bitmap and tilemap controllers. I realised I was using the pixel strobe to clock the entire controller, rather than only latching the X value. This blew out the pipeline delays (Galaxian) and also made them dependent on the horizontal scaling factor (yuck). Now that I've started to fix it, a few off-by-one conditions have crept in... though they should come out in the wash!

Also, as a result, the controller timings have become more critical, due to the fact that they're clocked at the pixel clock rate, regardless of the scaling. That simply means I need to add some more pipeline delays in each controller. Testament to the fact is that the corruption is more pronounced at the higher pixel clock rates.

I'm at least satisfied that I can now explain all the problems with the previous video controller. This incarnation *should* be spot-on. :cool:

[MiniMorph]

It is really great to see some progress in the FPGA field.

I am a bit confused at the state of the DE1 ports.

Are any of the home computers working ???

The work on video controllers sounds great.

This is a VGA controller, or TV rate controller or both ???

Over in Sweden MikeJ seems to be working hard too. He is even looking to open a Forum.

That would be great. I can ask him why he is putting a real 68000 on his FPGA board. It seems a very strange choice after TobiFlex has got the Minimig working with a Soft 68000. The board looks good otherwise at first glance.

MikeJ seems to have amazing graphics circuitry on his board with a DVI connector !!

I have been ill for the last few weeks but am getting back to full health now.

I am still desperate to do my bit for the FPGA hobby community, but I still need a working core to get started with. My Software skills are good. My HDL skills are still on the same level as the Amoeba, but maybe that will change one day.

[tcdev]

I am a bit confused at the state of the DE1 ports.

Are any of the home computers working ???

This is a VGA controller, or TV rate controller or both ???

I can ask him why he is putting a real 68000 on his FPGA board. It seems a very strange choice after TobiFlex has got the Minimig working with a Soft 68000. The board looks good otherwise at first glance.

I have been ill for the last few weeks but am getting back to full health now.


There's not a lot working on the DE1 atm. There's a lot of broken stuff in the repository overall, actually. That's why I'm focusing on fixing the video, then the sprites, which will hopefully bring almost every project up to "working" status. The problem with the DE1 is the internal RAM size on the micro projects. However, I may be able to fix some of those by moving ROMs into flash, for example. Hopefully I'll get most platforms running on the DE1 in the not-too-distant future. :o Once the video/sprites are in order, I'll clean everything else up before I tackle any more platforms.

The video controller should do both VGA and TV scan rates. However, the TV scan stuff is designed to use a video encoder on my P2 hardware. In theory it could be replaced with an encoder done in the FPGA, which was what I was going to play with some time back before I got the P2 hardware.

The 68K core in Minimig isn't, AFAIK, a complete implementation. There's a few features left out that the Amiga doesn't use - at least that was the case last time I looked. Leaving the softcore out and using a real 68K also allows more room in the FPGA for other features, and probably reduces build times somewhat which is always handy for development work.

Anyway, glad to hear you're getting back on your feet and welcome back!

[MiniMorph]

I am not quite sure what you mean about the DE1 as it has 512K of SRAM.

That should be plenty for all the early micro's !!!

If you need to go beyond that then it gets messy and you will have to use the SDRAM but there is 8MB of that !

Keep up the good work with fixing the cores and keep us informed!

All the best.

[tcdev]

I am not quite sure what you mean about the DE1 as it has 512K of SRAM.

I use FPGA internal RAM for storing system ROMs on larger FPGAs, which negates the need for pre-programming flash etc. I also use internal dual-port RAM for video as it greatly simplifies the video logic.

With any luck, moving the ROMs into external flash will leave enough room in the 2C20 for video memory on the micro projects. The arcade machines generally had small amounts of video memory as they were tilemap and sprite based rather than bitmap displays more commonly found in micros.

[MiniMorph]

Well that's where a boot loader comes in. The ROMs can be copied to RAM from SD card before the HDL is put in the FPGA and started.

That way all the on FPGA ram can be used for things like the Video where the most can be made of the HDL.

All the best.

FordP.