use interrupts.

My personal reccomendation would be to skip DOS altogether. The skills devolped by doing ASM DOS programming by and large will not transfer to NES development; those few skills that will transfer will be learned just as easily by starting off with the NES (presuming you're using an emulator; getting code to run on a real system is a different matter entirely). The NES and the PC use entirely unrelated CPUs on wildly different hardware architectures with completely different quirks and underlying assumptions and different coding standards; doing NES development with a background in DOS ASM coding may as well be starting from square one.

I agree with Anthony, but I'll give you some background information so you can make up your own mind.

DOS real-mode programming has the advantage that you can make a decent 2D game very easily in a couple of hours. There's no window-management or message handling to worry about; just have a simple high-level description of your game in Pascal or C/C++ with touches of assembly for switching to mode 13h or getting input. However, you're limited to a small number of screen modes (13h is probably the best option, and that's 320x200 pixels with 256 colours), you have very little memory to work with, and audio can be difficult, especially for Windows NT people.

NES programming is extremely different to DOS programming. Whereas DOS, despite severe limitations which render it obsolete, is a pleasure to work with, NES is an absolute nightmare. The assembly language is completely different (and I consider the instruction set incomplete), you have only one general-purpose register, which is merely 8-bit as I recall (so all numerical computations take place between register and memory, and most simple calculations need to be done in 2 tricky steps, because 8-bit numbers aren't that useful); high-level languages are not an option, and the memory behaves very strangely. To its credit, it's easy to initialise, and it does have dedicated graphics hardware to handle all your rendering for you, but this limits your flexibility.

SNES is like NES, but with much better capabilities, more flexible graphics hardware, more thorough instruction set, and better-and-bigger registers, but otherwise it's mostly the same, and a bit of a pain to initialise. DOS, NES and SNES are long-dead, so learning them at this point is unlikely to advance your career.

If you really want to go the route of retro games, the best option in my option is the GBA or DS. Download DevKitAdvance GCC and Visualboy Advance, and then visit http://www.gbadev.org if you want to go in this direction.

Quote:Original post by Jaywalk
I agree with Anthony, but I'll give you some background information so you can make up your own mind.

DOS real-mode programming has the advantage that you can make a decent 2D game very easily in a couple of hours. There's no window-management or message handling to worry about; just have a simple high-level description of your game in Pascal or C/C++ with touches of assembly for switching to mode 13h or getting input. However, you're limited to a small number of screen modes (13h is probably the best option, and that's 320x200 pixels with 256 colours), you have very little memory to work with, and audio can be difficult, especially for Windows NT people.

NES programming is extremely different to DOS programming. Whereas DOS, despite severe limitations which render it obsolete, is a pleasure to work with, NES is an absolute nightmare. The assembly language is completely different (and I consider the instruction set incomplete), you have only one general-purpose register, which is merely 8-bit as I recall (so all numerical computations take place between register and memory, and most simple calculations need to be done in 2 tricky steps, because 8-bit numbers aren't that useful); high-level languages are not an option, and the memory behaves very strangely. To its credit, it's easy to initialise, and it does have dedicated graphics hardware to handle all your rendering for you, but this limits your flexibility.

The 85xx series 8502, 8504, 8510 was used in many systems made that time. Good examples are the apple II and the commodore 64/128. The cpu is a good 8 bit cisc design with 16 bit address support. Programming them was way easier than today's 8bit PIC microcontroller line.

Quote:SNES is like NES, but with much better capabilities, more flexible graphics hardware, more thorough instruction set, and better-and-bigger registers, but otherwise it's mostly the same, and a bit of a pain to initialise. DOS, NES and SNES are long-dead, so learning them at this point is unlikely to advance your career.

If you really want to go the route of retro games, the best option in my option is the GBA or DS. Download DevKitAdvance GCC and Visualboy Advance, and then visit http://www.gbadev.org if you want to go in this direction.

For a completly home made design, you can use any PIC chip, but some level of electrical engineering knowledge will be required to design and solder the hardware together. But the result can be as good as any old console. For pure software development, I have to agree that the nintendo ds is the best option. (at least it's a supported system) For a cheaper solution, most newer mobile phones have some kind of game platform. (either java or mophun)

For the original cursor question, check Ralph Brown's Port List (bundled with the interrupt list) for the cga/ega/vga cursor position registers. (you have to write the offset from the start of the screen in characters to 2 registers to position the cursor) To access video card registers, one has to fiddle with the i/o ports of the graphics card, and since the x86 i/o and memory maps are distinct and c only supports memory reads/writes, one has to write assembly code (or at least assembly macros) to do it.

Viktor

Quote:Original post by F-Kop
I already know most 81686 and 6502 asm. it's the low-level game programming experience that i'm aiming for.

You're still barking up the wrong tree! There is NO reason whatsoever anybody would need to learn 16-bit PC BIOS programming unless you're trying to write a bootloader.

If you want to learn 6502 programming you could use a C64 emulator along with something like Turbo Assembler. Current PC's are fast enough to run C64 machine code in real time, so there's almost no limit to what you can do (within the boundaries of the C64 hardware, of course).

I don't know if it's possible to do, but I found this with google

MEM 0040h:0050h - VIDEO - CURSOR POSITIONS
Size: 8 WORDs
Desc: contains row and column position for the cursors on each of eight
video pages
SeeAlso: MEM 0040h:004Eh,MEM 0040h:0060h,INT 10/AH=02h


http://oopweb.com/Assembly/Documents/InterList/Volume/MEMORY.LST
http://gd.tuwien.ac.at/languages/c/programming-bbrown/advcw1.htm