Lee Stewart

I'm thinking about using the 64KB Guidry board for fbForth. I have little to no idea about cost and availability. @acadiel? I can probably do it in 16KB; but, I think I want to put into the cartridge all of the major code from the system blocks file (FBLOCKS)—editors, graphics, file I/O, TMS9900 Assembler, BSAVE , floating point (FP) math, ... . For FP math, I would use the package I modified for TurboForth. I would need to work out a system for searching the dictionary over multiple banks. I suppose the trampoline code for 8 banks would be longer than for 2. @Willsy? I might also make the additional dictionary code optional by patching link field addresses in and out at the user's whim. The reason I would do this is that having everything in the dictionary available, when the user may not be interested, will increase the time required to search the dictionary for a given word. I haven't run any tests to see what the increase in search time might be, however. I'll be getting back to the current project ere long—you know, the blocks file I/O conversion. I just needed to ramble a bit to try to get some ideas. ...lee

This method will not work with CPU interrupts enabled, correct? If so, would it work by disabling interrupts (LIMI 0) at wait1 and enabling them (LIMI 2) just before rt? ...lee

H-m-m...nice to know. I didn't realize the copy of the VDP status byte was only updated when interrupts were enabled. ...lee

Nobody commented on my posts above about it, but on the TI, testing the copy of the status byte at 837Bh for the coincidence bit was right on the money every time I tested it successfully with automotion and manual motion—and, it does not reset anything. ...lee

I got the idea to test the copy at 837Bh instead of the actual status byte (8802h) from Craig Miller's Smart Programming Guide for Sprites. He claimed that it was "equivalent" to XB's CALL COINC(ALL,C), but that cannot be quite true because testing the copy will not reset any bits. The only time I've found it important to actually test 8802h was with TI Forth's (and, now, fbForth's ) RANDOMIZE . There must be other reasons, but I don't know what they might be. ...lee

I think I figured it out—sort of. TI Forth and, by extension, fbForth sample the VDP status register (8802h) directly in COINCALL to get the coincidence bit instead of the copy at 837Bh, which works fine. Coincidence is properly captured during automotion and manual motion. Phew! ...lee

I must be missing something basic about sprite coincidence! Time delays do not work. The only time I get useful information from the coincidence bit (20h) in the VDPSTA (8802h) status byte is when I wait for the VDP interrupt status bit (80h) to be set. This only seems to work in my hands when I manually move the sprites and then wait for the interrupt status bit to be set. It does not work at all after I set the sprites in automotion. I am out of ideas. ...lee

Tilt!

You're right, of course! I parked one sprite, with a solid bottom half, at the bottom of the screen with one row of pixels showing (3 rows off the bottom). I passed a solid sprite from left to right across the bottom of the screen, one pixel at a time, for a short distance that included the first sprite, waiting for a detectable VDP interrupt between sprite moves. The coincidence bit was set whenever on-pixels of the moving sprite overlaid any visible pixels of the stationary sprite. Next, I performed the same operation with the second sprite moving just off the bottom of the screen, overlapping three rows of on-pixels off the bottom of the screen with no setting of the coincidence bit. The same result obtained on both Classic99 and the TI-99/4A with 9918A. Thanks, Matthew, for setting a knucklehead straight. ...lee

Okey, dokey...I'll try to do it in fbForth. ...lee

Off-screen sprites are, indeed, considered—reread the datasheet p. 2-11 and see post #110 above. ...lee

matthew180, on Sun Jul 21, 2013 12:09 PM, said: ... On the F18A V1.4 firmware and real 9918A: No, collisions are resolved in the color mux of the VDP, so only sprites that have a pixel on the active display, i.e. inside the 256x192 visible pixel area. If you can't see the pixel, it won't trigger a collision. ... Nope—The TMS9918A datasheet also says sprites partially to completely off the screen are included in setting/resetting the coincidence flag. ...lee

If you are correct, the E/A manual has it wrong on p. 269: "Coincidence flag. Set if two or more sprites have overlapping pixels, including sprites that are transparent and sprites that are off the bottom of the screen." ...lee

Speaking of sprite coincidence, I was looking at the TI Forth word COINC to see how the coincidence of 2 sprites was calculated, given a pixel tolerance. At first I was confused because the inter-sprite distance (d) is compared with the tolerance (t) X √2, i.e., d > t√2. The actual comparison is d 2 > 2t 2. I guess this is taking into account that pixels are considered square and the distance from one corner to the diagonally opposite corner of a pixel is the pixel width times √2; hence, the tolerance is recalculated (t√2) to describe the radius of a tolerance circle that circumscribes all pixels within the tolerance. This means that, if the top left corners (TLCs) of the two sprites are in the same column or row that the actual number of pixels considered is 41.4% higher than you might expect, e.g., if you specified a tolerance of 10 pixels and the TLCs of the two sprites are 14 pixels apart on pixel-row 100, they would be considered coincident! Sorry, if this is obvious to everyone—just thinking out loud. Also—if you think my explanation is wrong, please feel free to disabuse me of my logic. ...lee

Yes—for sprites with lower numbers than the first "undefined" sprite, i.e., the first sprite with D0h for its Y-location. See E/A manual, p. 269. ...lee

Yeah, I understand that. I was just quoting the E/A manual to avoid confusion; but, your explanation is decidedly better! This, of course, is not the first time TI's choice of words was not the best. ...lee

Oops! This is embarrassing! I figured out a month ago that it is, indeed, 16KB (4KB for proposed negative blocks + 12KB remaining)! You'd think I could remember that. It's hell gettin' old! ...lee

But—TurboForth uses 16KB, does it not? ...lee

I believe the value is D0h, not D1h. Also, you only need that value as the Y-coordinate of the lowest-numbered, undefined sprite. This will cause all higher-numbered sprites to be undefined, as well. ...lee

I am beginning to anticipate how I will be coding fbForth for cartridge space. Considering that a cartridge-based fbForth will not be loading the kernel from disk, I think I will forego my attempts at boot tracking and just deal with the user via holding down a key to indicate the location of the system files (FBLOCKS, FBCHARS and FBMSGS) when not on DSK1 and a warning message if they cannot be found on the default or indicated disk a la @Willsy's TurboForth. I suppose I could also provide a word to effect the change after bootup, say, SYSPATH or somesuch. Otherwise, I think I will limit changes to converting block I/O to level 3 file record I/O from the level 2 file sector I/O I am currently using. ...lee

It happens that the 8 additional bytes used by the nanoPEB/CF7+ are at the top of VRAM. On my nanoPEB at the moment, those 8 bytes are AA03h 0007h 0005h 0006h. The high 3 words (2 bytes each) indicate the mounted volumes—DSK1=VOL7, DSK2=VOL5, DSK3=VOL6. I am guessing the AA03h word holds validation information, but I don't really know how to decipher it. ...lee

I hear ya, Rich. I will probably wind up using it for fbForth when I hoist it into cartridge space because I think it will be easier than adapting the current TI-Forth/fbForth GPLLNK and DSRLNK. ...lee

The nanoPEB uses 8 additional bytes more than the TI floppy DSR. This would make the default value for 3 simultaneously open files 37CFh instead of 37D7h. This is not something you can set explicitly, however. ...lee

I do believe that any code you had that saved the GROM address was truly superfluous. TF is using a modification of the Millers Graphics universal GPLLNK/DSRLNK from Smart Programmer, both of which save the GROM address—GPLLNK because it calls console routines that start out with a GROM save and DSRLNK because it calls GPLLNK, which then invokes the console's DSRLNK. ...lee

I understand the note vis-à-vis returning to E/A, Basic or XB; but, I'm not sure it matters with BLWP @GPLLNK. ...lee