Urchlay

Is the thumbstick that screws into the CX78 gamepad as breakable as it looks? I've got a CX78, but it didn't come with the stick... seems like it'd be more comfortable to use with the stick attached (would change the angle of the thumb, anyway), but I don't want to go on a quest to track one down only to break it the first time I try to use it. (For reference: I bought a Gravis gamepad in '98 or '99 and broke its thumbstick literally 10 seconds into the first game I played with it... Galaga on MAME, I guess I was trying to treat it like an arcade controller...)

Everything has its time and everything dies... ...but if he's not running it outside its usual temperature range, I don't see how it'll just up and die after a few weeks of continuous use. Sure, all parts eventually fail. The console has a rated MTBF (though I don't know what it is; probably in the tens or hundreds of thousands of hours). Call it X hours. It's expected to fail after X hours of use (on average), and never mind whether those X hours occur all at once or an hour at a time. Actually, powering it up is a lot more stressful to the components that letting it run for a while (at least, this is true of electronics generally). Hm, I know what I forgot: humidity. I doubt that'd be a real problem in any place where humans live comfortably, though. I still would use an emulator for this, myself...

WRONG OK, I'm wrong... ...so can you explain why, so I won't go around telling people this wrong answer again?

You'd probably be OK leaving it on for weeks, if you keep it in an air-conditioned room and cool it with a big box fan. You could set things up so the fan blows on both the console and the power brick... assuming heat is the only concern, anyway (and what else would there be?) I know I used to leave my Atari 800XL on for weeks "back in the day", but it was pretty new then... and I remember having a bad power supply at one point, so maybe that wasn't a very smart thing to do This isn't a very serious suggestion, but... if you had a variable transformer, you could try running the console on less than standard voltage. 90 volts would probably be enough to power it without glitches, but keep it cooler than usual (assuming you're in the US where main are 110-120 volts). It'd be a pretty expensive piece of equipment to get just for something like this, though... when I was a kid, my grandfather had one, World War II era, which I got to play with (and I bet Dad still has that old monster somewhere. Note to self: ask him). Tube guitar amps can sound pretty raunchy if you run them at 90-100V. What about using an emulator for the "how many spiders" quest? You can leave your PC powered on for a long, long time (most good boxes will run for years, if you have a UPS), or you could use Stella and its "save state" feature to pick up where you left off. OTOH, an emulator is never 100% accurate: if the limit on spiders is a hardware limit, an emulator might be able to show more (or fewer) spiders than real hardware. I suspect the limit is soft, though: I bet the game has a coded-in limit that it won't exceed. Actually, if you know 6502 asm at all, you could probably find out whether there's a soft limit pretty quick, using Stella's debugger (plug plug plug!) Er, that's if you're talking about the 2600 version of the game (you said you were using a 7800, but this is the 2600 forum). I dunno if any 7800 emulators support saving state (maybe MESS does?)

You could try MASM32: http://www.masm32.com/ However, it's got a completely insane license restriction. From their license page: "The MASM32 project cannot be used to create open source software or any other project under any form of licence that requires the user of the MASM32 project to surrender the rights they are afforded under the MASM32 licence. In particular the MASM32 licence completely excludes projects licenced under the GNU organisation's published GPL licence and/or variants." Since PCAEWin is under the GPL, you wouldn't be able to use MASM32 to compile it (at least, not if you were planning to ever give anyone else a copy). Otherwise, you might look for MASM from Microsoft, which AFAIK has no such restriction. You probably can't get it for free, though. Borland's assembler that comes with their C++ package is probably Turbo Assembler, which isn't quite MASM-compatible. I think it maybe has a command-line option to turn on "MASM mode", but it's been so long I can't remember... I've also got an older version of MASM32 that I'm pretty sure doesn't have the "no GPL" license restriction, which I suppose is legal for me to give to you (the documentation says it's "freeware"). Try here: http://www.hardcoders.org/masm32.rar ...time passes... OK, I actually tried to assemble those two .asm files with "my" version of MASM32. One of them (process.asm) assembles fine if you add the /Zm option ("ML.EXE /Zm process.asm"), but the other one chokes with or without /Zm ("hand_tia.asm(80) : fatal error A1010: unmatched block nesting"). Presumably this wouldn't be hard to fix... ...more time passes... Yep. In "hand_tia.asm", change line 80 from "ends" to "TIA_RegList ends", change line 125 from "ends" to "TSave ends". Also, change every occurrence of the string "Addr" to "Adr". I've no idea whether the resulting object will actually link correctly with the rest of PCAE (depends on whether that "Addr" is visible to the Delphi code or not), but at least you can make a start on getting the assembly code to work now. One other possibly useful thing: There's a MASM reference manual at http://www.cs.wayne.edu/labPages/masmref.htm

I don't know much about Delphi, so I don't know if this is realistic or not, but... How likely would it be that someone could use Kylix or CrossKylix to compile a Linux executable of PCAEWin? Kylix: http://www.borland.com/products/downloads/...load_kylix.html CrossKylix: http://crosskylix.untergrund.net/ I'd be willing to make the attempt myself, but it'd probably be better done by someone who knows what they're doing, Delphi-wise... It's probably more than just a matter of a recompile. For one thing, there are a couple of files written in x86 assembly that look like MASM syntax (or maybe Turbo Assembler, it's been a while). I might be able to do something with those (I ported z26 to Linux, about 10,000 lines of MASM-syntax assembly there... PCAE only has about 2,000 lines) It's just a thought...

Works great - but I had to use breakif { pc==yourLabel && _bank==0 } else it complained about Invalid Word Argument Heh, it's been so long since I did anything with the debugger, I forgot my own syntax... One thing I want to add to a future version of the debugger is a way to disable breakif's without actually removing them from the list. That way you won't have to type "breakif { pc==yourLabel && _bank==0 }" over and over again. I should probably go ahead and make "_pc" a synonym for "pc" (and do the same with the other registers). There actually is a good reason why "_bank" has the leading underscore and "pc" doesn't, but it does make it annoying to remember which gets the _ and which doesn't.

You're welcome... The fact that people are actually using it makes me a happy camper One thing you could do would be to use: breakif { _pc==yourLabel && _bank==0 } ...instead of a simple breakpoint. The downside of this is that you can't just click on the disassembly to toggle a breakif, so you end up having to type it again when you want to enable it again (or at least you have to find it by hitting the up-arrow a lot). ...or you could use different RORGs for your banks as batari suggests. At some point, though, I do want to use bank+PC for regular breakpoints. It'd be quicker than using breakif, and more intuitive.

Hey, this is B. Watson, the Stella debugger guy. I created an account last night, just so I could reply to this... Apologies for the long post. The debugger sees what the CPU would see. Reading from PF2 doesn't return the value you wrote to PF2 because PF2 is a write-only location... you'll get whatever garbage value (AKA "bus noise") you'd get if your program did "LDA $0F" (probably, you'll get $0F, since there's no TIA read-only register at $0F). Really? I'll look into that... ...time passes... ...well, the WSYNC strobe at least works. Click it, then do a Step, then click it again, do a Step, etc... should be obviously working: the TIA should draw a new scanline for each Step. However, multiple clicks don't do anything, because the TIA isn't running until you step some code (the WSYNC strobe won't occur until the emulation starts running again, and there's no place inside the TIA to "queue up" multiple strobes that occur between clock cycles). In fact, that's generally true for all the strobes: they don't have any effect until you step some code, because the TIA is paused while you're in the debugger. I should make the buttons light up when they're clicked, then reset them when the emulator runs. That might make their function a little more obvious... The RESP0 and P1 strobes also definitely work. I just managed to totally mangle a 6-digit score by hitting RESP0 in the middle of the scanline There's one possible reason why the strobes are working for me but not for you: I'm using Linux, and you're (probably) using Windows. I can't really check the Windows version right now (the only Windows box in the house is being used by my roommate to play "City of Villains", probably for the next 6 hours non-stop), but I will when I get a chance. Stella is supposed to be 100% cross-platform, but nothing's perfect. One other thing you might try: see if the latest nightly build from http://www.hardcoders.org/stella_nightly/ shows the same symptoms. I haven't changed anything in the debugger since 2.2 was released (or even since 2.1), but Stephen may have fixed the bugs you found without me noticing. Huh? I just tried it, double-clicking the boxes, and it worked fine. There's not really a place to enter GRPx values directly in the TIA tab, though you can use "poke GRP0 aa" or whatever in the prompt. If you can tell me how to duplicate the problem with setting GRP0 via the boxes (with a common ROM, breaking at a specific address, etc), I'll take a look. I assume you meant to say "shows the *write* label"... The label issue is a known problem. The trouble is, the debugger's list of labels just contains the label name and the address, with no indication of whether the label is meant to be for reading, writing, or both. So when it goes to look up the label name for a given address, it gets the name that occurs "first" in the list (and since it's a hash table, the order isn't necessarily predictable, either). The label issue is even worse when you're using a DASM symbol file: In Poker Squares, I've got a symbol called PAL, whose value is set to 0 in the NTSC build of the ROM... when I click on the leftmost TIA byte, the label that gets displayed is PAL, not CXM0P nor VSYNC. Ugh, and I've just discovered something else: Removing the symbol with "undef PAL" doesn't help. The next version of the debugger will be smarter about this... They return the same value the CPU would see, including "bus noise" caused by reading unconnected data lines. Bits 0-5 aren't connected to anything in any of the TIA read locations (and bit 6 isn't connected in about half of them). The unconnected bits will read as whatever value was last on the data bus, which will be the low byte of the address you're reading from... If you watch while single-stepping through code that doesn't affect the TIA, you should see that the top bit (bit 7) doesn't change in any of the values, and that bit 6 doesn't change in the registers where it's connected (all the CX* collision regs except CXBLPF). Only bits 7 and possibly 6 will reflect the TIA state, because the other bits aren't really part of the TIA at all (they're effectively wires that hang in the breeze). This is really the same thing as you're seeing in #1 about the breakif, above: the debugger sees what the CPU would see (because it's actually using the emulated CPU to do the reads). This might seem confusing at first... I could change this behavior, but I thought it'd be better for the debugger to work this way. If the debugger shows one value, but the CPU sees another, it'd be even more confusing (or so it seems to me). I could also get rid of the raw display of the TIA bytes entirely, if they don't seem useful to anyone... all the same information is available in decoded form (or will be, when we add the INPTx register display). However I think seeing the raw bytes will be useful, and is worth the learning curve. Hm. That's not supposed to happen, will have a look. Again, not supposed to happen... I didn't write (and don't fully understand) the TIA emulation core, so I probably screwed up the interaction between the debugger and the TIA. I haven't been very active in Stella development the past few months. Hopefully that will change soon. -- B.