[phx]

Originally Posted by Oktai-Wanda

1. I'd like to write a simple (but perhaps graphically hardware-demanding) Amiga 500-compatible game at some point but I would like to do the programming without any real Amiga 500 hardware. In other words, I would like to do the programming either in Windows or in an emulated Amiga environment (where the host OS is Windows).

Cross development for the Amiga under Windows as a host OS is possible. Portable C compilers, like gcc or vbcc, can be configured as a cross compiler for host=Windows and target=AmigaOS.

For a portable, Devpac-compatible, assembler see here: http://sun.hasenbraten.de/vasm/

Furthermore, if I follow the usual practice of programming games for the Amiga 500, should I write my stuff in a low-level language or straight in assembler?

Depends on the type of game. A fast action game definitely requires you to write it in assembler and to program the custom chip hardware directly. You will only need an assembler and the Hardware Reference Manual in this case.

An adventure, or similar games, could also be written in C or Basic or whatever you like. But also keep in mind that high level languages tend to consume much more memory, which is limited on a stock A500.

Notice that I would like my game(s) to work on a real Amiga 500 as well.

You will absolutely need a real Amiga 500 then.
You may find a friendly person to test your game on real hardware, but when you have to debug it, then it is best to own the hardware.

I'm in the same situation. I wrote Sqrxz and Sqrxz2 for Amiga500 with a cross-assembler and UAE on my Pegasos2. But testing it at least once every day on real hardware was mandatory.

Currently I'm writing a new Jump'n'Run (Solid Gold).

2. I would also like to see if it could be possible to make any changes to existing A500 games and programs.

You can either patch the code directly with a monitor program (or an assembler IDE, like AsmOne) or disassemble it with a reassembler.

Only the reassembler will allow you to make bigger changes in a comfortable way, but in both cases you have to invest a lot of time to understand the 68000 code of the game.

This will be extremely frustrating when the original source was not in assembler, but in a high level language, like C.