Vorticon

Awesome! Are you planning on releasing a hardcopy manual on Amazon as well?

So I'm very motivated to get the TIPI disks working fully with the pcode card without having to remove the TI disk controller. With my current set up, TIPI is at >1000 and the disk controller is at >1100. Everything works fine and the system sees the 3 TIPI drives except the Editor which throws a Stack Overflow error when attempting to edit anything. From what I understand from @apersson850, the p-system is detecting both the TIPI and the real disk controller and creating an additional PCB in VDP RAM, which reduces the Editor's available RAM just enough to make it crash. The TOPMEM pointer at >2782 points to the highest VDP RAM location available and the PCB's are normally placed starting at that location and TOPMEM is adjusted down accordingly based on the length of the PCB. Now, since I don't need the physical drives when using the TIPI, in theory I should be able to remove the PCB for the TI controller and restore TOPMEM to its original content and *theoretically* the Editor will have enough RAM to work. So I need some additional info: How are the PCB's structured under the p-system? If each drive as its own PCB, why does the system not natively recognize more than 3 drives? Essentially, with both the TIPI and the TI controller coexisting, shouldn't we see 6 drives when we run the Volume command from the Filer? Or does the system only access the first controller it sees?

My kind of program. Nicely done. Getting the computer to make the necessary thrust corrections in real time and still achieve a safe landing is harder than it looks. I might want to replicate that idea in Pascal

So I finally got my IDE board assembled and it seems to work fine, but it is refusing to properly partition the 3 different CF cards I tried. The cards are recognized and go through the partitioning and initialization process in DU2K without errors, but when I check they are still reporting as unpartitioned. What gives? Am I missing something here or is the board very particular about certain CF cards? I tried 2 256MB cards and a 2GB one with similar results. All known working in other devices. I even tried 3 different CF-IDE adapters with no change.

I remember struggling to figure out how to get keyboard input in TI Forth when I coded Core Wars. I no longer recall how I did it, but it did strike me at the time that Forth did not have such a fundamental function built-in... Any particular reason for this? Not exactly a user friendly omission I might add... https://youtu.be/ZFANT61hEF0?si=1seXzWQpz9zOR7PR

How does one override the system font again?

Ah yes my bad. No comma separation. Essentially it's as if you are entering 2 separate commands, and the comma confuses the interpreter which does not know what to do with it, so it errors out. Just use a space in between. My grammatical OCD had taken over 😁

Make sure the Assembler/linker disk is in one of the drives so the system can see it. Also drive #4 (DSK1) is the default drive unless you execute a P=#<drive number> to set another default.

Indeed, but it's not complete. I preferred to roll my own to suit my needs better.

Best I could make it. Still not bad

Here's a real life code snippet on how to check the position of a moving sprite. It uses VSBR (VDP Single Byte Read) from my VDPUTIL library. In testing I had this a repeat/until loop checking for a destination position and it worked really well and was reasonably fast. set_sprite(sprnum, car[sprnum]); (* start sprite moving *) salloc := 3072 + (sprnum * 4); (* find location of sprite entry in the Sprite Attribute List *) vsbr(salloc, y); (* get y position *) vsbr(salloc + 1, x); (* get x position *) Below is the listing of VDPUTIL ready to assemble.

Yup, done that. You need to redirect input and output to the RS232 and connect the TI via a straight serial cable to a PC running a terminal emulator like Teraterm with matching comm parameters. The default setting for the RS232 under the p-system is 300bps 7-E-1. To make the redirection, type X, and at the "what file" prompt type I=REMIN:,O=REMOUT: then press Enter. Et voilà! You should see the UCSD system prompt on the PC terminal.

Exactly...

The only way to obtain the current sprite position is by looking up the x_pos and y_pos elements of the sprite's change list as there is no function to do that for you in the p-system. These elements are not getting updated as the sprite moves, and retain their original value when the sprite was created. This makes little sense and severely limits the usability of sprites. Yes, you can get around that by using assembly routines, but I'm talking here about what's available to the user within the p-system proper.

I dug a little further into this and it turns out the Sprite Attribute List starts at >C00. This is interesting because according to the EA manual sprite auto-motion requires the SAL to be at >300, which tells me that the p-system seems to actively move sprites directly. Second, the table only contains sprites that are on screen, with those defined off-screen not represented. The table appears to be initialized to >C000 >0000 for each sprite otherwise. >C000 is 192,0 which is just off screen. And I can see that the x and y positions for the visible sprites are updated in real time. So @TheBF's hunch is correct in that there must be a master copy of the SAL in RAM somewhere which is likely not a fixed location but depends on available memory for any particular program and the x and y positions in the VDP are not updating the RAM copy. This has got to be a bug. The good news is that I can easily write a small assembly procedure to check a sprite's position now that I know where to look for it. Homework for today 😁