Jump to content
IGNORED

Strawberry


Recommended Posts

This is video of an early TI-99/4A simulator prototype. Hope you like it.



Some of the ideas are
* Simulated/known environment/language
* RISC (reduced statements, integers ...)
* Cartridge creator (output runs on hardware)
* Extra commands (sync with frame, music, config ...)
* Popups (character editor ...)
* Import and export (character set, screen ...)
* Paste and copy (program ...)

The demo is C# and uses ushort (0 to 55,535) for now. I might go short (−32,768 to 32,767) instead. int (−2,147,483,648 to +2,147,483,647) will be added for sure. I might go int all the way, but cartridge performance will tell.

I think TI BASIC statements like this
X = INT(RND*24)+1
will have to be changed to something like
X = RND(24)+1

Strawberry and RISC are working titles.

icon_shades.gif Edited by sometimes99er
Link to comment
Share on other sites

It’s a TI-99/4A emulator for Windows.

 

It will only access Basic.

 

It will look (and sound) as if it emulates the 9918 and 9919.

 

It emulates parts of TI Basic and XB.

 

It will operate on integers, so there’s no floating point.

 

There will be some extra commands. And some change of syntax.

 

It will export a Basic program to Cartridge format. Basic will be transformed into machine code. The binary (multiples of 8K) will run on the real deal using EPROM or similar devices, and of course on emulators like Classic99 and MESS. Win994a will not run 24K and above.

 

The emulator is written in C#.

 

It does not contain the original console ROM or GROM.

 

It knows not what 9900 is.

 

It does not use an assembler. Basic statements like LET A=A+1 is translated directly. So basically when I add a statement to the emulator, I’ll also add how to transform it to machine code.

 

The exported cartridge binary is of course not going to have whistles and bells. It should be mean, clean, extreme, stable and unbreakable.

 

You create a cartridge using this command

CREATE CART(“HELLO WORLD”)

 

I think “expression evaluation” is going to be a good learning experience for me. For now you can only do extremely simple stuff, and it executes from left to right. I might even keep it like that, if it helps progress and/or machine code.

 

One idea is a popup character editor. Like when you’re entering this

140 CALL CHAR(40

and press Ctrl + Enter, then an editor pops up and helps you complete the statement.

 

As always ... All specifications subject to change without notice.

 

It’s not that I will be spending every minute on this sucker, but to top it all, my old trusty XP went belly up yesterday afternoon, so now I’m sitting here in my wife’s office. Will look for a shinny new Windows 7 today. Guess it will take days to get back on my feet etc.

 

:|

 

PS. Both emulator and cartridges will be ... hmm ... let’s say “fast”.

Link to comment
Share on other sites

It’s a TI-99/4A emulator for Windows.

 

It will only access Basic.

 

It will look (and sound) as if it emulates the 9918 and 9919.

 

It emulates parts of TI Basic and XB.

 

It will operate on integers, so there’s no floating point.

 

There will be some extra commands. And some change of syntax.

 

It will export a Basic program to Cartridge format. Basic will be transformed into machine code. The binary (multiples of 8K) will run on the real deal using EPROM or similar devices, and of course on emulators like Classic99 and MESS. Win994a will not run 24K and above.

 

 

So in essence this is a Basic compiler which will output cartridge format. Cool! Will it eventually be able to handle graphics and sprites? What is the reason for limiting it to integer only?

Link to comment
Share on other sites

So in essence this is a Basic compiler which will output cartridge format.

Yes, I guess you can think of it as a Basic compiler. I think most compilers won't let you break, list or edit the compiled output. Same thing here. On the other hand you may also enter programs and run them with this one (without compiling).

 

Will it eventually be able to handle graphics and sprites?

Yes, it will handle graphics and later sprites in much the same way possible with TI Basic and XB. I might throw in a hybrid bitmap (allowing many colors for each individual character).

 

What is the reason for limiting it to integer only?

Speed and size in the compiled cartridge. A variable will take 2 or 4 bytes as short or integer. I'm not sure, but I think floating point will take 9 bytes (I looked in TI Intern). And then it takes many times longer for the 9900 to operate on floating point. The emulator itself wouldn't care much.

 

:)

Edited by sometimes99er
Link to comment
Share on other sites

So in essence this is a Basic compiler which will output cartridge format.

Yes, I guess you can think of it as a Basic compiler. I think most compilers won't let you break, list or edit the compiled output. Same thing here. On the other hand you may also enter programs and run them with this one (without compiling).

 

Will it eventually be able to handle graphics and sprites?

Yes, it will handle graphics and later sprites in much the same way possible with TI Basic and XB. I might throw in a hybrid bitmap (allowing many colors for each individual character).

 

What is the reason for limiting it to integer only?

Speed and size in the compiled cartridge. A variable will take 2 or 4 bytes as short or integer. I'm not sure, but I think floating point will take 9 bytes (I looked in TI Intern). And then it takes many times longer for the 9900 to operate on floating point. The emulator itself wouldn't care much.

 

:)

 

Great! I'll be following your progress closely!

Link to comment
Share on other sites

Could u elaborate on create cart? Will that make something playable on a real TI?

 

-H

Absolutely. Playable on the real TI ? Yes !

 

As things are right now, it's more a mockup with code only just supporting the video demo. And no create cart.

 

When I get around to the first release, things might seem totally sparse (only a few commands and statements), but it will still be able to compile carts. And of course I can't help including at least one astonishing demo.

 

With the first release, CREATE CART("<cartname>"), or should it be CALL CART, will create files, probably named cartnamec.bin and cartname.rpk. The first is for Classic99, Win994a and EPROM, the latter for MESS.

 

The first number of releases might have an 8K output limit. Later when I'm into the switch thing, the 8K ROM switching will be over and done within the first second of execution, copying code and data to the 32K RAM and then having code in the remaining non switching 8K ROM. Game limit will be about 40K. The SIZE command could return ...

 

40132 BYTES FREE

 

However ... The first time you use a statement, a function or some other facility within your program, some sort of support routine might be included in the output. Allocation takes place too (variables, strings, arrays etc.). These things reduce the number of bytes free. CALL CLEAR and CALL SCREEN will compile with a very small footprint (bytes taken).

 

CALL SCREEN will take a integer, be it a constant or a variable, as parameter. Syntax checking will be done prior to compiling (actually when you enter the line). This might result in an error. Otherwise it will take the lower byte of a short (2 bytes), an int (4 bytes) or just a byte from a byte array and put it to the 9918. It does not care if the color code is out of range. It won't break, report, fail or crash. This will be a fundamental principle. Some functionality may set an overflow for you to check, if you want to.

 

Thanks for the questions. They help and affect design.

 

:)

Link to comment
Share on other sites

Wow man. This looks cool as hell!!! I'm really looking forward to it. SPRITEs, speed.... Cartridge output!?! This is freakin' great!!!

I'm getting a permanent case of pretty annoying goosebumps.

 

It might not be state of art IDE, but maybe most 99ers should be able to get down and get with it.

 

It will be Open Source at some point.

 

:mad:

Edited by sometimes99er
Link to comment
Share on other sites

If you pull this one off, you'll get a hell of a dev environment.

 

You can write/test/debug your programs on the PC using the simulator, when you'r done you press "compile" and

there you have your cartridge image :cool:

Yep.

 

I've got a few secret tricks up the sleeve for making the cartridge do things that would be considered impossible.

 

Okay, so today I've got this new shiny Windows 7. Ridiculous quad performance and graphics to match. Modern Warfare 2 is soooo smooth. Well, now I better go worry about the data on the old broken XP.

 

:skull:

Link to comment
Share on other sites

Damn... This better be real. April Fools is nowhere in sight, so... the waiting begins.

 

BTW - I think this will likely be the single greatest thing ever for the TI community. Inaccurate Invaders was my first foray into TI Basic land in 20 years, so, I know that I'll at least be immediately productive :)

 

Love and Kisses,

 

Howie

Link to comment
Share on other sites

Language: C#

Status: Odd blurbs

Time: 10 hours

Progress: Misty

Estimate: 0.2 release before fall 2010

 

It sucks, but I'm learning (or I hope I am). A programming environment of today's standards should assist you, and that may even be the fact, but one service returns the ASCII of some keyboard input and another returns other keys. There's an overlap, but arrow keys, delete, break and quit are only with the latter. Caps lock (integrated) is only with the first. So what I basically have to do is override ProcessDialogKey, handle its events, and also handle KeyPressEvent. Searching Microsoft and libraries didn't help much. Google did. All fine until I discover it's a 2002 article. Moving on there's a 2006 (and 2008) article on so called hooks into low-level keyboard. Is this really what it takes to emulate to just some degree. At least I would then be able to simulate keyboard input, and that's nice when it comes user pasting. On the other hand, I'm now reading a caution, if the application is intended for international use with a variety of keyboards, - it is, then this functionality could yield unpredictable results and should be avoided. Oh, how nice. Hell, I just want to read the keyboard and make some decisions. Now, an ordinary input field handles both upper- and lowercase, arrows, enter etc. It might not handle break or quit, but let's leave that for now. If I could hook the inner workings of an input field. Shouldn't that be "international". Maybe I have to instantiate it, but I could put it outside the visible area. Shouldn't affect performance. Hope it will focus there (take input).

 

GDI+ is out since it will only use software rendering. So Microsoft said. GDI will use hardware but apparently only with newer OS. DirectDraw might be out. Direct2D is new. Don't know if it will work on older versions of DirectX. Direct3D has been around for a while and should ensure good performance, and there's probably tons of people out there, who's documented a bit of basic 2D graphics using Direct3D. Started out using standard bitmap and images. It reports use of GDI+. That kinda sucks too. Guess I have to do my own experimenting and testing - and even on some old XP 1Ghz 1 MB config (hope that will do for most 99ers). I told the Studio to run .NET 3.5, but can't be sure. Nobody said it was going to be easy.

 

I'm using the Media layer for sounds. Sometimes it's clean, but mostly there are small pops and cracks in the sound.

 

You know I like results to be smooth, organic, sharp and intuitive, some think I get there from time to time, and some may disagree - as long as I think I strive. Does that make sense ? A lot of the time I risk ending up using too much time on nitpicking. Maybe I should turn to Destroyer. The low level routines work like a charm.

 

:|

Link to comment
Share on other sites

Come to think of it, I might as well do what I did with grapefruit - and that's Lock and UnlockBits and go Marshal (allowing me to move bytes with pointers). That did increase performance with maybe a factor of 10 or more. It does render and save in a flash. I think it was .NET 2 for that one. VS2005 is out the door with my XP crash (just after me announcing Strawberry). Got VS2010 now, but not much of a difference. Don't know if that's a good sign ...

 

:)

Link to comment
Share on other sites

Other than supporting a lot of Basic commands and statements, there's a bit of work behind the scenes. One is to make it act almost like TI Basic/XB, another is to translate relative easy into 9900 machine code.

 

LET A=15

 

So I would want words/short (16 bits registers) and long words/int (32 bit registers). The short for wicked performance and maybe size. The int for convenience (still lightening fast). Don't know if short will be signed or unsigned. I don't know what should be the default or how one will tell the difference in syntax.

 

LET A$="HOWDY"

 

Also I would want strings. Apparently TI Basic doesn't care about you adding characters to a string, but the maximum length halts at 255. XB at least issues a warning (string truncated in), when the length is trying to surpass 255. I've already advocated for an overflow bit. The easy solution is allocating those 255 bytes for any string. That would be easy on the memory handling. - Or maybe 256 bytes to nicely let 3 strings hold a screen (3*256=768) or something.

 

DIM A$(20)

 

I don't know if string arrays would be desirable. Maybe if one could set the maximum length of strings. Maybe not in the spirit of Basic.

 

DIM A(24,32)

 

I know I would want byte arrays and probably also word arrays (the 9900 being 16 bit). And I don't know how to tell them apart.

 

LET A = A$

 

I think there should be as much implicit conversion as possible. Again this might be flexible, won't catch errors and not in the spirit.

 

All for now.

Edited by sometimes99er
Link to comment
Share on other sites

It's really a incredible amazing idea !! when do you expect first beta to us to try ? ;)

Thank you and thanks for feedback/question.

 

I might try and do rapid pre-alpha (private beta) milestone releases. That's more or less whenever one or more functions are incorporated or updated.

 

It probably won't be feature complete this year, but whatever we call it, expect some sort of beta before this fall. That's still limited functionality, but ability to make relatively impressive demos and games.

 

:)

Link to comment
Share on other sites

I've been concentrating on graphics, 9918 simulation and keyboard input.

 

9918 (simulation and cartridge)

 

A separate thread will update the display. It will run at a maximum of 60 times a second (might need a fast computer for this). It will sense if updating is necessary.

 

It will be possible to set different screen update rates. Background graphics and sprites can have different update rates too. This allows for smooth sprites and complex updating of background.

 

Scrolling (up and down) will be very fast.

 

9918 (simulation only)

 

Some preparation will also sense if a complete render is needed or if a maximum of about 50 locations needs updating. These are put on a stack and pulled if maximum is not exceeded and no patterns are changed. This is only done to free resources.

 

Import and export of character sets. Of course ordinary CALL CHAR will still work in run mode.

 

Possibility for different sets at immediate and run mode respectively. Only run mode characters are exported to cartridge. Immediate mode will have panic button (a key combination).

 

9918 (possible hack)

 

If anybody knows how to wire things, I could slow down emulator display updates and then control a real 9918 at full speed via some device (USB).

 

Keyboard input (simulation only)

 

Still trying to find a bridge over troubled waters. Asking at other forums.

 

Keyboard input et al (possible hack)

 

Again if anybody knows how to wire things, I could let the emulator read another device etc. Ultimately letting you use the emulator via a real TI-99/4A. SAVE, CREATE CART, FCTN QUIT ... and it's there on the selection screen !

 

System requirements (emulator)

 

.NET 3.0 (default in Windows Vista and above)

 

System requirements (cartridge)

 

32K Memory Expansion

 

:cool:

Edited by sometimes99er
Link to comment
Share on other sites

Very cool!! So this will require a 32k expansion? It makes sense--- a compiled source from BASIC couldn't possibly be as streamlined and compact as a pure assembly design and would understandably require expansion. This is a great idea and I eagerly await the pre-BETA BETA. :)

Link to comment
Share on other sites

Very cool!! So this will require a 32k expansion? It makes sense--- a compiled source from BASIC couldn't possibly be as streamlined and compact as a pure assembly design and would understandably require expansion. This is a great idea and I eagerly await the pre-BETA BETA. :)

Mostly yes I guess.

 

Scratchpad (the console 256 bytes CPU RAM) itself will hold 32 bytes of workspace registers, a 16 level subroutine stack and a few other system control variables.

 

At the emulation end of things I can make it quite sophisticated or should I say take different routes of action all depending.

 

If the Basic programmer (the user) doesn't use too many variables (variables are naturally in need of RAM), then I could decide to go only for Scratchpad - aka NO Memory Expansion (32K CPU RAM). I didn't design for variables to be in VDP RAM, but that should maybe be an option. This could slow things down. On the other hand, if we want to sell cartridges to people with only the bare console at hand, this option would be cool. Some careful design on the users part could limit the need for RAM - knowing that data generally are stored in ROM. Something to consider there.

 

Also, if the user uses PRINT with his program, I'm designing for some Lime Crime Magic Powder, and Memory Expansion will be unavoidable (Scratchpad and VDP RAM won't do).

 

The idea is that export and compilation to cartridge includes routines on a need only basis. I might even do compilation as lines are entered. The user could then have easy access to consequences on ROM and RAM as he inputs or make changes. The SIZE command could leave a window open with memory info updated continuously.

 

If you're exceeding the need for 8K ROM, my simple solution was to copy three 8K sections to the upper part of RAM and keep one in ROM. That's 32K of code (3*8+8 ). Obviously having the need for Memory Expansion. The lower 8K would then be used for variables, strings, arrays and more. I might make something more clever with bank switching. The code limit with bank switching would of course be 64K.

 

I think there might be someone working on a hardware solution for GROM. Technically the original design of the TI-99/4A *) does open up for not only 5 GROM or GRAM each of 6K or maybe even 8K, but there's 15 more pages (never seen more than one used though). That's at least 30K (5*6) or maybe 640K (5*8*16) of extra memory.

 

:)

 

*) Page 7 in TI-99/4 System Software Design Specification, February 29th, 1980.

Edited by sometimes99er
Link to comment
Share on other sites

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. :)

Edited by sometimes99er
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...