Sure, I can do it.
Cleaning of my code took more time than expected, so I did not have time to do a PR today.
GCC has an attribute that can force the compiler to use -O3
for a specific function even if the compiler is set to use other options.
__attribute__((optimize("-O3")))
Who remembers that gameboy emulator? Would these frame-rate advances help it run faster at all?
There’s a Gameboy emulator? o_O
Yes it showed some kind of super slowmo Super Mario Land: Thank you video #1 where we look at buttons and cool features of the LPC11U68
Nice tech demo tho
Interesting. I hadn’t seen that video yet. What happened to it?
Nothing happened. I just never updated it and it fell behind the library updates. I have the source ofcourse
#define TGL_WR \
*reinterpret_cast< volatile uint32_t *>(0xA0002284) = 1 << LCD_WR_PIN; \
*reinterpret_cast< volatile uint32_t *>(0xA0002204) = 1 << LCD_WR_PIN;
void Pokitto::lcdRefreshModeGBC(uint8_t * scrbuf, uint16_t* paletteptr) {
volatile uint32_t *LCD = reinterpret_cast< volatile uint32_t * >(0xA0002188);
uint32_t x,y;
uint8_t *d;
setWindow( 16, 30, 144+16, 159+30 );
write_command_16(0x03); write_data_16(0x1038);
write_command(0x22);
CLR_CS_SET_CD_RD_WR;
SET_MASK_P2;
d = scrbuf;
for(y=0;y<144;++y){
for(x=0;x<160;x+=4){
uint8_t tdata = *d++;
uint8_t t4 = tdata & 0x03; tdata >>= 2;// lowest half-nibble
uint8_t t3 = tdata & 0x03; tdata >>= 2;// second lowest half-nibble
uint8_t t2 = tdata & 0x03; tdata >>= 2;// second highest half-nibble
uint8_t t = tdata;// highest half-nibble
/** put nibble values in the scanlines **/
*LCD = uint32_t(paletteptr[t])<<3; TGL_WR;
*LCD = uint32_t(paletteptr[t2])<<3; TGL_WR;
*LCD = uint32_t(paletteptr[t3])<<3; TGL_WR;
*LCD = uint32_t(paletteptr[t4])<<3; TGL_WR;
}
}
}
Milk and cookie kept you awake, huh? Let’s discuss this. You better come up, Sebastian.
Blade Runner? I haven’t watched it yet.
Share the GB Emulator Code, the community will work on it
It could be fun and a great buzz to have an Nano - GB in ur hand (thanks to pokitto emulation)
Instead of writing *reinterpret_cast< volatile uint32_t *>(0xA0002284)
all the time,
why not set a named variable as a volatile reference to whatever 0xA0002284
is the address of?
volatile uint32_t & someMemoryMappedIOThing = *reinterpret_cast< volatile uint32_t *>(0xA0002284);
It would make the code a bit more self-documenting.
Watch the directors cut of the original.
Yeah, that would be best and I already do it in some places (LCD
). It’s like this only because I’m more familiar with the processor docs than mbed’s and I’m still poking around trying to find out what’s best. Cleaning up later is simple enough (rename LCD
, move it and TGL_WR
to HWLCD.h
?). @Hanski: Does the cleanup you were doing include this?
Edit: Anybody know if one of these can be used for code profiling?
https://produto.mercadolivre.com.br/MLB-704520340-j-link-jlink-j-tag-segger-arm7-9-11-clone-_JM
The “china J-Links” come in 2 different generations. This ad does not say if you can upgrade the firmware to work with Keil MDK 5. That is the version you need and it is more rare than the one that will work only up till MDK 4
Not 100% sure but I think you need something that mentions the v9 firmware
https://probots.co.in/index.php?main_page=product_info&products_id=789
I can also highly recommend the original J-Link EDU version, which I had for a long time. Zero problems, works really well
Ok, just write your suggestion here and will put it in PR.
I don’t know what I did, but I had the plasma demo running at 125fps at one point. lost it though, I was compiling the wrong target, randomly messing about with the code, confused about why nothing was changing. When I came back to it today, its 79fps.
Also I wouldn’t mind having the gb emulator, for novelty value mostly
[edit] it was @FManga’s code further up. 125fps on the plasma demo. Unrolled loops gets 140fps.
How do I get rid of the line of noise along the middle of the screen?
Maybe an addition to the next PR so we can have a define in My_settings.h?