Atari + 65816 = Amiga Killer ?

Quote from Chrille

Der 68000er hat so viel mehr Register, so viele Befehle und so viele Adressierungsarten. Das ist schon cool.

Dafür ist er bei der Abarbeitung der Befehle deutlich langsamer. Das ist der Hauptgrund, warum der Apple IIgs "nur" mit 2.8MHz läuft: bei gleichem Takt wäre er schneller als ein Macintosh mit einem 68000 gewesen. Damit lässt sich das "Profigerät" natürlich nur schwer verkaufen.

Jetzt aber mal Spaß beiseite. Nach ein bisschen IIgs Coding kann ich sagen, dass der 65816 nicht einfach nur ein "6502 mit 16 Bit" ist, sondern ein Prozessor, bei dem man viel neu lernen muss, und der halt auch einen 6502 Kompatibilitätsmodus hat. Leider sind die Schwerpunkte komplett falsch gesetzt. Man hat z.B. 5 (in Worten: fünf) verschiede Modi in denen die Kiste zu jeder beliebigen Zeit laufen kann. Deshalb gibt es keinen Disassember für statischen Code. Zumindest ist mir keiner bekannt, und cc65 hat nur für diese CPU keinen. Richtig schlimm ist aber: keiner davon kommt ohne die ersten 64k RAM aus. Dort muss immer die Direct-Page und der Stack liegen. Beides sind 16-Bit Register, den Stack kann man auch in einen 16-Bit Modus schalten.

Was sich gelohnt hätte, wäre ein Modus in dem man quasi eine "virtuelle Instanz" in einer eigenen 64k Bank aufmachen könnte. Dort würde dann Code, der nicht explizit Bank-übergreifend arbeitet, in seiner eigenen Welt laufen, komplett getrennt von anderen 64k Bänken. Man muss dann "nur noch" den Kontextwechsel brauchbar in Software implementieren (anpassen vom Stack, z.B.) und der Prozessor hätte dann Spaß gemacht. Aber so was geht halt nicht, weil DP und Stack nur in den ersten 64k laufen können. Chance vertan.

Für mich wirkt der 65816 so, als wäre er nur ein Prototyp und nicht fertig geworden, und zu Ende entwickelt wäre da was schickes bei rausgekommen. Quasi der Commodore 65 unter den CPUs.

Quote from Thunderblade

Quote from Chrille

Der 68000er hat so viel mehr Register, so viele Befehle und so viele Adressierungsarten.

Gut 1 Register mehr hätte dem 65816 auch gut getan. Aber Adressierungsarten? Ich als alter 6510 Junkie vermisse da eigentlich nix, aber wenn man nicht weiß was einem fehlt... Mit 68k hab ich mich nur rudimentär beschäftigt. Kannst du 1-2 Beispiele nennen wo mit dem 68k dank seiner Adressierungsarten etwas deutlich effizienter (und/oder bequemer, hehe) zu lösen ist?

Also ein Beispiel:

Alle Register (3; A,X,Y) auf den Stack schieben 6502:

pha

txa

pha

tya

pha

Alle Register (15; d0-d7/A0-A6) auf den Stack (A7)schieben:

movem.l d0-d7/A0-A6, -(A7)

addieren

6502

ohne carry:

clc

adc #$0a

mit carry:

adc #$0a

68000 (ohne Carry oder Xentend Flag)

add.b #$0a,d0

mit Xtented Flag (so was wie mit Carry)

addx.b #$0a,d0

mit Carry bzw. X ist es also genauso

Und man würde man so was wie Objekte haben, z.B. für ein Spiel

6502

Mehrer Arrays verteilt über den Speicher und dann würde man schreiben

X ist dann die Nummer des Objekts

lda Eigenschaft,x

am 6800er hätte man so was wie ein zusammenhängendes Objekt, das wäre dann z.B. in A0. Die Objekte hat man dann in einer Liste anstatt in Arrays

Dann würde man schreiben:

move.w Eigenschaft(a0), d0

Für das nächste Objekt:

move.l nextObj(a0),a0

Ich muss jetzt nicht erwähnen das Listen dynamischer und flexibler sind als Arrays, oder?

Beim 68000er kann man bei fast jedem Befehl/Adressierungsart auswählen ob man 8/16/32 Bit haben will, jeweils mit .b,.w und .l

Die Shift und Rotierbefehle kann man bis zu 31 mal shiften/rotieren anstatt das immer wieder zu schreiben, so was wie

lsl.l #20,d0 statt auf evtl. 4 Speicherstellen alles nach links zu shiften.

Das ist nur ein kleiner Ausschnitt der Vorteile am 68000er, gibt natürlich noch viel mehr.

Ja mit dem 6502 kann man das auch alles machen, aber manchmal ist es dann wesentlich komplexer. Und wegen dem Registermangel beim 6502, klar man kann auch vieles in die Zero-Page verschieben.

Also klar kann man alles auch auf dem 6502 lösen aber manchmal wird es unnötig kompliziert. Deshalb würde ich auch sagen man programmiert einfach anders, oder?

Zum 65816 in Bezug auf SNES gibt es einen ganz interessanten Text (eine alte README-Datei zu einer Entwicklungsumgebung fürs SNES auf dem Mac):

Stand vor Jahren mal in diesem Post (leider geht Direktlink nicht wegen G**gle, müsst ihr "von Hand" die Lücken schließen und kopieren):

https://groups.g o o gle.com/g/rec.games.video.marketplace/c/KYuRpH1Tb-Q/m/yw64qPLeoisJ

Quote

In fact there is a guy who did that; Silhouette is an emu for MacOS, and

a guy who previously worked for Nintendo has written it. I'll include

the readme, it's really interesting:

[start of readme]
-- Silhouette History --

Silhouette is the product of internal Nintendo research over several

years. In my opinion, the history of Silhouette is nothing short of

fascinating, so please read this document at least once before you throw

it in the trash. Originally developed under the code-name "Mirage" and

designed to serve as a Super Famicom development environment, Silhouette

has been modified into a working Super Nintendo emulation environment

which rivals the best efforts of any public development. Adequate

explanation of Silhouette requires a step back to the original days of

Super Famicom development.

The first batch of games for the Super Famicom were developed around

1988 and 1989. Popular Super Famicom titles, like F-Zero and Super Mario

World, were the most difficult for several reasons--if nothing else, the

Super Famicom hardware specifications changed in small ways at least

twice during the development project, requiring changes to existing

code. (Trivia tidbit: the original Super Famicom plans called for much

more extensive onboard 3D hardware--PilotWings was developed assuming

that this hardware would be present, and since this chip was scrapped

from the Super Famicom at the last minute, Nintendo was forced to

include this 3D chip on the PilotWings board in order to keep the game

on schedule.)

The other reason for difficulty in development is much less known, and

very surprising--almost all the programming for these titles was done on

the Apple IIgs! This seems ridiculous until you realize that both the

Super Famicom and the Apple IIgs are based on the 65816 processor, a

cheap toy with inadequate processing power that was stuck in the Super

Famicom to smooth over the early development process (since it is

backwards compatible with the 6502, the NES' processor). However, it was

soon realized by the development teams that a reliable 65c816

development platform could not be found on the usual Nintendo platforms

(most Nintendo devs at that time had a generic PC, excluding the art and

marketing department which was mostly Macintosh and a few segments of

the development team). Deadlines approaching, the Apple IIgs was chosen

as a quick if inelegant solution--several C and assembly compilers were

available, and testing and debugging was easier since we were able to

use a native 65816 for testing.
However, the IIgs proved woefully inadequate for large projects. Most

machines didn't even have hard drives! Compile times for even meager

projects were horrendous, and keeping all the work on floppies was

getting out of hand. And obviously, the graphics support on IIgs' was

minimal, so testing out small programs required switching between a

Super Fami prototype on the left and a IIgs on the right. Programmers,

in general, hated the thought of Super Famicom development. Many

continued to write 6502 code using the old NES development environment,

choosing to ignore on the 16-bit advantages of the 65816 in order to

complete the project without losing their sanity.

Nintendo soon pushed its efforts hard into developing a reasonable

development platform for Super Famicom (and soon, the Super Nintendo).

The project was codenamed Mirage, and several of the key designers of

the Super Fami hardware were assigned to the project. Along with full

65c816 emulation, interrupt timing and memory management, the Mirage dev

platform offered realtime debugging, code stepping, breakpoints, limited

video support and almost instant compile times. Developers were happy,

and Mirage proved to be an excellent way to write Super Famicom software

in record times.

At first, Mirage was anything but a traditional emulator--the video

consisted of squares on a black background (showing where sprites would

be) and pages of debugging information. It did not run in real-time,

there was no controller interface, no SPC700 chip emulation (required

for sound), a text-based user interface. It was meant for programmers

and used for writing code. Final testing was done on a real Super Fami

unit.
However, over time, the Mirage project got more advanced. Of course,

bugfix after bugfix was added, patching the code to make sure its output

matched that of a real Super Fami. A team working on some tricky

graphical effects added the first major patch, a separate window

(originally forced onto a second monitor) which would render a virtual

SNES screen. This process took several seconds on our original

hardware--one could watch the screen slowly draw from top to bottom--but

it worked, and it was more accurate than most of the emulators you see

today. A second team optimized the code, and combined with computer

upgrades around the Nintendo offices, this let Mirage run in

pseudo-realtime, although it was a fraction of the speed of a real Super Famicom.

It soon became common to test games on Mirage more and more extensively.

Developers found that the time needed to load their code from Mirage

into the testing units (up to a minute for large games) was excessive,

when with a click of the mouse they were able to immediately see the

game running within Mirage. Of course, there were a lot of limitations,

and nobody would argue that Mirage could replace a real unit, but it was

a start.

This is where the story gets interesting. In late 1996, a high-level

executive (who will remain anonymous) at Nintendo came to the Rare labs

one day, and saw a coder working on his game using Mirage. (Trivia

tidbit: Yes, Rare has many of its development labs within Nintendo of

America headquarters nowadays--they were always in bed together, now

more recently they've even shacked up. Diddy Kong Racing--shudder.) By

now, computer hardware had advanced to allow Mirage to run at playable

speeds on this guy's average desktop hardware. Suddenly the potential

struck him--Super Nintendo games on household PCs! Obviously there's a

market.
Nintendo of Japan shrugged off the idea, but they always have--NOJ is

known for passing over potentially valuable markets, and focusing on

selling elaborate junk to young children (Virtual Boy, anyone?). On the

other hand, Nintendo 64 has not been the blockbuster that was hoped for

in the US market; obviously the higher-ups overestimated the market for

$79 games designed for kids when competing systems sell their games for

$39. Regardless, the project Silhouette was spun off from Mirage in an

attempt to broaden Nintendo's market to PC owners, especially those who

liked SNES software. Silhouette had two main developers, myself being

one of them; the Mirage team also worked on large portions. Silhouette

was designed to be a subset of Mirage; its purpose was to play games,

and be as optimized as possible for today's computer hardware, but be as

accurate as possible. No debugging windows, no test modes, no

compiler--just the emulated hardware, with the best possible gaming

experience. Every attempt was made in Silhouette's course of development

to obtain speed without sacrificing compatibility.
In many cases Silhouette was forced to expand to include features that

Mirage did not cope with. For example, Mirage had no sound support

whatsoever--Silhouette includes a full SPC700 APU emulator, designed by

myself and my partner from the ground up. Original versions of

Silhouette also included an encryption scheme to prevent customers from

hacking the software and using ROM images other than the game included

with the emulator; the version you have does not include this

encryption, however.

An interesting note is that most employees at Nintendo had no idea that

other people had already thought of SNES emulation until very recently.

The entire SNES9X cancellation story is a huge mess of bad PR for

Nintendo, but it couldn't be helped--if a Super Nintendo emulator were

released as freeware (along with the heavy ROM piracy that is

characteristic of the Internet), the market for Silhouette would be slim

to none. Nintendo's efforts in combatting ROM image piracy have always

been swift and effective, and frankly I feel nothing but satisfaction

seeing ROM pirates get shut down. Try watching your colleague's or

friend's hours and hours of labor get translated into a ZIP file and get

spread across the Internet and see how it makes you feel. Piracy sucks,

people--don't use Silhouette as a vehicle for piracy.

Unfortunately, as you can see, Silhouette did not make it into stores

nationwide as planned. Within the past few months, Nintendo of America

has undergone some extensive reorganizations and layoffs. Much of the

blame for this rests with the current state of N64 sales (let's just say

we're not doing so well; Sony destroyed us this Christmas). The

high-level executive who brainstormed Silhouette lost his job in the red

tape. After that, it was only a matter of time before the word came down

from NOJ to axe the Silhouette project, still unfinished. That ended my

career at Nintendo, since Silhouette had been my only major project at

Nintendo for several months and I had nothing to do after the project

was gone. I packed my bags and made sure to get a copy of Silhouette on

Zip disk before taking off.
I'm pretty sure that Silhouette is dead at Nintendo. In fact, I wouldn't

be surprised if they denied that it ever existed, at this point. But let

the facts speak for themselves--here's Silhouette, now on your hard

drive. Have fun. Due to the facts behind this program's development, and

the confidential nature of Silhouette, my colleague and I chose to

release Silhouette only under anonymity.

Most of all, please enjoy Silhouette! It's got a lot of hard hours of

work invested into it, and although I know there's a lot of rough

edges--transparency masking, for example, is all wrong, and the SPC700

really needed a little more testing--it really is the best out there.

Special thanks to whoever drew these icons--I lifted them off another

emulator in haste, since I am not an artist.
Future versions of Silhouette may emerge from time to time. No promises,

and no release dates--I have already gotten myself a new job where I'm

extremely happy, but the days are long and you can only program for so

many hours in a day. Have fun, and thanks for trying Silhouette!

[end of readme]

Display More

Quote from Chrille

Also ein Beispiel:

Alle Register (3; A,X,Y) auf den Stack schieben 6502:

pha

txa

pha

tya

pha

Display More

Ein schönes Beispiel dafür, dass der 65816 eben kein 6502 mit 16 Bit ist. Der 65816 Code hierfür wäre:
pha

phx

phy

(Das ist er genau genommen schon mit dem 65c02.)

Es geht hier um den Vergleich 65816 mit 68000. Mach Dir bitte die Mühe für einen fairen Vergleich auch nachzuschlagen, wie das auf den 65816 aussehen würde. Danke.

So toll ist der 68000er im Amiga auch nicht.

Beim 68000 (NICHT bei den Nachfolgern) ist der Speicher von 0x000 bis 0x3ff fest mit den Interrupts verdrahtet. Zu allem Übel liegt da beim Amiga das viel zu langsame Chip-RAM. Das merk man richtig, wenn man 4 Bitplanes Hires einschaltet und sich dann wundert, warum die IRQs viel zu spät kommen, selbst wenn der Code im FastRam liegt. Alles ziemlich vermurkst.

Wäre nett gewesen, statt auf den 68000er gleich auf den 68010 zu gehen. So immens war der Preisunterschied auch damals nicht.

Quote

Was sich gelohnt hätte, wäre ein Modus in dem man quasi eine "virtuelle Instanz" in einer eigenen 64k Bank aufmachen könnte. Dort würde dann Code, der nicht explizit Bank-übergreifend arbeitet, in seiner eigenen Welt laufen, komplett getrennt von anderen 64k Bänken. Man muss dann "nur noch" den Kontextwechsel brauchbar in Software implementieren (anpassen vom Stack, z.B.) und der Prozessor hätte dann Spaß gemacht. Aber so was geht halt nicht, weil DP und Stack nur in den ersten 64k laufen können. Chance vertan.

Hätte man vom 8086 abgucken müssen, da nennt sich so was dann Segment-Register. War eventuell patentiert

Bei den Prozessor-Schwanzvergleichen halte ich mich mal raus.
Meine Präferenz ist ja bekannt... (Ich ziehe übrigens auch den M6809 extremst dem 6510 vor. Motorola hat für mich einfach die wesentlich besseren CPUs gebaut).

Zum Thema SNES: Ich hab mich jetzt auch nicht SO massiv damit beschäftigt, aber man merkt schon an einigen Stellen, dass sie den NES-Codern den Umstieg so einfach wie möglich machen wollten. Das fängt schon bei der Auflösung an, und geht an vielen anderen Stellen im Chipset weiter die sehr sehr ähnlich funktionieren. zB das Palettenhandling.

Und der Erfolg hat ihnen da wohl auch ein wenig recht gegeben.