Jump to content
IGNORED

New title for ColecoVision: Robotron 2084


AnalogKid

Recommended Posts

Sorry this thread is getting detailed, but… 

 

I don’t know how I ever missed this. Thought I had all the Huggins classics. I wonder if Scott would mind if we lumped together all of them in one easily accessible (or pinned) archive,

similar to the 7800 Trebor Pro Pack. Didn’t he do the amazing (but never finalized) follow up to Frenzy?

Link to comment
Share on other sites

12 hours ago, phattyboombatty said:

I don’t know how I ever missed this. Thought I had all the Huggins classics. I wonder if Scott would mind if we lumped together all of them in one easily accessible (or pinned) archive,

similar to the 7800 Trebor Pro Pack. Didn’t he do the amazing (but never finalized) follow up to Frenzy?

I was in touch with Scott back in 2015 and he managed to retrieve a bunch of ROMs off an old external drive he had used during development.  Sadly, not everything was there but he did share the ROMs he found with me and was happy for them to be shared with the community.  I thought I had done that but perhaps not.  I'll put a new thread together over the coming week to address this.  The follow up to Frenzy, called Frantic, was abandoned.

Edited by Ikrananka
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

Here's a progress update on Robotron 2084. The video capture program I used seems a little off so the action looks a little faster than it actually is, so just tweak the playback speed.  I managed to get 18 enemies, 6 humans, 4 enemy shots, a spheriod, 4 player shots, and the player all moving around the playfield at the same time with a good animation rate and just under 1K. The last bit that needs work is quarks spawning the tanks, scoring, and sound and then it's bug fixing and polishing.  In my battle with beating the refresh I've learned a lot about generating optimal assembler and I'm going to share my findings in a separate post.

 

Robotron 2084 Demo

 

 

Edited by AnalogKid
  • Like 13
Link to comment
Share on other sites

Heya -- recently found out about this project via your Facebook post and asked you about a dev blog.

I'm curious if this is written as strict assembler, or you are using one of the c libraries, or a hybrid?

 

Unlike the 2600 that is very well documented at this point (yet I don't have much interest in hacking), I am curious about the ColecoVision and am not quite sure where to start.  I'm comfortable with C and can relearn ASM for 6502 on demand, but the Z80 is a new beast for me (but very well documented) and the ColecoVision completely unknown to me.

 

Again, this looks fantastic.  Going to fire up your ROM on the MiSTer in a few hours.

Link to comment
Share on other sites

20 hours ago, durkada said:

Heya -- recently found out about this project via your Facebook post and asked you about a dev blog.

I'm curious if this is written as strict assembler, or you are using one of the c libraries, or a hybrid?

 

Unlike the 2600 that is very well documented at this point (yet I don't have much interest in hacking), I am curious about the ColecoVision and am not quite sure where to start.  I'm comfortable with C and can relearn ASM for 6502 on demand, but the Z80 is a new beast for me (but very well documented) and the ColecoVision completely unknown to me.

 

Again, this looks fantastic.  Going to fire up your ROM on the MiSTer in a few hours.

What you're seeing is entirely written in C using a library but that being said, for this project I've paid close attention to the generated assembly file to get the best performance.  I'm going to be writing a separate post about all the performance related tricks and pitfalls I've learned with this project.  A seemingly benign change can save you or cost you hundreds or even thousands of clock cycles and if my math is correct, you only get roughly 59000.  If you already know C well then that's a very good start.   Next you'll want to learn how the SDCC compiler wants you to write C code, and that's what I'll be covering.  All my games have the same core engine that I wrote which was designed to make animation simple and it's why I can crack out a game in a couple months because I only have to focus on the unique aspects of the particular game.  The main challenge for Robotron, other than scalability, was integrating character based "sprites" with regular sprites because there's the extra code for rendering the characters and there's twice the collision detection code plus the scaling 255x191 to 32x23 and vice versa is a pain because of all the inaccuracy it introduces.  If I could have written it using only sprites it would have been done in a month, but there would have been so much sprite flicker that it would cause seizures.

  • Thanks 1
Link to comment
Share on other sites

6 hours ago, AnalogKid said:

What you're seeing is entirely written in C using a library but that being said, for this project I've paid close attention to the generated assembly file to get the best performance.  I'm going to be writing a separate post about all the performance related tricks and pitfalls I've learned with this project.  A seemingly benign change can save you or cost you hundreds or even thousands of clock cycles and if my math is correct, you only get roughly 59000.  If you already know C well then that's a very good start.   Next you'll want to learn how the SDCC compiler wants you to write C code, and that's what I'll be covering.  All my games have the same core engine that I wrote which was designed to make animation simple and it's why I can crack out a game in a couple months because I only have to focus on the unique aspects of the particular game.  The main challenge for Robotron, other than scalability, was integrating character based "sprites" with regular sprites because there's the extra code for rendering the characters and there's twice the collision detection code plus the scaling 255x191 to 32x23 and vice versa is a pain because of all the inaccuracy it introduces.  If I could have written it using only sprites it would have been done in a month, but there would have been so much sprite flicker that it would cause seizures.

Thanks -- I'll be looking forward to your post. 

I'm frankly quite impressed that this was written in C and gives me some confidence to begin working with that, letting the assembly fill in as needed.  Given the impressive results people get from Batari basic, I suppose I shouldn't be too surprised the compiler can produce some lean binaries.

 

Yeah, I previously read how you were using "characters" as a trick and thought it was quite clever.   At first glance of the video you posted I was amazed at how busy the screen was, and how smoothly the various objects were moving around.  Wizardry!

 

Very much appreciate the thoughtful reply and some pointers on how to get started with the development.  I'll check out some of your other games, too.  Hell, if they were published by Collectorvision or OpCode, they might be lurking on a shelf behind me as I write this.

Link to comment
Share on other sites

Positively outstanding!

 

This is holy-grail stuff. Never thought we'd see Robotron on Colecovision, but you've made it a reality.

 

How much space does each level take? Since these are "characters" is it a lot less than we might otherwise think? How many levels will you be able to fit into the .ROM?

Link to comment
Share on other sites

On 2/20/2022 at 12:40 AM, zyzzle said:

Positively outstanding!

 

This is holy-grail stuff. Never thought we'd see Robotron on Colecovision, but you've made it a reality.

 

How much space does each level take? Since these are "characters" is it a lot less than we might otherwise think? How many levels will you be able to fit into the .ROM?

Well there is a sort of pattern to the levels, increasing numbers of robots, increasing numbers of electrodes, increasing numbers of hulks, etc. and then a brain wave every X waves and a tank wave every Y waves, so I can put wave initialization into a loop with some incrementing counters.  Meanwhile the enemies will get a little faster over time, will shoot more often, etc.   Unfortunately there are limits to how many enemies I can throw at the player.  I'm just squeaking by under 1K, I've used all 32 sprites, and I'm just beating the screen refresh when I have all the knobs turned up to 11.  I've been using the Atari 5200 version of Robotron for comparison of what I should be able to achieve though the 5200 has more RAM and some helpful BIOS routines I don't have.  However the 5200 version has very low-rate low-res animation which is how they managed to squeeze the game onto the console.  I don't want to sacrifice any of the visuals.

Link to comment
Share on other sites

  • 3 weeks later...

Now all we need is a 3D-printed custom ColecoVision (stock) dual-controller holder to hold the two sticks in place similar to the 5200 controller holder included with its version of Robotron and also with Space Dungeon (I own BOTH units and have over 400+ titles, many of them exclusive to their individual units, on each of the Atarimax carts for them). After all, not everyone has the Roller Controller (even though I will be getting most of the modules for my C-V unit eventually) and this idea would be far more economical for those folks rather than paying out vookoo $$$ to get the Roller Controller solely for the purpose of using it (and holding them in place) for both sticks simultaneously.

 

.....and since you have the ROM available for the MISTer, can we Atarimax owners get one too? I too, would love to follow along with the progress of this terrific soon-to-be ColecoVision classic. 5200 owners (including myself) already get our hands on every WIP ROM that comes out for our testing enjoyment, why not here?

Link to comment
Share on other sites

I personally think the Roller Controller is a must purchase for the CV and ADAM due to numerous reasons:

 

- the cables that connect it to a CV act as extension cables to allow one to sit roughly 5’ or 6’ feet from the CV

 

- it works great with ADAM application programs like PowerPaint in joystick mode

 

- it breathes new life into numerous CV and ADAM games when used in joystick mode like Gyruss, Kaboom, Centipede and others

 

- the fire buttons, left and right handed setups provided, are much more suitable than the stock hand controller’s fire buttons for extended play sessions


- perfect option for dual controller games that have been and will be released

 

- a defective RC’s power adapter cable/connector can be repurposed on a Driving Module so that batteries are no longer needed


- it’s readily available and usually can be found for a decent price (without box) so a 3D printed hand controller holder wouldn’t be needed… but options are always welcome

 

- Slither is one of my favorites and a very good game! NewColeco’s controller mod rom is freely available but Slither really needs to be played with a Trakball.

 

- the weight of it seems like it will be a much better option than a 3D printed dual controller holder for a game like Robotron.

 

 

 

 

 

 

Edited by NIAD
  • Like 1
Link to comment
Share on other sites

  • 1 month later...
I personally think the Roller Controller is a must purchase for the CV and ADAM due to numerous reasons:
 
- the cables that connect it to a CV act as extension cables to allow one to sit roughly 5’ or 6’ feet from the CV
 
- it works great with ADAM application programs like PowerPaint in joystick mode
 
- it breathes new life into numerous CV and ADAM games when used in joystick mode like Gyruss, Kaboom, Centipede and others
 
- the fire buttons, left and right handed setups provided, are much more suitable than the stock hand controller’s fire buttons for extended play sessions

- perfect option for dual controller games that have been and will be released
 
- a defective RC’s power adapter cable/connector can be repurposed on a Driving Module so that batteries are no longer needed

- it’s readily available and usually can be found for a decent price (without box) so a 3D printed hand controller holder wouldn’t be needed… but options are always welcome
 
- Slither is one of my favorites and a very good game! NewColeco’s controller mod rom is freely available but Slither really needs to be played with a Trakball.
 
- the weight of it seems like it will be a much better option than a 3D printed dual controller holder for a game like Robotron.
 
 
 
 
 
 

I agree, it’s a great controller / accessory. It’s not quite the same feel and build quality of the 5200 trackball, but close.

Never thought about using the power adapter as a driving module ‘battery eliminator’. Gonna have to get a parts RC and do that!


Sent from unspecified hardware using indeterminate software
Link to comment
Share on other sites

24 minutes ago, Captain Cozmos said:

Speaking of the Roller Controller I would love some direction to toy with it under Assembly Language.

 

I have bee able to use regular controllers without using anything other than the ports but have yet to have success with the Rollers.
The extra two buttons on the SAC are another issue.

This is off-topic, so if you want to discuss further, you should make another thread. This is all I'll say here...

The 2 extra SAC buttons are essentially keypad buttons.

The spinners are at $73EB and $73EC. I don't recall the details, but if you have the programming guides, that would help.

 

Link to comment
Share on other sites

6 hours ago, nurmix said:

Never thought about using the power adapter as a driving module ‘battery eliminator’.

Actually it was Yurkie who came up with that idea some 7-8 years ago and posted pics of his modded Driving Module with Roller Controller power adapter.

  • Like 1
Link to comment
Share on other sites

Here's the final preview video for Robotron.  It's feature complete and now into the final testing and fine-tuning stage.  I've moved some critical code out of C and into assembler libraries because frankly SDCC just doesn't have the AI necessary for writing efficient code for structs.  As a result I was able to get up to 20 enemies on the screen along with 7 humans, 8 bullets, a couple of spheroids, and the player.  The limiting factor is now the 1K RAM and I've just about used it all.  I strongly recommend checking out GearColeco as a development tool.  It supports stepping through assembler code and has a RAM viewer which not only helps with keeping an eye on free memory and debugging but also helps identify stack leakage.  The video capture rate kind of spoils some of the visuals but there will be another hands-on demo available to play with soon.

 

 

  • Like 12
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...