Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Posts posted by TheBF

  1. 2 hours ago, Retrospect said:

    thanks guys ... old cs1 i'll try this routine you sent tomorro as i've ended up going out and getting smashed drunk in town, im too far gone to do anything constructive but that code looks good.  i should say tho, the one thing i should have presented was the counter variable C should have started at 16 and counted down to 1 instead of otherway round.


    i think.



    Bodington's or Tetley? :) 

  2. 1 minute ago, OLD CS1 said:

    Way bloated compared to Forth or assembly.  The compiled result is around 6k, which includes the XB support routines -- placing characters on the screen, array variables, &c.

    That's a nice small runtime block.

    I was meaning just the expression you wrote.


    • Haha 2

  3. In the course of working on VI99 I need a way to push things into a temp buffer. I decided to use VDP RAM since there is a lot of it available.

    This little memory management scheme combines the Forth dictionary static allocation method with a 32 bit stack to hold the VDP address and size of each allocated block.

    It seems to work pretty well and I think could be moved to other Forth systems with a little bit tweaking. 


    One of the application problems was how to insert an arbitrary sized string into the middle of an array of byte counted strings.

    Current solution: Copy everything below the string to a temp buffer, do your editing and then append the temp buffer onto the end of the newly inserted text.  :) 


    We shall see how it all works but here is the API that gives me the ability to try it.

    \ VS stack holds allocated VBLOCK data
    CREATE VS0   10 4* CELLS ALLOT  \ room for 10 allocated VDP blocks
    CREATE VSP   VS0 ,              \ VDP stack pointer, initialzed to VS0
    : VSDEPTH ( -- n) VS0 VSP @ -  2/ ;
    : >VS     ( addr len --) 4 VSP +!   VSP @ 2! ;
    : ?VMEM   ( -- ) DUP VS0 = ABORT" VStack empty" ;
    : VBLOCK  ( -- Vaddr size) VSP @ ?VMEM [email protected]  ;  \ return last allocation.
    : NEW-VDP ( -- )  1000 VP ! ;
    : VHERE   ( vdp-mem) VP @ ;  \ next free address in VDP RAM
    : VALLOT  ( n --)  VP +! ;
    : V,      ( n --)  VHERE V!  2 VALLOT ;  \ compile integer to VDP ram
    : VC,     ( n --)  VHERE VC! 1 VALLOT ;  \ compile byte to VDP ram
    \ reserve block of size n returning addres Vaddr
    : RESERVE ( n -- Vaddr) VHERE SWAP 2DUP >VS  VALLOT ;
    \ de-allocate the last VBLOCK





    • Like 2

  4. 4 hours ago, Retrospect said:

    Hi everyone.  I am working on a possible new game and I wanted the enemies to cascade down the screen with a movement like Centipede.

    My idea is, the segments move across the screen and only react to anything that isn't character code 32 - space.  So if it hits the edges of the walls the segment would move down one character and then move the opposite way.


    So far all my experiments have one thing in common, they're slow.  Even when compiled, specially with player movement and other stuff going on.  Does any of you guys know a routine that would work?  It would be best using characters to get around TI's wonder 5-in-a-line-and-you're-buggered limitation on "hardware sprites".

    Could you show us a short video example of what you mean by slow. Not fancy, just one of these things falling down the screen.

    And maybe show the mission critical part of the code?


    I am by no means the expert in these things but I have found that when you need the old 99 to go really fast any extra code in the inner loops has a huge impact.

    ( found this trying to make code that goes as fast as GCC)

    It could be that the normally acceptable overhead of using arrays for example, as we have in BASIC, or even IF ELSE, is just that little extra that is too much for this application.

    All that to say you might need a tiny little Assembler routine to push you over the top.

    • Like 1

  5. "The rumor's of my death have been greatly exaggerated"    Mark Twain


    I have not been posting because I have been distracted by a few things.  In particular I am trying to create a  VI style editor called VI99. 

    It will run without using SAMS or disk base virtual memory. 

    The design spec is something like:

    1. Runs on console with expansion RAM and disk. 
    2. Ability to edit the largest files in my system. (~300 lines, >8K )  
    3. Leverages the Forth interpreter to replicate the command programmability of VI.
    4. Data is held in memory as single linked list using byte counted strings to save space.




    Camel99 kernel Update

    I have to do a release with changes but I have made to Camel99 but in the mean-time I have posted the kernel program here which has a few warts fixed.


    1. A couple of words that I "improved" in ALC would not have worked correctly in a multi-tasking environment. (I forgot to use workspace relative addressing) DOH!

    2. There was a bug in TYPE that would not work correctly if the length was 0. It would fail to DROP the address. Oops.

    3. And as discussed programs from my cross-compiler didn't work on JS99er.  This one does. 




    • Like 5

  6. 1 hour ago, RXB said:

    RXB 2021 has CALL POKER(vdp-register-number,value) this was increased for using the F18 from RXB.

    Register number allows 0 to 63 registers.

    The value ranges from 0 to 255.


              This sets text mode.              | >100 CALL POKER(7,244,1,240)
              This is a delay loop.               | >110 FOR L=1 TO 500 :: NEXT L
              This sets multi color mode      | >120 CALL POKER(1,232)
              This is a delay loop.               | >130 FOR L=1 TO 500 :: NEXT L
              This sets bit map mode.         | >140 CALL POKER(0,2,1,2)
              This is a delay loop.               | >150 FOR L=1 TO 500 :: NEXT L
              This sets normal XB mode.     | >160 CALL POKER(0,0)


    I do not know the values to make the F18 work for modes so will wait for people using BETA of RXB 2021 to tell me.

    You could try plugging these ones in Rich.   

    I got them from TurboForth and tried them in my system with a color change.  It comes up in 80 columns with black on cyan text.

    \ HEX values 
           04   \ VR1
           70   \ VR2
           03   \ VR3
           E8   \ VR4
           01   \ VR5
           06   \ VR6
           00   \ VR7
           17   \ VR8
           88   \ VR9
           00   \ VR10
           00   \ VR11
           00   \ VR12
           94   \ VR13
           10   \ VR14
           00   \ VR15


    • Like 2

  7. On 11/28/2021 at 2:05 AM, Tursi said:

    The total file on disk is 8264 bytes.


    I think there are size problems in the header.




    So the first 128 bytes are the V9T9 header. Of interest, bytes 14-15 show that the file length is 32 sectors, or 8192 bytes. 


    But the first 6 bytes after that are the EA5 header. So starting at 80 in that image:


    00 00 - means there are no more files after this one

    20 46 - means this file is >2046 bytes long, or 8262 bytes

    A0 00 - means this file loads at >A000


    However, the file is NOT 8262 bytes long, and some loaders would not load it even if it were (since 8192 bytes, or 8k, is normally the maximum expected size). The actual TI part of this file is only 8136 bytes long, so loadable data is just 8130 bytes (cause the 6 byte header doesn't count).


    Classic99 has this report:

    DSR opcode >5 (LOAD) on PAB >100E, filename DSK0.CAMEL268
    Loading to VDP >1380 DSK0.CAMEL268 on drive type FIAD
    Detected d:\classic99\dsk1\CAMEL268 as a V9T9 file
    loading 0x1FC8 bytes

    That shows a smaller number still for the load size... 0x1FC8, which is the size on disk minus the 128 byte header (8136 bytes).


    As an aside, the PAB (from Editor/Assembler) allows for up to >2100 bytes (8448).

    So I am not sure what part JS99er is looking at, but you have a file on disk with 8136 bytes of TI data that represents itself as containing 8192 bytes of TI data and tries to load 8262 bytes of TI data. Somewhere in there. :)



    So the final resolution to this for JS99er was to use the correct Ti-99 code image size not the "total image-size" in the Program header. So 2046 became 1FC0.

    Then when the cross-compiler writes out the file I had to pad out the binary image to match the >2000 which is the number in the DOS file header.

    Now JS99ER loads programs created by my cross-compiler.

    Makes perfect sense.  

    Now I need to make a TIFILES. directive and stop creating V9T9 files. 




    • Like 1

  8. 20 minutes ago, Lee Stewart said:


    The reason I suggested Level-2 Subprograms >014 and >015 is that all the necessary 4KiB blocks of binary code can be loaded/saved at will, one 4-KiB block at a time from/to the same file.



    Ah!  I need to learn about those.  I have never pressed my DSR into service on the Level-2 Subprograms.

    Thanks for the reminder.

    • Like 1

  9. 8 hours ago, GDMike said:

    I just glanced it over, but I'm only needing to load 4K. Not sure if I need to do it twice (as maybe I don't need the code), but I've got to seperate out into 4K chunkies.

    See the #bytes parameter. That's controls how many bytes to read or write. With functions 5 & 6 the # of bytes goes into what is normally the record# field of the PAB.

    Max size is  8K. (>2000)

    These things are so fast you could have 3 or 4 code blocks and load them as needed. :)  


    • Like 1
    • Thanks 1

  10. 2 hours ago, GDMike said:

    Naaa. I'd have to build a loader, like a DF80 reader, and then setup the map and place the file read into SAMS manually at boot.

    Don't know if this helps but I love disk functions 5 and 6 for this kind of thing.

    They just blast in and out as long as you don't need more than 8K which you don't.

    Here it is Forth. I can answer any questions.


    But really you just set up the PAB and hit 6 to save and 5 to load.


    Differences from TF below: 

    VC! writes one byte.

    V!  writes 2bytes (one CELL) 


    ior means I/O response (error number) 

    \ PRE-FAB file access mode selectors for default file binary type
    0B CONSTANT W/O100  \ WRITE ONLY, binary, relative, fixed 100
    0D CONSTANT R/O100  \ READ ONLY,  binary, relative, fixed 100
    : NEWPAB   (  file$ len VDPaddr #bytes mode -- )
               -30 ^PAB +!         \ create new pab in VDP RAM with NO buffer
               [PAB 30 0 VFILL     \ erase PAB and file name
             0 [PAB RECLEN] VC!    \ set reclen (0 means >100 (256) bytes)
             \ pulls params from the stack to init the PAB
               [PAB FLG] VC!       \ set file access mode byte
               [PAB REC#]  V!      \ set #bytes to save (integer)
               [PAB FBUFF] V!      \ set where the file will load VDP Ram
               [PAB FNAME] VPLACE  \ set file name
    : SAVE-FILE ( file$ len VDPaddr #bytes -- ior)
           W/O100 NEWPAB  6 FILEOP  30 ^PAB +! ;
    : LOAD-FILE ( file$ len VDPaddr size -- ior)
           R/O100 NEWPAB  5 FILEOP  30 ^PAB +! ;


    • Like 2

  11. 6 minutes ago, GDMike said:

    What I had in mind was this...

    Step 1. Gather my routines and get them altogether to assemble using AORG >3000 as Lee suggested and save them out as dF80.

    I can load this at program boot, START


    Step 2. And find each routine's beginning address. Easy enough.

    (Each routine ENDS with a  KSCAN and Branch out to my mapper procedure at a high address, somewhere around >E000).

    And my program can call any routine address with a B @ >3456 or whatever and already mapped and ready to load the routine from the bank which is already predetermined.

    as Lee also suggested, try cramming as many routines as possible into that 4K space, and maybe I can get by with a low load Time.

    but, in my case, TIpi loads fast enough and I don't forsee a long wait for the ONE time load(Even in steps of records).



    So the E/A loader would load the code block as object code?

    If you have the way to do it, saving the data as a binary program, or converting the object to a binary program, would mean FOXIT could load the 4K block itself when it starts in about .5 seconds. 


    Wouldn't that be  BL @ >3456   ? 

    • Like 1

  12. 2 hours ago, Lee Stewart said:


    I think it should be separate EA/5 program files of 4 KiB max each (essentially overlays) that are each AORGed at >3000 (your SAMS window), which can be patched together into one DF128 file for later loading into SAMS banks, 4 KiB at a time (with one call each 4 KiB), via Level-2 Subprogram >014. You could also load to SAMS via Level-3 READs, but that would require reading 32 records, one at a time.



    Since I never work in conventional assembler, I am curious if it would be worthwhile to give the 4K overlays some kind of jump table at the top so you could call the code by number?

    Of course that means you need a standard calling sequence for each one too so maybe too complicated. (?)


    • Like 2

  13. 7 hours ago, Tursi said:

    Classic99 is fairly generous when it's loading, check the debug log after loading to see if it threw any warnings. The real TI of course doesn't care and just does whatever it's told, whether valid or not. You could also post a file that complains and we can check the headers for you.


    Thank you.  So far it is every file generated by my DOS cross-compiler, but none that I save from Camel99 Forth.

    To be fair the code is entirely different. The DOS version is clunky from when I was just getting back to this stuff. 


    Here is one the JS99er complains about.

    Ignore the error on startup. It's just looking for the START file that is like autoexec.




    • Like 2

  14. 21 minutes ago, TheBF said:

    I think I might have found an earlier version of JS99er. It defaulted to TI BASIC and Editor/Assembler in the menu.

    That's the one that gave me the "too short" message.


    I have not learned how to add cartridges to JS99er to use it for my purposes. 

    I will look for some docs. 

    So now that I know how to use the emulator a bit I have found that programs I create with Camel99 Forth like theMatrix demo load fine on JS99ER.

    The Camel99 program that is cross-compile with my DOS compiler are called "too short".

    So I will be spending some time learning what I have wrong in my cross-compiler. :) 

    Interesting that TI-99 and Classic99 load the files. 

    I suspect there is something wrong with the cross-compiler as it was my first journey back into TI-99 space.


  15. 1 hour ago, Asmusr said:

    Where does it say that?

    The first version doesn't work for me but the second does.

    BTW there's no need to use a disk image, you can just click 'Load disk' and select the zip file.

    I think I might have found an earlier version of JS99er. It defaulted to TI BASIC and Editor/Assembler in the menu.

    That's the one that gave me the "too short" message.


    I have not learned how to add cartridges to JS99er to use it for my purposes. 

    I will look for some docs. 

  • Create New...