superogue

hi, i've added those to re-release section. as they aren't technically 'new games' but rather conversions (even though done beautifully) martijn

Hi, I'm also happy to announce that i've revived and updated the ColecoVision FAQ as well, you can find the new FAQ at: www.colecoworld.com/faq To all webmasters, please update the old ColecoFAQ as soon as possible. kind regards and a happy new year to all Coleco fans, Martijn PS> The ColecoFaq hasn't been updated since 1996 i think. I have tried to track down the previous maintainers, but found it impossible. So if anyone objects to me reviving the FAQ, let me know.

Hi People, My name is Martijn Wenting, i am the author of the infamous www.vectrexnews.com , a very popular website for the Vectrex scene, and the maintainer of the Vectrex FAQ. I'd also like to announce here that of today i've launched a new ColecoVision website called: "ColecoWorld". I hope that ColecoWorld will become for the ColecoVision scene what VectrexNews is for the Vectrex scene. I have bundled together everything i know about the ColecoVision and all the tiny bits and pieces of information that are scattered around on the internet to create one definite newssource for everything related to the ColecoVision. So please visit the website and let all your (ColecoVision-) buddies know about the website and make "ColecoWorld" a success. You can visit the website at: www.colecoworld.com I will also post some nice reviews of new hardware and announce some new ColecoVision games on the website in the near future, so please keep your eyes on the website. Kind regards, Martijn Wenting

Hi again, I'm also happy to announce that i've revived and updated the ColecoVision FAQ as well, you can find the new FAQ at: www.colecoworld.com/faq To all webmasters, please update the old ColecoFAQ as soon as possible. kind regards and a happy new year to all Coleco fans, Martijn PS> The ColecoFaq hasn't been updated since 1996 i think. I have tried to track down the previous maintainers, but found it impossible. So if anyone objects to me reviving the FAQ, let me know.

I guess Richard beat me once again , so here is the official announcement: Hi People, My name is Martijn Wenting, i am the author of the infamous www.vectrexnews.com , a very popular website for the Vectrex scene, and the maintainer of the Vectrex FAQ. I'd also like to announce here that of today i've launched a new ColecoVision website called: "ColecoWorld". I hope that ColecoWorld will become for the ColecoVision scene what VectrexNews is for the Vectrex scene. I have bundled together everything i know about the ColecoVision and all the tiny bits and pieces of information that are scattered around on the internet to create one definite newssource for everything related to the ColecoVision. So please visit the website and let all your (ColecoVision-) buddies know about the website and make "ColecoWorld" a success. You can visit the website at: www.colecoworld.com I will also post some nice reviews of new hardware and announce some new ColecoVision games on the website in the near future, so please keep your eyes on the website. Kind regards, Martijn Wenting

please please scan/photograph and send it over, i'd love to include it Martijn

batari, PLEASE consider the 'cycling colors from romtable' option

any estimation on when the next bBasic release will be?

like i stated before, i have no problems having other things suffered for this. i think it could be setup in a way that it shouldn't affect the current kernel.. in the main kernel file (even if it contains different kernel-handling) check e.g. p0colordata, or bg/pfcolordata if its a number -> use current kernel, if its pointed to data, use different handling.. increasing a pointer each scanline for the bg/p0/p1 shouldn't be that hard to implement (even if you suffer a few cycles and have no missile or ball). i understand that multiplexing sprites might be a different thing alltogether, but just adding 'coloring' should be very doable imho.

Thanks for the workaround. though it will no doubt take much higher number of cycles (i need to look up a total of 8 times per frame), it seems to work fine. i had to change one thing. if offset was declared as dim offset=d.e Then, I had to replace "on offset goto ..". by "on d goto ....." i also put the lookup functionality in a gosub-return construction for easy reading As fo the kernel issues, i have no problem giving up one item for another. you can do it this way that old programs also work. like i mentioned in the kernel-features post. 1) - some kind of var/point to attach 'colordata' to (for background a 192byte array in rom', for sprites a 'spriteheight' array of colors in rom )... which during drawing will be read..... you could do it by having vars like p0colordata=mycolordata if you do p0colordata=14 it will just draw the sprite normally with color 14 otherwise it will draw it using the data in mycolordata and increase colordatapointer each scanline. same goes for the background..... ===> so in this case, if users make use of the option (checked by seeing if p0colordata is attached to a pointer) it will be handled (but no ballsprite for example), if it points to a simple color, it will set COLUP0 to the color and continue as it does normally Sound like a good solution to me, but let me know what you think... martijn P.S> Is there is no way to do any kind of sprite multiplexing other than interlacing from bBASIC (for example have a sprite start coordinate, if its bigger than otherspritey+spriteheight, it will automatically be multiplexed P.S2> For your kernal memory-structurig problem. I'm assuming you want playerdata to be alligned at 256 and making sure you won't wast memory? How about defining them from the back-end of the romspace of the main bank or another bank (can be defined with data definition) to the front and let the programmer bankswitch before drawing. 16 sprites per bank * 8 banks for 32kb should be enough to hold all your graphics. and nowadays 27c256s aren't much more expensive than 4kb roms. Only problem i don't know how 'costly' bankswitching is. coming from gameboy DMG/Gameboy color it wasn't that much of a problem. all my game graphics relied on bankswitching.

Hi Batari, With the new sprite kernel, could you PLEASE PLEASE add things like: - some kind of var/point to attach 'colordata' to (for background a 192byte array in rom', for sprites a 'spriteheight' array of colors)... which during drawing will be read..... you could do it by having vars like p0colordata=mycolordata if you do p0colordata=14 it will just draw the sprite normally with color 14 otherwise it will draw it using the data in mycolordata and increase colordatapointer each scanline. same goes for the background..... P.S. a 'normal' 16-bit var or indexpoint would be extremely helpful. i've got a pretty nifty musicplayer but it only plays for 3 seconds because my data point > 255 martijn

Hi People, After doing some vectrex and colecovision programming, i decided to give the atari2600 another shot with the newly release bBasic (awesome project!!!). I've done a few tests, but i have a few questions: - I need to acces data with a 16-bit offset. Right now i can't find a way to define 'normal' (non-fixedpoint) 16-bit vars (i only need 1 or 2 of them) and then use it to acces data, like: offset=670:value=mydata[offset]; Is there currently ANY way to do this??? I think more people would find this useful for a hand full of things (like a musicplayer or animation data,etc.) - I couldn't find a way to adjust object/pf/bg color per scanline, maybe a good idea to include a small array or list of some kind (starty,startcolor,numlines (will automatically be increased). in which you can set the colors which are later handled in the kernel - last but not least: a way to to 'scale'/extend' the playfield', so you don't have those square blocks, but you can also use it for logos,text,etc. maybe same mechanism (starty, playfield 'scale', num playfieldlines, and maybe pointer to playfield data (so you can point it to static data in rom!!!). Hope anyone here can answer my questions or is able to help implementing these features. Martijn