Shamus

@Heaven: OK, if you have any background other than $00s then your sprites are going to look bad. That's the bottom line. Unless you've designed your graphics to look OK when XORed with whatever number you decide to put there, but then it becomes an intractable mess. To answer your question, though, yes, you can leave the monster that isn't moving there while the other one moves away and then later XOR it when it needs to move. If you want, I can put together a QnD demo that shows this. @Rybags: I see what you're saying now. If you have any background other than $00s then it's gonna look like hell no matter what. That's why a lot of those A2 games used a black background, for that reason though there were exceptions. AE comes to mind--there you can clearly see XOR artifacts when the enemy ships move near the edges of the screen.

It was only a proof of concept demo, mainly to see if I could get decent speed using a combination of BASIC an ML. In short, no go. So yes, it only draws 200 robots then simply XORs them in the order they were drawn. And no, it doesn't matter what order they are removed. REM out line 200 and you'll see what I mean. If you want harder proof, remove line 200 and then randomize the removal process. I guarantee you'll end up with a clean screen. The beauty of the XOR is that you can do it in any order and as long as you do it again *in the exact same place* you'll undo whatever you did. There's a reason that all those A2 coders used it. I think I tried some simple animations in that example as well, it's been so long since I wrote that that I can't remember if they work or not. But some well placed GOTOs should answer that question.

Not true, you don't have to remove them all for it to work properly--just the ones that need to move. I found my little demo, it's written in Atari BASIC with ML helper routines. The images are put to the screen using XOR only. To see the effect a bit more clearly, comment out line 200 (the collision detection routine) and you'll see that the order doesn't matter. You could also load a background picture file to see it even more clearly. You would definitely want to do the erase/redraw as close to the blanking interval as possible as Rybags mentions, though. Chances are, though, that there'll be some flicker--depending of course on how many sprites there are and how big they are. Oops, forgot to mention that the file is LISTed Atari BASIC. shape.bas

I'm pretty sure that if you're XORing your sprites to the screen then you can remove them in any order--as long as you're XORing to the screen and then XORing at the same position to remove it. I had an old demo that, err, demonstrated this technique. I'll see if I can dig it out.

I had toyed with the idea, only I started with BT3 and I got that splash working as well. I've always thought that a BT1 conversion of the Apple2 version would probably be *much* easier as there would be much less hoops to jump through going that route. Plus you could do things like enhanced graphics, sound and whatnot. It's a cool project, but not for me. Instead, I've written an A2 emu to play it on. Yes, I know about AppleWin, but it doesn't do TV artifacting right. Mine does.

This is a bad argument, and tired as well. Why it's a bad argument is left as an exercise to the reader. i've restored the bit of my post that you strategically left out and put it in bold for emphasis; this thread was originally about converting the entire game and not just the pictures, the CPU and other resource overheads should therefore be a major part of that discussion but, since it seems to have boiled down to pretty pictures and cheap shots at me and Oswald, i think i'll keep out of it now. Good luck to anyone brave enough to take on coding something of this size, though. I stand by my original post; it's still a bad argument and pointless to boot since you're comparing apples to oranges. Actually, it's even worse than that: you're mischaracterizing what the A8 is capable of and muddying the waters as far as what is considered "normal" on the A8. I'm not going to point out why as others have already trodden that ground and the argument on its face is, really, quite silly and pointless. And BTW, the A8 is fully capable of playing music while doing disk I/O and showing graphics--The Eidolon comes to mind but I'm sure there were others as well. Just to emphasize the stupidity of this argument: The A8 can do 256 colors on the screen--can the C64? The C64 can do 16 colors in 320x200--can the A8?

This is a bad argument, and tired as well. Why it's a bad argument is left as an exercise to the reader.

Yes, the hi-bit was used to control a 1/2 color clock shift giving a couple more colors in A2 hires--gotta love Woz's design decisions. My guess for AE is that they redid the bitmaps for 8 pixels across instead of 7 in the original A2 version, which means that they needed 1 extra shift in the soft-sprite tables. And yes, the A2 hires screen is slightly less wide than the A8/C64.

Yeah, the memory on a hires apple 2 screen is not linear--I think the explanation that Wozniak gave was that the weird memory layout minimized the IC count on the motherboard. Bad design if you ask me, but then I'm no Woz. At any rate, I thought that most apple 2 games used a screen look up table for fast drawing, no? You might want to keep that in mind while looking at that IM code.

Ah yes, I remember that good 'ol (or bad 'ol, depending on you POV ) EA protection. That was a bitch and a half to remove and I didn't have Omnimon, either. I believe the trick there was that they were stuffing a value somewhere between $0000 and $0006 in memory and then doing a coldstart. Of course, jumping to COLDSV would wipe out all RAM, right? The trick there was that the coldstart routine would wipe out all RAM *except* for those first six or so bytes in memory! Really quite deviously clever.

I had an original copy of AR:Dungeon and I remember seeing that. IIRC, I believe it said "Ahoy, pirates: Change this byte from 0 to 1" or some such. So, out of curiosity I did that and it changed the into loader text message to one that looked like a cracking group had done it and the message along the lines of 'pirating software will kill development on the Atari, have a nice day' or somesuch. Of course, that didn't stop AR:Dungeon (or any of software that followed it for that matter) from being pirated.

I don't remember the first, but removing disk based so-called 'copy protection' was a hobby of mine (ah, youth, when one had little money and loooooots of time ). I think my favorite was my crack for Wayout. It seems that there was some fancy checksumming hidden deep in the code and of course I didn't have any Omnimon or anything that would have made tracing that kind of thing child's play. So I hit upon the idea of cloning sector 1, putting it on the disk (I think in sector 720) and writing my replacement for sector 1 in such a way that it would load the "real" sector 1 over my code and continue execution just past the bad sector check. The hidden checksum routine was none the wiser. Come to think of it, I do remember my first hack. My first hack was converting the Apple game "Sabotage" to the Atari. /me checks Atarimania... Hm, it isn't there.

Hmm, funny topic. It's true that a lot of A8 cracked software didn't have intros, but I do remember some groups did like Piratec and Heist Brothers/Heist Network (look at AR:Dungeon for an example; use slow SIO if in emulator--IIRC, the Dungeon release even had a character resurrector on disk 1/side 2).

Well, I just checked CVS Compile (the link is on the VJ homepage) and they haven't updated the site for a couple of years. And I haven't had access to win32 for at least as long, otherwise I'd whip you up an executable. Perhaps some kind soul here could do us the favor? As far as the CD stuff goes, yes, the plan is that you'll put a JagCD in your CD-ROM and hit 'Reset CD' in the menu and away you'll go. There's still some tidying up to do with that; I finally found a cross-platform low level CD library that I can use instead of the awful mess that's in there currently. Not to mention merging in the code that some guy sent me (I need to dig out his name, he really deserves credit for his work)--he has real CD hardware and the ability to reverse engineer it (although BUTCH ASIC nets would be cool--anybody got some? ). Even with the CD code in current state it's in I was able to almost get Blue Lightning to boot up; reverse engineering this thing without any good documentation has been quite a bear. I might be able to do a compile in a virtual machine if I can dig up my old win32 installation media... Hmm... Might not be such a bad idea.

Hey Rey, I don't have anonymous SVN set up on my server yet, so I just made a snapshot of my current sources. You can grab it at http://shamusworld.gotdns.org/virtualjagua...20080428.tar.gz. I just checked it and the overlays seem to be working OK (have to double check my real screenshots) but there's still an off-by-one bug in the text. Not sure about the automap, if the overlay works then that should too. You'll need to enable the DSP if you want to ride any elevators or get into any air vents, so that should make an already slow crawl even slower. Seriously, the new blitter is completely unoptimized so it's quite a bit slower than normal. And it's still currently based on the Oberon ASIC nets, but I'm hoping to get that sorted out soon.

Hey, sorry, it's been a while since I've checked CVS Compile (and the website) for dead links. And it's been a while since I've committed anything to CVS on Ryan's box anyway (been using SVN on my server and it kicks the living daylights out of CVS, which isn't too hard to do really). Compatibility has gotten better as a result of actual good documentation (in the form of ASIC nets) but it's still quite slow at the moment. Accuracy first, ya know. At any rate, Ryan was willing to switch projects over to SVN, but the guy who set things up with him has disappeared and Ryan isn't going to do anything without his approval--which makes sense from Ryan's POV. So I may just bite the bullet and host on my server if he doesn't turn up.

Thanks Reaperman! :) Very much appreciated!

Seconded. I still can't D/L #2 & 3 from langesite, but that torrent of CD #1 came through nice and quick. I'm still seeding that one, in case someone hasn't grabbed it yet. Don't make me beg. OK, I'm begging you--please, please, please...

Spelunker? I know that Broderbund eventually picked it up but it was originally done by MicroGraphicImage. I can't imagine that game being done well on anything but Atari 8-bit. What about Escape From Epsilon?

Well, the http download timed out. So thanks dwhyte for the torrent. All we need now is to get a few more people in the torrent to get it moving. If some kind soul(s) could torrent zips #2 & 3 we'd really be in business.

Dabbling in emulation now are we Gunstar? I don't know if Atari800Win is still being actively developed, but the plain old Atari800 project is and works just fine. Does disk rotation and all that jazz. No, it doesn't run in a window, but so what?

Off the top of my head the choices on a real Atari are: Editor/Assembler (a joke of an assembler with a horrible debugger) AMAC EASMD Synassembler Mac/65 On a real Atari Mac/65 is the hands down winner (I had the E/A cart, AMAC & Mac/65 on disk and cart). The one I had even had DDT built in so major bonus points there! Even the disk based version beats just about any other. What I used to do is write my source files using the Action! editor (THE BEST on a real Atari) and use Mac/65's ENTER command to have it append (prepend?) line numbers to the source before saving it out. I could even do edits in Mac/65 and PRINT the source back out to disk if I wanted to do heavy editing in the Action! editor. Good times.

OSS did what you're talking about with Basic XL/XE, though those probably don't work on the 400/800 series. And I have to agree with 1050, Action! was/is an awesome language--it was the first language that I could actually do things that would require assembly language before. My only complaint was that it came out late in the 8-bit lifecycle.

Great stuff Don! I remember stumbling upon this after the other Gauntlet was out in the arcades, so seeing this on my local BBS naturally piqued my curiosity. When I saw the size of it, I thought, "Could it be? The size seems reasonable. Maybe..." Then, after I ran it, I thought, "What a ripoff! Somebody is trying to cash in on the popularity of Gauntlet with this crappy saucer shooter!" Then, after I'd played it for a while I thought, "Wow, what a cool game!" It's too bad that I was just a kid at the time with little to no disposable income (I spent most of my time watching other people shoving their quarters into the other Gauntlet). I just have to say that the discussion in this thread is really quite interesting and that it's funny that you should be writing about ring buffers when those are the very things causing Virtual Jaguar problems at the moment. And funny you should mention optimization--I had to rip out lots of "clever" code just to get things to work properly when I inherited the code base. And there's still much to do to get it working correctly! @HappyMonster: I know this is probably a long shot, but since it seems like you intend to give away the full version of your game how would you feel about opening up the source? It would make a lot of people who don't use windows happy.

I you really want to know, the answer is here (warning: long article ).