Jump to content
IGNORED

Guru input needed on possible development path idea


Omega-TI

Recommended Posts

Things appear a little slow this morning, so I figured I'd drop this idea in your laps for discussion....

 

Since the advent of the F18A in the past, there was some ‘talk’ about a Contiki-type GUI for the TI, but memory, and the TI’s architecture was one of the a limiting factors. Lately though, I’ve been thinking that all the technology has come ‘into place’ that could enable a viable work-around.

 

The idea, an Uber Cart based GUI/OS for the TI-99/4A based around a ‘control program/module’.

 

This first program/module would basically be a blank screen, similar to the desktop in Windows with the framework to access the rest of the modules. This modules function would be to load the other program blocks residing in the Uber Cartridge (as needed) or other programs from disk. The size of this program block would remain as small as possible to facilitate the other future ‘Windows-type’ modules memory requirements. It would also load standard programs as needed as THE CARTRIDGE WILL ALWAYS BOOT OR RETURN TO THIS MODULE on startup or exiting from a standard program.

 

On execution this module will check the bit status of the ‘desktop’ and if absent will load the user’s custom ‘desktop’ preferences from diskette and put them into the 15K GRAM area of the Uber Cart as this area of the cartridge can be manipulated. If no preference file is resident on the diskette, the program will detect the error and automatically jump to another ‘invisible module’ in the cartridge that will create one with the basics like garbage can and directory icons then re-load the first block.

 

Now there is one drawback, every time the user changes something on the ‘desktop’ they would have to save their changes to disk or they would be lost during a power cycle. This could be done immediately, or with a Windows-type shutdown button. (Nothing is perfect).

 

Having all the support modules/programs in the Uber Cart for individual functions might get around the current memory limitations; but it would also be blindingly fast as it would all appear to be one program.

 

So what do you TI-Gurus think?

Link to comment
Share on other sites

I'm not a TI expert so someone else may know something I don't, so keep that in mind.

Do you want something like the Amiga, OS-9 Desktop, Deskmate, GEM, or the Apple GUI?

The AmigaOS could load applications without loading workbench, so having a blank screen of some sort isn't totally out of line. However, that screen will require some sort of system structures so you can open windows on it.
Needing to save changes to the Amiga desktop such as icon positions required you snapshot the current window layout to keep the changes so that's not unusual.
GEM and Deskmate just build directories and such on the fly, they don't need saved data. You can change how to sort directories.

 

You're biggest issues will be hardware.
I really think you need to have at least 16K of fixed RAM for applications and GUI data if not 24K, plus you need to page 8K for your GUI APIs.

Edited by JamesD
Link to comment
Share on other sites

I'm sure it's perfectly possible to create a windowing environment for the TI, and I wouldn't worry too much about where you store which data and all that, those are decidedly solvable problems. I think the biggest challenge is that you need to create a whole new application environment for developers to target, and you'd need to create an enticing enough environment so that developers are willing to create these modules you're looking for. Think about how many different entirely new programs that aren't games that come out for the TI every year, then imagine how many years it would take for there to be enough of those applications to make that environment you're envisioning more useful than something like BOOT or any other menu program... I don't think we'll live to see the day and I might be one of the younger guys on here ;).

 

On the other hand, if you can take an existing OS with existing programs and enable those on the TI, that's a different story. You would immediately have a useful environment with useful applications. Unfortunately, I think that porting an existing OS is much harder than what you're proposing.

Link to comment
Share on other sites

In terms of OS API, you could take an "If you build it they will come" approach. If the environment is compelling enough, developers may start showing up with some useful applications.

 

The only drawback I see to a new OS/OE, including my dream of porting an existing OS/OE, is applications would have to compete with existing programs in the native environment, and both the new OE and the application would have to be very compelling, offering some feature set or ease-of-use not otherwise available.

Link to comment
Share on other sites

Just remember that someone is working on a GUI for the Atari and they are getting to the point where someone could develop some apps for it.
And what are the proposed apps so far?
Pretty much stuff that already exists but uses the GUI for it's user interface.
Unless it brings something new to the machine it's pretty much just bragging rights.
OS-9 had a GUI and that got used by an handful of applications.

Link to comment
Share on other sites

... both the new OE and the application would have to be very compelling, offering some feature set or ease-of-use not otherwise available.

 

Agreed...

How about... DRAGGING & DROPPING of files from the PC via the HDX to any DSK1, DSK2 or DSK3, or any other connected storage device? I've seen requests for that feature from others in the past.

 

Granted, something like this would not pop into existence over night and and it might just be used as a fancy loader for standard programs at first. BUT THAT WOULD CHANGE.

 

I think this could invigorate the hobby and trickle across all of the TI user-base. Obviously the programmers would have fun, doing something that's never been done before while showing off their skills. User's would have fun with the new software, the excitement would probably bring in more new and past users as well. The hardware guys could get in on the action by designing and building a new mouse interface or potentially other things to support the new environment. The sellers would even have more business. Everyone would win. If things remain stagnant eventually interest will wane and when that goes... :(

 

I've seen the awesomeness Gazoo has managed to extract from the Uber Cart, I've seen the programming skills, of Tursi, Insane Multitasker, Senior Falcon, Rasmus and so many others. I believe it IS possible and a route that opens up so many other possibilities.

It all comes down to vision, interest and time...

Link to comment
Share on other sites

 

You're biggest issues will be hardware.

I really think you need to have at least 16K of fixed RAM for applications and GUI data if not 24K, plus you need to page 8K for your GUI APIs.

 

About that, a while back Gazoo did a trick with XB2.7S and an Editor/Assembler cartridge that had the GROM chip removed. I'm wondering, could that same method be implemented with both cartridges fully active at the same time for access to the 8K of a SUper Carts RAM? There are different ways it could be done, modifying a widget, making a special PCB that would hold two cartridges, or possibly even soldering an 8K kit directly onto the cartridge connector in the TI. Just an idea...

Link to comment
Share on other sites

Unless you want a stand-alone application, the best bet would be extensible file system handlers and device drivers which would almost require multi-tasking or a good interrupt system (Theirry's site discusses context switching and the possibility of multi-tasking on the TI.)

 

But what I am thinking more-so with the TI is an interface layer to the DSRs. That way, you could access an HDX: device through an application or by issuing a command like

 

PIP HDX:=A:FILE.EXT

Link to comment
Share on other sites

  • 2 years later...

This thread was PRE-TIPI, and while it would be cheating (not totally TI), it's now possible to do so much of this VIA TELNET with a program that accesses files via URI1. Using a 4A/DOS batch file on bootup, a whole world of stuff could be at our fingertips in mere seconds.

Link to comment
Share on other sites

Another thought has been floating around my brain lately that would utilize the TIPI and the F18A... a windows-like environment.

 

The main program, loaded using the "URI1." method over the network would be an 80 column display backdrop which would utilize other 'modules', all residing on the server, so no additional cartridges would be necessary. The modules could be anything really, some examples could be a calculator, email client, word processor, scheduler etc. TIPI also has mouse capability, so that could also be part of the windows like environment. Naturally all personal data would be stored on the SD card of the TIPI owner locally.

 

For example to load it all, a person would need to do is run "URI1.GUI" and be off to the races. Heck from my auto-loading 4A/DOS I could run a batch file to automatically run it on boot up!

 

Just an idea...

Link to comment
Share on other sites

I have a hard time imagining the 99/4A running an OS. You might get more participation if you describe what this OS would do, exactly. Provide the desired feature set without specifying particular hardware requirements, i.e. like that it should/count run from GROM or such things. Keep in mind that an OS should make the developer's life easier and typically provides a consistent interface to the hardware. But on limited classic computers, those needs do not exist like they do on bigger more recent computers. The OS should also not take away available resources from the software being written. The 99/4A is already limited enough, and having an OS sitting there taking up RAM does not seem like it is helping anything. Just my thoughts.

  • Like 1
Link to comment
Share on other sites

Ok here is 99% of the problem with a drag and drop on TI99/4A.

 

1. To little VDP memory to make any decent type of interface that would mimic even simple Black and White

Apple first GUI on Macintosh. (We need minimum 512K of VDP to even begin to make a decent version)

 

2. Best approach is a re-programmable EPROM with multiple banks of ROM 0, or use ROM 0 modified,

and GROM 0 1 and 2 to make a TI99/4A GUI interfaces this would be better backwards compatibility.

 

3. Of course now we need more RAM so the SAMS is the only real solution here.

Link to comment
Share on other sites

I have a hard time imagining the 99/4A running an OS. You might get more participation if you describe what this OS would do, exactly. Provide the desired feature set without specifying particular hardware requirements, i.e. like that it should/count run from GROM or such things. Keep in mind that an OS should make the developer's life easier and typically provides a consistent interface to the hardware. But on limited classic computers, those needs do not exist like they do on bigger more recent computers. The OS should also not take away available resources from the software being written. The 99/4A is already limited enough, and having an OS sitting there taking up RAM does not seem like it is helping anything. Just my thoughts.

 

I agree, that the TI is 'memory constrained' which is why I was thinking along the lines of a variant of the << CONTIKI METHOD >> for the C64, as they mentioned the exact same 'memory constrained' terminology in the WIKI article. That scheme could be further be expanded upon by using up to 1 meg of memory in the FG99 I suppose through GROM based bank switching of specific modules as needed. To futher alliviate memory constraints, processing with some programs could be done on the server end, depending upon how certian applications were written. I figured if they could pull it off on the C64, why not the TI? Of course I could very well be wrong.

 

What I envision is an environment that others, if they so choose could write applications for, which could theoretically give us a decade of 'new things' for our aging system, while keeping excitement levels up over the long term. In any event, combining the resources of the F18A, TIPI, RPi and FinalGROM I figured something new was possible.

 

As for hardware requirements and implementation, that would be better served by you 'big guns' who know way more than me. ;-) After Fest West and hearing how much of the TIPI's chess programs processing is done on the back end it made we wonder.

 

Where something like this could take us is a great unknown, and part of the fun, at least in my eyes. In the end, you guys know better than I.

Link to comment
Share on other sites

For me the way to go on the TI-99/4a would be to do something like tmux on linux.

I really got to appreciate tmux as a screen multiplexer at work and would work nice on the TI in 80 columns mode or 40 columns mode. It can run full screen, handle panes, etc.

So i am toying with the idea to make something along the lines.

  • Like 2
Link to comment
Share on other sites

I imagine an interface like Turbo Vision would be possible on the F18A with GPU routines to draw windows and TIPI mouse support. This could be used to build a series of applications including a file browser/manager/launcher and a text editor that would all be launched from the same base window.

  • Like 2
Link to comment
Share on other sites

Without a 9938 or 9958 chip that has the extra VDP memory available to pull this off a Disk version would be insanely slow and sluggish.

 

Also even though the F18 is a great product it sucks at memory size and graphics are limited to TEXT and damn few pixel count.

 

The 9938 and 9958 had 512 x 424 pixels, every pixel could could be 1 of 256 colors, not like 9918 has 256 x 212 and 1 of 16 colors.

 

This means you could have (4) four 9918 screens that would fit into (1) one 9938 or 9958 screen and have 256 colors to top it off.

 

Also a AUTOBOOT is built into GROM:

 

Link to comment
Share on other sites

  • 1 month later...

Without a 9938 or 9958 chip that has the extra VDP memory available to pull this off a Disk version would be insanely slow and sluggish.

 

Could be, but there are other hardware devices which are much faster than the standard disk drive, UberGROM or FinalGROM cartridges come to mind as does teaming them with a SAMS card.. that could help with the speed issues... a little bit.

 

Also even though the F18 is a great product it sucks at memory size and graphics are limited to TEXT and damn few pixel count.

 

Nothing is perfect for a one-size-fits-all anything. I'm happy with it though, it still beats the heck out of the standard 9918, if only for the RGB output, the extras are simply icing on the cake.

 

The 9938 and 9958 had 512 x 424 pixels, every pixel could could be 1 of 256 colors, not like 9918 has 256 x 212 and 1 of 16 colors.

 

The potential capabilities are superior, no doubt, but, as has been depressingly pointed out to me on numerous occasions, "Who's going to write anything for it?"

 

This means you could have (4) four 9918 screens that would fit into (1) one 9938 or 9958 screen and have 256 colors to top it off.

 

Sure, it would be nice, and I've always liked new toys, but I'm getting pragmatic about 'new' or 'newly re-made' hardware that exceeds the capabilities of the machine itself. Also, IF the hardware was available in a year or two, I'd wonder how much longer I'd have to wait for any new software in a time frame that would allow me to enjoy it. From now on I plan to take a wait and see approach about things.

 

Also a AUTOBOOT is built into GROM:

 

Yup! I decided (that for me) it was best to take the initiative to adopt & tweak WHAT WAS CURRENTLY AVAILABLE to best fit my needs. With a little bit of help from Tursi, a decades old dream of mine came true and I'm now using an auto-booting GROM cartridge for a DOS environment. It's fast, functional and awesome combined with the F18 & TIPI.

  • Like 1
Link to comment
Share on other sites

 

Agreed...

How about... DRAGGING & DROPPING of files from the PC via the HDX to any DSK1, DSK2 or DSK3, or any other connected storage device? I've seen requests for that feature from others in the past.

 

Granted, something like this would not pop into existence over night and and it might just be used as a fancy loader for standard programs at first. BUT THAT WOULD CHANGE.

 

I think this could invigorate the hobby and trickle across all of the TI user-base. Obviously the programmers would have fun, doing something that's never been done before while showing off their skills. User's would have fun with the new software, the excitement would probably bring in more new and past users as well. The hardware guys could get in on the action by designing and building a new mouse interface or potentially other things to support the new environment. The sellers would even have more business. Everyone would win. If things remain stagnant eventually interest will wane and when that goes... :(

 

I've seen the awesomeness Gazoo has managed to extract from the Uber Cart, I've seen the programming skills, of Tursi, Insane Multitasker, Senior Falcon, Rasmus and so many others. I believe it IS possible and a route that opens up so many other possibilities.

It all comes down to vision, interest and time...

I actually have some GPL code for that Drag and Drop OS on a notepad I worked on for 2 months on a shelf behind me.

It used the Joystick as a control and like a Mac only had one mouse button (FIRE) to CLICK or HOLD DOWN (Double Click).

 

RXB 2012 included a XB program called DM that was a preview of what I was doing.

 

All my RXB demo DM would do was protect, copy or rename or delete files or Directories on Hard drives or floppies.

 

Using GPL & Joystick would make the mouse (sprite) as fast as most games you could drag and drop files.

(It turned the 10 character filenames into sprites to be dragged or dropped.)

 

Could be speeded up using Assembly embedded into GPL like my RXB does now in several routines.

Link to comment
Share on other sites

I saw development on a GUI for the 99/4A 20+ years (or so) ago at a Fest West event (Very Foggy Memory). I want to say it was in Utah (Or Phoenix?). A young African American man had written it and displayed an Alpha copy. It worked off of a floppy and worked like Funnelweb in some ways, but was a GUI with icons. Using an rs232 mouse he could click on an icon and the program would run. It was a mind bender at the time. I never saw it before that meeting, or after. The idea is sound, it's the limitations of the hardware that have always gotten in the way. I'd love to see it, but it would have to be very light. It's beyond anything I could code. I'm only good for a Halloween Basic program to run on a monitor, put in the window, to entertain kids walking up.

  • Like 1
Link to comment
Share on other sites

I was at Utah and remember him.

His biggest problem as a real lack of memory to get it to work as he was loading off DF80 files a lot.

 

I remember suggesting AMS (SAMS Card) to him as a fix.....so where did he go?

Link to comment
Share on other sites

I'm pretty sure a GUI doesn't need to require any more RAM than any other display does. The TI can't do hardware windowing so you don't need to store hidden window data in VRAM (ie: there is no advantage to doing so, at least outside of the F18A or 9958).

 

Windows 3.1 actually quite elegantly solved the "where do we store hidden window data?" with the answer "literally nowhere". When a window that was previously covered is revealed (or any part of it is), the application responsible for it is sent a "PAINT" message, and redraws the now-visible area in an application specific way. This is probably the simplest way for the OS to deal with it (although it pushes the complexity to the app, many apps just redraw their whole display). Modern Windows still does this - although now you can ask the OS to save the hidden bitmap for you in some cases. ;)

 

Now, running multiple programs simultaneously on the TI does become a memory issue - they have to go somewhere. (And running legacy programs that directly access hardware would range from difficult to impossible without hardware mods. But you could define an API that allowed new software to play nice.) SAMS would be the best answer here IMO simply because it's the fastest memory expansion and more available today than the expanded VDPs.

 

However, a "shell" which simply enumerates drives and lets you launch a program -- MENU does everything there except draw icons for the programs. I don't think that drawing those icons would take that much more RAM! :) Of course, I still have to actually code it. ;)

  • Like 1
Link to comment
Share on other sites

Also even though the F18 is a great product it sucks at memory size and graphics are limited to TEXT and damn few pixel count.

The 9938 and 9958 had 512 x 424 pixels, every pixel could could be 1 of 256 colors, not like 9918 has 256 x 212 and 1 of 16 colors.

The F18A is an enhanced 9918A, after all, and not a 9938 or 9958, but it's a little more than you give it credit for.

 

Graphics are 256x192, yes, but the color palette is 4096 colors (also there's a palette now) with 64 colors onscreen in most modes. The 80 column text mode offers 480x192 pixels and both color and sprites are available (although I don't think anyone's tried to see what kind of pictures that can produce ;) ). Layers are available with multiple graphic planes and a dedicated bitmapped overlay layer that can be any size.

 

A 9900-compatible GPU running at 100MHz is built-in and has full access to the hardware functions of the VDP, as well as an extra 2k of dedicated program RAM. This can be used as a co-processor, or a graphical enhancer. For instance, with GPU software loaded all 4096 colors can be displayed on screen, and there are sample images from my converter scattered around the forum, and I've also demonstrated a fractal generator running under it. Rasmus has put the enhanced feature set to far greater (and more practical) use in his games.

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