Comment by quincunx | Hacker News Reader

Comment by quincunx | Hacker News Reader

Love this, love the write up.. but on the amiga...

the A500 had 6 bitplanes, not 5, also, with PAL being the most popular region, I'd say 320x256 was the more popular resolution over 320x200. 6 bitplanes are used for Hold and Modify (HAM mode, where 2 bits select Red, Green, Blue or Palette, and the remaining 4 bits indicate either R G or B values, or the index of the color.) The other 6 bitplane mode is "Halfbrite" which doubles the palette size for a total of 64 colors, where the second half 32 colors are half the intensity of the first half. When running with 6 bitplanes, agnus (the memory controller if you will) steals a lot of cycles for Denise (the display chip) from both the 68K and the blitter. The blitter being crucial for drawing filled polygons.

The second thing that made the Amiga revolutionary (and one could argue, for this reason, that the PCI architecture of Hombre/AAA is not a true Amiga no matter Commodore's demise) - the second thing is the way that Agnus orchestrates memory access much like the microcode inside a CPU orchestrates registers and ALUs. In particular, Agnus controls the memory address lines and chip-register-address lines; the chip-register-address and the memory address lines are opened up simultaneously against eachother with one reading and the other writing. So, for instance, when reading bitplans, agnus opens the chip bus using one of the register addresses 0x110-0x11A for BPL1DAT to BPL6DAT depending on which of the 6 bitplanes is being read; while at the same time driving the appropriate memory address by putting the contents of agnus registers 0x0E0-0x0F6 for BPL1PTL/H to BPL6PTL/H on the address bus of the "chip memory" DRAMs. The datalines of the DRAM and the special chips (Denise here) directly open on eachother (eg. DRAM and Paula chip-selected at the same time.)

I'm not sure if I did it justice and got the elegance of this architecture across in this short post. I'm sure many enthusiasts like me who got their start on the Amiga programming 68K continue to discover new things about this machine.

Good times, warm memories.

Thanks for the correction. I will update the drawings asap.

Since you seem to know the machine well, maybe you can shed some light on something i was unable to clarify: What is the fastest way to clear a framebuffer to a desired color on an Amiga. My hypethesis is that it was done with the Blitter, by disabling all DMA entries "doing something else". Do you have any idea?

To set the framebuffer to a single color, consider that there are actually up to 6 "framebuffers" (one for each bitplane.) Consequently, it is to either set all bits for a given bitplane to 1 or to set them all to 0. To control the actual word that is blitted without DMA, you would use BLTADAT, BLTBDAT or BLTCDAT registers to control the corresponding blitter input word with DMA disabled (so the blitter does not write into these registers itself.)

A common technique to avoid having to blit each bitplane independently (esp. for BOB sprites where the blits are small and plentiful) is to interleave the bitplanes by row using the BPL1MOD and BPL2MOD register values; these values are added to each bitplane pointer address at the end of each row to move the pointer to the start of the next row; consequently a single blit operation can capture all bitplanes as in memory a row can consist of all row bits belonging to bitplane 0, all row bits belonging to bitplane 1, all row bits belonging to bitplane 2 and so on.

If this is the bitplane layout used then a single blit can only set the values to 0 or 15 (all 0's or all 1's for 4 bitplanes enabled); note however that the blitter too has modulo registers (BLTA/B/CMOD for each input and BLTDMOD for the destination) so perhaps best examine how fancy the programmer got with it (eg. multiple blits to clear the screen to a specific color even if the bitplanes are interleaved using BLTDMOD.)

Obviously I'm a bit rusty given it's been a few years, but I hope this helps. I'm a fan of your work, thank you.

Thank you so much, I am going to amend the "fill" section. Are you ok with being credited as "quincunx" or you prefer something else?

That's very kind, quincunx is fine, or no credit is fine too. Glad I could be of help.

I had no idea about the BPL1MOD and BPL2MOD. Now that i know they exist I don't see why a game developer would not use them.

I will try to double check with Eric Chahi but this is so much more efficient that it has to be the way he drew polygons (instead of drawing into a scrap buffer and blitting four times, he used BPL*MOD to draw and blit only once).

Unless I'm wrong, a drawback of using interleaved bitplanes to do fewer but larger blits is that the mask for the sprite shape gets bigger too.

If you do several blits, one per bitplane, you get to use the same mask data, but when using interleaved data the mask needs the same shape data * number of bitplanes involved.

It's still a pretty small price to pay compared to Atari ST/ZX Spectrum preshifted bitmaps.

Does that mean you cannot use the Blitter to draw lines and fill area as described in the article?

You'd use a single multi-bitplane interleaved fill-blit if the background surrounding it did not need to be preserved (eg. no mask requirements as per Flow - demos tend to do this for its speed).

I'd imagine Another World creates an off-screen single-bit deep bitmap and uses that as a mask. I sent you an email if you'd like to explore more, however the original programmer probably just remembers what he actually did.

Also note that non-overlapping polygons can be grouped together in both approaches by line-blitting with XOR destination (adjacent polygons share an edge and so the edge is XOR blitted twice); so there are substantial speed-ups to be had.

Half-brite was not in the Amiga 1000 and early Amiga 500 and 2000. The later “ECS” chipset has included “halfbrite”. Most games did not take advantage.

Do you know of any games that used halfbrite? I can’t think of a single game that did.

I think there were like three games that used HAM mode, if you filter out “displaying a scan of the box art while the rest of the game loads”. Knights of the Crystallon, Pioneer Plague, and maybe Mindscape?

At least Pinball Dreams did and googling suggests Cannon Fodder. I suppose a few more must be in there.

Edit: https://retrocomputing.stackexchange.com/a/196/4616

Also The Settlers

Black Crypt - http://hol.abime.net/126 Links - http://hol.abime.net/892 Universe - https://en.wikipedia.org/wiki/Universe_%281994_video_game%29

Also interesting is the game 'Universe', which boasted achieving 256 colours on ECS (edit: a comment on the StackOverflow page linked below says it works on OCS as well). Some quick Googling before asking you guys about it as I was planning to turned up this:

https://retrocomputing.stackexchange.com/questions/44/how-to...

The Amiga was such an interesting machine. It's too bad I never got into assembly programming back then.

I know of one game that actually used HAM (specifically HAM6, the original OCS version) during gameplay and it seemed to run very fast as well - it was a PD game called Zdzisław Bohater Galaktyki 3D and it's, well, not very serious [0].

[0] https://www.youtube.com/watch?v=IV5UPk8ZQZw

It seems all sequences are prerendered, it’s all animation.

Yes indeed, but typically displaying a fullscreen HAM image takes up several seconds [0] of very visible scanline progress. This is pretty much instantaneous and runs on even the base 68000 models, as long as they fulfill the memory requirement (which is admittedly rather hefty - 2MB chip and 8MB fast).

[0] example: https://youtu.be/Y9qzUbT_5Dk?t=95 timestamp and later on as well

That’s just Deluxe Paint being slow. A HAM image is no slower than an EHB image, it’s the same amount of bytes.

Fusion was another one that used half brite

http://amiga.lychesis.net/knowledge/EHB.html

Lionheart? Very impressive pixel art, too.

Yeah, and pretty impressive performance wise as well.

Psygnosis' Shadow of the Beast used halfbrite, and was heavy on the copper effects too. Gameplay kinda sucked, but it was a hell of a demo against an ST or PC. When it was released no one had seen anything like it. :)

Edit: I suspected many Psygnosis titles used EHB, so I did a quick search, and discovered that the surreal barn-owl based defender clone -- Agony (Shades of Jeff Minter?) indeed used EHB, then got easily sidetracked as someone has made a UE4 based PC clone of it.

https://gamejolt.com/games/agony-unofficial-remake-demo/1601...

Codetapper has a nice breakdown of how it did things

https://codetapper.com/amiga/sprite-tricks/shadow-of-the-bea...

I still vividly remember Agony beautiful soundtrack. The game itself was very pretty but gameplay was nothing exceptional.

I remember my friends and I spent far more time showing it off to people than actually playing it properly.

Which fits, as people involved basically later described the original Shadow of the Beast pretty much as a graphics showcase with "no thought whatsoever" going into more than showing more parallax scrolling and more monsters in.

It's hard to show it to people now and have them understand just how jaw-dropping it looked to people at the time, both to Amiga users, but especially to PC users where most people still did not have graphics cards capable of lots of colours and smooth scrolling with even a single parallax layer, much less the dozen or so in Shadow of the Beast...

I also just realised the intro I remembered showing friends is the intro for Shadow of the Beast II, a game I never bothered playing - but where "everyone" had seen the couple of minutes of animation of the intro, at a time when having a long animated intro like that was in itself a big deal.

Also the smoothness - locked at 50 frames per second, it was mesmerising.

I came from the MSX computers, which usually had blocky character per character scrolling, or slower animations. The PC games were usually even crappier then that. And the Amiga stereo sound, was also incredible if you happened to play a game on a stereo TV set. Most games didn't even bother to mix the sound properly (to slow CPU and/or too few channels, 2 for left, 2 for right) but that the sound had some kind of "depth" not present in mono speakers, also added to the subconscious feeling that this is different.

(3D games - Wolfenstein & Doom - instantly switched the tables, it was obvious that the parrot was not merely pining but actually dead.)

Most Amiga games with parallax used dual playfields mode. AFAIK, you couldn't combine that with EHB.

Shadow of The Beast used dual playfield graphics, not EHB. Agony too, for gameplay. Title screen etc could be EHB.

https://codetapper.com/amiga/sprite-tricks/shadow-of-the-bea...

It was only early NTSC (only) A1000s that didn't include EHB -- it was OCS, not an ECS feature. Far as I recall all revision A500s and A2000s had EHB. All PAL A1000s had it.

Quite a few games used it for drop shadows and such. Well, the ones that weren't ST identical, which was far too many.

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

To maximize performance you'd tend to combine the blitter with a M68k loop, typically using MOVEM to maximize the number of bytes copied per instruction.

The reason for this is that the blitter can not utilize every single memory cycle.

So if you want to maximize graphics throughput you'll need to carefully balance the work between the blitter and CPU depending on which CPU.

There's also a NASTY bit you can set so the Blitter gets the bus cycles it want, any CPU access will have to wait for a spare cycle.

I'm not sure how much faster using that bit will make Blitter graphic operations in practise. I suppose when using 6 bitplanes a small speedup of like 10-20% could be seen.

so fun to see both of you discuss in depth like old magicians

I just want to let you know that I appreciate someone showing up in threads like this who have such solid knowledge of things like the details of the Amiga Halfbrite mode.

Targetting 320x256 makes it harder to port to 320x200. Meanwhile, porting 320x200 to 320x256 is easy, just add a small letterbox.

I always thought 256 vs 200 was a PAL vs NTSC thing? Is that wrong?

It certainly was on the Amiga.

Ya, depends on the system. For example, the NES is 320x224 (NTSC) and 320x240 (PAL).

I can't speak to why they differ exactly though.

The number of lines per second is constant, but you get 50 frames per second on PAL and 60 frames per second on NTSC.

Actually the number of lines per second is not constant, but the overall video BW is “similar”. In terms of analog TV, PAL has at the same time lower refresh rate and higher channel BW, which in terms of computer resolutions means that NTSC is exactly 640x480 (as that is derived from NTSC timing) while PAL is something like 800x600. Home computers for all the time where that class even existed simply didn’t have both the framebuffer sizes and video BW to generate full resolution video, so the resolutions ended up halved (and in analog TV there is no horizontal resolution to speak of, so 320 is just as good number as any)

Constant-ish.

320x200x60 = 384k lines 320x256x50 = 410k lines

Akshually, the horizontal (BW) resolution has little to do with timing. It's as good as the analog components are and as good the computer can output. Amigas had 1280x256 resolution, if you wanted, on standard PAL equipment. (On a fuzzy TV set, you weren't likely to appreciate 1280 horizontal resolution though.)

You need to ignore the horizontal resolution and count the blank areas as well: PAL = 25 * 625 = 15625, and NTSC = 29.97 * 525 = 15734.25.

Haha I wasn’t thinking straight! Good thing I used 320 in both examples

Not wrong but the Atari ST's low resolution is 320 by 200, even for PAL, so targeting that resolution is helpful if you want to target both machines

And only a few years afterwards, the Acorn Archimedes (launched in 1987!) would achieve comparable or better (especially in 3D) graphics and sound via pure CPU power, with little or no custom hardware. Cool stuff, but it was essentially a dead end architecturally. Even if Commodore hadn't screwed up to the extent it did, that whole generation of machines was tied to the 68k series, and would have died with it anyway. (Even Apple could not save the 68k, they jumped ship to POWER instead.)

Juste to state what is obvious for many but Archimedes CPU is none other than ... arm, the most ubiquitous cpu on the planet nowadays.

I'm not sure "little or no custom hardware" is a great way to describe the Archimedes.

OP meant custom graphic hardware. Dumb framebuffer is also what Apple Macintosh used, combined with full graphic library in firmware. Brilliant less is more/worse is better approach. Mac graphic accelerators simply patched firmware routines for their own accelerated versions - no drivers, no software rewrites, plop a card and everything is faster.

The Archimedes had custom graphics hardware. The VIDC was an Acorn design.

The VIDC provided a configurable framebuffer (with choices for resolution and color depth), plus a single "mouse pointer" sprite. Audio was just PCM channels. The Amiga custom hardware did a whole lot more than that.

Sure, but the quote was “little or no custom hardware” - a bit wide of the mark! The thing didn’t even have an off the shelf cpu.

ARM is not an "off the shelf CPU"? Would you say that the Commodore 64 didn't use an "off the shelf CPU" simply because MOS Technology was owned by Commodore?

Well, yes and no - it is a slightly modified version, the 6510, so in that sense, yes. But in another sense, no, because what did they do, when they found themselves in need of a CPU? They used an existing design. That's pretty much what "off the shelf" means.

The VIC-II would count as custom hardware, I should think, as it sounds as if it was designed specifically for the C64. Same as the Amiga stuff was designed by the Amiga team for use in their computers. And same as the ARM CPU (and the other bits) were designed by Acorn for use in theirs.

I would contest that, The CPU power advantage was considerable, the 68000 took 4 clocks to add two registers, anything fancier took more, compared to the ARM where you could build the kitchen sink and shift it across a bit in a clock. That was why the 3D performance was so much better. but to gain the capabilities that were available in 2D the advantages of playfields, sprites and copper lists you'd need far more CPU power.

Just leaving "The Ultimate Acorn Archimedes talk" here: https://www.youtube.com/watch?v=Hf67JYkUCHQ

Reply on news.ycombinator.com