PkK

I don't think they did. Or if they did, they didn't get a trademark. Philipp

Compression (RLE and Huffman) is used for graphics data (tiles and sprites). I even have my own Megacart pcb design that I could use (and intend to use for some future projects). But Io was meant to be a 32K game, and I don't want to change that now. I've recently made a few improvements in SDCC to bring Io code size down a bit (SDCC now generates better code for switch statements and some comparisons). I'll see how much I can fit into Io in the summer. One option I'm currently considering is handling it similar to what I did in SCJ3. * Additional levels (with the second graphics set for Io). * Some sound (I'm not that good at sound, so these will rather be very short music sequences corresponding to what happens in game) * Longer Music for the level won / lost / intro screen only (so as to not interfere with the music-like in-game sound). This will also keep the total length of the music short (and thus the required ROM space low). Philipp

While I still have a few ideas for cheap (in terms of code isze) features to implement, there are also the big items: * Sound * Music * Additional levels in a setting on Io, requiring a second graphics set I probably won't be able to fit all of these. Which do you consider to be the most improtant? Philipp

Most homebrew games don't need the SGM. None of my games needs it. Philipp

Another update. The highlights would be the 3 different levels and the savegame codes. There also were plenty of bugfixes. List of improvements since 0.11: * Bolder font * Fix saboteur target selection, tornado start point * Plant growth * Fix roller controller support * Menu debouncing * Fix simultaneous upgrade of HQs in two-player mode * Fix effect of volcanic eruptions and earthquakes on HQ of second player * Fix node upgrade and source node construction at construction site limit * Queue for construction sites for in-order processing * Make severe threats (earthquakes, volcanic eruptions) less common than other threats * Fix restoration of sulphur vents on destruction of sulphur node construction site * Savegame codes * Fix late-game buffer-overflow bug * Increased number of levels to 3 * Fix score calculation Philipp Io-0.14.rom

RAM is not that easy either. The cartridge slot doesn't have a read or write line. There is no easy way to distinguish between read and write accesses. If one really wanted to add RAM, I guess one could use one of the address lines for that, i.e. map 8 KB of RAM into a 16 KB window. Then e.g. the value written at address x could be read from address x + 16384. I guess compiler support for such an architecture would be unlikely though. Again, the expansion port makes it easy to add RAM. Philipp

Can't do that in a CV cartridge (would be possibleusing the expansion port though). Philipp

But for accessing banked data from banked code, one wants two areas. If each is 8KB, that leaves only 16KB for the common area 0. Philipp P.S.: The bank sizes are not hardwired; I intended to offer the kit with different firmware for different bank sizes. Maybe I should even look into allowing to change the bank size at runtime.

The current prototype uses 4KB. I've created a new thread over in the programming forum for discussing the technical details: http://atariage.com/forums/topic/262620-whats-the-best-bank-sizes-for-a-bankswitching-cartridge/ Philipp

I'm working on a bank-switching cartridge (originally intended for Tunnels & Trolls). It has 512 KB of Flash ROM. I've decided to use a layout like this: Common area 0: Directly mapped to the lower part of the cartridge. Meant for frequently-used code and data, standard library, etc. Bank area: Mapped to a selectable location on the cartridge Common area 1: Mapped to a selectable location on the cartridge Having two mappable areas allows e.g. for code from one bank to read data from another bank. This layout and the names are inspired by the Z180. How big should these areas be? Personally, I prefer a large common area 0, allowing large parts of the code to be placed there. Therefore the current prototype firmware used a 24 KB common area 0, a 4 KB bank area, a 4 KB common area 1. On the other hand, having larger mappabe areas would allow for larger arrays in mapped memory, and would allow more efficient use of mapped memroy for code (since objects in mapped memory are difficult to handle if they cross bank boundaries). What's do you think? Philipp

I've never heard of a CV power supply failing in a way that damages the CV. Usually when they break, the voltage gets lower, resulting in graphics errors or the CV not turning on at all. But the CV will still work with a good power supply. Philipp

This is one of the prototypes tested yesterday (the EEPROM is missing on this one to allow easier access to the contacts for measurements): The final version will be very similar. The Flash ROM is PLCC. Philipp P.S: The design would also support a 1MB Flash ROM, but since these are hard to obtain and expensive, the final version will most likely come with a 512KB Flash ROM.

Today, I successfully tested a prototype of a new version of the Homebrew kit. It is not meant to replace the current one, but to allow certain homebrew projects not possible with the old one. Features: * Twice as expensive * 16 times more ROM (512KB instead of 32KB) * Infinitely more EEPROM for savegames (32KB instead of 0KB) Years ago, I started working on this for my Tunnels & Trolls game, but then other projects took my time; only recently did I start working on this version of the homebrew kit again. Philipp

'Just came back home from a testing sessesion. We found 4 bugs specific to two-player mode, and a few other issues (one of them specific to the plain controller - hadn't noticed it before, since most of my recent testing was done using roller controller and emulators). I don't have a talent for music or sound either. So I leave the music to others (usually to composers that have been dead long enough for their copyrights to expire). Philipp

Compiler improvements also tend to take quite some time. Since I am also an SDCC developer, after looking at the asm generated for my game, I start improving SDCC to generate better code. Sometimes it's just a few rules for the peephole optimizer, implemented and tested within less than an hour. Sometimes it's a more complicated but still simple optimization that might take hours or days. And sometimes it takes years. Philipp

Testing definitely takes a lot of time. Especially since my games often to have simultaneous multi-player, which means that two people are needed for testing. Philipp

I wrote a small test program to look into the behaviour of Super Action Controller (SAC) and Roller Controller (RC). It displays the state of the controller ports at 0xfc and 0xff after spint and vint. I tested on a setup with an unmodified CBS RGB ColecoVision with various controllers. Results so far: 1) The bits of ports 0xfc and 0xff relevant to the SAC / RC are bits 4, 5 and 7. No surprise here. 2) It doesn't matter if port 0x80 or 0xc0 was previously written to (at least not in the short term). 3) For the SAC and RC, bit 4 is low if an interrupt-generating change recently happened. No surprise here either. 4) For the SAC, bits 5 and 7 give the quadrature of for current state of the spinner wheel. The accuracy of this seems to be 45°, while interrupts are generated every 90°. Thus just using the interrupt only gives half the precision of the SAC. The interrupts happen, such that bit 5 can be used to get the direction of the turn. 5) For the RC, bit 5 gives the direction of the previous turn. Bit 7 is nearly always the opposite of bit 4. Brief exceptions only happen during transitions. 6) For no or plain controllers, bit 7 is always 0, while bits 4 and 5 are always 1. That yields: 1) Checking bits 4 and 7 might give a heuristic: For the SAC, they are the same about half the time. Without the SAC they are nearly always opposite. Gives a 50% chance of detecting a SAC at a port. Higher is the spinner moves when players pick up the controllers after switching on the CV. Even higher when SACs are used in pairs. But we will still get false negatives. 2) Check for spint at startup. If a SAC or RC is present, we might get some when players pick up SACs or touch the RC. 3) Check bit 5. For plain or no controllers it will always be 1. If we ever see a 0, we have a SAC or RC. This will still give false negatives as we only have a 50% chance of detecting a SAC at a port and a 75% chance of detecting a RC. Combining all these should give a decent chance at setting a default config of SAC vs RC, but it doesn't seem good enough to just use the information without notifying the player and offering them a chance to change it in the start menu. Philipp P.S.: The test program was compiled with not-yet-released libcv 0.24. test.rom test.c.gz

I'd like to be able to detect the controller type. Is there a known way to do so. Background: In my game Io, one moves the cursor on the screen to decide where to build something. One also scrolls through a list of things to build. With the normal controller, the joystick is used to move the cursor, the list is scrolled one item at a time by pressing the second fire button (and the first fire button gives the actual build command). Moving the cursor is much nicer using the roller controller. So I implemented roller controller support for the single-player mode. But scrolling the list might be nicer using the spinner wheel. So the people using a super action controller could get that instead. Therefore I'd like to know what controller is attached to the CV: 1) Roller controller 2) Super action controller(s) I don't care about plain controllers or unattached controllers being put into one of these categories. Philipp

Here comes 0.11. Improvements over the previous version: * Warn when low on sulphur * Roller controller support * Fix tornado at HQ upgrade construction site * Use rand() instead of custom PRNG * Earthquakes * Volcanic eruptions Planned features for future versions: * More levels (with later levels possibly in a futuristic setting on Io instead of Earth) * Performance optimization? * Sound or music * Savegame codes * Plant growth Philipp Io-0.11.rom

Sine I also might want a few power supplies, I contacted them, they wrote that there would be more within a few weeks. Philipp

You can contact me at philipp@colecovision.eu. But shipping might be slow or expensive (you state your location as "PA", which probably means Panama or Pennsylvania; neither one is close to my place). Philipp

The power supply is, IMO, the main weakness in ColecoVisions today. Often, power supplies no longer supply a sufficient voltage on the +5V line, and the graphics chip doesn't tolerate voltage drops on that line. Out of multiple old ColecoVision power supplies I've seen, only few worked well. Personally, I often used an old power supply with the +5V line supplied from a programmable power supply instead. However, apparently someone has new power supplies for the ColecoVision. They seem to consist of a power supply capable of supplying the voltages needed by the ColecoVision, and an adapter plug to attach the 5-pin din connector on the power supply to the ColecoVision. Who is making these? Do they work well (I've seen forum posts of people who have them, and there are no complaints so far)? What are the voltage / current specifications? Apparently, a German shop was selling these (but they are curently sold out there). Any other places to buy them? Philipp

If you use a FR or DE power supply, you just need a simple adapter plug, instead of having to use a converter. They probably are be easier to obtain from the UK than US ones, too. Philipp P.S.: But working ColecoVision power supplies, no matter from which country, are not easy to find. In my experience bad power supplies are one of the main causes of ColecoVision problems, in particular graphics problems.

With the changes made in the last few days, the game Io has become quite playable, so I decided to post the current development version, 0.10, here. Here's a quick description of some important screen elements: * "Sulphur in HQ": Shows the current amount of sulphur in the HQ (you loose when this reaches 0, and the sulphur storage capacity of the HQ * "Workers": Shows the number of free workers (i.e. those not currently working on a construction site) and the total number of workers * "HQ Level": Current HQ level. Higher levels increase the amount of workers and the sulphur consumption. You win the level by increasing this to 10. * "Toolbar": Shows the currently selected tool (same as cursor) and a clickable list of tools (you can also change the tool by using the right fire button). At certain moments,such as after changing the tool, the toolbar is briefly replaced by a display of the name of the new toll. * "Sulphur Source": Provides sulphur. The suplhur can be supplied to other storage locations, such as your HQ, when there is a road or rail connection. * "Rock": Construction is not possible here. * "Sulphur vent": Can be turned into a Sulphur Source by building a depot on top of it. * "Debug Info": Just some data to help me during development. Does not affect gameplay The main aspect of the game is to supply enough sulphur to your HQ by building a transportation network consisting of sulphur sources, depots, roads and rail. At the start of the game, you should first connect your sulphur source to the HQ. Rail connections have higher capacity than roads, but need more time to construct. One unupgraded sulphur source supplies enough sulphur for one idle worker. Busy workers need twice as much. When the cursor is a above a node (HQ, depot, source) of the transportation network, the toolbar is replaced by a status display: It shows the current amount of sulphur in the node, the maximum capacity and the level of the node (higher levels have higher capacity). The difficulty level affects the game in various ways: * Starting amount of sulphur in HQ * Storage capacity at HQ * Amount of rocks on the map * Frequency and severity of threats Philipp P.S.: There is an older thread on the previous development of Io. When released, the game will come in yellow cartridges. P.P.S.: Improvements over the previous version 0.9: * Blink background on threat * Level loading infrastructure * Level editor (not part of the game) * First level * Fix destruction of railway curve construction sites * Fix bankruptcy in two-player mode * Fix demolition of railway curves * Fix tool selection on lower toolbar Planned features: * Earthquakes (destroying infrastructure, opening new sulphur vents, closing old ones, toggling rock in places where rock is optional) * More levels (with later levels possibly in a futuristic setting on Io instead of Earth) * Performance optimization? * Volcanic eruptions (similar to earthquakes, but affecting larger areas at a time) * Roller controller support * Sound or music * Savegame codes Io-0.10.rom

For running a shop, I'd recommend to add an easy way to contact you - I'd add at least email and mail address. Potential buyers might want to ask questions on the items. Having a mail address will increase buyers confidence in being able to return defective items. Currently, there is a small link "contact" on the front page (not visible on other pages), and it is dead. Though on some of the individual items pages, there are "contact" links that are not dead, but according to the description they are meant for rights holders, not customers. How about adding a "Contact" or "About us" page, will all the necessary information and having a link to there at the top or bottom of all pages? Philipp P.S.: Knowing in which part of the world you are located might also give potential buyers an idea on shipping costs. P.P.S.: I see that at least the "Returns" page has a working email link.