stardot / b-em Goto Github PK

There is code in B-Em to allow the keyboard to be redefined on Linux and there is even an option on the menu to do so, but clicking the menu item doesn't cause anything to appear.

I like to use 500% speed when running the test suite for a program I'm developing, but I have to drop back to 100% when I want to type something in to the emulated machine. It would be nice if there was a single key I could press to toggle between normal speed and maximum speed instead of having to navigate the menu each time.

Alternatively - but I suspect this is hard/impossible - if some magic could make it possible to type normally even when the machine is running at 500% speed, I wouldn't need the toggle and could just leave the machine at 500% all the time.

I hope it's OK to raise a feature request as an issue like this, please let me know if it's not.

Thanks.

Steve

If you have a Tube system and you try to run a transient executable on the Tube, it gets loaded and run in the I/O processor instead. With sometimes hilarious results.

https://www.youtube.com/watch?v=4icSz0ks2pE

Modifying the code in run_file() to load the binary into the Tube is really easy, but actually calling the code isn't, and may need ROM support --- out of my pay grade, unfortunately.

Reported by guesser in the B-Em release thread in the Stardot Forums. B-Em's emulation of Video NuLA does not include mapping the Mode 7 colours to the NuLA RGB palette as demonstrated by this test program:

   10 REM MODE 7 Video NuLA Test Program
   20 MODE 7
   30 PRINTCHR$(129);"This line is red"
   40 PRINTCHR$(130);"This line is green"
   50 PRINTCHR$(131);"This line is yellow"
   60 PRINTCHR$(132);"This line is blue"
   70 PRINTCHR$(133);"This line is magenta"
   80 PRINTCHR$(134);"This line is cyan"
   90 PRINTCHR$(135);"This line is white"
  100 PRINTCHR$(136);"This line should flash"
  110 PRINT
  120 PRINT"Press a key to enable NuLA...";
  130 K%=GET
  140 PRINT:PRINT
  150 *FX151,35,120
  160 *FX151,35,136
  170 *FX151,35,106
  180 *FX151,35,66
  190 *FX151,35,95
  200 *FX151,35,80
  210 PRINTCHR$(133);"Magenta should now be orange"
  220 PRINTCHR$(134);"Cyan should now be brown"
  230 PRINTCHR$(135);"White should now be grey"
  240 PRINT
  250 PRINT"Press a key to reset NuLA...";
  260 K%=GET
  270 PRINT
  280 *FX151,34,64

Most recent preview build crashes out on startup , "models: No models defined"

Build being - https://github.com/stardot/b-em/releases/download/allegro5-pre2/b-em-allegro5-pre2c-win32.zip

See http://stardot.org.uk/forums/viewtopic.php?f=4&t=10823&sid=1b0ce810467ebecbbd16449177d5a13e&start=270#p196074

The issue is caused because, when B-Em with Allegro 5 starts and is unable to open the config file, it does not create an empty config in the way that Allegro 4 does but waits until it is time to save the configuration before creating that config. This means code that previously wrote config changes while running, i.e. before config save time, must no longer do so.

This is a follow on from #11 (which we decided to make specific to Music 5000) and have since resolved.

These comments apply to official B-Em 2.2 release, as well as the current build. The problem seems to be present on Linux and Windows.

In very general terms, the sn74689 audio sounds slightly grainy. I really noticed this when I hooked up a decent amp and speakers, so that I could compare the B-Em sn76489 emulation with an FPGA hardware implementation (that uses a decent SPI DAC).

The difference was significant. My testy case was simply the ^G beep.

I think there are a few going on:

• the audio output of most PCs is pretty noisy
• the output level of B-Em is quite low compared to other applications
• the default re-sampling is probably just using linear interpolation
• on Windows the default openal32.dll is routing directly to DirectSounds3D - it may be better to replace this with OpenAL Soft, then we can control global levels and resampling via alsoft.ini file in %AppData%
• there is some noticeable modulation on the ^G beep

As a comparison, I tried the Beech emulator on Windows, and this sounded very clean in comparison.

Looking at the ^G waveform on a scope:

you can see there is one sample's worth of jitter.

I'm not sure if this is the problem, or if it's even avoidable. The real sn76489 runs at 4MHz/16 = 250KHz, which is 8x the audio sampling clock. So clearly some frequencies will jitter.

Oh, and the sn76489 code is much more complicated that I would expect:
https://github.com/stardot/b-em/blob/master/src/sn76489.c
I don't understand what sidcount is doing here!

I need to do some more investigation, but I would be interested in feedback from other people. Most people I suspect would not notice, unless the issue is pointed out to them.

Hi,

I don't know if this is my fault and/or it's an uninteresting case, but for what it's worth...

I'm running Ubuntu 18.04 amd64 as a guest operating system under VirtualBox 5.2.12 (Windows 7 host). I have the guest extensions installed. I've built f1dd7d2 from github without any problems (just a few warnings about ignored fread() return values). When I start the emulator it looks OK (I see the b-em window with menu bar and a BBC B mode 7 startup screen underneath it) but the terminal I launched it from says:

OpenGL Warning: vboxCall failed with VBox status code VERR_BUFFER_OVERFLOW

That may or may not be relevant. The b-em menus don't work; if I click on (e.g.) File it is highlighted but no menu appears beneath it. There's no additional terminal output when this happens.

Much more fuzzily - if I click on another window hidden behind the b-em window, the b-em menu bar and frame disappears but the actual emulated machine's screen remains in the foreground, whereas I'd expect it to be hidden. (I tried to take a screenshot of this but the b-em emulated screen isn't visible in the screenshot.)

Sorry if this is a bit incomprehensible and I appreciate it may not be easy to reproduce, but I thought I'd at least mention it. Let me know if there's anything I can do to help debug this, although I will be away from this virtual machine from tomorrow evening (I use it to get my Linux fix while visiting family, and my visit ends tomorrow...)

I don't know if the machine is a bit underpowered (i5-2500K, 2 CPUs in the emulated machine); if I type into the emulated BBC B I lose some keypresses. CPU use for b-em hovers around 65% in top.

Cheers.

Steve

In B.EM 2.2 The Eject disc menu option allows for a disc to be ejected.

In the current preview release this option appears to have NO effect, the loaded disc remaining on the menu.

In B-EM 2.2 , New disc menu option is supposed to create a new disc image.

This option appears to be non-functional in the current preview release, as it asks for a filename and then says it can't find it.

I suggest disabling the creation of b-emlog.txt, and then add a command-line option to enable its creation for those who really want it.

These comments apply to official B-Em 2.2 release, as well as the current build. The problem seems to be present on Linux and Windows.

The changes I have made so far in db-music5000 haven't made things worse, but also haven't made things better. But then I wouldn't have expected them to change much (it's mostly been refactoring)

In very general terms, the audio output sounds pretty rough. I really noticed this when I hooked up a decent amp and speakers, so that I could compare the B-Em Music 5000 emulation with an FPGA hardware implementation (that uses a decent SPI DAC). The difference was very marked!

Initially I assumed it was something amiss with the Music 5000 emulation, but then I realised that even the ^G Beep (VDU 7) was suffering.

I think there are several things going on:

• the audio output of most PCs is pretty noisy
• the output level of B-Em is quite low compared to other applications
• there is possibly a bug in the sound system that is causing discontinuities when switching audio buffers (every 32ms).

Something is definitely not right here.

As a comparison, I tried the Beech emulator on Windows, and this sounded very clean in comparison.

I need to do some more investigation, but I would be interested in feedback from other people. Most people I suspect would not notice, unless the issue is pointed out to them.

While attempting a build I noticed some issues which only seem to occur on this newer version of the compiler.

• tsearch.c contains a typedef for max_allign_t which now seems to be already done in the standard headers, or the surrounding #ifndef text must have changed
  /* #ifndef __CLANG_MAX_ALIGN_T_DEFINED typedef long double max_align_t; #endif */
• Makebem.bat points hardcoded to C:/Mingw where in Msys2 we have C:\msys64\mingw32 and mingw64
  set MINGW=c:\MinGW. Also, a makebem.sh seems more natural but preferably the autogen part should work.
• Compling Z80.c fails because in the Makefile.win it is actually called z80.c (lower case). Somehow this compiler version is case-sensitive.

I know it's only a small thing, but I would like to see the appropriate startup banner (and possibly any other subtle behaviour changes) when using a Master Turbo. The relevant ROM is available at mdfs.net (http://mdfs.net/Software/Tube/6502/) and it works fine if I drop it in in place of the existing second processor ROM, but it would be nice if b-em supported both ROMs. We could either make this a new second processor type (which you could then use with a BBC B or whatever; I believe there were add-ons to allow this with real hardware) or make selecting it part of the Master Turbo option.

Boot the attached ssd tube-bug.zip in Master Turbo mode. In MODE 7 you should see a message on screen, in any other mode a flash of green raster and then some crap left in the screen buffer.

This is copying 256 bytes from the parasite RAM over to the host RAM using the 256 byte "fast" transfer protocol - see AUG page 338 for details.

Alas on b-em (and jsbeeb) the Tube code hangs during the Tube release call waiting for a byte from the parasite that never arrives. This has been verified to work on my actual Master Turbo hardware.

Running a new build of B-em.exe downloaded from GitHub onto Windows 10 triggers the Widows Defender Smart Screen.
Apparently, digitally signing the exe with a consistent publisher allows MS to update their databases and make this less recurrent for installations.

https://www.codeproject.com/Questions/555248/Willplussigningplusanplusexecutablepluspreventplus

At the moment this is hard coded to Win32.

It's ugly, but something like this should work:

The hard part is not hard-coded a path to bash.exe!

If I modify a directory which the emulated platform has open, I frequently get a null pointer access in scan_dir(). I don't know why because I don't know the logic, unfortunately --- it appears that there are NULL entries in dir->cat_tab, which causes this loop to fail:

while (ptr < end) {
    ent = *ptr++;
    ent->attribs |= ATTR_DELETED;
}

Adding a simple if ent {} around the obvious line stops the immediate crash, but is probably the wrong solution.

From Hoglet in the comments on Issue#50:

Hi Guys,

I'm sure you are aware of this, but VideoNuLA now implements three different attribute based modes:

normal attribute mode (reg 6 = 1, reg 7 = 0)
text attribute mode (reg 6 = 1, reg 7 = 1)
spectrum attribute mode (reg 6 = 2, reg 7 = don't care I think)
It looks like the B-Em emulates normal and text attribute mode, but not the spectrum attribute mode.

Probably we should create a separate issue to track this.

Dave

So this is the separate issue.

Instead of sending this to stderr, we should probably write this to a file.

(This is what BeebEm does)

After changing the set of ROMs to be loaded for a particular model the order in which they are loaded, and thus which slots they appear in, is not stable.

For each model emulated, B-Em loads the roms from a sub-directory of the roms directory in the distribution. It starts at slot 15 and works downwards processing the rom files in the order they are returned by the Allegro al_findfirst/al_findnext functions. On Linux, at least, these functions return the filenames not in any obvious order, like alphanumeric, but in the order the OS happens to have the filenames stored in the filesystem. On some hash-based filesystems this is in hash order and may as well be random, while on others it is the order in which the files were copied into that directory independent of the name.

Controlling which rom goes into which slot is sometimes important as it sometimes necessary, for example if two ROMs implement the same command its may be necessary to put the one that should take priority in a higher numbered slot.

Two possible solutions come to mind:

1. Read the set of files in the directrory and then sort this list before processing it.

2. Make two passes through the files in the directory. On the first pass process only those rom files whose filename starts with a number indicating a specific slot to be loaded. On the second pass load the remaining roms into the remaining slots.

Attached in an ssd generated from beebasm; it works fine in MAME and jsbeeb, but half the files show up as corrupt in b-em.

To reproduce, load into a BBC Master 128 with DFS and autoboot. It'll crash on startup because setscrn is corrupt. Try it on jsbeeb and setscrn will contain real machine code.

I originally thought this was a beebasm bug (stardot/beebasm#32) until I realised that the disk catalogue between the known-good image and the known-bad image was identical. Somehow b-em is just reading half the files from the wrong place on the disk.

I've checked that I'm up-to-date with the head of master.

mandel.zip

With the emulation of the Music 5000 syntheisier and the Music 4000 keyboard (via MIDI) it would be good to complete the set with the Music 2000 MIDI interface.

Me again, I'm afraid...

My Cowgol build script got around 2/3 of the way through a build and failed weirdly; investigation shows that VDFS seems not to be able to delete or rename files. They fail silently.

*BASIC
>SAVE "FOO"
>*.
FOO        WR/r
>*RENAME FOO BAR
>*.
FOO        WR/r
>*DELETE FOO
>*.
FOO        WR/r

My build script was failing because it it does this:

*RUN PROGRAM1
*DELETE INPUTFILE
*RENAME OUTPUTFILE INPUTFILE
*RUN PROGRAM2

...so on VDFS, program2 is using the same input file program1 was.

I have a suspicion that the * commands are recognised but not implemented yet --- I haven't made *DELETE, *RENAME, *DESTROY etc produce anything, not even an error, even when given completely bogus input.

I'll have a quick look, but I don't have much time at the moment. (At the very least it'd be nice to report an error.)

I just built 4ce6e9d (current master HEAD) on Linux. It works great generally, but if I choose Settings->Model->Master Turbo, it seems to enter a strange stuck state where I can't turn the second processor off. If I subsequently choose Settings->Model->BBC Master 128 it doesn't turn the second processor off. Choosing a different second processor or none from Settings->Second processor doesn't make any difference - I always have a 6502 second processor.

Cheers.

Steve

Per a StarDot thread, I felt I should formally open an issue here..

What is the concern:
Most software written for the BBC micro uses an obsolete printer control method, using Escape sequences which were available on Centronics or Serial interfaced printers of their era. Current printers connected to Mac or PC systems are more likely to be USB based, and use entirely different printer control languages such as PostScript or HP-PCL.

What is desired:

A "virtual printer" that can emulate the control seqeunces translating them into an appropriate modern format, should be implemented. The output format of this could be PDF, or a suitable bitmpa image format for graphics.. If no specialist sequences are used then a plain text file could also be generated.

IIRC a "Virtual Printer" was implemented in some experimental builds of DosBox, but I have no further details at present...

If you look at the attached screenshot, you can see that some of the P characters look different to others. This is with allegro4 on Linux, built from commit 8277fe9.

I have seen similar results using older versions of b-em on Windows. I suspect the cause is that the emulator's window is not a neat multiple of the BBC screen size, so one BBC pixel gets mapped to a fractional number of pixels on the host screen and so some BBC pixels are (say) 2 host pixels wide and some are (say) 3 host pixels wide. On Windows I was able to fix this by using the menus to force the emulated window to an appropriate size, but I don't see any such options on Linux (nor is the window itself resizable)

As discussed at http://stardot.org.uk/forums/viewtopic.php?f=4&t=10823&start=270#p195413 though there is is some prior discussion too.

I extended my own version of b-em to have pause on PAGE DOWN (to complement PAGE UP) and single frame (20ms) step on RIGHT ARROW when paused. These are both very helpful for debugging, particularly graphical effects. Would this be useful to integrate into the main repo?

I'm not sure how to do a PR across repos plus don't have the "official" build environment set up on my machine to properly test - just a hacked together Visual Studio solution.

The small changes are here: kieranhj/b-em@7adb94f

Allow elements of the emulation environment to be controlled using star commands from the "Beeb".

e.g. *MUSIC5000 would "turn on" the 5000 Music system code.

This should be done by passing all unprocessed Commands to the emulator raw to be parsed.
Be careful not to make the commands too general as to cause security issues.

If you click on a uef file associated with b-em it does not load it in b-em as a tape but try's to load it as a disc image.

Readme file refers to an HDInit.ssd progrma used to initalise a Hard disc image. This disc image is not present in the distribution.

C:\MinGW\b-em>makebem.bat
windres.exe -i b-em.rc --input-format=rc -o b-em.res -O coff
C:\MinGW\bin\windres.exe: b-em.rc:145: syntax error
b-em.rc:4:0: fatal error: when writing output to : Invalid argument
compilation terminated.
C:\MinGW\bin\windres.exe: preprocessing failed.
make: *** [b-em.res] Error 1

As discussed at http://stardot.org.uk/forums/viewtopic.php?f=3&t=12150&start=510#p196887 the NuLA emulation doesn't match the behaviour of real NuLA hardware in extended attributes mode. If you run this program:

REM Start off in a known state
*VNRESET
MODE 0
?&FE22=&61:REM attribute mode
?&FE22=&71:REM extended attribute mode
REM display a block using colour pair 7 - i.e. foreground is logical colour 15,
REM background is logical colour 14
FOR I%=0 TO 127
I%?&3000=255
NEXT
?&FE21=(15*16)+(8 EOR 7):REM set logical colour 15 to physical colour 8
?&FE21=(14*16)+(0 EOR 7):REM set logical colour 14 to physical colour 0
?&FE23=&88:?&FE23=&88:REM set physical colour 8 to mid-grey
REM ?&FE23=&F8:?&FE23=&00:REM set physical colour 15 to mid-red
PRINTTAB(0,5);
REPEAT UNTIL FALSE

it should produce a group of non-flashing mid-grey blocks with black lines between them, but on b-em it produces a group of flashing mid-grey/white blocks.

Previous versions of b-em would run from the build directory. This one won't because it can't find the config. Can you consider either:

• Adding the b-em executable directory to the search path
• Creating the config in the home directory if it doesn't exist

See long discussion here:
http://stardot.org.uk/forums/viewtopic.php?f=4&t=12646

Building the allegro5-pre2 release candidate from source and running in Arch linux, the first two runs after a cold boot give a flickering line at the bottom of the window (Tested twice). Subsequent runs don't exhibit this problem.

I am not totally convinced that this is a b-em problem - it goes away, but raising it anyway just in case.

See this video (Sorry, the focus could be better - let me know if you need me to try to get a better one)
Google drive link

And thank you for your work on b-em. It is a massive improvement over the previous version. I hope you find these reports useful!

At some point I'd also like to investigate the set of differences between the Windows and Linux builds. With the Allegro 5 native dialogue option and hopefully the bugs in video bitmaps fixed on Linux there should be less need for platform specific code inside B-Em - that's what Allegro is supposed to handle.

I haven't spent a lot of time trying to investigate this myself, so don't take it too seriously, but FWIW I had a quick go at building this and it failed...

steven@riemann:~/src/b-em3/b-em$ make 2>&1 | head -20
Making all in src
make[1]: Entering directory '/home/steven/src/b-em3/b-em/src'
  CC       b_em-gui-allegro.o
gui-allegro.c:41:8: error: unknown type name ‘ALLEGRO_MENU’
 static ALLEGRO_MENU *disc_menu;
        ^
gui-allegro.c:58:31: error: unknown type name ‘ALLEGRO_MENU’
 static void add_checkbox_item(ALLEGRO_MENU *parent, char const *title, uint16_t id, bool checked)
                               ^
gui-allegro.c:66:28: error: unknown type name ‘ALLEGRO_MENU’
 static void add_radio_item(ALLEGRO_MENU *parent, char const *title, uint16_t id, int this_value, int cur_value)
                            ^
gui-allegro.c:71:27: error: unknown type name ‘ALLEGRO_MENU’
 static void add_radio_set(ALLEGRO_MENU *parent, char const **labels, uint16_t id, int cur_value)
                           ^
gui-allegro.c:87:28: error: unknown type name ‘ALLEGRO_MENU’
 static void add_sorted_set(ALLEGRO_MENU *parent, menu_map_t *map, size_t items, uint16_t id, int cur_value)
                            ^
gui-allegro.c:98:8: error: unknown type name ‘ALLEGRO_MENU’
 static ALLEGRO_MENU *create_file_menu(void)
steven@riemann:~/src/b-em3/b-em$ dpkg -l | grep -i allegro
ii  liballegro-acodec5-dev:amd64                  2:5.0.11-2                                   amd64        header files for the Allegro 5 audio codec addon
ii  liballegro-acodec5.0:amd64                    2:5.0.11-2                                   amd64        audio codec addon for the Allegro 5 library
ii  liballegro-audio5-dev:amd64                   2:5.0.11-2                                   amd64        header files for the Allegro 5 audio addon
ii  liballegro-audio5.0:amd64                     2:5.0.11-2                                   amd64        audio addon for the Allegro 5 library
ii  liballegro-dialog5-dev:amd64                  2:5.0.11-2                                   amd64        header files for the Allegro 5 dialog addon
ii  liballegro-dialog5.0:amd64                    2:5.0.11-2                                   amd64        dialog addon for the Allegro 5 library
ii  liballegro-image5-dev:amd64                   2:5.0.11-2                                   amd64        header files for the Allegro 5 image addon
ii  liballegro-image5.0:amd64                     2:5.0.11-2                                   amd64        image addon for the Allegro 5 library
ii  liballegro-physfs5-dev:amd64                  2:5.0.11-2                                   amd64        header files for the Allegro 5 physfs addon
ii  liballegro-physfs5.0:amd64                    2:5.0.11-2                                   amd64        physfs addon for the Allegro 5 library
ii  liballegro-ttf5-dev:amd64                     2:5.0.11-2                                   amd64        header files for the Allegro 5 TTF addon
ii  liballegro-ttf5.0:amd64                       2:5.0.11-2                                   amd64        TTF addon for the Allegro 5 library
ii  liballegro5-dev:amd64                         2:5.0.11-2                                   amd64        development files for the Allegro 5 library
ii  liballegro5.0:amd64                           2:5.0.11-2                                   amd64        portable library for cross-platform game and multimedia development

Let me know if you need any more information, of course.

Cheers.

Steve

If you don't insert a disc in the drive but try to use it anyway, the disc drive spinning noise continues until a disc image is entered to that drive.

If I select the "BBC Master 128 w/ MOS 3.5" option, b-em immediately aborts:
steven@ubuntu:~/src/b-em$ ./b-em
double free or corruption (!prev)
Aborted (core dumped)

Running under gdb:

steven@ubuntu:~/src/b-em$ gdb ./b-em
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./b-em...done.
(gdb) run
Starting program: /home/steven/src/b-em/b-em 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeab38700 (LWP 2061)]
[New Thread 0x7fffe853a700 (LWP 2062)]
[New Thread 0x7fffe7d39700 (LWP 2063)]
[New Thread 0x7fffe7538700 (LWP 2064)]
[New Thread 0x7fffe68f0700 (LWP 2065)]
[New Thread 0x7fffd6aa5700 (LWP 2066)]
[New Thread 0x7fffd62a4700 (LWP 2067)]
[New Thread 0x7fffd5aa3700 (LWP 2068)]
[New Thread 0x7fffd509a700 (LWP 2069)]
[New Thread 0x7fffa3444700 (LWP 2070)]
[New Thread 0x7fffa2c43700 (LWP 2071)]
[New Thread 0x7fffa2442700 (LWP 2072)]
[New Thread 0x7fffa1c41700 (LWP 2073)]
[New Thread 0x7fffa1440700 (LWP 2074)]
[New Thread 0x7fffa0c3f700 (LWP 2075)]
[New Thread 0x7fff57fff700 (LWP 2076)]
[New Thread 0x7fff4b7fe700 (LWP 2077)]
[New Thread 0x7fff4affd700 (LWP 2078)]
[New Thread 0x7fff4a7fc700 (LWP 2079)]
[New Thread 0x7fff49ffb700 (LWP 2080)]
double free or corruption (!prev)

Thread 1 "b-em" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

When compiling on Windows, gcc gives the following warnings:

gcc.exe -std=gnu99 -O3 -Wall -DBEM -DVERSION="Win32" -DINCLUDE_DEBUGGER -DUSE_MEMORY_POINTER -c video.c
video.c: In function 'videoula_write':
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]
video.c:130:78: warning: array subscript is below array bounds [-Warray-bounds]

This is >gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)