RetroFiends

In stella if you press alt+L it'll show you the scanlines per second. For ntsc you should be at 262 iirc. Any more than that and you have a problem and you need to optimize your code.

I like where this is going, especially the timing element to the tricks. However, please note the following: -You can jump while dead -360 Shove-it is more difficult than a backflip and gives more points? -There needs to be some sort of obstacle in place at the very least. Ramps, curbs, small animals, whatever it may be. I really like the idea of stairs in post #4, higher jumps from ramps or stairs could allow for more tricks and an actual risk-reward factor for the player where right now it's all about timing.

If you want to take it a bit further, you can buy a bulk of 100 cassettes with quite a few options in color and length here http://www.deltamedia.com/pg_blank_audio_cassettes_new.html?id=6cr4iCtj starting at $.40 per cassette for a 30 minute tape (15 minutes on each side. waaaay more than you actually need) but they also have options for less than a minute if that's all you need ($.35 for a one minute tape) After that they also have http://www.deltamedia.com/1CSNB1.html?leftmenu=mediasuppliesnav the cassette cases which will run you another 30$ or $.30 cents per making each release cost less than a dollar. Of course, you'll have a lot of excess material on your hands but it will ensure future stock if you ever decide to produce more than one Starpath game.

I'm aware of that. But from my understanding the supercharger dumps the entire "ROM" (in this case, the audio file) into the Supercharger's RAM, meaning that at any point the only RAM you have is 6k - "Rom" size. Granted, yes with multi loading and some cleverness you could theoretically make some some massive games but after a point you're pretty much forced to mp3/CD use. Not because there isn't enough room on tape --there is, but because you're ultimately always working with 6k - ROM chunks and the only end-user - friendly arrangement would require flipping the tape - Something you can only do so many times. Without a tape counter and the immediate attention of the player (stopping the tape right when you're given the que) you can only get so sophisticated. So, here you have end user limitations, plus 6k RAM - ROM. Higher resolution graphics cut out what you can do with game logic tremendously with your game logic in any given 6k chunk, and then of course also needs to be room for multi-load handlers. Sure, theoretically you could make some pretty massive games, but when you're switching audio files every 10 screens it's not at all practical. Nonetheless, I wouldn't mind seeing someone go absolutely mad at the expense of the end user just to see how far a Starpath game can go.

Well, the game I'm working on isn't nearly to the scale of that but it is relatively massive on a per screen account. This game is 32k and is looking like there will be little room to spare. Batari Basic is helping to make this whole process doable for someone new to the system, but of course there are limitations. Since playfield graphics are forced to the last bank and the game is already 29 screens with more on the way, I've made thorough use of playfield variables. Needless to say, that ain't gonna fit on a cassette Back to the topic at hand, I think people are being a little optimistic about what you can actually squeeze out of the SuperCharger. 6k of ram isn't a lot of ram at all once you understand that you're loading your entire rom into that ram. High resolution games will undoubtedly take a large portion of said ram, and then you have to fit all the game logic into it. The reality is that anything you would make would essentially be a beefy 4k game in quality.

You have no clue how much this excites me.

There's no indication as to why they wouldn't be, especially since they're made to order.

While I won't argue that a supercharger release wouldn't be an incredibly niche venture, that's not to say it isn't worth the venture. After all, everything we do here is incredibly niche in the first place. If I could release a supercharger game to even 5 people who end up happy with it, I would consider it a job well done. It's a matter of perspective, I suppose. That said, and as has already been said in #14 in this thread, it's more than possible to make a beautiful cassette release. The amount of options to make your cassette stand out are listless and as I said before there are plenty of tape duplication services and even cassette manufacturers that will bend over backwards to produce what you need. You can get cassettes done in nearly any color, printed on in any number of ways, and of course the case inserts are just as doable as any other media format. (Albeit, inserts would have to be smaller unless you wanted a full box as Starpath games did.) Additionally, there's no reason why we'd have to limit a game to supercharger release, it would simply be one more option available.

Hello Nognir, I thought I was having the same issue just now but rest assured the paypal option is still there. on the order page at the very top there's a little line of smaller text that says "Alternatively, pay with paypal." or something along those lines.

Excellent! So what it sounds like is that the ROMs themselves aren't actually anything special outside of conforming to what does and doesn't work with a Supercharger. Is there anything in particular that causes those 4k ROMs to not work? What triggers the bankswitching to occur in 4k games? Edit: That thread actually answered this question. So this is great news. 2k games are effectively ensured compatible, while 4k roms have additional considerations. With this in mind I might be making a Starpath game soon. I've been wanting to create a 2k game after the ridiculousness of this 32k game I've been working on.

Yep, how is the what I'm looking for. I mean, if we could somehow assemble games for use on a starcharger, this would give people another option when testing homebrew software, or even distributing said games. I know it's totally unnecessary since the Harmony Cart, but I love cassettes. The biggest benefit of course being super cheap to distribute. I mean, I can go to goodwill right now and I'll probably find at least one packgage of brand new cassettes for pocket change. And there is a multitude of media duplication services out there that also deal with cassettes for a more professional approach. Unfortunately, I'm having a very difficult time finding anything on the details of how the thing actually works. Right now it's occult.

As far as I'm aware, it's not like we can just load up any old atari ROM onto a cassette then load that from the Supercharger. What exactly does the super charger do? How is the data of the supercharger ROM converted to data readable by the unit? I did a google search for Starpath Supercharger homebrew, and came up with nothing other than claims that it existed. In short, how does this thing work? Are there documents available or is this thing magic?

I... don't exactly recall atm, I believe it was that old Tinkernut link and the more I read these forums the more I see that was probably not the best idea. I was also seriously unaware that batari basic and visual bB were two separate things as a result. I was under the impression it was just one package.

Oh wow! For some reason I had it in my head that those playfield variables would only work in 4 vertical rows. I don't know why. I guess I got that in my head by the manual diving them up like such and your previous reply where you value it at 255. But yes, this actually pretty much works perfectly, is accessible from any bank and is visually intuitive (so long as you take into account the rows with reversed bit order.) I take my lack of understanding and admit I need to get a bit of sleep. This is good news though, as it means I can definitely do the underworld I wanted to add to my game aswell, and not have to worry about the ROM space. EDIT: Yes, Random Terrain, something is wrong with my bB. I upgraded to build 566 just for convert data, but not even the example you posted in the "why this is so great" thread would compile. using data in general seems to not work regardless of what version my bB is and at this point I don't want to poke around too much further for fear that I might muck something else up. Still, it seems extremely odd that this is literally the only thing that is borked in my install.

Well, yes and no. If I'm careful I could totally make what I have planned now fit but it'll be a very tight fit. I was also mistaken that bank 7 was taking on a large part of the burden as it seems to have been an anomaly (meaning, I'm tired and reality totally wasn't cooperating with that fact.) I could shave a little bit of space off by moving all my pf color commands over to another bank. Right now the game already has a staggering 16 rooms with 19 planned. (The extra 3 being buildings or caves for a little of the beaten track exploration that I haven't gotten in yet.) I only have one enemy plugged in so far. Since Convert to Data File obviously isn't working for me I would still have a ton of room in the other 6 unused banks to make a convoluted system using pfpixels but I worry about how ungodly slow that might be.

Yes, I'm looking at the space. And while there is a small (4 bytes) decrease in available space in bank 8 when I store a playfield in bank 7, bank seven takes on most of the burdon. Is batari automatically bankswitching from 8 to 7? Or maybe the graphics really are somehow only 4 bytes and bank seven is just spitting out pfcolors info?

EDIT: Despite what the manual seemed to be telling me, I seem to be able to put graphics in banks other than the last bank and it is indeed stored in that bank. Where the manual says that graphics are put into the last bank automatically regardless of where they are called from. Am I missing something here? If I'm able to put playfields in say, bank 3 in addition to bank 4 then I don't even need convert to data. I would still love to figure out what's going on with not being able to compile data-fied playfields, though. Original Message: Hello everyone. I tried to use convert to data file today, but it just isn't working for me. I tried the example for this and it wouldn't compile. I am given an ambiguous syntax error if I use data ANYWHERE it seems. Am I missing something I need in my installation? That's the only thing I can think of. Otherwise I'm at a loss. I really want that data working :<

Convert to data file looks brilliant! With that I could certainly make use of more banks. Although, I want to get what I have implemented before I get too adventurous. All these randomterrain links answer my questions as well, I'll have to peruse the rest of your website too, now . Thanks for your reply.

Hello everyone. I recently started making a game with batari basic, And outside of a few "what the hell" type moments I've not run into any major issues. I do however, have a few general questions. Apologies in advance if any of these have been answered before but I did attempt a search before hand and have come up dry. 1. I recently upgraded my game to an 8k ROM. Bank switching allows me to (for the most part) create my vision without extreme compromise in terms of how many playfields I can store. However, since the graphics always go in the last bank, what real reason is there to ever venture on to larger ROM sizes. It'd be great if I could add an "underworld" to my game (but as I have the game fleshed out now I don't exactly NEED more playfields), but then I'd definitely run out of space. Is there any way to store playfields in other banks? Perhaps a way to dynamically swap out playfields between banks, although I fear that option is waaay over my head. 2. Does Stella accurately emulate hardware or am I potentially opening myself up to bugs I would otherwise not notice until played on real hardware? Since I don't have a Harmony cart yet testing on real hardware isn't an option at the moment. Is there anything in particular I should be aware of? 3. When dealing with pfcolors I notice that for seemingly inexplicable reasons the top or bottom bar of the playfield will be a single solid color unless I make a duplicate line entry at the bottom of the pfcolors: list. It's almost as if batari basic is counting the score line as a playfield line. I don't quite remember but I believe no_blank_lines does the same thing. 4. And speaking of no_blank_lines, can someone explain to me why they aren't perfectly divided amongst the allowed screen real estate? This little quirk has forced me to LOVE blank lines (and now I really do love the blank lines ) but I still find it odd. I'm having a blast developing this game and I'm making great progress in a very timely manner. Batari Basic actually fulfills a childhood dream I've had to produce a real game on a video game console and has definitely been the highlight of my life this week. So, thank you batari for making one of my dreams come true.