(EXIT) is the run-time code of EXIT or (VARIABLE) is the run-time-code for VARIABLE, it pushes the address of the variable on the parameter-stack. The words between left and right parenthesis are run-time codes, e.g. So WORD will create TYPE LENGTH CHARSofSTR bytes in the dictionary when reads a word.įOS> : test begin key 97 = until discard Įxecuting TEST will wait till we press 'a' then it discards the character. 1+ will finally arrive to the first char of our string. The next cell+ will point to the type-byte of the string (sample). Next the cell+ will point to the runtime-code of. ' (TICK) (caddr - dptoxt) and >BODY (dptolink - dptoxt) in GFOS, so there is no need for >BODY in GFOS in the example in SF chapter 10:Īfter tick our ptr points to dptoxt of test. a VARIABLE can be in a colon-definition and that variable needs to find its value. So we need to apply an extra indirection. The DPTOXTs mean not the pointers to the runtime-codes of the words but the pointers to the xts of those words in their dictionary entries. Since IMMEDIATE, EXEC_ONLY and COMP_ONLY bits are in the type-byte and not in the length-byte, GFOS can read strings that are 255 charaters long (e.g. The type-byte tells us whether the word is an IMMEDIATE, EXEC-ONLY, COMP-ONLY word or not and also shows if the word is a USER, VARIABLE, COLON, CONSTANT, CREATE, FCONSTANT, FVARIABLE word or not. The structure of a dictionary entry (a word):īYTE(type) BYTE(length) BYTES(name with delimiter at the end).ĭPTOXT-OF-RuntimecodeOfSemiColon i.e. Is equivalent to "TIB #TIB TYPE" in SF chapter 10. TIB and #TIB is used in the code of GFOS but INPBUFF and #INPBUFF need to be used in GFOS because the source can be a file (maybe soon in GFOS) and not only the TIB: There is a little difference currently between ANSI Forth (or FigForth) and GFOS. Move dictionary (and everything after it) to the longest continuous memory-region and everything goes to the dictionary (files from USB, blocks from disk!?) !? FORGET will remove them later. Rewrite everything that is possible in Forth Get USB working with most of the pendrives YForth was written in C and it helped a lot (it's not an OS): The Memory-map can be found at the beginning of forth.asm. Currently only simple-glyphs are supported (so no composite (or compound glyphs). 16*24 fonts for 1024*768).Ī Truetype-font reader can be downloaded (TTFTest.zip written in python3 with tkinter). bfeditorapp.py ) in order to facilitate the design of charsets for high resolution in GFOS (e.g. Boots from winchester(also from USB pen-drive), floppy, CD-with-floppyemulation (from floppy and disk also with Bochs)Ī Bitmap Font Editor is also available (BFEditorTk.zip, written in python 3.5.1 install python3 and python3-tk packages on Debian or Ubuntu start with python3. Can play (uncompressed) wav, and can display bmp-s USB (EHCI, UHCI so USB2.0) pendrive support (sectors/files) forth.asm in the source is very well commented and the source of YForth should also be checked (it's written in C and can be downloaded from this page). The hash-table is 20000 long with a list in each slot (20000*16). There is one dictionary and one hash-table (djb2 algorithm). The double-cells was a good idea in the 16-bit world. The main things that are missing are the double cells, value, locals and code. It has most of the words from ANSI Forth. This OS doesn't use the mouse (it's best to unplug it). The bochs-config file can be found in gfos.zip It has been tested with emulators (BOCHS and QEMU) and on real hardware (an old desktop and on a laptop: Dell D820). The 32-bit GFOS (Graphical Forth Operating System) was written entirely in assembly with NASM (Intel, minimum PENTIUM).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |