Things that annoy me about the 99/4a

[hwrd]

On 11/1/2022 at 2:30 PM, Retrospect said:

THIS !  ^^^

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

I always thought that the '32 sprites addressable' was to help programmers.

Other systems have similar arrangements (newer, with higher numbers).

[Tuxon86]

3 hours ago, hwrd said:

I always thought that the '32 sprites addressable' was to help programmers.

Other systems have similar arrangements (newer, with higher numbers).

Bt the limit of four on a scan line isn't helpful to the programmers...

[apersson850]

As said above, it was a performance limitation with the chosen hardware architecture.

[hwrd]

8 hours ago, Tuxon86 said:

Bt the limit of four on a scan line isn't helpful to the programmers...

I see what you are saying, but what I understood was "4 sprites per line" is the fact of the matter in terms of the hardware,

and the 32 sprites addressable is the programming aid.

 

Hope that helps. 🙂

[WhataKowinkydink]

Guess I'll throw my two cents into the fray here.

Why in the world did TI not take the opportunity to *really* fix the 99/4 when they re-released it?  Give it 32k as standard (not as dedicated video RAM), implement an appropriately sized bus, and ... dare I say ... get rid of GPL.

[Tursi]

16 minutes ago, WhataKowinkydink said:

Why in the world did TI not take the opportunity to *really* fix the 99/4 when they re-released it?  Give it 32k as standard (not as dedicated video RAM), implement an appropriately sized bus, and ... dare I say ... get rid of GPL.

Cost. It was already too expensive, and 32k of RAM was a significant expense in 1980/1981. Per https://jcmit.net/memoryprice.htm, 32k of RAM would be $150-$200 (doesn't say whether DRAM or SRAM, but I guess by the time you add the DRAM refresh it's a wash). When the C64 released with 64k in 1982, we're down to about $110 for 64k. Per https://ourworldindata.org/grapher/historical-cost-of-computer-memory-and-storage?time=1979..1982&country=~OWID_WRL, the average price of RAM dropped to less then half between 1981 and 1982. Between 1979 and 1981, RAM only dropped by about 1/3rd, so they simply may not have been looking forward enough. The console design suggests they were thinking ahead, but not always about the right things.

 

That covers RAM. Implement at 16-bit bus? Well... I'm actually kind of on board with you here. The VDP, ROM and console RAM are already on the 16-bit bus, no reason the sound chip couldn't be the same way. There's nothing else inside the console that needs to be 8 bit. But I think they'd still have to have kept the multiplexer and timing to keep the side port peripherals compatible, so there was no cost incentive to do it.

Getting rid of GPL would have been a long term operation that would have invalidated all the cartridge software already released, and required a full rewrite of the console OS and TI BASIC. The OS side is simple enough, but there's no way they'd want to rewrite BASIC and do all the re-testing needed for what was intended as a refresh of the console, not a new console. That's all what the 99/8 would have been for.

My biggest frustration, personally, is that I wish the sprite flicker only applied to scanlines that actually have pattern. Lots of tricks we could have done to get around the 4-sprites-per-line limitation. BUT, it's a silly wish because the way the sprites are selected makes it just as impossible as adding more sprites per line was - it doesn't have time to fetch sprite pattern data for every sprite in the list every scanline.

 

[RXB]

11 hours ago, WhataKowinkydink said:

Guess I'll throw my two cents into the fray here.

Why in the world did TI not take the opportunity to *really* fix the 99/4 when they re-released it?  Give it 32k as standard (not as dedicated video RAM), implement an appropriately sized bus, and ... dare I say ... get rid of GPL.

LOL The TI99/4A would not even boot without GPL!

Where do you think the Menu to Carts comes from? (GPL does that!)

Where do you think the carts majority of them get the program from? (GPL does that!)

GPL is not the problem it is the hardware design that is the real problem.

Hardware sets the speed of how fast GPL operates and it could be as fast as Forth if the hardware was better designed.

 

[DavidC]

The biggest annoyance to me was the lack of Sprites with TI BASIC.  Back then the Extended Basic cart was simply too expensive for a 14 year old kid. My Dad bought me the computer for $49.99 and I was lucky and happy to have that. So all I could do was dream about the mystical magical Sprites and drool over the possibilities that I read about in magazines.  Plus, (not TI's fault in any way) NONE of my friends had TI's.  They had Atari 800's or Commodore 64's. I was alone in my struggle.  By the time I found another TI'er, I was well into High School and had other interests. My TI-99/4a sat, neglected and forgotten about for the next few decades.  Until I discovered AtariAge!   

[Reciprocating Bill]

I've been able to mitigate most of what annoys me:

 

- Color fringing (mitigated by F18a)

- CPU RAM on 8-bit bus, wait states: (32k 16-bit RAM in console)

- Noisy PEB fan (replaced with quiet fan)

- CPU RAM limited to 32K (Supercart adds 8K.) 

- Slow BASICs (Cortex BASIC is very fast, for a BASIC)

- Console coffee warmer (installed small fan under power supply board)

 

NOT mitigated: the crazy number of fragile connections in my config:  SD card to SD caddy, SD caddy to FG cartridge, FG cartridge to console L-connector, console L connector to logic board, logic board to speech synth through side port, speech synth to Fire Hose connector, Fire hose card to PEB. It's a miracle it works at all, much less reliably. But mostly it does.

 

 

[+dhe]

Since this topic has drifted a bit anyway. GPL - did TI write any of it's arcade games in GPL? The source code for Invaders and Parsec and Tomb Stone City are all in assembly. And sometimes the GROM's just held assembly or basic code, like good little storage devices. Back in the early day's of owning a 4a, I always equated a GROM with GPL code.

[HOME AUTOMATION]

I've seen these in arcades:

 

CAR WARS
HUSTLE
THE ATTACK

 

These appear to be GPL, based as well:

 

CONNECT FOUR
MIND CHALLENGERS
HUNT THE WUMPUS

[RXB]

7 hours ago, Reciprocating Bill said:

I've been able to mitigate most of what annoys me:

 

- Color fringing (mitigated by F18a)

- CPU RAM on 8-bit bus, wait states: (32k 16-bit RAM in console)

- Noisy PEB fan (replaced with quiet fan)

- CPU RAM limited to 32K (Supercart adds 8K.) 

- Slow BASICs (Cortex BASIC is very fast, for a BASIC)

- Console coffee warmer (installed small fan under power supply board)

 

NOT mitigated: the crazy number of fragile connections in my config:  SD card to SD caddy, SD caddy to FG cartridge, FG cartridge to console L-connector, console L connector to logic board, logic board to speech synth through side port, speech synth to Fire Hose connector, Fire hose card to PEB. It's a miracle it works at all, much less reliably. But mostly it does.

 

 

SAMS makes 8K super cart look really lame. 32K vs 1 meg of memory?

Or 32Meg of memory in Classic99 or Mess. And the hardware for 32meg is available soon.

RXB has speeded up XB a lot. Like CALL HCHAR in RXB is 9 times faster then any other XB made.

Also replacements for PRINT and DISPLAY AT assembly versions in CALL HPUT and CALL CLEAR

Not to mention SCROLL routines in assembly in any direction like CALL SCROLLUP(repetion,string or number)

 

So I have taken the challenge of making XB that can run from Console only at assembly speeds WITHOUT 32K EXPANSION!

[Reciprocating Bill]

49 minutes ago, RXB said:

SAMS makes 8K super cart look really lame. 32K vs 1 meg of memory?

But SAMS and 16-bit memory can't coexist, unfortunately, and I like the speed boost afforded by the latter. It mitigates a major annoyance vis the 99/4a's design. 

 

Meanwhile, my assembly tinkerings don't often bump against memory limits. But nice to know the option is there. 

 

Having made that choice, the Supercart does provide a bit more elbow room. 

[RXB]

12 minutes ago, Reciprocating Bill said:

But SAMS and 16-bit memory can't coexist, unfortunately, and I like the speed boost afforded by the latter. It mitigates a major annoyance vis the 99/4a's design. 

 

Meanwhile, my assembly tinkerings don't often bump against memory limits. But nice to know the option is there. 

 

Having made that choice, the Supercart does provide a bit more elbow room. 

Loading files to make up for lack of memory is how other consoles beat the TI99/4A to death.

More memory is always a solution. 

Does you PC or Mac still have under 640K of memory?

Yea if is fun to be limited, I for one make RXB and designed to run from Console only and have Assembly built into routines using only Scratch Pad is like a art form.

But I also realistically support SAMS as a option as it is a predictable future that allows for support of huge programs instead of loading files over and over from disk.

[Reciprocating Bill]

Different smokes for different blokes. It's all good.

 

[Tursi]

On 11/5/2022 at 2:10 PM, Reciprocating Bill said:

But SAMS and 16-bit memory can't coexist, unfortunately, and I like the speed boost afforded by the latter. It mitigates a major annoyance vis the 99/4a's design. 

It's definitely possible, just that nobody has built it. There's nothing in the mapper connection that can't work inside the console.

[apersson850]

I don't have SAMS, and I don't remember exactly how it works. I can of course find out by reading various things here, but I'm too lazy. Does SAMS page into a certain part of the memory expansion? All of it, or just a piece? How big? 8K, 4K or what?

[+Lee Stewart]

3 hours ago, apersson850 said:

I don't have SAMS, and I don't remember exactly how it works. I can of course find out by reading various things here, but I'm too lazy. Does SAMS page into a certain part of the memory expansion? All of it, or just a piece? How big? 8K, 4K or what?

 

Thierry’s site has a detailed SAMS section you might find useful. Basically, SAMS uses all of the memory expansion and maps 4KiB pages via 8 of 16 possible registers located on the card at >4000, >4002, ..., >401E, corresponding to 4KiB blocks of RAM at >0000, >1000, ..., >F000, respectively. Only registers mapping to the 32KiB expansion are relevant. In transparent mode (as at SAMS card power-up), SAMS page 2 is mapped to >2000, page 3 to >3000, page >A to >A000, ..., page >F to >F000. Mapping can be changed in mapping mode by writing the desired page number to the relevant register, with the page-number bytes reversed.

 

...lee

[Switch1995]

At the bottom of Thierry's page he mentions:

 

Brad Snyder created "XBpacker", an utility that allows to store several Extended Basic programs in the SuperAMS card, or even one huge XB program written in a modular fashion.

 

Is there a thread on XBpacker?  This is exactly what I've been interested in doing with the SAMS.  Thanks!

[apersson850]

1 hour ago, Lee Stewart said:

Only registers mapping to the 32KiB expansion are relevant.

So with an internal memory expansion like the one I designed for myself, you could use SAMS and the speedup from internal 16-bit memory at the same time. My internal expansion design does implement 32 Kbytes of RAM internally, but it can be disabled 8 K at a time by dedicated CRU bits. If you disable it, the console will instead access RAM in the expansion box, if there is any. I can also enable RAM in the other 8 K segments, so I get RAM over the monitor ROM, cartridge space etc.

Anyway, with my design you can run programs in the 24 K section in 16-bit RAM, but turn it off so SAMS will "shine through" in the 8 K section. Or any other combination you like.

[Switch1995]

2 hours ago, Switch1995 said:

At the bottom of Thierry's page he mentions:

 

Brad Snyder created "XBpacker", an utility that allows to store several Extended Basic programs in the SuperAMS card, or even one huge XB program written in a modular fashion.

 

Is there a thread on XBpacker?  This is exactly what I've been interested in doing with the SAMS.  Thanks!

Found it.

[Reciprocating Bill]

2 hours ago, apersson850 said:

Anyway, with my design you can run programs in the 24 K section in 16-bit RAM, but turn it off so SAMS will "shine through" in the 8 K section. Or any other combination you like.

Is your design published? I've always found your description intriguing, but have never seen specifics.

[apersson850]

Yes, I've published it here. But I can do it again.

The documentation I have is of the first iteration, where all of the 32 K internal RAM is switched out at the same time. Only the other RAM blocks, overlaying the rest of the addressable area, are switchable 8 K at a time. I realized later that I should have made it as I described above, where also the 32 K RAM could be switched 8 K at a time. My actual computer is modified, but that was done out of memory, so to speak, so I don't have that as neatly documented.

 

In this album, there area some 99/4A related images, including of the schematics. U002 implements 8 CRU bits. By not using Q5 to turn on hardware VDP wait (to allow code that doesn't have a NOP in the right place to still run from fast RAM), then instead the 8 bits can be used to turn on one memory block at a time. It took three more inverters, since the signals to U003 have to be individual to D1, D5, D6 and D7. But U004 disappears instead, and as far as I can remember, then three gates became available on U010, so I think I used them. The part list claims it's a NOR-gate chip, but the drawing says NAND. Hmm. Too long time ago to remember. Probably have to open it up to check! 😃

The CRU bits are at >400.

 

[GDMike]

3 hours ago, apersson850 said:

Yes, I've published it here. But I can do it again.

The documentation I have is of the first iteration, where all of the 32 K internal RAM is switched out at the same time. Only the other RAM blocks, overlaying the rest of the addressable area, are switchable 8 K at a time. I realized later that I should have made it as I described above, where also the 32 K RAM could be switched 8 K at a time. My actual computer is modified, but that was done out of memory, so to speak, so I don't have that as neatly documented.

 

In this album, there area some 99/4A related images, including of the schematics. U002 implements 8 CRU bits. By not using Q5 to turn on hardware VDP wait (to allow code that doesn't have a NOP in the right place to still run from fast RAM), then instead the 8 bits can be used to turn on one memory block at a time. It took three more inverters, since the signals to U003 have to be individual to D1, D5, D6 and D7. But U004 disappears instead, and as far as I can remember, then three gates became available on U010, so I think I used them. The part list claims it's a NOR-gate chip, but the drawing says NAND. Hmm. Too long time ago to remember. Probably have to open it up to check! 😃

The CRU bits are at >400.

 

Such brilliant work ☺️

[cbmeeks]

If the TI had fixed all of these issues, we wouldn't have a computer to bitch about 40 years later!   LMAO.

 

But seriously, I don't know of any one mass produced computer that had so many bone-head moves as the TI.  For me, all of these (and the fact it was my first computer) is exactly why I love the thing.  There must be something great about it if we're still using it all of these years later.

 

When I think back to my 9 year old self using a computer for the very first time, I didn't know what a sprite was.  I never could figure out how games moved stuff around but all I could do is cheesy char drawing.  But if you twist my arm, I would say these would be my biggest gripes of the TI:

 

1)  TI Extended BASIC should have been standard and built in.

 

2)  A user port like the C64 and perhaps a decent serial port fast enough to drive a good floppy drive. 

 

3)  A "cheapish" floppy drive.

 

4)  32KiB of RAM standard (in addition to the 16 KiB for VDP)