Tom

bruce: 6502.org has some 65xx data sheets: http://www.6502.org/documents/datasheets/m...s_6532_riot.pdf

just strip off the first 128 bytes, which form the a78 header (for instance with dd)

certainly. and iirc the code is anyway prepared to be changed to f6 bankswitching in case we run out of rom space. btw, i haven't worked on my stuff (damage / status bar) neither, due to university projects, but i'm still into this project.

the most useful information about ntsc/pal frame timing i've found comes from some demo from eckhard stolberg (i think it's from the backdoor demo source) ; Differences between the NTSC and PAL 7800 consoles' output: ; NTSC PAL ; 15 15 automatic VBLANK lines ; 25 33 output lines, that can't be seen on many TVs ; 192 228 actual display lines ; 26 32 output lines, that can't be seen on many TVs ; 4 4 automatic VBLANK lines ; ; 262 312 total number of lines per frame ; 243 293 total number of DMA output lines per frame ; 60 50 frames per second ; ; So to make a NTSC game run properly on a PAL console, you can simply ; set up 25 extra blank lines before and after the normal NTSC display. ; Also you would have to adjust anything that is timed by counting the ; number of frames, since PAL consoles do less frames per second than ; NTSC consoles. The following routine detects if it is running on a ; NTSC or a PAL console by counting the number of scanlines per frame, ; so that you can make your game compatible with both TV standards. maybe that helps you to find the error in your display stuff.

use bruce tomlin's new sign7800, which doesn't need any additional libraries and compiles just with a simple gcc -o sign7800 sign7800.c you can get it from this thread: http://www.atariage.com/forums/viewtopic.php?t=52592

i heard "teach yourself 2600 programming in 20 minutes" was very good.

well, the emulator doesn't care about the encryption itself, but the 7800 bios you're using with the emulator does... anyway, that was just a suggestion, and i'm fine with using two different tools, one for signing and one for creating the header. oh, it's not like people waited with writing header tools there exists dan boris' 78hdr, and i'm using an own tool: ftp://ftp.profzone.ch/vantage/members/kil.../mka78-0.99.zip

now if one added support for creating a78 headers, then there would be one tool that: - compiles out of the box, just about ony any machine where a c compiler is available, and without the insane crypto library. - can sign rom images - optionally adds a78 headers in case you want to test on mess

now *that's* nice. great work.

well, he mentioned eric isaacson, who is the author of A86, so i think he's talking about x86 assembly

well, as i said, i think learning x86 asm if you want to do 65xx programming is nonsense. anyway, nasm is a good, free x86 assembler: http://nasm.sourceforge.net

i'd say it's bullshit. honestly, you don't want to know x86 asm. true, once you're familiar with asm programming (doesn't matter on which cpu) learning another cpu takes only a little time. on the other hand, if you've never done any asm programming you can directly start off with 6502 programming.

give it away for free to a homebrewer

a very nice starting project is a chip8 interpreter, which can be hacked together in a few hours. i just don't know any chip8 game that's fun to play (except maybe ant)

DracIsBack: http://www.atariage.com/forums/viewtopic.php?t=46375 in case you don't know what robotfindskitten is - don't be disappointed anyway, this is a buggy ntsc version and pretty much unplayable, since moving up doesn't work for some obscure reason on real hardware. i'll be soon working on that.

well yes, it's an ntsc binary, and on a pal machine there's of course garbage at the end of the screen (and the display is shifted up), because the display list list doesn't contain enough scanlines. that's by design (the instructions even say that select aborts the game, iirc), but i agree, it's stupid. i don't know why i chose select instead of reset

and here are some neat 6502 resources (also check out the source code section): http://www.6502.org/tutorials

no. i'm currently building a ramona cart, so that i can test on real hardware myself. and i still don't know what garbage on the screen you were talking about in the other thread you told me it happens on emulators too, but i don't see anything (i'm using mess 0.82b)

i found cc65 to be very useful. especially construction display (list) lists is much more convenient. the quality of cc65's code isn't terribly good, though. when i find some time i'll put the robotfindskitten 7800 source code onto the net, but it needs to be cleaned up a bit first.

btw, if you look at the run_z26.bat which comes with the hsr demo then you'll see that z26 is started with the -f switch, which causes it to blend between frames. this simulates the afterglow of a tv screen, which makes the flickering less apparent.

flickering. say you want to display 12 sprites in a row, but you can really only do 6, so you could display six sprites in odd frames, and the other six sprites in even frames: 0 = player 0 1 = player 1 odd frame 0 1 0 1 0 1 even frame 0 1 0 1 0 1 (sprites shifted 8 pixels to the right) and on the screen you will see 001100110011 now this flickers awfully. homestar seems to alternate the sprites on each scanline, which gives a better result. but then you have the problem that you have to move the sprites every scanline either 8 pixels to the right or to the left, but using HMOVE you can only move max. 7 pixels to the left (8 to the right is possible). anyway, moving 8 pixels to the left can be done using early HMOVE trickery.

you aren't talking about the 2600, are you ?

looks much better now, and still pretty 3d-ish

http://www.xmission.com/~trevin/atari/6502...2_insn_set.html search for jam on that page. i guess 1822 is the address where the instruction occured.

ah, i don't know anything about edtris. anyway, sometimes, if an emulator is not 100% accurate, it can be possible for a program to detect wether it's running on real hardware or not. for instance, most (if not all) gba emulators don't emulate the prefetch queue of the arm cpu. this can be detected (you'd write a self-modifying routine that modifies code that is on real hardware already prefetched, and thus the code change has no effect on hardware, but on the emulator it has). now if emulators get more accurate, such copy protection schemes stop working.