Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

971 Excellent

About TheBF

  • Rank

Profile Information

  • Gender
  • Location
    The Great White North
  • Interests
    Music/music production, The Forth programming language and implementations.
  • Currently Playing
  • Playing Next
    Trumpet ;)

Recent Profile Visitors

4,912 profile views
  1. I really love the animation of the fuzzy guy. Very cool.
  2. This is such a clever method. While it could be literally translated from BASIC to Forth with CAMEL99's re-entrant *string library, there is also an opportunity to use this method but make use of the machine in ways that native BASIC doesn't have. (*I made the first version in 1987 to give TI-Forth BASIC string functions) Perhaps Tursi can weigh in if I understand things correctly. Make dot plotting characters use the chars above 127. This would mean we don't need the CC$() array. We can just use the pattern descriptor table for that purpose Then we could redefine existing 1,2,3,4,5, "-" chars as tiny numbers and print to the screen directly And of course, with some effort, we could swap out the string functions for bit operations on the PDT data which would go faster. It is still a considerable effort (for me) to re-write it but I will come back here in future. 🙂
  3. I would say he faced it and beat it already.
  4. I think you could even define a custom SPLIT3, from the existing components and have just 1 line of text at the top for example making it 256x184 for plotting.
  5. Could you use the SPLIT mode to display the plot and put the text describing the plot in the other window?
  6. Oh yes I do. I don't have floating point support for my little system.
  7. 130 REM DOTPLOT AT DOTROW,DOTCOL (0-based) This is very cool. I need to try it this way. Thanks for taking the rest of my week away Tursi.
  8. Click the spoiler to see the code. It's Forth so... it's unusual. (Program code is a fine translation) Yes with a little more effort I can make it look more like your example. Vielen dank
  9. I got home from teaching and saw the challenge. It destroyed my afternoon. 😀 So I don't have bit mapped graphics working in my system yet so I used a sprite as the plotter. I showed the entire compile process with CLASSIC99 running at "NORMAL" speed so you know I didn't cheat. CAMEL99 Forth is "micro-kernel" (pico-kernel?) at 8K so everything has to be compiled on top of it. It's not exactly calibrated. Working in integers is a little more challenging but you get the idea. CARTESIAN.mp4
  10. I can't speak to the BASIC systems directly, but Forth is a low level language. It is really a clever macro assembler for a two stack machine. But the language is extendable. If you want cartesian coordinates then you just add words to the language that do that for you. FbForth has all the support needed to accomplish that.
  11. ED99 Beginnings I have been threatening to write an editor for CAMEL99 Forth for some time. I reached into the archive and found an editor that wrote in 1985 for MVP Forth that I just called "ED". I ported it to HsForth in the 90s and now to CAMEL99 Forth in the 21st Century. Truth be told it's a complete re-write because I think I have learned a thing or two about Forth since writing this system. As a result of ripping up and starting over it's still buggy. You can load,edit and save and file but I still have work to do. The design is a little weird but it is because of the limited memory in the TI-99 for big files. I use virtual memory file of 128 byte records to hold the file while working on it. This uses the Forth word BLOCK which gives you 1K blocks of disk that are stored in buffers and automagically paged in and out on demand. I create a swap-file on the disk that is 64Kb long and it is re-used. This allows files of over 1000 *500 lines to be edited. It's very crude however, If you insert a new line at the top of a 1000 line file be prepared to wait for about 8 seconds!! * There are only 3 kinds of people. Those that can do math and those that can't) The current version is to get the kinks out it and uses 80 columns because it's just easier to get started. I will add support for 40 columns later so I can use it my old IRON. Something that I always loved with the TI-FORTH 64 column editor was having a Forth REPL window under the source code so I create that here. This allows me to save a ton of code because I can use the command line for things that are not "text editing" per se. Currently the commands are: LOAD <filename> SAVE Save the loaded file with the same name SAVEAS <filename> saves loaded file as <filename> SWAPDEV <DSKx.> Sets the disk for the swapfile NEWBLOCKS Create a new swapfile EDIT Enter editor window at cursor position ED99 open swap-file, init the screen >> goto next page << goto previous page VIEW scroll through the file in the editor window PURGE Erase the entire swapfile. Having the interpreter means it is simple to make a config file to setup screen colors and disk selections on start-up. I will also add SEARCH and REPLACE as text commands once things are stable. Cut and paste will use a stack (what else in Forth) of lines that can be pasted back in difference places as needed. I will eventually port it to use SAMS as the BLOCK structure instead of a file but this version will work with a 32K card. ED99 PRELIM.mp4
  12. Do you mean that the system stops and does FLUSH automatically too often? If so increase the number of buffers. If you are doing it manually then you should use UPDATE whenever you change a block in any way. Then you only have to FLUSH when you leave the editor and return to Forth. SAMS could be used quite easily. You could rewrite the word BLOCK to SAMSBLOCK so that it behaves like ( block# -- address) but is returning a block of memory in SAMS. That's all you would need to do to edit in SAMS. BUT... you then need save those blocks out to disk when you are done. This could be to BLOCK file, one to one save, or if you want to get fancy save them as DV80 files. Of course then you need a DV80 file loader to SAMS blocks. I am doing the latter. Editing in BLOCKs and saving and loading DV80 files. (That was trickier than I thought it would be. I can send you code if you need it.)
  13. Please don't take this the wrong way but I started smiling when I read this. (it's from my past experience) My guess is that at some point you will find out why this happened while searching for a different bug. I'm just sayin' ... But congrats on getting things working. I managed to get the beginnings of a editor working that loads a text file into disk blocks using the blocks as virtual memory rather than using SAMS. A SAMS version will come next maybe. The text file is loaded into a 32K block file that is organized as 128 byte records (8 records/block) and edited in the blocks. When you are done editing you save the file back to DV80. So you only need 1 block file that is re-used every time. The downside is that erasing 32K bytes in a file is pretty slow on the 99. ( 9 seconds) AND I have not yet written the line insert and line delete code but in a full 32K byte file that will be slow as well. So this will probably not be as practical as I would like. I am considering making it a "page" based editor where you can only insert and delete lines on a page, but provide a big copy and paste buffer including a page copy and past. But in the end it's not an ideal way to do it. I think I should make each line a double linked list. I have plenty of extra bytes in each record to do this. Then when you move lines around you just changed the list pointers. That hard part is keeping those pointers accurate! But every time you do a final save back to DV80 you make it all new again. The downside will be file load/save times will be a bit worse and screen refreshes will be slower too. So much code, so little time...
  14. For sure they were teletype terminals. We only got to use them once and then it was over to another college where there was 1403 with Fortran and cards. I only got 2 programs to run between Sept and Christmas break going there once a week after high school classes. That machine had 8Kwords of "CORE" memory as I recall. 😂
  15. Excellent. I just attempted to count bytes from the source code. I missed a few!
  • Create New...