SpritesMind.Net

z80_driver.bin is any compiled Z80 code that you going to use as driver. This code only loads the driver, however, you also will need a bit of similar code to pass parameters to the driver, instead of loop you'll have to do few pokes that will put the parameters into certain locations of the Z80 RAM...

You don't need any special code to init the Z80, it is just few register writes - busreq on, fill Z80 RAM with your code, reset Z80, busreq off. You probably can easily do it with pokes in BEX, or, if there are some alignment problems, with few inline move opcodes that will act like pokes. Something...

I don't know such attempts.

Technically doable, but quite pointless in my opinion. There aren't much people who interested in console homebrews even, why spent even more effort for way lesser auditory?

I honestly don't know. I'm sure that there still could be enough time for game logic if it is all done properly, i.e. interrupt handler not in C etc. SNES is much slower, but manages to run the game well enough, I don't think SMD will be less capable in this case.

Is it really necessary? There is text export, which is much easier to parse than VGE.

These are interesting and useful results, thanks. That's cool that local vars are faster.

It would be interesting to test a simple time-wasting loop that uses few variables as counters, and check if there is difference when these variables are local and global. I mean, something like unsigned short cnt1; unsigned long cnt2,cnt3; for(cnt1=0;cnt1<50000;++cnt1) { for(cnt2=0;cnt2<10000;++cnt...

Global variables are more effective on 8-bit platforms. It is unclear for M68K and various compilers that are available. I think it should be just tested, moving few variables from and into a function should not be a big problem.

Good start. The tearing is probably because you see scroll offsets too late. You need to organize the code in a way that you only do VRAM/VDP parameters updates at VBlank time, and everything else, including preparation of the data for the updates in remaining time. Like: Wait for vblank Set scroll ...

Isn't GCC optimizer is smart enough to detect that the value is never used so it does not even try to calculate it, i.e. your u16 tileNumber ... line does not execute at all when you comment out its use?

These aren't calls, actually, as you can see there is nothing that could be that slow: #define GFX_WRITE_VRAM_ADDR(adr) ((0x4000 + ((adr) & 0x3FFF)) << 16) + (((adr) >> 14) | 0x00) #define TILE_ATTR(pal, pri, flipV, flipH) (((flipH) << 11) + ((flipV) << 12) + ((pal) << 13) + ((pri) << 15)) So probab...

Not a big deal to sacrifice Z80 for a debug build. However, why not simply modify an emulator and add a profiler? I.e. a write to a not existing reg starts a counter, a write to other reg stops it, and the value is displayed with OSD. It done this way in few debugging NES emulators, measurement is d...

I think 68K cult following is mostly exists on the Amiga and Atari ST scenes, so perharps you may check some related forums for a 68K section.

Many C optimization tricks are CPU-independent, so you may check these two pages, they are about CC65 compiler and 6502: 1 , 2 . However, it is a good idea to test some of the tricks and check assembly output, because in your enviroment one tricks could be effective, while other aren't too effective...

Yes, technically it is very simple - vertical scroll position modified every scanline using hblank interrupt and a precalculate table of offsets to create 'perspective' (i.e. just scroll_y+table[scanline]).