2009/4/9 Musus Umbra <[email protected]>: > On Wednesday 08 Apr 2009, Theo Markettos wrote: >> How odd. What RISC OS video mode are you in? It looks like blocks >> of maybe 4 pixels are flipped left-to-right. > > It'll be mode 27 by the looks of it. > >> Might it be a big/little endianness problem? > > That's what I thought when I saw the flipped columns and that 'p' in the > ResourceFS filer icon... and I was bored this morning, so I > reconstructed the desktop image by flipping pixels around in David's > screenshot ;) > > FWIW, I get a correct image when the pixels in each block of 8 are > flipped like this: 01234567 -> 32107654. Interestingly, the pointer is > the only part of the desktop that doesn't fix, I'll attach it :) > > Dunno if any of that helps... >
Very helpful - it told me what to look for in the code! If anyone has the code to hand, the relevant stuff is in the "vidcthread" method in vidc20.c. If you boot up the emulator on RISC OS 4 without a hard drive image, it emits reason code 32 (whatever that is) for 8bpp. If you look at that bit of code, there is nothing that tweaks the code for big-endian. Several other bits in there are without big-endian stuff either. Having changed the code (just for 8bpp, reason code 32), I now have a display that works! I did have a random crash (not sure why) but was all right after a forced quit and a restart. Now that the display works fine (at least in this mode), I can now see what's happening with the keyboard: if you press a key, there's an initial pause and then it auto-repeats forever. I wonder if there's something amiss with the CMOS? Perhaps its words need reversing? I tried moving my current file out of the way, but it didn't even get to the desktop. _______________________________________________ Rpcemu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
