Identify the command table that corresponds to the in-game characters. In the word that @antime described, it should tell you whether it's actual color bank code, or a CLUT which could contain color bank codes. From that, find what sprite type the VDP2 is set to. From there you can figure out...
I make use of that library. It's better incorporated here.
It's the same idea as FIXED. Except, it's fix16_t.
The idea is that the 16 lower bits are meant as the fractional part of the value, while the upper 16-bits are the integral part. This means that you can make use of non-integer...
This is all very confusing to me. You're claiming not to make a profit from the posts, but that isn't what's being contested here.
On the Facebook post, it states: "A full game release will still happen so if you enjoy this demo keep your eyes open for the full release. It will Be available to...
This is a bit off topic, but I wonder if it's possible to use the SCU-DSP for software translucency (similar to PlayStation blending modes).
Possibly perform it in 8x8 or 16x16 "tiles". You have two tiles in each bank, and DMA the results to VDP2.
That's odd. From what I've seen in the SCU restrictions, VDP2 VRAM cannot be read via SCU-DMA.
One thing to note is that you cannot read while VDP1 is drawing. To know whether VDP1 is finished drawing, use the SPRITE END IRQ, or poll the EDSR register. Then use PTMR to force stop drawing.
Detect "transfer over" and perform pseudo draw continuation.
I'm making this more complicated than it needs to be. What I proposed above would be good if I had a third buffer. But I don't. It really sucks that I can't choose where to render.
It's really not easy to keep both VDP1 and VDP2...
I'm completely in the dark here. Is it only possible to render via PTMR=2 when double-density interlace is enabled?
My goal is attempting to allow sub-30 FPS when double-density interlace is enabled by not swapping frame buffers. But now that I think about it, such a thing is not possible since...
I'm running some tests and I have the following (VDP1+VDP2 normal resolution, non-interlace):
0. Set up list of commands in H-WRAM
1. Transfer commands from H-WRAM to VDP1 VRAM
2. Draw. PTMR=1
3. If drawing is done (Sprite End IRQ fired) before VBLANK OUT IRQ, perform FB change. FBCR=3
So the consensus is that there could be a loss of data, or is this the reason why there's a hang, and the host is reporting that not all the data has been sent?
Aside from your last edit in your previous post, I've tested 62, 64, and 256. I haven't verified if all the data...
Thanks for the information. I'll continue testing, and testing the other bits.
So far, I've upped the transfer from 64KiB to 860KiB, and that takes about 700ms.
Is there a 2-byte aligned address to write to the USB FIFO?