+Lee Stewart Posted August 28, 2014 Author Share Posted August 28, 2014 And.......We have LIFT-OFF!!! I just received my 27C256 EPROMS, burned my first one with fbForth 2.0-beta09 and it works! ...lee 4 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted August 28, 2014 Share Posted August 28, 2014 :thumbsup: Hell yeah - congrats man! That's gotta be a good feeling . 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted August 28, 2014 Author Share Posted August 28, 2014 You got that right! ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted August 28, 2014 Share Posted August 28, 2014 That is some wonderful news, Lee. . .Now I just have to get some time to do some testing. . . 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted August 28, 2014 Author Share Posted August 28, 2014 That is some wonderful news, Lee. . .Now I just have to get some time to do some testing. . . That would definitely be helpful. ...lee 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted August 28, 2014 Share Posted August 28, 2014 Woohoo! Congratulations Lee! I remember the time when I got TF working from a real EPROM and the exhilaration of seeing my own work come up as a real cartridge! Congratulations Lee! Genuinely delighted for you! 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted August 28, 2014 Author Share Posted August 28, 2014 Woohoo! Congratulations Lee! I remember the time when I got TF working from a real EPROM and the exhilaration of seeing my own work come up as a real cartridge! Congratulations Lee! Genuinely delighted for you! Kinda makes me feel warm all over! ...lee Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted August 29, 2014 Share Posted August 29, 2014 At some point hopefully in the near future I have to start learning Forth . 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted August 29, 2014 Author Share Posted August 29, 2014 At some point hopefully in the near future I have to start learning Forth . The more, the merrier! As you know, there are a handful of folks here that can help. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted August 29, 2014 Author Share Posted August 29, 2014 @Astharot and I have been communicating about fbForth and he mentioned having problems (read "crash") when there was no FBLOCKS file present on DSK1. I had experienced that as well, but had forgotten to check into it. Just so you know, the beta I posted a couple of days ago (beta 9) fixes that bug. We may have another Forther in our midst ere long, eh, Ermanno? ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted August 29, 2014 Author Share Posted August 29, 2014 (edited) While reviewing the first block of FBLOCKS, I realized that the first action is redundant and that the second should be hoisted into cartridge space. The first, HEX 04F 7 VWTR changes the text display to blue on white, which the system already does. The second, HEX 10 83C2 C! ( QUIT off! ) turns FCTN+= (QUIT) off to prevent accidentally QUITting fbForth. You can do it on purpose with MON . However, if you start up without DSK1.FBLOCKS, the QUIT key is not disabled. Like I said, I need to get that into the cartridge, which I will do before releasing the final fbForth 2.0. ...lee Edited August 29, 2014 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 1, 2014 Author Share Posted September 1, 2014 As I am working on the fbForth 2.0 manual I am finding features I intended to implement and have not yet or features I have removed and perhaps should not have. Among the former is allowing for user-specified fonts and among the latter is the removal of F. for TI-Basic-style, free-form floating point number output (easy enough to do with FFMT. , but requires an additional stack entry). I will definitely implement user fonts as part of the resident dictionary. I will eventually implement a font editor and a CHARA1-file-to-fbForth-font-file converter as loadable blocks in FBLOCKS. A CHARA1 file and an fbForth font file are essentially only different by the first six bytes. I may re-implement F. to allow simple floating point number output from the stack. It would simply be defined as : F. 0 FFMT. ; The remaining removed output words I think I will leave to the user if s/he really needs them ( F.R , FF. , FF.R ). I am also wondering whether to include the option for the user to change the default colors for TEXT and TEXT80 modes—or any other modes, for that matter. The text modes would be easiest to handle; but, I could allow for default changes for the other modes, as well. Thoughts? ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 1, 2014 Author Share Posted September 1, 2014 Back in post #668 I indicated I had defined two words ( BNK2@ and BNK2C@ ) to assist VLIST in walking the threaded name field list of Bank #2 of fbForth 2.0. Well, I have changed those two words to BANK@ and BANKC@ , respectively. By adding the bank number to the stack signature for each word, we can now read any cell or byte in any bank. I don't know how useful it may be; but, at least now, they are general-purpose words that might be more useful: BANK@ ( bankAddr bank# --- n ) BANKC@ ( bankAddr bank# --- b ) If a nonexistent bank# is on the stack, the result will be for bank 0. I may rewrite DUMP to allow dumping banks other than bank 0, which is the current limitation. I'm not sure it's worth the effort, however. We'll see.... ...lee Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted September 1, 2014 Share Posted September 1, 2014 On the DUMP rewrite, there are instances where that might come in handy, especially as there are now a small number of applications out there that take advantage of bank-switched cartridge space. . . Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 1, 2014 Author Share Posted September 1, 2014 On the DUMP rewrite, there are instances where that might come in handy, especially as there are now a small number of applications out there that take advantage of bank-switched cartridge space. . . H-m-m-m... Mine is pretty myopic in that it presumes inverted paging à la 379 chips, which means presuming what the number of banks happens to be in the first place. Unless... Is there a way to discover how many banks there are in a particular ROM? If there is, I can make the code even more general to dump the code from any multi-cartridge ROM. That would be so cool! ...lee Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted September 1, 2014 Share Posted September 1, 2014 Iterative procees would get you there, Lee: try to read from the highest bank possible, any non-zero value will tell you ROM is present. If you get zeroes, cut that ROM bank's value in half and try again. Repeat until you get a non-zero value, and then increment one to see if there is anything in the next bank. Repeat again until zeroes appear. That will tell you exactly how many banks are in use. . .and there's probably a simpler way to do it, but I don't know one off the top of my head. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 1, 2014 Author Share Posted September 1, 2014 Iterative procees would get you there, Lee: try to read from the highest bank possible, any non-zero value will tell you ROM is present. If you get zeroes, cut that ROM bank's value in half and try again. Repeat until you get a non-zero value, and then increment one to see if there is anything in the next bank. Repeat again until zeroes appear. That will tell you exactly how many banks are in use. . .and there's probably a simpler way to do it, but I don't know one off the top of my head. That does not appear to work. I think the only way I will get anywhere in that regard is with 378s because fbForth 2.0, at least for now, is using 379s and, to get back to the inner interpreter, absolutely must return to bank 0. With 397s the address of bank 0 depends on the number of banks, but with 378s the address of bank 0 is always 6000h. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 2, 2014 Author Share Posted September 2, 2014 We discussed font loading and editing in posts #594ff and posts #680ff. I have now actually implemented USEFFL for user font files and need to start thinking seriously about file format and a user font editor. I am considering using a file-offset variable that could be set to accommodate CHARA1-style font files that have the font patterns offset 6 bytes into the file because of the E/A5 format. I suppose I could implement a frame shift in the editor, whereby the user could tell the program to shift a number of bytes left or right to get the correct registration before editing etc. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 2, 2014 Author Share Posted September 2, 2014 What do you think of an in situ font editor, i.e., the font editor edits selected character patterns in place? This would make it pretty simple to manage 256 patterns for all VDP modes except split and split2—those should probably be limited to 128 character patterns. (There is no automatic font loading for bitmap mode.) I could then allow the user to export the font as 0 – 127 (1KB file)., 128 – 255 (1KB file). or 0 – 255 (2KB file). I would then change FNT to always attempt to load 2KB of font patterns, except in split and split2 modes, which would throw errors if a 2KB file is attempted. I'm rambling—but, I'm getting there! ...lee 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted September 3, 2014 Share Posted September 3, 2014 Sounds seriously cool to me! Do you mean a built-in (in ROM) font editor? Mega cool. Great for games! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 3, 2014 Author Share Posted September 3, 2014 Sounds seriously cool to me! Do you mean a built-in (in ROM) font editor? Mega cool. Great for games! H-m-m-m... There's room, I think. I was going to put it in FBLOCKS—but, what the hell? By in situ, I meant that you would be editing the actual character such that, while editing a character that was part of the text displayed somewhere on the screen, all of those displayed instances would change, as well. I think, though, that I will do something else. I am, after all, designing on the fly here. As I am writing this down while pondering your comments, the design changes. I think I will reserve 2KB plus a small shift buffer in VRAM and run the program in graphics mode so it will be easy to display both text-mode and graphics-mode representations of the character while you are editing it. I am also thinking about how to use FNT to load font files or the default font to both the PDT and the font editor's buffer. I guess I could use a variable that holds the destination VRAM address. I could force it to always hold the PDT address except during font editing. Yeah! That should work! I'm glad we had this talk. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 4, 2014 Author Share Posted September 4, 2014 A question regarding frame shifts in my font editor— I am inclined only to allow implicit frame shifting in loading and saving the font file—and that, only by 6 bytes. That is to say, the user will only be able to tell the program to left-shift a font after it is loaded to accommodate editing TI-Writer-style font files such as CHARA1. And, only to tell the program to save a file starting at byte 0 of the file (fbForth 2.0) or byte 6 after first padding bytes 0 – 5 with zeroes (TI Writer). What do you think? ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 7, 2014 Author Share Posted September 7, 2014 Sheesh! I'm as slow as molasses in January! I am just about done with coding the font editor—maybe today to finish coding and another day or two for testing. Then, I'll post beta 10. ...lee Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted September 7, 2014 Share Posted September 7, 2014 Don't worry about how long it takes. Perfection takes time - especially in the world of coding. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted September 7, 2014 Share Posted September 7, 2014 Lee, slow and steady is the best way to go for good coding--it eliminates the tendency to hack a solution as opposed to coding one that is bulletproof. 1 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.