Commodore 64 and Amiga 500 video hardware characteristics?

The NES vs Commodore 64 discussion a while back made me wonder what exactly the Commodore 64's video hardware is. Unlike for other 2D based systems, Wikipedia doesn't do too great a job of explaining it. My initial question because it left me a bit confused: are the colors used by each tile actually unique (they don't just reference a palette)? Also, about tiles either being double width 4bpp or 2bpp, what basis can you change this on, or can each tile decide? It says sprites are 24x21 pixels tall, which seems a little odd... It doesn't say how the colors are defined for these either, unless every sprite can freely choose.

One last thing: does graphics data reside in main ram or somewhere else? Regardless of the fact that this will eat all of your already limited ram, with the tilemap, is it at all possible to change vertical scroll and have 8 tilemaps in a row for 8x1 pixel attributes like you theoretically can with the SNES? I can see this having a dramatic impact on graphics; you could just about seamlessly go between 4bpp and 2bpp modes.

And I figured that while I'm at it, I might as well ask about the Amiga 500 because Wikipedia is even worse here... I've heard the Amiga has either one 6bpp layer or two 3bpp layers, but other than that there's somehow no penalty for having to access more tilemap data (like on the SNES where every new layer consumes an additional 2bpp beyond the color depth) there's this:


It's still only 6bits of color depth between all the layers (I was really surprised to find out that the rear most layer is only 1bpp...) but yeah.

The Amiga also can't get away with defining what colors to use for every tile like the Commodore 64, but I can't find anything on color other than that the Amiga has a 12bpp master palette.

Both of those machines are framebuffer based, without any tiles and whatnot (except C64 in its character modes). Framebuffer sits in main memory that is shared by CPU, and accessible as normal RAM to the CPU.

Oh, really now? I'm actually surprised to find out that the 68000 in the Amiga 500 only ran at 7.16MHz; flight simulators and whatnot are much smoother on it than the Genesis could hope, unless the advantage of being framebuffer based is actually that large.

There is still a graphics chip drawing things onto the buffer. Aparantly it has several layers of buffering too. I'm not sure if it's a scrollable buffer or not.

I'd imagine; it seems like a huge waste of processing power to completely rerender everything just shifted a few pixels every frame.

Try the wikipedia page on the VIC-2 instead of the page on the C64...

The VIC-2, like the SMS's VDP, loads and caches tilemap data every 8 scanlines. (During this time the VIC-2 stalls the CPU—the C64 demoscene calls these "badlines"). But it can be tricked into fetching tile data every scanline.

—

Similarly for the Amiga 500, try reading up the capabilities of its Original Chip Set. The OCS has a coprocessor ("copper") that is basically the same as the SNES's HDMA unit.

Oh, yeah, that helped... Even better I found is this: https://www.c64-wiki.com/wiki/Character ... _character I had no idea the C64 was like the SNES in that it had a hundred which graphics configurations to make up for its relatively slow video bandwidth.

It appears that you can have both high color and low color tiles on the same screen together, but that you sacrifice some of the colors you can choose from.


That's what I'd have thought; like I had suggested, you could also have a smaller attribute space vertically on the SNES if you were to use HDMA to scroll down every couple of lines and upon reaching the end of the tilemap, changed the VRAM tilemap location register. 2bpp BG3 might not stick out like a sore thumb then.

Not really? The C64 only has (edit) one fetch pattern; its different modes are more like the CGA than the SNES. Every 8x8 HiRes pixel zone has its own unique 12-bit attribute, and the mode just changes how those 12 bits are interpreted.

Unlike the VIC-20's VIC-1, where the tilemap actually addresses three 4-bit wide RAMs and the portion of address space corresponding to the attribute data is open bus for the upper 4 bits, the C64 uses 64K x 8 of DRAM, so it's vaguely a shame that the attribute data isn't 8 bits wide. It'd've been nice to have more variable colors per tile.

Oh; the C64 wiki had me believe otherwise. Yeah, the fact you only get 2 colors at normal resolution is a real shame. I think games could have looked a lot better if they were smarter about when to use 2bpp vs 4bpp graphics. It looks like many games only ever even stuck to one mode. :/

Er. There's no 4bpp mode. (There's 16 color modes, but they're still 2bpp)

Also, I'm at least somewhat wrong about different VIC-2 modes https://www.c64-wiki.com/wiki/Graphics_Modes

But they don't differ as much as the different SNES modes; they're about how the 12-bit tilemap entry is interpreted rather than changing fetch cadence:

edit#large: reformatting into a table:
Each tilemap entry is interpreted as:

Yup, sounds as confusing as the SNES to me!

The thing to note is with architectures like the C64 and chipmem only Amiga, video bandwidth is ultimately constrained by how much CPU bandwidth you are willing to steal. Of course, the large advantage of such a design is the ability to randomly access the memory the video hardware is currently addressing.

Actually, C64's main RAM bandwidth is insufficient to feed the VIC-II. That's why the C64 has a separate 1024 x 4 SRAM for use as colour attribute memory. It is accessed in parallel to the character pointer data during the badlines.

If you want a fully comprehensive run down on the VIC-II then you can't do much better than look at this document.

All 12 bits are used. In fact, you could say there are 16 bits. 12 bits for three colours come from the tilemap and colourRAM respectively while the fourth colour is defined by the 4 bit background colour register.

While being a framebuffer architecture helps the Amiga a bit, what helps is that the Amiga has a hardware blitter it can use for filling polygons, amongst other things.

That makes more sense... it's also not what the c64 wiki says here

I hear Amiga can be 5bpp (32 colors) through use of Extra Halfbrite Mode.

6bpp. There's a 32-entry palette, and the sixth bitplane can generate 64 colors with extra half-bright mode.

That's also how HAM mode generates 4096-color images: two bitplanes specify what is done with the contents of the bottom four bitplanes. (Set R/G/B or reload all three components from the palette)

Okay...

C64
320x200 bitmap with 2 colours from the 16 per 8x8 block.
160x200 bitmap with 3 colours from the 16 per 8x8 block + 1 global background per screen.
320x200 char map with 1 colour from the 16 per 8x8 block + 1 global background per screen.
160x200 char map with 1 colour from the lower 8 colours per 8x8 block + 3 global background colours per screen. You can intermix 320x200 1 colour from the lower 8 per 8x8 block + 1 global background per screen.
320x200 char map with 1 colour from the 16 per 8x8 block with 4 background colours to choose from but only 1 per 8x8 block. This comes at the cost of only having 1/4 the amount of chars to select from.

Sprites
8 per raster line
24x21, 1 colour + transparency
12x21 1 colour + 2 colours shared with all 8 sprites + transparency
each sprite can be expanded 2x in the X and/or Y giving you twice the size but same pixel count

Enhanced modes
FLI - this forms a bad line every line so you loose the first 3 char rows to single colour grey, but you get 1 colour per 8x1 and then 3 colours per line at 160x400 interlaced
See also NUFLI, MUFLI XFLI etc for fixes and other compromises
Borders can be opened, allowing sprites to appear in the borders, there is also a single control byte for what is drawn in the border area.
Sprite stretching is also possible allowing you to duplicate Y rows as much as you like

Priority
A Sprite can appear behind char data or in front of char data. In Multi colour mode it can appear in front of background colour + mCol1 but behind Char colour + mCol0 allowing you to put the sprite behind somethings and in front of other things.

Amiga 500 ECS
320x200,320x400,640x200,640x400 2,4,8,16,32,HalfBirght(~64),HAM(~4096) colours
640x480 progressive, 1280x200/256 (NTSC/PAL) 2,4 colours
You can also enable Overscan to paint over the "border" for more pixels
Dual playfields lets you have a 8colour + 7 colour and Transparent screen giving you 2 "planes"
Sprites 16xasTallAsYouLike 3 colours + transparent, you can bolt 2 sprites together to make a 14 colour sprite. There is 8 per line however you can plex sprites on the same scan line to overcome the limit. Sprites are always "lores" so the use pixels as if they are in 320x200
Sprites can be behind the bitmap, above all bitmap or between the playfields in Dual Plane Mode
Blitter this is a fully programmable blitter than also has built in line drawing and polyfill instructions, this allows you to and,or,eor upto 3 planes to a single target plane
Copper this is basically HDMA, its a custom programmable chip that lets you modify any video register whenever you like, however unlike HDMA it is not limited to HBlank and can run anywhere in the frame
The Amiga has hardware windows, (7 or 8 I think ) that allow you to render different parts of the screen in different resolutions and with unique pallets, not used often in games but if you are making a strategy game it can be handy.

Thank you for finally compiling this! If you're actually programming for the C64, you should have an explanation for how these limitations exist due to memory, but they should really still have an easy to understand overview...

Character based modes are a lot worse than I would have thought... I don't really know all of the full ramifications of using either bitmap mode but, uhh, it clearly leads to better results: ("Another World" (not the one you're thinking of) on C64) https://youtu.be/fcNxoXwnFWY

One thing I guess you forgot to mention about the Amiga 500, is how much sprite color memory is there? Do you typically have Copper multiplex the sprites, because the majority of Amiga games definitely don't have that 8/4 sprite per line limitation.

So the Commodore 64 has a 2Mhz bus, the VIC chip gets 1 half cycle the CPU gets the other. Its a shared RAM system. The VIC is limited to see 16K at a time. the VIC has a private 4bit bus to CRAM which is made up of Nybbles.

For each char the VIC needs, CRAM data, Char number and then 8 char bytes to draw it. So to get all the data it needs 4bits of CRAM, 8bits of Char num and then 8bits of Each char for that line it is to draw

c Access to video matrix and Color RAM (c-access)
g Access to character generator or bitmap (g-access)
0-7 Reading the sprite data pointer for sprite 0-7 (p-access)
s Reading the sprite data (s-access)
r DRAM refresh
i Idle access

x Read or write access of the processor
X Processor may do write accesses, stops on first read (BA is low and so is RDY)
This is a DMA steal case. There are 40chars per Row, and they take 40 clocks to draw. The VIC and CPU are in perfect sync.

Sprites need 1 fetch for their PTR ( like tile in NES) and then 3 bytes to fetch a row 24bits. this is done in the borders of which the borders are wide enough to fetch 8 sprites worth. Again it does a DMA steal so it grab 4 bytes is "2 cycles"
The reason why the resolution drops to 160 vs 320 is it would have to halt the CPU for the entire screen in order to get double the data down the bus.
A Screen uses 1000 bytes for the screen map, colour is stored in CRAM which is seperate from the 64K, and the char set is 256*8 = 2K of data. So a Screen with chars take 3K a bitmap is 1000x8.
Hires uses the Screen map to hold 2 nybbles for the 2 colours, aaaabbbb this lets it fetch 2 colours per 1 byte.
Multicolour uses the Screen map to hold both multicolours and then CRAM to hold the extra colour. Again this does not change the bandwitdh needed.
EEBM is a hires char mode, so uses 1000 for the screen map, 64x8 for the chars. So it uses the chars in the screen as
XXaaaaaa XX = background colour 0-2 and then aaaaaa = char what they should have done is still keep all 256 just have it so each "bank of 64" could have a different colour.
Every single step, trick, feature, access, memory access of the VIC-II is documented here in extreme detail http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
But basically the vic gets 1 byte per character per line normally, and 4 bytes of data per sprite per line. This is 7 out of 8 lines, on the other line it DMA steals and gets 2bytes + 4bits of private bus per character. You can sacrifice CPU and force the VIC to "bad line" every line and hence it gets all new data per line for more colours. Or you can stop it from doing "bad lines" and shift the screen down ( see FLD) or even stop it for ever and hold a image in just its internal buffers and trash RAM for the extreme demo trick )

Amiga 500
Most games don't use sprites, they suck. Or you use them for hud, cursors, background layers etc to which you Plex them in the same row using the copper.
The "sprites" you see are BOBs Blitter OBjects, you use the blitter chip to shift and move around bits of bitmap really fast and build the games image that way. hence Shadow of the beast has really big things as its not bound by sprite limits but a fill limit which it can work around by offseting the planes start to make a "cylinder scroller"( I think this was Shadows big trick, it was the first to do it ) and things like that. It eats RAM, can eat DMA but gives total freedom.

Hmm... The only thing is, wont sprites then have to share the BG colors? That's fine for 6bpp, but not really for 3bpp...

It sounds like you'd have to go to town with the Amiga's windows if you want a reasonably colorful image in dual playfield mode.

Yes, they must share the palette, I think even the sprites have some palette overlap, not really done that much hardcore A500 stuff.

Dual Platfields can usually end up as 1 = background, 2 = "sprites"

Hmm... I'm assuming performance will be shit if you just try and render two layers and objects to one 6bpp bitmap...

you have ~1 million bits per second, so it depends on how you want to use them.

Not necessarly. The C64 can also work with a tilemap-like scheme, and that's what the vast majority of games uses I think, if you want to scroll you have pretty much no choice.

The confusing thing with C64 is that when switching to 2BP mode (either BG or sprites) they use two bits for the colours of two consecutive pixels, effectively halfing the horizontal resolution, but in the official documentation they call the two consecutive pixels "a pixel", even though this is wrong. There's no 160x200 mode, it's just 320x200 with every BG pixel being duplicated. The proof that the resolution is still high internally is that you can fine-position sprites.

The C64 wiki is wrong. Here's a quote from the C64 Programmer's Reference Guide:

I fixed the wiki entry.

the image resolution is 160x200 its displayed on a 404x312 screen, but the image it self is only 160 pixels wide. You can't have a half pixel, you can scroll it to the left by 1 pixel, but there is still only 160 addressable pixels.

A sprite is only 12 pixels wide, you can't set a half pixel, you can place it anywhere on the 404x312 resolution of the VIC-II with a single pixel resolution, however the sprite it self only has 12 individual pixels.

Which leads to a philosophical question: Are the sub-screen columns in Super NES pseudo-hires "pixels" or "half pixels"?

Most graphically impressive Amiga games (ab)use sprites in several clever ways. I urge you to check out the analyses Codetapper has made here:

http://codetapper.com/amiga/sprite-tricks/

So, 320 * 200 = 64,000 pixels,
1,000,000 / 60 frames / 6 bpp = 2,778. Ouch...


Could one make more elaborate backgrounds by changing sprite attributes while plexing them, or is this not possible?

I think Brian The Lion was dynamically replacing 1 bitplane of the cloud sprite, as the beam traced horizontally. Limited things can be done, though not in many bitplanes.

There's no such thing as "half pixel", but there's such a thing as "double pixels", which are unfortunately confusingly refered to as "pixels" in most documentations. As far as I know, both sprite positioning and scrolling is always done in native pixels increments, half the width of "double pixels" which are used when multicolour is enabled for either a sprite or background tile.


I might be wrong, but the Super NES in both pseudo-hires and real hires still uses "whole" pixels of sprite positioning and scrolling, so it make sense to call them "half pixels".

If you want some reliable technical infos on amiga hardware you have this :
http://amigadev.elowar.com/read/ADCD_2. ... e0000.html

Or this :
http://codetapper.com/amiga/sprite-tricks/

It explain how sprites trick are done on amiga in some games .

Actually, that one website TOUKO just linked said it could transfer 4MB in one second, so 32x as much data, which is a world of difference...

4 * 8 * 1024 * 1024 / 60 = 559,240 bits per frame,
6 * 320 * 200 = 384,000 bits per screen,
559,240 / 384,000 = about 1.46 screens per frame.

Of course, this isn't including any sort of overhead for setting everything up. Does the Amiga have some sort of display list for Copper, or what?

Yup. Read some random subset of the articles that ccovell linked to ("sprite tricks") for examples.

Looking more into it, the Amiga only has 32 colors (the sixth bit only halves the brightness) that the "sprites" must share as well. That's not exactly stellar, even for something released in 1987...

Yeah, but the Copper unit lets you change colors awfully fast. I don't know if it's enough to completely replace the entire palette on every scanline, but I think I remember descriptions of updating at least 16 of them per scanline for HAM mode.

Also note that if you want parallax, you have a layer of sprites and a you can staple the 6 bitplanes together in any combination (I think?) and you'll quickly run out of bits to index through the palette anyway.

The Amiga just looks like a real bitch to work with; The blitter seems really cool, (I'm not aware of other computers from the time having such a thing) but I'm still asking wtf at its "sprite capabilities". Was their intended purpose to be multiplexed to form backgrounds, or what? It's not like they could have been free to implement.


I guess you could do this during HBlank, and use Copper to multiplex the sprites during active rendering. Is the pointer for sprite graphics data fixed, or can it be moved? I don't know the feasibility of making a non-repeating background.

I have a feeling that Amiga sprites were intended to represent GUI elements in Intuition, such as the mouse pointer, the text insertion point, and an icon being dragged from one Workbench window to another.

There's only 8 sprites × 16 pixels × 2bpp per sprite of data. This would look like a limitation of 128 pixels (40%) of overdraw of 3-color sprites, or 64 pixels (20%) of overdraw of 15-color sprites, except that the Copper can be configured to program new X coordinates mid-scanline.

You do run out of bandwidth at some point. Presumably it lies somewhere between "updating 4 words containing X coordinates multiple times per scanline" and "updating 4 words of X coordinates and another sixteen words containing pixel data".

Sprites are arbitrarily high because they have associated DMA hardware (pedantically not part of Copper) that will update the sprite blitters with new data every scanline.

"The Amiga" = 1985 release.

That was a lot more colours (at an acceptable resolution) than any home computer until the VGA adaptor came to PCs in 1987.

Early computers went preferentially for more pixels over more colors. The modern retreaux "lots of colors but super chunky pixels" is almost entirely without historical precedent.

Yes it has a larger bandwidth if you are willing to saturate the entire bus for it. Remember the CPU needs the bus as well and if Paula is playing music it needs the BUS as well, so you don't get all of the max stats on everything you have to comprise as you see fit.
Also you can't just copy a sprite over the bitmap, you have to AND OR mask it. AND to make a hole in the background, then OR in your sprite. To remove the sprite you have to copy in the "background" again over it. Yes software sprites suck
So by the time you do FETCH AND OR STORE that is 4 bits per 1bit on screen ~4,000,0000 -> ~1,000,000 sure with the background you can just Blit so its swings and roundabouts. However you are free to use it as you wish and as it suits your needs.

Yeah the A500 is the Cost reduced A1000 of 85, and for 85 it is a total power house. The Amiga 500 can rival a 486DX4 100 in terms of productivity, its Multitasking capabilities and multimedia capabilities leave the others in the dust. At the same time the A1000 could emulate the Mac faster than the Mac could run it self. Only the Amiga multi-tasked and was in colour. You also have to look at the price in 87 an A500 was less than double a VGA card (The A500 was $700 while a VGA card was only $450, but you needed a $2000 machine to put it in )

Yup the PS2 is the NEW Amiga in terms of being a total pain. To get the best performance out of an A500 takes care and optimisation but when you get the bus signing and the bits flying she punches way above her weight. Sure the PC VGA has 256 colours, but with a screen you can use differing ( I've turned 4 greens into "can't believe its not a 16bit gradient on mine" ) to boost the shades, and then you have music and not a beep.

The Amiga has a fascinating development history but I will try to summerise it.
Jeff Minter gets annoyed with Atari ( he designed the 8bit series and the POKEY ) leaves Atari with some engineers and promises to make a new console for them.
They then set up and start making the Lorraine. While Atari wants a video game console, they really want to make a multitasking computer so start making a console with a multitasking OS and disk drive support.
Atari starts to fall badly, and starts to want out of its deal
Commodore steps in and promises to fund and take the "computer" and leave Atari with the console tech.
Jack Trimeil is fired from Commodore, Takes over Atari and does everything he can do to get the Lorraine tech back from Commodore. Commodore decided they want the lot, massive fight. Commodore wins.
Commodore gets them to push on and make it a full fledged computer. But then had budget issues and wants them to cut the amount of RAM. The A1000 only has 256K it needs 512K
Commodore limps on in 85/6/7 the C64 and C128 are keeping them strong, but the C64 is really starting to show its age and the 128 falling behind in the business markets, while the Amiga is still pricey. They cut the A1000 down to make a new 128 and try to replace the C64 and 128 with it. The C64 still keeps kicking though, so basically the A500 becomes the new C128, by this point the A1000 has evolved into the 2000.

The Sprites in the Amiga are basically Atari sprites, the tech is identical to the A8 series.

If the A500 is too limiting for you there is the A1200 with AGA which boosts everything. More planes more colours more blitter more RAM, more bits in the audio samples, more Mhz, more instructions etc etc (although maybe not the sprites... )

Yeah, I had that feeling too.


Can it also program new graphics pointer data for sprites mid-scanline?


Oh, yeah, that's quite a bit more impressive actually. Still a shame they cheaped out on the color ram; a sixth bit that leads to nothing couldn't have been the original intent...


Yeah, if I'm not mistaken, the resolution can actually go beyond 640x480, even though you'd be dealing with like, 1bpp.


Okay, do the 4MB isn't really a real-world number...


To rephrase that, you have to redraw the background over sprites, OR the sprite shape over it, then AND the sprite on top of it.

Die space gets to be an issue, RAM eats space


ECS can do 1280x200/256 at 2bpp. OCS can't. So A500+ can,although most A500s I have seen can also. A1000 can't(mostly) and A500 officially cant but its an easy upgrade.


Draw Background over sprites, AND the sprite shape over it, then OR the sprite on top of it. However the AND OR operation is done by the blitter in "one step", so the Blitter will read Buffer AND mask OR Src write Buffer on a word at a time it has a built in barrel shifter so you don't have to pixel shift the data in RAM. Rather than get it to do all the ANDs, then all the ORs.

Because they were primarily used to manipulate text and possibly line art as opposed to photos. That's also why many computers starting in the mid-1980s abandoned composite output (and hence the living room video game use case) in favor of faster-scanning, incompatible progressive output at medium resolution (342p-384p, Mac and EGA), enhanced definition (480p-600p, VGA/SVGA), or higher (720p-768p, XGA). This would separate the "open platform" and "couch gaming" worlds for about two decades until 2007, when TVs caught up to HD input.


That depends on what you define as "super chunky". A bunch of old systems had 160-pixel-wide modes, such as CGA (160x100), EGA (160x116), PCjr (160x200), Game Boy, and Game Gear.

To what end? The sprite data-to-blitter DMA is fixed and only happens once per scanline.

Even if it weren't, the only advantage would be spending one fewer "odd" cycle clocks on DMA (Copper, and that by only updating 16 bits of the address) to spend two more "even" cycle on DMA (Sprite DMA).

2600: ROM space was too much of a premium.
CGA: The 160x100 mode was extremely rare due to lack of BIOS support and still only supported 16 fixed colors
EGA: I've never actually seen any software divy up the RGB components into subpixels on the EGA to generate a 64 color mode. Even then, the 64 color master palette is limiting. (I have seen this trick used with the VGA 320x480 tweak mode to generate a 320x160x18bpp mode ... but 18bpp is a LOT more than 6bpp)
PCjr: 16 fixed colors
Game Boy Color; Game Gear: handheld. Still not MCGA levels of "lots of colors".

I'm basically ranting about the art direction of "Sword and Sworcery", but I've seen the same aesthetic used elsewhere too.

Screenshot please. The screenshots I've seen on Google Images look roughly MCGA/VGA mode 13h (320x200 pixels, 256 colors) in their aesthetic. That's roughly as "chunky" as Super NES.

1- Hardware sprites on real hardware are wasted by single-pixel-wide lines (Obvious exception: Atari 2600 "ball" and "missile" sprites). At the low contrasts as used in this game, single-pixel-wide lines are hard to see over composite video.
2- The game varies its zoom; the introduction starts at a 10x nearest-neighbor zoom (192x108); the first moment of game play is instead a 8x nearest-neighbor zoom (240x135). The former is comparable to the resolution of the Intellivision, but the Intellivision only had a 15 color master palette, and extremely limited color coincidence. The latter is comparable to the NDS, but the field-of-view of the NDS's screen under typical play is maybe 1/4 of a TV or PC monitor. (Human vision cares about pixels per minute-of-arc, not pixels per inch)
3- It's not even maintaining a strict pixel grid, it's just using huge chunky pixels.

It feels to me like trying use the "retreaux" aesthetic to achieve "abstract" but for me it falls flat, feels terribly lazy and cheapens the rest of the game. (CD quality sound but huge high color chunky pixels? FFFFFF)

Regardless, this is extremely off-topic, so I'm not going to talk about this on this thread anymore.

I think there may be some sort of communication error (probably on my part); you see how the background in games like the Amiga port of R-Type II is highly repetitive because the only thing that is being changed about the sprites is their position. I was wondering if you would be able to change their x coordinate in conjunction to their graphics pointer to eliminate this limitation.


Oh, I had looked up "Swords and Sorcery" instead of "Sword and Sworcery" and was wondering what you were going on about.



Yeah, It looks cheap af to me as well. It feels to me like great looking 2D games are largely a thing of the past.




...And about the Amiga, I'm surprised the R-Type II port even looked as good as it did, especially considering it only uses a 4bpp bitmap and 2bpp sprites (even if it ran like shit):


Probably helps that the entire game is in shades of gray and brown...

(I didn't actually know anything particular about the OCS beyond the bitplane graphics, HAM6 mode, and EHB mode. Everything I've explained since is just coming from the reference the reference manual that TOUKO linked)

The graphics pointer is part of the Sprite DMA unit, not part of the sprite blitters.

Before the active field, the sprite DMA unit fetches new values to be loaded into SPRnCTL and SPRnPOS. Before each scanline starts, sprite DMA fetches two words into SPRnDATA and SPRnDATB.

Changing the pointer doesn't help (in the same way that changing the SNES's HDMA channels pointer during rendering doesn't help); sprite DMA still only runs once per scanline.

To repeat a sprite within a scanline, you use the Copper to update the X/Y location in the SPRnPOS register. To update the tile graphics you have to send extra data to the SPRnDATA and SPRnDATB registers.

And that's when you run out of bandwidth.

This gives lots of details, saying that you can get one Copper copy per 8 pixels when not colliding with other DMA, or one per 12 or 16 when colliding. Since each sprite can only cover 16 pixels, at least half of your available Copper bandwidth has to go to just uploading new values to SPRnPOS.

The spritetapper archive shows that Brian The Lion multiplexes sprite data as well as sprite X coordinate—but only 1bpp. There isn't enough time to do anything more.

Oh, yeah, I read every game that was mentioned but didn't quite understand that. That really blows. It looks like Agony could have just gotten away with it instead of having to re render the background, but I guess not because sprites are used for the owl and the rain.

Do you know of any Amiga games that actually render what could be considered an additional background layer using one bitmap (for a larger amount of colors), or is this just computationally impossible with reasonable performance (at least 25/30 fps)?

I mean, if you do the math, sprites take roughly as much DMA bandwidth (16 words) as each bitplane (20 words). They could have (probably) chosen to have a 7bpp mode instead of sprites ... but I think that's clearly not worth it.

I'm not certain what your question actually means.

HAM games
http://hol.abime.net/hol_search.php?N_r ... ckmatch=81
EHB games
http://hol.abime.net/hol_search.php?N_r ... ckmatch=80

I was just talking about how Brian the Lion made a non-repeating 1bpp layer using sprites, while Agony has a 1bpp layer as well but by manipulating the back layer in split playfield mode.


None of those games appear to have an extra layer, and most don't appear to scroll either.

You can have some impressive effects like this :
https://youtu.be/j5e78_9Eo2Y?t=55m32s

I have no idea wtf is going on there gameplay wise, but you could accomplish the same thing in the Genesis and SNES (before mode 7) by having prerendered shrunken strips (or at least I think that's how it's done) like in Puggsy or the Lawnmower Man on Genesis.

From a 2D standpoint, I'm not really sure there's much that the Amiga can do that the Genesis can't, or anything it can do that the SNES can't (other than run at 320 pixels wide) but I have to keep reminding myself that it was made in 1985...

Well I did suggest in a list of things >NES <SNES

but the issue with the MD and SNES is they are VBlanked limited, the Amiga has always on raw access to everywhere on the screen, you can also double/tripple buffer. So While the 3D in the Overdrive 2 demo for the MD was good for the MD, watch some A500 demos. The line drawing and poly-filling hardware allow it to do some unique stuff. A few games let you morph your character because its actually vector. Anything that likes bitmap is going to favor the Amiga anything that works best with tiles will favor the SNES/MD. But it has the CPU as the MD, just it doesn't have a cheap char mode. Amiga invented the FMV Also RAM, an A500 has at least 512K, 1MB is basically standard. 3MB is a rareish but not uncommon set up as well.
You can pull some fancy effects with bit-plane tricks, putting a shadow layer or colour inversion in the palette then move single bitp-lane (shadow vectors). I would like to do the Donkey Kong Country Returns pure black foreground with colour background level idea on an Amiga. 1 bit-plane for the black, make half the palette black job done Sprites for colour accents.

It would be interesting to see what an A500 could do with a tile based video chip on the expansion bus, it would technically have the same CPU as the MD, but if you can keep full access to the RAM then it would really open up the taps, if you can genlock it with the bitmap hardware like the Picasso and Video toaster boards did, really really powerful.

If you want better than MD and SNES then you need to go AGA so Amiga 1200 or 4000 or CD32

The frustrating thing about overdrive 2 demo is that it only worked because of VDP glitches.

The bitmap AND behavior was only a couple of the effects in the demo. Saying "only" is really exaggerating.

That's like saying every memorable C64 demo since 1987 "only" worked because of VIC-II glitches, which might be almost technically true, but it also discounts the massive amount of legwork and technical ingenuity it takes to turn a hardware glitch into something that's actually interesting to look at.

No really, nothing on snes or MD are close to this one,you have a 8 way multidirectional scrolling with 2 layers,and a realtime boss zooming with lighning effect .

I'am curious to see an effect like this :
https://youtu.be/D3COba64xL4?t=2m54s

or this:
https://youtu.be/D3COba64xL4?t=4m

On Md or snes

I guess that's true. It's just weird that for such an iconic system, there was still so many undocumented features that weren't discovered until 28 years later.

I hope somebody finds a secret register or something in the SNES.

There's the one that makes the SPC700 run slower and/or stop working, does that count?

Multidirectional scrolling is trivial on both SNES and MD. Two layers is trivial on both SNES and MD (indeed, scrolling both layers is trivial on both SNES and MD, and your example doesn't have that). The scaling boss is a bit large for 60 fps perhaps, but the required tileset for everything else is pretty tiny and doesn't change much, so double buffering the scaling boss should be feasible and result in a decent frame rate for the scaling/Z-axis motion (no reason why the X/Y motion shouldn't be 60 fps). The boss is horizontally symmetric and appears to be a bit chunky at the largest scales, which means you could probably use tile flipping and line scrolling to fit it comfortably into a two-frame update on NTSC. The use of line scroll (as well as the fact that the boss can take up basically the entire width of the screen, leaving nothing (on MD) or almost nothing (on SNES) for the HUD and squirrel) would require the boss to use a BG layer, which means the far background would have to be sprites (unless it's 2bpp, which is a great fit for Mode 1 BG3 on SNES), but that's okay because the required coverage is low, and at least on SNES the backdrop gradient is trivial with HDMA - MD would need to use a raster IRQ, but it's still feasible.

The "lighting effect" looks like simple palette animation. Trivial on both SNES and MD.

If my calculations are correct, a modified tepples method on SNES could manage a credible scaling frame rate on that boss without having to store the graphic at all scales. But I haven't gotten very far with this due to being busy with other stuff, so I don't have a solid grasp of the real-life speed attainable with this class of methods. And using such a method on a BG layer is more work than using it on sprites, since you have to render slivers in absolute position rather than just sliding sprites around. If either the HUD or the far background were 2bpp, and the boss were narrow enough to allow the player character to coexist without glitching, maybe using sprites for the boss would work - line scroll is fairly cheap with the tepples method, although it does have to be hard rendered and thus the DMA bandwidth requirement will increase for high zoom levels...

Alternately, you could do what Rendering Ranger did here, and just use sprites for the backgrounds and Mode 7 for the boss - this method (first used in Super Mario World) might not be quite feasible for the exact content shown in your example (there are nearly-full horizontal runs of tiles in the foreground layer), but the scene is at least almost sparse enough to work.


I'm not a 3D expert, but that doesn't look out of reach.


...yeah, that's trivial with Mode 7, and I bet Titan could figure out a way on the MD.


Ah, yes, the legendary $FEED...

I love how the music broke for that level during the longplay. It even does it on BSNES in occasion, which is really bizzare; it might just be a problem with the game itself, but I don't recall it ever happening playing it in real hardware with my SD2SNES.

I've tried Rendering Ranger on real hardware. I got a good playthrough, but when I had my brother play it the whole game glitched out when trying to start up Stage 5 - even the music froze. Kinda disappointing, because he thought it was a pretty neat game up until that point...

Aw man... He just missed one of the cleanest, non low-saturation BG3s in an SNES game.

I think it's a surprisingly solid game for something that's really only known because of its technical prowless and rarity. (Especially considering it was made by a European developer in the 90's. )

My main problem with the game is that huge ass, 7 hit lifebar... It's not even that it's too lenient either; on hard and the regular number of lives, I barely beat the game. The problem is that in many areas, it's impossible not to get hit; everything just kind of files accross the screen straight into you. It's a real shame that Stage 7, which is easily the most impressive looking in the game (especially with that phenomenal intro), is probably also the worst gameplay wise.

Of course, it's a simple palette change, but it's here (axelay did it too )

A 8 way scrolling on 2 layers with a near full screen zooming on snes ??,i think is barely doable,mode 7 is useless here and even with precalc,i think you do not have the DMA budget for that,or you must drastically reduce the fram rate .

the boss zoom in pugsy is way simplier than that.
https://youtu.be/jgQCVi6HE6Y?t=2m54s


i think the boss is a bg layer, the second BG layer is done by sprites multiplexing .
The zoom is probably done by changing the X/Y harware scrolling, the copper can do it easily,but not at a 1 pixel precision.


I think it's an awesome game from a technical point of view(manfred did wonder with the 65816), but an average game overall.
The musics except in the level 7 one are bad, and sfx are a bit boring .

Oh, really? I'm a bit partial to the metal tunes in this game.

Yeah it's a matter of taste ,this is why for me only the level 7 is good .

And? It's such a simple technique that it doesn't really alter the feasibility on SNES/MD. The giant scaling graphic is the only part that's remotely challenging.

You sounded like you were trying to portray this as something clearly beyond the capabilities of the SNES and MD. Is this not what you were trying to say?


Only for this exact scenario, and only because the foreground layer isn't quite sparse enough to avoid glitching when combined with the player, HUD, and far background if all of them have to be sprites.

...okay, I haven't actually verified that the boss will fit in 256 tiles with no horizontal flipping (this being Mode 7, you can vertically flip the whole picture in between scanlines, so it's possible you could save some tiles on vertically symmetric features). If not, there's a trick that allows a 128x256 4bpp Mode 7 graphic without any compression losses, or potentially even bigger and/or more colourful if the picture compresses well. I think you could get pretty close to what's seen in your example.

Did you watch the Rendering Ranger example? Multiple independently-scrolling backgrounds made of sprites, combined with a Mode 7 boss (complete with palette fade-in). Carefully designed to avoid sprite dropout. Granted the foreground layer is eliminated before the actual fight starts, but that's probably because the player in this case can put out some fairly massive firepower, and combined with the boss' firepower it would have guaranteed glitching. Your scenario seems to lack firepower entirely; it's just the squirrel and the machine.


This isn't a generic full-screen graphic being scaled. It's a horizontally symmetric, vertically chunky full-screen graphic. That makes a big difference. Besides, even if you did have to drastically reduce the frame rate of the scaling (as you might if you attempted it in software), that wouldn't have to affect the frame rate of the rest of the action.


Interesting. But I was speculating about how to do it on SNES.

With precomputed graphics it's not hard at all. Considering how chunky the boss graphic seems to be at high zoom, along with the fact that the right side is a mirror flip of the left, I figure it probably doesn't need to be more than about 7-8 KB or so if you use a BG layer for it and repeat lines with HDMA scroll changes. Considering not much else is happening, you could probably update the whole thing in two frames on NTSC, or one frame on PAL (which may actually be the more appropriate comparison). The backdrop is dead simple to do with sprites; it doesn't even move, and coverage is low, but if it's only 2bpp it can be BG3. The foreground stuff can be a normal BG layer, and the HUD can be sprites, or BG3 or a mixture of both if the far background is sprites. The only question is storage, and you can get very fine-grained scaling in a few hundred KB with no optimization or compression, if you're willing to burn that much ROM.

Using precomputed sprites might work too, and it would take far less ROM because a lot of the fine scaling could be accomplished by shifting sprites relative to one another. You'd have to be super careful with sprite priority, though, to avoid massive glitching when scaling vertically - this is one scenario where the SNES has a disadvantage vs. the MD despite its slightly higher overdraw ratio, because it's the frontmost sprites that drop out, so you'd have to dynamically fiddle with sprite priority to keep the player's sprite in front of the sprites behind it, but behind the sprites beside it. Naïvely, DMA bandwidth requirements would seem to be higher than with a BG layer because you can't stretch sprites vertically with HDMA, so the graphics for a given frame take more space, but in practice you'd have several frames to upload the required shrunken sprites because with this scheme you don't need to update the whole mess every frame. You might actually be able to get 60 fps scaling this way. The boss seems to be slightly wider than the screen at its widest point and closest zoom, but if you used window masking instead of opaque sprites to fill, say, the dark part of the jet intakes, you might be able to avoid glitching since there's almost nothing else onscreen.

With a software scaling method, you have compute time to worry about (because all that crazy maneuvering in the previous paragraph is free, right?), and the tradeoffs get more complicated. An efficient quasi-tepples method of the sort I've been considering would involve 16-bit tables, which might actually take up more space than the precomputed BG approach... 8-bit tables are way smaller but constrain the method to be somewhat slower.

Technically it is possible to change H-scroll values during a line, and it would probably work if you used DMA. However, there are at least two reasons why this is a bad idea, possibly three: 1) DMA stalls the CPU, which is very bad in the case of a full-screen effect, 2) DMA is two dots per byte, and the timing alignment inevitably results in a one-dot horizontal offset between scanlines, so it's actually impossible to change a register at the exact same point on all lines, and 3) there's significant lag in the PPU's uptake of scroll values, which may or may not cause unresolvable issues. (I'd mention the 1/1/1 DMA/HDMA clash bug, but if you can pull off a timing-critical raster effect like this you can probably avoid triggering that bug in the process - in fact you can probably just forget about HDMA entirely and use DMA to do the same thing.) So duplicating the effect as you suspect it was accomplished on the Amiga is probably not reasonable on SNES - but as I've suggested above, there are other ways that could produce good results.

The only part where I noticed there would be sprite dropout for certain if you were to use Mode7 is the scoreboard when over that weird grate thing above the starting platform. I don't think any SNES game ever went that hardcore with sprites to fake backgrounds for Mode 7 (well, Cameltry/On the Ball) but I don't see why it couldn't be done here.

Actually, you know what? You could even use Mode 7 for the entire boss other than the top narrow part that reaches the scoreboard, and have only that be prerendered. The scoreboard could then still be BG3 like it would make most sense to be (it's only 2bpp).
Edit: Wait, no, this wouldn't work, because the boss really isn't tied to the screen much at all; if you fall fast enough, the scoreboard goes through the entire thing. I didn't watch it that closely...

Interestingly, Super Turican 2 typically uses BG3 for the status bar, but will switch over to sprites for Mode 7 or if all backgrounds are needed durring those lines. This isn't even an SNES game, but I observed in MAME that Ninja Baseball Batman does the same thing during the second stage when the clouds, large blimp, and bridge use all 3 background layers, so I guess it wasn't too uncommon.

I agree,but it's not like for exemple with pugsy where the boss stage is a simple zoom with nothing .
If you take this little effect alone, of course it's nothing as i said axelay did it,but it adds to the scene complexity .


Of course i know ,and you have the same in Mr nutz snes:
https://youtu.be/YX_HlhrSdhc?t=47s


Yes, it's the common and simpliest way, but it relies on how many bytes you can transfert each frame(because this kind of animation cannot sit in VRAM alone).

Thanks for your explanation, it was interesting to read

I am not saying amiga is the best machine, it's a better machine in some cases, worse in others .
The bitplanes manipulations is a part of his strenght,same as doing effects mid line with the copper which can drive all the chipset without any CPU intervention, but like HDMA on snes, it needs a list done before with the CPU(it's called copper list) .
The copper is in perfect sync with the TV's electron beam .

Look at agony:
https://youtu.be/a839o59Bt4s?t=4m57s
The Md cannot do that (the snes however can),the same with jim power .

The amiga is a 85's technologie, so he is not as powerfull as MD/snes/PCE for sprites intensive games and sub palettes are limited to 2,however it can multiplex his sprites for composing an entire BG layer without any sprites overflow .
The drawback is, it has only 8 hard sprites,of 16 pixels wide but up to 512 pixels high,the sprites colors are limited to 4 (if i remember correctly), and can be 16 if 2 sprites are attached,a bit limiting no ?? .
You can have 2 BG layers, but the colors drop to 3 bits per layer rather than 4 for 1 layer,quite limiting .
Also you have a limited number of DMA cycles each frame, and like the chipmem is slow (it's a 3.5 mhz RAM) you cannot use the chipset at his full set,because if you're using a chip intenselly, this is why if you use a chip intensely, you will reduce the use of other chips.


No, and even not on any consoles of that era because of sprites bandwidth, only the NG did this .


Yes the snes has a 3rd BG layer, and even limited in bit per tile, it's quite usefull and for me way better than a BG done with sprites multiplexing.

The titan's guys have touched the amiga's coders's ego and have done a 8 layers checkerboard in OD2 (thanks to them)
The answer was this :
https://youtu.be/nWJW0O3p1-E?t=41s

up to 13 layers in 332x256 .

That doesn't have any of the features you were talking about. No scrolling, no palette animation/lighting... very convincing fake BG, but it doesn't go anywhere - it's basically just like Super Mario World. The boss isn't even that big. And didn't you say that nothing on SNES is like what you showed? I'm getting mixed messages here.


I agree, it's an impressive machine for its time. And since it works very differently from the SNES (as well as being far more expensive - $1295 for an Amiga 1000 in 1985, and $595 for an Amiga 500 in 1987), it's reasonable to expect that not everything it can do will end up translating perfectly.

But when someone shows me something like this and says it's impossible, something inside me refuses to accept the conclusion without trying to prove it wrong. One time somebody on a different forum posited a Moon-sized object on a 40-year collision course with Earth, the idea being that there would be nothing we could do about it - rather than accept his premise and go along with the line of discussion he wanted, I started speculating about thermonuclear pulse spacecraft and world economic output, whereupon he changed it to a black hole and three days, which I thought was rather rude...

i answered to espozo about the boss in RR² .


I agree, in france the amiga was good only when the 500 goes out and at more or less the same price than atari ST,but it was always way more expensive than a game console .


I agree even if i tend to also use this word a bit often,but unless somebody do a similar thing, you cannot say it's possible when a machine is not designed for,but the history show us that impossible is something a bit false,or not entirely true .
For exemple, i am sure the MD cannot do agony or jim power in the same way than amiga did ,the snes can because of his 3rd BG layer,but in certain cases, the contrary is also true .

Today I learned that a real copy of Rendering Ranger can go for over $3500. (I then searched ebay, and observed a stark contrast between SFC originals going for ~$2500-3500 with box and manual, or ~$700-900 loose, and obvious repros going for between $10 and $50.) This implies that that video may have been made from an emulator, repro, or flash cart.

I wonder if it's a bad dump? Might explain the bugginess...

...what a wonderful 100% off-topic post to begin a new page with...

I too noticed the same price difference that distinguishes repros from originals. When I got R-Type III a few years ago, it wasn't even an option; I guess some factory in China has been cranking them out as of recent. I'm actually fine with them, because they're priced so much lower that it's obvious it isn't an original cartridge and it still lets people play the game on original hardware if they don't want to buy a flash cart.

I hardly ever care about people going off topic; usually that's just the conversation progressing. I'm just severely disappointed in the Amiga's color capability for an otherwise capable machine. The whole game pretty much needs to use a universal palette, unless you want objects that use only 4 colors. Can the blitter add, or only do and/or instructions? this way, sprites with only unique colors could dynamically shift the colors they are using anywhere in the color ram.