Jump to content

Pixelboy

Members
  • Content Count

    8,726
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Pixelboy

  1. I think I'm missing something here... How can you draw the wizard using only four sprites? I can't see how you can draw it with less than eight, unless you're just talking about simple graphic extent, not actual hardware sprites (0 to 31)...
  2. Wow, no kidding! Take it easy, Eduardo! The expression "No rest for the wicked" doesn't apply to you. Not when you're sick, anyway. About your latest post, I'd say the SEM is looking more awesome every time I learn something new about it, and it seems the amount of features in our CV dev kit associated with the SEM will be far more massive than those for the basic CV. Which is fine by me. Good job! Now get some rest!
  3. It's been a week since Eduardo last posted in this thread, and he hasn't replied to my e-mail either. I don't know the guy very well, so I'm just wondering what he's doing that's keeping him away. He was rather quick to reply before...
  4. Wow, this thread is old! Did opcode ever finish this DK game he was working on? If not, I'd like to contribute my own ideas: 1) In building new levels, take some elements from Mario Bros (turtles, crabs, fireballs, coins for bonus points, pipes, blocks that can be knocked from under, POW blocks that can stun enemies (including Donkey Kong). Those elements could enhance the DK experience in a fun way. 2) Have at least one level with water in it. Running and jumping physics could be altered, and there could be a time limit to how long Mario can stay underwater. Some water-based critters could be added. 3) There could be a two-player version of the game where player 1 plays as Mario, and player 2 plays as Luigi. The levels would be specifically designed to either encourage competition or cooperation. Designing such levels could be quite a challenge, however... 4) For a really advanced remake of this game, how about mixing DK and DKjr together? Once you finish the rivet level and defeat DK, the game then switches to DKjr mode, and once Junior frees his dad in the keychain level, DK kidnaps Pauline again and it all starts over with Mario from the first DK level. Intermissions would add extra polish to the finished product. 5) I haven't tried the Champ Kong games, but from the screenshots I've seen on the net, it seems like a good idea to include the extra levels. I'll admit all those ideas are overly ambitious for the CV... Seems like they could only be done on opcode's SEM...
  5. So I assume there will be something in the SEM BIOS to do this for any game. Will the SEM also be able to save game data in the same way? Would be perfect for RPG games, for one thing... Also, one suggestion for your palette editor: Be sure to offer a way to enter a palette specification using a number-based password. That way, players can quickly enter a pallette code using the standard keypad, and players can also exchange pallette codes between each other (by e-mail, or whatever). The Super Game Boy device (for Super-NES) had a similar pallette number code system, and it was VERY useful.
  6. Save it? Is this change persistent, or is it lost when you turn the system off?
  7. Huh? You mean it's pregnant??? (See, you're not the only one who can make bad jokes. Heh.) Text mode could be useful for those who'd want to do Infocom-type text games... Kewl! They indeed look much better. Although I've always felt that regular TV screens produced better CV colors than PC monitors... That reminds me: Will the SEM use the extra 16K of RAM together with the 1K of base RAM, or will the 1K become "obsolete"? But old CV games will only use the slightly upgraded set of 16 colors. Still, it's very cool. Ah, so this is the kind of code that our dev kit will generate...
  8. Thanks, but I think the words "near future" will not apply to this project. For one thing, what I'd like to do is use the month of December for performing analysis, because the last thing we want to do is rush head-first into this kind of project. For one thing, I'd like to take time to study SpeedBasic and see if it's worth using. The thing looks nice and polished on the outside, but if it's a piece of coding crap under the hood, we might want to look elsewhere. Just because it's open source, doesn't mean it's coded in a clear and readable way. So I'm reserving judgement for now. Also, I want to further my general understanding of the ColecoVision hardware by discussing certain issues with Eduardo before we get into coding. For example, we need to clarify stuff about the graphic modes (including modes 4 and 5 of the SEM) and discuss how this affects our Basic-style programming language. I would also like to discuss certain gaming scenarios and solution implementations. For example, let's say the programmer would like to do a Street Fighter-type fighting game with our IDE. How would the programmer code his game to record joystick sequences (down+down/foward+forward+fire button = hadoken fireball)? That's just one little example. And then there's the whole analysis of what the IDE will offer in terms of tools. We may decide to try to find a third person who has experience with GUI interfaces, so that this third person can work on such things as a tile editor (similar to the one in NESticle), a game screen editor, and more importantly, a music and sound effects editor. I think there's more than enough stuff to discuss between now and January 2006. Besides, I've got Christmas-related stuff to take care of this month, and we're also getting into the usual December rush at my company, so needless to say I'll be busy enough as it is.
  9. Give me a couple of days, and I'll show you something that I think you'll love. In the mean time, don't you have Pac-Man Collection to finish? I wouldn't want you to put your active CV projects aside, especially considering how a lot of people are waiting for those cool ports you're working on...
  10. It's very interesting, although I have to wonder exactly how far we can go with it. I mean, it basically takes Basic and translates in into C++. Would our "version" of it take our brand of Basic and produce CV assembly code, which would then be handled by a regular Z80A assembly compiler?
  11. Actually, I've never written one myself to this day, but I know the general theory behind them, especially when it comes to parsing source code, so I'm confident I can get at least some of the work done. On the other hand, turning the parsed source code into machine code will be your job, which means we'll have to devise the available keywords, attributes and methods of the language, and then establish how this code will be translated into functional (and optimized) machine code. From there, I can come up with a virtual structure for the parsed source which you can then easely traverse and process while you're generating the CV machine code of the ROM. How does that sound?
  12. As you said, this discussion is indeed getting interesting. I'm not sure I understand everything in your explainations (the NMI thing is more complicated than I expected), but I think I understand most of it in general, so I'm hopeful I'll be able to help you with the dev kit language. Speaking of which, I've been thinking, and I agree that using an object-oriented approach does have its advantages. If you really want to go the object-oriented way, I really have no right to stand in your way, since this is YOUR project after all, and I still have a bunch of stuff to learn about the internal workings of the CV anyway. It should be noted however that it's far more difficult to write a parser for a C++/Java type language, but I'm willing to give it a shot if you'll let me. Also, optimizing the generated machine code from the programmer's OO source code might prove more difficult than you might expect. We do have very limited RAM and ROM space to work with, and a programmer might get carried away and make a game that's too big for the CV to handle, especially if he makes his game for a plain CV, and not the SEM. Even if we go with an OO language, we should still offer a graphic tool to let the programmer monitor the available ROM space, so that the generated machine code will fit inside this ROM space together with the graphic and sound data. Beyond those basic issues, there's always something that the programmer wants to do, something really low-level, that the OO language will not allow. We should at least offer certain features within the language that will allow experts (like you) to pull off programming "stunts" when needed. Also, this leads me to ask a couple more questions, so I'll just regroup all my questions below (including those I've already asked but haven't gotten an answer yet) for your convenience. 1) Are integers stored on two bytes, and can they be signed or unsigned? 2) Does the 40x24 text mode use a hard-wired font, or does it use a modifiable pattern table? 3) If I'm not mistaken, the standard CV title screen is part of the BIOS. Does this imply that the font used for the game name and copyright strings in the bottom half of the screen (below the "COLECOVISION" multi-colored display) use a hard-wired font which we don't normally have access to? 4) How does the main stack work in the CV for regular push/pop operations? Do we need to reserve some space in the RAM for it, or is it a sort of secondary RAM in the hardware? 5) Does the CPU read machine code directly from the ROM space, or does it need to be loaded into RAM first before it can be executed? 6) The docs I've read indicate that the ROM space between 8000H and FFFFh is "broken into 4 sections, each enabled separately". What does this mean for our compiler/linker, in terms of constraints? That's all for now... I think...
  13. BTW, I made a little mistake in my first post in this thread. This example line: SET COLOR ROW a TO b c should instead be: SET TILE ROW a TO COLOR b c Sorry if it caused you any confusion.
  14. Actually, I was thinking the same thing, but I didn't get the chance to elaborate. There are so many issues with your above reply that it's going to take a while for me to formulate a complete response. Just keep in mind that my explanations will probably contain several flaws because my understanding of the CV hardware is very limited. But I'm sure we can iron things out together. I just hope you can see things my way... First of all, in my vision of the dev kit, the programmer first creates a "project" and selects the total cartridge size (16K, 32K, 64K). The project regroups such entities as pattern tables, title screen layout (with the multi-colored "COLECOVISION" label at the top of the screen), game screens (a.k.a. name table data), sound data and other types of binary data together with the central source code, and all these entities are saved in separate data files under the same project directory, and will be all linked together automatically by the compiler/linker upon ROM generation. Of course, the entities (pattern tables, sounds data, etc.) can be exported and imported in other projects later. The dev kit would offer a graphical interface for everything that can be presented graphically. For example, imagine a window with a rectangle of 128x256 pixels, where each pixel represents one byte of a 32K ROM space. The bytes already taken by data appear as red pixels, and the free bytes are shown as green pixels. With this interface, you can see at a glance how much space you have left to work with at any time. Under this rectangle, there would be a combo-box with a list of entities defined by the programmer, and when he selects one of these entities in the list, the bytes taken by this entity in the ROM space appear as yellow pixels in the rectangle. For example, select a game screen, and the 768 contiguous bytes taken for this game screen appear in yellow in the ROM space rectangle. Pattern tables and other entities are external to the main source code of the game, and are referenced by name. This means that your line of code: DIM mygraph as GDATA = c:\<some path>\graph2.scr would look more like this: LET adr_pat_tab_1 = ADR "pattern_table_1" where "adr_pat_tab_1" is the name of a variable, and "pattern_table_1" is the name given to one of the entities (in this case a pattern table) defined by the programmer under the current project. Of course, the instruction above is pointless unless you want to do something special with the pattern table, because under normal circumstances, all you need to load a pattern table in VRAM is a command like this one: LOAD PATTERN TABLE "pattern_table_1" When the compiler/linker generates the ROM file, the starting address of "pattern_table_1" is known, so the LOAD PATTERN TABLE instruction translates into a single "memcopy" operation of 2048 bytes between the ROM space and the VRAM (I'm assuming the CV hardware offers an easy way to do a memcopy like that). This perfectly illustrates the goal of the language: To allow the programmer to work in assembly, without having to write actual assembly code! I don't think defining such color data within the source code is a good idea (it should be done at the project level via the GUI of the dev kit), but I guess the programmer can need to modify the colors during run-time... To be honest, I haven't given much thought to the differences between the graphic modes, so this will require further discussions. However, no offense Eduardo, but using object-oriented syntax like "mytile.color()' is exactly the kind of thing I want to avoid with this dev kit. What I'm aiming for is a language that is easy to read and also directly translates into CV machine code. But in this case, wouldn't be C good enough? Allow me to tell you a story to illustrate my point of view: When I was studying at my local university in computer programming, there was a debate among teachers as to what language should be taught to first-year students. They discussed Pascal, ADA, some other languages, but one thing was unanimously agreed upon by all the teachers: C/C++ was NOT an acceptable option. Why? Because the syntax is too rough for beginners, and the compilers are generally too permissive. Building compiler/linker safeguards into something as loose as C syntax is downright impossible, and it is far more easy to do so in a language like the one I'm proposing. I want this dev kit to be something else than a glorified C compiler. I'm not sure I understand your explanation (mostly because I don't know what the NMI is) but I'm sure we can adjust the language to deal with this delay problem. And again, I must say I don't like using the C++ syntax... Ok, but you would still need some macros for easier animation It's funny you should mention that, because this raises the main issue which prevents me from forming a complete picture of the dev kit's language in my mind: How does a programmer set the overall speed and timing of objects within a game? And how does sound output fit into all this? This is an issue which remains a complete mystery to me, because all the programs I've written in my life were designed to perform jobs as quickly as possible, and I never had to calibrate a running program to a specific speed of execution, to make it normally playable. I've heard about the "vsync technique", but that's for PCs, right? If I could get a real handle on that concept, it would help me tremendously... Hmm... So you want to put an extra layer of abstraction between the programmer and the actual hardware sprites... Considering we only have 1K of RAM to work with, do you think it's really a good idea to create extra data structures like that? Not that's it's really a bad idea or anything, I'm just concerned. Since both are based on the Z80 CPU, you can't do floating-point math by hardware. That's okay, we can live without it for now, I guess. I assume that standard integer values are coded on two bytes, and that they can be signed or unsigned?
  15. Okay then, let's get to work on Item #2. I browsed through the docs at the CV FAQ page (http://www.classicgaming.com/colecofaq/), and that's about all I've been able to do for research, so whatever I say will be based on the info from that web site. My idea for a language suitable for a beginner would be something that's readable, yet optimized for the CV. For example, let's say you want to change the color for the 6th group of 8 tiles in the name table. It could be done like this: SET TILE ROW 6 TO COLOR 0 13 or SET TILE ROW 6 TO COLOR TRANSPARENT MAGENTA "6" is the offset number in the color table, "0" is the color used for the high nibble (first 4 bits - in this case, transparent), and "13" is the color used for the low nibble (last 4 bits - in this case, magenta). At compile/link time, this instruction would be transformed into a simple "poke" instruction in the proper location of the color table. It's also possible to do something more dynamic, like this: LET a = 6 LET b = 0 LET c = 13 SET COLOR ROW a TO b c The above commands do the same thing as before, but the values are stored in variables "a", "b" and "c". At compile time, the SET COLOR ROW command would be broken down into a few machine instructions to fetch the values from the variables in RAM and use them to perform the poke operation. The above example is an introduction to my philosophy for the proposed language: Keep things at a low, almost assembly level, but always keep it readable. Beginners can understand concepts such as "name table", "pattern table" and "color table" as long as it's explained in a basic way in tutorials, and so these should simply be "usable components" within the language. Another example: LET j = JOYSTICK 1 STATE LET f = BUTTON 1 STATE LET k = KEYPAD 1 STATE If the player is currently pushing the joystick in any direction, this direction will be stored as a number in variable "j" (if the joystick is idle, then "j" will be zero). Same goes for the BUTTON and KEYPAD commands, where any button/key currently being pressed on player 1's controller will be stored as a number in variable "f" and "k" respectively. At compile time, such commands as JOYSTICK, BUTTON and KEYPAD will become simple "peek" commands which look at the appropriate hardware addresses. Yet another example: Let's say you want to set sprite #1 (of the 32 available sprites) at a certain location on the screen. It would be done like this: SET SPRITE 1 AT 45 151 Other variants are possible: SET SPRITE 1 PATTERN 245 SET SPRITE 1 COLOR 0 13 SET SPRITE 1 AT 45 151 PATTERN 245 COLOR 0 13 This puts the sprite at x=45, y=151 on the screen, sets the sprite to use pattern #245 in the sprite descriptor table, and sets the sprite color to the transparent/magenta combo. Same as before, these are translated into simple "poke" commands in the generated ROM image, and integer variables can be used instead of constants: SET SPRITE a PATTERN b SET SPRITE a COLOR b c SET SPRITE a AT b c PATTERN d COLOR e f More later, if you're still interested... (BTW, can the CV do floating-point arithmetics, or is it limited to integer math? What about the SEM?)
  16. Is that so? That's great! I had a look at your code exerpt, and it's not exactly what I had in mind, but it's somewhat close... Ah, so RWB owns the right to the CV BIOS? Didn't know that. It does complicate things, doesn't it? Please do. I'll join you soon after. How about... "Vidblit"? One thing you need to know about me is that, while I'm a computer programmer by profession, I've never really programmed a real game before, especially not on a video game console, so terms like "bitmapped framebuffer" make me go "Huh?". But still, a quick explanation of such concepts will get me up to speed. See you on the Homebrew forum!
  17. Well, I have to say I'm just as intrigued as the next guy about your SEM project (glad to see your web site is partly back, BTW), but there's a basic problem which (I think) explains the divergence of opinions of the "classic homebrew programmers": Let's say your SEM project becomes a fully functional device. The next question that will inevitably come up is: Who will make games for it? Sega, with the 32X add-on for the Genesis, tried to do exactly what you're proposing with the SEM. But only a handful of games designed for the 32X were released before Sega discarded it in favor of the Saturn. In the end, the limited availability of the 32X, coupled with the low number of 32X games, made the whole 32X endeavour pointless. The case of the SEM is similar, where you'll probably be releasing all the tech docs programmers need to take advantage of this new piece of hardware, but the end result is fully predictable: A handful of homebrew authors (including you, Eduardo) will take a shot at making one or more tech demos for the SEM, there will be some attention (maybe even some hype) from the homebrew scene, perhaps a few good games will even emerge, and then the SEM will fade away as "just another interesting project... in theory". The "classic homebrew guys" prefer to make games for the "non-upgraded" base systems because these systems are already widely available, which means more players can experience the fruits of their labours. The reason why I think the CV homebrew scene is so small right now is mostly a question of tool availability (and this has little to do with the relative popularity of the Atari 2600/5200/7800 homebrew scene). Having CV tech docs available on the net is nice, but if there was a proper homebrew PC dev kit with a programming language designed specifically for the CV (a language which would be easier to learn and understand than standard C, yet would compile easely into CV machine code), packaged together with a graphic tile editor, a sub-editor for creating music and sound effects, an integrated emulator/debugger with a memory monitor that lets the programmer know exactly what's happening under the hood of the machine at runtime, and a compiler/linker that produces CV ROMs (compatible with the real CV hardware, as well as any CV emulator), then you'd give homebrew programmers, both beginners and experts, one heck of an incentive to design their own CV games in record time. And then there's the real beauty of the proposition: This proposed CV dev kit could be upgraded for the SEM, so when the SEM is released as a functional product, programmers could use the dev kit to dive into it head first! If all you offer is the SEM hardware with the specs and the plain tech docs, your SEM will only attract the attention of hardcore CV homebrew guys. Is that really what you want, Eduardo? Or would you like the SEM to become a learning tool for beginner programmers? With a good dev kit, even beginners (who usually shy away from cryptic technical documentation) could get into the act, and the SEM could achieve the same level of recognition as other similiar dev kits like Game Maker. Think about it...
  18. I don't know... Probably a few hundred thousand dollars at most. RWB are just 3 or 4 guys, with no exact idea about what they have bought. Just look their website. That doesn't look like a website from a multi-million dollar company... 974097[/snapback] Man, that's a lot of money for just 3 or 4 guys... Let's say the number was roughly 100,000US$ for both the Coleco and ColecoVision names, you'd need to find 100 people ready to pay 1,000$US each, without any guarantee as to what would be done with the name! On the other hand, imagine if it DID happen... If 100 ColecoVision fans got together to buy the name, and then developping CV games became something like open source, where technical documentation and dev kits became openly available, where Eduardo could release his Super Expansion Module internationally, under an official ColecoVision label like "Super ColecoVision"? Well, come to think of it, I guess it wouldn't make much of an impact, with the Xbox 360, PS3 and Revolution being light years ahead of the CV. However, with the current popularity of plug-and-play video games (the kind sold at Wal-Mart that look like big joysticks that you plug directly in the TV), there could be a niche market waiting for a CV-on-a-chip device shaped like a Super Controller with a SD port, where people could download new CV games for free off the internet. That'd be really neat! And with a really good official dev kit (with built-in emulator for testing purposes) and well-written PDF tutorials and reference documentation, homebrew hobbyists could create new CV games on their PC and make them available to all! (I gotta stop dreaming like this, it's not good for my blood pressure...)
  19. How much do you think buying the Coleco name would cost, just out of curiosity? And would that include the ColecoVision name?
  20. I tried the Intellivision only once in my entire life, roughly two decades ago, and after 10 minutes of experiencing that awful controller, I promised myself I would never touch it again. I'm a CV fan, but even if I wasn't, I'd still pick the CV over the Inty any day of the week.
  21. Okay, I'll just re-post the small non-arcade list I included in my other post within the arcade-to-CV thread: 1) Star Wars - The Empire Strikes Back: A port of Atari 2600 game with improved graphics. I'm not sure the CV can handle the horizontal scrolling well enough though, so a word of caution to any homebrew developer who could ever want to port this game: Choppy side-scrolling could ruin the experience. 2) Remakes of the Atari 2600 SwordQuest games: If it was up to me, I would improve the graphics (especially in the mini-games) as well as the music, add a few bells and whistles here and there, and have the hidden clues displayed as words, not page numbers that refer to the comic books. This could really be a fun homebrew project for experienced CV programmers. 3) Adventure: A port of the classic Atari 2600 game with more skill levels, bigger maps and a few more items. I wouldn't want a monster-sized expansion like Indenture though, just something larger than the original world, but not so large as to make a hand-drawn map an absolute necessity. If I may, I'd like to add a fourth choice: 4) Space Shuttle- A Journey Into Space: A port of the Atari 2600 Activision game that would use the CV keypad for control switches (Engines, Cargo Bay Doors, Landing Gear, Status computer screens, etc.). Considering the primitive hardware it was designed for, the original game was a masterpiece in realistic flight simulation, which involved the technical input of some people at NASA. Recreating the game on the CV would be one heck of an achievement.
  22. My take on this subject is that all CV products should be bundled together as a single cartridge for the Nintendo DS. There are a lot of advantages to this proposition: 1) The bottom screen can be configured to "emulate" the expansion modules (drag the steering wheel or the trackball with the stylus, for example), and this would fix the keypad issue once and for all (just press the keypad keys displayed on the touch screen). 2) Since the DS is internet-compatible, you could theoretically download new CV software via an internet wi-fi hot spot. Homebrew heaven, my friends. 3) They could encode virtual game manuals, just like it's done in Activision Anthology for GBA, (only this time they could add some screenshots). 4) Since this would be a Nintendo DS exclusive, getting the rights from Nintendo for the CV versions of Donkey Kong and Donkey Kong Jr shouldn't be too much of a problem. I'm not sure about other arcade games though, but if they can pull off getting the rights for such classics as Venture, Lady Bug, Time Pilot, Pepper II, Mr Do and Zaxxon (just to name a few), this could be one sweet DS product. One question that comes to my mind is whether the top screen of the DS can handle the CV screen resolution. I'm guessing the screen output might need to be compressed vertically, like it was done with the NES games on the GBA...
  23. My three picks are: 1) Moon Patrol (the real deal, not a prototype like the CV ROM that's floating around the net) 2) Arabian 3) Discs of Tron (could use the trackball expansion module!) Other arcade games that deserve honorable mentions as possible CV ports: - Arkanoid - Asteroids (has it been ported to the CV already? I was too lazy to check...) - Bomberman - Elevator Action - Galaga - Gravitar - Kangaroo - Kung-Fu Master - Lunar Lander - Marble Madness - Mario Bros - Missile Command (another great candidate for the trackball module!) - Pengo - Pooyan - Qix (assuming it's actually possible on the CV) - Quarth - Rip Cord - Robotron 2084 (is it possible without tons of flicker?) - Rally-X - Solomon's Key - Space War - Super Sprint (single-player could use driving expansion module) - Tempest - Vanguard - Wacko (fun trackball game) - Wizard of Wor Since people are going outside the realm of arcade games in this thread, I'd like to voice my own non-arcade CV port wishlist: 1) Star Wars - The Empire Strikes Back (port of Atari 2600 game with improved graphics) 2) Remakes of the SwordQuest games on the CV, with more bells and whistles 3) Adventure (port of Atari 2600 game with more skill levels, bigger maps and more items) 4) Space Shuttle (port of the Atari 2600 Activision game that would use the CV keypad)
×
×
  • Create New...