Cybearg

Does anyone know of a working 2600 emulator in HTML5? I know of jAtari, which is a Java-based emulator, and I know that there have been some attempts at an HTML5 emulator, but the Java one requires Java, of course, and I haven't been able to find a working HTML5 emulator so far. Has anyone else heard of any?

So who's the lucky batariBasic coder who got his cart shown on the latest AVGN?

I'll definitely be using 7800 basic as well. I had wanted to do something on the NES, but that means raw 6502 Assembly. Why do that when I could use what I learned from batariBasic with 7800basic instead? I'm excited! Won't be able to start for a while, though. I have some other projects to complete and then I want to make a full-fledged 2600 game before moving on to the 7800, but I'm looking forward to seeing what 7800basic and updated releases of the tool bring!

Damn you slick Assembly geniuses. You make we batariBasic-dependent game programmers look like lazy idiots. Amazing demo!

Most of those Atari 2600 games didn't have screenshots on their labels. They were trying to give you something to imagine as you played and they didn't want you to see the game for the super-simple graphics that it actually had. To me, a screenshot isn't very authentic. The problem is that the authentic 2600 cover art style is difficult to replicate because it was done by pros. They had an authentic 70s sci-fi movie poster art style that has a lot of detail and a distinct painted look. It's a bit unrealistic to expect homebrews to meet that level of quality. Paying an artist to make a decent facsimile would cost more than the homebrewer could ever hope to make selling their game.

Haunted House's sound effects and style actually managed to increase my heart rate. That's pretty impressive.

Looks amazing! ... Dammit. I'm just about to release my compilation on cart and now you have to come and steal all the thunder. Grr...

I have some ideas. I'd still like to create some kind of proper action, adventure, or RPG game for the 2600 before moving on to 7800basic and making some stuff for the 7800. Lots of ideas, but right now I'm very pressed for time as graduation is in May and then I will be finding a full-time job. I want to get this all finished before graduation, just in case I am unable to get back to it.

Al may correct me, but I think it will be on the AtariAge store. As for when, the game is going through its final round of testing and I'm just finishing up the manual design, so I'd say it should be ready on my end within the week (or so I hope). It may take longer for Al.

So say I want to calculate the distance between x1,y1 and x2,y2, or determine what angle sprite0 is in relation to sprite1 and then start moving sprite0 toward sprite1 as the crow flies. Are there any 6502 functions that exist (or could be written) to perform these maths quickly and efficiently?

That is the most amazing thing I've ever seen on the 2600. Holy crap!

Yes, it's on there, although, under advisement from Al, I've renamed it to Fixer Fenix, Sr. in order to curtail potential copyright issues (this is Disney we're talking about, after all). As for the front cover, Fixer Fenix isn't represented on it to avoid copyright issues, but I'll make up for that with the manual! Sorry, it's save only. There is literally no room for any game to have a speech component--every game squeezes every byte out just for gameplay and features!

I'm getting the same problem. The Kernel Editor apparently wants me to select a valid title project folder, but no folder I give it seems to suffice as I get constant "Error adding title: Parameter is not valid" messages. EDIT: Apparently the issue was an image being taller than 256 pixels. That solves that!

Just going through the manual now. Very excited to see this! A couple of minor typos in the manual: Page 30: Page 2: That last one is just a nitpick, but there should be no apostrophe.

I'm fairly certain it was your idea, as I highly doubt I would think of something that clever. Noted. The issue is that none of my games have the space to afford even that if statement to ensure no zero is seeded. I'll just need to leave it at rand, then.

In my multicart, I have had issues in the past where the random number generator seems to break between game banks. RevEng, I believe, recommended that I set T1024T=rand before exiting each game. I have been seeding rand in some games with if joy0fire then rand=counter, with counter being a variable that just increments once per frame. A potential issue here is that rand could, in a 1 in 256 chance, be set to 0, which breaks the random number generator and would then push that brokenness into the T1024T and break all random numbers until the 2600 was powered off and on. Furthermore, the same could happen if the rand of T1024T=rand happens to roll a 0. Am I incorrect in this concern? I was reading the documentation for 7800basic (very excited) and noticed this brought up, which reminded me that this was an issue for the 2600 as well. How should I seend rand and T1024T without possibly breaking anything?

I finally found an artist to make me a label. Now with college coming to a close and the label made, I'm discussing the details for publication with Al.

Alright, thanks. Now, with all that in mind... is there any reason to not just get a serial card and plug the AtariVox directly into that, instead? Wouldn't that work just as well?

Yeah, that's what I mean--a data statement holding a mega-room that's the size of 9 rooms arranged in a 3x3 grid, which can scroll in and out. I'm investigating the possibility of a Zelda 2-style game, with an overworld map and sidescrolling rooms/dungeons, or a more Metroid-like game with a single large map. That doesn't matter to me. I'll be making a map editor in Gamemaker or something to ease the editing/output of the proper format. I just need to know how the data will be structured first and have some idea of how it will work. Also, if I had maps across multiple data sets, would I be able to feasibly read partially from one set, then another, then another, in order to do scrolling? How would that sort of logic look?

I'll happily add a sign for your product in my 2600 homebrew games, indicated by two 4x8 playfield blocks side by side, to represent a billboard. Sorry--can't actually write anything on it.

That would be fine, except that it would require code to jump between the pages, which could be clumsy if a room was half of one page and half of another page, wouldn't it? It'd need some sort of on..goto statement to switch between data sets, as I don't know of any way to do so elegantly without on..goto But to read the address Array+1624, you'd actually be setting Hi = (1624 / 255) : Lo = (1624 & 255), right? I suppose that, in the end then, sdata may be the most difficult way of indexing the data because of the need to shift where the data is being read from in order to account for rows and columns. For instance, if I had a set of data for 10 rooms (480 bytes), arranged like so: column0-row0, column1-row0, column2-row0... column39-row0, column0-row1, column1-row1, ... column39-row11 ... then code that reads from the array would be like: for i = 0 to 11 k = 0 loopjump if k > 3 then goto skiptonext temp1 = (i * 4) + k temp2 = indexposition + (i * ARRAYWIDTH) + k var0[temp1] = _DataArray[temp2] k = k + 1: goto loopjump skiptonext next ... Right? I mean, forgetting for a moment that the above code wouldn't work on a 2600, that's essentially what I'm doing, yes? And to facilitate a shift up, I would subtract ARRAYWIDTH from indexposition and add ARRAYWIDTH to indexposition to shift down, while horizontal shifts would just be a matter of adding or subtracting 1 from indexposition. So then what would actually be the best way to do this for large, 4-directional scrolling playfield data? That sounds great if I wanted a bunch of individual rooms stored together in a single large sdata set, but how would I index half one room and half of another room? 1/4 of one room, 1/4 of another room, 1/4 of yet another room, and 1/4 of a fourth room, in the case that the player was standing right on the intersection of the corners of four rooms? How would I handle horizontal/vertical playfield scrolling with this?

How would one solder it? The board looks surface-mount. What would it be soldered to? Also, is that USB plug positioned properly? I guess it would need some kind of USB extension to be plugged into anything, right?' And those settings you mentioned--that will somehow allow Stella to detect that there is an AtariVox plugged in and output to it for voice emulation?

But a normal array can only hold up to 256 bytes of data. If (like I plan) I'm using the superchip to get a 4x22 grid, that's 88 bytes per screen, limiting me to 2 full screens that can fit in an array. It's not enough.

I have nowhere near the knowledge to build and program my own. I have a solder gun that I've not used in 10 years, but no parts and no knowledge of how they may be acquired, let alone the knowledge to program a driver for it. Any takers on someone who'd be willing to make or sell me one for a reasonable price? And what about serial-to-usb adapters of the type I can find on ebay?

From what I understand, the reason sdata is able to hold so much more than a normal data set is because it is essentially a 2d array, while a data set is more like a 1d array. Therefore, an sdata set can hold 256^2, or 65536 bytes of data, far more than a single bank making it as large as one could use it. According to the link posted, two sequential bytes are set aside, but do those two bytes work together to create a 16-bit register to address the sdata's data, like a superlong 1d array, or do they work separately to create a 2d array, as mentioned? I ask in the interest of creating a scrollable playfield. Evidently, the only way to read data from an sdata array is using var = sread(_SData_Set), so it will read from whatever the bytes aside from the sdata depict, but how would one then move along the sdata set, say to read playfield data? For instance, if I have 4 x 11 = 44 bytes per full room and wanted nine rooms in a square of 3x3, which would take 396 bytes of ROM, how would I need to address that data in order to account for both horizontal and vertical shifts? My guess would be that an sdata set is a very long 1d array using the two bytes as a 16-bit register to reference them. If I had the aforementioned data set as: sdata _Playfield = a ... end ... and the player started in the center-most of the 9 screens, I would do something like: a = 4 * 44 ... for temp1 = 0 to 47 temp2 = a + temp1 var0[temp2] = sread(_Playfield) next And, if so, then I suppose that shifting would all come down to how the playfield data was arranged, correct? For instance, if the 12 bytes of the first row of the top-most 3 rooms would come first, followed by the 12 bytes of the second row of the top-most three rooms, etc. moving down, how would one accomplish shifts left/right and up/down? In this particular data configuration, up/down shifts should be as easy as adding or subtracting 12 from a for each vertical shift, but how would one account for horizontal shifts? This would be much simpler if a and b were treated as a 2d array, with one specifically being rows and the other columns, rather than an upper and lower byte of a 16-bit register. So, in conclusion (after that speculative ramble), how do the two bytes of an sdata set work, how should playfield data be organized in an sdata set, and how can directional shifts for playfield data in an sdata set be accomplished?