dmk

Thanks, I'll try it.

And don't forget, 1 cpu cycle = 3 pixels, you only have 76 cycles per line total and 22 before the start of active portion, so you don't have that much time to spare.

Greetings, Just a quick question: can someone suggest sensible TIA values for a short "blip" sound to provide feedback when the player changes menu selection? Thanks PS: I'm making a launcher app to launch other games on my Atari-on-FPGA. So far it looks like this: (see attached) It is a work in progress, graphics and color scheme are subject to change. Any suggestions welcome. Regards, dmk

For audio you can use DTMF It is very easy to produce on 2600 and there are libraries to decode it on the PC side. It won't be very fast but it is going to sound pretty cool, it has the right vintage

FWIW this is what happens inside the chip: Each sprite has its own position counter that gets incremented at every visible pixel and wraps around to 0 at position 159. When it happens, a signal is generated to start drawing the sprite. Other signals are generated at positions 16, 32 and 64 and fed into the logic that generates 2nd/3rd copies of the sprite. Under normal circumstances there are 160 visible pixels and so the counter overflows and the sprite is drawn at the same position on every scanline. RESxx strobe resets the counter to 0 immediately. As there is no wrap around from 159, the sprite is not generated at the new position, but its 2nd/3rd copy will be drawn. Since 1 cpu cycle = 3pixels, it only works with 3 pixel accuracy. When HMOVE is issued, 2 things happen: 1. A flag is set, causing subsequent horizontal blanking to be extended by 8 pixels, reducing the number of visible pixels to 152. 2. A sequence of N pulses (1 pulse every 4 pixel clocks) is generated and injected into the counter clock line. N is the value 0..15 that was written to HMxx register. Now the way these pulses and regular counter clock pulses are mixed together causes some interesting side effects: * If a pulse occurs during blanking interval, the counter is incremented by 1 * If a pulse occurs during visible portion, the clock misses a beat and the counter is NOT incremented by 1 So when you issue HMOVE immediately after WSYNC, the counter is first incremented by N (0..15) during the blank and then not incremented during the first 8 pixels, resulting in -8/+7 motion range, everything works as advertised. If HMOVE is issued at other times, the pulses that occur during hblank are added, and pulses that occur during visible portion are subtracted from position counter, causing all sorts of weird effects depending on the timing. Plus, extending hblank by 8 pixels or may may not happen, causing extra 8 pixel shift. Also the sprites themselves may be weirdly stretched (sprite logic is driven by the same clock as the position counter). HTH, dmk

Hi all, Thanks everyone who replied, that was extremely helpful. I'll try StarBlitz and the interlaced demo as soon as I get my hardware back in one piece Do you happen to know what is the timer register initialized to? My guess is 255 (it would have to be either all ones or all zeroes and if it was 0 the prescaler setting wouldn't matter anyway). And just to confirm, interrupt flag will keep getting re-asserted on every transition from 0 to 255, right? At the moment I'm trying to squeeze more stuff into Spartan-3E which is already full. Ideally I want to add HDMI sound, auto NTSC/PAL switch, auto HDMI/DVI switch and also analog AV outputs (with 1-bit delta/sigma modulation). One way of doing this is through extensive resource-sharing in TIA (there are many repeated blocks). This is a big rewrite and I want to get my TIA logic exactly right before I plunge into it. Implementing DVI/HDMI switch would also involve writing i2c and EDID parsing code in 6502 assembly, what fun! Cheers, dmk

Greetings Earthlings, My first post here. I'm doing a yet another Atari-on-FPGA project just for fun. It runs on Xilinx Spartan-3E Sample Pack. It is a pretty old entry-level board, in particular it does not have enough RAM for a framebuffer, which makes implementing HDMI output 'interesting' (it actually works, still trying to get the audio part squeezed in, so far getting about 105% overmapped) It is a cleanroom implementation, all code is new from scratch. I used official6502 programming specs and Visual6502 as a reference. For the TIA I used schematics which I found on this web site. So far it mostly works. I'm trying to iron out all the little timing quirks. Regarding 6532, unfortunately the datasheet does not tell the whole story. I looked at the code in Stella and z26, and I have a strong suspicion that both are broken to some degree. As I understand the logic goes as follows: Writing TIMxxT: - The value is written to the timer register - prescaler register is cleared - prescaler_max set to xx-1 (0/7/63/1023) - interrupt flag cleared Reading INTIM: - current timer register value returned - timer interrupt flag cleared Reading interrupt flags (what is the mnemonic for this register btw?): - timer interrupt flag returned in D7, edge interrupt flag in D6 - edge interrupt flag cleared At the end of each CPU cycle (after doing the reading/writing as above): if prescaler = 0 then if timer = 0 then prescaler_max = 0 interrupt flag = 1 end if timer = timer - 1 prescaler = prescaler_max else prescaler = prescaler - 1 endif If my guess is correct, then it means: * Writing 0 to timing register sets interrupt flag and starts decrementing timer by 1 immediately * Once expired, timer continues to decrement by 1 every cycle * Every time timer rolls over from 0 to 255, interrupt flag is re-asserted The datasheet says "However, the reading of the timer at the same time the interrupt occurs will not reset the interrupt flag". I wonder if they mean the last cycle with timer=0 or the first with timer=255. TIA: I wonder how accurate the schematics is. I know it says 'preliminary'. I've implemented is in verilog 'as is' as a ground truth for simulation. I found at least 1 obvious error (the polarity of PyGR that controls transfer from 'new' to 'old' player register is reversed). I can also see at least 1 timing glitch (writes to player registers propagate 1 pixel early, causing visible artefacts in basic.bin and bmx.bin). I can fix it by delaying write enable by 1/2 osc clock cycle, but I'm not sure why it is happening. Also the way HMOVE is done is just ugly and I'm not confident at all I got it right especially when HMOVE is issued in the middle of scanline. I wonder if there is a document somewhere that describes all these little details. Also a question about games: what are the min/max numbers of scanlines seen in the wild? Do games often change number of scanlines from one frame to the next? Are there any games implementing interlaced display (262.5 lines/field)? This is important for my HDMI genlock implementation. I appreciate your comments. As I don't have a real 2600 to it compare with, I might prepare a couple of test roms ans ask someone to run them on the real thing. Happy 6502, dmk