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 · Edited by Willsy

    Attached is a conversion of Thierry Nouspikel's GPL manual from his website (the document contains appropriate attribution).

     

    I've done quite a lot of re-formatting, corrected a litany of spelling errors, added table of contents etc.

     

    It's a work in progress. Still more work to do on it, but it's a start. If anyone wants to chip in, feel free. Download it, edit it, and send back to me as a PM.

     

    Thierry's manual is split into two HTML files. I'm going to work on merging the second file into this file, so that it's all in one PDF. The PDF will be hyperlinked.

     

    Updated 2nd February 2016: Indexed and linked. Much better. Some formatting improvements. Still some linking to do: GPL Manual.pdf

     

    Mark

     

    Previous Version:

    GPL Manual.pdf

    GPL Manual.zip

    • Like 5

  3. Posted

    Right. That's the perl interpreter, XDT99 assembler installed, and your additional files. PATH environment variables set. I used different paths so edited the files as per your instructions.

     

    ALL WORKING! Just assembled prog1G and it worked like a goodun!

     

    :thumbsup:

    • Like 1

  4. Posted

    Of course. It does everything the TI-99/4A ever did, just with a better quality picture. If you don't want to use the additional facilities of the F18, then that's totally cool. Just seeing the 4A displayed on a VGA monitor with absolutely perfect picture quality is enough to sell anyone on it IMO.

    • Like 1

  15. Posted · Edited by Willsy

    http://www.theregister.co.uk/2016/01/08/windows_10_upgrade_blocker/

     

    The instructions are official from Microsoft. Neat. Do it before Windows 10 is pushed onto your system as a mandatory update, which, according to the article above, is going to happen soon.

     

    From what I've seen of windows 8 and 10, Windows 7 is my last dance with the Microsoft operating system. It's Linux or Mac OS next.

    • Like 1

  19. Posted

    The early clock would make collision detection with background a real pita as you'd have to correct for the early clock before checking background characters.

     

    It would be best implemented at the TF kernel level rather than the application level. The kernel could account for early clock and do the horizontal correction such that it's transparent to the application. The application does not want a sudden jump in horizontal coordinates by 32 pixels. It needs a logical horizontal coordinate system implementation on top of the physical system. Perfectly doable with relatively little impact.

  22. Posted · Edited by Willsy

    One for the guru's: What is the condition of the EQ bit after executing this:

    LI R0,>0011
LI R1,>2233
MOVB R0,R1

    Subtle eh? The byte moved into R1 is 0, so R1 contains >0033.

     

    Now the question: Since this is a BYTE operation, and we moved a 0 to the destination, does the EQ bit go on, or does the CPU check all 16 bits of R1 for 0 and set the EQ bit accordingly?

     

    As usual, the Editor Assembler manual is absolutely pathetic on this point.

  24. Posted

    Considering some of the regularity of the sounds we are creating, and the fact that the sounds generated by the Spectrum have tones with a higher resolution than 1/60s, I postulated on the idea of a custom sound routine which would just throw the requisite data at the 9919. It looks like resolution used for Jetpac on the Spectrum is somewhere between 1/90s and 1/120s. As a result the sounds from the game are more complex than can be easily recreated in an interrupt-driven player.

     

    What can TF do toward this end?

     

    It's a bit of an un-known quantity really.

     

    I decided to bite the bullet and write my own sound list processor/driver. Here it is:

     

     

    asm: soundListPlayer ( -- )
    \ re-entrant. Uses r0 to remember state:
    \ 0 = doing nothing. Waiting for a sound list to be loaded
    \ 1 = loading sound bytes to sound chip
    \ 2 = counting off duration counter
    $2000 lwpi,
    r0 r0 mov,              \ have a sound list to process?
    ne if,
        r0 1 ci,            \ loading sound bytes?
        eq if,              \ yes
            r1 *+ r2 movb,  \ get number of bytes to send to sound chip
            r2 8 srl,       \ move to low byte
            eq if,
                r0 clr,     \ if 0 then we're finished
            else,   
                begin,
                    r1 *+ $8400 @@ movb,    \ send a byte to the sound chip
                    r2 dec,                 \ decrement counter
                eq until,       \ loop until finished
                r1 *+ r3 movb,  \ get duration byte
                r3 8 srl,       \ move to low byte
                eq if,          \ processed everything?
                    r0 clr,     \ reset state to 0 (idle)
                else,
                    r0 2 li,    \ set state flag to counting
                endif,
            endif,
        else,
            \ we're counting off duration
            r3 dec,         \ decrement duration`
            eq if,          \ hit zero?
                r0 1 li,    \ set state to load sound bytes
            endif,
        endif,
    endif,
    $83e0 lwpi,             \ restore GPL's workspace
    r11 ** b,               \ return via R11
;asm

     

    It occupies a whopping ( :grin: ) 86 bytes. How cool is that. It plays regular sound lists in the TI format.

     

    'Yall probably don't know, but TF has built into it a user ISR hook. When an interrupt fires, it first checks to see if there's any data to pipe out to the speech synth. After that, it checks CPU ram location >A008 for an address. If there is an address in there (i.e. it's non-zero) it branches to the code at that address, hence you can run your own machine code on the VDP interrupt.

     

    So, the little sound driver above is pretty cool. It's re-entrant, and stateful. It manages it's own state. You can analyse the code to see how it works, but very briefly, the driver has 3 states:

     

    0 - idle - nothing happening

    1 - loading sound bytes into the sound chip

    2 - counting off duration ticks

     

    To play a sound, put an address of a sound list on the stack, and call playSoundList - as long as there is some vdp access going on, it'll play the sounds.

     

     

    : playSoundList ( address -- )
    $2000 @ 0= if       \ if r0 of ISR=0 (not playing a sound list)
        $2002 !         \ set R1 of user ISR workspace with sound list address
        1 $2000 !       \ kick off sound processing
    then
;

     

     

    Note: As you can see, playSoundList as written will only play a sound list if it's idle.

     

    You can query the driver with soundBusy? to see if it's idle. You might want to do this before initiating a sound.

     

     

    : soundBusy? ( -- flag )
    $2000 @             \ load R0 of user ISR workspace
;

     

     

    So, boot TF, load the assembler from the blocks file (9 LOAD) and paste the text in the attached text file in, and then try:

     

    airBurstSnd playSoundList

     

    and

     

    groundBurstSnd playSoundList

     

    and

     

    inFlightSnd playSoundList

     

    I cannot take credit for the example sound list data. I took it from The Art Of Assembly, from the chapters on sound lists, which is a lot easier to understand than TI's load of old cock. The code is my own though.

     

    Oh, one thing to note: The driver above does NOT require the sound list to be placed in VDP ram. It reads it directly out of the compiled data list. Much more efficient.

     

    I've tried it from the command line and it's perfect. However, when you enter something on the command line TF just sits there flashing the cursor. That is quite a short loop, and interrupts are enabled and disabled in that loop. I would expect it to be more jittery in running code.

     

    Walid, I was thinking, wrt to Jetpac: Do you call the delay routine in the main loop of your game anywhere? If so, it would be a great place to do some dummy vdp access to fire the vdp interrupts. So, instead of:

     

    : delay ( n -- ) 0 do loop ;

     

    You could have:

     

    : delay ( n -- ) 0 do 0 [email protected] drop loop ;

     

    You would have to shorten your delay loops in your code, but interrupts would fire the delay loop without a doubt. That might be all you need to remove the jitter.

     

    Note that JOYST also fires the interrupts.

     

    Entire source code attached. I have't produced a CODE: version of the assembler code, but 'yall know how to do that.

     

    Rock on. Time for bed! :)

     

    sound list driver.txt

    • Like 3
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...