Strawberry

[+retroclouds]

Thanks for the update sometimes99er. Very nice.

 

Even though nothing is released to the public yet, I think these are interesting times.

 

Thinking about Turboforth, Strawberry and spectra² these are all indiviual projects.

Still there are some commong things that seem to affect all.

 

That goes especially for the "thinking" processes that go-on before any coding is done.

 

It seems we're all dealing with:

 

• How do I setup scratchpad memory
  
• What will be stored in VDP
  
• Speech, Sprites, Graphics, ...
  

 

I find that very cool.

 

Considering we're in 2010 and that we are trying to squeeze the most out of an 80's computer

[+retroclouds]

Considering the many challenges you are faced with while developing such a big project, I guess it is a lot to tackle by a single person.

 

If you want to create a cartridge, you at least need an assembler and some support libraries if you don't wanna start everything from scratch.

 

I'm hoping that my spectra² library could be of any use. Another possibility would be to use Turboforth for driving the program on the TI-99/4A. Perhaps Turboforth could be more "in line" with what Strawberry outputs. Then again, that would quire 32K memory expansion.

 

Anyway, I'm really hoping that my library could be of use for you. Have you considered doing a "mini-interpreter" instead of pure assembly language output ? That might be an option.

[sometimes99er]

Thanks for feedback.

 

Yeah, it's actually much too ambitious, and the project is still much a vision, with an ongoing phase of growing in different directions. It seems every time I tell myself to concentrate on a scooped down release version, I wander off in some other direction. The work lately on cartridge output actually made me want to exercise a bit in assembler and do one or two mini games. I would have loved to show off a bit of everything, but I think I have to simply forget about backward compatibility and induce "start small, think big". Like releasing something quite minimal. Have I posted this link before ?

 

http://learningvoyager.blogspot.com/2008/06/start-small-think-big.html

 

I was thinking about a detour down collision detection. Apart from using the sprite collision bit, I was thinking about doing pixel sampling, box sampling, masks and square distance (my chosen nicknames for now). I'm tempted at starting a thread on this, and doing mini games on these techniques. Plan is to have all methods available to the user. All have their pro and cons, and could be used in combination. Like if there's no sprite collision bit then maybe you need go no further.

 

I think I might have to pass on speech altogether. I could sample the built-in vocabulary for the emulation. And yes, I think the built-in vocabulary can be used to great effect in many future games.

 

The cartridge creator does nothing more than translating one Basic statement after another. Support routine are only included as they are used. So I don't know about spectra² as backbone, but it would be cool, if we could share source for different routines. For examples I would like to know how to tell 50Hz and 60Hz machines apart (so I could simply avoid the 9901 timer, if the user wants something like a timer in his game).

 

A mini-interpreter (bytecode) might be an option at a later stage. I haven't been able to see the significance yet. Compression might be the road to take first.

 

And yes, I'll have a go at producing some kind of impressive demo in both spectra² and TurboForth when the time comes. Looking forward to both of them.

 

[marc.hull]

Thanks for feedback.

 

Yeah, it's actually much too ambitious, and the project is still much a vision, with an ongoing phase of growing in different directions. It seems every time I tell myself to concentrate on a scooped down release version, I wander off in some other direction. The work lately on cartridge output actually made me want to exercise a bit in assembler and do one or two mini games. I would have loved to show off a bit of everything, but I think I have to simply forget about backward compatibility and induce "start small, think big". Like releasing something quite minimal. Have I posted this link before ?

 

http://learningvoyager.blogspot.com/2008/06/start-small-think-big.html

 

I was thinking about a detour down collision detection. Apart from using the sprite collision bit, I was thinking about doing pixel sampling, box sampling, masks and square distance (my chosen nicknames for now). I'm tempted at starting a thread on this, and doing mini games on these techniques. Plan is to have all methods available to the user. All have their pro and cons, and could be used in combination. Like if there's no sprite collision bit then maybe you need go no further.

 

I think I might have to pass on speech altogether. I could sample the built-in vocabulary for the emulation. And yes, I think the built-in vocabulary can be used to great effect in many future games.

 

The cartridge creator does nothing more than translating one Basic statement after another. Support routine are only included as they are used. So I don't know about spectra² as backbone, but it would be cool, if we could share source for different routines. For examples I would like to know how to tell 50Hz and 60Hz machines apart (so I could simply avoid the 9901 timer, if the user wants something like a timer in his game).

 

A mini-interpreter (bytecode) might be an option at a later stage. I haven't been able to see the significance yet. Compression might be the road to take first.

 

And yes, I'll have a go at producing some kind of impressive demo in both spectra² and TurboForth when the time comes. Looking forward to both of them.

 

 

<tell 50Hz and 60Hz machines apart (so I could simply avoid the 9901 timer, if the user wants something like a timer in his game).>

 

I just happened to have run into this problem of figuring out the real length of an interrupt. If you use the 9901 in timer mode and time the length between interrupts that should give you enough data to tell whether you are in PAL or NTSC. At 3MHZ clock the length of an NTSC VDP interrupt is very close to 782 9901 clock ticks, PAL should be right around 870 ticks (although I didn't test it.) Theirry has code on his site to do the actual measuring...

[+retroclouds]

Perhaps you could turn this into some kind of collaboration project. I think you have a clever design going for Strawberry.

Also your decision about doing this project using the .NET platform doesn't sound like a bad idea to me.

 

You could "split" the Strawberry project up in different modules (e.g. emulator, debugger, assembler, support library).

If you design & set the interface specifications then other programmers could tune in and have an own module they develop

and take care off, in the supported language they are good in. Also with MONO there's a nice alternative for the linux world.

The only real alternative I'd see for a .NET Strawberry would be java.

 

As far as spectra² is concerned, I'd sure be interested in sharing routines. And would be interested in borrowing some myself

 

Regarding the 50/60 Hz test; I also have that on my to-do list, because I need it for adjusting my thread scheduler.

Currently the threads on PAL run a tick slower as on NTSC. It would be cool if you could just check a memory location.

But it seems that isn't possible. I was thinking about doing a tight loop in scratchpad on startup.

Say counting from 0 to XXXXX and see how often the VDP interrupt flag is set in between.

What I don't like about these solutions, is that it requires some time for getting a test result.

I haven't done any math on it yet, but I suppose you'd need to let it run for 1/2 second to get a reliable answer.

Edited October 20, 2010 by retroclouds

[sometimes99er]

I just happened to have run into this problem of figuring out the real length of an interrupt. If you use the 9901 in timer mode and time the length between interrupts that should give you enough data to tell whether you are in PAL or NTSC. At 3MHZ clock the length of an NTSC VDP interrupt is very close to 782 9901 clock ticks, PAL should be right around 870 ticks (although I didn't test it.) Theirry has code on his site to do the actual measuring...

Thanks Marc. I think the ColecoVision has a different value within the ROM, and I was hoping it could be as easy as that. How do you get/plan to get the value, Filip ?

 

I think most of us write and test on emulators at 60 Hz these days, and for the expected relatively few of the community who has 50 Hz real stuff to run on, the action, music etc. (perhaps even a timer) runs about 1/6th slower or 17%. Making an action game considerably easier(/boring) !? Maybe a bit more relevant due to all the cart production happening.

 

Yesterday I did some work on my Sudoku cart, and it sure would be nice to have a timer (with seconds), that runs correctly on both machines. An early Sudoku demo of mine did user the 9901 timer. And if I have to measure using the 9901 anyway, then I might as well use it directly (for timing). And for timing in Strawberry too. And maybe it wouldn't be to far fetch to have music running from the timer too (not to have it run 17% slower). Problem remains about smooth moving sprites/graphics - they have to follow the vertical blank - or do they ?

 

[sometimes99er]

Perhaps you could turn this into some kind of collaboration project. I think you have a clever design going for Strawberry.

The size (of the project) forces me to clean up, use somewhat descriptive but not too long names and comment - well, at least on the method level (and up). Howard said it would be alright/nice to interface with his Magellan map editor, and that he'd be willing to make changes to also "service". I do plan to "release" to SourceForge.net and at least before 2012.

 

Also your decision about doing this project using the .NET platform doesn't sound like a bad idea to me.

 

You could "split" the Strawberry project up in different modules (e.g. emulator, debugger, assembler, support library). If you design & set the interface specifications then other programmers could tune in and have an own module they develop and take care off, in the supported language they are good in. Also with MONO there's a nice alternative for the linux world. The only real alternative I'd see for a .NET Strawberry would be java.

At a certain point it was job relevant, but C++ might be a better choice, well, at least considering the game world. Also Flash is something to consider though I'm still a bit worried about speed and output (haven't tested it fully yet (AS3 is not as loose as AS2 and debugging is pain (relatively))). There's a ZX Spectrum AS2/3 emulator out there. And several 9919 AS3 emulators too. They're opensource, but I don't know the license (yet).

 

Yeah, well, I'm using the VisualStudio debugger. Strawberry might get a debugger, my only loose plan was to trace and trap values. If you're familiar with the TI Basic environment, then I think it's easy to list, edit, add etc. to do your own debugging, but of course. Remember listing is super fast.

 

Well, looking at projects in the community and also the desire to turn things your own way (hehe), I think I'm on this one on my own for the first few miles. Ideas are more than welcome, and testing should be interesting with the first release. This will probably also show how much interest there is. It worries me a bit to see the "game programming forum" turning toward fancy hardware addons and development environments, which all seem to end up lacking software support. All the tools (on here) hasn't really generated a "lift" as I see it. I guess we just have to do what we think is fun, and then maybe things will "shape" in the long run ?

 

As far as spectra2 is concerned, I'd sure be interested in sharing routines. And would be interested in borrowing some myself

 

Regarding the 50/60 Hz test; I also have that on my to-do list, because I need it for adjusting my thread scheduler.

Currently the threads on PAL run a tick slower as on NTSC. It would be cool if you could just check a memory location.

But it seems that isn't possible. I was thinking about doing a tight loop in scratchpad on startup.

Say counting from 0 to XXXXX and see how often the VDP interrupt flag is set in between.

What I don't like about these solutions, is that it requires some time for getting a test result.

I haven't done any math on it yet, but I suppose you'd need to let it run for 1/2 second to get a reliable answer.

I think 3 frames should be more than enough. I'll refine some code for this soon (no promises).

 

[+retroclouds]

It worries me a bit to see the "game programming forum" turning toward fancy hardware addons and development environments, which all seem to end up lacking software support. All the tools (on here) hasn't really generated a "lift" as I see it. I guess we just have to do what we think is fun, and then maybe things will "shape" in the long run ?

 

I agree. Isn't it about having fun anyway? I still think there is a need for good development environments anyway.

And let's face it, we are still way behind other communities (think openMSX emulator for instance).

Think about the wonderful things that happened this year with Magellan, the competitions, etc.

 

I know for sure that for me, there would not have been any Pitfall! without the classic99 emulator and debugger.

Even though MESS comes close and in some regards is better

 

For myself I decided to stop doing further Tutankham development until I have a -for my purposes- good assembly language library.

It was annoying me that I had to do so many things from scratch.

I'm currently using spectra² for converting one of Owens games (where is he anyway?), and it looks pretty straightforward.

On the other hand, we have to be realistic. Assembly language will never be as easy as basic or any high(er) level language.

 

And there is still no real C alternative available for the TI-99/4A at the moment.

 

I think Strawberry could fill a gap here

[Opry99er]

I'm still here, Filip. Been swamped.

 

Karsten, Strawberry is such a cool concept.... You pull this off, it'll be the coolest thing since the EA suite TI released in 81.

Edited October 27, 2010 by Opry99er

[sometimes99er]

Today I made progress with sound in C#. Work with sound and a music tool may be the thing to do for the next weeks. It's not just a mere music tool (with ability to do soundeffects), Strawberry simply needs me to exercise in that area, - and Destroyer, Sudoku and a few other games need the tool badly. If tests with a redesigned spectrum analyzer goes well, there will be a dedicated soundeffects tool too.

 

The potential for something great is there, though I have to cut a lot of corners to get anything out there at all.