Pixelboy

After years of playing Atari 2600 and ColecoVision games at my friend's house, my first was an ADAM computer, which I mostly used to play games, so even if it's not exactly a console, to me it was a glorified ColecoVision with a keyboard and printer. I loved my ADAM, especially for Dragon's Lair. And I loved it even more once a friend of mine gave me the means to copy ColecoVision cartridge games onto ADAM data cassettes. I sold the whole shabang for 15$ years later. Ah, the memories...

If you manage to pick up Activision Anthology for GBA, don't forget to download my unofficial companion guide for the game! You can find it here, in PDF format, and it's completely free: http://colba.net/~lucm/pix_aa_guide/ The version on my web site is the low quality version. A high-quality PDF also exists, but I never got around to finding some extra web space for it. (I thought the AtariAge webmasters might be interested in hosting it, but it didn't work out.)

You won't hear any complains from me about using tiles, but are you still planning to offer split-screen features, with independent scrolling? If yes, how will sprites behave in split-screen situations?

My experience of YACC has been that it generates nice stuff, but the parser it produces doesn't work very well. What I mean is that when a programmer makes some kind of syntax error in his code, the parser will sometimes produce incorrect error messages, or indicate errors on the incorrect line number of the source code. Frankly, I'd rather work on my own parser, if only for the fun of it. Well, the idea is just to give the language some consistency. For example, all functions related to Graphic Mode 1 fall under "cv.gmode1", which means that if the programmer wants to define a new function called "setTileColor()", he can do it without conflicting with the basic pre-defined functions of the language. Also, not everything falls under the "cv" master object. All of the functions related to Eduardo's SEM will be regrouped under the "sem" master object, which means that if the game programmer wants to make a game for the basic CV hardware, all he has to do is refrain from using any pre-defined function that starts with "sem.". As far as the IDE is concerned, the proposed syntax also offers some advantages when it come to automatic word completion, which will be a readily available feature if we use SpeedBasic as a basis of our IDE. (Which reminds me: I'll have to study SpeedBasic under the hood one of these days...)

Right. Speaking of which, I guess now would be a good time to stop asking questions (although I still have a ton of them) and start contributing something more concrete to this thread. So allow me to throw some ideas around... The central idea of the functions described below is to use a sort of "built-in" object simply called "cv", which is an entry point to several sub-objects like "io" and "ctrl", which themselves hold specialized functions. It's a way to keep the code clean from the programmer's point of view. IO: cv.io.gmode1.initialize() --> Initializes Graphic Mode 1. --> Returns nothing. cv.io.gmode1.loadColorTable(<byte_id>) <byte_id> = name of registered array of 32 bytes in RAM or ROM --> Loads the entire color table for Graphics Mode 1. --> Returns nothing. cv.io.gmode1.setTileColors(<num_group>, <color_1>, <color_2>) <num_group> = group number between 0 and 31 <color_1> = color #1 between 0 and 15 <color_2> = color #2 between 0 and 15 --> Sets the colors of a group of 8 tiles under Graphic Mode 1. --> Returns nothing. cv.io.gmode1.loadNameTable(<byte_id>) <byte_id> = name of registered array of 768 bytes in RAM or ROM --> Copies 768 bytes from <byte_id> into Graphic Mode 1's name table. --> Returns nothing. cv.io.gmode1.loadPatternTable(<byte_id>, <bg_or_spr>) <byte_id> = name of registered array of 2048 bytes in RAM or ROM <bg_or_spr> = 0 for background patterns, 1 for sprite patterns --> Loads 2048 bytes from <byte_id> into Graphic Mode 1's pattern table. If <bg_or_spr> = 0, the data is loaded into the background pattern table, else if <bg_or_spr> = 2, then the data is loaded into the sprite pattern table. --> Returns nothing. cv.io.gmode1.setSprite(<sprite_number>, <x_coord>, <y_coord>, <pattern_number>, <color_1>, <color_2>) <sprite_number> = sprite number between 0 and 31 <x_coord> = x coordinate of sprite, between -32767 and 32767 <y_coord> = y coordinate of sprite, between -32767 and 32767 <pattern_number> = pattern tile number between 0 and 255 <color_1> = color #1 between 0 and 15 <color_2> = color #2 between 0 and 15 --> Sets the attributes of a sprite under Graphic Mode 1. --> Returns nothing. cv.io.gmode2.initialize() --> Initializes Graphic Mode 2. --> Returns nothing. cv.io.gmode2.setTileLineColors(<num_group>, <num_line>, <color_1>, <color_2>) <num_group> = tile group number between 0 and 31 <num_line> = pixel line number between 0 and 7 <color_1> = color #1 between 0 and 15 <color_2> = color #2 between 0 and 15 --> Sets the colors of a group of 8 tiles under Graphic Mode 2. --> Returns nothing cv.io.gmode2.setTileColors(<num_group>, <line0_col1>, <line0_col2>, <line1_col1>, <line1_col2>, <line2_col1>, <line2_col2>, <line3_col1>, <line3_col2>, <line4_col1>, <line4_col2>, <line5_col1>, <line5_col2>, <line6_col1>, <line6_col2>, <line7_col1>, <line7_col2>) <num_group> = tile group number between 0 and 31 <line0_col1> = color #1 (between 0 and 15) of pixel line #0 <line0_col2> = color #2 (between 0 and 15) of pixel line #0 <line1_col1> = color #1 (between 0 and 15) of pixel line #1 <line1_col2> = color #2 (between 0 and 15) of pixel line #1 <line2_col1> = color #1 (between 0 and 15) of pixel line #2 <line2_col2> = color #2 (between 0 and 15) of pixel line #2 <line3_col1> = color #1 (between 0 and 15) of pixel line #3 <line3_col2> = color #2 (between 0 and 15) of pixel line #3 <line4_col1> = color #1 (between 0 and 15) of pixel line #4 <line4_col2> = color #2 (between 0 and 15) of pixel line #4 <line5_col1> = color #1 (between 0 and 15) of pixel line #5 <line5_col2> = color #2 (between 0 and 15) of pixel line #5 <line6_col1> = color #1 (between 0 and 15) of pixel line #6 <line6_col2> = color #2 (between 0 and 15) of pixel line #6 <line7_col1> = color #1 (between 0 and 15) of pixel line #7 <line7_col2> = color #2 (between 0 and 15) of pixel line #7 --> Sets all 8 color pairs of a group of 8 tiles in Graphic Mode 2. --> Returns nothing. cv.io.gmode2.setSprite(<sprite_number>, <x_coord>, <y_coord>, <pattern_number>, <line0_col1>, <line0_col2>, <line1_col1>, <line1_col2>, <line2_col1>, <line2_col2>, <line3_col1>, <line3_col2>, <line4_col1>, <line4_col2>, <line5_col1>, <line5_col2>, <line6_col1>, <line6_col2>, <line7_col1>, <line7_col2>) <sprite_number> = sprite number between 0 and 31 <x_coord> = x coordinate of sprite, between -32767 and 32767 <y_coord> = y coordinate of sprite, between -32767 and 32767 <pattern_number> = pattern tile number between 0 and 255 <line0_col1> = color #1 (between 0 and 15) of pixel line #0 <line0_col2> = color #2 (between 0 and 15) of pixel line #0 <line1_col1> = color #1 (between 0 and 15) of pixel line #1 <line1_col2> = color #2 (between 0 and 15) of pixel line #1 <line2_col1> = color #1 (between 0 and 15) of pixel line #2 <line2_col2> = color #2 (between 0 and 15) of pixel line #2 <line3_col1> = color #1 (between 0 and 15) of pixel line #3 <line3_col2> = color #2 (between 0 and 15) of pixel line #3 <line4_col1> = color #1 (between 0 and 15) of pixel line #4 <line4_col2> = color #2 (between 0 and 15) of pixel line #4 <line5_col1> = color #1 (between 0 and 15) of pixel line #5 <line5_col2> = color #2 (between 0 and 15) of pixel line #5 <line6_col1> = color #1 (between 0 and 15) of pixel line #6 <line6_col2> = color #2 (between 0 and 15) of pixel line #6 <line7_col1> = color #1 (between 0 and 15) of pixel line #7 <line7_col2> = color #2 (between 0 and 15) of pixel line #7 --> Sets the attributes of a sprite under Graphic Mode 2. --> Returns nothing. MISCELLANEOUS: cv.mem.copyBytes(<src_address>, <dest_address>, <number_of_bytes>) <src_address> = address of first byte to copy (in RAM or ROM) <dest_address> = address of first byte to copy to (in RAM) <number_of_bytes> = number of bytes to copy --> Copies <number_of_bytes> bytes from one memory address (in RAM or ROM) to another (in RAM only, obviously). --> Returns nothing. cv.timer.get() --> Returns the current value of the internal clock (which is based on the video refresh NMI) as an integer value. cv.timer.reset(<value>) <value> = integer value used to reset the timer (usually zero) --> Sets the internal clock to a specific value. cv.random.setSeed(<value>) <value> = integer value to use as seed on the next call to "cv.random.get()" --> Sets the seed of the built-in random number generator. Note that this seed is also modified each time the joystick is moved or the keypad is pressed on either controller, which helps in making the random number generator truly random. cv.random.get(<max_value>) --> Generates (and returns) a random number between 0 and <max_value>. CTRL: cv.ctrl.keyPressed(<port_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 --> Returns true if a keypad key was registered as "pressed" during the last NMI loop. --> Returns false otherwise. cv.ctrl.keyDepressed(<port_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 --> Returns true if a keypad key was registered as "depressed" during the last NMI loop. --> Returns false otherwise. cv.ctrl.keypadGet(<port_number>) <port_number> = 1 for controller #1, 2 for controller #2, 0 for both ports --> Returns 0 if last key pressed was key '0' --> Returns 1 if last key pressed was key '1' --> Returns 2 if last key pressed was key '2' --> Returns 3 if last key pressed was key '3' --> Returns 4 if last key pressed was key '4' --> Returns 5 if last key pressed was key '5' --> Returns 6 if last key pressed was key '6' --> Returns 7 if last key pressed was key '7' --> Returns 8 if last key pressed was key '8' --> Returns 9 if last key pressed was key '9' --> Returns 10 if last key pressed was key '#' --> Returns 11 if last key pressed was key '*' cv.ctrl.keypadFlush(<port_number>) <port_number> = 1 for controller #1, 2 for controller #2, 0 for both ports --> Discards all previously recorded keypad information on port. --> Returns nothing. cv.ctrl.joystickState(<port_number>) <port_number> = 1 for controller port #1, 2 for controller port #2 --> Returns 0 if joystick was not moved in any direction by the player --> Returns 1 if joystick was moved upward --> Returns 2 if joystick was moved up/right (diagonal) --> Returns 3 if joystick was moved left --> Returns 4 if joystick was moved down/right (diagonal) --> Returns 5 if joystick was moved down --> Returns 6 if joystick was moved down/left (diagonal) --> Returns 7 if joystick was moved right --> Returns 8 if joystick was moved up/right (diagonal) cv.ctrl.buttonPressed(<port_number>, <button_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 <button_number> = 0 for left button (or top button on Super Controller) 1 for right button (or second button on Super Controller) 2 for third button on Super Controller 3 for fourth button on Super Controller --> Returns true if the specified button was registered as "pressed" during the last NMI loop. --> Returns false otherwise. cv.ctrl.buttonDepressed(<port_number>, <button_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 <button_number> = 0 for left button (or top button on Super Controller) 1 for right button (or second button on Super Controller) 2 for third button on Super Controller 3 for fourth button on Super Controller --> Returns true if the specified button was registered as "depressed" during the last NMI loop. --> Returns false otherwise. cv.ctrl.lock(<port number>) <port_number> = 1 for controller #1, 2 for controller #2, 0 for both ports --> Makes the state engine ignore controller input on specified port until cv.ctrl.unlock() is called. --> Returns nothing. cv.ctrl.unlock(<port number>) <port_number> = 1 for controller #1, 2 for controller #2, 0 for both ports --> Restores checking controller input on each NMI loop for the specified port. --> Returns nothing. cv.ctrl.trackballState(<port_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 --> Returns the last recorded state of the trackball (on the Roller Controller). cv.ctrl.steeringWheelState(<port_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 --> Returns the last recorded state of the steering wheel (on Expansion Module #2). cv.ctrl.gasPedalState(<port_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 --> Returns the last recorded state of the gas pedal (on Expansion Module #2). cv.ctrl.spinnerState(<port_number>) <port_number> = 1 for controller port #1 or 2 for controller port #2 --> Returns the last recorded state of the Super Controller spinner on the specified port. I'm sure there will be some adjustments and many more functions to add to the list above, but the beauty of it is that we can separate the CV stuff from the SEM stuff easely. For example: sem.gmode4.initialize() Haven't received a reply yet.

16x16? Okay... So if you set the 6th bit of VDP register #1 to 1, then ALL sprites used in the game are displayed in 16x16 mode? Heck, I don't even know what VDP stands for, so color me stupid! Oh, and remember those screenshots I showed you earlier, the ones you called "fantastic" in the dev kit thread? I designed them with the 8x8 sprite mode in mind. I'm sure there will be some flicker in some spots, but if they can get away with tons of flicker in a commercial game like Roc'n'Rope, I don't see why I should bother myself with it.

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)...

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!

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...

What happened to Eduardo...?

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...

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.

Save it? Is this change persistent, or is it lost when you turn the system off?

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...

So, opcode, did you get my e-mail?

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.

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...

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?

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?

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...

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.

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?

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?)

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!

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...