apersson850

When you do have the memory expansion together with XB, then 24 K RAM segment will be used for code lines and numeric variables. The rest, like the symbol table, string variables, line number table, return stack and scratch pad for string manipulations etc. is still in VDP RAM. You also have disk I/O buffering there. The scratch pad employs garbage collection, so it will eventually use all available VDP RAM, then collect the unused garbage and start over again. Hence there's not really any corner of VDP RAM it will not touch, when it has been running for a while. The 8 K RAM part of the expansion is reserved for assembly language support for XB.

In my independent multi tasking scheduler (not when using the p-system), I used the TMS 9901 as the timer to invoke the scheduler. But since I have a console with 64 K RAM internally, I can overlay console ROM when I want to. Thus I can change the interrupt vector in the system to point to my own interrupt service routine. That allows me to create the most efficient task scheduler possible, since the TMS 9901 hardware will do the counting and the interrupt will invoke the scheduler when it triggers. Then it's just the standard issue of keeping track of running and waiting tasks. In the p-system I used a different trick. Since the interrupt service routine there partially runs in RAM, you can easily modify it. The p-system is also cartridge independent, since the p-system operating system is on a card in the PEB, not in a cartridge in the cartridge slot. Thus you can for example plug in Mini Memory when running the p-system. So I inserted a wedge in the standard interrupt service in RAM, went to a routine in Mini Memory and then returned to the standard interrupt service. The part in the Mini Memory RAM does the task switching. There are also some support routines to implement monitors and some other stuff, that's convenient to have in a pre-emptive multitasking system.

Well, here's something to look at. Internal 64 K RAM memory expansion, CRU I/O bank enabling and VDP access delay logic. Load interrupt and reset switches also included. https://goo.gl/photos/do8zDtjpNnr7Z1ca8 Peripheral expansion box with real time clock and digital/analog I/O board. Later, cards with real time clock, like CorComp's Triple Tech, became available, but there was nothing to buy when I built my clock card. https://goo.gl/photos/op1NZnKRfvuu86dJ6 Analog joystick with buttons, 7-segment digits and LED. It's not a modification of the 99/4A itself, but connects to it. Inside there's a dual port 4*4 bit memory, which holds the numbers to show on the display, LED status and controllable leading zero ripple blanking for the display. This is accessed by a four bit data bus, two bit address bus and one WE signal from the computer. The rest of the wires are for power supply and analog signals from the joystick. The electronics inside the joystick are built on three separate PCBs, stacked on top of each other. https://goo.gl/photos/huz7Y2Gqfwus7m2m6

You have understood that Extended BASIC can't run at the same time as the screen is in Bitmap mode, right? XB uses a lot of VDP RAM resources for it's own stuff, even if you have the 32 K RAM expansion in place. The disk drive system also uses VDP RAM for buffering data being read or written. It's possible to start XB, run an assembly program which uses bit map mode and die from there. When you want to start XB, run assembly with bit map mode and then return to XB, you must make sure you save the XB environment in VDP RAM before start fiddling with creating the bit map mode. Otherwise you can't return. Since bit map mode requires approx. 12 K bytes in VDP RAM, it's quite a lot of data to hide elsewhere. In a system like mine, which has 96 K RAM instead of 32 K, that's not a problem, but it is in a standard 99/4A. You can dump it as memory images to files on disk, but you have to do that while you are still in the standard graphics mode, or you'll literally see the disk file system working on the screen.

No, because to keep the internal structure of memory accesses with the TMS 9900 as simple as possible, memory access is done the same for byte and word operands. So there's a read before write for word operands too. This is the reason for the TI 99/4A never having autoincrementing memory mapped I/O at the same address for reading as for writing. The TMS 9995 also has internal memory on a 16-bit bus. This is equivalent to the RAM pad in the 99/4A. The internal memory is typically used for workspace and other frequently used parts of code and data.

Yes. You assign a register as a stack pointer. I usually use R10, and that's also what the PME uses.

No, it's more a question about that since an unexpanded TI 99/4A has almost nothing else but video memory. Hence almost everything that takes place goes through video memory. This includes the memory image transfer function, which is used for the Run program file option (#5) in E/A, to load and save BASIC programs and several other stuff.

It's not the crystal itself that's interesting, it's how the CPU runs internally. The 99/4A has a 48 MHz crystal inside for the CPU, but that's just to be able to generate all the phases of the main 3 MHz clock.

The TMS 99105 has stack support. So has for example the TI 990/12 minicomputer. When I wrote TMS 99000 it was in a generic sense, since I didn't remember the detailed differences between the different introduced and planned versions of the TMS 99000 CPU.

You can define an alternate character set that's inverted. But there's not space to do that for all possible characters within the X-BASIC environment. Nor can you use bit map mode with BASIC, as you get a video memory conflict. A loader that loads relocatable code can be anywhere, since per definition the code it's loading can be anywhere. But most larger programs are converted to memory images, which must load at a certain memory location. The machine's support for loading memory images requires them to go to a buffer in VDP RAM, which is so large that you can't have bit map mode enabled when doing that. Not unless you don't care you'll literally see the file being loaded. But once the file is loaded, you can check in the file where it's supposed to go in memory. If the file is on disk, you can do a sector read of the beginning of the file, and find out where it should be loaded. If you write your own loader, you can then read and load one sector at a time, instead of one up to 8 K byte memory image at a time. Regarding the flipping cursor, you are right in your assumptions.

True. One reason for the higher efficiency of the TMS 9995 is that it has one stage instruction pipelining. If I remember correctly, it also gets away with the read before write memory access implementation. It's not necessary with a byte-addressable CPU with a byte wide data bus. But it is on a byte-addressable CPU with word wide bus.

The TMS 9900 CPU implements the multi-chip CPU from the TI 990/9 minicomputer on one chip. Almost. It has a separate clock chip. The TI 990/4 and TI 990/5 minicomputers were actually driven by the TMS 9900 CPU. The larger TI 990/10 and the TI 990/12 had more advanced CPU designs, more similar to the later TMS 99000 series of microprocessors. When TI designed the TMS 9900, at a time when most other LSI manufacturers were starting to consider 8 bit designs, chip technology was such that fast memory designs were capable of following logic circuits in speed. Thus they gained flexibility without really sacrificing anything. But already by the time the TMS 9900 ended up in the TI 99/4A, this had started to change. Although there's no dedicated stack pointer in the TMS 9900 (there is in the TMS 99000), there is autoincrement. So although a PUSH must be implemented by DECT SP MOV Rx,*SP you can do a POP by simply MOV *SP+,Rx I've implemented pre-emptive multitasking within the p-system, and as a separate assembly thing on the TI 99/4A. As you state here, the TMS 9900 is efficient for this. But in the p-system case, you have to keep within the constraints of the PME, as it's supposed to work on Pascal level as well.

Things are generally different when running Extended BASIC. Back when I did, I used a DSRLNK that was a bit different compared to the one TI recommends in the E/A documentation. The one I used works regardless of whether the DSR is written in assembly language or in GPL. That has the advantage that you can store a memory image in a file in exactly the same way regardless of whether it ends up on disk or cassette. This may not be an issue today, but I wrote some software that was intended to be used as subprograms for Extended BASIC, and could work also with systems having only 32 K RAM expansion but no disk system. If you want to do something that requires learning quite a bit of the internal working of the computer, and Extended BASIC, but still is a project of limited size, you could write a program that makes the cursor in Extended BASIC flash not between the character it's covering and a black block, but between the character it's covering and that character inverted in a black block. Flipping the cursor like this could be enabled by CALL LINK("FLIP") and disabled by CALL LINK("NOFLIP"). This is a good educational exercise, because it's not trivial but still rather small in size.

Well, I've installed 64 K RAM expansion inside the console. All on 16 bit wide bus, the fastest the TMS 9900 can utilize. Normally, only 32 K RAM is seen by the CPU, but it's possible to enabled the other 32 K RAM too, 8 K at a time, to overlay internal addresses like operating system, DSR space, cartridge port and I/O ports. Enabling all gives a contiguous 64 K RAM, but then you can't access VDP, sound etcetera without disabling RAM covering addresses 8000H-9FFFH while doing so. It's also possible to disable the 32 K RAM part which acts like the normal memory expansion. When doing that, the normal memory expansion, if present, is instead visible, so it's possible to have two separate 32 K RAM expansions present at the same time, but available for use one at a time. All this switching between different memory blocks is done with I/O bits (CRU), which means it's all under software control.

I was quite heavily involved in the user's group Programbiten in Sweden for some years. The group no longer exists.

I once created a program to compute dimensions of piping for evacuation systems used to extract for example saw dust from saw mills. It ran on the 99/4A and was used professionally by a company selling such systems. It was later ported to PC platform, running under DOS. It can still run as a console application in a command window under Windows XP. We called the program DUSTBUSTER. What else?

Of course you can do things with less hardware than all that stuff that goes into the expansion box. But since I had a box handy, I didn't see any reason.

It could depend on how you express them, perhaps... There were several things that TI had to consider. Memory space limited to 64 Kbytes, without additional mapping registers. The 990 was a pretty early 16-bit architecture, when memory was expensive. The TMS 9900 integrated the architecture on a chip, so kept this limitation. But TI wanted working RAM, cartridge slot, operating system, expansion devices and internal I/O, like sound and video. All these competed about the memory space. Then they also wanted a comprehensive BASIC, with several features inspired by the BASIC running on the TI 990. To squeeze all that in, they got the idea to make byte-serial memory (GROM), which stored instructions in a special language (GPL), which was more compact than the native instruction set for the TI 990. A great deal of the operating system ROM in the console was then used to interpret this GPL language, something which added to the time needed to execute the programs. As I've shown earlier, in another post here, even the simplest interpreter typically has a speed penalty of seven times or so, compared to native code. Since GROM are 8-bit devices, and the VDP as well, cost could be saved by using a scaled down CPU. The TMS 9980 was developed as a TMS 9900 inernally, but with 8-bit wide data bus externally, as well as an internal oscillator. The TMS 9940 is a TMS 9980 with the addition of 8 K ROM and 256 bytes of RAM inside the chip. This is exactly the configuration of the 99/4A console, and perhaps the CPU they were really considering. But it didn't get ready in time, so they had to use the TMS 9900 instead, and do the memory and 8-bit multiplexing externally. There they ended up with an architecture which could handle quite a lot of memory, but at the cost of slower execution. In applications with a lot of user interfacing, it doesn't matter so much, since the user is comparatively slow anyway. Educational use must have been a tempting market, pretty new and well suited to the architecture. Games could be handled by having 8 K ROM space in the cartridges, if assembly language was needed, and otherwise everything could run from GPL. The problem turned out to be that few outside TI wanted to write games for it, since it couldn't run assembly programs without additional memory. If the console had been like mine, which is modified to have 64 Kbytes of RAM in addition to the 16 Kbytes video RAM, then amazing games could have been written by anyone, for the 99/4A. They could even have been loaded from cassette, if you were patient enough to let them load. BASIC became slow due to the design considerations regarding memory use. With an expanded machine, you could run a better Pascal than Apple had, but not enough people wanted to invest in that, when they could keep up with the Jones'es and buy their kids a cheap VIC-20, to make sure they had a computer too. Most of them didn't know what to use the computer for anyway.

Many years ago (around 1985), I made an elevator out of Lego (toy construction kit). The motor as well as same lamps and buttons at the different floors were connected to the PIO port through some extra electronics. This interface made the port 8 bits out and 8 bits in at the same time, instead of an 8-bit bidirectional port. Then a Pascal program, running different concurrent processes for handling user interface and motor control, was operating the lift. The multitasking program was supported by my own multitasking support core, which I developed as an add-on to the p-system.

I'm sorry, I just realized I've already mentioned this once in this thread. Please disregard. I've done this, more or less, since by now I think you need to consider a computer which runs Windows XP as "vintage". The reason for it was that I printed files to the Toshiba netbook computer (running HyperTerminal to collect the files), then printed them from there to the printer, which required a Windows driver (or similar) to work. My old impact printer works, but the ink band are dried up. I've also done this at work. Not with vintage computers, but with more or less vintage machine control systems, which didn't support Ethernet or something like that. I had to use RS232, so I made up a protocol similar to what's normally used for CAN-bus networks, and exchanged information that way between two different machines. Exactly that same protocol could be applied to a 99/4A without any issues.

I've considered making an interface for the TI 99/4A, where it would simulate a storage device, so the CC-40 could use the 99/4A as kind of a file server. But I've never really taken the time to start analyzing if it's feasible.

You better behave, or I'll show you a picture of the other one too. It looks the same...

I doubt I have a cut list for the traces, but I do have some schematics, somewhere. Meanwhile, the last three pictures in this album shows the internal modification. Only the last one also contains the VDP access wait state logic. As you can see I never made any PCB, but the modification is completely self-contained inside the original metallic screen inside the 99/4A. Thus you could for example run assembly programs without the PEB, if you loaded from cassette. Like you could with Mini Memory, but here you could also have Extended BASIC plugged in, for example. I did a demo of Forth on a seemingly unexpanded console, with cassette tape recorder connected only, at a meeting in Sweden once. To begin with, I installed the modification with one single bit toggling all 32 K RAM expansion, and individual bits toggling the other 8 K sections. But I realized that it was smarter to be able to handle the 8 K RAM and the 24 K RAM expansion areas (2000H-3FFFH and A000H-FFFFH) separately, so I modified the logic to Control them by two different bits. Since I also need a bit for the VDP wait state generation control, and I have eight bits in my latch, I couldn't spend one bit per 8 K memory bank. But usually it makes sense to consider the 24 K RAM part as one single section anyway. Forgive me if I have made some error. I did this modification in the 1980's. Together with the 56 K Maximem universal module, this additional 64 K RAM memory and some memory on my additional home made wire wrap PEB cards, I simulate a RAM-disk for the p-system. I remember that compiling a Pascal program was done in about half the time when the compiler was in RAM all the time, due to the extensive segmentation of that program. Later additional memory devices with a lot more memory has been designed, but 176 K RAM was quite a lot in 1985. The fact that my design co-exists with the standard 32 K RAM expansion made a difference. I used 400H as the base address for the CRU bits used to swap in/out RAM segments.

Now I don't have the schematics in front of me, but the principle is to fiddle with the chip select lines. Since all memory is connected to the same data bus, the chips that actually are active are selected. The other chips go to tri-state output level. What I did was to add to the chip select decoding, to involve also a CRU bit for each bank. At power up, chip select goes to ROM, expansion cards, cartridge memory, ports and the new internal 16-bit wide memory expansion. But setting the appropriate CRU bit, I can modify chip select to go to new RAM instead of ROM, cartridge space etc. Setting an appropriate bit also disables the new 16-bit wide RAM expansion and instead brings in the standard, 8-bit wide memory expansion, if available. Thus I have two 32 K RAM expansions in the machine at the same time, one fast 16-bit internal for normal use and one slower 8-bit wide, that can be used for buffers in assembly programs, emulate a RAM disk or whatever you need. Or you can load a program there, if it relies on timing with normal memory to run properly. Since the TI frequently use writing to ROM areas for memory mapped ports, bank switching and similar, I didn't implement write through, though. To efficiently copy ROM to RAM, I can do like this: Enable RAM at 4000H. Copy 8 K from 0000H to 4000H. Enable RAM at 0000H. Copy 8 K from 4000H to 0000H. Disable RAM at 4000H (to free up DSR access again). Now the operating system at 0000H is in RAM, and can be modified as you like. I also added some hardware which causes a one cylce wait state when accessing the VDP. That too is controlled with a CRU bit, since it's not needed for software which does have that extra NOP which is recommended by TI. But in some cases, with normal memory expansion, such a NOP isn't needed. Thus some programs don't have it, but then fails when you run from faster memory.

This is of course one reason for that I, when I made my 32 K RAM internal 16-bit memory expansion also allowed it to overlap all other memory in the machine. Thus I can copy console ROM to RAM, switch to RAM and change the vectors as I like.