GroovyBee

The only hardware capable of running these games is either Hive or Bee3. They will not work on any other cart hardware.

Congats Rev, its good to see you winning after so many years of being in the race.

http://www.atari-forum.com is the best place to go for talking about STs

Waiting for the Blix outcry again .

For many people AtariAge is the "go to" forum to discuss all things in Intellivision land. Many folks on here probably call it IntellivisionAge , so you might find it an uphill struggle to attract new blood to your discussions. Best of luck with your endeavour though.

Check out ColouredSquares.bas in the contrib folder of IntyBASIC. It draws lines in that mode.

Man, you gotta laugh at the bullshit posted by the trolling fucktards in my threads. Now down to the business at hand. Firstly, I'd like to publicly apologise to those people who asked me for pre-order refunds and didn't get a timely response. Work and life have kept me away from AA for far too long. As a priority those people have all been sent PMs today and will be dealt with ASAP. Secondly, to paraphrase Whose Line Is It Anyway: "Free refunds for all!” I'll be contacting everybody else who pre-ordered Rocketeer or Mars Minis and giving them a full refund too. Please wait until you are contacted by me in PM, so I can keep track. “Why am I doing this?”, I hear you ask. Looking at my upcoming schedule (and other factors), I don't currently have the time to run a comprehensive test programme, fix any lurking and hard to find bugs or build/test/ship the remaining carts. So it seems like a good time to draw a line under this long running saga. Plus the last year has hammered home that it doesn’t matter how optimistic you are about getting things done, life always finds a way to kick you in the nuts.

You might find this Z80 to 6502 "recompiler" useful as a starting point :- http://atariage.com/forums/topic/247596-z80-6502-recompiler-used-with-pentagram-port/ It has been used to convert several ZX Spectrum games over to the A8. With some manual optimisations afterwards, the games are quite playable and sometimes play faster!

That method is OK for something like Berzerk, as long as you stick to the same kind of restrictions seen in the 2600 version. As a side note, my KillBotz! game does something similar. For Robotron, you'd end up needing some kind of "dirty" BACKTAB/GRAM card manager and a bunch of pre-shifted graphics to handle arbitrarily overlapping enemies. The enemies in the game would all have to be the same colour too. If you don't let the enemies overlap, you would end up using too much screen real estate because of the restricted Inty screen height. Creating compelling ports of games from either the arcade, or from other machines is mostly an exercise in compromises. They are needed in order to capture the "essence" of the game and to also make what you actually implement fun to play.

Nah... It has the same "problems" as an Inty version of Robotron. They are booth games that need way too many compromises for them to be any fun to play. Having said that, I did experiment with something I called "Slime-o-tron" a few years ago. A few people saw it demoed on our stand at PRGE last year. It uses coloured squares mode for the enemies, but it wasn't all that much fun to play, so I dropped the idea.

Which assembler and linker is this? Can you provide a short example that demonstrates your problem?

Its a modern and efficient compiler and its syntax is not all that much different to C. It has the same loop constructs but a much more limited set of variable types.

There is no real reason why the game couldn't be done in IntyBASIC. Having said that, it has been discussed recently here, so maybe somebody is already working on it (not me ).

Seems to me that you forgot to add "Fumes" and "Attracts drama queens, BS mongers and trolls, like flies on the proverbial" as the first two items in your list .

What is the crystal frequency on that PCB? Its the grey looking can next to R9 and R10.

Good luck with your retro and real life projects. If you need programming help, drop into the programming forums any time.

Nooooooooooooooooooooooooooooooo!

Good luck with whatever it is.

Some solutions :- - Use 42k.bas to get the largest ROM space for your game. - IntyBASIC already supports the PSG in the ECS (see the manual for channel numbers). - Initialise the ECS PSG into a good state using nanochess's code above. - If you want to use ECS controllers then use CONT3 and CONT4. - Use the code here to detect if the ECS is plugged in.

If you are using the ECS's 8bit RAM, PSG or keyboard/controllers then you can still have a 42K word ROM (or 84K bytes). A 42K word ROM just needs to map out the ECS ROMs so that they don't interfere with the cart's on-board memory map.

Shouldn't the Y register be loaded with 31*4 and not 191?

Sometimes, I like to add additional data to the end of the bitmaps section in a file generated by intycolor. To save manually editing files (not ideal in a complex build process), is it possible that a suitable command line parameter, e.g. -i, could be added? For example, if you added "-i aFileName" that would generate a line with an include "aFileName" in the resultant output file.

For mocks, I normally do the following :- Draw the BACKTAB graphics and any sprites that match BACKTAB's pixel size (e.g. anything with ZOOMY2 set in IntyBASIC) in an image that is 160x96 (w x h) using the STIC "rules" for colour stack mode or foreground/background mode (as appropriate). Scale that BACKTAB and sprite image to 200% in both X and Y, thus making an image that is 320x192 (w x h). Draw the half height sprites separately, and then scale them by 200% x 100% (w x h). Copy the"half height" graphics into place, accounting for sprite priority etc. Apply suitable scaling to any sprites that use ZOOMY4, ZOOMY8 and then add them to the composition. Any sprites that are to be displayed using ZOOMX2 must be scaled in X by 400% before being placed into the BACKTAB composition.