What really makes TI EX-BASIC slow?

[RXB]

I've thought about this before, so now is a good time to ask.....

If you can have 48k with out banking, does that mean you can do 48k bank switching and if so can you do that as a sidecart like the couple that do exist?

 

Yes and no. The cartridge port is mapped in at $6000 to $7000, so any side cart trying to repond to RAM / ROM in that range would conflict with any cartridge plugged in to the console. Well, not *any* cartridge technically, but probably 99% of them. GROM only carts would not conflict. You can bank switch the 32K though, and some people have modified their consoles internally to bank switch the whole 64K address range. But only software they write themselves will take advantage of that, so you are limited to new development only, thus it is hard to justify doing such a project other than for yourself, because you want to.

 

Seems like if sidecarts could have access 48k at once then someone would be able to make anygame that the MSX series runs. They all just need more memory cause they all run in full bitmap mode.

 

Not really. You have to qualify which MSX you are talking about. MSX1 or MSX2? The MSX1 used the 9918A, thus the graphics are the same as for the 99/4A, CV, etc. and are tile based. The MSX2 had the 9938 which has the true bitmap modes and onboard GPU to do block moves and such, which is the only way to make dealing with a bitmap display possible on a system like that (or on the 99/4A). The CPU simply can't push enough data fast enough to support a real bitmap without the GPU commands in the 9938 and later. The amount of CPU RAM available is irrelavant and would not help. Also, the 9938 had at least 128K available to support those bitmaps, extra graphic information, etc. and the 99/4A does not have that amount of VRAM available. CPU RAM does nothing for the VDP.

 

However, for the MSX1 games, the main thing holding anyone back is simply motivation. Pick an MSX1 game and start porting, it should be very viable.

 

I think you ment that the GPL GROM is mapped from >6000 to >7FFF as this is the first bank of GROM for XB and most other carts.

 

And they are 40K not 32K boundaries. The hardware of carts are not like GRAM as Hardware is 6K boundaries while GRAM devices are 8K boundaries.

Everyone thinks 6K as this was the hardware of the Carts but Miller Graphics always used 8K boundries in hardware as NO ONE MAKES 6 K CHIPS except TI.

 

There is a command in GPL to bank switch directly from one bank to the address in another bank. SWGR GADD would look at DATA at GADD variable and go to that bank by DATA >980C,>6010

 

So this would go from whatever bank you are in running GPL to page >980C and run address >6010

[mnbvcxz]

The idea of a dedicated GPL processor is interesting. How would that have interfaced with the 9900 or the original CPU meant for the 99/4? Some kind of processor trap?

 

I read that interview and I thought he was saying the engineers wanted TI to design a processor that ran GPL as its machine code, this processor would have replaced the 9900 in the 99/4B, but management chose not to develop such a chip.

[mnbvcxz]

CRU I/O is slow and stops the processor from accessing memory during CRU operations, anyone know how much this impacts on performance?

[Tursi]

CRU I/O is slow and stops the processor from accessing memory during CRU operations, anyone know how much this impacts on performance?

 

According to the datasheet, it's comparable in time to a normal memory access. But instead of accessing 16-bits of memory, you only get 1 bit of CRU. That's why it's slower.

[mnbvcxz]

CRU I/O is slow and stops the processor from accessing memory during CRU operations, anyone know how much this impacts on performance?

 

According to the datasheet, it's comparable in time to a normal memory access. But instead of accessing 16-bits of memory, you only get 1 bit of CRU. That's why it's slower.

 

If you want to transfer 16bits, it takes 16 times as long as a memory mapped port which is why I think it is slow, now many I/O ports may not require high speed so slow I/O is acceptable, but it stops the processor from executing the main program which must slow things down.