Jump to content

TheBF

+AtariAge Subscriber
  • Posts

    4,470
  • Joined

  • Last visited

Everything posted by TheBF

  1. I finally got around to formalizing support for an inverted font in Camel99 Forth. A nice out-growth of the effort was the creation of VCMOVE which allows VDP to VDP movement using a dynamic buffer in low RAM. This makes copying a font from the default position to a new position in VDP RAM very easy although it does use a lot of return stack juggling. With your font in VDP RAM you must first run INVERTFONT which copies the font to >80+ASCII value and then inverts all the bits in VDP RAM for the copied patterns. You can then use HITYPE to type an inverse colored stack string (addr,len), or HILITE an area of the screen or NORMAL an area of the screen. Edit: ANS Forth has the word INVERT which is faster than -1 XOR. DUH!
  2. Beery motivated me to try something that I was wanting to make anyway. In the past I have been using the TI editor as simple way to convert a PC text file to DV80. It's not great but it works. I realized that I had a pretty good set of utilities in my SHELL program so I tried adding something called WAITFOR that accepts text from the keyboard and saves it to a file when you press BREAK (FCTN 4). The videos show it working and how you use the COPY command to take TI files back to the windows clipboard. All of this is made easy because of Classic99. Shell utility code with WAITFOR added at the end WAITFOR_FILE.mp4 COPY_TO_CLIP.mp4
  3. I have corrected this version. It is now 2.62c. The supercart version is not behaving yet.
  4. Sounds like a design spec to me. My idea of using Classic99 as the go-between is definitely one file at a time so not ideal for your needs. I will put it on my stack anyway and see where it goes.
  5. Since I forgot about that admonishment I have left Forth running overnight numerous times and the machine is still working. It could be because I only poll it during a delay. However I am now reading it in my cursor blinking loop so that's pretty frequent but Forth is not really polling continuously since it runs the interpreter every 56 or so micro-seconds and the cursor loop has other stuff in it as well. So either I am lucky or it's not too dangerous. ? All that to say try it you may like it. ?
  6. I have been noodling on making an app to let the TI-99 do that on Classic99. It would start the app, give it a DSK?.FILENAME string and then paste PC text to classic99 and it would write to DV80 file. The reverse would be to write the DV80 file to CLIP and paste it into your PC editor. Would that do the job?
  7. Am I the only person who uses the 9901 timer as a time reference? It works great on a real TI-99. Would it help to make delays the same on a 99 and Geneve?
  8. I was totally surprised by the Macro file. They were not programming Assembly language. The combination of macros created a simple hi-level language. Some of it is similar to how a Forth Assembler works. I don't fully grok the stack stuff where they are doing a BLWP ?? Looks like they created a way to push/pop variable numbers of registers. Very fun to see this. Thanks
  9. Is it just me as an old man complaining or have people who write these weather apps not learned that it is important to know the direction the barometer is moving as well as the absolute value? I see this on my local TV station news as well. Why when I was a boy...
  10. I know this is Forth but it might help you out nevertheless. I took the approach of creating literal values for each sound source in the chip. Then I OR the sound value with the appropriate literal value to select which sound source on the chip. Here are the constants. You could use EQUates or DATA values in Assembly language. After ORing the frequency values to the OSCillator constant you write the two bytes of the register to the chip starting with the lsb. ( example AABB , write AA 1st, then BB) For attenuation values and noise values, it is just a one byte write. Edit: Home Automation pointed out to me that Oscillators require 3 nibbles. I was thinking in terms of writes to the sound chip. \ frequency code must be ORed with these numbers to create a sound HEX 8000 CONSTANT OSC1 A000 CONSTANT OSC2 ( oscillators take 2 nibbles) C000 CONSTANT OSC3 E0 CONSTANT OSC4 ( noise takes 1 nibble) \ Attenuation values are ORed with these values to change volume ( 0= max, 15 = off) 90 CONSTANT ATT1 B0 CONSTANT ATT2 D0 CONSTANT ATT3 F0 CONSTANT ATT4 ( OSC4 volume adjust) Might make it easier for you like it did for me.
  11. Source code must be related to rabbits. It replicates prolifically. I have been building different verisons of Camel99. Indirect threaded, direct threaded and supercart versions. It starts to get overwhelming with all these different files and dependencies. I finally completed something that I should have done a long time ago. I made a single source file for the indirect threaded Camel99 Forth system that compiles to either a regular expansion ram version or a supercart version base on a value in the source code that can be changed. For the curious out their this is done similar to the way 'C' uses the pre-processor and the #define #if etc directives. In Forth of course the interpreter is just extended to give it the ability to do the job. ANS Forth and my homebrew cross-compiler use the ANS Forth words [IF] [ELSE] [THEN] for logic control. There are also the words [DEFINED] and [UNDEFINED] to interrogate the system for the presence of some names as well. I chose to create a VALUE that is a flag to make a supercart version or not. Here the section of CODE at the top of the program that makes the magic work. 0 VALUE <PROG-ORG> \ holds origin address for primitives \ ******************************************************** \ **** Set SUPERCART to false to build regular system *** \ ******************************************************** FALSE VALUE SUPERCART SUPERCART [IF] HEX 6000 TO <PROG-ORG> ( make a supercart) [ELSE] HEX A000 TO <PROG-ORG> ( make Expansion RAM version) [THEN] INCLUDE CC9900\SRC.ITC\9900FAS3.HSF INCLUDE CC9900\SRC.ITC\TI99PRIM.HSF The VALUE <PROG-ORG> is used in the Assembly language file 9900FAS2.HSF to set the program origin. SUPERCART determines the address that is assigned to <PROG-ORG> And then the Forth Assembly language files for the Forth low level code and TI99 i/o primitives (VDP and KEY stuff) are loaded. I have streamlined some of the code involved in branching and looping and when I am happy with it and confirm everything works on real iron I will release it. I hope that will be soon. B
  12. Here is something called Forth in 5 Minutes which I modified for Camel99 Forth and corrected a few errors in the original. It's a tutorial that is written in Forth.
  13. I am very happy that you enjoy it. It has been a lot of work but I wanted to do 35 years ago and life got in the way. Ask any questions you want. I am happy to explain whatever you need. It's a pretty big jump from BASIC, but it can be a little easier than Assembler once you get the concepts. B
  14. Wonderful. Thank you Microsoft. Thanks for the quick reply.
  15. I have been meaning to ask about this. When I start Classic99 on my new Windows 10 machine I get this dialog box. I can click yes or no, it makes no difference from what I can see. Anyone know what it means?
  16. Having just tested these new versions on real hardware I have discovered that they do not work on real hardware despite working perfectly on Class99. I will have to use the real hardware as my reference and revert to previous versions. More to come...
  17. If I remember correctly 1dB is defined as the amount of level change that can be perceived 50% of the time by humans, so 2dB might be a reasonable choice to overcome that hurdle. It does provide the ability to create relatively smooth attack and decay envelopes to our sounds. I think a 3dB step would produce an audible step but I have never tried it to know for sure. I think if I wanted anything more it would be 1 more bit of attenuation range.
  18. When you are making a compiler that is making a compiler ... and you find a bug in the first compiler, it's probably a good idea to check the second compiler for the same bug. While working on some SAMS card code I created a new user variable for R12. I was benchmarking different code running through all the SAMS pages using that USER variable. I have taken to having the heap map open on Classic99 and I saw a familiar signature. ? It turns out that all the data structures (variables, constants, user variables) that were generated by the cross compiler worked perfectly now in V2.62b Unfortunately my method for creating these structures when running on the TI99 also needed fixing. I ended up creating TI-99 CONSTANTs in the Forth kernel for the date interpreters DOVAR DOCON DOUSER and DODOES so that later on the TI99, Forth HAD got the correct addresses to plug into new definitions. There will be a V2.62C coming after I beat it up a little more. As of right now it seems good. Making your own tools is humbling.
  19. I haven't test this but I think you could make a toggle function like this. * TOGGLE higlight/normal LI R0,STRPNT LI R1,STRLEN LI R2,>8000 LOOP XOR R2,*R0+ DEC R1 JNE LOOP
  20. Camel99 Forth supports the SAMS card with a function called PAGED( addr) and SEG variable. The SEG variable sets a 64K segment you are using in SAMS memory. You call PAGED with any 16bit virtual address parameter and it returns a real address in RAM that you can read and write. This gives me byte level access to the SAMS card albeit slow. So that means to be faster you operate on larger chunks in the paged buffer where it makes sense to do so. It's not a bad compromise. Currently I have only one page mapped at >3000 which means if I have to copy data across Mapped memory boundaries I have to double buffer. If I want to copy 4K at a time there is no safe place to buffer it except VDP which works, but seems silly. I am playing with using a block concept and keeping two 4K blocks in low RAM. The SAMS memory will look like a sequential set of these blocks numbered 0 to FF for a 1 Mb card. When you request a block by calling MEMBLOCK(n) , MEMBLOCK will return the base address in low RAM where it was mapped, either >2000 or >3000. (Stolen concept from Forth disk blocks) This should be pretty fast access, the slow part will again be computing the byte or word access that you require for your application. As I think about it might simpler to just have two mappers, one HEAP() at >2000 and one MEMBLOCK() at >3000. Then there is no arbitration code for which real address to use. Hmm... That could be done in 4 instructions for each function.
  21. *NEW* Camel99 Update V2.62c I have changed the ZIP file with a correction to the "USER" word in this Version. This version runs on real iron. I am still working on the Supercart version. Thanks to the expert interpretation by Tursi of an error I created in patching my cross-compiler we have what I believe it is now the most solid Camel99 kernel in this long history of my journey to cross-compile a Forth system for myself and the greater TI-99 community. We have CAMEL99 for conventional 32K RAM machines and CAMEL99SC for Supercart users and Classic99. I have touched the DEMO programs on DSK3. and found a few warts that were fixed. Notably the SNAKE game now works correctly. Try it. It is a little bit addictive. ( After starting Forth type: INCLUDE DSK3.SNAKE ) I will update the previous post and remove the older version. I also will rebuild the TTY version next week with these changes to the code base. Release Notes: CAMEL99.262.zip
  22. Touched one of those in 1982 (?) at a TI office in Redwood CA. Not PC compatible but similar. Poor TI didn't get the direction that the world was moving. Compatibility was more important than 'special features". I read about it a magazine and it was deemed to be a good machine but not exactly like a PC.
  23. Excellent writing Lee. Makes it all very accessible.
  24. There are some very clever people in the Forth world. I found this word in the system called 4TH by Hans Bezemer. I coded it up in Camel99 Forth with assembler code. This word lets you create very fast incrementor's and decrementors that operate like a constant that adds its value to the top of stack. \ +CONSTANT create incrementing/decrementing constants NEEDS ADD, FROM DSK1.ASM9900 : +CONSTANT CREATE , ;CODE *W TOS ADD, NEXT, ENDCODE Very handy when you need to compute a fast offset from value on the stack. DECIMAL 16 +CONSTANT 16+ -16 +CONSTANT 16-
×
×
  • Create New...