fix tiny pixel-glitches in bitbox visual output

[lowagner]

bitbox output can sometimes look clean (like when waiting for input on bootloader 2), but when activity starts or more computations are run, the output can have some small pixel glitches.

[makapuf]

from what I can see, this happens because of interrupts having impacts on the access of buses and/or cpu states. I suggest we try outputting sound and maybe also usb during hsyncs and see what happens

[pulkomandy]

On my setup this is very visible during SDCard access (for example when loading files in the chiptracker). Maybe the priority of interrupts can be tweaked and/or interrupt nesting should be enabled?

Does the SD Card and USB also use DMA or are they done with the CPU? Maybe the DMA unit does not handle well dealing with multiple channels?

[makapuf]

in fact I guess the contention comes from AHB2 access during interrupts
and/or interrupts. current plans include

• polling interface through line callbacks instead of current interrupts
  for sound, usb or SD
• verification of no DMA usage
• usage of sdram2 instead of SDRAM1 for blitting, CCM for sd / usb
  ...

2016-11-14 22:09 GMT+01:00 Adrien Destugues [email protected]:

On my setup this is very visible during SDCard access (for example when
loading files in the chiptracker). Maybe the priority of interrupts can be
tweaked and/or interrupt nesting should be enabled?

Does the SD Card and USB also use DMA or are they done with the CPU? Maybe
the DMA unit does not handle well dealing with multiple channels?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#43 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAlREVD7-zN0F0BqP-Vi_7iAVabs0cPZks5q-M4fgaJpZM4GJyCL
.

[lowagner]

does this have anything to do with it?
http://cliffle.com/article/2015/06/11/matrix/

this is a synopsis from a later post:
"""
m4vgalib avoids this by writing pixels into a separate SRAM from the one used by DMA. It would be reasonable to flip SRAMs each line: write pixels into SRAM2 while DMA reads SRAM1 on line N, then write pixels into SRAM1 while DMA reads the result from SRAM2 on line N+1. However, the STM32F407 just doesn’t lend itself well to this approach, because the SRAMs are so asymmetrical (16k and 112k). By scanning out of SRAM1 on every other line, we’d lose access to the vast majority of our RAM half the time — or risk corrupting the video by accessing it.

Instead, and perhaps counter-intuitively, m4vgalib always writes pixels into CCM, and always streams out of SRAM2. At the very beginning of hblank, the driver copies the pixels from CCM to SRAM2. This costs a small amount of CPU, but since the Cortex-M4 can shuffle data around quite quickly, it has less overhead than you might expect6. m4vgalib’s heavily optimized copy_words routine comes tantalizingly close to the theoretical maximum throughput of the AHB matrix — it runs about twice as fast as the DMA hardware.
"""
(from http://cliffle.com/article/2015/06/16/racing-the-beam/)

[lowagner]

v0.10 seems to have regressed for me, though i will try to do more testing. at the very least, i get some black pixel rows in 16, near the center of the screen, in the main game as well as on the menus. in the old v0.9 sdk, i wouldn't get any black lines in the menu screens, and i would only get the black lines in the main game when lots of sprites occupied the same row.

[lowagner]

ok, here's the difference between old and new, 0.9 to 0.10, with the black lines:
https://www.youtube.com/watch?v=gFBTXkjD8sI

[lowagner]

ok, well, things are super strange. the other bitbox examples are fine, bdash looks good with the new v0.10 sdk. trying to figure out what's different about 16 compared to others (it does incorporate everything, so io, music, etc. could all be to blame.) most of the other changes in v0.10 have been usb related:
v0.9...lowagner:master#files_bucket

i suppose i should raise this as a new issue on bitbox 16 (incompatibility with sdk 0.10 update???), but i'm very puzzled!

[edit]
ok, so it does appear to be the USB: when i unplug the controller, i get a clean screen, but when i plug it back in, the black lines reappear.
https://www.youtube.com/watch?v=boxG3yNg3Hw