Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Willsy

Members
 View Profile  See their activity

  • Content Count

    3,144

  • Joined

  • Last visited

Posts posted by Willsy

  1. Posted

     

    KMODE is a variable and typing it puts its address on the stack.

     

    ...lee

     

    So how does one set the keyboard mode in TF? The online reference states that KMODE places the address of the keyboard mode variable on the stack, but does not give any further details. I wanted to change the mode to 1 (split keyboard), so I entered 

    KMODE 1 SWAP !

    and I got no errors. However, the keyboard mode remained in the default 5 (BASIC mode). What am I doing wrong here?

     

     

    1 KMODE SWAP !

     

    **edit**

     

    Cancel that...

     

    KMODE is a variable. I thought KMODE popped a number off the stack, THEN acted upon it.

     

     

     

    That should work; but, it's convoluted! It's simpler to do this:

     

    1 KMODE !

     

    The variable, however, appears to not be functioning as documented. The value I get from KMODE after booting up is 1280—not 5! @Willsy is gonna have to weigh in on this one.

     

    ...lee

     

    I see I neglected to answer this one. The answer is that KMODE pushes an address, but the keyboard mode is in the UPPER 8 bits of that address!

     

    Gotcha!

     

    Try this:

     

    kmode @ .

     

    You should see 1280. Hmmm...

     

    Now try this:

     

    kmode @ $.

     

    You'll see 500. In other words, 5 in the high byte and 0 in the lower byte (the display suppresses leading zeros unless you override it with true zeros !)

     

    I've updated the language reference page for that one, as it's sure to catch others (including me, since my brain is fried) :D

  2. Posted · Edited by Willsy

    Absolutely. I was just thinking about saving space (as usual ;) ). But there's no doubt your approach would be much faster.

     

    I should really have a look at getting TF to run with interrupts enabled (or, at least give the option). Last time I tried that (a looooong time ago) it crashed everything so hard I had to have a little look out the window to make sure the universe was still okay.

     

    That's how hard it crashed! :grin:

    • Like 1

  3. Posted

    Hiya. Yes interrupts are normally disabled in TF. However the speech routines in TF are interrupt driven. TF only enables interrupts during vdp access (strictly speaking, just before the vdp access takes place). Thus you need to 'pump' the vdp to ensure that the ISR runs. Speech is really only used in games which hammer the vdp anyway so it's never been a problem. Not yet anyway.

     

    83C2 is a flag to the TI OS which enables specific portions of the ISR. You can disable sprite motion, sound list processing, and the quit key. By default TF turns them all off so that the ISR in ROM returns as fast as possible to TF.

  4. Posted

    The attached plays the sounds, but the explosion doesn't sound right. Is the sound list data correct?

     

    Also, is the grab fuel sound correct? If so, no real point in using a sound list for that! Just use SOUND with a short delay.

     

    Have you seen these rather funky sound commands? You can do cool stuff with loops.

     

    Nayway, here's the code. I removed the machine code LIMI 0 and LIMI 2 stuff, because it's not really needed. Most VDP accesses in TF trigger vdp interrupts, so putting [email protected] in your loop is enough ([email protected] does a LIMI 2/LIMI 0 internally).

     

     

    hex
\ Sound effects data
: SndGrabFuel ( -- addr #cells )
 data[ 0385 0690 0102 8F08 0102 8506 0101 9F00 ]data ;      
: SndMonsExplode ( -- addr #cells )
 data[ 05C7 09DF E7F0 0101 FA01 05C7 09DF E7F0
    0101 FA01 05C7 09DF E7F0 0101 FA01 019F 0000
  ]data ;
 
\ Sound generation routine
: PlaySound ( sound_list -- )
 1000 -rot 2 * vmbw      \ load sound list into VDP sound buffer @ >1000
 1000 83CC !             \ place VDP sound buffer address in >83CC
 83FD [email protected] 1 or 83FD c!    \ indicate VDP sound buffer loaded
 1 83CE c!               \ place 1 in >83CE - start sound processing
 40 83c2 c!              \ enable ISR engine for sound lists
 begin 0 [email protected] drop 83CE [email protected] 0= until \ loop until processing done i.e >83CE is 0
    8000 83c2 !             \ disable all ISR routines
    ;

  5. Posted

    There's a couple of things:

     

    • Sprite auto-motion, sound-list processing and the QUIT key are all disabled by writing >8000 to >83C2
    • Other locations in PAD ram may need to be set up that aren't - or (worse) have TF code in them

    See the PAD RAM memory map on the web site.

     

    I'll see what I can figure out over the next couple of days.

  6. Posted · Edited by Willsy

    If you're getting a black screen and tones then I would say that the 9900 CPU is not initialising. The first areas I would look at would be the 256 byte RAM chip and the ROMs. If either of those has failed, then nothing will work. I'd check the RAM chip first. If those check out okay, check the 9900 cpu. I've never known a CPU to blow though.

  10. Posted · Edited by Willsy

    (Actually... that's a hell of a good debugger idea for any target address.... ;) )

     

    Well, since you mention it, yes it is ;-) It would make ripping music/sound effects and speech especially simple... :thumbsup:

  12. Posted

    What would be VERY VERY nice is if Classic99 (or some other emulator) could capture the data streamed out to the speech synth into a file. Then, it would be possible, using Text to Speech, to say a particular phrase and capture the resulting LPC and take that and put it in your own program.

  16. Posted

    Here's a tested Forth Assembler version. :thumbsup:

     

     

    variable BITMSK   $8000 BITMSK !
 
asm: doRLE ( rleSrcAddress vdpDestAddress -- )
    *sp+ r0 mov,                \ get vdp address
    r0 $4000 ori,               \ set vdp write bit
    r0 swpb,                    \ get low byte
    r0 $8c02 @@ movb,           \ write to vdp address reg
    r0 swpb,                    \ get high byte
    r0 $8c02 @@ movb,           \ write to vdp address reg
   
    r0 6144 li,                 \ counter
    r1 clr,
   
    r9 $8c00 li,                \ vdp write register
   
    *sp+ r8 mov,                \ get pointer to rle data
   
    begin,
        r8 *+ r1 movb,              \ get control byte
        BITMSK @@ r1 coc,           \ packed or unpacked?
        eq if,
            \ packed
            r1 $7f00 andi,          \ get count
            r1 swpb,                \ move to low byte
            r1 r0 s,                \ update counter
            begin,
                r8 ** r9 ** movb,   \ write a byte
                r1 dec,             \ decrement counter
            eq until,               \ loop if not finished
            r8 inc,                 \ point to next control byte
        else,
            \ unpacked sequence - r1 contains count
            r1 swpb,                \ move count to low byte
            r1 r0 s,                \ update counter
            begin,
                r8 *+ r9 ** movb,   \ write a byte
                r1 dec,
            eq until,
        endif,
   
        r0 r0 mov,                  \ check count
    eq until,                       \ loop if not finished
;asm

  22. Posted

    If it sounds like something you're comfortable with, I'd love to take your F18A renderer in -- saves me a BIG step. :)

     

    Damn right! Andif a new F18A implementation executed 9900 like the actual F18A did, that would be awesome! (Might struggle getting 100mhz out of it though!)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...