+Lee Stewart Posted October 21, 2013 Author Share Posted October 21, 2013 WooHoo! 80-column mode is working! Here is my simple-minded code to do it: * HEX 0470 VARIABLE TXT8 03E8 , 0106 , 004F , 8800 , 0000 , 9410 , 0000 , : TEXT80 TXT8 F 0 DO DUP I + C@ I VWTR LOOP DROP 70 83D4 C! 00 SCRN_START ! 50 SCRN_WIDTH ! 780 SCRN_END ! 135E PABS ! 780 836E ! 0 VDPMDE ! CLS 0 0 GOTOXY ; * It's 134 bytes, but it works! I've made VDPMDE = 0 for 80-column text. That way I can manage to keep pretty much every other thing the way folks familiar with TI Forth would expect it. I think I will include it in the system block (#30) that defines TEXT (40-column text mode). And now—On to modifying the 40-column editor to include 80-column mode! ...lee 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 22, 2013 Share Posted October 22, 2013 Yeah nice job!! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 23, 2013 Author Share Posted October 23, 2013 While modifying the original TI Forth 40-column editor to make it also work in 80-column mode on the F18A, I'm finding programming errors I didn't expect! My latest error discoveries are in TAB and -TAB . Both words leave stack debris! Depending on where in the block the cursor happens to be, one or two numbers get left on the stack for every use of each word. There is an additional error in TAB ,viz., the 16-bit value at the cursor address is read—it should be an 8-bit value. It's as though the original programmers were expecting to use those values, abandoned the idea and forgot to remove the offending code. Oh, well—I'm learning a lot in the process. Hopefully, I will have fbForth's new(?) 40/80-column editor working today or tomorrow! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 24, 2013 Author Share Posted October 24, 2013 Phew! Finally got TAB and -TAB working. A couple more words and I'll be ready to test in 80-column text mode—likely sometime tomorrow. Life got in the way today—nothing serious—just needed to tear myself away from the computer for several hours. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 25, 2013 Author Share Posted October 25, 2013 I'm having a little trouble tracking down the bugs I have introduced to the 40/80-column editor. It's likely something I've done; but, I did notice that, when I use it in 80-column mode, exiting it leaves things in a strange state. The TIB (I'm guessing) seems to have one or more characters that screw up the very next entry from the console— IN should be 0, but I'll check. After hitting <enter>, the first time, things seem to be normal except that the Pattern Descriptor Table seems to have taken a hit. Something obviously wrote to it because some letters (not always the same) have pattern changes. These seem to be only lowercase letters, so perhaps the random writing is to somewhere above fbForth's record buffer, where I'm storing the lowercase patterns. Because, at least, some of the problems appear related only to 80-column mode, I need to understand the F18A VDP register settings I lifted from @Willsy's TurboForth code. I believe I understand VR00–VR07; but, I'm at a loss concerning VR08–VR14 (see settings below), only one (VR10) of which @matthew180 documents—and, I don't see how that one concerns 80-column-text mode. @Willsy? @matthew180? * Settings for VR08–VR14 from TurboForth: VR Value -- ----- 08 88h 09 00h 10 00h 11 00h 12 94h 13 10h 14 00h * ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 25, 2013 Share Posted October 25, 2013 Hi Lee They are documented in the v9938 user manual which can be downloaded from the whtech ftp site IIRC. If you can't find it then let me know and I'll get it to you. Mark Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 25, 2013 Author Share Posted October 25, 2013 Hi Lee They are documented in the v9938 user manual which can be downloaded from the whtech ftp site IIRC. If you can't find it then let me know and I'll get it to you. Mark Thanks. Hopefully, the 9938 can handle VR00–VR07 being the same as the 9918A and the F18A. I have tracked (sort of) the trashing of my lowercase storage table to merely switching between TEXT (40 column)and TEXT80 and it appears to be random. Something is stepping on the memory around 1250h in VRAM and I can't figure it out. I may have to forget 80-column mode for awhile. My head hurts! ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 25, 2013 Share Posted October 25, 2013 Are vdp interrupts enabled by any chance? Is Not corruption of the vdp address on the vdp address register is it? That one has bitten me on the ass a few times! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 26, 2013 Author Share Posted October 26, 2013 Are vdp interrupts enabled by any chance? Is Not corruption of the vdp address on the vdp address register is it? That one has bitten me on the ass a few times! That might be it! Do I need to disable them while I change other VDP registers and enable only after that? ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 26, 2013 Author Share Posted October 26, 2013 That might be it! Do I need to disable them while I change other VDP registers and enable only after that? ...lee I can't figure this out. Could it be possible that I'm outrunning the VDP reads and/or writes? Do I need to worry about putting no-ops between VDP accesses or ensuring another statement interleaves VDP access? I have a couple of places where I'm moving blocks of memory from one place in VRAM to another. Any ideas? @Tursi? @Willsy? @matthew180? @InsaneMultitasker? Anybody? ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 26, 2013 Share Posted October 26, 2013 Very unlikely imo. From what i remember from tests that Tursi and others have executed it's pretty much impossible to overrun the VDP chip. *maybe* an unrolled loop using indirect register addressing in PAD ram but otherwise I think you'd struggle. However, if VDP interrupts were enabled while your loop was moving data from one location in VDP to another then you will definitely encounter problems. They'll appear random in nature (ass to the locations in vdp that get corrupted) because it depends what state the vdp address register was in when the interrupt was loaded. I assume interrupts are enabled most of the time in fbForth/TI forth since that's how the multi-tasking works? Or does it use PAUSE and not use interrupts at all? If the latter then all the above was a waste of your time! Sorry! Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 26, 2013 Share Posted October 26, 2013 that should say "as to..." not "ass to...". Bloody touch tablets.... Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 26, 2013 Author Share Posted October 26, 2013 ... However, if VDP interrupts were enabled ... . I assume interrupts are enabled most of the time in fbForth/TI forth ... . You don't really mean I should disable VDP interrupts (fbForth: bit 2 = 0 in VR01), do you? Yes, CPU interrupts are enabled most of the time in fbForth/TI Forth. I think I know where the problem lies. All of the system calls (including VRAM transfers) in fbForth/TI Forth execute a "LIMI 0" before branching to the requested routine and "LIMI 2" just before returning to caller. I defined my VMOVE word (copies VRAM to VRAM) in the resident dictionary and neglected to manage CPU interrupts! I probably should make VMOVE a system call; but, that'll remove ~60 bytes of return stack space, which is already 642 bytes—down from TI Forth's 806 bytes. I'll let you know in a little while if LIMI 0/2 fixes it. Thanks again for the help. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 26, 2013 Author Share Posted October 26, 2013 ... I'll let you know in a little while if LIMI 0/2 fixes it. Thanks again for the help. ...lee Bingo! And—Now, on to debugging the 80-column part of the 40/80-column editor without that distraction! I have this bad habit of changing too many things at once before thoroughly testing them—then I have a devil of a time finding the bugs! You'd think after 50 years in computer programming I'd have developed better programming habits! Oh, well... ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 27, 2013 Author Share Posted October 27, 2013 WooHoo! I think I just may have done it! It appears that just one misplaced DROP was wreaking havoc on my 80-column variation of the old TI Forth 40-column editor. It's a bit convoluted; but, it now appears to be working in both 40-column and 80-column modes with repeating characters. I will probably post fbForth 0.93 (I'm close to calling it v1.0!!) sometime tomorrow. I'd like to work through some more of the FBLOCKS system blocks to insure they are working OK with fbForth before posting; but, with the 40/80-column editor nearly clean, I think I will post it anyway. I probably won't have the manual completed by Faire time, however; but, I'll work on it. ...lee 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 27, 2013 Share Posted October 27, 2013 Great job Lee! You should post an announcement on the mailing lists if you haven't already. I know Bill Sullivan will be interested as he's a big TI Forth user. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2013 Author Share Posted October 28, 2013 While further testing 80-column text mode (TEXT80), I discovered a few words that need fixing to work properly in 80-column mode. There are probably others; but, I'm just going to fix these before I package up fbForth 0.93 tomorrow. The first of these words is VLIST , which lists the words in the dictionary. It works fine in TEXT80, but only lists half a screen's width. It turns out VLIST is using a hard number instead of SCRN_WIDTH to figure out how many words to display on a line! It is now fixed. Also, the floating point package invokes some GPL routines that use the "VDP Rollout Area" from 3C0h–3DFh (in the middle of the TEXT80 screen!), which cannot be moved. I was aware that the transcendental functions used that area, but had forgotten that the number-to-string routine does, as well. I have written save/restore functions to manage these 32 bytes and will include them in the package tomorrow. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2013 Author Share Posted October 28, 2013 OK...I defined the following helper words for saving and restoring the 32-byte VDP Rollout Area: * HEX 0 VARIABLE ROA 1E ALLOT : >ROA 3C0 ROA 20 VMBR ; ( save ROA to array) : ROA> ROA 3C0 20 VMBW ; ( restore ROA from array) * Maybe there are better names than ROA , >ROA and ROA> because I plan to include them in the manual for general use. @Willsy? @Vorticon? Here is my implementation for the number-to-string situation: * : DOSTR FAC B + C! >ROA 14 GPLLNK ROA> FAC B + C@ 8300 + FAC C + C@ DUP PAD C! PAD 1+ SWAP CMOVE ; * Notice that I am not checking for TEXT80—just unconditionally copying. It causes a momentary blink of that area of the screen in TEXT80 that I don't think is worth the effort avoiding. I'm not sure whether I should also include them similarly in all the transcendental words. Suggestions? ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2013 Author Share Posted October 28, 2013 I will post the fbForth v0.93 package in a couple of hours if I don't get any change suggestions by then. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2013 Author Share Posted October 28, 2013 Here 'tis! FBFORTH093.zip I have not yet installed the latest build of MESS—so, would someone test it in 80-column-text mode (TEXT80) for me and let me know if it works alright? @Willsy? @Vorticon? @jacquesg? Anyone? To get the display mode into TEXT80, you must first load block 30 ( 30 LOAD )—then type TEXT80 . TEXT will get it back to 40-column mode. ...lee Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 28, 2013 Share Posted October 28, 2013 Lee, just tested in MESS using EVPC (80 column card) and Geneve, same result for both in 80 column mode. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2013 Author Share Posted October 28, 2013 Lee, just tested in MESS using EVPC (80 column card) and Geneve, same result for both in 80 column mode. That's not good! I will probably not get around to working on MESS until after the Faire. I presume this card uses the TMS9938 and I don't know enough about it, yet, to know whether it wants VRAM set up differently from the 9918A. I assumed the video registers VR00–VR07 have the same meaning with the exception of the reserved bits. It could be that I have VR08–VR15 improperly set; but, I used (see post #380 above) what @Willsy used for TurboForth except that I used my own settings for VR00–VR07: * VR Value -- ----- 00 04h 01 F0h 02 00h 03 0Eh 04 01h 05 06h 06 01h 07 4Fh * l also set up VRAM to use 0–780h for the screen image table. I moved a few other tables around; but, that really shouldn't matter. ...lee Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 28, 2013 Share Posted October 28, 2013 EVPC and Geneve both use v9938. The 80 column mode is the startup default for GeneveOS, which is working in the emulation. The v9938 manual says that VR1 has a bit 0 at the leftmost position, so F0 is not a valid value. But this would mean an incompatibility between TMS9918 and v9938 which is not the case (I just verified: the reg 1 value is ANDed with 0x7b, so the MSB is cleared automatically). Here are some settings from my Fractals program which has a text screen: (high byte = reg number, low byte = reg value) DATA >0004,>0170,>0203,>0347DATA >0401,>0506,>0600,>0717DATA >0888,>0A00DATA >0C6A,>0E00DATA >0DF0 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 28, 2013 Author Share Posted October 28, 2013 EVPC and Geneve both use v9938. The 80 column mode is the startup default for GeneveOS, which is working in the emulation. The v9938 manual says that VR1 has a bit 0 at the leftmost position, so F0 is not a valid value. But this would mean an incompatibility between TMS9918 and v9938 which is not the case (I just verified: the reg 1 value is ANDed with 0x7b, so the MSB is cleared automatically). Here are some settings from my Fractals program which has a text screen: (high byte = reg number, low byte = reg value) DATA >0004,>0170,>0203,>0347 DATA >0401,>0506,>0600,>0717 DATA >0888,>0A00 DATA >0C6A,>0E00 DATA >0DF0 Thanks. I'll check it out a little later. Right now, I here some oysters on the half shell calling my name! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 29, 2013 Author Share Posted October 29, 2013 Lee, just tested in MESS using EVPC (80 column card) and Geneve, same result for both in 80 column mode. I presume it works in 40-column text mode? And, that the screen you posted happened after typing TEXT80 ? ...lee Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.