EricBall
-
Content Count
2,362 -
Joined
-
Last visited
Posts posted by EricBall
-
-
The main issue with hi-res sprites is the lack of palletes. You're limited to 2 in this mode. So, that's a total of 7 colors possible (background, plus 2x3-color).This is true only of 320D mode. 320B mode has the same color capabilites as 160A (although the bit order is different).
However, in this mode when objects overlap, there is no transparency (so any overlapping objects will display the background color to show around the sprites, causing crappy-looking results). If you turn transparency on to circumvent this issue, you lose your resolution (back to 160), and in addition, you lose some colors in your palette (now limited to 5 colors, IIRC).Just to clarify - positioning and transparency still use 160 resolution boundaries even in 320 modes. So 00 is transparent, while 01 is background/color 1. It means that sprite edges need to use 160 resolution, while the interior can use the background color as well.
-
since the 7800's 160x200 mode is (apparently) the only one that directly supports multicolor sprites.Not so! The 7800 has four 320 modes:
320A is an 8 pixel 2 color mode (on/off), though each sprite may have a different palette (1 of 8 )
320B is a 4 pixel 4 color mode (just like the normal 160A 4 color mode) from 1 of 8 palettes
320C is a 4 pixel 2 color mode, but each sprite may use 2 palettes
320D is an 8 pixel 4 color mode, but some of the color bits are shared and only 2 palettes are available
It is possible to flip between A&C and B&D modes for each sprite. The 320 modes also have some quirks like positioning is still done at 160 resolution and transparency only works if both 160 half pixels are off, otherwise off gives the background color.
I also just realized that you couldn't do a fully tiled background with either 320B or 320C; there isn't enough time each line for the GPU to draw more than the background.
-
Skeleton and Skeleton+ use a simple LFSR RNG which gets cycled once per frame (including during the title & end screens, so the initial state is unknown). The Skeleton "AI" uses the RNG to determine whether to turn at a branch in the maze when it isn't actively "chasing" the player. The RNG is also used to determine the damage a player's shot does to the Skeleton, and in Skeleton+, how much damage the Skeleton does per "touch" to the player.
I would expect that there are many "deterministic" titles where player motion, actions & timing solely determine the outcome of the game. e.g. the ghosts in the Pacman arcade game follow a pattern or chase the player.
I'd say the games like Video Chess are the only ones that don't have randomnessI suspect that Video Chess does have a RNG to avoid having the game play the exact same moves all the time. This could be tested by playing several games and seeing if the computer will follow the same move sequence.
-
Clarification of my own point: Processing the signal after it comes out can make a stereo signal, i.e. with a chorus effect or something, but it won't actually split the audio into separate distinct channels.Let me see if I can explain this simply:
The TIA in the 2600 (and 7800) has two independent audio channels each with volume, waveform and frequency controls. The output of each channel is a separate pin on the TIA.
On the 2600 motherboard, the two pins are electrically connected before they are modulated into the RF video signal. So if you are using the RF output, you only get mono sound.
The typical 2600 A/V mod, the audio signal is tapped on the motherboard, so again you get mono sound. However, if you disconnect the two pins on the TIA from the motherboard and tap them directly you get the two channels separately.
For some games the two channels are used to generate a true stereo sound (e.g. Skeleton plays same sound but different volume from the two channels). Other games use the two channels in a similar but distinctive (e.g. Combat has a channel assigned to each player) or related (e.g. Synthcart) fashion. Finally, many games use the two channels very differently (e.g. Pitfall 2 has music on one, SFX on the other), so will sound "strange" when in stereo.
-
Do EEPROMs and OTPs suffer from bitrot too?Based on Pitfall Harry's excellent explanation, EEPROMs will be subject to the same problem. Some types of OTPs may not be. Those which are EPROMs without a window will be; while those which are based on fuses (so programming causes an actual physical change, not just an electrical one) should not be.
Check the datasheets for more info.
-
Would using a clear shell speed up the bit rot of an EPROM? Since the shell is clear it seems like the UV rays could get to the EPROM easier.Typically you put a small label sticker over the window once you have finished programming the EPROM (properly labeled with a description of the contents of the EPROM). If you are really worried, use an EEPROM (electrically erasable) or an OTP (one-time programmable) which don't have windows.
-
Can you just load a program into internal RAM ?A typical 7800 game is 32K or more, while the 7800 has 4K of internal RAM. RAM also gets used to build the sprite display lists for the MARIA GPU.
-
Should throw up an "Illegal Addressing Mode" error.The bigger question is how the following should be handled:
TMP EQU $80
BAD LDA TMP,Y
Since a typical 6502 assembler considers all equates to be 16 bit integers. Thus LDA ZP,X is really just a special case of LDA ABS,X.
-
7 cycles?ldy #1 ; Immediate addressing = 2 cycles
lda $00FF,y ; Absolute, Y addressing = 4 cycles + 1 for crossing a page boundary (from $00FF into $0100)?
Correct. This is why it is supremo important to ensure that any lookup tables used in timing sensitive code (kernel) don't require calculations which cross page boundaries.
For most 6502 instructions you can figure out the number of cycles required by counting memory accesses and remembering a couple of other rules: 2 cycle minimum, +1 for crossing a page boundary, +1 for branch taken. (There are exceptions of course...)
ldy #1 = 1 cycle to fetch the opcode + 1 cycle to fetch the immediate value
lda $00FF,y = 1 cycle to fetch the opcode + 2 cycles for the address + 1 cycle for the carry + 1 cycle to get the value from memory
-
then the background colour would change after the first TIA pixel has already been drawn, because the STA COLUBK would finisch it's write cycle at CPU cycle 23 (which is TIA cycle 69, which is one TIA cycle after the horizontal blank period).Thanks, that was the info I was looking for.
-
What a pain in the butt, Putting a 50/60hz switch alone is one of the easiest mods to do on the majority of consoles. Changing the hz on the appropriate pin is not feasible? Coming from a pal country it is very common for people to do this. Hmm, av mod plus 60hz,,, Another fried machine 4 me?Unlike the TIA in the 2600, the 7800 MARIA handles the number of lines per frame. There are also differences between NTSC and PAL video beyond the 60Hz/50Hz frame rate.
-
This is correct. If you change a playfield register while the third playfield pixel is currently being displayed, then the first three playfield pixels will be taken from the old value in the playfield register, and the last five playfield pixels will be taken from the new value.Which TIA cycle does the 6507 write cycle "complete" on? The last third, I think, right?
-
(I'd like to see what could be done with a 6502 running at 3X. There were some experiments done by someone on Stellalist and the concensus was that it wouldn't work...)FYI, the 6502C in the 7800 runs 50% faster than the 6507 in the 2600 (1/2 colorburst, 1.78MHz vs 1/3 colorburst, 1.19MHz), but it drops back to 1.19MHz when accessing the TIA (which the 7800 uses for sound & paddles/buttons and 2600 compatibility mode).
-
Find a 6502 cycle-timing referencehttp://www.6502.org/tutorials/6502opcodes.htm
Bonus question, how many cycles does the following require?
ldy #1 lda $00FF,y
-
And since it doesn't contain a transistor level copy of the 6507, each instruction (documented or not) has to be "programmed" individually.Are you sure?
Unlike the TIA, there are no transistor level schematics available for the 6502. So any VHDL (the programming language for FPGAs) has to be based on functional documentation. And any transistor optimizations may be different becuase FPGAs are not simple NMOS devices.
-
I would think that a specific microprocessor would execute any instruction, undocumented or not, the exact same way every time.I've seen a document somewhere on the 'net done by some C64 programmers that attempted to document the behaviour of all the undocumented instructions. They were largely successful, but in some cases undocumented instructions can cause multiple sources to drive the same bus, which can cause unpredictable results due to manufacturing differences.
If Stella doesn't handle undocumented opcodes, I really see that as a failure on the part of that particular emulator.I agree with you there. But note I specified MacStella, not Stella or StellaX. The problem is with that emulator only. (Not to say that all emulators are able to emulate all undocumented instructions either.)
As for VCS on a chip, it has a transistor budget too. And since it doesn't contain a transistor level copy of the 6507, each instruction (documented or not) has to be "programmed" individually.
My observation about some games not working on some VCS is meant to indicate that even with "identical" hardware, micro differences can and do exist which may have a much larger impact.
Goodness, what a discussion for what is supposed to be a beginner tutorial.
-
Sorry if I went off on a bit of a rant back there.
Ok, I understand why it wasn't recommended to use the undocumented/illegal opcodes when the machine was still in production. But, correct me if I'm wrong, AFAIK there are no 2600's that have problems with these opcodes, right? And any new hardware/software that can run 2600 programs is going to have to implement these opcodes in the exact same way, right?Personally, I don't see the problem -- unless there are 2600s out there that just won't work with them...
I agree with Thomas for the most part. Undocumented opcodes like NOP ZP and LAX should be okay to use for the most part, but there are others with far less predictable results (and typically less usefullness) which should probably be avoided.
But on the other hand, apparently MacStella doesn't handle undocumented opcodes. And who knows what the VCS on a chip will and will not do.
And as for all 2600s being the same, there are still occasional reports of problems with various games on certain 2600s.
-
Although Pitfall Harry has done an exceptional job explaining how SLEEP 2n+1 and NOP 0 work, I have to disagree with his statement that NOP 0 is merely undocumented through some kind of oversight.
Let me explain. Back when the 6502 was designed (although I wasn't there, I do have a BASc in Computer Engineering), the team first came up with a list of instructions / capabilities they wanted their microprocessor to have. This wish list would have been whittled down (or beefed up) depending on the transistor "budget" they had to work with.
But one of the important things that was done was to arrange the instructions into patterns so bits (or combinations of bits) in the opcode could be used to select registers, addressing mode and instruction type. This simplification reduced the number of transistors; a very good thing.
But this also meant that the effect some of the undefined opcodes could be defined by inference. So opcode $04 is effectively NOP ZP, a two byte instruction requiring three cycles and not changing any registers, including the status register. There are more bizzare opcodes like $A7 (aka LAX ZP), which loads both the A and X registers simultaneously from zero page memory. And some simply crash the processor.
However, because these instructions are not documented, the chip maker was under no obligation to ensure they worked, no matter how useful they were. This was particularly true for later revisions or enhancements. It was common for a chip maker, or cloners trying to add value, to add new instructions to later versions by using those "unused" opcodes.
Personally, although NOP ZP does waste 3 cycles, there are other documented 2 byte instructions which accomplish the same thing (especially on the 2600), so I will use them instead.
-
Before creating new hardware, maybe us homebrewers should first start exploring the capabilities of the Pitfall 2 chip. At least using that would be as "authentic" as e.g. using the SuperCharger RAM.How complicated would it be, to produce new boards based on that chip?
I belive the Pitfall 2 chip was made like most of the other bankswitched games: with the control logic included as part of the masked ROM. So you can't re-use a Pitfall 2 chip, since there is no way to modify the ROM parts of the chip or reuse the control logic.
However, there is no reason that you couldn't put the logic (documented in the patent) into a modern FPGA, and put that into a cartridge along with the code and graphics EPROMs. (See the Cuttle Cart for an example of what an FPGA can do & cost.)
Patent #4,644,495 is an interesting read. However, some features almost require a disassembly of Pitfall 2 to understand how to use them. But my guess is, other than the sound oscillators, the features are only applicable to some games and would be useless in most cases.
Supercharger games are an untapped market too.
-
Just for the heck of it, I put together the following tool. You feed it an a78 binary and it will create a PPM file. It assumes a 2 bit per pixel mode. Each page starts a new row, so each row is 1024 pixels wide.
I used IrfanView to vertically flip the PPM and turn it into the attached GIF.
Remember that the 7800 has 8 palettes.
Source is included.
-
The 7800 is fairly easy to understand: everything is a sprite.
The MARIA GPU has 25 colour registers (8 palettes of three 8 bit colors plus background) and 7 other registers (not including the TIA/RIOT registers shared with the 2600).
(I'm going to use my own terms for this explanation for ease of understanding.)
The MARIA processes a list of zone headers pointed to by two registers (pointer MSB & LSB). Each zone header contains a pointer to a list of sprite headers and the number of lines in the zone.
There are two kinds of sprite headers: indirect (or tile) headers, and direct (or graphics) headers. Both sprite headers contain a pointer, a horizontal position, and a width. For direct sprites, the MARIA simply copies the number of bytes given pointed to by the header into the current line buffer. For indirect sprites, the bytes pointed to are tile numbers.
From a program perspective, it boils down to a lot of data movement to build the list of sprite headers.
I've included the source code for my demos in other posts for those who are interested.
-
To develop asymetrical playfields, I set up a simple spreadsheet, with each row representing one CPU cycle. I can then put cycle numbers in one column, PF changes in the second, and the instructions in another.
My recommendation is to make sure the last CPU cycle of a PF update is either before or after the PF is active. Tighter timing may be possible, but would need to be tested on actual hardware.
-
And then there's this one I did:
-
I'm still confused over a few technical aspects of the basic kernal.Interrupt Vectors
The 6507 used in the 2600 doesn't have the NMI or IRQ pins, which trigger these interrupts on a normal 6502.
The 6502C used in the 7800 does have these pins. The MARIA graphics processor can trigger an NMI interrupt (to allow the game a chace to change the MARIA registers mid-screen) and the IRQ pin is connected to the cartridge port (don't know if any games used it).
But we're talking about the 2600. Although the 6507 doesn't have NMI or IRQ pins, it's good programming practice to have those vectors point somewhere, either the same as RESET or an RTI instruction. (And to include an SEI instruction in your initialization section.) That way if the 6507 flakes out it won't crash horribly.
While we're on the topic, you should also reserve $FFF8 & $FFF9 in any 2K or 4K games to make them compatible with the Supercharger. Stick in a version code or your initials in ASCII.
Vertical Synchronizing:
I'm still not 100% certain about what the correct timing of VSYNC / WSYNC is msyelf. And, unfortunately, I don't have a oscilliscope to check it out. Maybe I could brute force it with test programs on the SuperCharger.
Re: VBLANK, see my replies over in Session 13 for more info, but basically there is no required relationship.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
NES games on 7800?
in Atari 7800
Posted
256x200 makes sense when you have a frame buffer since it makes x,y to address calculations easier. Since the Atari 8bits all used a GPU of one kind or another without a frame buffer, it made more sense to link everything (including the CPU clock) to a single colorburst clock crystal.