FlyGuy II

[Tursi]

Yup, I found that tracker last night and messed around with it a little. Very clunky and hard to use IMHO. I don't know what he used to write that with, but a language that would have allowed him an easier and more standard interface would have been a better choice, again IMHO. Either way, it is better than nothing and lets me mess with the sounds quickly and with reasonable feedback. A few of the sounds are pretty nice, however the best sounding one seems to use a frequency setting of 1/2 of the real Master System, so those sounds would not be possible on the real gear (lower frequency for better sounding bass tones.) I wonder if the SMS uses the same frequency as the 99/4A?

 

Yes, it does. So does the Colecovision and (though the chip is a little more advanced) the MSX.

 

It's actually pretty standard for trackers to use their own GUIs, I guess you never messed around with MOD files. Doesn't make it any easier to get the hang of, but the point of the interface isn't loading and saving files, but composing music. To that end it functions like most traditional trackers. I'd say it's substantially better than nothing.

 

The ability to import VGM and export in the somewhat size-reduced EPSGMOD format is actually a benefit if you want to use tracks from other systems - there are thousands of VGM files recorded from almost every game released on SMS (and Genesis, but you won't get much out of those files). The downside is VGM is fairly wasteful of space, since it records every change sent to the sound chip (meaning, for instance, a bell sound has every volume change recorded, while the native format would only need a single note). The MOD and MIDI imports are also disappointing, the resulting files are nearly useless most of the time. I had planned to write my own converter for them at some point as I have some files I need to convert, and I want very simple changes (like storing drums only on the noise channel, not whatever happens to fall there... ). Again, dunno when or if that will happen.

 

The music composition itself is quite good, though, offering a lot of variety in the sounds produced. It has full control over the noise channel, better-than-ADSR keying on the waveforms, and vibrato and modulo for free. Most importantly, a working tracker is not a simple thing to build, plus it apparently supports MIDI input, suggesting that you can compose your tunes with a MIDI keyboard.

[The Codex]

Thanks for the tracker stuff, Tursi. Looks pretty standard for a tracker, if there is such a thing. Evokes the hardcore "tune programming" interface of apps like OctaMED and Goattracker. Shame its seems to be in development limbo, but it looks featured enough for my needs at the moment. Now if I can find somewhere to download musical talent...

[matthew180]

Actually, Matthew, if you just support segments (using the TI naming scheme or something else), that's really what they are for. The idea of segments is just that each segment has its own address counter, and you switch between segments freely in your code. Then when you assemble or link, that's when you tell the computer what address to base each segment at. This makes it easy to write code that works both in RAM and on cart, you just change the data segment and program segment addresses around.

 

Oh, so that's what the E/A manual was *trying* to say... I hate it when things are technical for the sake of being technical. Well, that sounds easy enough if that's all there is to it. However, why are there different segment types if all that is being controlled is an address? Or it is because you can only have 1 segment of each type?

 

Matthew

[matthew180]

Thanks for the tracker stuff, Tursi. Looks pretty standard for a tracker, if there is such a thing. Evokes the hardcore "tune programming" interface of apps like OctaMED and Goattracker. Shame its seems to be in development limbo, but it looks featured enough for my needs at the moment. Now if I can find somewhere to download musical talent...

 

Ah yes, OctaMED. I remember that (I have an Amiga back in the day.) :-) Tursi, it is not that I have never really seen a tracker, but I always glazed over looking at them. They are definitely some of the most intimidating software IMHO. I'm not convinced a tracker is the best way to compose music for a PSG either, I think someone did it that way once and everyone just followed suit. However, I have not tried to solve that problem either, so I can't speak on it with anything but the opinion of a user.

 

Matthew

[Opry99er]

Matthew--- I have 2 pieces of music written for you--- I'll send them to you tomorrow... I've got them in mp3 right now--- I'm Playing tonight here in Florida.... One kinda creepy, one quite triumphant... When you listen, tell me if you want some changes made, I can modify before I put 'em into call sounds... No Sound FX done, but 2 pieces of music.

[Tursi]

Trackers are not so intimidating once you get used to them... a bit like programming. I never had any talent but I used to fix up broken MODs back in the day with new instruments, even added a note here and there.

 

The segment stuff - I admit I've never read the E/A manual section on them... this is just taken from all the other systems I've worked with. (My bank switched work on other systems would never have happened without the ability to define custom segments, actually).

 

The idea with different segment types is to solve exactly the problem we're talking about here - where program needs to go in one place, and data in another. You can do something like this:

 

 DSEG
score   BSS 2
score2  BSS 2
high    BSS 2
level   BSS 2

PSEG
start
LIMI 0
... etc code here

 

Then when you link it, you tell the linker that the DSEG goes at >8300, or >2000, or whereever your RAM is, and the PSEG goes at >A000, or >6000, or whereever you want the code.

 

In a new assembler, custom segments would be preferable to the ones TI defined (maybe keeping with the more common default of the 'text' segment being program, 'data' being initialized data, and 'bss' being uninitialized data, with the ability to add your own, something like "SEGMENT text" as the directive).

 

Then for things like our multi-bank cartridges, you could have segments named BANK1, BANK2, BANK3, etc. You set them all to the same address in memory (>6000), and then all your labels and such line up, but the linker can still figure out where to put each block of code.

 

When building to RAM, usually the segments all just get packed together, the main advantage there is that the linker works out exactly where everything needs to go, rather than needing to define the blocks.

[The Codex]

I find trackers pretty intimidating as well and have generally used tools like Deluxe Music on the Amiga or Melody Assistant on the PC. But I've got friends who are retro musicians and who swear by trackers, so whatever works is my credo. I'd love something like Deluxe Music on the TI. Which, now that I think about it, is probably something I could write. Does anyone know if there already is a "graphical sheet music composition" style program on the TI already? Would hate to reinvent the wheel, especially if mine turned out an inferior version thereof.

Edited March 19, 2010 by The Codex

[matthew180]

Matthew--- I have 2 pieces of music written for you--- I'll send them to you tomorrow... I've got them in mp3 right now--- I'm Playing tonight here in Florida.... One kinda creepy, one quite triumphant... When you listen, tell me if you want some changes made, I can modify before I put 'em into call sounds... No Sound FX done, but 2 pieces of music.

 

Sweet, I can't wait to check them out! Don't worry about any effects, I'll get those done.

 

Matthew

[matthew180]

Then when you link it, you tell the linker that the DSEG goes at >8300, or >2000, or where ever your RAM is, and the PSEG goes at >A000, or >6000, or where ever you want the code.

 

So how exactly to you indicate to the linker where you want the segments? Seems a bit cumbersome. Wouldn't it be easier to have the segment address as part of the statement?

      DSEG >8320
SCORE  BSS  2       * Uninitialized data, 2 bytes
TIMER  DATA 0       * Initialized data, this probably can't be done in a ROM-based program
.
.
.

 

Also, thinking about it now, for a cartridge you would not be able to have initialized data outside of the ROM address space. How would the assembler know what to produce without knowledge of what was RAM and what was ROM? Probably should start a different thread for this...

 

Matthew

[matthew180]

Does anyone know if there already is a "graphical sheet music composition" style program on the TI already? Would hate to reinvent the wheel, especially if mine turned out an inferior version thereof.

 

I'm pretty sure the TI has a music maker cartridge, but I would not count that as any way to produce, well, anything; and you certainly can't get sound chip data as an output. I'd dare say that anything you come up with for the TI would be better than what exists.

 

Matthew

[The Codex]

I'm pretty sure the TI has a music maker cartridge, but I would not count that as any way to produce, well, anything; and you certainly can't get sound chip data as an output. I'd dare say that anything you come up with for the TI would be better than what exists.

 

Thanks, I'll start looking into as a new project then. Might even try out assembler on it later, as I'm sure that would make it far more responsive than XB. But I think the first pass will be XB while I'm tinkering with ASM. The posts here continue to be very useful and educational, and I am learning a lot from you, Tursi, Adam and Karsten.

[GroovyBee]

Also, thinking about it now, for a cartridge you would not be able to have initialized data outside of the ROM address space. How would the assembler know what to produce without knowledge of what was RAM and what was ROM? Probably should start a different thread for this...

The assembler doesn't know. Normally the first code executed in the cart will do some initialisation for you :-

 

- Zero the BSS segment in RAM (This contains variables initialised to zero)

- Copy the DATA segment from ROM to RAM (This segment contains nonzero data).

- Hand control over to your main loop.

 

This means that both the BSS and DATA segments must be contiguous and not interleaved with each other's data otherwise simple memory fills and copies won't work.

 

The linker does all the work for you so you could litter your assembly language files with :-

 

BSS

... Some zero initialised data

CODE/TExT

... Some code

DATA

... Some initialised data

BSS

... More zero initialised data

CODE/TEXT

... More code

 

The linker will then work out all the space needed to hold the BSS segment, the DATA segment and fix up the CODE/TEXT section to point to the right things.

 

The DATA segment in this instance is variables that will be updated by your program and changed during the course of normal execution e.g. Incremented, decremented etc. If you have data that is constant it just stays in the ROM.

 

The linker will normally be passed a file that describes the memory layout of the machine so it can work out where to put things.

[Tursi]

So how exactly to you indicate to the linker where you want the segments? Seems a bit cumbersome. Wouldn't it be easier to have the segment address as part of the statement?

      DSEG >8320
SCORE  BSS  2       * Uninitialized data, 2 bytes
TIMER  DATA 0       * Initialized data, this probably can't be done in a ROM-based program
.
.
.

 

Also, thinking about it now, for a cartridge you would not be able to have initialized data outside of the ROM address space. How would the assembler know what to produce without knowledge of what was RAM and what was ROM? Probably should start a different thread for this...

 

How you would specify would depend on the linker but the whole point of segments is that the code doesn't worry about where it goes. It's like having multiple RORG bases. (Otherwise, you would just use AORG anyway).

 

It may seem cumbersome after working solely with a single address, but it solves problems nicely when your needs get more complicated, like with overlays.

 

Usually initialized data is handled by a piece of startup code that copies the values into the right place - I've seen that used more in C than anywhere else. But it was just an example.

 

I don't plan on going into much further detail.. I know I've hijacked a lot of people's threads, sorry about that!

[sometimes99er]

Hehe, OctaMED and Deluxe Music. Programming the Amiga in C using the graphics.library was amazingly close to doing some of that stuff (on that level) in todays Java and ActionScript. And the only thing that really was any close to the 68000 (in my world) was then 9900. Though I’m tempted at going back to the Z80A. I might have to compare the 6502/6510 with the Z80A. As I remember it the Z80A felt superior, but I guess they were related.

 

I'm not convinced a tracker is the best way to compose music for a PSG either,

I did compose more staccato or childish tunes on trackers. Composing in a music sheet style layout is not going to be that much easier. When you have tried to play around with a real piano keyboard/synthesizer it’s much easier to compose there. If you already master another real instrument, then that’s probably a way to go.

 

[matthew180]

Well, I have not mastered anything except mash a bunch of keys and adjust a lot of settings, and hope for something that sounds good. :-)

 

The problem I find with most music programs is, well, they expect you to already know something about music. Actually, they expect you to know the lingo, be able to read music notation or know what the scales are, etc. I have an idea, but not enough to apply it. However, I can create something that sounds decent through much work and some trial and error. I have simply never found any software on music creation for a non-musician. That might sound odd, but it is perfectly legit. I'm not an artist, but I can do mechanical and structural drawings, and I can even copy something pretty well. I approach music the same way. I'm good a programming drum machines, and I can make cool sounds my messing with a synth, but a tracker... ugh.

 

Matthew

Edited March 20, 2010 by matthew180

[Willsy]

Well, Asm994a won't do it. I pukes all over itself when you use an AORG other than >6000 and ask it to make a cartridge binary. It makes the correct references though. However, it seems that Asm994a requires a BSS to be on an even boundary, and pucks on itself when you have odd BSS counts in succession. This does not assemble with it:

 

      AORG >8320
SCORE  BSS  2
LIVES  BSS  1
PILLS  BSS  1
LEVEL  BSS  1

 

Matthew

 

You need DORG, not AORG. And use BYTE instead of BSS:

 

      DORG >8320
SCORE  BSS  2
LIVES  BYTE 0
PILLS  BYTE 0  
LEVEL  BYTE 0

 

Don't worry about the zero's - they're dummies. You will need run-time code to initialise your in-ram variables to 0. You're in ROM remember

 

So:

 

AORG >6000
...
... lots of assembly code
...

DORG >8300
... reserve space for variables

 

[The Codex]

I have simply never found any software on music creation for a non-musician. That might sound odd, but it is perfectly legit. I'm not an artist, but I can do mechanical and structural drawings, and I can even copy something pretty well. I approach music the same way. I'm good a programming drum machines, and I can make cool sounds my messing with a synth, but a tracker... ugh.

 

For me a tracker is the closest thing to tune programming I've seen. Not that it makes it any more intuitive to use, though.

 

The best music software for folks who aren't music types I've found are the Acid Music/Fruity Loops type programs. They give you the ability to arrange and combine in very friendly fashion, and can be powered up to do more depending on your own talents. Check out a demo version of one of those products if you haven't yet.

 

My notation program is likely to be a bit heavy on the music terminology, and will require a passing ability to read scales, so it alone is not going to fill the TI niche for good music softs. Good that there are other efforts underway.

[matthew180]

You need DORG, not AORG. And use BYTE instead of BSS:

 

      DORG >8320
SCORE  BSS  2
LIVES  BYTE 0
PILLS  BYTE 0  
LEVEL  BYTE 0

 

Don't worry about the zero's - they're dummies. You will need run-time code to initialise your in-ram variables to 0. You're in ROM remember

 

So that's what a dummy origin is for!! I sure wish I could get a good description of each of the assembler directives with some real examples of how we might use them. I'm going to start a new thread so I can get my assembler under way.

 

Matthew

[+retroclouds]

Any news on Flyguy II ? Can hardly wait playing the finished version

[The Codex]

Secondeded.

[matthew180]

And I can't wait to get it finished! :-) Lately it seems when the wind blows, I change projects. I'm still waiting for either Owen or my wife to come up with some game-play music, and I still have to work out how I'm going to do levels. I think there needs to be a little more to the game to make it something you can play for more than 5 minutes.

 

Just so I don't forget, some things I'm planning on adding:

 

* a pill counter for each level so you can see how many you grabbed and how many are left

* an extra FlyGuy if you manage to get all 10 pills on a level, since it is actually hard to do

* being able to grab captured FlyGuys

* some sort of increasing difficulty levels

* something with the timer (currently it is added to your score)

 

Matthew

[The Codex]

Good ideas, those. At this point I think you're safe calling the game Fly Guy Deluxe or some such, akin to what they did with Space Invaders, Asteroids, etc. Only in this case, your game will be better than the original.

[matthew180]

Well, I recently have somewhat of a motivation to finish this game. I'd like to solicit any ideas for levels, difficulty, additional level widgets, the timer, power ups, etc. Basically what kind of criteria would qualify the game as cartridge worthy?

 

Should I carefully construct something like 30 levels, or come up with a scheme to generate a level based on criteria such that it would "generally" be of a certain difficulty? The random levels might give better repeat playability, but would probably not be as good as hand crafted levels. Then again, hand crafted levels are a pain in the ass. :-)

 

I was also entertaining the idea of giving FlyGuy the ability to, well, fly... Kind of like a hyperspace button, if you hit the fire button FlyGuy flies to a new random location. However, while he is in the air he could be caught by a spider. I think that is like in Asteroids where using hyperspace means you might blow up.

 

Matthew

[+retroclouds]

Well, I recently have somewhat of a motivation to finish this game. I'd like to solicit any ideas for levels, difficulty, additional level widgets, the timer, power ups, etc. Basically what kind of criteria would qualify the game as cartridge worthy?

 

Should I carefully construct something like 30 levels, or come up with a scheme to generate a level based on criteria such that it would "generally" be of a certain difficulty? The random levels might give better repeat playability, but would probably not be as good as hand crafted levels. Then again, hand crafted levels are a pain in the ass. :-)

 

I was also entertaining the idea of giving FlyGuy the ability to, well, fly... Kind of like a hyperspace button, if you hit the fire button FlyGuy flies to a new random location. However, while he is in the air he could be caught by a spider. I think that is like in Asteroids where using hyperspace means you might blow up.

 

Matthew

 

I like the idea of letting FlyGuy hhmhm... fly

 

Perhaps you could introduce something like "warp pils". You start with 5 and you collect some

while you proceed. Using a warp pil will let flyGuy take off.

Wonder how it would look like if FluyGuy is bigger while he is flying.

(like in the racing game Bump 'n Jump when the car jumps).

 

How about adding a Mrs. FlyGuy to the match ?

 

As far as the levels are concerned: now that Magellan is in place, a small contest where the atariage members

design the levels could perhaps be an option. It would save you from having to design all the levels yourself.

The level designers could be credited (in the manual or something)

 

Well, these are just some ideas. I think that FlyGuy will be a big success

[Willsy]

Well, I recently have somewhat of a motivation to finish this game. I'd like to solicit any ideas for levels, difficulty, additional level widgets, the timer, power ups, etc. Basically what kind of criteria would qualify the game as cartridge worthy?

 

Should I carefully construct something like 30 levels, or come up with a scheme to generate a level based on criteria such that it would "generally" be of a certain difficulty? The random levels might give better repeat playability, but would probably not be as good as hand crafted levels. Then again, hand crafted levels are a pain in the ass. :-)

 

I was also entertaining the idea of giving FlyGuy the ability to, well, fly... Kind of like a hyperspace button, if you hit the fire button FlyGuy flies to a new random location. However, while he is in the air he could be caught by a spider. I think that is like in Asteroids where using hyperspace means you might blow up.

 

Matthew

 

This is sounding awesome Matthew! Is this going in a cart or on disk?

 

Want some speech doing?

 

How about it saying "FLYGUY! YEAH!" when you get a new life