SpritesMind.Net

Hello again.
Please be patient if I take too long to reply any questions, as it's going to be very hard to get free time, working at a limited pace until February.


A few friends and me have been writing & arranging a fully documented cross-platform engine, for the MD, 32x and SCD consoles, including Mode 1 and the full 32xCD combination, all written in Assembly. Meant to be found useful and "versatile" enough, its main goal is to keep it free and open from a legal viewpoint, so anyone could use it for Any purposes-
In simpler words, your same code could run in any of these platforms, unless you take a more complex route and program for a dedicated target with its extra features.

Technically, Build time is driven through GNU Make, under a "Build Objects / Link them" scheme. Uses open-source VASM and VLINK tools to assemble the Z80 and 68k code, plus a custom checksum generator and CD image builder. Each Makefile.[TARGET] file produces its output by fitting the Object files however does "best" (that's relative) to the Target; can automatically link objects from a previous build meant for a different Target, and for each SCD file (speeding up build process) even! The latter point should count, only as long as there's no VDP-related code in said Object files, though (more on that later).
Optimization Priority: CPU > ROM > RAM

Some (planned) key features, these may change at any time:
- 32x PWM driver on SH2

• Stereo Output
• Pan control
• Vol control

- SMPS-derivaten sound driver

• Z80-based version
• Not sure about a 68k-based version?

- 32x Framebuffer renderer on SH2, 256 color mode

• "Corner Pin" support
• Scaling & Rotation support
• DMA-based sprites list (for anything that doesn't require any of the above)
• "Basic" 3D support (Using flat color texture, no lighting) (Besides need to investigate a lot yet, may and up using ".blend to custom" format converter or similar method))

- SCD ASIC library
- SCD ISO-9660 library, V2 or Joliet (whatever turns best, need to investigate)
- SCD builds shall run core engine from 12MHz SubCPU

• > The other way could be optional (?)

Regarding the presentation, it's meant to, overall, look like this:
https://i.imgur.com/5y5fBLg.png
Here I'm showing the first inmediate drawback about SubCPU support: There's no direct way to communicate to VDP, and it's necessary to send the command to MainCPU; either "inmediately", or to its VInt-based queue, however necessary. This is why the commands and data is sent through macros: It would build differently if the target was SCD.

With some help from Mercury's Sonic Physics Guide, a first "ideal" release would include a character with Sonic's physics, a few other objects to play with, and a scroll engine capable of drawing in individual 16x16 blocks and 128x128 chunks (made from 16x16 blocks) modes. It will be up to you to replace it with a Sonic the hedgehog's spritesheet and make a fangame upon it, or create something new.

This project is still taking shape, so any comments would be appreciated. For you, is any of this a good idea in the first place?
Please excuse any ignorance from mine part, especially regarding terminology, but, isn't the intention what counts?

A few things to note:
- It's the first time I try an arragement where files aren't directly attached to the "ROM tree"
- I'm beginning from the MD alone's implementation

Hope to read more exiting news very soon!

I always liked the idea of a cartridge game using the SCD sub-CPU. With the lasers dying out that could be the only way to benefit from a SCD, unless a drive emulator comes along.

One reminder about the 32X - the 68K->SH2 DMA is flakey. You either need to not use it, or to add error checking and retries to the code. If you look at 32X games that use it, they transfer the data in small chunks, checksum the data and check the checksum after the data is transferred, have timeouts in case the transfer never finishes, and retries for when the transfer doesn't work. At the moment, I tend to use the comm registers to transfer data, or the vram if there's LOTS of data. The vram buffer makes a good temporary buffer for a number of things... I use it for compressing/decompressing save data, for example. Just put a static image in the buffer, flip it, and you've got 128KB of "free" ram you can do anything you want with. Just don't forget to rewrite the line table if you overwrite it.

Chilly Willy wrote: ↑

Sat Jan 06, 2018 9:19 pm

One reminder about the 32X - the 68K->SH2 DMA is flakey. You either need to not use it, or to add error checking and retries to the code. If you look at 32X games that use it, they transfer the data in small chunks, checksum the data and check the checksum after the data is transferred, have timeouts in case the transfer never finishes, and retries for when the transfer doesn't work.

If you really need to do that then DMA has definitely no use :-/ Better to transfer it through the CPU...

Yeah, the idea was that the SH2 DMA would handle the block in the background while the CPU was busy, with either the CPU or the VDP DMA handling the 68K side... and then they couldn't get the timing for the VDP DMA, and it looks like the timing for the 68000 barely squeaked by. You'll find references to it in the old material, but they gave up on the VDP DMA by release time. I'm actually surprised any games use ithe 68k/SH2 DMA channel considering the limitations. I'd think that copying the data to the frame buffer, then DMAing the frame buffer on the SH2 side would be the preferred method to handle larger blocks of data, while the comm registers would be the way to go for smaller blocks.

I guess the games that do it only do so because they were originally programmed when it seemed more stable and they just kept getting hacks on top of it instead of just having the DMAs rewritten. Welp.

And yeah, I'd consider that feature to be completely non-working.