Jump to content

Pixelboy

Members
  • Posts

    9,266
  • Joined

  • Last visited

  • Days Won

    13

Pixelboy last won the day on December 25 2015

Pixelboy had the most liked content!

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Montreal, Canada
  • Interests
    Everything related to the ColecoVision.
    Everything related to Metroid.

Recent Profile Visitors

47,944 profile views

Pixelboy's Achievements

Quadrunner

Quadrunner (9/9)

5.3k

Reputation

  1. One thing you have to keep in mind is that all those old consoles followed very different hardware architectures. For starters, did you know that the Atari 2600 doesn't have any video memory? This means that a substantial portion of the software on an Atari 2600 cartridge is dedicated to drawing stuff on the screen on the fly. To make the most out of this hardware "limitation", the hardware lets the programmer run a tiny amount of code before drawing each TV scanline. This is how the seagull in your example can have so many colors: The sprite itself is single-colored, but if you change the color of the sprite at the start of each TV scanline, you get a multi-colored sprite on the screen. Note that this technique only works well vertically. Changing a sprite's color while the scanline is in the middle of being drawn is much harder to pull off. Consoles like the ColecoVision and Intellivision do have video memory, and they work quite differently under the hood. For example, the ColecoVision doesn't offer any way for the game software to run code at the beginning of each scanline like it can be done on the 2600. All it offers is a single interrupt signal sent to the CPU after the entire TV screen has been refreshed, and when the software receives this interrupt, it has only a finite amount of time to alter the contents of the video memory before the TV starts the next screen refresh. So that's why the seagull in the ColecoVision version of Fathom only has one color. I'm not very familiar with the Intellivision hardware, but I know it's similar to the ColecoVision in the way it handles displaying graphics. Ask any programmer and they'll tell you that having video RAM to work with is way better than not having it. But video RAM always comes with its own set of constraints, at least where game consoles from the 80s and 90s are concerned.
  2. You can also crush an enemy under a see-saw: When he's walking under the raised portion of the see-saw, just jump onto that raised portion.
  3. This is excellent news! I do have a few questions though: 1) I know this new compiler is very early in its development, but do you have plans to offer a tile/sprite editor, or a sound/music editor? If it's not something you've thought a lot about so far, perhaps you could collaborate with people on AtariAge who have already made such editors (mostly for data import/export functionalities)? 2) While the programming language is a central part of the project, another very important part is the debugger. Do you plan to add a proper debugger (with breakpoints, RAM usage monitor, interrupt monitor and time-to-next-VBLANK monitor) into CoolCV? One thing that is difficult with programming for the ColecoVision is that you don't have any real control over when the VBLANK NMI happens, and if your code tries to do too many operations between VBLANKs, this results in graphic corruption, and perhaps even complete runtime crashes. 3) Your sample Basic code doesn't seem to have any provisions for specifying the compiling setup (i.e. does the game use bankswitching (32K, MegaCart, Activision PCB), does it require the Super Game Module, is it supposed to support (or ignore) interrupts from the Roller Controller, that kind of thing). 4) Will you be offering built-in functions with the language? For example, a standard function to detect the SGM, or a function to clear VRAM at boot/reset, or a function to initialize the sound chip into "silent" mode, so programmers won't need to code their own routines? Those are just questions off the top of my head, I'm sure I could come up with more.
  4. I had an ADAM at the time (with no floppy drive), not an IBM PC, so I never had any reason to bring home the PC floppy disc from school with my games on it, and there was no printer I could use to print the listings of by Basic programs (I probably did write those listings by hand at one point during development, but I threw away those papers a long time ago). I also didn't know how to define and use sprites in SmartBASIC, so it never occured to me to try to reproduce either Big Maze or Basicanoid on my ADAM. One thing I did do on my ADAM was adapt the Basic listings from the classic books "Computer Spacegames" and "Computer Battlegames". Both can be found (along with others) in PDF format here. A few years ago, I actually spotted both books on eBay and decided to buy them just for nostalgia's sake. I still have them, and I'd be willing to sell them to anyone here, if they share this nostalgia and would like to own them in printed format.
  5. I can recall the first real "game" I made back in high school, in Basic. It was called "Big Maze" and was essentially a very large maze of interconnected empty rectangular rooms (think Berzerk but without inner walls, and the player controlled an Otto-like smily face). There were no enemies, so there wasn't a lot going on aside from exploring the maze, but I recall that you needed to find a key to reveal the exit of the maze. My second game (during that same time) was actually an end-of-year assignment. I tried making a clone of Arkanoid in Basic called Basicanoid, and while the CGA graphics looked good, my code was a spaghetti mess and I never got the ball to actually collide with the bricks, the ball was like a ghost flying off the screen and making the program crash! I ran out of time and handed in "Big Maze" instead!
  6. All I can say on this subject is that the number of bugs reported to FPGA core authors (forcing the release of updated cores) looks roughly about the same as the number of issues reported in software-based emulators. That alone tells me that FPGA solutions are not really "better" than emulation, just different. Also, the way FPGAs are used today to replicate game consoles and handhelds is a relatively recent thing, and I have to wonder how long those FPGA chips last. Will Analogue FPGA products still work 20 years from now? Maybe, maybe not. And as FPGA technology progresses, will the cores developed for today's FPGA chips still work on more advanced FPGAs just 5 to 10 years from now? If it turns out that FPGA solutions are just as transient as original hardware, then for me PC-based emulation will always seem like the better option, because programming a pure software emulator is less of a niche activity than learning to program FPGA cores.
  7. If this bug can be reproduced under emulation, then that's where all efforts should be concentrated. An emulator equipped with a step-by-step debugger should be enough to track the problem down and ultimately provide an explaination for the bug. Testing on real hardware is a good thing, of course, but it's absolutely necessary only if emulation fails to reproduce the bug. Just my two cents.
  8. So this is a prequel to The Heist? It has the same music!
  9. Oh! Alright then, I'll be curious to see what that box looks like.
  10. Thanks, but I have the controller itself, so I can take a picture of it anytime I want. The box is what I'm after.
  11. I want to make a ColecoVision trading card for the Joy Sensor controller, but the box picture I have in my archives is rough and not suitable for putting on the front side of the card. Does anyone here own this controller with the box? If so, could this person be persuaded to scan this box for me, at 300 DPI? The box has a weird trapezoid shape, so 3 scans would be required to get all the image details of the frontal side. I'll take care of uniting those three scans into a single image. Crossing my fingers...
  12. Perhaps not the joystick port, but a small module similar to the Super Game Module that plugs into the front expansion port should be doable. I don't know the hardware technicalities involved in making the ColecoVision communicate with a PS2 keyboard, mind you, but the CollectorVision Phoenix can do it, so I'm pretty sure it can be done.
  13. Just to quickly chime in, the ADAM went through multiple board revisions during its short life cycle. Some of these boards may show unforseen problems with homebrew hardware. This is not the first time such issues have been reported in the ColecoVision homebrew community.
×
×
  • Create New...