The official "ColecoVision 2" thread

[NIAD]

Can SmartBASIC be compiled? Because interpreted BASIC is kind of useless for game development.

 

In case SmartBASIC can not be compiled, guess what I am going to suggest?

 

BTW, can we move to the CV2 thread?

While most SmartBASIC programs that one may run across are still interpreted, numerous programmers from back in the day did compile their Basic programs into Machine Language programs... ie: PowerPaint by Soloman Swift/Digital Express and ADAM Bomb II by Steve Pitman. The authoritative figures on this subject would be Rich Drushel (Dr. D) and Dale Wick (HardHat) so hopefully they see this and can chime in.

[+opcode]

A problem with using ADAM tools is that we would be stuck with the TMS9928/SN76489.

With MSX Basic we get full access to all the V9958 features, AY-3-8910, etc. We get simple BASIC commands for everything, from color palette manipulation to scroll to sprite control, sprite collision, sound MML, and it can be compiled in run time. I have seen some really professional looking games done in compiled MSX BASIC. Check the video I just posted. That is compiled MSX BASIC controlling a V9990 video chip. A short program was created to zoom in an image, similar to SNES mode 7. Really impressive.

 

If the idea is to create a platform for those interested on retro games, retro computing and retro programming, then it needs to be easy to use, accessible and fast. Nowadays nobody is going to learn peeks and pokes to create a game.

Edited March 19, 2013 by opcode

[HDTV1080P]

It appears MSX Basic is more powerful compared to the Coleco SmartBasic version 1 and 2,however I would need to do more research.

 

In the Coleco Adam world Walters Software company which was one of the best 3^rd party developers for the Coleco Adam designed a new operating system for the Adam called EOS 9 which was an improvement over the official Coleco EOS 6 operating system. Walter’s Software also made several cartridges for the Adam computer that installed the EOS 9 operating system along with an Adam machine language software called Adam Desktop. When the reset button was pushed or pulled on the ColecoVision/Adam both the new operating system and new Adam machine language Smartkey driven program was installed. There was also a Project Name by Line cartridge that Coleco used to create Supergames and ColecoVision games.

 

Therefore, it would be possible for a programmer who owned the Ultimate SD cartridge to make a modified operating system that installed a version of Coleco SmartBasic on the ColecoVision II.

 

The most important part of the ColecoVision II development is to get the hardware design with the features that people want. As long as there is both a PS/2 keyboard interface and a SD card slot interface on the ColecoVision II then later on videogame developers and possible Adam programmers might be interested in developing special operating systems and programs for the ColecoVision II.

[NIAD]

Indeed, that MSX Basic video is very impressive and to be able to compile the program in run time is an incredible advantage... one that was never afforded to ADAM users in any version of SmartBASIC. I actually completely overlooked the fact that we are talking about the CV II, so indeed, why would we hamper things by using ADAM tools that were developed for use with the older, slower and less feature packed Processor, VDP and Sound chips. It's just something that immediately came to mind, that is taking advantage of numerous development tools that are already there.

 

You are absolutely correct about trying to make the programming experience as easy as possible and the flexibility/ease of use/ease of access to the mentioned functions as well as those seen in the video will make a huge difference for those willing to take the plunge. The old way of doing things with POKEs, PEEKs and CALLs is so inefficient, not to mention all those long DATA statements that contained the appropriate code needed to POKE into memory locations and then CALLed to execute.

 

HDTV is correct is his praise of Walters Software. They set the standard for ADAM utilities early on and then expanded into some very good productivity software as well as a very good graphic adventure game. They also patched numerous programs such as SmartBASIC to run from cartridge and actually manufactured these carts themselves. So to answer a previous question I saw somewhere, yes, the Basic boot loader can be patched to allow it to run from a cartridge or even to boot from a Slot #2 interface card as an Expansion ROM.

Edited March 20, 2013 by NIAD

[youki]

This is compiled BASIC. In an environment similar to what we are planning. Check the whole video, especially the mode 7 like part, real-time in BASIC....

 

http://www.youtube.com/watch?v=LNyfkCnyQXg

 

It is running on a TurboR , with a R800 at 7,16 Mhz and Fast Ram .I don't think it can be really compared with a Z80 even at the same frequency. Despite the fact the R800 is "more or less" compatible with the Z80... it is like compare a 8088 and a 80286 on a PC.

[JamesD]

It is running on a TurboR , with a R800 at 7,16 Mhz and Fast Ram .I don't think it can be really compared with a Z80 even at the same frequency. Despite the fact the R800 is "more or less" compatible with the Z80... it is like compare a 8088 and a 80286 on a PC.

The R800 estimates I saw were that it ran somewhere around 2.5 times the speed of a Z80 at the same clock speed. At twice the clock speed of the Colecovison you are talking about a cpu running 5 times as fast. It adds a few additional instructions but nothing like the amount of change from the 8088 to the 80286. Many of the new instructions were just the undocumented ones from the Z80 but they were made official. The speed increase is due to the 16 bit ALU and a pipelined architecture.

 

It's clear from the text scrolling on that screen on that demo that the graphics hardware is doing the heavy lifting anyway.

A look at the code on the screen shows just a bunch of COPY instructions which is just a blit from one location in video RAM to another in PowerBasic.

In SmartBasic you could create a machine code routine to duplicate the copy command and CALL it. It wouldn't be any slower than if that TurboR were running at standard speed off it's Z80.

 

FWIW, you could expand SmartBasic's keywords to get the same results if you are using a compiler. Frankly, if I were going to use BASIC for an 8 bit machine these days it would be a PCODE type interpreter and with a separate compiler. Code is a lot more compact than tokenized BASIC, the interpreter doesn't waste time parsing, there are no searches to find line numbers, the resulting programs can be larger than memory (swapping in or calling routines from a cartridge or disk is a very real possibility), it's easier to generate code for, code would be smaller than native Z80 code, for speed you can create functions in assembly you can link to, etc...

New commands can be added whenever you want, you just link to the library when you compile your program.

You can also generate PCODE from other language compilers that will run on the same PCODE interpreter.

But I see that as a developer tool and not necessarily something that has to be built into a machine.

 

 

If it were me, I'd look at implementing the machine in an FPGA.

A COLECOVISION has already been implemented in an FPGA on a development board and the AY sound chip has been duplicated.

Source is available for both.

Some of the Z80 cores can easily run at 25MHz or more on development boards which means you don't have to write everything in assembly for it to be fast and you'd have TurboR like speeds which *could* make porting code from the TurboR a possibility in the future.

Release an initial Colecovision compatible system with SGM support, then release upgrades for the FPGA to add new features in the future.

The board could be smaller since you don't need space for all the old chips, it would require less power, and there is example code for implementing HDMI out there if you really wanted to support it,

But that's me. FPGA has the risk of compatibility issues, some things aren't fully implemented in FPGAs yet, etc...

[+opcode]

It is running on a TurboR , with a R800 at 7,16 Mhz and Fast Ram .I don't think it can be really compared with a Z80 even at the same frequency. Despite the fact the R800 is "more or less" compatible with the Z80... it is like compare a 8088 and a 80286 on a PC.

 

That is just partially true.

Indeed the R800 is much faster (than a Z80 at 3.58MHz), 8 to 10 times on average actually. However that only applies for things that run on DRAM. Once the CPU moves to I/O ports, ROM or cartridge slots, then it goes below Z80 performance. And as you know the VDP is mapped to I/O. If you look around the Internet you can find performance tests showing that the R800 usually perform well below a Z80 at 7.14MHz on video intensive tasks.

 

It isn't R800's fault actually, but a problem with the Turbo-R architecture You probably know the Turbo R was a last minute patch work once it was decided that no company was going to release the MSX3. The R800 is capable of much more. Its I/O performance has nothing to do with the CPU itself, but with the S1990 system controller that adds an insane number of wait states for each I/O access. The R800 has an interrupt controller, a dual channel DMA controller and a built-in MMU. All of that is disabled in the Turbo R. Coupled with the V9990 (which was originally named V9978), the R800 is capable of some amazing things as originally planned for the MSX3, as the R800 DMA could transfer data directly to the V9990 VRAM without CPU or VDP intervention at insanely fast speeds. You can use the V9990 with the Turbo R sure, but then access is going to be through the cartridge port, which means lots of wait stats and sub MSX2+ speeds.

 

Anyways, back on topic, with the CV2 we can have direct CPU access to VRAM at twice the speed of the MSX2+, and about 3 times faster than the Turbo R. You can check benchmark results here:

 

http://www.ricbit.com/mundobizarro/advram/

 

So even if the R800 is 4 times faster than a Z80 at 7.14MHz with no wait state when running a program in RAM, for applications that are mostly video or I/O bound, the CV2 would have an advantage.

That is system design is all about, you need to reach a good balance between components. It is of no avail to have a component that perform incredible well when that component will spend a lot of time waiting for the rest of the system to catch up. The CV/MSX1 were well rounded systems in that sense. The MSX2 and up, not so much. First the CPU couldn't keep up with the VDP (MSX2), then (Turbo R) the VDP couldn't keep up with the CPU.

 

So a Z80 at 7.14MHz with no wait states and direct VRAM access should hit the sweet spot IMHO.

[tomjscott]

That is just partially true.

Indeed the R800 is much faster (than a Z80 at 3.58MHz), 8 to 10 times on average actually. However that only applies for things that run on DRAM. Once the CPU moves to I/O ports, ROM or cartridge slots, then it goes below Z80 performance. And as you know the VDP is mapped to I/O. If you look around the Internet you can find performance tests showing that the R800 usually perform well below a Z80 at 7.14MHz on video intensive tasks.

 

It isn't R800's fault actually, but a problem with the Turbo-R architecture You probably know the Turbo R was a last minute patch work once it was decided that no company was going to release the MSX3. The R800 is capable of much more. Its I/O performance has nothing to do with the CPU itself, but with the S1990 system controller that adds an insane number of wait states for each I/O access. The R800 has an interrupt controller, a dual channel DMA controller and a built-in MMU. All of that is disabled in the Turbo R. Coupled with the V9990 (which was originally named V9978), the R800 is capable of some amazing things as originally planned for the MSX3, as the R800 DMA could transfer data directly to the V9990 VRAM without CPU or VDP intervention at insanely fast speeds. You can use the V9990 with the Turbo R sure, but then access is going to be through the cartridge port, which means lots of wait stats and sub MSX2+ speeds.

 

Anyways, back on topic, with the CV2 we can have direct CPU access to VRAM at twice the speed of the MSX2+, and about 3 times faster than the Turbo R. You can check benchmark results here:

 

http://www.ricbit.co...bizarro/advram/

 

So even if the R800 is 4 times faster than a Z80 at 7.14MHz with no wait state when running a program in RAM, for applications that are mostly video or I/O bound, the CV2 would have an advantage.

That is system design is all about, you need to reach a good balance between components. It is of no avail to have a component that perform incredible well when that component will spend a lot of time waiting for the rest of the system to catch up. The CV/MSX1 were well rounded systems in that sense. The MSX2 and up, not so much. First the CPU couldn't keep up with the VDP (MSX2), then (Turbo R) the VDP couldn't keep up with the CPU.

 

So a Z80 at 7.14MHz with no wait states and direct VRAM access should hit the sweet spot IMHO.

 

That all sounds great. I would love to get a CV2 and someday be able to program some games for it.

[+opcode]

That all sounds great. I would love to get a CV2 and someday be able to program some games for it.

 

You know, that opens a lot of potential indeed. However I am always torn about the two sides of the matter. Adding something like a keyboard input and BASIC could have an appeal beyond the CV fan base circle, and while I think it is always nice to have something that brings new blood, on the other hand I am happy to focus on our core audience instead of scattering on multiple audiences.

 

And that is the same thing with FPGA. I have considered FPGAs innumerable times, but in the end I just cannot see the difference between a FPGA device and connecting your laptop to the TV and using an emulator. It doesn't bring the same sense of "reality" to me. It also detracts of the what-if paradigm, as you are no longer bound to the technological limitations of the 80s.

[tomjscott]

You know, that opens a lot of potential indeed. However I am always torn about the two sides of the matter. Adding something like a keyboard input and BASIC could have an appeal beyond the CV fan base circle, and while I think it is always nice to have something that brings new blood, on the other hand I am happy to focus on our core audience instead of scattering on multiple audiences.

 

And that is the same thing with FPGA. I have considered FPGAs innumerable times, but in the end I just cannot see the difference between a FPGA device and connecting your laptop to the TV and using an emulator. It doesn't bring the same sense of "reality" to me. It also detracts of the what-if paradigm, as you are no longer bound to the technological limitations of the 80s.

 

I wasn't necessarily thinking BASIC or a keyboard even. Maybe an emulator could be updated to support this new machine and we could program on that and then have the ROM images put on cartridges? I don't know. I'm assuming someone is going to be making games for it that way.

[+opcode]

I wasn't necessarily thinking BASIC or a keyboard even. Maybe an emulator could be updated to support this new machine and we could program on that and then have the ROM images put on cartridges? I don't know. I'm assuming someone is going to be making games for it that way.

 

Another good point. Making it programmable could open the door for many user made games that would take advantage of all the new features without placing the burden on a single individual or publisher. Something to discuss with Ricardo tonight.

[+Gemintronic]

ZX Basic has source and a lenient license:

http://www.boriel.com/wiki/en/index.php/Main_Page

 

Couldn't NewColecos devkit be enhanced with extended libraries for Coleco 2?

http://www.ccjvq.com/newcoleco/

[Pixelboy]

I have to assume that if Opcode Games was to market the CV2 in any capacity, it would do so as a gaming console, and Opcode wouldn't bother to go through the trouble of actually creating a BASIC interpreter/compiler/whatever. It really comes down to two things: Include the PS/2 connector, and code a test program that helps to make sure that the keyboard works properly at the hardware level.

 

Creating a BASIC interpreter should be left to other homebrewers, and if no one steps up to the plate to develop such a piece of software, then all the CV2 will do is play games, (which is fine by me). The point is that the PS/2 connector should be there, to at least make a BASIC interpreter (or perhaps even an ASM or C compiler) possible.

[+Gemintronic]

I have to assume that if Opcode Games was to market the CV2 in any capacity, it would do so as a gaming console, and Opcode wouldn't bother to go through the trouble of actually creating a BASIC interpreter/compiler/whatever. It really comes down to two things: Include the PS/2 connector, and code a test program that helps to make sure that the keyboard works properly at the hardware level.

 

Creating a BASIC interpreter should be left to other homebrewers, and if no one steps up to the plate to develop such a piece of software, then all the CV2 will do is play games, (which is fine by me). The point is that the PS/2 connector should be there, to at least make a BASIC interpreter (or perhaps even an ASM or C compiler) possible.

 

BASIC running ON the machine is pointless. Having an easy to use language for making games is essential. No one said anything about an interpreter or runtime engine. You can't expect a small amount of all-star assembly gurus to push new hardware alone. Get game making enthusiasts involved buying hardware and using accessible software to make games.

[tomjscott]

I have to assume that if Opcode Games was to market the CV2 in any capacity, it would do so as a gaming console, and Opcode wouldn't bother to go through the trouble of actually creating a BASIC interpreter/compiler/whatever. It really comes down to two things: Include the PS/2 connector, and code a test program that helps to make sure that the keyboard works properly at the hardware level.

 

Creating a BASIC interpreter should be left to other homebrewers, and if no one steps up to the plate to develop such a piece of software, then all the CV2 will do is play games, (which is fine by me). The point is that the PS/2 connector should be there, to at least make a BASIC interpreter (or perhaps even an ASM or C compiler) possible.

 

Maybe I'm missing something then. If it is only marketed to play games then what will it play? Existing colecovision games? If so, would they somehow be enhanced then just by virtue of the improved hardware? Is that the basic idea then?

[JamesD]

FWIW, you could expand SmartBasic's keywords to get the same results if you are using a compiler. Frankly, if I were going to use BASIC for an 8 bit machine these days it would be a PCODE type interpreter and with a separate compiler. ...

I meant to say could there, not would.

 

It is possible to mix PCODE compiler output with native Z80 compiler output btw.

[+opcode]

Maybe I'm missing something then. If it is only marketed to play games then what will it play? Existing colecovision games?

 

Yep.

 

If so, would they somehow be enhanced then just by virtue of the improved hardware?

Yep.

 

Is that the basic idea then?

 

Nope.

[+opcode]

Seriously, it would play both CV, SGM and exclusive CV2 games. But we need to be realistic and consider that there is so much that a single or small group of developers/publisher can do. So that is why I thought the idea of supplying it with some programming language would be interesting, as it would open the doors for more games, even if simpler games.

[+Gemintronic]

ZX Basic is already useable for multiple platforms. Someone even made a Sega Master System port that creates actual game binaries.

 

If that's too complicated at least go for the C library route with NewColecos devkit. As a bare minimum.

 

Once that is done something like BCX could be altered to convert BASIC to C -> Coleco 2 binary.

http://bcx-basic.sourceforge.net/

 

Why make ONE game for ONE system when you can enable MANY enthusiasts to create MANY more?

[tomjscott]

Seriously, it would play both CV, SGM and exclusive CV2 games. But we need to be realistic and consider that there is so much that a single or small group of developers/publisher can do. So that is why I thought the idea of supplying it with some programming language would be interesting, as it would open the doors for more games, even if simpler games.

 

I'd already be making Colecovision games myself if I could find some serious documentation on how the CV actually works. The best stuff I have right now is newcoleco's dev kit, but, to be honest, it is poorly documented due to French translation issues and just lack of core information. I suppose I could reverse engineer his libraries and see how the machine language code actually manages sprites and sound, but I don't have that kind of time for hobby programming. Why is there no basic core documentation on memory maps for the CV and how to program the video chip with assembly language? Or have I just completely missed where this information is at?

[+Gemintronic]

I'd already be making Colecovision games myself if I could find some serious documentation on how the CV actually works. The best stuff I have right now is newcoleco's dev kit, but, to be honest, it is poorly documented due to French translation issues and just lack of core information. I suppose I could reverse engineer his libraries and see how the machine language code actually manages sprites and sound, but I don't have that kind of time for hobby programming. Why is there no basic core documentation on memory maps for the CV and how to program the video chip with assembly language? Or have I just completely missed where this information is at?

 

Is this documentation no good?

http://www.gooddealgames.com/articles/Colecovision_Programming2.html

[JamesD]

I'd already be making Colecovision games myself if I could find some serious documentation on how the CV actually works. The best stuff I have right now is newcoleco's dev kit, but, to be honest, it is poorly documented due to French translation issues and just lack of core information. I suppose I could reverse engineer his libraries and see how the machine language code actually manages sprites and sound, but I don't have that kind of time for hobby programming. Why is there no basic core documentation on memory maps for the CV and how to program the video chip with assembly language? Or have I just completely missed where this information is at?

I thought some of that was bundled with the docs I downloaded for the Adam.

[tomjscott]

Is this documentation no good?

http://www.gooddealg...ogramming2.html

 

No, it isn't sufficient. It tells me absolutely nothing about how to program the CV in assembly language. It has some C libraries that are somewhat documented, but don't seem to do what their function names suggest or what I would expect. It gives me no information whatsoever on the core concepts of manipulating sprites, drawing bitmap graphics, or playing sounds from a pure hardware perspective and with assembly language.

[tomjscott]

I thought some of that was bundled with the docs I downloaded for the Adam.

If you have that information, I'd be grateful for getting my hands on it. I've tried finding it myself, but to no avail.

[+Gemintronic]

No, it isn't sufficient. It tells me absolutely nothing about how to program the CV in assembly language. It has some C libraries that are somewhat documented, but don't seem to do what their function names suggest or what I would expect. It gives me no information whatsoever on the core concepts of manipulating sprites, drawing bitmap graphics, or playing sounds from a pure hardware perspective and with assembly language.

 

One more try.. have you been to this site? I know its Adam centric but it seems to have some good material.

http://www.theadamresource.com/manuals/index.htm#prog