Jump to content

Pixelboy

Members
  • Content Count

    8,589
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Pixelboy

  1. Amidar was never made for ColecoVision, probably because Pepper II is the same kind of game, only better.
  2. And the ColecoVision doesn't have enough maze games as it is, so yeah.
  3. I recall a time a few years ago when Crush Roller often came up in discussions. So it's either that or Bandido or Hard Hat. Circus and Crash were released on other early consoles, notably the Atari 2600.
  4. I have a feeling it's going to be one of these Exidy arcade games: Bandido Circus Crash (a.k.a. Dodge 'Em) Crush Roller Hard Hat
  5. No, I mean 128 Kbytes, like what was used in The Legend of Zelda on NES.
  6. At the time, yes you did. Bankswitching over 32K implied using 64K ROM chips, or 128K, or higher. Those bigger ROM chips weren't commercially viable until the NES came long a few years later.
  7. Rest assured I won't rest until the one-player mode in Utopia is fully functional. Problem is, in order to have any meaningful discussion with Mystery Man about how to improve the AI, I have to play the current incarnation of the game and get a real feel for the current AI's alleged shortcomings, as reported by the game's beta-tester. This is going to take some time, and chances are I won't have any time to do this in 2020.
  8. Thanks for your input, Matthew!
  9. My wish would be to make it possible to have vector arcade games like Asteroids Deluxe, Eliminator, Gravitar, Lunar Lander, Star Castle and others which are a little too graphically intensive for a vanilla ColecoVision to handle. I could see the CollectorVision Phoenix welcoming home ports of those arcade games, if the F18A can support a vector engine that can display a lot of vectors on the screen.
  10. I want to be sure I understand: Where are you taking that "2kb" from? 256 x 192 = 49152 pixels 49152 bits / (8 bits per byte) = 6144
  11. I think I understand what you're suggesting, but at a certain point, the canvas data has to be cleared before you can use it for rendering the next screen update.
  12. I see three main challenges with adding vector-rendering capabilities: 1) Assuming the rendering of the entire screen is raster-based (line by line) then a screen buffer would be needed to draw all the vectors into, before sending the buffer to the TV screen. Assuming we have enough VRAM space to contain all the buffer, how do we quickly clear that buffer (after VBLANK) before drawing the next set of vectors towards the next screen refresh? Should we just redraw all the vectors with black pixels? Would we have time to do that and keep it a 60 frames per second? 2) If "vector objects" are constructed as a series of points defined as an angle + distance from a (0,0) origin point, then scaling and rotation could be done relatively easily around that origin (sinus and cosinus could be pre-calculated for a distance of 1) as long as the VPD can multiply the given cos and sin results by the required distance, and this implies multiplying floating-point values. Multiplication is always a bitch to compute... 3) If we go with a 256 x 192 display (I'm thinking ColecoVision here) then vectors could be drawn as basic spreads of pixels. But at a higher resolution, it would be good to have a line thickness parameter. Rendering a thicker line has to put more strain on the vector rendering. There are probably other challenges I'm not thinking of, but those are the ones that come to my mind. (And I'm now realizing that this thread may not be the best spot to post these comments, as I'd be curious to see what Matthew has to say.)
  13. I'm guessing that little enclosure is a prototype, since it has no stickers on it. The controllers are oriented on the wrong side, and the ball knobs are, well, funny. You can tell the guy who made this has never seen a real ColecoVision console. This is really misleading. Like Nintendo is actually going to allow Donkey Kong to run on this thing. Yeah, right. Also, regardless of the game selection, who's going to want to play this on that little TV replica? Am I supposed to put this little TV on a high shelf and play standing up? 'Cause I need two hands to use the Coleco controller, and I don't have a third hand to hold up that little TV next to my face.
  14. Alright, and your game "uploads" this code from the cart to the gpu at boot/reset?
  15. Interesting. And the Phoenix reproduces all the capabilities of the F18A precisely and at the same potential speed?
  16. I just had an interesting thought regarding the Phoenix. Would it be hard to alter the ColecoVision core to replace the native VDP with a vector VDP, something that would draw vectors much like the Vectrex, but designed to output those vectors as a raster image on a regular TV screen? The ColecoVision CPU, sound chip and everything else would remain unchanged, but the VDP would generate vectors only, and the programmer would write bytes to VRAM following a different "protocol". I can imagine several graphic modes with this alternate VDP. The most straightforward would probably be for the programmer to write two sets of screen coordinates in VRAM for each vector to draw, and once the entire screen has been drawn, the VDP would "clear" VRAM (in addition to generating a VBLANK signal to the CPU) so that the programmer has a clean slate to draw on upon each screen refresh cycle. Another graphic mode would offer object-driven features: Define an object in VRAM as a static series of vectors, and then tell the VDP to draw the object somewhere on the screen, possibly with a scale and rotation factor applied. Not sure if the Phoenix's Spartan FPGA could handle vector scaling and rotation like that (in addition to supporting the rest of the ColecoVision architecture) but I think it would be super fun to program for. And then there's another obvious graphic mode, which would offer colored vectors. This would add a color byte to each pair of screen coordinates. Again, I'm not sure it can be done as I describe it. Perhaps have a bigger VRAM with multiple "page buffers", and the VDP would clear the previous page while it's writing the current page, in order to always offer a clean slate for the programmer to refresh vectors on. Having to clear VRAM manually would suck... Anyway, I'd call this altered FPGA core the VectorVision. Catchy?
  17. Oh my, that's more than just woodgrain, that's actual wood!
  18. That's what I've said...but someone else thought that was a bad idea! 😉 It in all actuality it would be perfect, especially with the leaf-switch push-buttons. Well, if you want to submit a 150$ controller to that kind of abuse, be my guest. Although it's true that with leaf-switch push-buttons, you don't have to mash the buttons like crazy. Just place the bottom of your palms on the controller's surface, and tap the buttons rapidly with the tip of your fingers. That shouldn't wear down the buttons in the long run. (And yes, I know those buttons are designed for heavy-duty usage, but at 150$...)
  19. The results of the poll are what is important at this point in time. A pre-order list will happen only if the poll demonstrates that there is enough interest in the Asteroids Controller.
  20. I just finished sending an e-mail to each of my active customers, excluding those who I know have already answered the poll. Hopefully this will provide a little boost of participation.
×
×
  • Create New...