Jump to content
IGNORED

Ultimate Extended Basic


retroclouds

Recommended Posts

8 hours ago, RXB said:

For over a year I have asked for help on XB ROM's.

Honestly I asked for help on re-writing XB ROMs since 2000 with not one offer.

 

So this is pretty pie in the sky if I can not get help for 12K of Assembly ROM asking for 1 meg help is hilariously sad.

 

Yea you can use Myarc XB but it has almost no backward compatibility for good reasons.

 

This could be done, but it is going to take a group effort and never got any help yet myself so good luck.

 

I'm with you it's going to take a group effort for this to ever materialize.

 

However, the idea of this thread is to think about how an ultimate extended basic could look like and what features are most important. 

This without any thinking constraints of what we had in the past (except for hardware limitations and compatibility with existing extended basic perhaps).

 

That's why I'm very interested learning what people like or consider important and perhaps do some design document based on that.

Can you share some details on why Myarc XB has almost no backward compatibility? 

Link to comment
Share on other sites

I would also consider following important:

  • Possibility for easy extensibility. 
    By that I mean it probably makes sense to decide what belong to "core" functionality and what can be added via extensions (think libraries, ...)
     
  • What language Ultimate Extended Basic should be implemented in?
    From my point of view that would be C, mixed with assembly language.
    Don't know how mature the current TMS9900 gcc target and libraries are at this time though.
     
    Nonetheless, having written too much assembly language lately I would not be inclined tackling such a project with only assembly language. 
    For the most performance critical parts or for interfacing with existing libraries one could still mix-in assembly language ofcourse.

    I don't see GPL in the picture due to the speed penalty and the fact you are more or less at the same coding level as assembly language.
    But that's just my opinion ofcourse. Don't forget, the idea of this thread is to discuss all possibilities without thinking constraints.
Link to comment
Share on other sites

I do have one request (if at all possible)... the addition of a 'DOS' command.  Upon execution it would load Force Command into memory.  (How this would be done, I leave to you, the expert in such things.

 

This way, if some at sometime in the future a new "XB tipi.path.filename" is added to Force Command, users will be able to easily go back and forth between BASIC and DOS as easily as those running EA5 programs.

Link to comment
Share on other sites

I would like to see an overhaul of the sprite collision handling routines provided by extended basic. Imagine that instead of having to "poll" for collisions ala CALL COINC, one could use a callback function-like system. Prior to executing your main game loop, you declare which sprite collision combinations you are interested in like so:

100 CALL COINCSETUP(#1, #2, PLAYERHIT)
110 CALL COINCSETUP(#1, #3, PLAYERPOWERUP)
120 CALL COINCSETUP(#4, ALL, ENEMYHIT)

Then, further down the program you declare the subroutines mentioned above where you put your collision handling code. E.g.:

10000 SUB PLAYERHIT
10010 PLAYERHEALTH = PLAYERHEALTH - 1 :: IF PLAYERHEALTH = 0 THEN RESETLEVEL = 1
10020 SUBEND
10030 SUB PLAYERPOWERUP
...

The actual collision check would be performed in the interrupt handler and whenever a collision that the program is interested in happens the associated callback routine would be called.

  • Like 1
Link to comment
Share on other sites

3 hours ago, TheMole said:

I would like to see an overhaul of the sprite collision handling routines provided by extended basic. Imagine that instead of having to "poll" for collisions ala CALL COINC, one could use a callback function-like system. Prior to executing your main game loop, you declare which sprite collision combinations you are interested in like so:


100 CALL COINCSETUP(#1, #2, PLAYERHIT)
110 CALL COINCSETUP(#1, #3, PLAYERPOWERUP)
120 CALL COINCSETUP(#4, ALL, ENEMYHIT)

Then, further down the program you declare the subroutines mentioned above where you put your collision handling code. E.g.:


10000 SUB PLAYERHIT
10010 PLAYERHEALTH = PLAYERHEALTH - 1 :: IF PLAYERHEALTH = 0 THEN RESETLEVEL = 1
10020 SUBEND
10030 SUB PLAYERPOWERUP
...

The actual collision check would be performed in the interrupt handler and whenever a collision that the program is interested in happens the associated callback routine would be called.

That's a cool idea! I like that a lot.

Link to comment
Share on other sites

1 hour ago, senior_falcon said:

What shortcomings exist in the XB roms that you feel need to be changed?

Duplications of routines for one thing.

 

Best would be add an assembly XB ROM routine for Sprite collisions and for distance in another 4K banks of XB ROMs.

This would make it totally backwards compatible and make a better XB cart.

 

Add in another 4K ROM for dealing with Integers or Floating Point as currently EVERYTHING IS FLOATING POINT.

Example get a number like CALL HCHAR(3,7,44) every damn number is considered Floating Point, so I have done some of this in RXB but so little can be changed.

The current GPL command XML GETCHR uses Floating point and should only look for a Decimal Point or E and instead consider every number Integer instead.

INT(#) is used so much and slows XB to a crawl.

 

These are just a few examples I could think of more, would be great to add like 3 4K banks of ROM to XB ROMs and fix these problems, yet be backwards compatible.

  • Like 1
Link to comment
Share on other sites

I would rather discuss the ultimate programming language for TI development rather than the ultimate XB: Something that's simple to learn. Something that's designed from the onset to support SAMS memory. Something that's designed to be compilable into machine code. Something that people would want to use for writing new TI games and applications.

 

It could be based on the TI BASIC syntax, but I think it should also focus on clear, readable code rather than compactness. Integration with TI devices/DSRs would be essential. The ability to include libraries for other devices, e.g. F18A, or just for other functionality, would be great

 

The language could (and probably should) have a TI side interpreter, but if it was possible to compile to E/A#5 file on a PC in seconds and send it to the a TIPI or similar, how many of us would actually use the interpreter? On the PC side, however, we could run the program in an special emulator, interpreted or compiled with a source map, to allow easy debugging.

 

Well, this is just a fantasy thread, and I'm probably going to stick to assembly language, but I sometimes wonder if there could be an easier way...

  • Like 3
Link to comment
Share on other sites

I love forth, but it occupies the cart port. And I need access to that since I'm storing info in that spot on a SRAM.. but otherwise I'd be back in forth again, but currently I'm in assy, not having too much of a hard time, but still it's slow process of bug and debug. I'm not wanting to use classic 99 because I'm playing with real toggle switches to change Banks on real hardware, and classic as good as it is, requires you to have extensive knowledge of mouse clicks, keyboard shortcuts, drive info, other settings just before I can even start. It's full of bells and whistles, but going between two machines to try to get a task done is beyond what is like to put in. Of course put in what you want out...so when I use classic then I'm just getting info that my NanoPeb needs, like values, strings etc..

I'd wish for my birthday to get a forth OS Only computer. Ahhhh....looky  100 42 V! Just put an asterisk on the screen...KEY just started a kscan....

Link to comment
Share on other sites

I'm not sure, I learned a lot of turbo forth

( www.turboforth.net ), over a couple summers ago, there's still a lot I don't know, but only because the stuff I was dealing with didn't require it, like "case"

I don't know that one . Of course forth is just words and depending on that word it does or it requires something.

And you could actually create an OS with it because it reaches all or most all of the hardware. I just found it very powerful, you can see immediate results in the command line, or you can string along words in blocked screen sector location and load it with the load word, as in if I want my screen 5 to load, I'd say "5 LOAD" each block can contain 15 or 16 I forget, lines of 80 columns and each of your words are just seperated by a space. You define words and there are built in words. You get a vocabulary or make your own vocab. Fun stuff

Fast and no compile just enter word and press enter to see results.

Fun stuff

 

 

Edited by GDMike
  • Like 1
Link to comment
Share on other sites

4 minutes ago, GDMike said:

each block can contain 15 or 16 I forget, lines of 80 columns

 

A block traditionally has 16 lines of 64 characters for exactly 1 KiB (1024). However, that is not sacrosanct. It had more to do with convenience because, originally, blocks were stored directly to disk without the use of higher-level files. TI Forth is that way. I thought it was too dangerous, so wrote fbForth to be TI Forth that stores blocks in files. 

 

...lee

  • Thanks 1
Link to comment
Share on other sites

Happy New year Lee!!

Sorry I missed you earlier, but I just don't want to go any further until I acknowledged that to you. Hope all is well for you guys and a great 2020.

I'm having a blast at my E/A Notes program, and the fits it's giving me too.. comes with the territory I suppose.

But so far I've been able to figure things out for most of the week alone, by myself, my shadow..me..lol

 

Link to comment
Share on other sites

4 hours ago, Asmusr said:

I would rather discuss the ultimate programming language for TI development rather than the ultimate XB: Something that's simple to learn. Something that's designed from the onset to support SAMS memory. Something that's designed to be compilable into machine code. Something that people would want to use for writing new TI games and applications.

 

It could be based on the TI BASIC syntax, but I think it should also focus on clear, readable code rather than compactness. Integration with TI devices/DSRs would be essential. The ability to include libraries for other devices, e.g. F18A, or just for other functionality, would be great

 

The language could (and probably should) have a TI side interpreter, but if it was possible to compile to E/A#5 file on a PC in seconds and send it to the a TIPI or similar, how many of us would actually use the interpreter? On the PC side, however, we could run the program in an special emulator, interpreted or compiled with a source map, to allow easy debugging.

 

Well, this is just a fantasy thread, and I'm probably going to stick to assembly language, but I sometimes wonder if there could be an easier way...

so gcc?  all it needs is a sams library

 

Link to comment
Share on other sites

12 hours ago, Asmusr said:

I would rather discuss the ultimate programming language for TI development rather than the ultimate XB: Something that's simple to learn. Something that's designed from the onset to support SAMS memory. Something that's designed to be compilable into machine code. Something that people would want to use for writing new TI games and applications.

 

It could be based on the TI BASIC syntax, but I think it should also focus on clear, readable code rather than compactness. Integration with TI devices/DSRs would be essential. The ability to include libraries for other devices, e.g. F18A, or just for other functionality, would be great

 

The language could (and probably should) have a TI side interpreter, but if it was possible to compile to E/A#5 file on a PC in seconds and send it to the a TIPI or similar, how many of us would actually use the interpreter? On the PC side, however, we could run the program in an special emulator, interpreted or compiled with a source map, to allow easy debugging.

 

Well, this is just a fantasy thread, and I'm probably going to stick to assembly language, but I sometimes wonder if there could be an easier way...

Well XB is as simple to learn as you can get. It's already familiar to most TI users and it is quite a capable XB even without extensions, with it's major shortcoming being very slow execution speed, something Senior Falcon remedied with his XB compiler. We have over the recent years seen a renaissance of sorts with new XB programs coming out of the woodwork on almost a monthly basis, most compiled for speed and I highly doubt you are going to have a run of users trying to learn a new programming language on the TI no matter how good the specs are (think FbForth and TurboForth for example) because familiarity is comforting for many. It takes a concerted effort to learn a new language, and even longer to become proficient at it, and since the vast majority here already have years, if not decades, of experience with XB, it would be hard to put it down and go with something else. Take me for example: I know assembly, Forth and Pascal on the TI and have produced programs in all 3 languages, but nonetheless the majority of my projects remain in XB (or RXB) because it is comforting and so easy to work with, and I bet that feeling is shared by many users as well.

Therefore, what retroclouds is trying to do actually makes a lot more sense than coming up with an entirely new language. Don't get me wrong, your wish list is very appealing, but as you said, pie in the sky...

  • Like 2
Link to comment
Share on other sites

29 minutes ago, Vorticon said:

Well XB is as simple to learn as you can get. It's already familiar to most TI users and it is quite a capable XB even without extensions, with it's major shortcoming being very slow execution speed, something Senior Falcon remedied with his XB compiler. We have over the recent years seen a renaissance of sorts with new XB programs coming out of the woodwork on almost a monthly basis, most compiled for speed and I highly doubt you are going to have a run of users trying to learn a new programming language on the TI no matter how good the specs are (think FbForth and TurboForth for example) because familiarity is comforting for many. It takes a concerted effort to learn a new language, and even longer to become proficient at it, and since the vast majority here already have years, if not decades, of experience with XB, it would be hard to put it down and go with something else. Take me for example: I know assembly, Forth and Pascal on the TI and have produced programs in all 3 languages, but nonetheless the majority of my projects remain in XB (or RXB) because it is comforting and so easy to work with, and I bet that feeling is shared by many users as well.

Therefore, what retroclouds is trying to do actually makes a lot more sense than coming up with an entirely new language. Don't get me wrong, your wish list is very appealing, but as you said, pie in the sky...

Well I did suggest it could be based on the TI BASIC syntax.

Link to comment
Share on other sites

41 minutes ago, Vorticon said:

... I highly doubt you are going to have a run of users trying to learn a new programming language on the TI no matter how good the specs are (think FbForth and TurboForth for example) because familiarity is comforting for many.

Forth is not a good example when talking about ease of migration, since its concepts are radically different from BASIC programming. C is a lot closer to BASIC.

 

When c99 became available, I dropped both my Forth experiments as well as TurboPasc'99, and I never wrote longer BASIC programs anymore, so the languages (at the start of the 90s) that I used were Assembly language, C (c99 -> TIC), and Fortran (9640), the latter only for about four years as well.

 

Of course, everyone here has his own story, and as you see, YMMV. :)

  • Like 2
Link to comment
Share on other sites

15 hours ago, GDMike said:

I love forth, but it occupies the cart port. And I need access to that since I'm storing info in that spot on a SRAM.. but otherwise I'd be back in forth again

I know a guy who has a Forth that does not occupy the cart port ... :) 

  • Like 1
  • Haha 1
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...