Shawn Jefferson

Nice straw man. No one said anything about stealing a physical item. The stuff we are talking about is simply making a copy of a specific sequence of 0s and 1s. Nothing was harmed, nothing physical taken, no one deprived of anything, other than you didn't pay the price being asked to have a copy of those 0s and 1s. In law it isn't called theft either (although IANAL.) As far as my comment about "worth the money", I was thinking more about movies and (some) music. When the movie companies are making millions of dollars in profit, CEOs making million+ salaries, and movie stars making millions per movie... well, something is wrong there if you ask me, and some people may just be "pirating" to make a social statement too. Of course, if one was a CEO or a movie star, one may have a different idea. My own personal situation, is that I although I had an extensive library of "non-legally obtained" software back when it was still being produced, now, I tend to purchase those things that I want/need. My situation has changed in that I can afford those things, prefer to legally own them, and the downsides of having to deal with pirated software (malware, lack of updates, etc...) is too high. Older systems/software... well, that I have rationalized as "abandon-ware" like most people here have. I fully recognize that as a rationalization and realize that someone is losing out by me not purchasing those items legitimately.

The trick is to develop a device that can reconstruct what's on the data bus by just the sounds. Then you can eavesdrop on your neighbor's Atari activities.

Half-playing Devil's Advocate here... First off, I don't think Morals=Laws, they are not necessarily equal. Sure, you could look at it that way. Another way to look at is that the person was never going to purchase the game, for whatever reason, be it geography, financial, maybe they just didn't think it was "worth the money being asked." If they were never going to buy the product, they weren't taking anything away from anyone, so not "theft" in the sense of depriving someone of something that is theirs. I had a fairly large library of copied games (and some purchased of course) for my Atari like almost everyone else "back in the day". A lot of friends of mine played those games, maybe some of them purchased them after playing at my house. Maybe some of them purchased sequels for other computers too, maybe they still are purchasing them to this day even. It's possible that my having a copy actually helped the game creator/software house/game distributor. Hard to say with certainty. What about the vendors that still exist that still sell real copies of the game? Some of the cost of the those games is in warehousing and distribution. Why do you feel it's ok to short-change those people who put time, effort and money into those tasks and only compensate the "creator" of the software?

Oh, we have Gremlins. Thanks to Glenn. http://www.atarimania.com/game-atari-400-800-xl-xe-gremlins_2307.html

I was a member of the Garden City ACE in my hometown in Victoria, Canada as a teenager. I was a little too immature to really get much out of the forth lessons and other "productivity" software demos, but it was great getting the newsletters (which I threw away years ago when I didn't think I'd ever pull the Atari out again) and of course getting to join the "Saturday" copy party. The club also introduced me to memory upgrades, happy drives and SpartaDos. Those were good times.

I look at it this way... I learned something that I wouldn't have learned if I hadn't posted that code, and I hope the OP's question was answered as a result. I did post it with some trepidation, since most of the coders here are way, way ahead of me. (Wait till I release the code from the Moria port I'm doing... that will give some folks a laugh I'm sure.) Those were all good points too, I always ignore those equates and header files that are there to make life easier... the technical issues around safely setting up a display list with DLIs are much more interesting to me though. You've got the next one.

I knew there would be. It was test code I dug up quickly... Maybe I shouldn't have posted it as I wouldn't want to pass on too many bad ideas! Yes... Some projects I've written I've manually adjusted the location of the data segment to make sure it didn't cross a 1k boundary. This code doesn't I believe... you do have to keep that in mind, for sure. Use the linker config for that in cc65. To safely change the display list with DLIs are you saying you pretty much have to do it in a VBI? So that I know better for any future code I may write, what would the safe process look like to enable a display list with DLIs?

I guess I love it because it's the processor that was in my Atari computer. If that had been an 8080 I'd probably have grown up with that and "love it" now. Personally, I like 6502 assembly because its simple, but when I did some 68000 in school, that was nice. No fooling around with segment offsets to address more memory, and very similar to 6502 so it felt very natural. Unfortunately, the computers I typically used outside school did not contain that particular chip... so it was a fleeting affair.

You could use in-line asm, but the cc65 compiler can optimize that in-line code, sometimes doing things you don't want. I usually write routines like DLIs or VBIs in a separate assembly file and link to my project. Here's something I had laying around that I modified to do a simple DLI. Main C code: #include <atari.h> #include <stdio.h> #include <stdlib.h> #include <conio.h> #define SAVMSC *(unsigned int *) 88 // Screen address #define NMIEN *(unsigned char *) 0xD40E // NMI enable #define SDMCTL *(unsigned char *) 559 // Antic DMA control shadow #define SDLSTL *(unsigned int *) 560 // Display list start shadow #define VDSLST *(unsigned int *) 0x200 // Display list interrupt vector char dl[] = {112,112,112,66,0,0,130,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,65,0,0}; void dli(void); void main(void) { unsigned char i; dl[4] = (unsigned char) (SAVMSC % 256); dl[5] = (unsigned char) (SAVMSC / 256); dl[sizeof(dl)-2] = ((unsigned) &dl) % 256; dl[sizeof(dl)-1] = ((unsigned) &dl) / 256; NMIEN = 0xC0; // enable dli + vbi SDMCTL = 0; // turn off antic SDLSTL = (unsigned int) &dl; // new dlist address VDSLST = (unsigned int) &dli; // set dli vector SDMCTL = 34; // turn on antic for(i=0; i<24; ++i) { gotoxy(0, i); cprintf("This is a string! %d", i); } while(1); return; } Assembly DLI routine: .export _dli COLPF2 = $D018 WSYNC = $D40A .code _dli: pha ; save registers lda #$40 sta WSYNC sta COLPF2 pla ; restore registers rti Command line to compile/assemble and link: cl65 -t atari -Osir vsdli.s testvs.c -o testdli.xex testdli.xex

It is disappointing that we haven't heard anything from Candle, at the very least a "Sorry, very busy with real life, another project, etc" and an update on ETA. He was on AtariAge Dec 12, 2014. I think he has another project still in the pipeline that needs to be delivered (an Atari 8-bit project) too.

Pin 1 is marked, on the chips, on the sockets and on the motherboard, but I agree if you don't have that knowledge of what you are looking at/for, you could easily not know where pin 1 is. This might help: http://www.evilmadscientist.com/2010/basics-finding-pin-1/

It must setup a chain of SCBs all using the same sprite data I guess. It wouldn't have to reload some of that SCB I suppose, and maybe the actual sprite data is "cached" somehow too maybe? Do we know enough about the internal workings of Suzy to know exactly what it does, how it loads data, etc... I didn't think we had any real data about Suzy like we do on the Atari 8-bit side with ANTIC (it's been de-capped even.)

Trig3 is used for the cartridge interlock on the XL/XE is it not? Edit: Yep... From Mapping: 1018 3FA GINTLK Cartridge interlock register; the complement of BASICF, above. It reads 1 when an external cartridge is installed, 0 when not (or ROM BASIC is in use). The value of TRIG3 (53267; $D103) is loaded here by the OS initialization routine. If at any time, the external cartridge is pulled, the system will crash.

Seconded, definitely! Here I can't agree. I don't actually care about the protection itself, however, the problem with a "cracked" version, is you have no idea what the cracker has done. Did they change something? Inadvertently screw something up? Not fully crack the program? Some programs will run to a certain point being "half-cracked". With a format that preserves the copy protection, you at least know you are getting software that is unchanged. Think of it as preserving the software as it was produced and not the copy-protection. That said, beggars can't be choosers and I'll take a cracked version over nothing, and I think that's the same motto that Atarimania seems to have (which is good for everyone). PS. Having the non-cracked version doesn't mean the cracked versions all disappear or become useless. On the Atari you can run ATX (VAPI) via APE on real hardware, and with the Altirra emulator, so it's a good format in that sense.

Better would be to emulate VBXE, since that exists in physical hardware and provides 80 column natively. There's already software written for it too. No sense dreaming up some other mods that only exist in this emulator/hardware implementation.

I can't speak for others, but think the idea is that a cracked piece of software is not the "original"-it's been modified in some form, and it may not behave like the original. At least the VAPI format can be created with a SIO21050 cable and a Happy drive, and this produces an "ATX" file, that can be read by APE (with an add on DLL), and by Altirra, at the very least. It's my understanding that the VAPI format stores the copy protection and allows APE/an emulator to "emulate" the protection for the software-essentially what the disk drive is signaling to the computer. VAPI is not a method to make physical copies, only to "rip" disks with copy protection. The Kryoflux method records the actual flux changes on the disk itself in a special format that is independent of what the disk drive may signal to the computer (my understanding of it anyway). I doubt these APX titles are very complicated copy protection-wise though, at the most maybe a bad sector. It's also possible that the disks have actually deteriorated and are actually bad and not copy protected at all too. A straight sector copy of the disk (I always used copymate4.4) would probably give an ATR that can be booted in an emulator and quickly cracked by most people here in short order if the disk has copy protection.

I don't think you can in that case... VAPI requires a Happy drive, but I think PRO works on a stock 1050 (but PRO is a proprietary design and not well supported in emulators) Those other things Kryoflux and Supercard Pro require specific hardware that most people don't have (I guess they would be the "ultimate" in disk preservation.) Posting just the ATR will probably quickly get them cracked anyway.

Why not VAPI or PRO images of the those? They can always be cracked later on.

SIO2PC is more versatile and flexible than the other solutions, but requires PC side software. Software like APE emulate "perhipherals" and not just disk drives. SIO2SD will have great compatibility with software, because it is just emulating the disk drive, but is only good for that one purpose. MyIDE II has some drawbacks, requirement for a custom OS is one of them. Without it, quite a bit of software will not work. Even with it, some rare software may not work (not sure how many titles with the newest OS though. Price is lower than SIO2SD. I guess it comes down to what you want to do with your Atari system, what software you want to run (multi-disk games? demos?) I personally have SIO2PC with APE, a SD solution (not the SIO2SD, the SDrive), and the older MyIDE system with internal MyIDE OS and MyIDE cartridge. Of those, I use the SIO2PC with APE the most, and secondly the internal MyIDE (and sometimes those two together since you need a way to get the games/software onto the IDE hard-drive). I don't ever use the SDrive system, I just don't find it very versatile or convenient in my setup.

I assume you mean cycles for either mainline code? VBI doesn't run during the display so there shouldn't be much contention with DLIs, unless your VBI is running late (ie. into your screen?) That's my understanding anyway, could be wrong/not 100% understanding the issue you are seeing at all.

Just got a XEGS package actually, box is a little beat up, but everything works.

It is well known on the cc65 side... I guess mostly people use the provided header files with function declarations and don't provide their own usually. I remember having this issue a long time ago myself, due to not having the function declaration for some system function (I think cgetc). As Karri said, the __fastcall__ syntax is a cc65 addition that makes for smaller and faster code. Glad you got it figured out! Check out this page for other tips on using cc65: http://cc65.github.io/doc/coding.html

What is the assembly code being generated? (check out -T, and --listing <file> arguments) Can you post the smallest example code that fails?

It's entirely the good will of the community, and respect for the Author's wishes that is keeping it from being pirated, nothing to do with the medium it's being sold on. That this doesn't seem to be understood is the truly odd thing. But, in the end, it's their product to do with what they will... We can all agree to disagree on their reasons for that.

Sure, but on the PC, you could upgrade all these things piece-meal and keep backward compatibility. At least that's what I did. I went from Atari 8-bit straight to 8086 XT PC, then upgraded piecemeal to 286, 386, 486, Pentium, etc... keeping some of the stuff I used to use. Also, ditto with the graphics and sound, Hercules to CGA, to EGA, to VGA, to SVGA, etc... Sound was also pretty easy to upgrade and keep some capability (Sound Blaster seemed to be the base/common denominator there.) Usually software would run fine on the next iteration, even two or three iterations. Same with the OS, I went from MS-DOS 3.3 up through Windows and everything worked pretty well. Of course, trying to run the software I ran 20 years ago on a PC now might be problematic (we'd use emulation or virtualization to do that now), but at the time, you could quite capably run your "old" software until it was naturally deprecated. That coupled with the fact that the PC was ubiquitous in business is what lead to it's dominance of the computer industry.