▲ 704 points
back
125 comments
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?
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.
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.)
Traditionally some corrections for the author:
>The Amiga 1000 could not boot by themselves, they had no ROM. The bootloader was on a floppy and you better not lose or damage it!
Amiga 1000 has bootloader (Kickstart loader) in ROM, chips U5N and U5P - two 256Kbit EPROMs/mask ROMs, 64KB in total. What it didnt have was firmware(Kickstart, like PC bios) or system(Workbench, like PC DOS/Windows) in ROM. You can see chips containing A1000 bootloader on the motherboard picture, its the two with stickers, right below two 8250 CIA chips https://www.bigbookofamigahardware.com/bboah/media/download_...
You cant boot(load) without a bootloader. Trivia: Back in the day Bill Gates held a record of writing the shortest bootloader for Altair 8800, computer with nothing but LEDs for output and switches for input. You had to input said bootloader every single time you wanted to load something (like BASIC) from tape. 'Computer Notes Volume 1, Issue 6, 1975' Page Twenty-One, Author Bill Gates: “I’ve written a bootloader that only takes 13 bytes of keyed-in data, but anything smaller than 20 bytes isn’t easy to use.”. He was finally beat by one byte in 2017 http://just8bits.blogspot.com/2017/03/doing-it-in-less-than-...
>It was Commodore best selling product with an estimated 6 millions units shipped from 1987 to 1991
other than you know, C64 ;-) and thats not counting other products like Datasette Commodore 1530, shipped with every VIC-20 and C64.
>amiga_arch.svg
Chip RAM is not directly connected to CPU, its gated behind AGNUS https://www.pmsoft.nl/amiga/A500-block-diagram.jpg DBR signal is what switches CPU data bus access.
Thanks for these clarification, I will update the article and drawings tonight.
> firmware(Kickstart, like PC bios)
My understanding is that Kickstart contained both Exec (the kernel) and Intuition (the windowing GUI library), so it was more than a BIOS.
Corrections for http://fabiensanglard.net/another_world_polygons_PC_DOS:
>pc_arch.svg
VGA was hanging off 16 bit ISA bus. CPU wasnt touching ISA, Ram wasnt touching ISA. You had chipset with build-in memory controller, ISA arbitration and fast Cache was the norm. Typical contemporary 386/486 motherboard diagram http://www.textfiles.com/bitsavers/pdf/samsung/pc/98134-925-.... page 1-1 system block diagram will explain a lot.
> clear the screen
this must be the worst clear screen routing of all time :o why bank switch at all? setting mask to 0xff once will write to all of them at the same time
outpw(0x3c4, 0xff02);
memset(VGA,0, 8000);
>SOLVING COPY, 4x speed up
Transfer speed when writing to non crappy 16bit ISA VGA card is ~3MB/s. Reading is always slower, nobody optimized graphic cards for reading, sometimes even ending up under 1MB/s. I think I read Abrash or Carmack stating that IRL on real hardware this ended up being a wash in terms of performance.
>SURPRISINGLY DIFFICULT AUDIO, On Amiga and ST it was a piece of cake
ST has no native PCM output. Atari uses "Yamaha" YM2149 aka re-licensed AY-3-8910, audio chip from ZX Spectrums and Amstrad CPC. Its the same pain as trying to play PCM on Adlib (volume register?), except even lower fidelity.
> Datasette Commodore 1530, shipped with every VIC-20
The Datasette did not ship with every VIC-20. There were plenty of non-Commodore datasette clones on the market, however.
Since you seem knowledgeable, and this seems surprisingly hard to google, do you know why it was named "Amiga"? I know the codename was "Lorraine" and, because I'm a native Spanish speaker, I know "amiga" means "female friend", but why was this name chosen? Did they simply pick a random name, and if so, why Spanish?
A few games used the RAM intended for the Kickstart on A1000. The same game on A500 needed 1MB RAM.
Bootloaders are interesting, and the one that impresses me the most is the one for the EDSAC. It's 31 instructions, and implements a relocating assembler that is used to load and assemble the program you want to run on the computer.
Another World was _astounding_ when it came out. Although the Amiga was considered a high spec machine at the time, its graphics hardware was oriented around scrolling, sprites, and rectangular blits. This is good for the typical platformers and shoot-em-ups that dominated gaming at the time but useless for the type of full motion video the AW was attempting.
The Amiga's blitter could write almost 4Mbs per second (if you set things up juuuust right and you had the wind behind you). On a modern monitor (a modest 1920 * 1080) the Amiga's blitter would take almost 2 seconds just to clear the screen.
I think the coolest part about many games from this time period is how vastly differently they were developed compared to modern games from modern game studios.
"...it is the original version built from 1989 to 1991 by then 21 years old Eric Chahi working alone in his bedroom."
Because he got royalties from an earlier game, and that paid enough for him to take on this project. And he did pretty much everything except the music: Programming, graphics, story, box art. One dude. One 21yo dude. In his bedroom. And he wrote a VM! He wrote his own bytecode! He wrote his own VM host in assembly!! And then he wrote the game in his own bytecode!!!
And then you have the people who ported games in this time period, who often got nothing to work with. No code, no comments, no assets. Disassemble the thing yourself on a platform you might know very little about, and re-write the thing on a platform you do know a lot about. You get a couple of months. Chop chop, the publisher is waiting.
And if you haven't read Jordan Mechner's journals of him writing Prince of Persia from the same era, you should. It's equally bananas. And impressive.
It was astounding back then and in my mind still is a work of art. Like Fabien says, its limited palette actually worked in its favor. The evocative graphics still remain some of my favorites, ever.
It's one of my most replayed games ever. Even when I know the plot and there are no surprises, this game manages every time to take me to... (cue music) ANOTHER WORLD.
If you haven't played this game I strongly recommend it. It's on GOG. It's on old emulators too but the graphics and input handling can be pretty rough and unforgiving.
Given that it’s apparently a bytecode executable for a VM, is there a modern implementation of said VM? Maybe even one that translates the draw ops into Vulkan commands? Seems like a fun project.
I second this. Another world was a fantastic, innovative game.
Also look for Another World – 20th Anniversary Edition.
There is a version on Playstation that's very good. You can switch between the original graphics or updated graphics by simply pressing a button at any time. It plays really well.
It's also on Steam now!
Amazing, as everything in Fabien's site.
I rushed, hoping to find some oldskool tricks and remember my time spent reading Denthor's VGA Trainer[0].
It seems I'll have to wait some more chapters for that, though. :-)
Another World's original author Eric Chahi gave a great GDC "Classic Game Postmortem" talk about creating the game:
Using a custom VM was certainly a clever and efficient at the time.
LucasArt used the same trick for a lot of point and click games.
I don't think this idea would scale well for much bigger projects, as debugging internal scripts can quickly become a bottleneck.
Well, the technique has been used in newer projects as well. Quake and Quake 3 both had VMs that ran the game logic.
Tooling is a perennial problem with extension systems, but it’s really damned if you do, damned if you don’t. If you’re not using an extension system, then you’re probably writing the game logic and the engine as one giant mass of C++ code. Writing tons of game logic in C++ will get you in trouble for lots of reasons. Writing an interface between your C++ core and some kind of scripting system will get you in trouble for completely different reasons.
Tim Sweeney did a presentation about the programming environment needs of different parts of games back in 2005, still worth reading: https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...
Another example of custom VMs from that era is Infocom's Z-machine, used for text adventure games.
The strategy of using a bytecode VM to ship cross-platform games seems to have been pretty popular back then, which is a little surprising to me -- I thought Java came up with that idea first!
Now that the Atari ST part of the article is out as well, I'll add some corrections regarding ST graphics format. The article states that "There are no bitplanes here like on the Amiga we saw in the previous entry." This is slightly inaccurate. ST does have bitplanes, but the organization is interleaved to 16 bit words, unlike on Amiga where the bitplanes are stored as separate memory regions.
So in 1 bpp hires mode, there's just a single bitplane (and the memory layout is identical when comparing to Amiga 640x400 interlaced hi-res 1 bpp screen mode). In 2 bpp medium res (640x200, 4 colors), there are two bitplanes, alternating bitplanes for every 16-bit word. So 16 bits of bitplane 0 for the first word, then 16 bits of bitplane 1 for the second word (these together form the first 16 pixels), and so on. In the 320x200 low res mode there are four bitplanes interleaved in the same way.
What this means from the programmer's perspective is that you can do similar bitplane tricks as with Amiga, e.g. modify just one of the bitplanes independent of the others. For instance effects where car headlights change the background image colors can be done the same way on both machines: render to just one bitplane and use the palette to achieve the change in colors.
However, when with Amiga it's trivial to modify bitplane pointers independent of each other to scroll graphics around, on Atari ST all bitplanes are tied to the same base pointer (because they are interleaved in the memory). (And to make things like full-screen scrolling even more difficult, this base pointer is aligned to 256 bytes, i.e. the low byte of the video memory base address is always 0 on Atari ST - on STE this is programmable.)
There are some cases where the interleaved bitplane format gives benefits: while neither of the machines are good for writing texture mappers (or other effects that require manipulation of single pixels), it's slightly more efficient on Atari ST because the layout allows some tricks (e.g. using MOVEP instruction to write 8 pixels to all 4 bitplanes at once from a single 32-bit register).
From the point of view of a game like Another World, the bitplane arrangement of Atari ST doesn't really cause additional problems when comparing to the Amiga. The issue is the lack of blitter (and STE blitter isn't that great improvement, it doesn't have the line drawing capabilities of Amiga blitter and has less flexible src/dst mechanism, so no wonder it isn't utilized by the game).
The SNES was the platform I played "Out of this World" on.
The interesting thing about it was, it was a polygon game that ran without using the SuprFX chip.
With the SNES being sprite-based I could never figure that out.
The article has a link to a video of the author of the SNES port talking about it. https://www.youtube.com/watch?v=tiq0OL8rzso
I've always wondered, did Nintendo demand that all games have continuously running soundtracks? I remember playing this game and Prince of Persia on the SNES and being really put off by these soundtracks someone shoehorned in.
I think hardware limitations were a huge source of creativity in games. If you want to make an interesting game, tie a proverbial hand behind your back and see where it forces you to go.
Game developers are ALWAYS held back by hardware limitations.
Fabien's blog is a pot of gold. I love this "archeological" approach to programming. He also makes the articles feel like documentaries. It's just unique.
Couldn't agree more. His two books are also phenomenal [1]. If anything, worth getting a copy just to support his amazing work.
I was one of the few kids who got a 3DO (yes really), and I had a copy of Another World for it, after already having played it on the Genesis, and I was a bit underwhelmed, since moving to comparatively more-powerful hardware didn't make the game look a million times better.
After a bit, though, I realized it wasn't that the 3DO version was underwhelming, but instead that the Genesis version was amazing. It already felt like a next-gen game, and so the upgrade to the 3DO didn't make a huge change.
In the end, it has become one of my favorite games. I love the art, the style, the cutscenes, and even though it's incredibly short, I love the story.
I never played Heart of the Alien, because I never had a Sega CD, but I'd like to play it at some point on an emulator.
"The 3DO version of Out of This World is quite different from the other versions in terms of graphics and sound. The polygon backgrounds have been replaced by hand-drawn versions, the quality of which varies from stunning to amateurish."
It's available on Nintendo Switch for those who are interested in trying it out.
I played this game in the PC, back then. It was one of those games I've consireded like "top game" for D.O.S. What a nostalgia bump I've got.
I was just eyeing the game on my steam library early in the day. Fantastic title, shame he went on to produce so few follow ups.
Another World was so far ahead of it's time. I have such find memories of playing it on my brother's Amiga :)
It's also just a lovely piece of art.
Awesome read
amazing stuff, give a try also to the video from the snes conversion programmer
who remembers... Bard's Tale??
https://en.wikipedia.org/wiki/The_Bard%27s_Tale_(1985_video_...
This is truly amazing.
This is amazing.
Is there a known Javascript VM implementation of this game?
Third time this has been posted in 17 hours: