P2 Invaders 2.0 - Their back!
ozpropdev
Posts: 2,792
Hi All
Here's the new version of Invaders for the P2.
This time around the code design is quite a departure from the original P2-Hot version.
In this version the system uses a "sprite engine" instead of a video frame buffer.
The same also applies for the 2 * "text engines" that build the video lines on the fly.
The sprite/text engines take advantage of the "masked write" WMLONG instruction.
The video driver and sprite/text engines are all sync'd with the COGATN mechanism.
Sound is generated using a simple 4 bit resistor ladder fed by the new streamer hardware.
The "game engine" utilizes cog/lut and hub exec modes.
The cordic solver is used in some of the animation/effects code.
The code runs on all 3 test platforms that support VGA connection (P123-A7,P123-A9 and DE2-115 with add-on board).
Code only runs on P123-A9 FPGA board with 8 cogs now.
Hope you have as much fun playing the game and pulling the code apart as i did writing it.
oz
Update 17th April 2018: Latest version for 32b FPGA image
Here's the new version of Invaders for the P2.
This time around the code design is quite a departure from the original P2-Hot version.
In this version the system uses a "sprite engine" instead of a video frame buffer.
The same also applies for the 2 * "text engines" that build the video lines on the fly.
The sprite/text engines take advantage of the "masked write" WMLONG instruction.
The video driver and sprite/text engines are all sync'd with the COGATN mechanism.
Sound is generated using a simple 4 bit resistor ladder fed by the new streamer hardware.
The "game engine" utilizes cog/lut and hub exec modes.
The cordic solver is used in some of the animation/effects code.
The code runs on all 3 test platforms that support VGA connection (P123-A7,P123-A9 and DE2-115 with add-on board).
Code only runs on P123-A9 FPGA board with 8 cogs now.
Hope you have as much fun playing the game and pulling the code apart as i did writing it.
oz
Update 17th April 2018: Latest version for 32b FPGA image
Comments
How did it feel different to write from the P2-Hot version? Was it easier or harder? Did you feel you had more or less flexibility? Which one was more fun to work on? I'm wondering about the programming ergonomics.
How many cogs did you wind up using? Were you forced to under-utilize any cogs, or could you spread the workload evenly? How about compared to P2-Hot?
When I started on the P2-Hot version I only had a 1 cog Nano to develop on.
This forced me down the multi-tasking road and writing some tight code which takes longer and gets a bit messy.
This time around I wanted to try and make it simpler so in the end I used seven cogs.
I am still exposed to P2-Hot code as well as the latest P2 incarnation and find them both a joy to code.
Even though P2-Hot had 1 clock instructions I think the new P2 compensates nicely with lut execution, smartpins, new hub scheme and 16 cogs.
I personally don't find one harder/easier than the other, just a little different.
I am a big fan of both variants so it's hard to pick a favourite, I'd buy both.
I hope someday we can buy both.
IIRC the P2-Hot only had 128KB of hub ram. I would have loved to see P2-HOT silicon tho'. Perhaps just splitting the hub ram into 16KB blocks would have helped the hub power section. Certainly would be interesting to see the real power usage under normal operating conditions - not the contrived flat out operating conditions.
In the current P2, if we have all 16 cogs running hubexec, I expect to see something towards "hot" style power consumption. But the removal of quad cog ram/lut and quad threads per cog should save power.
And now OnSemi is offering low leakage transistors too. It all adds up
Very very cool.
Almost makes me wanna get a P2 setup to play with.
(Almost- because I'd probably never finish anything else I'm suppose to be doing... that fear will keep me away a bit longer!)
Dang android. I swear, I've gotten really good on mobile. Some days, can do all my work on a Note 5. (My 4 got mangled) That includes CAD!
Did it at the beach once, just because.
Most can be touch and voice input too. Some needs Bluetooth keyboard mouse. And it is possible to be productive with all that. (Hint: get a tween or 20 something to run through how they work. It's different.)
But automangle just isn't there. It's supposed to get good as I use it. Fail.
And the worst is when it makes the edits. I tend to glance when making input actions. And the latency is enough, I will see it, verify state of input matches my running intent, then glance away, and then it does it.
Sneaky.
I broke into a cold sweat when my monitor showed 640x480 input, but nothing but a black screen. But since I have been suspecting my monitor for a while, I finally dug out a recent vintage, 12 inch VGA LCD and as if by magic, my pictures match your pictures.
YES!!!
I really like the way you have segmented the code. It makes re-using and playing with various parts so much easier.
Thanks
p.s.
If anyone has a 32" recent make Vizio, give this a shot. Is it Vizio? or just my particular monitor?
How did you go with attempting to exercise most/all instructions?
Analysis shows I missed the mark by more than I thought.
With a bit more "free time" I could weave more of these into the code but i'm back onto smartpin stuff now and preparing for analog testing.
It looks like you used SETBYTS five times. I just got rid of that to allow ALTB for addressing multi-long bit fields.
I'm thinking maybe TRIML should be gotten rid of, TRIMR changed to BTRIM, and SETBYTS put back in. What do you think? SETBYTS does save an instruction (MOV reg,value + MOVBYTS reg,#%00_00_00_00), but in the case where you just want to copy the bottom byte to the others, MOVBYTS is sufficient. What do you think?
Keeping TRIML also seems more useful to keep at the expense of losing SETBYTS.
Ok. Thanks.
BTW Only runs on P123-A9 boards now.
Sorry code is a bit messy. Lots of changes along the way from V13 image.
Is the new code smaller and faster ? ( V13 -> V32b ?)
Coupled via a cap to drive an audio amp.
Not very "Hi-Fi" but enough to add to the overall game atmosphere.
Haven't got component values handy at the moment.
The bulk of the changes have been related to changes to instruction operation.
IIRC here's some of the things that changed along the way that broke my code temporarily.
The WMLONG instruction transparent value changed from FF to 00.
The CT overflow check changed which affected my time delay operation.
The Z flag changed to a inverted state.
Some instructions were deleted from the instructions set and therefore needed substation.
I'm sure there were more than that, but that's all I can remember at the moment.
The circuit changed from the P123-A7 board which was easier for Chip to map the second DAC.
It would have been nice to get to the second DAC.
When we get our silicon P2's we can have sound on any pin we like.