Christopher Tumber

Uh, no. colours.zip

Mr. Driller = Tetris + Boulder Dash Chris...

All my souce code is just fine. My computer came through okay, except my monitor which was slightly melted (stuff that was high off the ground got the worst of it from heat and smoke). Big Dig is still in development. It's stalled a little because of some major logic issues (essentially, the grouping of like coloured blocks is quite labour intensive and I was having problems getting it done over few enough frames to keep the action smooth). That and I'm easily distracted. Chris...

I've just finished PAL50 and PAL60 conversions of Space Instigators. They should be available through Atari Age shortly. There's no speed compensation for the PAL50 version, I can't see any way to do it without fairly major revisions (several objects depend upon the framerate for their timing) and given how long it's taken me to get these relatively modest conversions done I wouldn't expect that to happen anytime soon... Chris...

There's no PAL version of Space Instigators yet. I remember a lengthy conversation on Stella list about PAL conversions. Did we ever reach a consensus on what was sufficient? Most NTSC to PAL conversions simply modify the colours and leave the scanlines at 262 and 60hz. My understanding is that most PAL tvs don't have a problem with this (?? Does the result look letterboxed or squished or does it look right?) I was hoping to eventually do a "real" PAL conversion, but I don't know if that will ever happen (fixing the timing to run properly at 50hz is a big problem). However, if just changing the colours is "good enough" that's a really quick fix that I could have done right away. Chris...

The comparrisions I've been making are between: A short story vs a novel. A half hour sitcom vs a 3 hour movie. A single vs a concept album. One is not inherently "better" than another (except for personal taste) but they are very different experiences with their own strengths and weaknesses. Chris...

Hrm, you know I just realised that this kind of thing is used all the time: ldy #19 nextsetup: lda (pointer),y sta table,y dey bpl nextsetup Where table is a table of values in RAM (That is, moving a bunch of data from ROM to RAM based on a pointer) which is almost always otherwise refenced as zero page (not absolute). So I'm not sure what the real best answer is here, if there is one. It could still be an error that could be overridden through the use of .w but I'm a little less sure that's really ideal. Should definately be a warning though... Chris...

Yeh, the error dew2050 made is similar to this one: #include #include int variable1; int variable2; printf("Hello Worldn"); void main(void){ /*some code in here*/ } In essence, you tried to put code outside of any subroutine. You'd have just the same problems in C if you tried to insert code that was not "anchored" in a subroutine. The ORG statement tells the assembler where to start putting code. Being without an ORG is like being without a subroutine in C. The order of subroutines doesn't matter in C because the compiler always sets the code to start running at main() even though the actual sequence of code in the final compiled binary is completely different. You can do the same thing in assembly, but you have to implictly set it up that way - That's what ORG is for and that's what those two pointers you have at $FFFC are for. There's no real reason* other than convention NOT to put your data tables at the start of your ROM if you want to but again, you'd have to set it up properly so your program starts running from the right place. This kind of thing is the very essence of the difference between a high level and low level language. Like the difference between a standard and automatic transmission on a car. A high level language will shift gears (allocate ROM and place your code seamlessly) for you while in a standard you must shift gears manually (place code explicitly yourself). The former is easier drive, particularly for a beginnner. The latter gives the driver more control and is generally more efficient resulting in a faster vehicle (Yeh, yeh you'll hear claims of great compilers that can generate faster, more optimised code then humans. And I have a really nice bridge I'll be listing on eBay next week...) Chris... *Atari 2600 will often put their display kernal at or very near the begining of ROM. This is so that as you add code later you are almost always adding it after the kernal. This avoids moving the kernal around which can cause timing problems ie: Moving a loop around so a branch instruction suddenly crosses a page boundary.

Yes, because the assembler tries put the included file right where you have the INCLUDE command which in this case is before all the rest of your code. And given it's probably before any ORG statements this is a real problem! (The assembler doesn't know where to put the PFData tables). An include file consisting entirely of label definitions and/or macros is the only include file you're going to put at the very top with VCS.H and MACROS.H. Labels and macros don't really care because they aren't "anchored" to any specific place in ROM. However any code or data must be put in a specific ROM location. In other words, include File1 include File2 include File3 Will give you a completely different result than: include File3 include File2 include File1 Just like: lda #$10 sta $80 Is completely different from: sta $80 lda #$10 All the INCLUDE command does is drop the included file directly in that spot. If you put everything back into one file like it was originally, would it make a difference if you moved all those PFData tables to the very start of your code? That's what you did by putting the include up there. If you have to, think of an include file as a super label. So just as: TMP EQU $80 LDA TEMP is really just: LDA $80 because the label TEMP gets replaced by the $80. So too your INCLUDE statement gets replaced, right there, with the contents of the included file. Chris...

Yes. That's really all the line: include vcs.h does. Yes, there's always another way. Here are a couple suggestions... If the blank lines are a known constant, then at the top and bottom of the screen (ie: Before and after you actually start drawing) you can add something like: lda #10 nextblank: sta WSYNC dex bpl nextblank where #10 is the number of blank lines you need. If the number of blank lines is not constant (ie: You're writing a general purpose screen display routine that could display any of several different "bitmaps") then you can turn taht #10 into a variable. Or, you could include it all in your graphics data like: ldy GraphicsData ;Get number of blank lines at top nextblankline1: sta WSYNC dey bne nextblankline1 ldx #0;Index of graphics data ldy GraphicsData+1 nextdrawline: sta WSYNC lda GraphicsData1,x sta PF0 lda GraphicsData2,x sta PF1 lda GraphicsData3,x sta PF2 nop ;Some NOPs in here, I'm not going to cycle count nop lda GraphicsData4,x sta PF0 lda GraphicsData5,x sta PF1 lda GraphicsData6,x sta PF2 inx dey bne nextdrawline ldy GraphicsData+2 ;Get number of blank lines at bottom nextblankline2: sta WSYNC dey bne nextblankline2 GraphicsData: .byte 20;10 blank lines at top .byte 150;150 lines of graphics .byte 22;22 blank lines at bottom GraphicsData1: .byte ;150 bytes of data for left PF0 GraphicsData2: .byte ;150 bytes of data for left PF1 GraphicsData3: .byte ;150 bytes of data for left PF2 GraphicsData4: .byte ;150 bytes of data for right PF0 GraphicsData5: .byte ;150 bytes of data for right PF1 GraphicsData6: .byte ;150 bytes of data for right PF2 You can further abstract that by using indexed indirect addressing: lda (),y but that should wait until Andrew explains the more advanced addressing modes... Chris...

I think you do if you're going to be mixing 8-bit and 16-bit labels. Consider a similar example in C int NumberFinal; char NumberInput[20]; scanf=(&NumberInput[0]); NumberFinal=atoi(&NumberInput[0]); NumberFinal and NumberInput represent the same value but different variable types which is basically what you're doing above. Or maybe it's closer to a local/variable relationship. Okay, neither is exactly the same situtation. but the fact that we can have this conversation indicates that there is a potential problem here and it should at least throw up a warning. I'd suggest that an error or warning be generated but that an explicit override should be available, for example: TMP EQU $80 LDA TMP,X LDA.w TMP,Y Would be perfectly valid. The .w essentially says, "Yes, I meant to do that" while any actual ambiguity should at least generate a warning. Chris...

IMHO, it should try to assemble it as LDA $80,Y and throw up a warning or an error. So, anyone want to verify how: TMP EQU $80 BAD LDA TMP,X Assembles? That's not really true - What about constants: TMP EQU $80 lda #TMP Which of course works, while TMP EQU $0080 lda #TMP Will presumably throw up an error. Chris...

I'd settle for a warning but I think a command line switch to turn "optimisation" on and off would be the best way to go. Have it default off and then assembling any old code would simply involve turning it on. (If it defaults to on we're back to square one since you have to be aware the assembler is going to try to optimise your code in order to turn off optimisation. If you're already aware of this behaviour you're already going to be making allowances for it anyway. So you don't really need the on/off switch.) IMHO something like lda $0080 should be handled the same way. Either throw up a warning, or, assemble it corectly (Absolute, not Zero Page) unless the "optimisation" switch is on. In general I want an assembler to assemble exactly as written and not try to guess what I mean. And in particular if someone is doing something like lda $0080 on the 2600 it's probably for timing in the Kernal and they're expecting that extra cycle. Yes, I know about .w but you shouldn't have to hunt down some obscure syntax in order to get the assembler to behave properly. Sure in both these cases the first time the assembler bites you on the ass by not behaving correctly is going to be the last. You're going to remember that 3 hour debug and never make that same "mistake" again. So the only people really affected are n00b's. Do you really want to saddle n00b's with an idiosyncratic assembler? Anyway, I didn't mean to turn this into a big assembler design debate in the middle on Andrew's excellent lessons. Please, carry on... Chris...

I know everyone's heard me piss and moan about this on Stella List, but I don't think I've mentioned it since you took over maintenance of DASM so I'm going to mention it here: lda $80,y Should throw up an "Illegal Addressing Mode" error. It should do this because: A) It actually IS an error. There's no such thing as lda $80,y B) The assembler shouldn't be trying to read our mind and ASSUME we mean lda $0080,y - there are certainly plenty of other errors where the assembler could try to guess what we really mean. This is the only one. Why? C) It's very likely that this represents some other error that's going to be a bitch to debug if DASM doesn't flag it: If either it was supposed to be lda $80,x or lda $FF80,y it may not be obvious to spot. D) This is a very common error for programmers making the transition from other CPUs (ie: 6809) which actually do have valid lda $80,y (I know I did it all the time at first) Chris...

Maybe you should scale it back and just consider a graphics hack. I'm sure you could find someone to make you a graphics hack for a couple hundred bucks. Chris...

$5000 is a bargain! Do the math, at minimum consider the legendary Pac-Man which was supposedly slapped together in, what, 2 weeks? $5000/80hrs is only $62.50 and hour. If the game takes 4 weeks, that's $31.25 an hour. Can you even hire someone to design a website for $30 an hour? (Sure the kid next door, but I mean a pro web design company) If the project takes much longer, you're going to quickly fall below minimum wage - Manuel's estimate of 2 months, 10-12 hour days (I'm assuming week-ends off) is 400 to 480 hours which is $10.42 to $12.50 an hour. Not quite flipping burgers but pretty close... I'll do it for $50.00 an hour. $50.00/hr is very reasonable, even in today's market, for a specialised IT professional. My estimate for a 4k game is 200 hours though the nature of the project is a little unlear and that could be WAY off: ie: How much game design is involved. Is Tommy going to provide a detailed spec or is it just "I want a KISS game" and I have to design the game too? It also depends on the scope and technical sophistication of the game. If something on the level of Artilery Duel is all you need you can easily cut the time in half. If you want something cutting edge for which new tricks or techniques are required or a larger game, it could climb exponentially. I'd need more information on design specs before making a concrete evaluation. The one absolutely non-negotiable deal-breaker catch is that if it's going to be a licenced game, like KISS, you absolutely have to actually have the licence. It's one thing to write a clone that sorta, kinda looks like the original and they could MAYBE make some trouble for you but the money involved is well below their radar so it's never going to happen. But for a contract like this involving an obvious paper trail with real money and using an actual trademark it absolutely has to be 100% squeaky, squeaky clean. Chris...

I have a socketed Colecovision PCB, so I could test it for you. However, as far as manufacturing carts you're probably on your own. There should be a supply for PCBs (the one I'm holding in my hand is evidence of that). I got mine from SylvainDC so you should probably ask him if somebody's manufacturing them. I haven't spoken to him in a while and I know he's recently moved but his webpage is still at www.chez.com/slydc/ You might also contact Daniel Bienvenu, whose webpage you have linked on your site. Chris...

The TRS-80's are all desktop computers (micro-computers). They used cassette drives or 5 1/4" floppies. They did NOT use 8" disks, nor were their monitors particularly large. You're thinking of something else. http://www.kjsl.com/trs80/ (The TRS-80 Model III was the first computer I ever really used) For first platform game, I would nominate Stunt Cycle (Atari, 1976) as the embryonic platform game. Chris...

Yeh, I wrote a Vectrex disassembler when I did Spinnerama (FYI a multicart featuring a controller hack). My disassembler was quite simple, however, it didn't trace any code. It started by assuming everything was code. I'd then look through the disassembly by hand and add sections which should be data to a .ini file and then redo the disassembly. Areas which should be data are generally pretty obvious because you get a bunch of illegal instructions if you try to disassemble them. Since I was dealing with 4K/8K ROMS this wasn't a big deal, it usually only took a few retries to get a reasonable looking disassembly. There were probably some parts that weren't code that should've been data or vice versa but I didn't really care. I just needed a disassembly that I could find where to hook in my controller hack and then make the game relocatable (In order to fit a bunch of 4K/8K games onto a 64K EPROM without going to bankswitching hardware). Relocatable was the hard part if the game used any sort of indexing but in most cases it wasn't a huge deal (Just look for ,y or ,x and firgure where y or x is pointing...) Depending upon what someone wants to do, a similar method could be used for bankswitched 2600 games. If you want a comprehensive, annotated disassembly this isn't really going to be ideal. But if you just want to find out how something specific is being done (like the 6 digit score routine was) this would be okay. Or, how about running the game in z26 with -t. Then using a grep-like tool to pull out valid code addresses and build the kind of list I mentioned. Then do the disassembly based on this list. The downsides are pretty obvious - You're going to have to play through the entire game to get an accurate disassembly and any obscure areas of code that only rarely get called for whatever reason may resist being properly disassembled. And running a game with -t is pretty slow (at least on my system...) and results in a huge log file. Maybe if a log file could be generated with only the current address (skip all the other fields - registers and flags, scanline #, &etc) it might be more feasable. Distella does support the kind of config file I'm talking about with CODE/DATA labels... (I realise the idea of using an emulator to disassemble is not new but maybe this is a way to make it work...) Chris...

This is really key and I should have elaborated further. What you propse is actually very likely to have the opposite effect to what you claim to intend and actually impede new developers from learning to code. If someone wants to do a graphics hack "the hard way", by modifying source code, they're going to have to learn a few things. Not nearly as many things as a real coder, but, they will learn to use a disassembler and assembler. They will become familiar with what code looks like and they will start to see what a kernal looks like and what sprite data looks like. Most importantly they will become increasingly comfortable with the whole process so if the time ever comes that they actually want to code they've already started. On the other hand, using something like Hack-O-Matic is an awful lot quicker and easier, particularly for the layman. But nobody learns anything. That's fine for all the people who never had any interest in coding. But at the same time, what about the person who started out just looking to do some graphics hacks, but after poking around some source code discovers they have a taste for it and it's really not so intimidating now that they've been at it a while... Chris... (That really isn't intended as a slam at Hack-O-Matic! All I'm saying is that there's a tradeoff to be made as you abstract the process out. Making something easier is not always doing people a favour.)

Really? I lived in Markham for a year and did my final year of high school at Markham District High. Man I hated that school! I have only one semi-decent story from that time - Our Calculus teacher wouldn't allow calculators in class. To do logs, these stupid little books of log tables were provided. I brought in a slide rule. Fight the power! Ah, teen rebellion! Such a little hellion was I... (This was about '89 or '90) Markham District High had the reputation for being one of the toughest schools academically in the Toronto area. It wasn't, what it REALLY had was teachers who were complete pricks. (Obviously not allowing calculators in high school math class is not unusual, that's not why I'm calling them pricks [Though forcing students to use log tables instead of calculators is pretty freaking stupid... Boy, they're sure going to be glad they learned THAT skill...]) Chris...

They're also not being taught assembly language much anymore. So, can we expect a C++ compiler for the 2600 from you anytime soon? For that matter, the 2600 would be a lot more attractive for potential developers if it were net enabled. So will you include a web browser too? I expect some would appreciate it if you held their hand while clicking the mouse. Will you be there for them as well? Classic consoles are obscure, esoteric, specialised areas of knowledge. Part of delving into obscure, esoteric, specialised areas of knowledge involves a little bit of ambition, a little bit of perserverance and a little bit of self-motivation. If someone's completely unwilling to make the leap from GUI to CLI, why would they ever be interested in going from 512M RAM and 1GHZ CPU to 128K RAM and 1.19 MHz? I just don't buy it. Did YOU miss a post? The development environment is the EASY PART. Anyone who can't even get past DOS is not going anywhere as far as serious 2600 development. It's like wanting to be a racecar driver but being too intimidated to learn how to drive a stick. If you can't even manage a standard transmission, what're you going to do when you're boxed in at 500 mp/h with cars inches from your bumpers? Umm, we're not the ones who are discontent, you are... For instance? Well, networking. If for some reason you want your assembler to use TCP/IP then sure Windows is the way to go. But otherwise....??? Well, which do you want, hack tools or dev tools? They're completely different things and using a hack tool isn't really getting anyone closer to actually learning code than playing the game is (can you say script kiddie?) If you want to make some hack tools, make some hack tools. Why do you feel a need to pretend you're looking for dev tools? Which isn't to say a hack is a bad thing, if it's the first thing you've ever gotten running on a computer I'm sure it's pretty freaking cool. And all hacks are not created equal (Adding new levels to an existing game is several orders of magnitude greater than editing some sprites, for example). But, if you really want to bring the "next generation" (Hey, I've been writing 2600 code for less than 6 months, I *am* the next freaking generation!) into the fold they'd be a lot better served by a truly comprehensive set of tutorials starting with, "Welcome to the exciting world of assembly language" up to "How to design the labels for your newly completed 32k Atari 2600 game". Why don't you get on that? Well no, all other views have been that it's not worth the trouble because everyone's comfortable with DOS while your proposals seem largely cosmetic in nature and don't offer much in the way of a real increase in productivity and nobody else sees the current tools as holding back the 2600 renaissance (which you may not have noticed is kinda happening anyway...) But hey, if you want to make tools, go ahead and make tools. Maybe one day we'll all be marvelling at how we managed so long without them but you're obviously not going to be overwhelmed with volunteers to do the work for you. If you're serious there was recently a thread on Stella list about possible improvements to DASM now that Andrew's taken it over. That conversation more or less dovetails with this one, though in a slightly more realistic fashion. Yeah, you caught us. We're all secretly Luddittes, just pretending to be technophiles. Chris...

Blink. Blink. Okay, let me get this straight. These guys are all set to A) work in assembly language on B) an obsolete console with C) extremely sparse resources and D) particularly esoteric and difficult video hardware BUT having to run DOS apps which are functionally almost identical to what a Windows version would do is just too much of an impediment? This may sound elitist as hell, but, really, dealing with DOS is the least of their worries and it sounds suspiciously like kids who are really, really dedicated to being the next great guitar god except the blisters on their fingers really, really hurt... I've said similar before and I'll say it again. Working with these classic consoles is like playing the accordian. If they're not really, really into for its own sake and if they can come up with any excuse not to do it then they shouldn't. They're much better off sticking to Java or Visual Basic or Flash or whatever and actually enjoying what they're doing... Chris...

They're probably PAL games... Chris...

Actually, this is on my todo list - To check and modify all 2K and 4K games to work on the Supercharger (Like Thomas' Pal2NTSC hacks). I think I got through testing up to the letter "B" before getting distracted by other things. (Yeh, the letter "B" - Damn you ADD!) It's a bit tedious... Chris... Yep, here it is: Legend ====== Crashes or otherwise does not function correctly Starts up but not thoroughly tested Tested thoroughly Modified to work on Supercharger 3-D Tic-Tac-Toe (1978) (Atari) Action Force - Action Man (Parker Bros) Adventure (1978) (Atari) Adventures of Tron (Mattel) Air Raid (PAL) Air Raiders (Mattel) (1982) [!] Airlock (Data Age) Air-Sea Battle (1977) (Atari) Alien (20th Century Fox) Alien (CCE) Alien Invaders Plus Aligator People (20th Century Fox) (Prototype) Amidar (Parker Bros) Apples and Dolls (CCE) Armor Ambush (Mattel) (1982) [!] Assault (Bomb) Astroblast (1982) (Mattel) [!] Astroblast (1982) (Mattel) [a] Astrowar (Starsoft) Atari Video Cube (Atari) Atlantis (Activision) [a] Atlantis (Activision) Atlantis (CCE) Atlantis (Imagic) [!] Bachelor Party (Mystique) Bachelorette Party (Playaround) Backgammon (1978) (Atari) Bank Heist (CCE) Barnstorming (Activision) [!] Barnstorming (CCE) Basic Programming (1978) (Atari) Basketball (1978) (Atari) Beany Bopper (20th Century Fox) Beany Bopper (CCE) Beast Invaders (double shot hack) Beat 'Em and Eat 'Em (Mystique) [!] Bermuda Triangle (Data Age) Berzerk (Atari) Berzerk (CCE) Better Space Invaders (1999) (Rob Kudla) [!] Blackjack (1977) (Atari) [!] Bobby is Going Home (CCE)(PAL) Bogey Blaster (Telegames) [a] Boom Bang (Cooper Black) Bowling (1978) (Atari) Boxing (Activision) [!] Brain Games (Atari)