Support editing for 'retro' hardware modes

[bcampbell]

In particular, some of the C64 modes: http://studiostyle.sk/dmagic/gallery/gfxmodes.htm

Although most of the techniques required to do so would also apply to other hardware (eg ZX Spectrum, various Amiga modes).

For reference: Timanthes - pixel editor in C# with some C64 support.

@caiwan: you mentioned a native code exporter for C64 (which I assume generates 6510 asm encoding the image). Can you elaborate? Any websites which detail this stuff?

[caiwan]

Here's the original whitepapers for Interlaced HiRes and I. Multi Color which I got from from @jubatian: https://gist.github.com/caiwan/72e6571fc4d86e6446b6

[Jubatian]

Huh, that thing wasn't that good to do such! It was rather a kind of hack to deal with some pixelling with a limited app. written to convert and display them on the breadbin. The limitations were (are) that it only supports up to 104 pixels height, and either 8, 4, 2, 1 or 0 sprite layers. The 104 pixels came from that then I didn't attempt to work around the problem of 21 pixel sprite height, which if the sprites are laid out simply sequentally, would collide with Bad Lines where there is not enough time to update the sprite pointers for the next row.

Moreover the drawing program itself is a bit inaccurate on terms of how the interlaced color would look like. There are two problems on this term: for one, I didn't knew about gamma when I did it (this roughly means that a dithered 0x000000 - 0xFFFFFF pattern wouldn't result in the perceieved color of 0x808080 on a proper display, rather something like maybe 0xC0C0C0), for an other, I didn't know about the effect of the capability of how fast the beam may adapt to a change, which affects what color a horizontally dithered pattern would produce on the display (that's why gamma calibration tools and proper interlace mode images use horizontal stripes instead of dither patterns). These should be corrected if attempting to produce such a drawing app. which would automatically deal with these (by supporting showing the interlaced result as a plain image, and when optimizing for the best interlace pattern, preferring to build it from horizontal stripes).

If interested, I could jump in the C64 side, building conversion routines for the breadbin, and display routines. One particular idea when I did my pixel pushing hack was to automatically deal with arbitrarily placed sprites, that would be something definitely spiffy. Later I did many VIC sync experiments, so I have good ideas on how to deal with that aspect, to build an entire display VIC synced with quite free sprite placement (I wanted to do some game, but then gave up).

I would like to hear about the idea, though. My pixeller's primary strength was that it automatically determined the useable colors for a 8x8 block, using always the nearest to which was on the brush, so you could paint, and the same time the result was exactly what it would look like once exported to the 64. I don't think this is reasonably possible with several of the hack modes (particularly those where due to crafty sprite placements interdependences arise between neighboring pixels, such as by having X extended sprites behind a Hi-Res surface, or the MCI mode as described on studiostyle.sk). FLI is possible, but on FLI you can't have sprites, so it is again something different. I would stay with the original idea (retain the 8x8 block limit, using sprites aligned with the pixels of the mode, optional interlace), first thing to expand towards being arbitrary sprite placement. It would have two benefits: one is allowing to craft the image allowing to increase color count where it is necessary, the other is that the display routine produced for this might be able to deal with free sprites, maybe even with open sideborders if specific constraints are met, which allows for some creative effect coding over the image.