SeaGtGruff

I'm pretty sure it was a 2600. At first I thought it might be a 7800, but after the reference to a 5200 I watched it again in slow motion. The "2600" on the silvery chrome or whatever is clearly visible at one point. Graphics and other data that get loaded directly from ROM while drawing the screen have to be in the last bank because that's where the code for the kernel is, and the kernel doesn't change banks as it's drawing the screen. Graphics and data that aren't in the last bank need to be somewhere that's accessible to the kernel at all times (i.e., some location that isn't affected by switching banks)-- such as in RIOT RAM or Superchip RAM.

Can you post the binary file for us to look at?

I thought it looked like "Lulu Joey."

Maybe you could open a contest to see who can design the best title screen? The winner gets their name included *and* gets a free cart! But first we all need to know something about your game so we'll know what sort of title screen you'll need-- otherwise you might get a lot of entries with title screens that say Insert Name of Game Here An Atari 2600 Game by Fothlyrdrag For 1 or 2 Players Press Fire to Begin

That's weird, when I tried it I didn't have to do that-- just putting "inline 6lives.asm" in the second bank was enough. I'm wondering if maybe the problem was *where* you were putting the "inline 6lives.asm" in bank 2? I put it right after the "bank 2" line, before any bB code for bank 2. From your first post it looks like maybe you put it in the middle of your bank 2 bB code-- is that correct? If so, try moving it up to immediately after the "bank 2" line, remove the "includesfile 6lives.asm" line, recompile, and see if it works or not.

The multisprite.h file does include variables such as lifecolor, lifepointer, and lives, so I'm guessing that 6lives.asm *is* supposed to work with the multisprite kernel-- although I've never tried it myself. If it weren't compatible then there should be compile errors. As a matter of fact, I did get a compile error on this line: lives: 000000 000XXX end But it's a syntax error, not a compatibility error. I think the lives icon should be defined like a sprite, whereas the above code is like a mixture of the playfield syntax (...X...X) and the player syntax (%00010001). Try something like the following: lives: %00111000 %01111100 %11101110 %11010110 %11111110 %11010110 %01111100 %00111000 end

I can help with the documentation, at least with the TIA aspects of it (but not so much with any high-pass, low-pass, or band-pass filtering that gets applied after the AU0 and AU1 signals leave the TIA chip). I have a set of spreadsheets I made that simulate the TIA's sound generation on essentially a gate-by-gate basis. I've been planning to write up a document that would explain it, and include the spreadsheets. I'm reasonably sure the existing sound emulation is probably "too simplistic" in two or three different ways. First, I presume the code is designed in such a way that changes to AUDF0/1 and AUDC0/1 have virtually instant effects, whereas changes to those registers on actual consoles need time to "propagate" (if that's the correct term here). Changes to AUDF0/1 can take the most time, because the frequency counter typically needs to finish counting the old frequency before the new frequency takes effect. But changes to the AUDC0/1 registers also need time to propagate, at least for some of the values, because the shift registers need to shift out any current values before the new values can be output-- and since the shift registers are clocked by the output from the frequency counters, that might take a while. Second, I don't think the emulation tries to replicate the effects of any filtering that gets applied to the audio signals after they leave the TIA. I don't know how much difference that makes. And third (and probably least important), the audio emulation probably isn't timed to be in step with the scan lines the way the TIA is-- that is, the two audio clock signals are triggered four times (twice each) at specific times on a scan line. So the effect of writing to AUDF0/1 or AUDC0/1 may not even begin the propagation process until as much as half a scan line later when the next audio clocks are triggered. I presume this third consideration has a negligible impact, whereas the impact of the first and second considerations (in that order) are potentially more significant.

Different enemies should have different hit point and skill/attack point levels, and bumping/attacking an enemy should produce a random result based on the enemy's levels and the player's levels-- who got the first swing, was it a hit or miss, how many points damage did it do, and so forth. You might need to bump/attack an enemy more than once to kill it. Also, the enemies should go after the player. If the enemy bumps/attacks the player while the player is standing still or trying to run away, maybe you could give the player the option of attacking or parrying?

I don't know if it will be possible to have a full-fledged playfield as in the standard kernel, due to timing constraints in the multisprite kernel-- I'll have to check to see, but I imagine that if there were enough time to draw an asymmetrical playfield, batari would have done that. But at the very least you should be able to relocate the mirrored playfield to the Superchip RAM so you can modify it without having to redraw the entire playfield. Modifying the multisprite kernel to get an asymmetrical playfield will probably require giving up something, the same way you have to give up certain things when using the various kernel options with the standard kernel.

Right, all this does is let you use the Superchip option with the existing multisprite kernel, so everything is still the same as using the multisprite kernel by itself *except* you get 128 additional bytes of RAM. The read and write variables that I had defined for the Superchip aren't used by the multisprite kernel, but are there for you to use in your program.

It appears the includesfile option used to require set, but no longer does, so the correct lines of code at the beginning of the program should be as follows: includesfile multisprite_superchip.inc set romsize 32kSC set kernel multisprite Then it will compile without the crazy errors about pfcenter, FASTFETCH, etc. Edit: I say "It appears the includesfile option used to require set" because I don't know why I would have used "set includesfile multisprite_superchip.inc" back then unless the set was necessary. I see that Random Terrain's batari Basic page does show the includesfile option *without* set.

Should these be set to 31113Hz for PAL/SECAM emulation, since that's the half-line frequency for the TIA on PAL/SECAM consoles? Or does Stella make some sort of internal adjustment for the different oscillator rate when emulating PAL/SECAM games? All you'd need to do internally is multiply the NTSC half-line rate (approximately 31400Hz) times 3546894 / 3579575 (PAL oscillator rate divided by NTSC oscillator rate) and round the result, giving 31113Hz.

I'm just posting a couple of general comments about gosubs, since you've already got your problems worked out. (1) When you perform a gosub, the return address must be pushed onto the stack so the program can eventually return to where you called the subroutine from. The 2600 has a small stack to begin with-- only 128 bytes-- and it coincides with the zero-page RAM that's used for variables, so you need to be careful about how much you use gosub (or JSR if you're using assembly). And batari Basic has even less usable stack space because it uses most of the zero-page RAM for what I call batari Basic's "system variables" (things like the player pointers, sprite x and y coordinates, etc.), the playfield RAM (if you aren't using the Superchip option in a bank-switching game), and the user variables (a through z). So that means you have to be extra careful about how much you use gosub in batari Basic. Note that it isn't the number of subroutines that's the issue, but rather the number of *nested* subroutines. So it's perfectly safe to call a subroutine, but you want to try to avoid calling a subroutine that calls another subroutine that calls another subroutine that calls another subroutine, etc. If you're used to programming in a high-level language on a computer, you might not think twice about doing that sort of thing, but when programming for the Atari 2600-- and particularly when using batari Basic-- you need to be mindful of how many levels of nested subroutines your code contains, otherwise the stack could end up overwriting some of your variables and causing program glitches. I think a batari Basic program can have up to 5 levels of nested subroutines before the stack begins to overwrite some of the variables, and you can nest more than 5 levels of subroutines if you aren't using any of the variables that would be overwritten-- but keep in mind that batari Basic also uses subroutines (for example, drawscreen is a subroutine). So it's probably best not to go beyond 3 levels of nested subroutines. And make sure that whenever you call a subroutine it will eventually do a return, otherwise the return address will get left on the stack. You can use pop to remove a return address from the stack, but that should only be done if you're sure you know what you're doing! (2) Calling a subroutine and then doing a return takes up more machine cycles than doing a straight goto. That generally isn't a problem unless you're working on a section of code that has really tight timing constraints-- for example, if you're writing your own display kernel in assembly then you might not want to do a JSR in the loop that draws the active lines (unless you've allowed for the extra time needed for the JSR and RTS). On the other hand, if your batari Basic program contains a large number of gosubs and returns it might start to eat into your free cycles. And this is even more the case if you're using bankswitching and are doing gosubs and returns between different banks, because gosubs and returns between banks take up even more cycles than regular gosubs and returns. So it's a good idea to design your batari Basic programs to use goto instead of gosub wherever possible. Of course, sometimes you *do* need to use gosub instead of goto-- after all, subroutines are an essential part of efficient programming. You don't want to repeat the same code in multiple places in your program if it would be more ROM-efficient to put that section of code in a subroutine and then gosub to it from different places in your program. But you should avoid using gosub in cases where it really isn't necessary, such as if the code in the subroutine is only called from one spot, or if the subroutine is so short that it would actually be more efficient to just duplicate that code wherever it's needed.

Correct, it gets cleared before the score is drawn so that none of the score digits will be backwards.

Here's an example using a data array. In this example a frame counter (a) is incremented every frame, then after 60 frames (1 second) the color counter (t) is incremented. If the color counter reaches 16 it gets reset, because the data array in this example has only 16 values in it. t = 0 : a = 0 : rem in this example a is a frame counter playfield: ....XXXX....XXXX....XXXX....XXXX XXXX....XXXX....XXXX....XXXX.... ....XXXX....XXXX....XXXX....XXXX XXXX....XXXX....XXXX....XXXX.... ....XXXX....XXXX....XXXX....XXXX XXXX....XXXX....XXXX....XXXX.... ....XXXX....XXXX....XXXX....XXXX XXXX....XXXX....XXXX....XXXX.... ....XXXX....XXXX....XXXX....XXXX XXXX....XXXX....XXXX....XXXX.... ....XXXX....XXXX....XXXX....XXXX end loop COLUPF = playfieldcolor[t] drawscreen a = a + 1 if a = 60 then a = 0 : t = t + 1 if t = 16 then t = 0 goto loop data playfieldcolor $08,$18,$28,$38,$48,$58,$68,$78,$88,$98,$A8,$B8,$C8,$D8,$E8,$F8 end playfieldcolor.bas playfieldcolor.bas.bin

Yes, if you do it in assembly then adding to the lo byte with decimal mode set will take care of any overflow from the lo nibble to the hi nibble for you-- and if the hi nibble overflows (rolls over) then the carry will be set, so you just add 0 to the next byte without clearing the carry first. And if the middle byte overflows then the carry will be set again, so adding 0 to the hi byte will automatically bump it up as well. Basically, the decimal mode and the carry bit take care of everything for you. Edit: PS, if you want to make the two subroutines more generic, you can put the value you want to add to score in a variable, then when you do the first ADC you would use ADC VARIABLE (whatever the variable is), rather than using immediate mode.

How about changing it to say that some versions of the bB multisprite kernel require player0 to be defined each time you go through the loop, so try defining player0 outside the loop first, and if that doesn't work then move it inside the loop.

I think the corruption is happening because you aren't checking the digits individually. Plus, you aren't adjusting the digits for overflow until after you've already moved them to the score. And finally, this would all be easier if you used assembly. Based on your ifs I take it that p?sc3 is the lo byte, p?sc1 is the hi byte, and p?sc2 is the middle byte. So I'd suggest something like this: if !player0y then gosub increment_p0score if !player1y then gosub increment_p1score rem etc. goto main increment_p0score asm SED LDA p0sc3 CLC ADC #$10 ; or whatever you need to add STA p0sc3 LDA p0sc2 ADC #0 STA p0sc2 LDA p0sc1 ADC #0 STA p0sc1 CLD RTS end increment_p1score asm SED LDA p1sc3 CLC ADC #$10 ; or whatever you need to add STA p1sc3 LDA p1sc2 ADC #0 STA p1sc2 LDA p1sc1 ADC #0 STA p1sc1 CLD RTS end scoretest.bas scoretest.bas.bin

Playing with sock puppets, are we? I don't think I knew about player0 having to be defined each time through the loop with the multisprite kernel, or if I did then I'd forgotten because I haven't used it in so long. I would have thought that player0's pointers would be retained? But I see on your batari Basic page that it does say player0 needs to be (re)defined each time through the loop. Oh well.

I thought animating player0 was the same in both kernels. What specific problems are you having?

I think you should be able to add some color changes to your sprites in Timmy to get the luminance change effect in SECAM. The grid I drew has color A for the odd lines and color B for the even lines, where color A is the same for a particular row and color B is the same for a particular column. So if you look at the grid and see a particular shade you like, it's fairly easy to figure out which colors to combine. For example, black alternating with magenta makes a lighter red, and flipping them around (magenta alternating with black) makes a lighter blue. If you're trying for one and end up getting the other, just swap the order of the colors around. I drew 50 blanked lines after VSYNC before starting the active display, so using Stella's line-numbering method-- which counts line 0 as the line where VSYNC is turned off-- the first active line in my grid is line 50 (an even line). For convenient reference, the color combinations appear to be as follows-- (E)ven colors listed first, then (O)dd colors. Since some combinations are essentially variations of a particular color, I'm calling them COLOR 1, COLOR 2, COLOR 3, etc., where lower numbers are the darker shades and the luminance increases as the number increases. Some of the shades are difficult to tell apart, so I'm not sure if I've got the relative order of shades correct-- and some of the names I'm using are debatable (such as Light Green, should it be Light Cyan?): Black (E) + Black (O) = Dark Gray 1 (solid Black) Black (E) + Blue (O) = Dark Gray 2 Red (E) + Black (O) = Dark Gray 3 Red (E) + Blue (O) = Dark Gray 4 Black (E) + Yellow (O) = Gray 1 Black (E) + White (O) = Gray 2 Red (E) + Yellow (O) = Gray 3 Red (E) + White (O) = Gray 4 White (E) + Black (O) = Light Gray 1 (same as Gray 2?) White (E) + Blue (O) = Light Gray 2 White (E) + Yellow (O) = Light Gray 3 White (E) + White (O) = Light Gray 4 (solid White) Blue (E) + Black (O) = Blue 1 Blue (E) + Blue (O) = Blue 2 (solid Blue) Magenta (E) + Black (O) = Blue 3 Magenta (E) + Blue (O) = Blue 4 Cyan (E) + Black (O) = Light Blue 1 Cyan (E) + Blue (O) = Light Blue 2 Blue (E) + Yellow (O) = Light Blue 3 Blue (E) + White (O) = Light Blue 4 Magenta (E) + Yellow (O) = Light Blue 5 Magenta (E) + White (O) = Light Blue 6 Cyan (E) + Yellow (O) = Light Blue 7 Cyan (E) + White (O) = Light Blue 8 Black (E) + Red (O) = Red 1 Red (E) + Red (O) = Red 2 (solid Red) Black (E) + Magenta (O) = Red 3 Red (E) + Magenta (O) = Red 4 White (E) + Red (O) = Pink 1 White (E) + Magenta (O) = Pink 2 Blue (E) + Red (O) = Magenta 1 Blue (E) + Magenta (O) = Magenta 2 Magenta (E) + Red (O) = Magenta 3 Magenta (E) + Magenta (O) = Magenta 4 (solid Magenta) Cyan (E) + Red (O) = Magenta 5 Cyan (E) + Magenta (O) = Magenta 6 Black (E) + Green (O) = Dark Green 1 Red (E) + Green (O) = Dark Green 2 Black (E) + Cyan (O) = Dark Green 3 Red (E) + Cyan (O) = Dark Green 3 Green (E) + Green (O) = Bright Green 1 (solid Green) Yellow (E) + Green (O) = Bright Green 2 Green (E) + Cyan (O) = Bright Green 3 Yellow (E) + Cyan (O) = Bright Green 4 White (E) + Green (O) = Light Green 1 White (E) + Cyan (O) = Light Green 2 Blue (E) + Green (O) = Cyan 1 Blue (E) + Cyan (O) = Cyan 2 Magenta (E) + Green (O) = Cyan 3 Magenta (E) + Cyan (O) = Cyan 4 Cyan (E) + Green (O) = Cyan 5 Cyan (E) + Cyan (O) = Cyan 6 (solid Cyan) Green (E) + Black (O) = Dark Yellow 1 Green (E) + Blue (O) = Dark Yellow 2 Yellow (E) + Black (O) = Yellow 1 Yellow (E) + Blue (O) = Yellow 2 Green (E) + Yellow (O) = Yellow 3 Green (E) + White (O) = Yellow 4 Yellow (E) + Yellow (O) = Yellow 5 (solid Yellow) Yellow (E) + White (O) = Yellow 6 Green (E) + Red (O) = Orange 1 (use for Brown) Green (E) + Magenta (O) = Orange 2 Yellow (E) + Red (O) = Orange 3 Yellow (E) + Magenta (O) = Orange 4 Some of these combinations don't appear to make much sense at a glance, but do in light of how SECAM works. For example: Magenta (E) + Yellow (O) = Light Blue 5 The (E)ven lines use the Luminance and Blue signals from Magenta with the Red signal from Yellow. The (O)dd lines use the Luminance and Red signals from Yellow with the Blue signal from Magenta. (I think.)

I downloaded the free LTspice IV program a couple of years ago, thinking to use it to build a simulation of the TIA. Not being an engineer or electrician, I quickly found that it was WAY over my head. Specifically, I had virtually no clue about what to enter for the different parameters-- for example, it's very simple to pick a resistor and put it on your schematic, but you either need to pick an existing resistor from the library or enter the resistance, tolerance, and power rating yourself. Fortunately, I found some of this information in the parts listing included in the 2600 field service manual-- for example, it lists the resistance and power rating for each resistor, but says nothing about the tolerance. I was thinking that if I knew who manufactured the parts (or equivalent replacements), it might help me find existing definitions of those parts that I can download and use with LTspice IV. Does anyone know specific present-day companies that make resistors, capacitors, transistors, etc. that can be used as replacements for the Atari 2600's parts? Second, I recently decided to model the 2600's oscillator from the schematic for the 2600 (as opposed to the 2600A, which uses a simpler design for the oscillator). I chose the XTAL symbol for the crystal, but have no idea what the parameters should be. LTspice IV needs to know the capacitance, voltage rating, RMS current rating, equivalent series resistance, equivalent series inductance, equivalent parallel resistance, and equivalent parallel capacitance. Holy cow! All the parts list says is that it's a 3.579575 MHz crystal. I'd already given up on trying to model the TIA schematics in LTspice IV, and resorted to using an Excel spreadsheet to model the TIA-- which works pretty well for what I wanted; the biggest hurdles were teaching myself how to read and understand the schematics (which I've gotten reasonably good at), and figuring out how to eliminate problems caused by circular references (which I was able to do). My spreadsheet simulations don't show any timing delays due to signal propagation delays or gate delays, but they do let me follow the flow of the signals and see how everything works. Now I decided to take another stab at learning to use LTspice IV to model the oscillator and the sound filters on the motherboard. At the moment my primary interest is in the sound generation, and I've got all the relevant portions of the TIA done in Excel spreadsheets, but I'd like to graduate to LTspice IV if possible, and I figured the oscillator would be a good place to start-- because it really is where everything starts (since the signal that feeds into XTAL or OSC-- TIA pin 11-- is used to get the PHI-0 signal, CLK signal, H-PHI-1 and H-PHI-2 signals, etc.), and also because the oscillator circuitry is fairly small and self-contained (I'm not sure about where the oscillator circuitry and the color delay circuitry are joined together, but they're separated in the 2600A design, so I'm just going to leave out the color delay stuff). Even if I decide to just use the 2600A schematics (I'd actually like to model the oscillator for both the 2600 and 2600A for comparison), I still need to know what the parameters for the XTAL symbol should be, and that's where I'm stuck. Any suggestions or guidance would be appreciated-- although this project is just for fun, so if I can't get it off the ground because it's too much for my meager abilities, then no biggie!

WavePad can be downloaded and used for free for a trial period-- I don't remember, but I think it might be for as long as a month. During the trial period all of the features will work, but after the trial period is ended some features will stop working-- including the text-to-speech tool. To keep the text-to-speech tool working I believe you'll need to purchase a license for the Master's Edition, which is normally $129 but temporarily reduced to $79.99 until June 15 (tomorrow!). When I tried WavePad I decided to buy the Master's Edition after the trial period ended because one of the main things I wanted to use it for was the ability to do a Fourier frequency analysis of a sound, which is available only in the Master's Edition. I later found a free utility that will do the same thing-- but I actually like WavePad's FFT tool better, so I'm content with my decision to buy it. If you're mainly wanting to just do text-to-speech and then modify the result, there might be free resources you can use-- e.g., use one free tool to do the text-to-speech conversion, and a different free tool to modify it. I'm telling you this because, while I do like WavePad and find it to be useful, I'd hate to recommend it to you, have you buy it, and then have you find a bunch of free tools that could meet your needs just as well. Earlier this afternoon I searched for "text to speech free online" and there seem to be many web pages or apps that will do text-to-speech for free and create a WAV or MP3 sound file for you. I didn't try them out, but most look like they either try to produce "natural" sounding voices, or synthesized voices that probably sound similar to the "original" version I posted for "Your mother thinks 2600 PacMan is awesome" (which sounded much better before I reduced the sample rate and sample size), so you'll probably want to modify the result somehow to make it sound more robotic, alien, or whatever. WavePad's text-to-speech tool uses whatever the default voice engine is on your computer-- in my case it's "Microsoft Sam"-- but you can also download third-party voice engines (which may need to be purchased). If you do download WavePad and try it for free, I'd recommend wasting no time generating your text-to-speech samples and playing around with different ways to modify them, so you can accomplish your goal before the trial period ends. Or if you download it and decide right away that you like it enough to buy the Master's Edition, be aware that the sale price ends June 15-- although from what I've seen, it looks like they regularly offer their software on sale, so if you miss tomorrow's deadline then you might want to wait another few months to see if they put it on sale again. One last thing I need to mention about WavePad, because I just recently got burned with it. If you buy a license, it will let you apply free updates to the program for a period of 3 months. After 3 months, any updates you apply will require you to buy a new license. I found this out the hard way, but fortunately I was able to reinstall my original version and reactivate my existing license without having to buy another license. So keep a copy of the original installation file-- they actually recommend doing this themselves-- and keep copies of the emails that contain your license information, activation key, etc.

One more, since I'm having so much fun. You missed me, and my imaginary friend too!.wav

Here's three versions of another one. The first is unchanged except for the reduction in sample rate (to 6000) and sample size (to 8 bits). In the second one I lowered the voice 10 semitones. In the third one I undid the second change and lowered the voice 6 semitones. Your mother thinks 2600 PacMan is awesome (original).wav Your mother thinks 2600 PacMan is awesome (change 1).wav Your mother thinks 2600 PacMan is awesome (change 2).wav