68k details

[roondar]

Originally Posted by chb

True, but in my eyes it's not a design very well suited for scrolling if your system with 4x the bandwidth of the Amiga after display dma and scrolling is left with about the same bandwidth... not to speak about overscanned screens! (Yep, I'm comparing 4bpl to 8bit, not fair.)

This may come as a shock, but I don't think that gaming performance was the key design element of the Archimedes computer range

However, unlike most other non-gaming systems of the time, the Archimedes could do it rather well anyway. Which should speak for itself. Besides, plasmab showed us that the system can do vertical scrolling just fine and offers two-pixel granularity scrolling using the hardware (so 1px scrolling only really needs half the work done - do one frame using the hardware and one using brute force).

Personally, I rather like the Archimedes and the ARM2. Never owned one, but I can't help but like the idea of a computer design where everything was focussed on that getting that (for the time certainly) fast CPU working as well as possible. It certainly is a better design for that purpose than the average PC was.

[plasmab]

Amusingly... show me an Amiga game that allows arbitrary direction scrolling like the Archie does..

[ Show youtube player ]

Honestly.. you 68K fanbois... locked to the X and Y axis like suckers

[Bruce Abbott]

Originally Posted by plasmab

[ Show youtube player ]

Honestly.. you 68K fanbois... locked to the X and Y axis like suckers

Jaggies everywhere, disorienting, unimaginative graphics, weak sound, repetitive gameplay - Awful. If that's the best it can do...

[plasmab]

Originally Posted by Bruce Abbott

Jaggies everywhere, disorienting, unimaginative graphics, weak sound, repetitive gameplay - Awful. If that's the best it can do...

You'd say the same about Doom or Quake though so i'm taking no notice. Just the usual jealousy that I've come to expect from Amiga fan bois.



Its basically a top down first person shooter. First person in the sense that the map rotates around the player rather than the player around the map.

[robinsonb5]

Originally Posted by plasmab

Amusingly... show me an Amiga game that allows arbitrary direction scrolling like the Archie does..

[ Show youtube player ]

OK [ Show youtube player ]

Point taken though, for the time and the technology that's really cool. Looks awful to today's eyes, but a noteworthy milestone nonetheless.

[touko]

This may come as a shock, but I don't think that gaming performance was the key design element of the Archimedes computer range

You're right .

[Galahad/FLT]

Originally Posted by plasmab

Amusingly... show me an Amiga game that allows arbitrary direction scrolling like the Archie does..

[ Show youtube player ]

Honestly.. you 68K fanbois... locked to the X and Y axis like suckers

Rotox released in 1990 did that and Operation Harrier

[plasmab]

Originally Posted by Galahad/FLT

Rotox released in 1990 did that and Operation Harrier

Not seen those. Will check em out. Thanks

[zero]

Originally Posted by roondar

Personally, I rather like the Archimedes and the ARM2. Never owned one, but I can't help but like the idea of a computer design where everything was focussed on that getting that (for the time certainly) fast CPU working as well as possible. It certainly is a better design for that purpose than the average PC was.

Me too. It was a nice machine, nice OS. Some great apps, and back at school the speed of the BASIC interpreter was great fun to play with (I didn't have access to an assembler or any documentation).

In many ways it a next generation Amiga, just lacking in the gaming graphics department, and released at a time when gaming was moving away from computers and on to consoles anyway. As you say, the hardware was very well designed and powerful for the time, taking full advantage of higher memory bandwidths available by then.

[Megol]

Originally Posted by Bruce Abbott

Jaggies everywhere, disorienting, unimaginative graphics, weak sound, repetitive gameplay - Awful. If that's the best it can do...

Let's extract the part relevant to this thread: "Jaggies everywhere".
Yes. That's a given with that resolution and isn't architecture dependent, a really fast machine can use subpixel precise rendering however that doesn't do much.

Don't understand how anyone can think "repetitive gameplay" is relevant in a technical discussion...

Originally Posted by Galahad/FLT

Rotox released in 1990 did that and Operation Harrier

No they didn't. The whole point is that the Archimedes could use texture mapping.

Originally Posted by zero

Me too. It was a nice machine, nice OS. Some great apps, and back at school the speed of the BASIC interpreter was great fun to play with (I didn't have access to an assembler or any documentation).

The BASIC _is_ an assembler?
Never "got" the OS myself, some ideas are really cool but in general Amiga OS is much better IMO.

In many ways it a next generation Amiga, just lacking in the gaming graphics department, and released at a time when gaming was moving away from computers and on to consoles anyway. As you say, the hardware was very well designed and powerful for the time, taking full advantage of higher memory bandwidths available by then.

An Amiga-type chipset plus an ARM processor with an Amiga OS type system would have been a cool combination. Better than the PA RISC idea anyway...

[roondar]

Originally Posted by Megol

Let's extract the part relevant to this thread: "Jaggies everywhere".
Yes. That's a given with that resolution and isn't architecture dependent, a really fast machine can use subpixel precise rendering however that doesn't do much.

Don't understand how anyone can think "repetitive gameplay" is relevant in a technical discussion...

Thinking about it a bit, a redesign of the graphics would probably alleviate the jaggies quite a bit, they are mostly visible because of the many sharp edges in the tiles that are displayed. Note how they are less noticeable on the start screen with the purple rocks.

As for repetitive gameplay not having a place in technical discussion I mostly (but not fully) agree.

You could argue that if too many resources are taken up by the technical display trickery of a game, not enough CPU 'grunt' will be left in a frame to actually have competent gameplay logic (unless you let the frame rate drop). This may, or may not be why games such as Agony and Shadow of the Beast were lacklustre affairs in the gameplay department.

Note that I'm not saying that this is definitely the case, nor that it is the reason for Axis seemingly having this problem, just that it may contribute.

Heck, I haven't even played it - perhaps it only looks a certain way but turns out to be a blast to play. Wouldn't be the first time that happened.

[grond]

There are so many rotozoomers in Amiga demos that it is really is surprising that nobody ever turned that into a game. But then rotozooming a picture is a different thing than constructing the picture from tiles. I have to admit that all games mentioned here make me feel dizzy and the only one that might be some fun is "Bob's Bad Day". Yes, fun isn't a relevant parameter here but we should consider the possibility that somebody back in the day decided that the technically impressive and perhaps possible way just sucked as a game and did not do it for this reason.

Anyway, I think that a more important factor than processor power alone would be the availability of chunky modes because what we see really is mostly simplified texture mapping.

[roondar]

Didn't Brian the Lion have some levels using a rotozoomer or similar technique? I swear I remember a whole 'lecture' in the Amiga magazines of the time about how happy the programmers were with the results (better than SNES mode 7 accuracy, and similar marketing gobbledegook).

[Bruce Abbott]

Originally Posted by plasmab

You'd say the same about Doom or Quake though so i'm taking no notice. Just the usual jealousy that I've come to expect from Amiga fan bois.

Yep, Doom and Quake are both boring games - and I had Quake on my A3000-060 so I'm not just saying that as an Amiga fan.

Originally Posted by roondar

You could argue that if too many resources are taken up by the technical display trickery of a game, not enough CPU 'grunt' will be left in a frame to actually have competent gameplay logic (unless you let the frame rate drop).

We don't know if that is the case here, which is why I said "if that's the best it can do...". I am suspicious though - why does the background seem to have lower resolution than the sprites? Why no antialiasing? Why such lacklustre sound? Why leave the game in that awful state if it can be better?

[touko]

Originally Posted by roondar

Didn't Brian the Lion have some levels using a rotozoomer or similar technique? I swear I remember a whole 'lecture' in the Amiga magazines of the time about how happy the programmers were with the results (better than SNES mode 7 accuracy, and similar marketing gobbledegook).

Yes in the bonus stage .

[Megol]

Originally Posted by Bruce Abbott

Why no antialiasing?

8MHz processor and little memory.

[zero]

Originally Posted by Megol

The BASIC _is_ an assembler?
Never "got" the OS myself, some ideas are really cool but in general Amiga OS is much better IMO.

It is, but I didn't have a manual so I didn't know back then, and didn't know anything about the ARM CPU. Luckily I had a 68k reference...

One really nice thing about the OS was that apps were self-contained. They were just a directory with a special file inside that told the OS it was an app, and all the app's files could be stored in there. Installing and moving it around was as simple as drag-and-drop, no installer scripts or assigns to worry about. Uninstall was as simple as deleting it.

Having 3 mouse buttons was nice too.

[litwr]

I have added some more info to my article about 68k series.

But 68008, like 68000, does not have an instruction queue, which makes it about 50% slower than 68000. Thus, the 68008 may even be a little slower than the 8088, which is only about 20% slower than the 8086 due to the presence of the instruction queue.

I have also read a quite interesting cite about 68000 in the very solid Byte magazine recently - https://archive.org/details/byte-mag...5-09/page/n197

The MC68000 is one of those chips that some people love and others hate. There is very little middle ground. Compared to the 8086/8088, it required a massive software effort to get it to do anything.

Originally Posted by Bruce Abbott

I had an A3010...

I'm curious when did Archimedes appear in NZ? Were they available in 1987?

Originally Posted by roondar

It is actually 'completely' true: I was referring to your use of a .COM file to make your executable size smaller on one specific architecture.

The COM-file format is a consequence of the presence of segment registers, so it is quite fair to use this advantage. Indeed those several dozen bytes mean little for larger programs.

Originally Posted by roondar

Indeed, Intel's 486 and Motorola's 68040 were faster. To be clear here, they were roughly 3-4x faster than the ARM you are talking about. They were also a whole lot cheaper than you claim.

I can't agree with it. IMHO ARM@12MHz is only about 2 times slower than 486@25MHz with integer computations.

Originally Posted by roondar

Note that a fast 386 or 68030 should also comfortably beat the 12MHz ARM2. And those were cheaper still.

They couldn't do it with integers.

Originally Posted by meynaf

Who started cutting?
Sorry, but your 80386 code appears to have non-working timer code. Where is the text for the message saying what time it took ?
Furthermore, i never said this version was the fastest anymore. I never said it still measured time anymore. No OS calls, we said. I'm just approaching this goal.

You have started the cutting. You have used OS calls instead of the codes for them. 80386 code just prints time in seconds - what do you want else? The making slower code does this contest senseless.

Originally Posted by meynaf

I wouldn't say that, no. It's unbeaten only because you constantly change the rules.
However, even with whatever rules you use, it would be largely beaten if using my own "reencoded from 68k" instruction set

Sorry I haven't completely understood you. Should I emulate every 68000 instruction? You are asked to make the code for 68000 as fast as mine (for 68000) and smaller than mine for 80386. Indeed you don't need to emulate every 80386 instruction.

Originally Posted by meynaf

Best is still 72 bytes, and i didn't make that much efforts to reduce it.

It is just one rare case where we have to use a lot of registers.

Originally Posted by meynaf

There is no beauty for me in C code, and therefore no beauty to whatever corresponds to it.

C is very beautiful - it is beauty inspired almost all modern PL creators. What do you like? Fortran or Cobol?

Originally Posted by meynaf

For me English is too simple, imprecise language. In short, not the right tool - but what else can we do.

BTW does French have so many accents? IMHO English has too many layers and some of them are quite simple. Can you read Shakespeare rapidly?

Come on, more efforts on the "true" 80-byte version (2 insns to remove) and it could equal the 68k version Could you please post the 80386 code here as well?

My 386 version is about 180 bytes long. Do you claim that you have a fair 68020 version 80 bytes long?

Originally Posted by chb

*yes, I'm aware of Zarchos' demo, impressive, but still a lot missing.

Thanks for the mentioning. I'm very impressed. BTW it is at [ Show youtube player ]

[roondar]

Originally Posted by litwr

The COM-file format is a consequence of the presence of segment registers, so it is quite fair to use this advantage. Indeed those several dozen bytes mean little for larger programs.

1) It only works natively using DOS - and then only because DOS isn't as much an OS as it is an interface to the disk and screen. Only working under DOS => you are showing off an OS feature, not showing off the superiority of the ISA.

2) There is in fact nothing stopping you from creating similar headerless 68000 code other than the OS used. Only not working because the OS doesn't support it => you are showing of an OS feature, not showing off the superiority of the ISA.

To put it more simply: if you can't reproduce this 'fair advantage' using any non-DOS lineage OS, I'll correctly continue to consider it what it is: cheating.

I can't agree with it. IMHO ARM@12MHz is only about 2 times slower than 486@25MHz with integer computations.

Opinions are irrelevant, what you actually need is proof - and the easily available evidence (like the MIPS figures I Googled) suggest something completely different (About 7 MIPS for the ARM2, about 21 MIPS for the 486@25MHz).

If you feel this is wrong, I'm obviously more than willing to consider any evidence you wish to provide for your claims.

Besides, even if you were correct (and I don't buy that for a second given the massive difference in MIPS figures), your $10000 figure for the 25MHz 486 in 1991 is still utter nonsense. Which, if you had like me, Googled for even 30 seconds, you'd have known.

They couldn't do it with integers.

Yes, they could (or at the least should): high end 386's/68030's easily do over 8 MIPS, which is simply more than the 7 MIPS the 12MHz ARM2 does.

Just like with the 486 above, I'm willing to consider evidence against this, of course, but until there actually is some, I'm going to go with the MIPS numbers instead.

[meynaf]

Originally Posted by litwr

But 68008, like 68000, does not have an instruction queue, which makes it about 50% slower than 68000. Thus, the 68008 may even be a little slower than the 8088, which is only about 20% slower than the 8086 due to the presence of the instruction queue.

68000 does have an instruction queue. Perhaps you wanted to write "unlike 68000" ?

Originally Posted by litwr

The COM-file format is a consequence of the presence of segment registers, so it is quite fair to use this advantage. Indeed those several dozen bytes mean little for larger programs.

Not really, segment registers have absolutely nothing to do with COM format. Most 8-bit programs are headerless, too, without having segment registers.
Btw an Amiga bootblock is also headerless (well, mostly).
But running code that's not code (= data files) is quite dangerous so it's why it's better to not support this nonsense today.

Why don't you just do an Atari ST version of your program, btw ?
You would then notice that it's somewhat smaller than the Amiga version (OS calls are less powerful but simpler).
But it's the same cpu.
Does the code density of the 68000 change when put in a different machine ?

Originally Posted by litwr

You have started the cutting. You have used OS calls instead of the codes for them. 80386 code just prints time in seconds - what do you want else? The making slower code does this contest senseless.

No it's you who have started the cutting. You removed the part that asks for the number of digits. And the original code had a lot more text inside, so what you're doing here is basically removing texts (and a few features) from some code and then pretend the cpu you're using has better code density. Intellectually dishonest, to say the least.

Originally Posted by litwr

Sorry I haven't completely understood you. Should I emulate every 68000 instruction? You are asked to make the code for 68000 as fast as mine (for 68000) and smaller than mine for 80386. Indeed you don't need to emulate every 80386 instruction.

It seems you haven't understood at all
I didn't speak about emulating 68000 or 80386 instructions.
I just told that if i could use a 68k-like cpu i designed myself, it would beat the crap out of any x86 code you might write.

Originally Posted by litwr

It is just one rare case where we have to use a lot of registers.

It's not rare at all. 10 isn't a lot either.
If you really want to see something that can use lots of registers, try writing a c2p (or p2c).

Originally Posted by litwr

C is very beautiful - it is beauty inspired almost all modern PL creators. What do you like? Fortran or Cobol?

PL creators just lack imagination.
C is quite ugly, with all its curly braces everywhere (and meaningless : closing braces don't tell the type of block they end), parenthesis overload because of stupid operator priority, etc.
Perhaps even Basic is (visually at least) a lot more beautiful.

Originally Posted by litwr

BTW does French have so many accents? IMHO English has too many layers and some of them are quite simple. Can you read Shakespeare rapidly?

Why would reading Shakespeare have anything special ?

French has many accents because they actually mean something, either to get a different sound (like "é", "è" which are different to plain "e"), or to mark the presence of a removed letter (like the "ô" in "hôpital" which marks the ancient "s" which is still present in english "hospital").

Originally Posted by litwr

My 386 version is about 180 bytes long. Do you claim that you have a fair 68020 version 80 bytes long?

A 68020 version 80 bytes long ? It's already 72
But, hey, i was speaking about the line drawing algorithm...