Things that annoy me about the 99/4a

[+mizapf]

29 minutes ago, Retrospect said:

The hell were they thinking?  32 sprites addressable and that limitation!!!  

I only understood it when I learned how the VDP creates the raster screen. It is essentially lack of time.

[apersson850]

1 hour ago, RXB said:

Do you know exactly what the GROM chips do?

Yes.

It stores files that belongs to unit #14, called OS:. The files there, SYSTEM.PASCAL, SYSTEM.MISCINFO and SYSTEM.CHARAC contains the code in the operating system, information about how the system is set up (which key is used to do this and that, screen size and stuff) and the standard character definitions. The PME can run code directly from GROM, so there's no need to first load the code in SYSTEM.PASCAL into RAM to execute it. This is the main reason for the TI being able to run meaningful programs in spite of its small memory, as well as for the p-code card not being a cartridge.

The PME can also run code directly from VDP RAM, so when the p-system is running, there are two code pools. About 12 K in VDP RAM and a bit over 20 K in the 24 K RAM section, where it shares space with the stack and heap. The VDP RAM is the main code pool, to avoid having code competing with the stack for space, as long as the code fits in VDP RAM.

If you want to update something, you can store copies of these files on the system drive (unit #4:, or DSK1). If there are duplicates of the files there, the files on the disk is used instead. So by making a copy of SYSTEM.CHARAC and storing that one the diskette, you can modify that file and get true lower case letters as a standard font in the system, for example.

SYSTEM.PASCAL is a big file, but it's heavily segmented. If you want to do an update, you only need to store the updated segment in the SYSTEM.PASCAL file on the diskette. The rest of the segments will be accessed from the OS: drive on the card as usual.

 

These GROMs also contains a repository of assembly code, which is brought into RAM when the system is running. There are two sections. One is a startup segment, code which for example is stored in the screen memory when the system is starting and the 80-column simulated screen isn't used anyway, and another section which is loaded again into 8 K RAM prior to execution start of the p-system's interpreter (PME). This second section contains code that can't run from the p-code card, as it need to work even when the p-code card is disabled. Like to do IO, when the RS232 och disk controller cards are active instead, and to handle interrupts etc.

The PME instruction pointer table is also here, to make it possible to modify the PME by simply changing the pointers. So if you want to enable the p-code ATTACH (which does nothing on the 99/4A), you can write your own interpreter stub, place it somewhere you find suitable in memory and change the pointer for the ATTACH p-code to point to your own code.

Thus it's at least theoretically possible to modify the p-systems handling of memory management to include more modern and larger memory devices, even if it would be a pain to do it, as the source code isn't publicly available.

[+arcadeshopper]

1 hour ago, Retrospect said:

There's one more thing that annoys me about the 99/4a  ... well not the 99 specifically, but it's users.

 

Seems we can't have new side-scrolling shoot em up's without people saying "oh look, it's Parsec without the speech" ... more than once that type of comment was presented to me by people in the community when they saw videos of "Anubis" my new side scrolling shooter project.  It's been cancelled as a result because my understand is now this; we can't HAVE a new side-scrolling shoot em up , because ... well, Parsec, right????

 

Fuck my life.

 

 

 

NEVER make things for other people.. always make them because it is what you want to do..   I am always looking forward to anything you write dude.. and don't ever think it's not appreciated

[+arcadeshopper]

1 hour ago, RXB said:

Do you know exactly what the GROM chips do?

from thierry's page

TI-99/4A p-system implementation

The intrinsics of the p-system are described in another page. I have very few details on how the p-system is implemented on the TI-99/4A. Here is the little I know...

The GROMs hold unit #14, a.k.a. OS: They contain three files: SYSTEM.PASCAL which implements the main menu and some of its functions, SYSTEM.MISCINFO and SYSTEM.CHARAC which hold the default system parameters.

The ROMs must therefore contains the PME, the BIOS (together with the card DSRs) and possibly part of the OS. The second ROM page at >5000-5FFF contains some unit BIOS: console, RS232, TP, cassette, etc.

To speed up execution, part of the code used to interpret p-codes is copies into the 16-bit scratch-pad RAM (>8300 and up), but since that's only 256 bytes in size, not much can go there. The scratch-pad also holds several workspaces used by the p-system.

The heap is at the bottom of the high memory expansion, growing upwards. The stack grows downwards from the end of the high memory expansion. The internal code pool is placed in between them, but p-code programs can also be executed in several external code pools: in the VDP RAM or in GROMs (in the case of SYSTEM.PASCAL).

The low memory expansion is reserved for system use, upto >390C. I'm not sure whether the remainder of it could also be used as a code pool. A detailed description of its contents can be found on this file, once published by Anders Persson.

[matthew180]

2 hours ago, Retrospect said:

It is just a massive burden on my time , for something to end up being "like parsec without speech" ... the mentality of some , not all, of the TI community seems self destructive at best.

 

Seems to be a *thing* with the TI community, but really any long-lasting community will have similar traits I suspect.

 

2 hours ago, Retrospect said:

I aren't going to spend my time creating something that finishes up being compared negatively to a game that came out 40 years ago.

 

Ignore those people, or ask them "oh yeah, what did you make?"  It is a rhetorical question because most people don't make anything, they only consume and bitch.

 

As mentioned, do it because *YOU* want to and are having fun, and not for, or because of, anyone else.  This is a hobby, so find your fun and enjoy yourself.  The same thing happened with the F18A.  Some love it, some have written software to use features, some hate it, some will absolutely not write software for it, some are indifferent, some always compare it to the 9938 and state all the things the F18A can't do, etc..  I made the F18A because I dislike composite video and wanted nice crisp pixels, more colors, and hardware scrolling.  I try to make it available (when I can get parts) for others, but it does not bother me one way or another if someone does not want one.

 

I played Parsec BITD but not very long, it is very shallow and quick to grok.  Due to the way scrolling was done, the CPU cycles and memory to make a more in-depth game were burned, which is why I have a dislike of technical effects, for the sake of technical effects, in general.  They are good for a demoscene, but not much else.

 

Sadly, once people see something solved, like the way Parsec did the side scrolling on the 9918A, people think "well, that's the best you can do, 4 tile-lines, and not much CPU time for much else".

 

We now know that is not the case, and you can have full-screen scrolling *and* an interesting game.  If you find those kinds of technical challenges interesting and fun, I would encourage you to continue to explore that.  I like a good retro side scroller, bonus if it has some nice depth of play and randomness.  I would certainly enjoy watching the progress of your game, having conversations here on the forum about assembly language and the VDP, how to solve the various technical challenges, etc..

 

Enjoying yourself is the primary directive, but having a community to share with can be very rewarding.  Don't let a few random people ruin your fun, or the enjoyment for the rest of us in seeing and experiencing what you make.

 

2 hours ago, mizapf said:

2 hours ago, Retrospect said:

The hell were they thinking?  32 sprites addressable and that limitation!!!  

I only understood it when I learned how the VDP creates the raster screen. It is essentially lack of time.

 

Yes and no.  The way the 9918A was designed, yes, it is a function of time.  But it also has to do with money, i.e. TI being cheap even with the chip design.  There are video designs of the era that put more than 4 sprites on a scan line, which could have been incorporated into the 9918A.  Lots of coin-op games from the same time period do so with only TTL ICs, which map nicely into microcircuits.  The 9918A design also pays a heavy time-price for the flexibility in various VDP table's size and placement.

 

Removing the 4-sprite limit is one of the best features of the F18A, IMO, so please use that to your advantage and enjoy a slightly less annoying 99/4A.

 

[Tuxon86]

6 hours ago, Retrospect said:

There's one more thing that annoys me about the 99/4a  ... well not the 99 specifically, but it's users.

 

Seems we can't have new side-scrolling shoot em up's without people saying "oh look, it's Parsec without the speech" ... more than once that type of comment was presented to me by people in the community when they saw videos of "Anubis" my new side scrolling shooter project.  It's been cancelled as a result because my understand is now this; we can't HAVE a new side-scrolling shoot em up , because ... well, Parsec, right????

 

Fuck my life.

 

 

 

Yeah… I don’t understand that attitude either. On other contemporary platforms we had a plethora of similar titles and we never complained. This bitching is like saying there could only be one rock song or one red wine…

[Tuxon86]

5 hours ago, arcadeshopper said:

NEVER make things for other people.. always make them because it is what you want to do..   I am always looking forward to anything you write dude.. and don't ever think it's not appreciated

Especially on retro system… It’s a labor of love, you’ll hardly make a living out of it.

[Tuxon86]

2 hours ago, matthew180 said:

 

Seems to be a *thing* with the TI community, but really any long-lasting community will have similar traits I suspect.

 

 

Ignore those people, or ask them "oh yeah, what did you make?"  It is a rhetorical question because most people don't make anything, they only consume and bitch.

 

As mentioned, do it because *YOU* want to and are having fun, and not for, or because of, anyone else.  This is a hobby, so find your fun and enjoy yourself.  The same thing happened with the F18A.  Some love it, some have written software to use features, some hate it, some will absolutely not write software for it, some are indifferent, some always compare it to the 9938 and state all the things the F18A can't do, etc..  I made the F18A because I dislike composite video and wanted nice crisp pixels, more colors, and hardware scrolling.  I try to make it available (when I can get parts) for others, but it does not bother me one way or another if someone does not want one.

 

I played Parsec BITD but not very long, it is very shallow and quick to grok.  Due to the way scrolling was done, the CPU cycles and memory to make a more in-depth game were burned, which is why I have a dislike of technical effects, for the sake of technical effects, in general.  They are good for a demoscene, but not much else.

 

Sadly, once people see something solved, like the way Parsec did the side scrolling on the 9918A, people think "well, that's the best you can do, 4 tile-lines, and not much CPU time for much else".

 

We now know that is not the case, and you can have full-screen scrolling *and* an interesting game.  If you find those kinds of technical challenges interesting and fun, I would encourage you to continue to explore that.  I like a good retro side scroller, bonus if it has some nice depth of play and randomness.  I would certainly enjoy watching the progress of your game, having conversations here on the forum about assembly language and the VDP, how to solve the various technical challenges, etc..

 

Enjoying yourself is the primary directive, but having a community to share with can be very rewarding.  Don't let a few random people ruin your fun, or the enjoyment for the rest of us in seeing and experiencing what you make.

 

 

Yes and no.  The way the 9918A was designed, yes, it is a function of time.  But it also has to do with money, i.e. TI being cheap even with the chip design.  There are video designs of the era that put more than 4 sprites on a scan line, which could have been incorporated into the 9918A.  Lots of coin-op games from the same time period do so with only TTL ICs, which map nicely into microcircuits.  The 9918A design also pays a heavy time-price for the flexibility in various VDP table's size and placement.

 

Removing the 4-sprite limit is one of the best features of the F18A, IMO, so please use that to your advantage and enjoy a slightly less annoying 99/4A.

 

Can’t wait to get one when they’ll be available again. 

[+OLD CS1]

7 hours ago, Retrospect said:

They ALL got it wrong though - it was never gonna be Parsec, it was actually much much closer to Gradius.  Not that some of these eejits would know it.

Kind-of sums it all up.  Screw 'em.  You are creating something, they are neither your benefactors nor patrons, so you make what you want and what you like.  If they wanted something different, then they can make it, play something else, or just pound sand.

[Tuxon86]

Something has been nagging me since I’m in heavy research mode until my PEB and other accessory gets here… I’m reading that the TMS9900 can address 64k directly. I understand why TI went with that 16>8 architecture (except for the 16bit 256bytes), but even if it would sacrifice compatibility would there be a possibility to tap those cpu address lines directly and increase that 256bytes scratch pad?

 

what I mean is, keep the 16k 8bit vdp ram but instead of going thru the 8bit lanes for the rest of the ram, tie them directly to the 16bit tms9900 cpu. We could get a 16bit computer with 16bit main memory ram, but with a 16k 8bit gpu… 

 

It’s pure speculative fantasy, but I wonder if this would be possible.

[matthew180]

15 minutes ago, Tuxon86 said:

what I mean is, keep the 16k 8bit vdp ram but instead of going thru the 8bit lanes for the rest of the ram, tie them directly to the 16bit tms9900 cpu. We could get a 16bit computer with 16bit main memory ram, but with a 16k 8bit gpu… 

 

It’s pure speculative fantasy, but I wonder if this would be possible.

 

http://www.mainbyte.com/ti99/32K16/32k16.html

 

[pixelpedant]

12 hours ago, fabrice montupet said:

Time as passed, now nothing in the TI-99/4A annoys me, I ended to like its lacks and failures. However, if I had to mention one annoying point it should be the VDP 4 sprites per line limitation.

This is my outlook these days pretty much, likewise. 

 

Almost all of its limitations are just fun challenges now.  Not annoyances.  Even the four sprite limit is specifically necessary to a couple of tricks I'm fond of.  And even just the exercise of finding clever ways to work around the limit can be interesting, in the same way working around bitmap attribute clash can be. 

 

The one thing I would wish away, I suppose, is the SD disk controller as the de facto platform standard.  There's nothing interesting to me about 90K disks.  It's merely a tad annoying.  Legends can still do its thing on two disks instead of one.  But forcing users to swap (because targeting SD controllers was more or less necessary, under the circumstances) is just a minor aggravation, and is not actually technically interesting in any way. 

[JB]

1 hour ago, Tuxon86 said:

even if it would sacrifice compatibility would there be a possibility to tap those cpu address lines directly and increase that 256bytes scratch pad?

I swear I saw instructions to upgrade the 256 bytes into the full 1 kilobyte reserved in the memory map, but I can't find them anymore.

[Retrospect]

4 hours ago, matthew180 said:

Removing the 4-sprite limit is one of the best features of the F18A, IMO, so please use that to your advantage and enjoy a slightly less annoying 99/4A

Thankyou Matthew, and everyone else who spoke to me on this.  Without taking up too much of this thread , because it's gonna de-rail, I will give this another go and with the F18A in mind, kinda makes what I'm attempting a little easier and gives software to those who have an F18a.  Since I'm coding in XB256 and compiling, the benefit we're looking at is more than 4 sprites on a line.  I can finally do that thing I wanted to do with the Player Ship !!!    I am enthused again for the project.  I guess I had my head in my arse. 

[+OLD CS1]

2 hours ago, Retrospect said:

I am enthused again for the project.

Hell yeah, brother!

2 hours ago, Retrospect said:

it's gonna de-rail

Seems this is what we do around here

[apersson850]

8 hours ago, Tuxon86 said:

Something has been nagging me since I’m in heavy research mode until my PEB and other accessory gets here… I’m reading that the TMS9900 can address 64k directly. I understand why TI went with that 16>8 architecture (except for the 16bit 256bytes), but even if it would sacrifice compatibility would there be a possibility to tap those cpu address lines directly and increase that 256bytes scratch pad?

 

what I mean is, keep the 16k 8bit vdp ram but instead of going thru the 8bit lanes for the rest of the ram, tie them directly to the 16bit tms9900 cpu. We could get a 16bit computer with 16bit main memory ram, but with a 16k 8bit gpu… 

 

It’s pure speculative fantasy, but I wonder if this would be possible.

Yes, there are the solutions where you get 32 K RAM inside the console, on 16 bit bus. And then you can take it a bit further, get 64 K RAM inside, where 32 K is always the memory expansion (16 bit), and the other 32 K can be enabled to cover the remaining address space, if you want to. By disabling the internal 32 K RAM expansion you get access to the standard 32 K RAM on the outside (only 8 bit wide access, of course).

[Keatah]

The anti-hobbyist policy by TI (and TRS-80). I didn't know it at the time, I was just a dumbass pre-teen brat. But I always wondered why such a sleek-looking machine with a big-ass 64-pin CPU didn't have any software from Sirius or Br0derbund, Electronic Arts or Spinnaker..

 

For the short time I had a 99, I found myself becoming quite bored with it. And because of that I didn't put in time to learn the ins and outs. Anti-hobbyism at work!

 

Make no mistake. I didn't dislike the computer. Just that there were other forces conspiring against me. The aforementioned clampdown on 3rd party software. The fact I got it after I had an Apple II, Atari 800, and C64. I was backlogged in learning Atari & Commodore and their respective BASICs and DOSes. The 99 would have been 3rd in line. Time was such a limiting factor. Running the BBS, going to school, hosting videogame get-togethers. Doing model rockets and R/C cars. So yes, little time available.

 

And of course funds. I would have to buy hundreds more dollahz worth of peripherals. As you can surmise, the other micros I had had pretty much drained me. And I felt like I was reinventing the wheel when I started reading its manuals.

Edited November 2, 2022 by Keatah

[Arnuphis]

Can't really add much to the excellent posts but I will say this. The thing that annoyed me the most about the TI-99/4a was not the machine itself it was TI. For pulling out of the home computer market when they did. Here in the UK the machine became a top seller after the price cut and the unit + Yahtzee cart bundle was being sold. Loads of new users suddenly came on board. Momentum was growing. The TI-99/8 was coming and then boom. It was all over. 

[SteveB]

On 11/1/2022 at 5:36 PM, Retrospect said:

Seems we can't have new side-scrolling shoot em up's without people saying "oh look, it's Parsec without the speech" ...

So we did intuitively the right thing ... and straight wrote another Parsec (without speech!) ... 

 

But it makes me feel sad when good ideas get cancelled because of unqualified discouraging comments. To make make qualified discouraging comments you have to have at least one serious game released in this decade ... 😜

 

I am waiting on your next project to be released.

[Retrospect]

1 hour ago, SteveB said:

and straight wrote another Parsec

With flying toasters among other enemy's , I mean, yours was good!  I love Parsec,  and feel if I ever did try to ret-con it or sequel it I'd better nail it and nail it good.

So I'm doing it in the style of different shoot-em-ups, namely Gradius. 

[Tursi]

Lack of third party support was big for me too.

 

I had a different post here, but it was covered better by others. So I'm just fronting now

 

Edited November 2, 2022 by Tursi

[Tuxon86]

2 hours ago, Tursi said:

Lack of third party support was big for me too.

 

I had a different post here, but it was covered better by others. So I'm just fronting now

 

I don’t really know how it was back then since I didn’t own a 99/4a, but didn’t the lack of 3rd party nudge many people and user groups toward creating their own programs. Even to these days, you’ve people who are actively invested learning and programming on the 99, where most other retro computers are about watching demos and playing tunes… I see something similar with the Color Computer, where it’s more about mastering the platform than just loading a game from a sd card for nostalgia sakes. 
 

Take me for exemple. I never owned a Ti while growing up. I did see it on display at the electronic kiosk at the mall and thought it was the most impressive system with its PEB, monitor and printer but I couldn’t afford it. Now decades later I can! Not to play games, I’ve a nice Launchbox setup for those. No, I want to learn assembly on the thing. I also want to give Forth and XB (and derivative) a shot. Heck if I ever get my hand on a UCSD P-Code card, I’ll give Pascal a shot (Pascal was my first language in college).

[Tursi]

4 hours ago, Tuxon86 said:

I don’t really know how it was back then since I didn’t own a 99/4a, but didn’t the lack of 3rd party nudge many people and user groups toward creating their own programs. Even to these days, you’ve people who are actively invested learning and programming on the 99, where most other retro computers are about watching demos and playing tunes… I see something similar with the Color Computer, where it’s more about mastering the platform than just loading a game from a sd card for nostalgia sakes. 

Unfortunately, not really. On a stock system you were limited to TI BASIC - no sprites, poor performance. There were a lot of TI BASIC games, but let's face it. Very few were very satisfying.

 

To get a system that could create assembly language software cost 3-4 times what most of the other systems did. If you bought a Vic-20, you could create anything. If you bought a C64, you could create anything. If you bought a BBC, you could create anything. If you bought a Timex/Sinclair, well, you could at least try, but you probably wanted the 16k memory pack.

 

But on the TI, to get out of TI BASIC, you needed memory expansion, a disk drive, and Editor/Assembler. You could get by with memory expansion and Extended BASIC. (Eventually there was also MiniMemory, which was a cheap way to get into it, but not everyone HAD a mini memory to share your software.) Most of the time, memory expansion also meant getting a PEB.

 

I know a number of friends who wrote software back in the day who said they wanted to get into the TI, but they just couldn't justify the cost of all the add-ons needed to get started.

 

[apersson850]

Still those who "only" wanted Extended BASIC with memory expansion or assembly language had it easier than me, who wanted Pascal...

[Tuxon86]

36 minutes ago, apersson850 said:

Still those who "only" wanted Extended BASIC with memory expansion or assembly language had it easier than me, who wanted Pascal...

Since most of the software I ever owned back then was pirated copy without documentation, I had a hard time trying to learn to code in anything beside Basic and assembler on the C64 and Atari. I did get a version of Pascal for the C64 but never used it since I didn't have any books on it at the time while just about every magazine had a Basic or Assembler tutorial/section.

 

I did buy the Atari Editor/Assembler, one of the few original I had.