• Advertisement
Sign in to follow this  

dos & asm

This topic is 4241 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've learned that the character buffer is at b8000h, but is there an address somewhere that you can use to move the cursor? I know there's an interrupt, but an address would be better.

Share this post


Link to post
Share on other sites
Advertisement
dos died a long time ago. sorry... we've all moved to the 21st century.

Share this post


Link to post
Share on other sites
well i haven't ;D
kidding, but i'm programming for 16 bit dos in asm to get practice with lower level programming. i will need it to develop for nes. (also old ;D)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
NES doesnt use x86 instructions. I believe that CPU was a derivative of the 65c816 processor which is way over in motorola land.

Share this post


Link to post
Share on other sites

VIDEO - SET CURSOR POSITION
AH = 02h
BH = page number
0-3 in modes 2&3
0-7 in modes 0&1
0 in graphics modes
DH = row (00h is top)
DL = column (00h is left)
Return:Nothing


from Ralph Brown's Interrupt List (quite famous). http://www.ctyme.com/intr/rb-0087.htm
I can also recommend TechHelp. http://margo.student.utwente.nl/el/pc/help/techhelp.zip

Share this post


Link to post
Share on other sites
Writing directly to the graphics memory is indpendent of cursor positions and such. It is like a framebuffer similar to video devices.

If you want to draw text where the cursor is, you should use dos/bios interrupts instead of direct writing to the memory.

Are you sure you want to program games for the NES. You can write NES-like games for modern environments. I don't know how well documented is the NES platform, but it sure isn't like DOS asm programming.

I recommend learning at least some assembly programming, anyway. It might prove useful when trying to find a job or doing low-level stuff.

-Riku


Share this post


Link to post
Share on other sites
Yeah, RichardoX is right. If you are in say 80x25 mode, you have at b800:0 80*25 pairs of bytes, with one byte for the character and one byte for color and blinking (iirc). 0 is the top left, then every byte higher move you to the right, then to the next line on the right, etc. So you don't need a cursor indeed.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
NES doesnt use x86 instructions. I believe that CPU was a derivative of the 65c816 processor which is way over in motorola land.


it uses 6502

Quote:
Original post by roel
Yeah, RichardoX is right. If you are in say 80x25 mode, you have at b800:0 80*25 pairs of bytes, with one byte for the character and one byte for color and blinking (iirc). 0 is the top left, then every byte higher move you to the right, then to the next line on the right, etc. So you don't need a cursor indeed.


but i need the cursor to indicate where input will be echoed. i'll use an interrupt for it if i have to, but i prefer addressing memory directly.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
I already know most 81686 and 6502 asm. it's the low-level game programming experience that i'm aiming for.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Quote:
There is NO reason whatsoever anybody would need to learn 16-bit PC BIOS programming...


How about for the sake of being interested in how something works?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement