Jump to content

Willsy

Members
  • Content Count

    3,144
  • Joined

  • Last visited

Posts posted by Willsy


  1. : TEST  1 GMODE  1 SCREEN  5 3 12 COLOR
    7 0 DO  I 11 +  0  I 40 +  32 HCHAR LOOP
    BEGIN  HEX
     DATA 10 FF00 0 00FF 0 0 0 0 00FF 0 0 0 0 0 0 FF00 0  28 DCHAR
     DATA D 0 0 0 0 0 0 0 FF00 0 0 0 0 0         2C DCHAR
     DATA 10 00FF 0 0 00FF 0 0 0 0 0 FF00 0 0 0 0 0 0  28 DCHAR
     DATA A FF00 0 0 0 0 0 0 0 0 00FF            2C DCHAR
     DATA B 0 FF00 0 0 00FF 0 0 0 0 0 00FF       28 DCHAR
     DATA D 0 0 FF00 0 0 0 0 0 0 0 0 0 FF00      2C DCHAR
     DATA D 0 00FF 0 0 0 0 FF00 0 0 0 0 0 FF00   28 DCHAR
     DATA F 0 0 0 0 00FF 0 0 0 0 0 0 0 0 0 00FF  2C DCHAR
     BREAK?
    AGAIN ;
    TEST
    

     

    It's a bit quick. Still, plenty of cycles left for other processing I suppose!


  2. While we're talking about features, I have one that I think/assume would be fairly trivial to add?

     

    Can we have a 'warm reset'? I.e Reboots the TI but does *not* zero the RAM in the TI. In other words, it would mirror the behaviour of turning off the console, but leaving the PEB switched on? This would make post-mortem crash investigation easier in some circumstances (i.e. buffers would still be present in memory for inspection etc).

     

    So, I would propose to rename the current Reset entry in the File menu to Cold Reset, and add a Warm Reset menu entry as well.

     

    Just to be clear: Clearly *some* memory would be changed in RAM (mostly in pad) even during a warm reboot - there's nothing that can be done about that, that's just the TI running it's ROM ;) - I'm just talking about skipping the initialisation of memory to 0 during start-up.

     

    As a total aside, not associated with Classic99, it's interesting the note the different behaviour of the TI 32K memory card and the SAMS card. When I power up my system with the TI card in (from power off) memory is mostly 0, with the odd FF in there. However, the SAMS memory is almost completely randomised! It's all over the place!

     

    Thanks


  3. I don't want to piss off the few that did purchase the card though.

     

    Don't worry about that. By making the software available you increase the chances of people writing software to target the SID99, be it an emulated one or a real one. That's good news for SID99 owners like me! :thumbsup:

     

    My card has died :? The card itself appears to be working ok, just no sound. I suspect the SID chip itself, which I bought from FleeceBay... I'll probably buy another sid chip in the next week or so and give it a try. My card is in slot 1 (next to the PSU) - it does get quite hot in there... Perhaps I should move it to another slot...

     

     

    Ouch. Try re seating the card a couple of times and /or changing it's location. Also clean the fire hose connection. That audio line path may be dirty/corroded somewhere.

     

     

    Ooh! Good point, I'll give that a try, thanks!


  4. I don't want to piss off the few that did purchase the card though.

     

    Don't worry about that. By making the software available you increase the chances of people writing software to target the SID99, be it an emulated one or a real one. That's good news for SID99 owners like me! :thumbsup:

     

    My card has died :? The card itself appears to be working ok, just no sound. I suspect the SID chip itself, which I bought from FleeceBay... I'll probably buy another sid chip in the next week or so and give it a try. My card is in slot 1 (next to the PSU) - it does get quite hot in there... Perhaps I should move it to another slot...


  5. I just want to give a great big shout-out to everyone in the TI-99 community. Not only do you guys create some incredibly cool stuff that really pushes the envelope for what the system can do and amazes me non-stop, you guys all seem to get along great and everyone contributes in a positive way to everyone else's projects. This is hands-down the best programming group and computer enthusiast group of gentlemen I have ever seen.

     

    :thumbsup: to the TI-99/4A crowd for being so cool!

     

    Thank's we appreciate it a lot ;)

     

     

    Hmmm, you are an Atariage site moderator.

     

    Pushing my luck now: Any chance you could add us as a news topic on the Atariage main page. The TI-99/4A and this group can for sure use some publicity :D

     

    Yeah, that's true. The 4A community is a great community; mostly because we have 'known' each other for years. However, there's not many of us. It would be lovely to get some new blood into the community!


  6.  

    Wow! I like that one! I managed to implement it with a little extra functionality and fit it into the spare space in bank 1 with 2 bytes to spare!

     

    Thanks

     

    So will you consider a 32K (4x8) ROM for the future version of Turboforth? Here's an idea, perhaps add the possibility for loading screens from ROM.

    You could use the remaing space to include a standard library of words with super-duper fast access. I don't think the 64K EEPROMS are that much more expensive than 16K EEPROMS nowadays.

     

    The current TurboForth lineage will end with V1.1 I think. I've taken it as far as I can in 16k.

     

    TurboForth 2.0 will probably be 32 or possibly 64K. If I ever start it. Some of the features:

     

    * Compile Forth code to native machine code (not threaded code) with inlining of certain words (e.g DROP DUP SWAP etc would be inlined).

    * Multi-tasking

    * Bitmap mode

    * A full suite of DOS words built in (DIR, COPY, TYPE, FORMAT etc)

    * Save/load memory image files

     

    It will essentially be a self contained alternative operating system on a cartridge.

     

    Marc Hull's idea of a multi-banked cart with RAM on it is the target (for me). Multi-tasking requires each task to have its own set of private variables, which can eat RAM, so the idea of 4K of ram in the cartridge is attractive.

     

    Since Marcs cart contains Flash memory, you could also load/save/edit code to 'virtual blocks' contained in the Flash memory chip. You would have access to around 200 blocks actually on the chip, living inside the cartridge. If these were compiled and BSAVED then they would load instantly. :-)

     

    We'll see. ;)


  7. Does anyone have any suggestions for a random number generator in assembly language? A routine that generates a number between 0 and 65535 would be fine.

     

    I'm not satisfied with the Forth routine I have been using in TurboForth, so I'd welcome any suggestions.

     

    If anyone has any ideas, and the routine is short enough, I'd like to add it to the TF V1.1 code.

     

    I'll check MicroPendium etc but I thought I would give a shout out in case anyone has code already done, that they don't mind sharing.

     

    Cheers

     

    Mark


  8. May the Forth be with you.

     

    Okay...now we need a t-shirt

     

    Like this one? They're bloody expensive though - I don't set the prices, unfortunately. I ordered one for myself, so we'll see how it goes. I was going to get some done as gifts, but they're just too expensive... I looked at CafePress also, but their editor is rubbish :(


  9. Okay. I'm emulator only, so when things get stuck, I'll just reset the emulator. And then I didn't know/expect having to hold the "break" for a while. All good.

     

    :)

     

    No problem ;) - the only reason you have to hold break for a while is that I am only testing the break key at the end of the loop :)


  10. That's by design. You can only "break" a program in TF if the program designer allows it ;-)

     

    There are two words associated with breaking a program:

     

    BREAK? ( -- )

    Scans for FCTN+4 and terminates the program immediately if detected.

    (So, with BREAK? TF will stop the program for you)

     

    TERMINAL? ( -- true|false )

    Scans for FCTN+4 and pushes TRUE if detected, else FALSE.

    (So, you can *detect* a break condition, and then decide what to do in your code)

     

    : BREAK-TEST
     0 BEGIN  DUP . 1+ BREAK? AGAIN ;

     

    : TERM-TEST
     0 BEGIN  DUP . 1+ TERMINAL? ABORT" Break was pressed - see ya!" AGAIN ;

    (in this code, the true/false pushed by TERMINAL? is fed into ABORT" - look up ABORT" in the gloassary ;)

     

    FCTN+QUIT is disabled, because it is evil! :P

     

    You can test for it though. KEY? returns 5 when you press QUIT... So...

    KEY? ( -- keycode )

    : TEST 0 BEGIN DUP . 1+ KEY? 5 = ABORT" Quit was pressed" AGAIN ;

     

    ;)


  11. Thought I would show some of the programming concepts in TurboForth. Most people will be able to follow this, I hope ;)

     

    1 GMODE  1 SCREEN \ 32 column mode, black screen
    
    \ define a hatch shape...
    : HATCH DATA 4 $AAAA $5555 $AAAA $5555 ;
    
    \ set up characters 144 to 248 with hatch pattern...
    : SET-HATCH  248 144 DO  HATCH I DCHAR 8 +LOOP ;
    SET-HATCH \ execute SET-HATCH
    
    \ define a list of colours for our patterns
    CREATE COLORS \ this creates a dictionary entry called COLORS
    \ if you *execute* colors, it returns an address to the stack
    
    \ we will now compile a list of color values (bytes) directly
    \ to memory...
    2 C,   3 C,   4 C,   5 C,  6 C,  7 C,  8 C,  9 C,  10 C,  11 C,
    12 C,  13 C,  14 C,  15 C,
    
    \ at this point, we have effectively created an array called
    \ COLORS. COLORS returns an address, which is the start of the
    \ list of data compiled above.
    
    \ now we will set up the colors using the list...
    0 CONSTANT TRANSPARENT
    : SET-COLORS 14 0 DO 
       I 18 +  \ color set number
       COLORS I + [email protected] \ fetch a color from the list
       TRANSPARENT COLOR \ set the color with transparent BG
     LOOP ;
    SET-COLORS \ execute SET-COLORS
    
    \ we can now remove ALL of the above code and data from memory.
    \ we dont need it any more...
    FORGET HATCH
    \ the above removes everything from HATCH downwards from
    \ memory, by resetting the dictionary pointers appropriately.
    \ the code below will compile over the top. This is a nice
    \ 'overlay' technique to save memory.
    
    \ scroll directions...
    0 CONSTANT LEFT  2 CONSTANT RIGHT
    4 CONSTANT UP    6 CONSTANT DOWN
    
    \ random number generator...
    $8379 [email protected] VALUE SEED 
    : RND SEED 31421 * 6927 @ +  $8379 [email protected] TO SEED ;
    
    \ initialise screen coordinates and character code...
    0 VALUE X   0 VALUE Y   144 VALUE CHR
    
    \ clear the screen in a fancy way...
    : WIPE
     16 0 DO
      0  0 16 12 PANEL   LEFT SCROLL
     16  0 16 12 PANEL  RIGHT SCROLL
      0 12 16 12 PANEL     UP SCROLL
     16 12 16 12 PANEL   DOWN SCROLL
     LOOP ;
    
    : KSCOPE  PAGE \ clear the screen
     BEGIN
       RND 300 MOD 1+  0 DO \ random repeat loop
         \ get random x & y for upper left quarter of screen:
         RND 16 MOD TO X   RND 11 MOD TO Y    
       
         \ display character CHR at x and y:
         Y X CHR 1 HCHAR
       
         \ display in lower left quarter:
         23 Y -  X CHR 1 HCHAR
       
         \ display in upper right:
         Y  31 X -  CHR 1 HCHAR
       
         \ display in lower right:
         23 Y -  31 X -  CHR 1 HCHAR
    
         \ add 8 to CHR. if CHR>248 then reset to 144:
         8 +TO CHR  CHR 248 > IF 144 TO CHR THEN
       LOOP \ go back to BEGIN until finished
       WIPE \ clear the screen
     TERMINAL? UNTIL \ repeat, unless FCTN 4 is pressed
     PAGE ." Thanks for watching!" CR ;
    

     

    Just paste into TF and type KSCOPE. Press FCTN 4 to break.

     

    A more compact version of the code, with comments removed follows. Note how the first section of the program is essentially a 'script', and we only retain the second half in memory.

     

    1 GMODE  1 SCREEN
    : HATCH DATA 4 $AAAA $5555 $AAAA $5555 ;
    : SET-HATCH  248 144 DO  HATCH I DCHAR 8 +LOOP ; SET-HATCH
    CREATE COLORS
    2 C,   3 C,   4 C,   5 C,  6 C,  7 C,  8 C,  9 C,  10 C,  11 C,
    12 C,  13 C,  14 C,  15 C,
    0 CONSTANT TRANSPARENT
    : SET-COLORS 14 0 DO  I 18 +  COLORS I + [email protected]  TRANSPARENT COLOR 
     LOOP ;  SET-COLORS
    FORGET HATCH
    
    0 CONSTANT LEFT  2 CONSTANT RIGHT
    4 CONSTANT UP    6 CONSTANT DOWN
    $8379 [email protected] VALUE SEED 
    : RND SEED 31421 * 6927 @ +  $8379 [email protected] TO SEED ;
    0 VALUE X   0 VALUE Y   144 VALUE CHR
    : WIPE  16 0 DO
      0  0 16 12 PANEL   LEFT SCROLL
     16  0 16 12 PANEL  RIGHT SCROLL
      0 12 16 12 PANEL     UP SCROLL
     16 12 16 12 PANEL   DOWN SCROLL  LOOP ;
    
    : KSCOPE  PAGE
     BEGIN
       RND 300 MOD 1+  0 DO
         RND 16 MOD TO X   RND 11 MOD TO Y    
         Y X CHR 1 HCHAR          23 Y -  X CHR 1 HCHAR
         Y  31 X -  CHR 1 HCHAR   23 Y -  31 X -  CHR 1 HCHAR
         8 +TO CHR  CHR 248 > IF 144 TO CHR THEN
       LOOP  WIPE  TERMINAL? 
     UNTIL  PAGE ." Thanks for watching!" CR ;
    

     

    Enjoy :D


  12. What I want to do today is take a DV80 file and edit it with XB and output a DV 80 file, why does it always end up a 1 sector DV80 file?

     

    The file I have has excess stuff in it from a sector dump like the crap at the front and end, I just want to convert it to data statements.

     

    Why is this so hard to do with Classic99? This program worked like a charm on a real TI.

     

    The only reason I was using my Real TI was Classic99 just will not allow it, what am I doing wrong?

     

    100 OPEN #1:"DSK2.EAASM1",INPUT

    101 OPEN #2:"DSK3.EAASM1",OUTPUT

    110 LINPUT #1:I$

    120 X$=SEG$(I$,10,48)

    130 PRINT #2:X$

    140 GOTO 110

     

     

    This is a sample of the DV 80 file:

     

    00000000 FF FF 20 00 20 00 AA 55 20 04 04 20 28 9E 00 00 .. . ..U .. (...

    00000010 00 00 00 00 00 00 00 04 10 80 00 00 00 00 00 00 ................

    00000020 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

    00000030 00 00 00 00 00 00 00 04 10 80 50 50 00 00 00 00 ..........PP....

    00000040 20 8B 13 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............

    00000050 00 00 00 00 00 00 00 00 11 80 00 00 00 00 00 00 ................

    00000060 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

    00000070 00 00 00 00 00 00 00 02 12 80 00 00 00 00 00 00 ................

    00000080 00 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

     

    I do not get why this program will not work?

    Firstly, you are not closing the file after you have finished writing to it. That is SERIOUSLY bad. You would almost certainly lose records, even on a real TI.

     

    Secondly, it depends how you have set up DSK3. Check out the file options for DSK3.


  13. What I want to do today is take a DV80 file and edit it with XB and output a DV 80 file, why does it always end up a 1 sector DV80 file?

     

    The file I have has excess stuff in it from a sector dump like the crap at the front and end, I just want to convert it to data statements.

     

    Why is this so hard to do with Classic99? This program worked like a charm on a real TI.

     

    The only reason I was using my Real TI was Classic99 just will not allow it, what am I doing wrong?

     

    100 OPEN #1:"DSK2.EAASM1",INPUT

    101 OPEN #2:"DSK3.EAASM1",OUTPUT

    110 LINPUT #1:I$

    120 X$=SEG$(I$,10,48)

    130 PRINT #2:X$

    140 GOTO 110

     

     

    This is a sample of the DV 80 file:

     

    00000000 FF FF 20 00 20 00 AA 55 20 04 04 20 28 9E 00 00 .. . ..U .. (...

    00000010 00 00 00 00 00 00 00 04 10 80 00 00 00 00 00 00 ................

    00000020 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

    00000030 00 00 00 00 00 00 00 04 10 80 50 50 00 00 00 00 ..........PP....

    00000040 20 8B 13 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............

    00000050 00 00 00 00 00 00 00 00 11 80 00 00 00 00 00 00 ................

    00000060 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

    00000070 00 00 00 00 00 00 00 02 12 80 00 00 00 00 00 00 ................

    00000080 00 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

     

    I do not get why this program will not work?

    You are not closing your output file (#2) at the end of the program. Why?

  14. Buffers in the flex interface, or in the console.

     

    I imagine the memory cards, TI and SAMS will use the +12V line in the PEB and regulate it down to +5V so check the voltages on the PEB power rails. This is difficult to do, because you need to do it with the cards in - in other words, the power supply has to be loaded or otherwise it will look like it's fine when it might actually be weak under heavy load.

     

    There's a circuit board of electronics in the PEB associated with the PSU, but I'm not sure what it does.


  15. I would say it's the 9901 chip.

     

    You really need a multi-meter. You could try examining the solder joints round the male keyboard connector on the motherboard. If you have a soldering iron, melt them and re-make them, in case the 5V or 0V lines have gone open-circuit.

     

    Otherwise, it would be impossible for the *entire* keyboard to not work, since the keyboard is actually a number of seperate circuits IIRC. It's a purely mechanical device, with no electronics on it. So the fact that no keys works at all would tend to imply that

     

    a) The keyboard is not getting a power supply

    b) The 9901 is faulty

     

    If it were the 9901, one would expect the whole machine to just lock solid, and not even boot, but the 9901 has to be a suspect in this particular fault.

     

    You can buy two 9901's for $18 plus shipping here: eBay Auction -- Item Number: 2208240446361?ff3=2&pub=5574883395&toolid=10001&campid=5336500554&customid=&item= 220824044636&mpt=[CACHEBUSTER]

     

    Mark


  16. I'm too wrapped up in the world of Forth at the moment to take anything else on. I'd be happy to do something after that though, probably in about 6 months.

     

    How's the book coming?

     

    Not too bad. Still loads to do though :( The problem is that I chose to make it difficult for myself! The book not only teaches all the TurboForth words, it also teaches *Forth*. I considered this essential as most people in the (current) TI community don't know Forth, so without a book to teach them Forth programming they wouldn't be able to do anything more than 'kick the tyres' and then they would lose interest.

     

    *Hopefully* the book will show them what Forth *is*, show that it's not as difficult as it looks and encourage people to sit down and give it a good spanking, rather than kick the tyres!

     

    Mark


  17. Today I finished my first enhancement for classic99. It's nothing fancy, you have to start small :D

    I've added the possibility to save and load breakpoints from a file. Here's a screenshot:

     

    post-16219-0-70127100-1313178180_thumb.png

     

    I'm hoping that Tursi is accepting patches and that my coding quality isn't too bad :ponder:

     

    Woah! Hell of a job RetroClouds! Nice one!

     

    I also added a new function to Classic99. It's called

    bool ready=makeCupOfTea(bool sugar);

     

    Sadly, it only works in the UK. My C skills are not up to the job of

    YACK ready=cupOfRancidPiss(coffee);

    which seems so popular across the pond ;) :D

×
×
  • Create New...