Christopher Tumber

IMO you're approaching this backwards. regardless of which system you choose to dev for, you have a lot of hours of learning and work ahead of you. Picking the "easiest" system just means X/2 hours instead of X hours. But that's irrelevant if it's not a project you're going to enjoy putting potentially hundreds of hours into. As an example, I personally love the Virtual Boy, however, a lot of people hatehatehate it. Suppose you're one of those people. So what if everyone in this thread came to the agreement that Virtual Boy is the easiest to program for. What would you do? Instead of "what's easiest" I suggest you ask yourself: What is your favorite system or system(s)? What project specifically do you want to develop? (ie; a clone or an original concept?) Which of your favorite system(s) lends itself best to this project? (ie; if a clone, does one already exists on some systems? if an original concept what are the technical requirements?) What are the production issues related to your prospective systems? Some systems are a lot easier to produce physical cartridges, or have them manufactured entirely for you. Or so you want to design your own PCBs, possibly with custom features? Don't overlook production, unless you're going downloadable ROM only these have the potential to put your project on the shelf until resolved. The hobby is littered with dozens of unfinished projects. Unless you absolutely love what you are working on, it's highly likely you will be another one of these. While the learning curve on most systems is considerable that's going to be the case regardless and it's just a matter of degrees. So IMO it's much better to take on a slightly more ambitious project that you're enthusiastic about than an "easy" project that you're going to loose interest in half way through. If you're going to compromise in order to ensure an attainable project, compromise on game details (ie; don't try to push the envelope technically, don't design 75 fully animated sprites to populate 50 highly detailed levels) rather than the core.

Why is it appropriate for other people to do your work for you? Because you downloaded it from an EMU ROM site (or Torrent derivative) like Zophar's or something who, along with ROM checkers like clrmamepro have been misplabelling homebrews for at least 15 years. The "funny" part is that's exactly what people selling ROM CDs on eBay for $20 would say when I'd have eBay shut them down. Le plus ça change. No. Not that it matters. Shareware isn't public domain either.

No, absolutely not.

Everyone hitting F5 waiting for the fireworks...

Then I would like to offer you, and everyone else who follows with similar projects - as this is a recurring issue - the following two pieces of advice: 1 - Stop calling things "public domain" which are not. Clarifying the rights, ownership or permissions issues of any works you plan to redistribute is your number one job. The copyright status of the original Vectrex games is not an obscure bit of trivia. Nor are homebrews. 2 - Before announcing, "Hey guys, I'm going to be mass distributing all these works even though I have no idea what I'm doing or any of the provenance. How awesome is that?" Something like, "I'm looking for contact information for Vectrex authors, developers, modders and rights owners for a potential project. Can anyone help?" might raise a few less hackles.

How about spending the effort expanding and organizing the wiki, with links to the applicable developer, modder, &etc sites instead? http://vectrex.wikia.com/wiki/Vectrex_Wiki

And I found a website that says Elvis Presley was behind 9/11. So what? The people running ROM checksum lists and ROM sites don't care. They've been mislabeling stuff as PD, particularly homebrews, since the mid-90's. None of my material is public domain and you do not have permission to redistribute any of it.

Actually, thinking about it further - I'd completely avoid timer interupts unless you're willing to turn the interupts off at critical times (which may defeat their purpose). I could easily envision a situation where you're pushing values onto a register(s) to start drawing, a timer interupt happens, and that results in a very visible problem with your drawing.

Harvey, Where are you in Ontario? Please Facebook me as I don't get around this way much anymore.

Yeah, V-Model was something I threw together in an afternoon or so 'cuz I got tired of graph paper and particularly doing rotation sequences by hand. Kinda amazing people are still using it. Def nice to hear!

Wow, people are still using that thing? Chris Salomon did vfrogger, btw. His work was hugely pioneering - Using the hardware wait states to do game processing and calculations instead of the more standard [frame] [calculations] [frame] model. I did write a tutorial back in the day, but it's much more of an intro to 6809 programming than to Vectrex hardware (never got back to it...) http://www.playvectrex.com/designit/christumber/tutorial.htm

Wow, I remember that, that's a loooong time ago. IIRC I was trying to abuse the Kool-Aid man bug which turned out to not be a PAL artifact but a TIA version issue. Yeah, here it is: http://www.biglist.com/lists/stella/archives/200211/msg00098.html Based on the archive search, it looks like this discussion has been had several times. If only there was a VSYNCH equivalent to WSYNCH then you could just setup the timer to see how long between frames...

It's an earlier (or later) version of this list: http://www4.ncsu.edu...S/2600list.html Your first page probably has the version # so you can compare how different this one will be.

http://www.atariage.com/forums/topic/199475-what-defines-a-rogue-like-game/ http://www.atariage.com/forums/topic/172686-destiny-wip/ Adventure and Venture come to mind.

Sorry, I mistyped, Instigators masks by skipping a strobe to RESPn. Not sure it makes a difference in the end but NUSIZn never changes. (we'll, may be a little simpler than changing NUSIZn).

Oh, btw, Instigators does masking by substituting RESPn with a dummy register, like: sta RESP1,x ;4 sta RESP0,x ;4 sta RESP1,x ;4 sta $80,x ;4 (skip this one) sta RESP1,x ;4 sta RESP0,x ;4 sta RESP1,x ;4 sta RESP0,x ;4 Problems do arise and exceptions need to be handled when gaps are too wide for NUSIZn copying. However, this gives you another option for masking that might be useful when you run into the display priority problem. ie; when the stickman is over a baloon, mask it by skipping the NUSIZn strobe instead of using the playfield. You'll only ever have a gap one sprite wide so no exception handling...

And just realized that because the hard scroll is 3 pixels with a 4 pixel gap between sprites, the widest object that can be scrolled smoothly is 5 pixels. So somewhat limited in usefulness.

This is because you`re altering GRP1 while the sprite is being drawn, right? I think this might work (haven't tested, maybe this week-end) With the original kernal, use this instead: sta GRP1 sty.w RESP1 This should add 1 cycle/3 pixels between sprites (resulting in 4 pixels between sprites) but allow you to use all 8 pixels in each sprite. In order to do smooth scrolling between the gaps then depending on the actual width of the objects you need multiple kernals each offset by 1 cycle/3 pixels. Kernal1: XXXXXXXX0000XXXXXXXX Kernal 2: XXXXXXXX0000XXXXXXXX Kernal 3: XXXXXXXX0000XXXXXXXX Kernal 4: XXXXXXXX0000XXXXXXXX So two four pixel wide objects scrolling from left to right would progress as: #####XXX0000#####XXX X#####XX0000X#####XX XX#####X0000XX#####X #####XXX0000#####XXX X#####XX0000X#####XX XX#####X0000XX#####X #####XXX0000#####XXX X#####XX0000X#####XX XX#####X0000XX#####X XXX#####0000XXX##### X#####XX0000X#####XX XX#####X0000XX#####X XXXXXXXX0000#####XXX0000#####XXX (Need to view with fixed width fonts - cut and paste into notepad or something). Big downside is the increased gap between objects (same as Space Instigators) but OTOH, if you preload A, X and Y with one of them zero'ed you can do masking with sta/stx/sty GRP1 and two different bitmaps per line. And hopefully still have time to do other things...

FWIW, I think you could save a few cycles (and possibly more importantly, RAM) per scanline by unrolling your loops, using constants instead of variables and only having sta GRP1/sty RESP1 in RAM. But that's not going to solve your real problem which is that a smooth scroll really isn't possible using this technique. IMO it looks fine in Space Instigators due to the pacing, sound and animation. Maybe try to approach the problem from that way around - turn it from a bug into a feature? Space Instigators+.bin

You're already using the technique by hammering RESP1. Though using GRP1 as an on/off switch is sweet and would have simplified things considerably in Instigators as there's a bunch of exception handling for when RESPn strobing can't be used (too few objects, gap too wide). This is how Space Instigators does it: position1: STA WSYNC Scan1p: lda (Aliens_Display_Offset),y ;5 sta GRP0 ;3 sta GRP1 ;3 lda Scanline ;3 Cycles 2 Bytes inc Scanline ;5 sta RESP0 ;3 sta RESP1,x ;4 sta RESP0,x ;4 sta RESP1,x ;4 sta RESP0,x ;4 sta RESP1,x ;4 sta RESP0,x ;4 sta RESP1,x ;4 sta RESP0,x ;4 sbc DrawnShot_Pos_Y ;3 Cycles 2 Bytes lsr tax ;2 Cycles 1 Byte lda Player_Shot_Data_Table,x ;4 Cycles 3 Bytes sta.w ENABL ;3 Cycles 2 Bytes ldx #0 ;2 dey ;2 bpl Scan1p ;2 rts ;2

Have you considered using the RESPn trick as used in Space Instigators? Upside: No flicker Downside: Scroll is not smooth Ridiculously complicated; requires self modifying code in RAM and special handling when gaps are too big Eats up a bunch of RAM Scanlines between rows are difficult to do anything with as you're setting up the RAM routine - Unless you want to sacrifice even more RAM by setting each row up in advance.

How long does polling the trackball take? Are you doing anything while waiting for the electron gun to move/draw/reset? If not, you could read the trackball every time you move/draw/reset (or at least every big move/draw). I'd try to plan out your drawing and game calcs so you're reading the trackball at a constant-ish rate. If you poll the trackball 50 times in the first half of each frame but ignore it in the second half, you're still going to get poor results. IIRC the 6809 is capable of interupts but I never used one and it's ages since I looked at the manual. But if you need to poll the trackball so frequently that you need an interrupt multiple times per frame to make it work properly maybe it's just not an appropriate input device. Due to the Vectrex's archetecture, maintaining a stable image at a sufficient frame rate is both the most important and most difficult task. If you've already cranked up the frame rate you may have a serious problem drawing everything you want. Particularly if you're trying for as many potential on screen items as in a Centipede game. My advice would be to skip messing around with exotic hardware for now and run some tests to see the limits of what you can display. If you're hoping to display a screen full of mushrooms you may be in for some difficulty.

It sounds like you're trying to load a binary file into a text editor.

Now that you mention it, it's the ten year anniversary! Yeah, my bad, not familiar with this forum software and had to go back and attach the ROM after the fact.

; - Saucer is slower and comes out less frequently. ; - Shots don't turn off when invaders get low. ; - When instigators get low, houses cleared every frame (makes stability testing easier). ; - Saucer score uses authentic table (100,050,050,100,150,100,100,050,300,100,100,100,050,150,100,050) based on player shot count. ; - Saucer direction determined by player shot count. ; - Instigators speed/speedup changed (may be tweaked based on feedback). I am not currently setup to test on real hardware and this update has not been extensively stability tested. Please post if you experience anything funky (particularly roll, flicker or video glitches). Barring any tweaks to the speed or stability fixes this should be the final version (for at least as long as last time ). The only features which could be added (PAL/NTSC switch, title screen, improved display of shots) would require bankswitching and possibily substantial revision (to free up RAM) which I'm not really interested in doing. (and no way to do proper PAL conversion - with speed adjustment, anyway) The contents of this post, including any binaries or source code, are not public domain. All copyrights are retained by the author. Redistribution in any fashion including but not limited to rehosting, compilation CDs or DVD, multi-carts or cartridges is strictly prohibited. Sp+.bin