Thursday, September 5, 2013

Doriath on ColecoVision, The Tools. (V)

When I first started to see if Doriath could be made on Coleco Vision, I got no idea what are the tools available. After asking on forums, a lot's of people give me some help by telling me where to look for documentation, tools and hardware.

In this article, I want to describe the tools I will be using, my though about it and what I consider to be useful. You does not have to write your software in assembly language, but in my case the choice is clear... assembly language only!

Why? I wanted to get in control of the code and data, explore some limitation of the hardware and I knew that I want to produce the game only on ColecoVision platform. So, no need to port the game and by doing so I can learn more about the machine and its limitation.

Then, the question is... which compiler I will use to produce a binary (.ROM) from the source code I will write (text file)?
I have been suggest to use tniASM for pure assembly language. It's a command line utility, easy to use which can indicate errors by specifying line number where the syntax error occur.

The compiler does not seem to offer much feature. I would have like to see a Map and Listing file, which could help to know the length of functions and data.

I was considering to write my own compiler. In the past, I wrote a compiler for assembly language for some Commodore 64 personal projects. It was a compiler that was producing a disk image, rather than a file!

You may wonder, why someone today will be writing his own compiler if one already exist? In fact, you may be doing so when you see that you can add features or use new concepts. Back to my C64 compiler, I wanted to have an easy way to manage data on a full diskette and not be limited to one file. By writing my own compiler, I could provide keywords that will tell where to place data on disk and eventually automate some disk access without using other utilities.

Basically, by writing your own compiler, you can bring feature that will save you time or give you information to improve what you try to achieve.

Some compilers come with an IDE (Integrated Development Environment) which offer a text editor and debugger. With tniASM, you need to use your favorite text editor and Emulator/Debugger.

Notepad++ is a free and small software which can be run easily and support many features for text editing that we can find in a complex IDE like the Microsoft Visual Studio (text editor).

It support many computer languages and will identify keywords and types by changing colors or style which make them easier to read. It also support the ALT + click and drag mouse feature, which allow to edit columns of text. That feature is very convenient when editing array of data.

Did I think to write my own text editor? In a way yes... when I see that I will be in a text editor, compiling in a command line. Then, getting an error on line # x in file y. Hum... I though there is room for so much improvement that it's seem an interesting project.

I was thinking to have a real-time compiler combine with a text editor. Something which does not need to click... compile, but does self-modify as you type your source. New features like being able to modify code while keeping copy of other versions, allowing the programmer to see if his changes does reduce the number of bytes or clock cycles. Or, to be able to click on the header of a function and tell, add this to a library of functions for reference or re-usability in a newer project. We can even push it further by selecting a bunch of functions set in a library and be able to generate a computer language out of it.

When you are the one writing the software, you can imagine pretty much what you want! You know that the more features you add, the more work hours you will need. As a programmer, I can do barely any kind of software and routines. If it involve so many hours, why not programming something which write software by it's own? I got some serious though about this problem over the years of what limit what a person can write as a program. How we overcome problems which at first we don't know how to solve? Hum, as you can see ideas of big projects are coming out faster than I could make them. I choose to pick up this game & blog writing first. Was it a good idea? ;-P

Back to the tools... In order to execute and debug my game, I will be using an emulator: BlueMSX. It does contain a debugger which allow to enable breakpoints, step through the execution and so on. I don't think it offer a feature to measure clock ticks between 2 points. The only way I can think about profiling stuff is to loop a routine N times and calculate the number of NMI interrupts. Having a precision of 1/60 seconds is not too bad but it could be definitively better, I would say... 16.7 times better!

When I was thinking about having my own compiler combine with a text editor, I was also thinking about emulating the chips. But then, that mean having to support all hardware components, doing reverse engineering on the hardware and so on. In short... a project for the next 3-5 years considering a 4-6 hours of free time per week and not doing any other projects. So, for now, I will focus on the game itself and learn the tools that other did.

Even if testing in an emulator could be good enough, as I am interested to know the details how it work. I got to test some stuff on the real hardware. People are selling their Coleco Vision mostly on eBay.

I am not interested to have one forever but will prefer to have one for testing until the end of the project. I don't like to pile up stuff and prefer to keep things which I use. I could resume my way of consuming goods on saying that I tend to be fast on giving my things and slow on acquiring new stuff. I like organize place and easy to clean. I regret so much when I purchase something which I don't use. So, when it's time to buy I would ask myself many times, do I really need this?

Lucky I am, my best friend is quite the opposite and agree to provide me a Coleco Vision. I promise him the game in return of the rent! Is it a good deal? Well, I guess we will find out only at the end of the project.

On the other hand, I purchase an Atarimax Ultimate SD cartridge. Having the hardware is one thing, being able to put my software in is another thing! There was two options, this cartridge or an EEPROM and an EEPROM programmer. It is more easy and fast to write a file on SD card than it is to write on an EEPROM.

So far, I have receive it and started to experiment how the video chip is working. On my first day, I achieve a stable CPU-VDP (Z80 and TMS99x8) communication for every frame and display 48 sprites on screen (where the limit is known to be 32). On my second day, I tested the text mode by switching the color and char patterns at specific place on screen. I also create a new video mode based on the multicolor mode. But instead of a resolution of 64x48, the new one is 64x192.

You can get my source code, binary and screenshot here:


If you would like to burn an EPROM, there is one available with a PCB for 12$. From the pictures I saw, I think you need to buy a socket if you want to easily remove, reburn and place back the chip. When I will complete the project, I think to go with someone that could distribute the game rather than doing it myself. Being a producer and distributor could be a cool thing to do but that will involve more spending in money and time. With one game only, and the small market potential, I think it make more sense to go with a distributor.

Website for the EPROM cartridge:

An EPROM programmer is necessary in order to program your chips. Eprom programmers like the one from Batronix can program a variety of chips. I don't know the voltage required to write, but I guess the speed being not too fast, maybe a MSP430 combined with enough memory to hold 32 Kb could do the job. A MSP430 (16-bits microcontroller) devkit from TI cost 4.30$ US! That's just a guess, but if someone could come with a programmer around 25$, that will make this solution more affordable.

You can find the this EPROM programmer at

I was talking above about chips emulations. In fact, when analyzing the limit of the hardware, being able to measure things make a big difference between hypothesis and facts. Being able for example to probe the video signal to see the timing of HSYNC and VSYNC via analogue probes and be able to measure data transfers on bus via digital probes could be useful. I saw that Rigol seem to have an interesting product for that type of measurements. However, I did not investigate more about it and there might be other brands which are better.

If I would be thinking to build a new hardware design, then for sure this tool will be required. But, for software development so much can be done without it.

The model DS1102D is a 100 Mhz mixed signal, available for 840$ + Taxes + Shipping at

And as always, thanks for reading!

No comments:

Post a Comment