51 replies to this topic

[opcode]

Hi there,

Following Pixelboy suggestion, I am planning a PC dev kit for the ColecoVision. Here is what he suggested:

1 - Complete CV emulator with integrated debugger
2 - Beginner level programming language
3 - Graphic and sound tools

Item #1 is under development. I started it some weeks ago in order to simulate my proposed SEM, so the final emulator will include it too.

Item #2 is probably the most complicated item to accomplish in this list. I started to define a Game Basic language like 2 years ago, but then quit... I would need some help here...

Item #3 is easy, though time consuming....

Ok, so I will post my progress here. In the meantime, I would post detailed SEM info here, if someone is interested and I have the time...
BTW, here is a screenshot of a preliminary port of Aleste running on my SEM emulator... (Aleste is a Compile game released for the MSX2 and SMS)

Eduardo

Attached Thumbnails

• 

[Pixelboy]

Okay then, let's get to work on Item #2.

I browsed through the docs at the CV FAQ page (http://www.classicga....com/colecofaq/), and that's about all I've been able to do for research, so whatever I say will be based on the info from that web site.

My idea for a language suitable for a beginner would be something that's readable, yet optimized for the CV.

For example, let's say you want to change the color for the 6th group of 8 tiles in the name table. It could be done like this:

SET TILE ROW 6 TO COLOR 0 13
or
SET TILE ROW 6 TO COLOR TRANSPARENT MAGENTA

"6" is the offset number in the color table, "0" is the color used for the high nibble (first 4 bits - in this case, transparent), and "13" is the color used for the low nibble (last 4 bits - in this case, magenta). At compile/link time, this instruction would be transformed into a simple "poke" instruction in the proper location of the color table. It's also possible to do something more dynamic, like this:

LET a = 6
LET b = 0
LET c = 13
SET COLOR ROW a TO b c

The above commands do the same thing as before, but the values are stored in variables "a", "b" and "c". At compile time, the SET COLOR ROW command would be broken down into a few machine instructions to fetch the values from the variables in RAM and use them to perform the poke operation.

The above example is an introduction to my philosophy for the proposed language: Keep things at a low, almost assembly level, but always keep it readable. Beginners can understand concepts such as "name table", "pattern table" and "color table" as long as it's explained in a basic way in tutorials, and so these should simply be "usable components" within the language.

Another example:

LET j = JOYSTICK 1 STATE
LET f = BUTTON 1 STATE
LET k = KEYPAD 1 STATE

If the player is currently pushing the joystick in any direction, this direction will be stored as a number in variable "j" (if the joystick is idle, then "j" will be zero). Same goes for the BUTTON and KEYPAD commands, where any button/key currently being pressed on player 1's controller will be stored as a number in variable "f" and "k" respectively. At compile time, such commands as JOYSTICK, BUTTON and KEYPAD will become simple "peek" commands which look at the appropriate hardware addresses.

Yet another example: Let's say you want to set sprite #1 (of the 32 available sprites) at a certain location on the screen. It would be done like this:

SET SPRITE 1 AT 45 151

Other variants are possible:

SET SPRITE 1 PATTERN 245
SET SPRITE 1 COLOR 0 13
SET SPRITE 1 AT 45 151 PATTERN 245 COLOR 0 13

This puts the sprite at x=45, y=151 on the screen, sets the sprite to use pattern #245 in the sprite descriptor table, and sets the sprite color to the transparent/magenta combo. Same as before, these are translated into simple "poke" commands in the generated ROM image, and integer variables can be used instead of constants:

SET SPRITE a PATTERN b
SET SPRITE a COLOR b c
SET SPRITE a AT b c PATTERN d COLOR e f


More later, if you're still interested...

(BTW, can the CV do floating-point arithmetics, or is it limited to integer math? What about the SEM?)

[jbanes]

Pixelboy, on Thu Dec 1, 2005 3:43 PM, said:

(BTW, can the CV do floating-point arithmetics, or is it limited to integer math? What about the SEM?)

The CV used a Z80 processor, which was more or less a clone of the Intel 8080. As you may already know, Intel didn't add Floating Point support to their chips until the 486. (You could get a separate chip in earlier models, but the 486 was the first with it bundled.)

Sooo... the only option for floating point numbers is to use a software library like this one. Be aware that this is slow, painful, and ultimately pointless for video games. Your best bet is to work out a fixed point math library and use that. (There's one on the same page as the floating point implementation.) The only thing you lose over floating point is the ability to go beyond a certain number of digits. On the bright side, your math will be far more accurate. That should be more than sufficient for video games. (Hey, it worked for BASIC back in the day, so it can't be that bad.)

[opcode]

Ok, let's start.

Pixelboy, on Thu Dec 1, 2005 6:43 PM, said:

For example, let's say you want to change the color for the 6th group of 8 tiles in the name table. It could be done like this:

SET TILE ROW 6 TO COLOR 0 13
or
SET TILE ROW 6 TO COLOR TRANSPARENT MAGENTA

Problem is, how would you define a tile in Graphic 2 mode? It would require a lot of writing, becoming a tedious process. I was thinking of a higher level language.
Like, once you have created the tiles using the graphic tool, you would use the following syntax to load it:

DIM mygraph as GDATA = c:\<some path>\graph2.scr

mygraph.load(0,0) 'load graphic data to vram starting in character table 0, position 0

graph2.scr is a special file, with compressed graphic data generated by the graphic tool. It will be linked to the ROM image in compile time.

In addition you can have something like this to control the fine details:

DIM mytile as GTILE = 2,0 'mychar is tile # 0 in pattern table #2 (or 3rd third)

mytile.color=(2,0;2,0;3,0;3,2;3,2;3,0;2,0;2,0) 'define all colors for a tile

or yet

mytile.color(2)=(3,0) 'define colors for line 3 in tile

Quote

The above example is an introduction to my philosophy for the proposed language: Keep things at a low, almost assembly level, but always keep it readable. Beginners can understand concepts such as "name table", "pattern table" and "color table" as long as it's explained in a basic way in tutorials, and so these should simply be "usable components" within the language.

But in this case, wouldn't be C good enough?

Quote

Another example:

LET j = JOYSTICK 1 STATE
LET f = BUTTON 1 STATE
LET k = KEYPAD 1 STATE

If the player is currently pushing the joystick in any direction, this direction will be stored as a number in variable "j" (if the joystick is idle, then "j" will be zero). Same goes for the BUTTON and KEYPAD commands, where any button/key currently being pressed on player 1's controller will be stored as a number in variable "f" and "k" respectively. At compile time, such commands as JOYSTICK, BUTTON and KEYPAD will become simple "peek" commands which look at the appropriate hardware addresses.

The joysticks and keyboards requires a relatively long setup time before you can read them, so accessing them in real time isn't a good idea. It is better to read them just a single time inside the NMI. Then you can store the current status and the changes from previous read, so you can know if a button was just pressed or released for example.

This way you can do:

DIM myjoy as JOYSTICK = 1 'joystick player 1

if myjoy.changed.fire1 then.......

Quote

Yet another example: Let's say you want to set sprite #1 (of the 32 available sprites) at a certain location on the screen. It would be done like this:

SET SPRITE 1 AT 45 151

Other variants are possible:

SET SPRITE 1 PATTERN 245
SET SPRITE 1 COLOR 0 13
SET SPRITE 1 AT 45 151 PATTERN 245 COLOR 0 13

This puts the sprite at x=45, y=151 on the screen, sets the sprite to use pattern #245 in the sprite descriptor table, and sets the sprite color to the transparent/magenta combo. Same as before, these are translated into simple "poke" commands in the generated ROM image, and integer variables can be used instead of constants:

SET SPRITE a PATTERN b
SET SPRITE a COLOR b c
SET SPRITE a AT b c PATTERN d COLOR e f

Ok, but you would still need some macros for easier animation

I would suggest several objects here:

DIM mysprset1 as SPRITESET = (2)
DIM mysprset2 as SPRITESET = (2) .... 'define several sprite sets for animation, 2 sprites each

mysprset1.pattern=(0,1)
mysprset2.pattern=(2,3)
mysprset1.color=(6,4)
mysprset2.color=(9,4)
mysprset1.xoffset=(0,0)
mysprset2.xoffset=(0,16)
mysprset1.yoffset=(-8,8)
mysprset2.yoffset=(0,0) 'define pattern, color, x and y offset in the sprite set

Then:

DIM mychar as CHARACTER

mychar.spriteset=mysprset1
mychar.x=10
mychar.y=32

Maybe we would even create a few extra macro structures....

Quote

(BTW, can the CV do floating-point arithmetics, or is it limited to integer math? What about the SEM?)

Since both are based on the Z80 CPU, you can't do floating-point math by hardware.

Eduardo

[Pixelboy]

opcode, on Thu Dec 1, 2005 7:28 PM, said:

Problem is, how would you define a tile in Graphic 2 mode? It would require a lot of writing, becoming a tedious process. I was thinking of a higher level language. Like, once you have created the tiles using the graphic tool, you would use the following syntax to load it:

DIM mygraph as GDATA = c:\<some path>\graph2.scr

mygraph.load(0,0)    'load graphic data to vram starting in character table 0, position 0

graph2.scr is a special file, with compressed graphic data generated by the graphic tool. It will be linked to the ROM image in compile time.

Actually, I was thinking the same thing, but I didn't get the chance to elaborate. There are so many issues with your above reply that it's going to take a while for me to formulate a complete response. Just keep in mind that my explanations will probably contain several flaws because my understanding of the CV hardware is very limited. But I'm sure we can iron things out together. I just hope you can see things my way...

First of all, in my vision of the dev kit, the programmer first creates a "project" and selects the total cartridge size (16K, 32K, 64K). The project regroups such entities as pattern tables, title screen layout (with the multi-colored "COLECOVISION" label at the top of the screen), game screens (a.k.a. name table data), sound data and other types of binary data together with the central source code, and all these entities are saved in separate data files under the same project directory, and will be all linked together automatically by the compiler/linker upon ROM generation. Of course, the entities (pattern tables, sounds data, etc.) can be exported and imported in other projects later.

The dev kit would offer a graphical interface for everything that can be presented graphically. For example, imagine a window with a rectangle of 128x256 pixels, where each pixel represents one byte of a 32K ROM space. The bytes already taken by data appear as red pixels, and the free bytes are shown as green pixels. With this interface, you can see at a glance how much space you have left to work with at any time. Under this rectangle, there would be a combo-box with a list of entities defined by the programmer, and when he selects one of these entities in the list, the bytes taken by this entity in the ROM space appear as yellow pixels in the rectangle. For example, select a game screen, and the 768 contiguous bytes taken for this game screen appear in yellow in the ROM space rectangle.

Pattern tables and other entities are external to the main source code of the game, and are referenced by name. This means that your line of code:

DIM mygraph as GDATA = c:\<some path>\graph2.scr

would look more like this:

LET adr_pat_tab_1 = ADR "pattern_table_1"

where "adr_pat_tab_1" is the name of a variable, and "pattern_table_1" is the name given to one of the entities (in this case a pattern table) defined by the programmer under the current project. Of course, the instruction above is pointless unless you want to do something special with the pattern table, because under normal circumstances, all you need to load a pattern table in VRAM is a command like this one:

LOAD PATTERN TABLE "pattern_table_1"

When the compiler/linker generates the ROM file, the starting address of "pattern_table_1" is known, so the LOAD PATTERN TABLE instruction translates into a single "memcopy" operation of 2048 bytes between the ROM space and the VRAM (I'm assuming the CV hardware offers an easy way to do a memcopy like that). This perfectly illustrates the goal of the language: To allow the programmer to work in assembly, without having to write actual assembly code!

opcode, on Thu Dec 1, 2005 7:28 PM, said:

In addition you can have something like this to control the fine details:

DIM mytile as GTILE = 2,0    'mychar is tile # 0 in pattern table #2 (or 3rd third)

mytile.color=(2,0;2,0;3,0;3,2;3,2;3,0;2,0;2,0) 'define all colors for a tile

or yet

mytile.color(2)=(3,0)  'define colors for line 3 in tile

I don't think defining such color data within the source code is a good idea (it should be done at the project level via the GUI of the dev kit), but I guess the programmer can need to modify the colors during run-time... To be honest, I haven't given much thought to the differences between the graphic modes, so this will require further discussions.

However, no offense Eduardo, but using object-oriented syntax like "mytile.color()' is exactly the kind of thing I want to avoid with this dev kit. What I'm aiming for is a language that is easy to read and also directly translates into CV machine code.

opcode, on Thu Dec 1, 2005 7:28 PM, said:

Quote

The above example is an introduction to my philosophy for the proposed language: Keep things at a low, almost assembly level, but always keep it readable. Beginners can understand concepts such as "name table", "pattern table" and "color table" as long as it's explained in a basic way in tutorials, and so these should simply be "usable components" within the language.

But in this case, wouldn't be C good enough?

Allow me to tell you a story to illustrate my point of view: When I was studying at my local university in computer programming, there was a debate among teachers as to what language should be taught to first-year students. They discussed Pascal, ADA, some other languages, but one thing was unanimously agreed upon by all the teachers: C/C++ was NOT an acceptable option. Why? Because the syntax is too rough for beginners, and the compilers are generally too permissive. Building compiler/linker safeguards into something as loose as C syntax is downright impossible, and it is far more easy to do so in a language like the one I'm proposing. I want this dev kit to be something else than a glorified C compiler.

opcode, on Thu Dec 1, 2005 7:28 PM, said:

The joysticks and keyboards requires a relatively long setup time before you can read them, so accessing them in real time isn't a good idea. It is better to read them just a single time inside the NMI. Then you can store the current status and the changes from previous read, so you can know if a button was just pressed or released for example.

This way you can do:

DIM myjoy as JOYSTICK = 1    'joystick player 1

if myjoy.changed.fire1 then.......

I'm not sure I understand your explanation (mostly because I don't know what the NMI is) but I'm sure we can adjust the language to deal with this delay problem. And again, I must say I don't like using the C++ syntax...

opcode, on Thu Dec 1, 2005 7:28 PM, said:

Quote

Yet another example: Let's say you want to set sprite #1 (of the 32 available sprites) at a certain location on the screen. It would be done like this:

SET SPRITE 1 AT 45 151

Other variants are possible:

SET SPRITE 1 PATTERN 245
SET SPRITE 1 COLOR 0 13
SET SPRITE 1 AT 45 151 PATTERN 245 COLOR 0 13

This puts the sprite at x=45, y=151 on the screen, sets the sprite to use pattern #245 in the sprite descriptor table, and sets the sprite color to the transparent/magenta combo. Same as before, these are translated into simple "poke" commands in the generated ROM image, and integer variables can be used instead of constants:

SET SPRITE a PATTERN b
SET SPRITE a COLOR b c
SET SPRITE a AT b c PATTERN d COLOR e f

Ok, but you would still need some macros for easier animation

It's funny you should mention that, because this raises the main issue which prevents me from forming a complete picture of the dev kit's language in my mind: How does a programmer set the overall speed and timing of objects within a game? And how does sound output fit into all this? This is an issue which remains a complete mystery to me, because all the programs I've written in my life were designed to perform jobs as quickly as possible, and I never had to calibrate a running program to a specific speed of execution, to make it normally playable. I've heard about the "vsync technique", but that's for PCs, right? If I could get a real handle on that concept, it would help me tremendously...

opcode, on Thu Dec 1, 2005 7:28 PM, said:

I would suggest several objects here:

DIM mysprset1 as SPRITESET = (2)
DIM mysprset2 as SPRITESET = (2) .... 'define several sprite sets for animation, 2 sprites each

mysprset1.pattern=(0,1)
mysprset2.pattern=(2,3)
mysprset1.color=(6,4)
mysprset2.color=(9,4)
mysprset1.xoffset=(0,0)
mysprset2.xoffset=(0,16)
mysprset1.yoffset=(-8,
mysprset2.yoffset=(0,0)  'define pattern, color, x and y offset in the sprite set

Then:

DIM mychar as CHARACTER

mychar.spriteset=mysprset1
mychar.x=10
mychar.y=32

Maybe we would even create a few extra macro structures....

Hmm... So you want to put an extra layer of abstraction between the programmer and the actual hardware sprites... Considering we only have 1K of RAM to work with, do you think it's really a good idea to create extra data structures like that? Not that's it's really a bad idea or anything, I'm just concerned.

opcode, on Thu Dec 1, 2005 7:28 PM, said:

Quote

(BTW, can the CV do floating-point arithmetics, or is it limited to integer math? What about the SEM?)

Since both are based on the Z80 CPU, you can't do floating-point math by hardware.

That's okay, we can live without it for now, I guess. I assume that standard integer values are coded on two bytes, and that they can be signed or unsigned?

[Pixelboy]

BTW, I made a little mistake in my first post in this thread. This example line:

SET COLOR ROW a TO b c

should instead be:

SET TILE ROW a TO COLOR b c

Sorry if it caused you any confusion.

[opcode]

Hi Pixelboy,

Now this discussing is getting interesting…

Ok, let me try to do the same as you and expose my point-of-view…
Let’s take a practical example, a vertical shooting game like Xevious.

Usually any game can be done in the CV using the assembly structure bellow, but first let me explain what keeps games in sync:
The Z80 has a normal execution path, which starts in address 0000h when the CPU is reset. However, there are some alternative paths, which are toggled by interruptions. In the CV specific case, the video processor generates an interruption always it completes a frame, or every 1/60s. That is what keeps game in sync. But where the CPU goes once it receives an interrupt? It goes to address 0066h, because the VDP generates a non-maskable interruption, or NMI, a kind of interruption which can’t be turned-off by the CPU.
Ok, so going back to the game structure, the programmer is usually free to choose if he/she wants to do things inside the “normal” program area or in the NMI program area or both. From my experience, it’s easier to do everything inside the NMI area, mainly because you can’t share the VDP between accesses from both program “areas”, i.e. if you are in the middle of a VDP access in the main program and then the CPU receives an interruption, it will jump to the NMI area. But then, if the NMI area executes some tasks involving the VDP, once the NMI program completes and control goes back to the main program area, all your previous VDP states, like address pointers, etc, would be gone. There isn’t a way to save it.
So a typical structure would be:

Main program area:

Init VDP
Clear VRAM memory
Clear main memory
Set stack
Init sound
Do nothing (stay in an infinite loop, waiting for an interruption)

NMI area:

Save registers
Do some interruption checks here
Play sounds/music
Check if the previous interruption was completed
If previous interruption was incomplete (i.e. we interrupted an interruption), then exit
Read controls
Control Game
Set flag telling that this interruption has completed
Restore registers
Exit

Absolutely any CV can use this basic structure, no exceptions, no matter how complex or how simple, so it will be our starting block.
My point is, why to give the programmer freedom to micromanage things differently that could not work after all? Or, taking into account that the above solution always work, why not hide this level of detail from the programmer? We are aiming for a beginner language after all, right?
So my idea is, by just starting a new project the programmer already gets the above structure, no need to code a single line.

Let’s check sound now:

Usually you just need two sounds routines, one for actually play sounds and another to set the sound you want. This set of routines is the sound driver and, well, I don’t see a good reason to oblige the programmer to create it. Instead, the programmer should concentrate on creating the tunes or sound FXs, and then bound everything with:

DIM soundlist (10) AS SOUND    
'this game has 10 different sounds, soundlist is a SOUNDSET, a array of SOUNDs
soundlist(0).source = sound1.snd
soundlist(1).source = fx2.snd	
'source is a property of SOUND, defines the sound data source
….
soundlist(9).source = maintune.snd

Now just play a sound when you want:

soundlist(3).play       
'will play sound or music #3. “play” is an action of SOUND
'another action could be “mute”, which stop all sounds. One should use it with a SOUNDSET, like this: 
soundlist.mute

That is all that you would be required to do in order to add music and sound to your game, nothing more. My point is: if we make it too low level, the programmer would need to create the whole sound driver, which is a difficult and tedious job.
Also, it is a good example of why an object oriented language would work great for games. With games, object orientation is more than some abstract concept, it really works! I mean, all game components are objects, so it’s natural: the main character, an enemy, an enemy shot, a screen, a tune. Every object has properties, has defined actions (or methods) and can respond to events. The whole game is a state machine, so it is easier to define things based on object declaration than tedious low level coding. Another advantage is that probably the final engine will be more efficient, because it uses pre-defined, assembly coded modules. It’s like a plug&play language…
Furthermore, a lot of people are used to VB, which is standard with all MSOffice apps.

Ok, I need to go now. I will continue this practical example later, once I have the chance to comment your last message…

Eduardo

[Tempest]

opcode, on Thu Dec 1, 2005 2:39 PM, said:

BTW, here is a screenshot of a preliminary port of Aleste running on my SEM emulator... (Aleste is a Compile game released for the MSX2 and SMS)

That's Power Strike for those of us in the US.

Tempest

[opcode]

Tempest, on Fri Dec 2, 2005 2:08 PM, said:

opcode, on Thu Dec 1, 2005 2:39 PM, said:

BTW, here is a screenshot of a preliminary port of Aleste running on my SEM emulator... (Aleste is a Compile game released for the MSX2 and SMS)

That's Power Strike for those of us in the US.

Tempest

Oh yeah, right, Power Strike... I had forgot... Ok, thanks for the info!
So, Power Strike is using the new Graphic 4 mode, which is similar to the SMS and MSX2 native modes. I can have twice as much sprite area in the same scanline as the SMS though. Graphic 5 is even more powerful, probably PC-Engine quality. I just will know what the video blitter can really do once it's fully implemented...

Eduardo

[Pixelboy]

opcode, on Fri Dec 2, 2005 1:03 PM, said:

Also, it is a good example of why an object oriented language would work great for games. With games, object orientation is more than some abstract concept, it really works! I mean, all game components are objects, so it’s natural: the main character, an enemy, an enemy shot, a screen, a tune. Every object has properties, has defined actions (or methods) and can respond to events. The whole game is a state machine, so it is easier to define things based on object declaration than tedious low level coding. Another advantage is that probably the final engine will be more efficient, because it uses pre-defined, assembly coded modules. It’s like a plug&play language… Furthermore, a lot of people are used to VB, which is standard with all MSOffice apps.

Ok, I need to go now. I will continue this practical example later, once I have the chance to comment your last message…

As you said, this discussion is indeed getting interesting. I'm not sure I understand everything in your explainations (the NMI thing is more complicated than I expected), but I think I understand most of it in general, so I'm hopeful I'll be able to help you with the dev kit language.

Speaking of which, I've been thinking, and I agree that using an object-oriented approach does have its advantages. If you really want to go the object-oriented way, I really have no right to stand in your way, since this is YOUR project after all, and I still have a bunch of stuff to learn about the internal workings of the CV anyway.

It should be noted however that it's far more difficult to write a parser for a C++/Java type language, but I'm willing to give it a shot if you'll let me. Also, optimizing the generated machine code from the programmer's OO source code might prove more difficult than you might expect. We do have very limited RAM and ROM space to work with, and a programmer might get carried away and make a game that's too big for the CV to handle, especially if he makes his game for a plain CV, and not the SEM. Even if we go with an OO language, we should still offer a graphic tool to let the programmer monitor the available ROM space, so that the generated machine code will fit inside this ROM space together with the graphic and sound data. Beyond those basic issues, there's always something that the programmer wants to do, something really low-level, that the OO language will not allow. We should at least offer certain features within the language that will allow experts (like you) to pull off programming "stunts" when needed.

Also, this leads me to ask a couple more questions, so I'll just regroup all my questions below (including those I've already asked but haven't gotten an answer yet) for your convenience.

1) Are integers stored on two bytes, and can they be signed or unsigned?

2) Does the 40x24 text mode use a hard-wired font, or does it use a modifiable pattern table?

3) If I'm not mistaken, the standard CV title screen is part of the BIOS. Does this imply that the font used for the game name and copyright strings in the bottom half of the screen (below the "COLECOVISION" multi-colored display) use a hard-wired font which we don't normally have access to?

4) How does the main stack work in the CV for regular push/pop operations? Do we need to reserve some space in the RAM for it, or is it a sort of secondary RAM in the hardware?

5) Does the CPU read machine code directly from the ROM space, or does it need to be loaded into RAM first before it can be executed?

6) The docs I've read indicate that the ROM space between 8000H and FFFFh is "broken into 4 sections, each enabled separately". What does this mean for our compiler/linker, in terms of constraints?

That's all for now... I think...

[opcode]

Hi Pixelboy,

Ok, quick question before I answer your list of questions:

Have you any experience with compilers? It would help a lot...

Eduardo

[opcode]

Hi Pixelboy,

Pixelboy, on Fri Dec 2, 2005 2:54 PM, said:

1) Are integers stored on two bytes, and can they be signed or unsigned?

2) Does the 40x24 text mode use a hard-wired font, or does it use a modifiable pattern table?

3) If I'm not mistaken, the standard CV title screen is part of the BIOS. Does this imply that the font used for the game name and copyright strings in the bottom half of the screen (below the "COLECOVISION" multi-colored display) use a hard-wired font which we don't normally have access to?

4) How does the main stack work in the CV for regular push/pop operations? Do we need to reserve some space in the RAM for it, or is it a sort of secondary RAM in the hardware?

5) Does the CPU read machine code directly from the ROM space, or does it need to be loaded into RAM first before it can be executed?

6) The docs I've read indicate that the ROM space between 8000H and FFFFh is "broken into 4 sections, each enabled separately". What does this mean for our compiler/linker, in terms of constraints?

Ok, let me start from here:

1) The Z80 can do math with bytes and words (2 bytes), but basically just additions and subtractions. Signal is just the MSB.

2) 40x24 text (Text 1) will read the font from the VRAM. Font use 8x8 tiles, but the lower 2 bits of each byte isn’t displayed (resulting in a 6x8 visible tile).

3) No, that font is also included in the BIOS and loaded to the VRAM during boot.

4) Yeah, you need to reserve some RAM space to the stack, like 200 bytes, maybe less.

5) Directly from the ROM.

6) Means nothing. This bank selection is handled by the CV hardware.

Back in a few moments...

Eduardo

[opcode]

Hmm, I just found it.... http://martinm.net/speedbasic.html

It is a Basic compiler with integrated IDE, and open source. We could base our Basic on it...

Eduardo

[Pixelboy]

opcode, on Fri Dec 2, 2005 2:06 PM, said:

Hi Pixelboy,

Ok, quick question before I answer your list of questions:

Have you any experience with compilers? It would help a lot... 

Eduardo

Actually, I've never written one myself to this day, but I know the general theory behind them, especially when it comes to parsing source code, so I'm confident I can get at least some of the work done.

On the other hand, turning the parsed source code into machine code will be your job, which means we'll have to devise the available keywords, attributes and methods of the language, and then establish how this code will be translated into functional (and optimized) machine code. From there, I can come up with a virtual structure for the parsed source which you can then easely traverse and process while you're generating the CV machine code of the ROM.

How does that sound?

[opcode]

Pixelboy, on Fri Dec 2, 2005 2:54 PM, said:

As you said, this discussion is indeed getting interesting.    I'm not sure I understand everything in your explainations (the NMI thing is more complicated than I expected), but I think I understand most of it in general, so I'm hopeful I'll be able to help you with the dev kit language.

Perfect!

Quote

Speaking of which, I've been thinking, and I agree that using an object-oriented approach does have its advantages. If you really want to go the object-oriented way, I really have no right to stand in your way, since this is YOUR project after all, and I still have a bunch of stuff to learn about the internal workings of the CV anyway.

Hey, don't try to leave the ship now!

Quote

It should be noted however that it's far more difficult to write a parser for a C++/Java type language, but I'm willing to give it a shot if you'll let me.

Good! No pain no gain...

Quote

Also, optimizing the generated machine code from the programmer's OO source code might prove more difficult than you might expect. We do have very limited RAM and ROM space to work with, and a programmer might get carried away and make a game that's too big for the CV to handle, especially if he makes his game for a plain CV, and not the SEM.

I believe that if we manage to create a basic game engine and make it transparent to the programmer, then we could save a lot of ROM/RAM, because it would leave less space to the programmer to do stupid things (no offence guys!). In other hand we need to be careful to not make the engine too rigid. It must be flexible enough to allow the creation of any kind of game...
For example, the sound engine that I described in my previous post use like just 30 bytes of RAM memory. ROM space will depend on the kind of sound created by the programmer.
Damn, the Atari guys are doing a lot of cool stuff with Batari Basic and they have just 3KB of ROM and a few bytes of RAM!

Quote

Even if we go with an OO language, we should still offer a graphic tool to let the programmer monitor the available ROM space, so that the generated machine code will fit inside this ROM space together with the graphic and sound data.

Ok, but probably the IDE is going to need to compile the game first, before being able to give such information.

Quote

Beyond those basic issues, there's always something that the programmer wants to do, something really low-level, that the OO language will not allow. We should at least offer certain features within the language that will allow experts (like you) to pull off programming "stunts" when needed.

I would say that the programmer can do anything as long as he doesn't interfere with the basic engine (you could call it the Master Control Program ). But then we could give him the choice to disable some of the built-in modules, like the sound driver and then create his own module...

Eduardo

[opcode]

Pixelboy, on Fri Dec 2, 2005 3:42 PM, said:

On the other hand, turning the parsed source code into machine code will be your job, which means we'll have to devise the available keywords, attributes and methods of the language, and then establish how this code will be translated into functional (and optimized) machine code. From there, I can come up with a virtual structure for the parsed source which you can then easely traverse and process while you're generating the CV machine code of the ROM.

How does that sound? 

I can't think of a better deal!
When do we start?!

Eduardo

[Pixelboy]

opcode, on Fri Dec 2, 2005 2:28 PM, said:

Hmm, I just found it.... http://martinm.net/speedbasic.html

It is a Basic compiler with integrated IDE, and open source. We could base our Basic on it...

It's very interesting, although I have to wonder exactly how far we can go with it. I mean, it basically takes Basic and translates in into C++. Would our "version" of it take our brand of Basic and produce CV assembly code, which would then be handled by a regular Z80A assembly compiler?

[Pixelboy]

opcode, on Fri Dec 2, 2005 2:59 PM, said:

I can't think of a better deal!
When do we start?!

Give me a couple of days, and I'll show you something that I think you'll love.

In the mean time, don't you have Pac-Man Collection to finish? I wouldn't want you to put your active CV projects aside, especially considering how a lot of people are waiting for those cool ports you're working on...

[opcode]

Pixelboy, on Fri Dec 2, 2005 4:07 PM, said:

opcode, on Fri Dec 2, 2005 2:59 PM, said:

I can't think of a better deal!
When do we start?!

Give me a couple of days, and I'll show you something that I think you'll love.

Sure, but I should warn you that I am 100% heterosexual, ok?...
Just kidding. Can't wait...
I mean... the first line was a joke... but I am serious about being heterosexual...

Eduardo

[Tom]

Pixelboy, on Fri Dec 2, 2005 2:00 PM, said:

Would our "version" of it take our brand of Basic and produce CV assembly code, which would then be handled by a regular Z80A assembly compiler?

Would be a good idea. There are several very good open source Z80 assemblers available, so why bother with rolling your own machine code generation backend.

[yuppicide]

I have no clue about helping you guys, but I wanted to drop by and say good luck and I hope to see this come out in the near future.

[Cybergoth]

Hi there!

How about having something like a Flash/RAM cart round up the kit?

Greetings,
Manueö

[Pixelboy]

yuppicide, on Fri Dec 2, 2005 8:04 PM, said:

I have no clue about helping you guys, but I wanted to drop by and say good luck and I hope to see this come out in the near future.

Thanks, but I think the words "near future" will not apply to this project. For one thing, what I'd like to do is use the month of December for performing analysis, because the last thing we want to do is rush head-first into this kind of project.

For one thing, I'd like to take time to study SpeedBasic and see if it's worth using. The thing looks nice and polished on the outside, but if it's a piece of coding crap under the hood, we might want to look elsewhere. Just because it's open source, doesn't mean it's coded in a clear and readable way. So I'm reserving judgement for now.

Also, I want to further my general understanding of the ColecoVision hardware by discussing certain issues with Eduardo before we get into coding. For example, we need to clarify stuff about the graphic modes (including modes 4 and 5 of the SEM) and discuss how this affects our Basic-style programming language.

I would also like to discuss certain gaming scenarios and solution implementations. For example, let's say the programmer would like to do a Street Fighter-type fighting game with our IDE. How would the programmer code his game to record joystick sequences (down+down/foward+forward+fire button = hadoken fireball)? That's just one little example.

And then there's the whole analysis of what the IDE will offer in terms of tools. We may decide to try to find a third person who has experience with GUI interfaces, so that this third person can work on such things as a tile editor (similar to the one in NESticle), a game screen editor, and more importantly, a music and sound effects editor.

I think there's more than enough stuff to discuss between now and January 2006. Besides, I've got Christmas-related stuff to take care of this month, and we're also getting into the usual December rush at my company, so needless to say I'll be busy enough as it is.

[opcode]

Pixelboy, on Sat Dec 3, 2005 8:38 AM, said:

I think there's more than enough stuff to discuss between now and January 2006. Besides, I've got Christmas-related stuff to take care of this month, and we're also getting into the usual December rush at my company, so needless to say I'll be busy enough as it is.

By then I hope to have the first version of the SEM emulator already available...


Eduardo

[Pixelboy]

So, opcode, did you get my e-mail?