1

The stats are: https://en.wikipedia.org/wiki/Cray-1

Memory‎: ‎8.39 Megabytes (up to 1 048 576 words) CPU‎: ‎64-bit processor @ 80 MHz The 24-bit address arithmetic was performed in an add unit and a multiply unit. The scalar portion of the system consisted of an add unit, a logical unit, a population count, a leading zero count unit and a shift unit. The vector portion consisted of add, logical and shift units. The floating point functional units were shared between the scalar and vector portions, and these consisted of add, multiply and reciprocal approximation units.

The system had limited parallelism. It could issue one instruction per clock cycle, for a theoretical performance of 80 MIPS, but with vector floating-point multiplication and addition occurring in parallel theoretical performance was 160[11] MFLOPS.


I am not sure how graphics would implemented, but I`d like sprites with arbitrary size and of arbitrary number, Amiga's Denise like https://en.wikipedia.org/wiki/Original_Chip_Set#Denise

  • 2
    Of course, in a standard config, you need another computer to do the I/O. Some systems used as front-ends would be considered as mainframes in their own right. – another-dave Oct 11 '19 at 0:25
  • 1
    I am just giving a general idea. I saw a question regarding a present day supercomputer, but they are no good for games, as they would hardly synchronize for fast refreshing frames per second. And old cray is closer to a fast CPU though. – user36088 Oct 11 '19 at 0:40
  • 3
  • 1
    @another-dave The article misses a key point: though it discusses the Fujitsu Numerical Wind Tunnel and rates it at 124.2 gigaflops per second, it entirely misses the fact that by accelerating its processing by 124.2 giga-floating-point operations per second per second, it would rapidly become faster than even our fastest computers from 2019. – cjs Oct 11 '19 at 1:12
  • 3
    Not quite video games, but there were flight simulators in the 80s and 90s which used Crays for calculations (and another supercomputer or mainframe for I/O). I don’t have references at hand, I’ll try to look them up later... – Stephen Kitt Oct 11 '19 at 5:57
10

The Cray you're describing there is nothing but a block of pure processing power. You're not describing any sort of input or output, so the question is very vague. You could put any sort of rendering front-end onto a generic computer like that:

  • Older 8-bit home micros could have bitmap modes, or tile modes with sprites, or some combination of these, making them a lot more console-like than computer-like.
  • Bitplaned graphics like the Commodore Amiga series OCS chipset. Memory efficient, but requiring finesse to draw arbitrary graphics.
  • Chunky graphics like 320x200 13h VGA. Accessible, easy.
  • A fully-hardware accelerated graphics card capable of hardware transform and lighting etc. The processor lines up the shots and the graphics card takes them.

I'm going to assume by the way you're mentioning the memory size and computational throughput, you want to know more about the software rendering capability of a computer of that level of sophistication, which sounds to me a lot like how DOS games were rendered into VGA-style chunky output.

Let's take a typical early-nineties VGA card and attach it to our Cray. Something like the Trident TVGA9000C (http://old.vgamuseum.info/zaatharens-collection/69-trident-microsystems-inc/1129-trident-tvga9000c.html). It's got a flat framebuffer, with no acceleration whatsoever. No block image transfers (blits), no hardware scrolling beyond a couple of coarse register tricks. It's just a rectangle of memory in the Cray's memory space linked to a 256-colour palette.

Now we can have a look at a couple of DOS games:

Here's the minimum requirements for Quake in DOS. https://gamesystemrequirements.com/game/quake

IBM PC and Compatible Computers
Pentium 75 MHz processor or better (absolutely must have a Math Co-Processor!)
VGA Compatible Display or better
DOS -- 8 MB RAM required
CD-ROM drive required
Hard Drive Space Needed: 80 MB

That'll get you 75 fps 256-colour palettized 320x200 3D graphics with some lighting effects. That's all software rendered in DOS Quake.

Here's the minimum requirements for Jazz Jackrabbit in DOS. https://pcgamingwiki.com/wiki/Jazz_Jackrabbit

Operating system (OS)   5.0 
Processor (CPU) Intel 386 33 MHz    486
System memory (RAM) 4 MB    
Hard disk drive (HDD)   13 MB   
Video card (GPU)    VGA 
Sound (audio device)        Gravis Ultrasound, Sound Blaster, Sound Blaster Pro, Sound Blaster 16, Pro Audio Spectrum 16
Controller      Gravis Gamepad or generic joystick

Jazz Jackrabbit is a very console-like game with tiled backgrounds, sprites (let's say 64 16x16 sprites going around if there's a lot of bullets, explosions and enemies), software-mixed music. The game offers levels of detail settings, which I believe affects things like coloured sky, amount of explosion sprites, etc.

Jazz also has a 3D bonus stage section that resembles SNES Mode-7 graphics with overlaid sprites, with Jazz running around a flat but textured landscape in pseudo-3D collecting floating gems.

All that fast math is going to be a great help for these games!

Let's move up a level to the original Unreal: https://wiki.beyondunreal.com/Legacy:Unreal

 Operating System  WIN 95/98/NT/Linux
 CPU  Intel Pentium 166 MHz
 Memory  16 MB RAM
 Hard Disk Space  100 MB
 CD ROM or CD/DVD ROM  4x
 Audio System  Windows® compatible sound card
 Video System  Video Card 1MB

Unfortunately, the Cray isn't going to cut it software rendering Unreal. It might be able to do a low resolution mode or something, but it won't be pleasant.

Here https://www.alternatewars.com/BBOW/Computing/Computing_Power.htm the FLOPS of a Pentium 100 is given as Benchmarks: 0.09 GFLOPS (i.e. 90 MFLOPS).

You said:

The system had limited parallelism. It could issue one instruction per clock cycle, for a theoretical performance of 80 MIPS, but with vector floating-point multiplication and addition occurring in parallel theoretical performance was 160[11] MFLOPS.

So, as a back-of-the-envelope, like-for-like comparison of the various attributes, as a computer, it resembles a 1994/5/6 DOS 6.22 machine. I'd say you'd be playing Jazz Jackrabbit, Quake, Need For Speed 1&2, Theme Hospital, Dungeon Keeper, Sim City 2000, Tomb Raider, Little Big Adventure, Abe's Oddysee and Command & Conquer on your Cray - DOS machine.

And, looking at that list of games, what console does it most closely resemble in visual output power for real-time gaming? A PlayStation 1.

But depending on how things work out in this fictional computer - I'd say it would be heavily fill-rate limited due to the memory rather than the processing power. For either 2D or 3D, there's going to be lots of copying backwards and forwards of blocks of memory.

For purely 2D output, it'd be juicier than a SNES I would say, since there are SNES emulators for DOS. Other 2D consoles it would be able to completely encompass: Spectrum, C64, Master System, NES, Amiga 500/1200/CD32, Mega Drive, PC-Engine.

I'd say it would be within ±20% of what a Neo Geo's display hardware can do, in terms of independent layers and sprites. https://en.wikipedia.org/wiki/Neo_Geo_(system)

Here's a video of Metal Slug on the Neo Geo AES: https://www.youtube.com/watch?v=qsMWIbnKrqk

Your entirely-software-based rendering system would have no restrictions on layer or sprite size since they'd just be (masked) rectangle copies. The limitation would simply be how much memory assignment power (i.e. the fill rate) was available. Rotating and scaling sprites in software would be a large cost - to be avoided by prescaling in advance when the game assets where made, or just-in-time scaling in memory before whatever scene needed them began.

(Bear in mind that the Neo Geo uses cartridges to contain all the source graphics. Would your hypothetical Cray-console have that?)

Edit - Addressing alephzero's comment:

All this is probably an overestimate of the Cray performance for this type of application, since memory was word (64-bit) addressable only, there were no 64-bit integer machine code instructions, and there was no "quick" way to do anything with 8 or 16 bit data. The maximum performance (in reality 132Mflops not 160, because of vector start up overheads) was only possible with 64-bit floating point operations on vectors that were a multiple of 64 elements long, which is pretty irrelevant for a video game. "Scalar" performance was typically about 5 Mflops, not 132

You're right alephzero, insofar as the values 80-160 MFLOPS are at maximum, fully-populated vector performance, and that outside this ideal, the scalar performance would be low. However for many kinds of 2D games under DOS the amount of decision-based, highly-branching computation is pretty low. Assuming again that the asker is interested in shmups, fighting games and other Neo-Geo-like titles with large bgs and sprites, there's going to be a lot of predictable, repeated, direct rectangular copying going on. Since the Cray-1 has a "memory-memory" (see Wikipedia) architecture, the vector instructions will be ideal for block memory reads, masks and copies!

The vector operations are not necessarily floating point: they can be scalar. The following operations can be performed by the scalar logical units with their contents populated, advanced and written to memory by the vector system. (See 2240004 3-11 C in the Cray-1 Hardware Reference Manual http://ed-thelen.org/comp-hist/CRAY-1-HardRefMan/CRAY-1-HRM.html#p3-3) Sure, this might be not particularly great match for the interface of the standard VGA card I described, but for the case of getting values around from one place to another, it would be somewhat helpful.

The contents of a V register are transferred to or from memory by specifying a first word address in memory, an increment for the memory address, and a length.

From the sounds of that, it might be possible to have these vector operations working on a byte granularity, satisfying the use of a VGA card in 13h with chunky pixels. (And if not, then you'll have to use word-aligned sprites perhaps?)

Unmasked direct rectangular blit:

DEST = SRC

The contents of the lines of graphics within SRC overwrite those in DEST.

This is what you could use for filling the screen, drawing rectangular layers where the underlying content is unimportant, or drawing rectangular objects. (Alternatively, you can use it as a scrappy way of drawing sprites if you don't care about weird corners disappearing.)

Masked rectangular blit:

DEST = DEST & MASK 
DEST = DEST | SRC

Where MASK contains all 0s in pixels occupied by visible pixels of the sprite (that should be erased before the sprite is copied) and all 1s where the sprite is transparent.

This will let you draw graphics while keeping the background intact, for sprites, GUI elements, etc.

Also, note the following:

A result may be received by a V register and re-entered as an operand to another vector computation in the same clock period. This mechanism allows for "chaining" two or more vector operations together. Chain operation allows the CRAY-1 to produce more than one result per clock period.

This means that the operation DEST = (DEST & MASK) | SRC could be performed without the intermediate write to memory taking place.

More complicated algorithms for texture mapped graphics might benefit from the vector floating point performance as the pixels of a textured/shaded triangle are drawn in a vectorisible fashion.

| improve this answer | |
  • You may use memory, but the idea is to keep as close as possible to the original hardware, avoiding more recent hardware as much as possible. Cray had 303Mbytes of `disc`` memory, which is much more than a cartridge. So, yes, you could use anything, as long as, in the end, it had to stay in the Cray. But, I think PS1 is much faster than a NEO-GEO, I think. It did outperform the best Super Scallers from Sega and Capcon machines for their fighting games. – user36088 Oct 11 '19 at 1:21
  • I'm not entirely sure of the relative performance of the PS1 and Neo-Geo for 2D games. I have an inkling that the Neo-Geo wins in 2D in terms of layers and sprites, which is what the question asked. – Gero Oct 11 '19 at 1:25
  • I think PS is pretty much superior in all aspects. But its loading time is slow, so you won`t huge sprites or large 3D environments, like the N64. The NEO GEO CD had long loading times, like minutes, for a simple fight stage, something which would takE fractions of a second in an AES NEO GEO – user36088 Oct 11 '19 at 1:46
  • 3
    All this is probably an overestimate of the Cray performance for this type of application, since memory was word (64-bit) addressable only, there were no 64-bit integer machine code instructions, and there was no "quick" way to do anything with 8 or 16 bit data. The maximum performance (in reality 132Mflops not 160, because of vector start up overheads) was only possible with 64-bit floating point operations on vectors that were a multiple of 64 elements long, which is pretty irrelevant for a video game. "Scalar" performance was typically about 5 Mflops, not 132. – alephzero Oct 11 '19 at 9:52
  • What do you mean by scalar performance? If you are getting to the level of a NeoGeo, you have to have at least 24 bit adressing. – user36088 Oct 11 '19 at 20:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.