I was asked a STUPID TI-99/4A related question today...

[Tursi]

23 hours ago, HOME AUTOMATION said:

@Tursi, Sic 'em!?

http://harmlesslion.com/temp/TI_vids/

 

I don't have most of them uploaded cause they keep getting hit for copyright strikes, but any of these will play in Classic99 or on hardware if you can get a large enough cart.

 

[Tursi]

21 hours ago, wierd_w said:

Depends on how you decide to go about it.  Take for instance, Tursi's video solution (as found in Dragon's Lair). You just need to get char data in fast enough to handle the mode-switching magic's requirements.  If you were to abuse the SPDIF interface to just blast in digital level data, and get it right from the CRU bus, you could conceivably get it in fast enough to satisfy the requirements.

The problem with the CRU bus is that it's really slow. For a full duration memory access, you get 1 bit of data. You can get 16 bits of data in the same time on the memory bus. I was reading an interview with some guy from TI who was looking back and admitting it was a bad idea.

 

What we /really/ needed was for TI to route the CPU DMA control out to the side port instead of tying it high (or low, whichever disables it). We could then have an external bus master manage the bus.

 

But even there we are limited - the sound chip takes as long as it takes to receive a single byte of audio control, and the VDP is easily overrun with little more speed than the 9900 already produces. The only way to get much better VDP, barring a new breakthrough, is a better VDP or DMA to VRAM. Personally I really wish we had an expansion concept like the NES, which puts the VDP memory bus on the cart port - so mappers in cartridges can do all kinds of fancy video tricks in real time.

 

My video conversion script runs video and audio at 8.6458 frames per second (that's what it converts it to, anyway, and it does it's best to play back at that rate). A frame is 1544 bytes of audio (really nibbles, but stored as bytes for performance) and 6144 bytes of video (50:50 pattern and color), so that's just shy of 65k/second (and uses 1/2 the video bitmap).

 

[HOME AUTOMATION]

...

Edited January 28, 2021 by HOME AUTOMATION

[HOME AUTOMATION]

2 hours ago, DuaneAL said:

If there are no stupid questions, what do stupid people ask?

 What makes you so smart?

 

Do you think animals have feelings??

 

 Which supermarket do you do your shopping at??

 

Do you think there will be any looting?????????

 

Do you think the bar-chart should go vertically or horizontally?↕️↔️

 

Should I turn off the cooling pumps, to keep the reactor from going solid?☢️

[wierd_w]

2 hours ago, HOME AUTOMATION said:

 What makes you so smart?

 

Do you think animals have feelings??

 

 Which supermarket do you do your shopping at??

 

Do you think there will be any looting?????????

 

Do you think the bar-chart should go vertically or horizontally?↕️↔️

 

Should I turn off the cooling pumps, to keep the reactor from going solid?☢️

Smartass mode ENGAGED!

 

No idea, why? Looking to improve?

 

Of course they do. They (typical vertebrate animals people think of, discounting things like mollusks, bugs, et al that are most certainly not vertebrate animals) have fully developed limbic systems. There is no conceivable reason why they would not have feelings.

 

Mostly walmart, due to convenience. However, I DO grow my own produce each year...

Probably not. At least, not at the one I shop at.  It has a very low patron rate, and is very uncrowded. The community it is in is likewise, very quiet.

Silly plebian, a quality chart is information dense, and easy to read. A scatter plot with BOTH axes is the proper response!

 

Turning off the coolant pumps on a fission reactor is pretty much universally a "Bad Idea". 

[+FarmerPotato]

12 hours ago, Tursi said:

The problem with the CRU bus is that it's really slow. For a full duration memory access, you get 1 bit of data. You can get 16 bits of data in the same time on the memory bus. I was reading an interview with some guy from TI who was looking back and admitting it was a bad idea.

 

There are crazy long-distance daisy chains of CRU lines in the 990s, going across multiple chassis! (where it is branded TILINE). I don't get why serializing the data gave any electrical advantage, when the address was still parallel. 

 

I like how TI did make CRU parallel in the 99000.

 

It's closer to the 8086. So a 16-bit LDCR/STCR in the >8000 address range uses the whole data bus, not just one bit.  It then works like IO ports on the 8080 or Z80, for 8 or 16 bit I/O, in a separate address space. You would use LDCR instead of MOVB to write to the VDP (you can even use the conventional address of 8C00 in CRU space, happily)

 

[+Vorticon]

On 1/27/2021 at 10:08 PM, DuaneAL said:

If there are no stupid questions, what do stupid people ask?

They ask questions commensurate with their level of education and critical thinking. When these criteria are at a minimum and a question is asked, the most productive response is a factual one framed within the perceived cognitive and educational level of the asker with the hope that it will help enhance their knowledge even if minimally, and if repeated enough times, will actually have a measurable positive effect. The worst response is the condescending and dismissive one which brings nothing to the table and results in a resentful or perhaps humiliated asker who will resort to entrenchment as a protective measure.

You DID ask the question, right?

[Omega-TI]

Honestly, I think many people now days confuse ignorance with stupidity.  Ignorance is simply the lack of knowledge, and I guarantee EVERYONE is ignorant about something, but that does not make them stupid.  Only the arrogant and others like those with personality disorders look down on others due to their perceived superiority or inflated self-worth.  I agree condescension and dismissiveness adds nothing positive to the mix, other than allowing others to learn more about the personality/nature of those exhibiting the anti-social behaviors.

[oddemann]

My thinking...

Ask so that you get to the smart questions as quick as possible :p - Now... I ask much smarter TI questions :p hehehehe

[+DuaneAL]

14 hours ago, Vorticon said:

You DID ask the question, right?

Yeah, but I stupidly thought it was funny.  Looks like I went too far.  I’ll try to be better in the future.

[wierd_w]

If you really need 8 bits wide, simply for the speeds needed...  A stripped down 8bit PATA would work..  It would just be un-fun to implement.

 

 

As for a potentially dumb question...

 

We don't have a DMA mechanism, but I remember reading that when the GROM is accessed, it needs to assert the GREADY line before the CPU can/will respond.  This means the CPU is in a state that is actively ignoring the data bus. (and possibly the address bus? At least, part of the address bus?)

 

If we implemented a circuit that is accessed like a GROM (done blindly, since we will be abusing GREADY to keep the 990 CPU in a bus-ignoring state while we do the fun stuff), we can catch the GROM access as the mechanism to initiate the DMA operation, then assert GREADY when done, and return a status byte from the GROM read, indicating an operation status. (Success, Failure, and lots of reserved)

 

Since the sideport has MEMEN and pals, we should be able to grab the memory bus away from the 990 and do the reads/writes, while the CPU is waiting for GREADY.  (At least, the significant bits of the address bus not utilized by the GROMBASE)

 

Is this just idle silliness, or would that be actually doable?

 

It would DEFINITELY be doable, if we abstracted the 32k memory area behind a gatekeeper circuit controlled with the fake GROM circuit. (because then we could unlatch the memory, fiddle with it without raising lines that go to the 990, latch it back, and then raise GREADY)

 

[Yes, I realize this would not be any at all useful for the VDP's memory. You would need a circuit sitting underneath the VDP, to catch all its accesses, similar to I think, how the mechatronic 80col card did things]

Edited January 30, 2021 by wierd_w

[Stuart]

Unfortunately the processor is still driving the address bus, and driving or reading the data bus, while waiting for GREADY.

[wierd_w]

OK, then one would need to latch the whole damn sidebus, and route the VDP socket out the side, like the mechatronic card, implement a replacement 16k VDP memory on the card, and THEN use a microcontroller to handle the DMA operation(s)

 

(eg, unlatch both data and address buses, bankswap or DMA VDP memory by having raw access to it, since it was moved outside "the mechatronics way" with a ribbon cable, and accomplish that by being the very first card on the sidebus.  32k or SAMS lives right after it, and any CRU bit jiggling, et al, to manage the SAMS with the DMA would be done by the microcontroller on the card, while the TI waits for GREADY)

 

If the GROM-acting circuit operates like a GRAM, the byte written could be used to issue one of 256 'instructions' to the microcontroller, and thus enable control over the fake DMA. It could return a status byte about any bank switched states, if last operation succeeded, et al, when read.

 

Then, as far as the 990 is concerned, "nothing happened", and any changes are "magic".

 

 

[Tursi]

1 hour ago, wierd_w said:

If the GROM-acting circuit operates like a GRAM, the byte written could be used to issue one of 256 'instructions' to the microcontroller, and thus enable control over the fake DMA. It could return a status byte about any bank switched states, if last operation succeeded, et al, when read.

GROM is just like any other memory from the CPU's point of view, it just holds READY inactive longer. There's some circuitry on the board to only gate READY from the GROMs to the CPU during a GROM access (necessary because GROMs are "not ready" in their idle state, it's more of a "data available" line), but there's otherwise nothing there you can't do with any other memory. (The sound chip also holds READY inactive while its working on a write, as does the speech synthesizer).

 

If you were going to start patching up the board, you could untie !HOLD - that's the true DMA request pin which makes the 9900 let go of the bus. It's tied high, but you could untie it and then real DMA is potentially possible. (There's a HOLDA output as well, that tells you when the 9900 has acknowledged the request and gotten out of the way).

 

Unfortunately, I think this will only work on the 16-bit side of the bus, since the multiplexer circuit doesn't have any concept of getting out of the way either. It's even possible that it will interfere, since the control lines will go floating, which it doesn't expect. (But we have so many pull ups and pull downs already, who knows! )

 

[wierd_w]

The really cool shit would come from being able to bankswitch pages of memory between the VDP's pool, and the 32k area pool.

 

EG, if that memory was dolled out from a single physical source, and just allocated to a specific pool by some circuitry that could be reconfigured on the fly.  (eg, a 16kb window into the larger RAM area, is the "VDP Window" that we give to the VDP, while the SAMS memory gets 4 such windows of 8k size, but ultimately it is the SAME memory, physically. This would enable the DMA controller to write directly on VDP memory, behind the VDP's back-- or just switch out the whole region really fast while the next page of VDP memory is being worked on, etc)

 

I would think your video solution would get a tremendous boost from having memory get scribbled on by an outside controller (memory is not owned by VDP yet), then the VDP updated wholesale 16kb at a whack with a page flip.

 

You could only really do that if you routed the VDP socket outside the system, and did not connect the socket's RAM leads to the memory on the motherboard. (instead, satisfying it with your bank switcher, from the switchable pool)

Edited January 30, 2021 by wierd_w

[Tursi]

Agreed! The ability to directly access video RAM would open a lot of options. It was one of my early "wouldn't it be cool if?" sketches.