Strawberry

[unhuman]

Call me crazy - but for speed purposes by convention, I think I'd rather see A be 16-bit integers and A% to be the 32 bit ones.

 

-H

 

Well, in the picture above I made a small hint about variables. I remember one computer having the % after the variable name. I googled and it made me read some of the C64 Programmers Guide. I used to have that one. Wonderful manual by the way. So, you would have ordinary variables being floating point. Then there would be the string variables having a $ as suffix in the variable name. And then there were faster variables with the % suffix which were integers. I guess they must have been 16 bit (8 bit variables would be rather limited range). Anyways, I think I'll adopt the syntax somewhat. 32 bit integers will be the "ordinary" variables. The 16 bit integers will be the faster variables - and have the % suffix. - I was shocked to relearn that C64 variables only were known (to the computer) by they first two characters. The variables LE and LEARN would be the same. So what do we have ?

 

LET A = 0

The variable will be a 32 bit integer having a range of −2,147,483,648 to +2,147,483,647.

 

LET A% = 0

The variable will a 16 bit integer having a range of −32,768 to +32,767 (or maybe unsigned 0 to 65,535).

 

LET A$ = ""

The variable will be a string with a capacity of 0 to 256 characters.

 

The above examples will create 3 different variables - aka they will not be confused with each other. Same as C64.

[sometimes99er]

Call me crazy - but for speed purposes by convention, I think I'd rather see A be 16-bit integers and A% to be the 32 bit ones.

 

-H

Okay.

 

I chose the other way around trying to come more close to TI Basic. But whatever way it's not floating point by far. So for the sake of speed, we'll do as you say.

 

[sometimes99er]

Been redesigning and maybe optimizing a bit. I'm sticking with C# for now, but I've also done some tests with Flash. Added about seven or eight things to make this demo run. To many weights and pulleys as is.

 

http://www.youtube.com/watch?v=3jfw3rU_jTI

[+retroclouds]

Very impressive

 

Looking at the video, it seems that you have call color, call hchar, ... variables, loops, expressions and random function working.

 

Might sharing some light on how you did the implementation especially in regards to the expression handling ?

[unhuman]

Can we help test? :)

 

Very impressive

 

Looking at the video, it seems that you have call color, call hchar, ... variables, loops, expressions and random function working.

 

Might sharing some light on how you did the implementation especially in regards to the expression handling ?

[sometimes99er]

Very impressive

 

Looking at the video, it seems that you have call color, call hchar, ... variables, loops, expressions and random function working.

 

Might sharing some light on how you did the implementation especially in regards to the expression handling ?

Thanks. Expression evaluation is relatively simple left to right. No operator precedence. Parentheses are not allowed except with functions and most statements. Functions and statements only take super simple arguments, being a variable or a value, no expressions allowed. That's how it is for now. I'll definitely be looking into better expression evaluation along the way. The user has to plan somewhat too since this is not floating point as with TI Basic.

 

TI Basic

50 / 9 * 4 = 22.22222222

50 * 4 / 9 = 22.22222222

 

RISC Basic

50 / 9 * 4 = 20

50 * 4 / 9 = 22

 

[Opry99er]

Man!!! This is really taking shape!!! I hope this thing comes to fruition.... There will be some very pissed off people if you shelf this thing.

 

Great job, buddy. This may well

revolutionize the TI cartridge market.

[sometimes99er]

Can we help test? :)

Oh yes, please. Probably at least one month before first release. There's many uncertain aspects and no cartridge creation yet, though the command is accepted. OLD is just lazy reading plain text into a program array. Still no SAVE. You can't delete, backspace or use arrows. That's really bad. And I'd like to add some kind of frame sync statement before any release. This should give simulation and cartridge performance a chance of being similar. With C# I haven't dealt much with timers, threads and overriding, so I'm learning as I go. I'm also wondering why the last demo only seem to peak at 22% CPU in one of the cores.

 

[sometimes99er]

Man!!! This is really taking shape!!! I hope this thing comes to fruition.... There will be some very pissed off people if you shelf this thing.

 

Great job, buddy. This may well revolutionize the TI cartridge market.

I'm actually more worried about destroying assembler game programming as we know it. Future plans might include exports to other engines like Basic4GL, ColecoVision, Flash and J2ME.

 

[unhuman]

Won't stop me. I program externally and just paste into Classic99.

 

You can't delete, backspace or use arrows. That's really bad.

[+retroclouds]

Man!!! This is really taking shape!!! I hope this thing comes to fruition.... There will be some very pissed off people if you shelf this thing.

 

Great job, buddy. This may well revolutionize the TI cartridge market.

I'm actually more worried about destroying assembler game programming as we know it. Future plans might include exports to other engines like Basic4GL, ColecoVision, Flash and J2ME.

 

 

Recalling yesterdays' chat, I think Strawberry will be a blast. I wouldn't worry about destroying assembler game programming. We'll just see more software running at warp speed ... and that's a good thing

 

Perhaps we'll even see way more homebrew games on cartridge in the future

 

EDIT: It would be very very cool if you'd be able to output colecovision binaries too :-)

Edited May 24, 2010 by retroclouds

[Opry99er]

Hey sometimes--- any new stuff to talk about?

[sometimes99er]

Hey sometimes--- any new stuff to talk about?

Hi Owen, and thanks for asking.

 

I'm continuing developing and rearranging things. Pop up windows can be somewhat "emulated" in Flash, so a rerouting at some later stage is still not out of the question. I'll stick with .NET 3.0 for now as it is default in Vista and up (Windows only as I understand).

 

I'll try and be true to TI Basic as much as possible (and XB to some extend), but of course I'll be adding a bunch of new commands.

 

Apart from standard graphic mode, I'm also making good progress in support of text, multicolor, bitmap and hybrid graphic modes.

 

CALL PIXEL(row, column, color)

CALL GPIXEL(row, column, variable)

 

The above, CALL HCHAR, CALL GCHAR, CALL CLEAR and more, will work and make more or less sense in all graphic modes. Out of range values are adjusted automatically at runtime. Generally you won't be able to crash the darn thing.

 

I'm preparing for the next demo. I'm trying to make something really nice, so it may take a few weeks to pull it all together.

 

Edited June 13, 2010 by sometimes99er

[+retroclouds]

You might want to check out Mono here.

I guess it should allow you to run Strawberry on Linux and OS X as well.

 

From their project page:

 

Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Novell (http://www.novell.com/), Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. A growing family of solutions and an active and enthusiastic contributing community is helping position Mono to become the leading choice for development of Linux applications.

[unhuman]

EDIT: It would be very very cool if you'd be able to output colecovision binaries too :-)

 

There's a very good C dev toolkit for the CV... Alas, the sounds stuff - I just don't understand.

 

-H

[sometimes99er]

You might want to check out Mono here.

I guess it should allow you to run Strawberry on Linux and OS X as well.

Thanks for the link. I might go down that road.

 

There's a very good C dev toolkit for the CV... Alas, the sounds stuff - I just don't understand.

Well, I don't think another level of abstraction (the C dev toolkit for CV) is going to be much help. When the time comes, I'll be looking into the CV BIOS song table specifics, and Strawberry and therefore TI cartridge output should benefit (sound sweeps). My Z80 is rusty, so I might try and get outside help there. Foundation work is still being laid, so it's much too early to awaken anybody from their beauty sleep. At times a difficult start, but I like to do the groundwork and then have a few things my way. I'm learning as I go (like 2 steps forward and 1 step back). It's also not totally impossible to think of Strawberry booting into another Basic like the Adam SmartBasic. I'll make it possible to configure constraints. For example the CV has 1K RAM as standard. The TI has only 256 bytes of RAM as standard (and CPU registers there too).

 

I'll have to get speed control into some shape or state, before releasing any beta, to get Strawberry to act a bit like the real world TI. At first a Strawberry programmer will have to limit himself within the frame timeslot. At some future stage I might be able to do aid with some sort of cycle count. A running program however has different needs for cycles with each frame (different action on screen etc.). Maybe a tachometer when running emulation.

 

Edited June 13, 2010 by sometimes99er

[Opry99er]

I was hoping perhaps you had an update to share with us. Actually I was eating a carton of strawberries this morning with my son and I had a little nudge to read this thread again. Hope you still care to develop this further--- it's a great project man.

[sometimes99er]

Ah well, let's just say that work has been done. It's been a bit like taking one step forward and two steps back for some time.

 

[sometimes99er]

Overall

 

There's still tons of work to be done. I've been working and experimenting in different directions.

 

Right now I'm trying to lower efforts with sounds, sprites, accuracy, graphic modes, speed and "extras", and then concentrate a bit more on release version and crucial features for basic demo and game production. When doing things like Beryl (sprite tool) and Pineapple (font tool), I'm also trying out designs and developing ideas for the "extras" (with Strawberry).

 

Assembler

 

Think I can bypass this for now, but in addition to saving basic source and binary cartridge output (and all the other stuff in the "extras" box), assembler output is on the list. Later internal multi stage passing will allow easier access for users (=hardcore assembler developers) to expand and/or further co-develop Strawberry. I'm also thinking about a byte code super level with option to target different processors (even graphic and sound).

 

With the above I might have to lower my ambitions about near realtime memory management (that's simply consequences of entering a line in Basic or pulling in extras). Using like Print for the first time is rather expensive (=relatively memory hungry).

 

First release

 

Please don't expect too much. Once the first release is out, you should hopefully expect many smaller and some larger updates.

 

Can't set a date, real life fluctuates, TI time is residue and wife would respond immediately. Though a date would stick to me like glue (until I run out of money ... guess it's the same with the wife ... I could pretend to be broke !?).

 

[+retroclouds]

Thanks for keeping us posted

 

If this really is pulled off, it will change the way how new games get developed.

 

A very fascinating project indeed

 

I think it's a good idea not to set a specific target date for release.

I'd say it's done when it's done

[sometimes99er]

How often to update the display

 

I've done a bit of research into this before, but I had to look it up again. My theory for emulator and cartridge output is, that I need to update sprites 60 times a second, while the background graphics "only" need updating 30 times a second. If there's only a small number of updates, it will be dealt with every 1/60 of a second, and then when a full screen update is required, this may very well take more than 1/60th of a second, - and if it does, it will at least wait for the next frame update before any new updates of screen. Phew! If this (more than 1/60th of a second) happens a certain number of times within a certain time frame, then the update is effective brought down to 1/30th of a second. Tests for trying to up the frame rate will be done.

 

I'm working on the above to allow complex artificial intelligence, full screen engines or other stuff to get its share of CPU at the expense of screen updating.

 

I guess when you type in the emulator (or on the TI-99/4A), a frame update of 30 times a second would be alright. The emulator will still read all your keystrokes (limited by your own PC).

 

Reading the keyboard for games every 1/60 of a second should be fine. But this is not good enough, if you're allowing the user to enter text.

 

How fast do people type

Fast finger test

 

I think I'll just read the keyboard every time the Basic program encounters a CALL KEY. And I guess it would be acceptable to have the program counter (PC) stop at an INPUT or ACCEPT. I guess I would allow music to play, but you won't be able to move sprites or anything else while waiting for the user to enter a string of text or whatever (with INPUT or ACCEPT). This allow the TI-99/4A to access the keyboard a couple of hundred times every second (with "famous" delay loop for whatever reasons (debounce/electric current)). This should catch most fast-finger-dudes.

 

Did I make any sense at all ?

 

Edited August 13, 2010 by sometimes99er

[sometimes99er]

Trickery

 

If you're wondering why I want to go through all the trouble above think of this.

 

I have a fast program. It updates the score and more than 60 times a second. Will you be able to see all the updates ? No.

 

I have a fast program. It counts from 1 and up. Every time it adds one, it displays the result. It updates the number on screen and this happens more than 60 times a second. Will you be able to see all the updates ? No.

 

I'm doing this one step at a time to have you follow me.

 

I have a fast program. It counts from 1 and up. Every time it adds one, it displays the result and scrolls the screen. Woh, hold on, scrolling the screen takes a lot of time - well, relatively to the counting that is. Maybe it updates the number and scrolls the screen in less than 1/60 of a second. Will you be able to see all the updates ? Maybe.

 

Now the counting above is slowed down considerable because of the scrolling. If we had 24 lines in memory and put the number to one of the lines at a time and did not update the screen (VDP), then the count would be very fast again. If we then only interrupt the counting every 1/30th of a second to update the screen, taking into account which line should start out at the top, then my guess is, that your eyes would almost not be able to tell any difference between the two methods. Other that one counts much faster than the other. Trick no. one.

 

Is this cheating. Yes.

Is it optimizing. Yes.

Is it good for anything. Yes. We can scroll the entire screen every 1/30th of a second, and still have lots of CPU for doing funny stuff. And yes, we can scroll it in any of direction (that's not only 8 directions, but also 1 up and 2 left etc.).

Is it bad. Yes. It requires a few control bytes and an 768 byte array in CPU RAM (=screen buffer).

When is scrolling performed. Only when the screen is updated. Not while counting. Several lines in screen buffer may be overwritten before a screen update (moving the screen buffer to the VDP).

 

Edited August 13, 2010 by sometimes99er

[unhuman]

How fast do people type

Fast finger test

 

68 WPM! And I wasn't even in the zone yet.

 

Seriously, I think your plan sounds pretty good. Most people are going to be using this for games, I'm sure, so it sounds like it's a plan. I don't think you're gonna miss too many keypresses - besides - isn't that the max the system could do anyway? 1/60s?

 

EDIT - sometimes makes a good point about partial updates... If games are scrolling - that could result in tearing. That never looks good. If people are doing that - perhaps some setting to disable the "planned" strategy and then if the programmer screws up and uses too much CPU and things fall apart, blame it on him....

 

-H

Edited August 13, 2010 by unhuman

[sometimes99er]

From the fonts thread ...

 

Will you combine it with Strawberry (e.g. export as character patterns) ?

You will see the first Strawberry release with just a small subset of TI Basic functionality (with a few variations) and ability to create cartridges. I'll be adding (and changing) from then on as I go along.

 

The ability to import a font/character-set has high priority. You may define characters using the well known CALL CHAR, but you will also be able to do something like this:

100 CALL CHARSET("dsk1.graphics")

or

100 CALL CHARSET("graphics.gif")

Memory will limit the number of fonts available in one program.

Let's try and create a cartridge with the above program:

CALL CARTRIDGE("mycartc.bin")

Works fine. Testing the cartridge will probably just show a blank screen. The font/characters will be moved from ROM to VDP, and since the screen is not updated with anything, the "space" character will fill the entire screen with its pattern. The cartridge will loop forever waiting for you to press QUIT. Running the same program in Strawberry sets all characters and then restores the TI Basic environment characters while ending the program (the one liner).

 

The ability to combine your old work or that of others into a font will also be possible like this:

460 CALL CHARSAVE("crapgame.gif")

Let's try and create a cartridge with the above program:

CALL CARTRIDGE("mycartc.bin")

It will return an error like this:

* CAN'T DO THAT IN 460

You will be able to run the program in Strawberry, but you can't create a cartridge with that statement in the program. Sorry.

 

The "external" fonts/characterset are in the 64x256 format. Only characters 32 through 159 are used/stored (equals 1K of memory (=((159-32)+1)*8 ). Future enhancement and statements can change the possibilities.

 

Edited August 29, 2010 by sometimes99er

[sometimes99er]

First release ?

 

You know, real life, on and off, sporactic interests, TI and otherwise ... though not always on my mind, it lurks there somewhere. Imagine waking up at night, thinking about collision detection and what's more.

 

Release date ?

 

I think I said September once, but now I don't see it happening this year. A bit of drive and dedication, and a lot of time, yes, it wouldn't be impossible.

 

Sprites ?

 

No, first release(s) will not support sprites. First of all it's realized almost as a completely independent layer. Secondly, I haven't really given the maximum of 4 sprites per horizontal line much thought. Information about the fifth sprite (on a horizontal rasterline) seems totally unnecessary (guess it sets at every rasterline like the collision bit). Thirdly, but not least, I've got some really nice ideas about collision detection (both sprite to sprite and sprite to background) - actually using bits of what's already been "invented" with other languages/games/platforms.

 

Data files ?

 

Nope. Haven't even given it much thought. It might happen, but there will be other commands for graphics, maps, screens etc.

 

Cartridge creation ?

 

I have simple things working, but the amount of time taken (on my part) is kind of breaking my confidence. I think I might have to look into building my own assembler or porting one (abstracting the process into a separate layer). And the user should of course not be able to blink an eye while compiling (guess I'm assuming a decent PC).

 

Realtime memory management ?

 

No and yes. For now the emulator allocates on creation time (run or create), that is the easy solution, but I would still like for the user to see consequences on memory as he goes along. There's a few problems, but there might be solutions. Like if you turn on sprite rotations, is it going to buffer in ScratchPad RAM, Expansion Memory RAM or mostly do the thing in VDP (minimal buffer). There's a trade off here and there.

 

How many TI Basic programs will run without modification ?

 

I'm afraid many or most will have to be modified - hopefully a good deal in a lesser degree.