brainwagon

I ordered an EPROM programmer from mcumall.com (~50.00), some of the raw boards from atariage (~8.00) and a bunch of AT28C64 EEPROMS from digikey.com (~2.00), took the innards out of an old Super Breakout cartridge, printed a new label using a color laser printer, et voila! Might be a bit late to get them all delivered in time for christmas though.

It is indeed. I wrote a simulator in C back when I read Simon Singh's The Code Book and was working on breaking his 10 challenge ciphers for a $10,000 prize (I got seven). Stage 8 required a working Enigma emulator, so I rewrote the C code in 6502 and then worked on the interface (which still requires a bit more work, but all the bits are there). It emulates the three rotor machine, including the Stecker plugboards. Should be fun when it is all done. Someday I suppose I'll have to write a real game. :-)

What do you all think? I'm actually going to take my first real Atari 2600 program, burn some roms, put it in a cartridge, use this as a label, and then wonder why everyone arounds me wonders if I've gone off the deep end. :-) I haven't had this much fun programming in a while.

Thanks for all the hints. Here's another question: I'm using Stella (of course) to test my game. Is there some good way to make sure I get 262 scanlines per frame exactly?

As a relatively new programmer to this platform, I'm working on my first program which ultimately I want to run on real Atari hardware. As such, I'm trying to do as much development using emulation as humanly possible, with the idea that I may have to burn this only a couple of times. I'm curious though: for NTSC your program must generate 262 lines, normally divided as three vertical sync lines, 37 more in the vertical blank, 192 visible, and 30 in the overscan. Is there a hidden gotcha in using slightly more in the visible area (other than possibly clipping the bottom?) I'm running short on scanlines to accomplish all the data that I'm trying to dump on the screen, and I'm wondering if a significant reorg might be required or if I can let it slip. Incidently, the project isn't really a game: it's a simulation of the WWII German crypto machine Enigma. The encoding and decoding work, and generate text which can be deciphered with my reference C implementation, I'm mostly working on interface and graphics. I use the 48-pixel wide trick to get six characters on a line. Currently I display two keyboard layouts (as a 5x6 matrix) and use the ball to implement a cursor. There are also six character input and output buffers. I suppose I could eliminate the output keyboard matrix (no real need to keep it), but I kind of like the trick.

This was exactly the information I needed. I find it a bit surprising that this useful information isn't in any of the tutorial information that I've found so far. Your presentation (and routine) are probably just about the most clear that I've seen. Hmm. perhaps I should write a tutorial myself. :-)

I'm having some difficulty understanding horizontal positioning code, in that it doesn't behave like I expect. I began by looking at the "Revolutionary Horizontal Positioning Code", but that didn't work as expected, and so I started running some experiments on my own. This only serves to confuse me more. Here's what I think, and what I found out. I'm trying to position a player flush with the left most edge of the playfield. The playfield begins 68 TIA clocks into a scanline. So, I execute the following code sta wsync nop <repeated 10 times, for 20 cycles> sta resp0 By my count, this should execute 23 cycles or 69 clocks into the line, leaving one blank space (which presumably I could move by loading hmp0 with $10 and executing an hmove). But instead, I get the player several pixels in from the left (see the attachment). Am I fundamentally missing something about how the cycle timings work? Is there some edge condition that I'm unaware of? Until I can figure out how these simple examples work, it seems understanding the more complicated revolutionary stuff is just a pipe dream. Thanks for your patient instruction.