6502.org

Are you using SNES Mode 7 style rotozooming for this?

For other readers, basically you start off with a subpixel texel coordinate to display in the upper-left corner, and 2 deltas. For each horizontal pixel the raster travels, it adds one (dx,dy) to the texel coord, and for each new rasterline, it adds a different (dx,dy) to the texel coord. The actual color to draw for each pixel is independently fetched from memory based on that calculated texel coordinate; there's no per-character/tile caching.

So it only takes 8 fixed point registers (current coord, cached start of line coord, delta horizontal, and delta vertical; each with their own x & y) and addition to perform a screenful of affine rotozooming. For doing perspective graphics, usually the horizon is ... horizontal, and each rasterline gets its own (dx,dy) changed during horizontal raster interrupt, as each rasterline is at a different distance from the camera and thus at a different zoom level.

I had to go have a quick read about SNES Mode 7, and, along with your description bellow, I'd say yes, it's the same style.
Usually limited to background graphics only, due to the tile based output. The trick to using it with sprites, or even the screen in the screenshot,
is to use the centre of a huge tile so you never see the edges, leaving you with a rotozoomable object instead of a background. I haven't had a play with perspective (or pseudo-perspective as in the above description) graphics yet, though have seen it used to good effect in flying / racing games.

Had to look up SNES mode 7, too.

Say... since we might have a lot more colors than with the original VIC-II,
would it be possible to make sprites etc. look a little bit nicer by creatively
adding "a little bit of noise" to one of the color channels or such ?

https://en.wikipedia.org/wiki/Procedural_texture

We had something about generating pseudo_random noise here.

Since sprites were mentioned, I now remembered to have toyed with the Trinamic TMC453
stepper motor controller controller some time ago, the interesting part is on page 20 of the data sheet.

The (now obsolete) TMC453 was able to run nonlinear ramps.
In theory, in might be possible to use that sort of algorithm for generating the X and Y coordinates of a sprite.
So you could have something like a ball bouncing around in the picture, moved by hardware.

But the interesting question then would be: how to make creative use of collision detection (and maybe Attribute Bits)
for having something like Pong or Breakout.

I'm thinking of applying HQ2X to the output, that would make everything 'look a little bit nicer' in some ways.
Procedural texturing in general is interesting, though is probably a stretch for anyone thinking about a TTL design.
Pseudo random noise should be possible with a suitably large LFSR generated bit stream.
Stepper ramping has to account for a moving mass so probably has some similarity to gravity calculations, though it probably easier to start off
by looking at actual gravity calculations. I'll think a bit more about collision, though seeing if more than one object is active for a single pixel might be a good place to start.

Augh! Nooooooo!

All of those pixel upscaling techniques destroy the very notion of what pixels represent in visuals. The same arrangement of pixels might represent completely different visual cues in different uses, based on conceptual context, yet all of those upscalers would assume only 1 way to insert additional information for some certain arrangement of input pixels (except maybe fullscreen non-convolutional neural nets, if such are in use). It's never a sensible transformation and use of such algos is an offense to all pixel art.

Noise, CRT emulators, even plain blur, all keep the notion of a pixel as a point sample intact. Even sharp nearest-neighbor scaling adds additional high-frequency visual information with those sharp edges that aren't present at their 1:1 sizes. You want to keep the space between input pixels as low-information as possible, because there's literally no visual information there on the input, and it is the conceptual & visual context that allows the mind to fill in from that very symbolic representation which the pixel artists have crafted. The computer can't fill in for that job.

</rant>

I'm sure HQ2X could generate a heated debate with valid points from both sides of the for/against argument. I'm not choosing a side, though think it's an interesting thing to include as a hardware option.
It hasn't progressed further than being a thought in the back of my mind, but if implemented, would be selectable with the modes on/off/OFF, with OFF requiring a reboot to clear. The default would be 'off'.

I added a noise generator (large LFSR) just after my last post, though have only directed it at the border colour as a test. I looks just like an untuned analog colour TV, so I guess that works fine as a noise source.

I'll do more on the video side of things soon, but have branched it off to a second design project so I can play about with interfacing a 6502 core to it. I'll start a thread about it once it takes on a little more form,
currently I can PEEK/POKE display RAM and attribute RAM with a 6502 core running BASIC (at 33MHz), but I haven't implemented any chip registers yet.

Cray Ze, thanks for still working on that VHDL implementation.

;---

Spent some more thoughts on moving sprites by hardware, and I now started to think that trying to integrate
something like this into the VIC-II won't be a good idea, also it would bloat the design too much.

When tinkering a bit with the TMC453 algorithm one might be able to add gravity effects etc.,
but when considering things like pinball, I'm not sure about the "flexibility" of that algorithm...

Also, with some software tricks it might be possible to display more than 8 sprites on the screen,
what means there could be more than 8 moving objects.

I'd say, for a C64 the worst case scenario would be if Pinball Dreams and Asteroids
would be having an "illegitime spawn" named Breakout 3D... with a little tad of Gyruss.

But to be serious:
I think that adding more computing power to the system makes more sense than adding a "minimalist physics engine" to the VIC-II.

...maybe a TTL implementation of a 16 Bit fixed point DSP like the TI TMS320C10.
An assembler that supports the TMS320C10 (and the 6502\65816) would be the AS.

Side effect is, that a DSP also might be good for other things, but an unmodified TMS320C10 core won't be too useful
for speeding up those slow floating point routines in the C64.

Hmm... I just wonder, if the designers at Microchip who did the PIC33F DSP core knew that Microchip had been a second source for the TMS320C10 long time ago.
(Don't remember exactly, if it was the TMS32010 or the TMS320C10.)

I had something in mind that's probably simpler than even the TMC453, consisting primarily of counters.
Position updates occur only once per frame so there're plenty of cycles for some counter based math.Pinroids Byruss, sounds like fun! One thing I've never looked to deeply into is DSP's, though a floating point accelerator would be nice,
and I suspect both ideas would take a 'beyond reasonable' amount of TTL logic.

Edit: Noticed 'AS' also supports the MELPS-7700, that will come in handy at a later point. I've got a few of these chips so will likely wire one up to this display system at a later point for a bit of extra fun.

8 Sprites, X\Y... that's going to be a lot of counters !

In TTL terms, I think it would take less chips to implement a minimalistic TTL CPU,
with an instruction set that only does DEC, CMP, and conditional\unconditional jump.
No subroutines, no indirect addressing mode, etc.
Hmm... when remembering Galaga:
Try to add one or two winged things that aimlessly are flapping around on the playing field...
and when the ball is getting too close to one of them, it just steals the ball for setting it on a random trajectory.
A complete floating point accelerator would be 'beyound reasonable' amount of TTL logic,
but I think that just having hardware support for multiplication, normalization (see PIC30F\33F DSP instruction set or 80C537 MDU)
and maybe rounding already might speed up floating point math on a C64... but we are getting off topic.

If generating a trajectory won't require the use of multiplication, I think the amount of TTL logic for a "custom DSP" won't be too big...
...the question is more like: would it make sense to add something to a C64 that isn't used\supported by the standard software
and that only 0.001% of the end users might be going to need.
I now remembered to have used the AS for generating the microcode of my first TTL CPU...

I'm not sure you'd need to extend the functionality to more than a few sprites (multi-ball in ball games). Lunar lander type games would need only one.
At some number though, a minimalistic TTL CPU would probably take less chips.
If just controlling X and Y acceleration (think lunar lander again), there would be no multiplier required. For setting a defined trajectory (think artillery) though,
there would be some math, but infrequent enough to do on the host CPU.

Another crazy idea is something along the lines of "HP Color Recovery Technology" to extend the colour range provided by 8 bits of colour data. In it's default form it
would be too large for TTL but it may be possible to reduce the output colour range and the resolution.

1st link is just the section on "HP Color Recovery Technology" taken from the HP journal linked second. Some additional minor mentions in unrelated sections of the full journal.
ftp://ftp.mrynet.com/operatingsystems/D ... pr95a6.pdf

HEWLETT-PACKARD JOURNAL April 1995 - FULL
http://www.hpl.hp.com/hpjournal/pdfs/Is ... 995-04.pdf

Hmm... when spending some more thoughts on this:

One also could try to implement the VIC-II functionality with two _custom_ 16 Bit TTL CPU cores
running at twice the speed of the dot clock.

When considering all the ideas that showed up in the thread,
one could try to cobble together some more 16 Bit TTL CPU cores...

Probably the best would be to go for a pyramid like structure of TTL CPUs working as "GPUs",
where the base of the pyramid connects to the bus, and the top of the pyramid emits the pixels
at dot clock rate...

...But I think it would mutate into something that resembles a Goa'uld mothership rather quickly.

Indeed.

...The Ha'tak-VIC.

Ok, we had our fun, now back to the humdrum work routine.

;---

Somewhere up in this thread we had a concept where two separate 64kB blocks of RAM main memory
are tied to the VIC-II, each block has its own address and data bus.

We already had discussed what options this might give us for the text\graphics screen, now for the sprites.

When having twice the bus bandwidth as usual, there would be some interesting options: ;---

Now for the encoding of sprites in 4 Bit MultiMultiColor, supposing that we have a palette of 256 colors.

MultiColor from the original VIC-II gives us 2 Bits for 2 pixels, that's 4 different options of how two pixels are displayed on the screen.
Transparent, color from Reg. 37, color from Reg. 38, or a color from one individual sprite color register (Reg. 39..46).

MultiMultiColor means 4 Bits for 2 Pixels, that's 16 different options of how two pixels are displayed on the screen.
Transparent, of course.
Maybe some more registers than Reg. 37 and Reg. 38 for all of the sprites.
Maybe more than one individual color register (like Reg. 39..46) per sprite.
Of course, this means having a lot more color register in the VIC-II than usual.

;---

A different (but "conceptually less clean") approach for going without additional sprite color registers
when we happen to have a configurable color palette would be selecting the palette color directly
from the 4 Bits like this:

cccc
0000 transparent (no sprite color at all)
0001 Reg. 37
0010 Reg. 39..46 // depending on which of the sprites
0011 Reg. 38
0100 color 1sss0100 // where 'sss' is the number of the sprite
0101 color 1sss0101
0110 color 1sss0110
0111 color 1sss0111
1000 color 1sss1000
1001 color 1sss1001
1010 color 1sss1010
1011 color 1sss1011
1100 color 1sss1100
1101 color 1sss1101
1110 color 1sss1110
1111 color 1sss1111

Downside is, that depending on how the color palette is implemented,
writing the palette registers when the CRT is outside horizontal\vertical blanking
might generate glitches on the screen.

Because of this the CPU probably can't write\modify many of those palette registers
per raster line, so I'm not sure if decoding the 4 Bits like this would be a good idea.

I haven't read all of the thread so it might have already been discussed, but once you start expanding things there's no reason to keep limiting sprites to 21 pixels tall. All that ever did was roughly keep pixel data around 64 bytes long.