apersson850

That's one of many reasons for why I used Pascal almost always, instead of Extended BASIC.

When a key on my beige boards stop working, it's usually the key itself. Hammering on it frantically restores functionality.

I don't know what you mean about deliberately crippling something? What is crippled? Which microcomputer? The 99/4A? Yes, that's "crippled", partially because it was actually a 16-bit CPU with an 8-bit data bus that was supposed to be there, but it didn't get ready in time. Then if GPL is "crippling" or "saving ROM space" can be argued.

Yes, the compatibility issue isn't due to lacking the concept of tracks. Tracks are only meaningful if you want to store unformatted data. The only use of that I've seen on the TI is for copy protection.

The CorComp controller is quite similar to the TI original one, but the CorComp uses a WD 2793 controller instead of the 1771.

The cassette DSR is in the console, and different, as it's not among those that are scanned in the PEB expansion card scan sequence. It's partially in GPL, so it's different from all aspects. But when it comes to disks, you can do just anything. Look at the p-system, for example, which uses the original TI disk controller, or a CorComp double density or whatever, but doesn't read the normal TI files at all. It doesn't have any allocation map limiting the number of sectors, but instead have the p-systems limit of max 77 files per volume. It also allows 15 character file names. Look at the programs Advanced Diagnostics and Explorer, which use non-contiguous sector numbers or unformatted storage, by bypassing the DSR and doing their disk access in their own way. The same method could be included inside a DSR. Or look at my very own DSR, which converts a Maximem module and 64 K internal memory expansion into a RAMdisk.

When you simply convert code, that's written to work well on one CPU, to another, that's quite a lot different, you have to count on that the code will not be that terrific when translated. But if you re-write it to actually exploit the advantages of that second architecture, then it may be even better (depending on the source and target systems, of course).

One reason for BASIC to be pretty slow is all the administration it does. Perhaps it resets the GROM read address over and over again, or at least after all instructions which has a chance to modify it, to make sure it can return and continue properly. If you load a different address to the VDP when you are running a Pascal program, then it will fail. When p-code is interpreted from VDP RAM, the PME assumes that nothing else messes up the VDP read address, unless it does it by itself.

Maybe if you peek at GROM read data or VDP read data addresses. Since these chips are autoincrementing on each read, they'll not return the next byte as the system expects.

What you can do to destroy hardware is turn some of the programmable I/O points on the TMS 9901 PSI in the wrong direction. If you set an output against an output, you may fry the chip. But you can't do that with just a "poke".

It turns out that the later ROS versions, like 8.12 and 8.14F, they don't adhere perfectly to the rules for how a DSR should behave. They employ a trick, where they look into internal data for the DSRLNK routine in the console, to determine which subprogram is called on the RAMdisk. This works as long as the normal DSRLNK in the console is calling the card, but the p-system has its own BIOS, with a different DSRLNK, operating under a different principle. Thus this trick fails and Horzon RAMdisks with version 8 don't work with the p-system. The version 4 I had for the first Horizon RAMdisk I tried does not use this trick, but behaves the way a DSR is supposed to. That's why the older version works. So does my own RAMdisk design, as well as the CorComp RAMdisk a friend of mine once had. A textbook example of why one should have well specified interfaces between software modules, and stick to them!

They not only invited a few calculator engineers to the party, they gave the whole responsibility for the TI 99/4 to the calculator division. They probably thought that a "home computer" was just a over-fed calculator anyway. To the calculator guys, the equation calculator probably made just as much sense as the chicklet style keyboard, which resembled a, well, I already wrote it, over-fed calculator's keys. Take a look at the TI 74, the BASICALC, and you see the same idea again. By pressing a mode switch, you have either a full-function (but not programmable) scientific calculator, or you have a small BASIC-programmable computer. The BASIC is pretty similar to the Extended BASIC in the 99/4A. For some unimaginable reason, it's two completely different things in the same housing. You can't even pass a value from the BASIC part to the calculator or vice versa. It would have been much smarter if there was some pre-defined data structure, like an array CALC(0..9) which corresponds with the storage registers 0-9 on the calculator. But no.

No need to. We got Muliplan instead.

The point I was making is that it's not "whatever you want to call it". A bug is something that doesn't work as intended. Period. The behavior of CALL LOAD is clearly intended. By design. One can argue that it was anything from the right thing to do via a slight oversight down to downright stupid to not allow POKE, PEEK, POKEV and PEEKV in Extended BASIC, regardless of whether there is any memory expansion or not. But it's not a bug. If you take a step back and look at what TI probably had in their mind, when they originally designed the TI 99/4, then it makes more sense. They came from the calculator division. They had been successful with the TI-59 and its software modules. They thought they'd make a super calculator, with a rather limited BASIC and pre-programmed modules for most everything they imagined people would otherwise. It took them a long time to even come up with the Editor/Assembler package, as they thought software was better developed on a TI-990, using the DX10 assembler, than on the TI 99/4A itself. From that point of view, not allowing the user's to poke into memory unless they do intend to load assembly programs (they've executed CALL INIT) seems rather logical. TI obviously didn't think too much about the exploring users, who want to dig into the interior of the system. Like you have done with Extended BASIC and I've done with the UCSD p-system. But there it was a bit easier, since the p-system wasn't designed by TI, but by people who actually thought you may want to port it to another computer system. Thus the internal architecture is described in good detail, and in documents that are published. But it's not a bug. It's bad design choice.

Since you seem not to know what a "bug" is, I can inform you about that it's something that doesn't work as intended. Thus this is not a bug. It's as intended, by design. TI choose to provide the Extended BASIC with a more advanced version than then ordinary POKE, and gave us a tagged object code loader, which also can poke values into RAM. Since the main purpose is to work as an object code loader, it works without any bugs I've heard about. They also made a more advanced way to call assembly routines, by name via the CALL LINK statement, instead of just some version of EXEC at a memory location, which otherwise was common on contemporary computers. Then if there should be a POKE, specifically to do just that, that's something else. It was available on other computers, but I've not seen any other computer of the same style which didn't have any CPU RAM (except for the 256 bytes). So it's much more meaningful on other machines.

The fact that you can't do CALL LOAD in Extended BASIC without first doing CALL INIT isn't a bug. It's by design. CALL LOAD calls the assembly program loader, designed to load assembly programs into expansion memory, and to do the bookkeeping of the loading using data structures set up by CALL INIT. Thus it's pointless without the memory expansion. The different fact that CALL LOAD can be used as what's normally called POKE as well, that's also by design. That you in fact can't do a POKE without having the memory expansion, now that's a limitation, of course. Not a very big one, since most of what you POKE without the memory expansion will destroy Extended BASIC anyway, but yes, it's a limitation. But it's still by design, so it's not a bug.

That would be Michael L Bunyard, I presume.

There's no interrupt vector at >834C. It's just a branch address. An interrupt vector contains both the address to run code at and the new workspace address. The location of all interrupt vectors are fixed, and almost all of them are at the beginning of the memory. BLWP is a good instruction, if you really need it. If not, it's a waste. But it's impossible to get the same effect as you get with BLWP by a number of other instructions, without that taking much longer time.

Well, it's only my machine, and one of my friend's (but I doubt his is running any longer) that has a unit realtime. The p-system keeps track of today's date, and uses it to tag files when they are created or updated. But you have to key in the date manually, as the system always starts with the same date as last time it was set. It's stored on the disk, so it's the last date the system disk was used you get when you start next time. If the computer had a battery-backed real time clock, keeping track of date and time, the setting of the date could be done automatically. As there was no such device available on the market at that time, I set about to design and build one. I did of course also write the software to use it. The p-system unit realtime is one part of that software. I have two editions of the unit realtime, one that works with my own clock hardware and one that works with the Triple-Tech card, which was the first clock card available one the market that I came in touch with. A friend of mine bought one, so I wrote a driver for him to use it with the p-system. My device uses the same clock chip as you find on the P-GRAM card. It's good for precision timing, as it counts down to 1/1000 s. The chip they used on the Triple-Tech card would do seconds only. I've also designed my card so that I can use the interrupt generation capability of the clock. Thus the card can issue an alarm, via an interrupt, at a pre-programmed time, or use a counter rollover interrupt, and thus issue one every minute or every 1/10 s or every day. The every day interrupt can be used to change the system date not only when logging on, but also during operation of the p-system. Since I can change the interrupt vector in my system (I can overlay the console ROM with RAM) I have the ability to for example reconfigure the TI to become a controller, which can take actions based on time. But in this benchmark case the clock is simply used to time the activity. The unit realtime allows the dynamic creation of any number of timers (only memory limiting), that can run simultaneously. They can be halted and read individually, and disposed when not needed any longer, to recover the memory used. Anyway, don't look for it in the stock UCSD p-system, as it's not there.

I thought you were talking about replacing the whole system with a compiler that produced code files which couldn't be loaded under the p-system. As I understand you now it's completely different. Automating that process is like having a native code generator (which normally does accompany the p-system), but perhaps even better, if it is an optimizing such thing. How fast do you guys sort 1000 random integers? Using whatever language you like, thus most likely assembly?

Sure. Here you go. Note that the UCSD p-system on the somewhat peculiar TI 99/4A has dual code pools. One in VDP RAM, the other in the 24 K CPU RAM. Normally, the p-system will load pure p-code in the VDP pool. Code containing assembly programs must be loaded in the secondary code pool, as they can't run from video memory. But in this program, I'm writing to the VDP from Pascal. Thus you must use the utility setltype (set language type) to change the type of the code file you run from Pseudo to M_9900. This is not very flexible, as the procedure that writes to VDP RAM is fixed to set the position values for sprite #1, nothing else. A few more milliseconds could have been saved by not calling any procedure at all, but putting the code in line in the main program. Then it would also have been possible to only write one coordinate, as the other is fixed in each loop. But I didn't bother. I just wanted to see if it was the versatile and complicated unit sprite which does some overkill for such a simple task as this one, and thus wastes a lot of time. And it obviously is. The time related code is just to make the benchmark timing automatic. A few declarations aren't used; they remain from the first version.

What about the ROS 8.14F? As it seems it doesn't work with the p-code card, I was a bit interested in checking why? The source would be easier than using the DISkASSEMBLER.

You can see a picture of my RTC. It's the card with the battery on top. When I did that one, there was none available for purchase, at least none I was aware of at that time. By coincidence, I use the same clock chip as later showed up on the P-GRAM card. Funny enough, I noticed that when I run the configuration program (CFG) that comes with the ROS 8.14F for the Horizon RAMdisk, it scans the box for all cards it can find. It's unable to figure out what a standard p-code card is, but my one-card-in-the-world clock card it does identify correctly as a CLOCK CARD.

As I actually laid my hands on three different Horizon disks, I also tried with what I think is the latest model, a Horizon RAMdisk 4000. There's an operating system called ROS 8.14F that came with it. But this one fails. If I add that drive to the p-system in the same way as I did with the Horizon drive I described in the post above, the p-system will call it alright, but the drive DSR never returns to the caller. I found some old documentation, and it seems that OPA did a lot of work to make sure it would collaborate with virtually everything, but the p-system seems to be one of the few things they didn't get it going with. Since I've written a general DSRloader in Pascal, a program that's capable of loading absolute assembly code (generated by the assembler you get with the p-system) at any address, even if it requires setting a certain CRU bit to access the memory, I can make a simple DSR for the Horizon 4000, to see that it can work. It only needs to implement the sector read/write subprogram, so it's not much to write. Especially since I've already done it once, for my own RAMdisk. I only need to change the memory mapping. I noticed that for the older RAMdisks (there was a ROS version 4 with the one that worked above), the source code was included. But as far as I can see, that seems not to be the case with the version 8.14F. Does anyone know if this is the case?

Sure, but as far as I see it, it's not interesting. The value with the UCSD p-system lies in the word system. It's the whole system, with code and memory management, libraries and such that I like. Then I can live with that it doesn't outrun Forth, and that I occasionally have to write external procedures to get the desired performance.