BOULDERMARK not working

[Ben-401]

PGS has advised that the "BOULDERMARK" program no longer works on the current bitstream. The Bouldermark program runs a special-level in the Boulderdash program and counts how many frames it takes to complete. The Bouldermark program can be found on the MEGA65 image.

[Ben-401]

An old bitstream dated Mar 15 2016 23:18:00 shows that the Bouldermark program gains a score of ~27K. go64 y sys49152

load"BOULDERMARK POKE0,65 LIST RUN

[Ben-401]

PGS has suggested that maybe something in the gs4510 file has changed, causing the Bouldermark program to now crash. PGS has suggested that an iterative-approach be taken to find which bitstreams do work, and at what point the bitstreams dont work, and then find the commit that breaks the Bouldermark program.

[Ben-401]

the bitstream referred to above (Mar 15) is commit ID commit ad7698ce809479d3ce1b71675ded70d2fa729b77 Author: justburn justburn@users.noreply.github.com Date: Sun Mar 13 07:44:16 2016 +0000 Cleanup and making it work again

[Ben-401]

i am currently building all relevant bitstreams to detect which commit caused the issue.

[Ben-401]

I am able to build old bitstreams, using colossus HPC, home/dev/sdcard/_safeKeep/MEGA65.BIT is the BITfile that runs and gets a score of 26023. work only on PGS fpga-board, ie not on BNG fpga-board. BG has captured a video showing the highscore. still need to verify if I can build a BITfile that gains the same highscore.

[gardners]

Have you found the commit where it stops working?

[Ben-401]

i have found a commit where it does work. All I have is a "container.bit" file as listed above. What I have found is that this particular bitstream works to some success(*) only on your Nexys board; it works to a much lesser amount on my Nexys board. This suggests to me that the bitstream is not hardware independant. Given all the compile warnings and lack of timing closure, i think the best approach is to get the design compiling with 100% timing closure and minimise warnings before trying to fix an intermittent problem.

() Your board runs for a minute or so, says it run out of time, then continues the level as score increases, loops a number of times, then finishes the level with about 30k. () My board starts the level, border flashing, after 5-secs or so, full-screen flash with bitmap-detail showing top horizontal line. seems to be stuck in a loop.

[gardners]

Hello,

Yes, this suggests that timing closure is the problem -- or failing that, that one of our boards is faulty in some way.

For the timing closure issue, this is relatively easy to verify, as you can modify the design to operate at ~32MHz (196/6) or ~40MHz (192/5) instead of ~48MHz without great difficulty. This isn't a long-term solution, however. The remaining timing closure problems in the CPU were intended to be fixed by moving to the new CPU design, however, that is still some time off.

Note that the VIC-IV 192MHz clock domain is much harder to get to meet timing right now, but is rather unlikely to be the cause, because the CPU is not sensibly dependent on it. The easiest and most sensible way to solve the video clock timing is to drop to 1080p, as we have been planning for some time, as this will allow dropping the pixel clock to 148MHz, which should fixing the timing closure there.

Of course, the CPU and VIC clocks have to remain integer ratios of each other, since there is a lot of cross-domain data passing between them. This would mean that the CPU would need to be at 148/3 = ~48MHz as now, or 148/4 = ~37MHz.

But in the meantime, if you can identify the commit ID, we can examine what was changed, and revert that specific problem for now.

Paul.

On Mon, Oct 24, 2016 at 2:39 AM, Ben-401 notifications@github.com wrote:

i have found a commit where it does work. All I have is a "container.bit" file as listed above. What I have found is that this particular bitstream works to some success(*) only on your Nexys board; it works to a much lesser amount on my Nexys board. This suggests to me that the bitstream is not hardware independant. Given all the compile warnings and lack of timing closure, i think the best approach is to get the design compiling with 100% timing closure and minimise warnings before trying to fix an intermittent problem.

( ) Your board runs for a minute or so, says it run out of time, then continues the level as score increases, loops a number of times, then finishes the level with about 30k. () My board starts the level, border flashing, after 5-secs or so, full-screen flash with bitmap-detail showing top horizontal line. seems to be stuck in a loop.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/mega65-core/issues/24#issuecomment-255626244, or mute the thread https://github.com/notifications/unsubscribe-auth/AAonT-GviBzhD-Ksncr2nzw9hifoSHA6ks5q2_5egaJpZM4KEh9y .

[Ben-401]

The current version of code is KSv10. The KSv10 when running on the NEXYS4DDR board labelled "PGS" gains a score of 26k or more. I have tested many times. The KSv10 when running on the NEXYS4DDR board labelled "BNG" gains a score of zero. During the first 3 secs (when the balls are falling), the screen shows the balls falling etc but flickers black a few times, after the balls finish dropping, GAME OVER is instantly displayed and switches to the high-score table. This differs to what was experienced previously as detailed on 24-OCT-2016.

I consider that the firmware is not hardware independant, and seems 'tuned' to the 'PGS' board where the firmware was initially written for.,

This issue remains open.

[gardners]

As mentioned, the issue is most likely related to the lack of timing closure on the CPU. This means that production variation in the FPGA can change the behaviour of the system. If you run Bouldermark with the CPU at 1MHz, then it performs reliably on all boards that I have seen, adding some support for this theory.

I believe the underlying problem is occurring in branch instructions, but don't have the hard evidence to back that up at the moment.

Paul.

On 20 March 2017 at 15:15, Ben-401 notifications@github.com wrote:

The current version of code is KSv10. The KSv10 when running on the NEXYS4DDR board labelled "PGS" gains a score of 26k or more. I have tested many times. The KSv10 when running on the NEXYS4DDR board labelled "BNG" gains a score of zero. During the first 3 secs (when the balls are falling), the screen shows the balls falling etc but flickers black a few times, after the balls finish dropping, GAME OVER is instantly displayed and switches to the high-score table. This differs to what was experienced previously as detailed on 24-OCT-2016.

I consider that the firmware is not hardware independant, and seems 'tuned' to the 'PGS' board where the firmware was initially written for.,

This issue remains open.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/mega65-core/issues/24#issuecomment-287678200, or mute the thread https://github.com/notifications/unsubscribe-auth/AAonTwo9ai5YSBleoeISQjvAs8sC4b97ks5rngRwgaJpZM4KEh9y .

[Ben-401]

Yes, both the "PGS" and "BNG" boards get a score of 306-to-309 when BOULDERMARK is run in 1 MHZ mode, ie "POKE 0,64".

As for the timing closure issue...

[gardners]

You could make a build with a 32MHz CPU and try that.

It is also possible that it is something strange that requires a CPU wait state for some signal to be propagated.

Paul.

On 20 March 2017 at 16:07, Ben-401 notifications@github.com wrote:

Yes, both the "PGS" and "BNG" boards get a score of 306-to-309 when BOULDERMARK is run in 1 MHZ mode, ie "POKE 0,64".

As for the timing closure issue...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/mega65-core/issues/24#issuecomment-287681698, or mute the thread https://github.com/notifications/unsubscribe-auth/AAonT5em8Hymkb7tV-UjwGwrtTVTU4u-ks5rnhCKgaJpZM4KEh9y .

[gardners]

This problem has been fixed some time ago, as I recall. I forget precisely what the underlying cause was. Please test and verify, then we can close the issue.

[Ben-401]

cannot load the "BOULDERMARK.PRG" file from sdcard, as sdcard not working. have tried using "monitor_load" but cannot seem to upload PRGs to c65-mode like i can do in c64-mode.

Can monitor_load be updated to upload files to c65-mode? I will wait until sdcard operational then test.

[Ben-401]

sorry, we should be in c64 mode, not c65 mode. Yes I can upload bouldermark to c64 mode, gets a score of ~100 in c64 mode. then upload bouldermark, POKE0,65, run, does not score.

-> still a problem (as verified with you alongside me)

[rdpeake]

Currently tested on recent bitstream as working