Page 2 of 2
Re: Tectoy's weird VDP behavior
Posted: Tue Feb 20, 2018 3:45 pm
by Sik
That'd explain why Miniplanets crashes at random at least... (it probably breaks NBA Jam too then? or was that just controller access without halting the Z80?)
Re: Tectoy's weird VDP behavior
Posted: Tue Feb 20, 2018 5:17 pm
by Chilly Willy
Sik wrote: Tue Feb 20, 2018 3:45 pm
That'd explain why Miniplanets crashes at random at least... (it probably breaks NBA Jam too then? or was that just controller access without halting the Z80?)
The hardware bug that causes shortened cycles if certain circumstances occur when accessing IO without stopping the Z80 doesn't matter if the rom is fast enough. That's why virtually no games beyond the first year bother stopping the Z80 to read the controller. I'm unaware of a flash cart that is slow enough to show this bug. It's possible that an emulation trying to be completely anal about timing without giving you an option of faster rom access might show this bug.
Re: Tectoy's weird VDP behavior
Posted: Tue Feb 20, 2018 6:33 pm
by cero
Everything from me was run from the cart port, not the SD card.
Re: Tectoy's weird VDP behavior
Posted: Wed Mar 07, 2018 3:25 am
by FireRat
How about sending a DMA request... After the manual writes? Weird, but could it be that a DMA forces some sort of VRAM buffer refresh? that manual writes miss... ?
I mean, oddly enough, what if had to do with the way the screen is drawn from the emulator's code itself? There must be some reconversion at some point, from the MD format, into the appropiate output supported by the different hardware.
What if, writes and DMAs indeed all happen properly within Buffer A (internal), but they forgot to make it convert to Buffer B (screen output) in one only one of either cases?
For example: Try opening the sprite list viewer in Gens KMod. List will appear blank, unless you also keep VRAM viewer opened at same time.
Because, I imagine, that it's a lot easier to program a renderer that composes the screen by using their good old typical display libraries... working in a "common" format (definitely not 4bpp) so it's also easier to apply any necessary effects and so on...
I'm only a 68k programmer though, I couldn't say how much chances are of that to happen, I just talk from previous experience...
A good reference to test, try the debug mode from Sonic the hedgehog 1: If the numbers do update, BUT are delayed by 1 frame, then that's it. Or try to run fast, and check if the scroll engine seem some more sloppy than usual at the edges.
The game does constant DMAs every frame, but does those manual writes after them.
Re: Tectoy's weird VDP behavior
Posted: Wed Mar 07, 2018 10:29 am
by cero
How about sending a DMA request... After the manual writes?
I did:
...
- DMA write one tile
- DMA write a few tiles
- DMA queue one tile
...
Re: Tectoy's weird VDP behavior
Posted: Wed Mar 07, 2018 1:05 pm
by Eke
cero wrote: Tue Oct 03, 2017 5:31 pm
The new tilemap data snaps in entirely during one frame, as if the fifo was massive, but I can't think of any reason for the delay.
That is most likely the case, the clone is probably using a much larger FIFO (or a VRAM cache).
Remember that:
1) DMA will release 68k bus and software execution as soon as the last data read from 68k bus is written to FIFO (data in FIFO still has to be written asynchronously in VRAM)
2) Data port writes will return immediately as long as FIFO is not full
so, with a very large FIFO, it's possible your tilemap filling code ends (and fade in starts) before the first tilemap data has even been written to VRAM
Have you tried waiting for VDP status FIFO empty flag to be set before re-enabling display ? Similarly, you could play test FIFO full flag after continuous writes to try to figure the new FIFO size. There is the possibility those flags do nothing on this clone though.
Someone could also test the 'Chaos Engine' game in this clone, it has graphical issues in emulators if VRAM writes delay and FIFO timings are not correctly emulated.
Re: Tectoy's weird VDP behavior
Posted: Wed Mar 07, 2018 2:13 pm
by FireRat
cero wrote: Wed Mar 07, 2018 10:29 am
How about sending a DMA request... After the manual writes?
I did:
...
- DMA write one tile
- DMA write a few tiles
- DMA queue one tile
...
Oh, just thought you done these before the manual write instead of after, just like in first post...
Re: Tectoy's weird VDP behavior
Posted: Thu Mar 08, 2018 3:46 am
by Sik
There's no way in heck a large FIFO would waste 60 frames in flushing itself. Especially when the DMA hogging it has itself been flushed before the fade in starts.
There are two problems here:
- We can't figure out how to stop this behavior (or what could be triggering it)
- We can't understand how the heck could any game even work with this
Miniplanets hangs at random (probably the bug Stef described) but I don't recall it ever having any graphical glitches and it does indeed have the 68000 write directly to the tilemap in several occasions.
I'm stumped on this.
EDIT: can you isolate it into a sample program and post the full code of that? (no comments like "// fade in") We really should know the exact full procedure at this point.
Re: Tectoy's weird VDP behavior
Posted: Thu Mar 08, 2018 9:06 am
by cero
I already tried to just have the image writing code and fade in a sample program - it didn't show the bug. Something in the larger program triggers this, maybe the clone has several modes, tuned for specific games (yay for game-specific hacks due to bad quality emulation), and mine somehow gets into one.
Code: Select all
#include <genesis.h>
#include "files.h"
#include "../coords.h"
static u16 tmppal[64];
void rendering(const u8 enable);
static const u16 flower1pal[16] = {
RGB24_TO_VDPCOLOR(0x334225),
RGB24_TO_VDPCOLOR(0x3e4e2f),
RGB24_TO_VDPCOLOR(0x4f6132),
RGB24_TO_VDPCOLOR(0x4a533c),
RGB24_TO_VDPCOLOR(0x595b53),
RGB24_TO_VDPCOLOR(0x666565),
RGB24_TO_VDPCOLOR(0x68704d),
RGB24_TO_VDPCOLOR(0x737474),
RGB24_TO_VDPCOLOR(0x8f6a84),
RGB24_TO_VDPCOLOR(0xab6b9e),
RGB24_TO_VDPCOLOR(0xc468b8),
RGB24_TO_VDPCOLOR(0xce91d8),
RGB24_TO_VDPCOLOR(0xda6acd),
RGB24_TO_VDPCOLOR(0xe89d7f),
RGB24_TO_VDPCOLOR(0xecb216),
RGB24_TO_VDPCOLOR(0xed80e6),
};
static const u16 flower2pal[16] = {
RGB24_TO_VDPCOLOR(0x124108),
RGB24_TO_VDPCOLOR(0x22690f),
RGB24_TO_VDPCOLOR(0x3a7b25),
RGB24_TO_VDPCOLOR(0x49a10d),
RGB24_TO_VDPCOLOR(0x5a893c),
RGB24_TO_VDPCOLOR(0x73a766),
RGB24_TO_VDPCOLOR(0xc77005),
RGB24_TO_VDPCOLOR(0xaba67b),
RGB24_TO_VDPCOLOR(0xb49c47),
RGB24_TO_VDPCOLOR(0xa7b097),
RGB24_TO_VDPCOLOR(0xc5caaf),
RGB24_TO_VDPCOLOR(0xe7a107),
RGB24_TO_VDPCOLOR(0xe1e3c8),
RGB24_TO_VDPCOLOR(0xebd264),
RGB24_TO_VDPCOLOR(0xfde709),
RGB24_TO_VDPCOLOR(0xf5f8e9),
};
static void fadeout() {
VDP_fadeOut(0, 63, 30, 0);
}
static void fadein() {
VDP_fadeIn(0, 63, tmppal, 30, 0);
}
static void fillbg(const u16 * const buf) {
u16 x, i = 0;
u8 y;
for (y = 0; y < 28; y++) {
for (x = 0; x < 40; x++, i++) {
VDP_setTileMapXY(PLAN_B,
TILE_ATTR_FULL(0, 0, 0, 0, TILE_USERINDEX + buf[i]),
x, y);
}
}
}
int main() {
u8 i;
rendering(0);
VDP_loadTileSet(&flower1, TILE_USERINDEX, 1);
VDP_waitDMACompletion();
memcpy(tmppal, flower1pal, 16 * 2);
fillbg(flower1coords);
VDP_setPaletteColors(0, palette_black, 64);
rendering(1);
fadein();
for (i = 0; i < 60; i++)
VDP_waitVSync();
fadeout();
rendering(0);
VDP_loadTileSet(&flower2, TILE_USERINDEX, 1);
VDP_waitDMACompletion();
memcpy(tmppal, flower2pal, 16 * 2);
fillbg(flower2coords);
VDP_setPaletteColors(0, palette_black, 64);
rendering(1);
fadein();
while (1)
VDP_waitVSync();
return 0;
}
As for bisect-cutting the app to get to the bottom of this, it would take ages since I don't have the Tectoy console physically with me.
Re: Tectoy's weird VDP behavior
Posted: Sat Mar 17, 2018 4:32 am
by carpediem
Hey guys, I'm from Brazil and I bought one just today to complete my collection..maybe next monday or tuesday I'll put my hands on it
So far, surely you guys already know but just to reinforce that this GOAC runs under the atgames's alternate version of the infamous redkid 2500 chip (and almost sure that is the same chip used in the firsts handhelds version but with sdcard support). So if you want to know how your homebrews can behave on 2017 TT genny, just get these alternates that I believe is easier for you in US or Europe.