apersson850

Once the program is in memory, there's no difference. The main advantage of the linking loader is that it allows the declaration of external DEFinitions and REFerences. You can for example build a software library with functions you need frequently. Just like TI have done, when they provide REFerences to VMBW and DSRLNK, you can make you own such routines. It doesn't matter what you need. You can make file access routines, screen formatting, array sorting or other stuff. You can then let the EA3 option first load your file FILEUTILS, then your own application. In your program, you use REF FLOPEN, REF FLCLOS, REF FLWRIT, REF FLREAD and whatever you have DEFined in the FILEUTILS library. FILEUTILS can be used by different programs, even different programs that are loaded at the same time, if that makes sense. Since they are relocatable, the linking loader will stuff them where there's room, and will link all REFerences with the DEFined locations. This provides the foundation for a system of assembly language utilities and programs, where you reduce the work with writing code, since you can re-use what you've done multiple times. Today, nobody does this, but at the time when TI developed their TI 990 minicomputer series, it was a viable concept, to get the required performance. The memory image loader, with its creating utility, is instead used to create and load one-of-a-kind programs. They aren't intended to be part of a system of cooperating code segments, but instead solve one single task, and do that quickly.

I have the monitor behind the console, and the two PEB units stacked on top of each other to the right of the monitor. The fire hose I make a 90° turn on, just to the right of the computer, and route it under the PEB. The two boxes are one standard TI PEB at the bottom, and then one more I designed myself on top of that. The top one holds the disk drives that doesn't fit in the TI PEB and some other stuff.

Looks like IKEA shelves.

I like the idea of using the housing of the TI-59 calculator as a terminal to the board.

If you are overwriting everything in the VDP memory anyway, you only need to reload the VDP write address once per row. It's only if you want to handle border cases you need to read, modify and write.. Here we're talking about drawing/erasing a line in a consecutive sequence of bytes. Using a buffer memory in such a case will only give you a redundant transfer from VDP memory to the buffer, a redundant modification to the buffer (it's mainly the same byte content that should be copied to multiple locations) and, finally, actually updating the VDP memory with the result. You do need to go through all steps for the border cases, but they involve only a single byte per side of your area to clear. You also have to think about that graphics 2 mode involves both a bitmap of pixels, as well as a "bytemap" of colors. Just erasing pixels doesn't necessarily say that you get to see the backdrop, as the background color for that byte of pixels may not be transparent.

Sure. But a fill routine can easily be modified to clear as well as fill. But I agree, what I referred to has nothing to do with what's asked for here. A high speed clear routine. I just thought about the closest thing I've done, in this field.

Yes, since in that case you don't know the boundary of the area beforehand. The idea is that you give what he actually wrote in the first post, a pixel position, not two pixels spanning a rectangle. Then, from that single position, you scout for the lines delimiting the area to fill. Not very difficult to implement as long as the area is a box, but when the algorithm should be able to handle an arbitrary shape, then it becomes a lot more tricky. You will of course also have to check that you don't start filling outside the screen, or outside a viewport, if you implement a viewport concept. Even if it will perform slower, the time saved when writing programs that use such a function is tremendous, if the areas you want to fill are complex. When I wrote my line drawing algorithm, it got pretty fast when implemented in assembly language. Then I learned about Bresenham's algorithm, and tried that. It was a bit faster, since it uses a somewhat simpler math to do the same thing as I did.

Filling an arbitrary area, delimited by a line, is more tricky. But also more useful.

I changed to the MG Eproms way back, and that took away all CorComp controller issues.

I'm old enough to remember (from school) that the minimum RS-232 levels are +/- 3 V. Within these limits all bets are off, but outside 3 V you should be OK.

What I meant was that when a DSR is called, you can never rule out that a completely different program has, by coincidence, put a value at a certain address that's the same, or similar, to what Extended BASIC would put there, had it been running. The remnant of the file name LOAD will probably not exist in memory if Extended BASIC has opened other files, after running, or attempting to run, DSK1.LOAD on startup. But I don't know the circumstances when you expect your DSR to be called, so I may be completely off.

You're aware of that termination is a physical/electrical thing? It's supposed to be in the drive at the end of the ribbon cable, regardless of how many drives are connected to the cable. If you have two cables, internal and external, then you need two terminators as well. My TI has four drives. Two connected with the internal cable (these drives are half-height, both located inside the PEB) and two connected via the external ribbon cable. These two are in a separate box. Drive 2 and 4 have terminators, as they are the last on the internal and external cable, respectively. Drive 1 and 3 don't have any.

But the problem with looking at a pointer is that a pointer, in this world, contains a number in the range 0 - 65535. Any program could set any word in memory to any content. If a pointer is used, it's frequently because the target pointed to could be in different places. At least within a range of addresses. If it's fixed, it can usually be addressed in simpler ways than going via a pointer. But if a range of values are possible, then the probability that some completely different program happens to set that memory cell to a value that looks like a valid pointer increases by the size of the valid range. Perhaps a combination of "module present" and "certain values in memory" is needed?

I see. I wasn't sure in which order they were introduced.

Why is looking for some identification in the module itself brittle? To me, that sounds about as rock solid a method as any could be.

When I designed my internal memory expansion, which uses internal CRU bits for bank switching, I installed a 74LS138 and a 74LS259 to decode a CRU address and provide eight new output bits. Less flexible than another TMS 9901, but requires no setup for I/O configuration.

But they (Programbiten) can be found here. Although they started in Swedish, the last few editions, before the news group was closed down due to diminishing number of members, had many articles in English. That was due to the desire to fill the newletter with good material, in spite of limited flow of such articles in Swedish. Programbiten actually started as a user's group for the TI 58/59 programmable calculators, so you'll find material for them too.

I checked some old newsletters. Programbiten Forth was introduced in the Programbiten newsletter 1983: 4/5. At that time, it was perhaps the only Forth version that could run with only 32 K RAM expansion and any of the three modules Editor/Assembler, Extended BASIC or Mini Memory. You could load it either from tape or diskette.

Looking at my own documentation, it says "VDP read delay logic" on the block diagram of the memory expansion. The delay circuit is triggered each time the *CS VDP R signal (Chip Select Video Display Processor Read) goes true.

No, it's not file based. Still using the blocks of memory. But it would load from tape. I don't remember if you had a few blocks in memory, then could save them or how the tape part worked. I never used that, as I had a disk system rather early. I'm 100% sure I have a disk with Programbiten Forth, and 99% sure it works, since it's been very rare that my 40 year old diskettes have lost memory. But I don't have any system set up where I can easily transfer the content to a dsk image for emulation and easy internet distribution. I don't have any emulator installed, for example. Is someone willing to do that transfer, if I copy the disk and send it to you via regular mail? Distributing the disk is no problem, from a copyright point of view, I mean.

Oh, it was a long time ago I designed this memory expansion. I'm not sure without checking, but I have a feeling that it was setting up the address to the VDP that required a wait, if you didn't have any operation between sending the two bytes. TI does advice that you should do a NOP or SWPB or whatever in between, but some programmers realized that with the wait-state hampered execution in a stock TI, you could remove that instruction. Then it fails if both workspace and code are in fast RAM. I've not encountered any program that has a problem with sound or speech or anything else but VDP access. I used CRU base address 0x0400, or >0400 if you prefer the TI notation, for the memory bank switching. There are 8 bits used to select the RAM banks to switch in RAM over ROM etc., and switch out the internal RAM over the normal expansion RAM. When using the normal expansion RAM, the wait states are as usual. No, I have 7 bits available for memory bank switching, because I have one bit that enables the hardware wait state for the VDP as well. Normally it's off. I don't remember now exactly how tight I decoded the VDP address for inserting the wait, and I don't remember exactly how long I made that wait either. I'd have to check the documentation I made. The RAM that's overlaying other memory areas doesn't provied write-through. I thought there was a risk it would cause issues in a machine that has quite a lot of memory mapped devices, including memory bank switching in some modules and so. So if I want to modify the machine ROM, the easiest and most efficient method is like this. Enable RAM in DSR space (>4000). Copy ROM >0000 - >1FFF to >4000 - >5FFF. Enable RAM at ROM space (>0000). Copy RAM block at >4000 to >0000. Disable RAM over DSR space. Now I can start writing to the "ROM", as it's actually in RAM. Hence interrupt vectors and such things can be modified. There's no speed penalty, since this RAM is as fast as ROM at that location. One could imagine expanding this idea to include 16 CRU bits, and thus be able to control things a little better. One could imagine being able to switch in RAM only at >8000 - >83FF, not the entire block with all memory mapped I/O, have more granularity than 8 K blocks, add LED visible from the outside to show some interesting status about how memory is configured or whatever. But there's not too much space inside, as long as you piggyback everything on existing circuits.

Oh gee, it was 40 years ago... Well, it was developed within the Swedish user's group Programbiten, mainly by Björn Gustavsson. It was based on TI-Forth, adding some stuff, removing other. One main difference was that you could run it from tape, if you wanted to. I'd have to look up the old documents to be more specific.

Are you referring to Programbiten Forth?

I have a console that's modified to include 64 K RAM, all at 16-bit wide bus. Half of that is used for a fast, internal 32 K RAM expansion. Now I don't have RXB, but there are a few programs (like the game Tennis), that doesn't work with that memory. The program doesn't access VDP RAM correctly, when the memory has no wait states. Since BASIC relies heavily on VDP RAM, it's of course not impossible that it has a similar issue. Exactly what happens is then of course a question about what it's trying to do when timing gets wrong. In the Tennis case, the game kind of still works, but the players split up in two halves (they are obviously two combined sprites), where the upper and lower parts of the body runs in different directions. My memory expansion is my own design. It's augmented by hardware which allows the VDP to run properly at full memory speed (this hardware inserts the required wait, but only when accessing the VDP, hence not slowing down anything else). If I enable that hardware, Tennis works as intended. It's just impossible to beat, since it runs significantly faster. It's more like table-tennis. I can also, using CRU bits, disable my internal memory, in which case the console falls back to the normal 32 K RAM expansion, if there is one. Then everything works normally, of course. This RAM expansion is my own design. I've never seen anybody else come up with that particular idea, so I doubt there are more than a handful consoles (those I was involved in modifying) that have it.

I like my own design better. First, it makes the 32 K RAM internal and 16 bit wide, no wait states. Second, it adds another 32 K RAM, 16 bit wide, which can be switced in or out, in 8 K banks, to replace memory anywhere in the machine. Console ROM, cartridge space - you can make it RAM instead. With all RAM enabled, you have 64 K contiguous RAM. Third, you can disable the 32 K 16-bit internal RAM, in which case you instead access the normal 32 K RAM expansion. Fourth, it's possible to run at 16-bit wide speed, no wait states, but enable a hardware wait state Circuit which only activates on VDP access, where it's necessary. Fifth, all these options are accessible to the CPU, so they can be done under software control.