EricBall

Especially with the CC2, there should be a sufficient number of people who will be willing to test out anything you code up. Working from an emulator (MESS, EMU7800 or even V7800) isn't that bad. About the only major gotcha is CPU usage during display time. DLLs and display lists aren't that bad, just a pain to create on the fly. The first step is to realize the 7800 DLL has nothing in common with the 5200 (very scary IHMO) display list. Check out http://ericball.atariage.com/balldemo.html for sample code.

If I understand your idea, your concept is to somehow use the SuperCharger RAM to store a 4K bank in a bankswitched game and somehow load the necessary bank into the SC when a switch occurs. Unfortunately, there is a major flaw in your idea - the time to switch banks much be instantaneous. When a bankswitch game accesses the "hot address" (typically $1FF8/9) the next byte read from the ROM will be from the other bank. Bankswitched games may change banks every frame (i.e. using one bank for the display kernel and the other bank for game logic). Banks do not necessarily correspond to levels. And writing to SC RAM is a multiple cycle operation, whether it be via the audio interface (which uses a program in SC ROM), or by manipulating the address bus. If all you want to do is play bankswitched games on a RAM Cart, that can be done without any kind of Bridgestone License (the CuttleCart 2, for example), and it would be easier to create in the first place.

STx WSYNC causes the TIA to hold the 6507 RDY active until the "start" of the next line. This causes the 6507 to halt processing. The timer is part of the RIOT chip (so named because it contains RAM, I/O and a Timer). In my 2600 programs I often include a STA WSYNC in my INTIM test loop simply to make the Z26.log smaller! Just be careful that you calculate the TIM64T value correctly or INTIM will start counting the number of cycles since the timer expired!

As per the development diary The other twist is I had Chad ship my CC2 to my grandmother in Cleveland Ohio, whom I will be visiting in August, to avoid cross-border shipping issues. But it is nice to hear that someone is anxious for updates.

The source code for http://www.atarihq.com/danb/files/a78sign.zip has a decent description of the 960 bit Rabin Digital Signature used for the a7800.

You mean like http://www.hauppauge.com/html/usb_data.htm? Search for USB Video Capture and you will find what you are looking for.

Not mine, but thought you all might be interested: COMPUTER SPACE VIDEO GAME Item number: 3288856772

Two sprites on a tile row, one sprite repositioned per row of tiles. Intelligent flicker routine already done and working.

Don't worry about it. I've just gotten the kernel and the sprite position to repositioning table code done. I'm a long way from having anything playable and thus generating demand for a working level editor.

This is the code from SpaceWar! 7800 for handling the fire button, which you should be able to adapt to handle SWCHB. FIRE_A LDA INPT4,X TAY ; save result in unused register EOR FIRE_1,X; quick compare BPL FIRE_B ; same as last frame STY FIRE_1,X; save if different BNE FIRE_Z ; and exit FIRE_B TYA ; restore current value EOR FIRE_2,X; quick compare again BPL FIRE_Z ; no change STY FIRE_2,X; save if changed TYA ; set flags BMI FIRE_Z ; up (X is used because I use the same code for both players). For SWCHB you will need to mask off the desired bits and change the BPL/BMI to BEQ/BNE. And I appologise to those programmers that prefer lowercase, but uppercase ASM is a habit I've had since I started on the CoCo/6809 where we didn't have no stinking lowercase.

int main(int argc,char *argv[]) should get rid of the warning, however, issues with what main returns shouldn't cause a seg fault. You may need to look at the coredump using your debugger (dbx?) to see where it is dying.

The Skeleton in Skeleton+ isn't truely animated, but it does take up a large part of the screen.

The STA RESPn doesn't take effect for several cycles after when you expect it. Trust Z26.log, it's correct.

No, there are no data structures; only data stored in memory. How the program choses to interpret that data is up to the programmer. Of course, you could get even more literal and talk about bits or electrical signals, but some degree of abstraction and equivalence is necessary to stay sane.

My point is it probably required extra transistors for CMx to not update V, and all indications are the 6502 design team didn't waste transistors without a good reason.

I agree with Dan, learning 6502 is the first step. Personally, I found the lack of 16 bit index registers took some getting used to, not to mention the minimalist instruction set. The MARIA GPU is unique and the documentation is rather sparse. However, the 7800 programming community is getting bigger and some sample code has been created. http://ericball.atariage.com/balldemo.html For me, it took about 3 months to learn enough about the 7800 to put out my first demo, and another 6 months for the first build of SpaceWar! 7800. But thats after doing lots of 6502 programming for Skeleton.

Jedd, it sounds like you are missing some basic concepts around registers and memory. The 6502 has 3 "general purpose" registers: A, X & Y. (And 3 special purpose registers: PC, SP and PS.) All instructions use at least one of these registers. EOR #$FF means "take the value in the A register, bitwise exclusive or it with the value $FF and store the resulting value back into the A register". PF1 is a TIA register which is memory mapped to address $000E. So a STA $000E instruction stores the value in the A register into TIA register PF1. Other CPUs have more registers and may specify more than one register per instruction.

Sorry, I was wrong about the Compare instructions. (I've modified my post.) I assumed that since CMP is so close to SBC that it would also affect the oVerflow flag (and didn't check my own refs ). Wierd. I wonder why the designers decided to explicitly exclude it. Maybe there is a well known routine which needs that behaviour. Sorry Erik, we were both wrong.

One of the simplest Pseudo-Random Number Generator (PRNG) is a Linear Feedback Shift Register (LFSR). This is a routine which takes the last value of the PRNG, shifts it by a bit, then uses the bit shifted out to determine whether to XOR the PRNG with a value. Here is an example: ; simple 8 bit LFSR (RANDOM is a byte in Zero Page RAM) RAND LDA RANDOM BEQ XSEED LSR BCC SRAND XSEED EOR #$A9 SRAND STA RANDOM RTS In Skeleton+ this subroutine is called once per frame including during the title and ending screens. Then the code just samples RANDOM as required when a random byte or bit is needed. Some games use multiple LFSRs or incorporate additional "random" inputs like cycling the LFSR an additional time when the player presses a button. But I figure that since the LFSR is "free running" that when the game is started is random enough. LFSRs do have some negatives. First, they have a null value (typically all bits set or cleared) that will not cycle properly. That is why my routine has the extra BEQ at the begining to avoid this problem. This also means that RANDOM will never be zero once the game starts. Simple LFSRs are also predictable and will tend to have sequences of certain values. Depending on how you use your PRNG, this may not be a big issue. Skeleton+ doesn't use the PRNG every frame and typically only uses bits 6 & 7, so this wasn't a concern for me. (But this is why LFSRs are snubbed by the crypto boys who want "real" random number generators.) LFSRs can also be used for other things - like map generation in PitFall!

Wrong, SBC does too. (See http://www.6502.org/tutorials/6502opcodes.htm for a good 6502 opcode list.) ADC, BIT, CLV, PLP, RTI and SBC all update the oVerflow flag. CLV clears it, BIT grabs bit 6 from the memory location, and PLP and RTI pull the entire Processor Status (aka Flags) Register from the stack. See http://www.6502.org/tutorials/vflag.html for more on the oVerflow flag. On a related note, IN_ and DE_ also do not change the Carry bit.

Bad habits like GOTOs, right? Guess what 6502 ASM uses? Gotos. Bad habits like global variables, right? Guess what 6502 ASM uses? Global variables. Versus good structured programming habits like nested subroutines, dynamic memory allocation and recursion, right? Guess what almost never gets used with 6502 ASM.... "Good habits" and "bad habits" are largely a matter of context and convention. ASM programming is about wringing out as much CPU power and efficiency as possible (otherwise you would program it in a higher level language). So anything which uses extra cycles or requires additional bytes is often avoided or recoded. However, some habits, like descriptive variable names, informative comments and sensible documentation, are always applicable no matter the language.

Weird, sounds like something marginal in your 2600. Overheating maybe?

What do you mean by "flickers on and off"? Which style 2600 do you have?

The way that the 2600's GPU, the TIA, works is it automatically creates each TV scan line using the data stored in internal registers. If the game wants to change what is displayed on the screen, it must update those registers appropriately. The game is also responsible for keeping track of the number of scanlines which have been displayed. Once 259 or 309 lines have been displayed, the game changes a bit in one of the TIA registers for 3 lines. This changes the TIA output and causes the TV to start drawing at the top of the screen. In other words, a magic cartridge adapter can't do it.