Jump to content

kenjennings

Members
  • Content Count

    849
  • Joined

  • Last visited

Posts posted by kenjennings


  1. 15 minutes ago, phaeron said:

    Double-checked on an 800XL that yes, you should see the text here.

     

    The reason this happens is that hires graphics are special in GTIA: they bypass the priority and palette lookup circuits and go directly to the output logic at the end, where they switch the luminance between the normal output and PF1. The priority logic only works at color clock speed (160 resolution) and only sees PF2 for the hires playfield regardless of the individual pixels. The result is that nothing ever blocks the hires layer, it tunnels through anything and everything and stamps PF1 luminance wherever it is active.

     

    As far as I know, Atari800 has also supported this effect forever -- at least as far back as Atari800WinPLus. If you aren't seeing it then either something weird is making the program run differently or you are using an old version of Atari800.

     

    Ok, my own stupid programmers' trick.  THANKS.  👍    Solution is to remove the text when not needed.

     

    I'm running atari800 4.2.0 on linux which is the last version I found on   https://github.com/atari800/atari800/releases

     


  2. Hi lo....  I recently did a new install on Linux, new eclipse, and fresh update of WUDSN.

    The Hex editor display only looks ok when the ASCII character set  is chosen.   If any of the Atari character sets is chosen it ends up with microscopic, tiny font that is not readable.

    I added Atari 8-bit true type fonts to the system and have used them in other programs.  I went into eclipse visual setting and was able to choose the Atari truetype fonts for Diff display.

    What font setting do I need to look for to set WUDSN's hex editor display?

     

     

     


  3. Having a problem that could very well be my own stupid programming trick.  (Altirra x64 3.90)  (Test configuration is NTSC Atari 800 OS-B, 48K).

     

    I have a line of ANTIC mode 2 text.   Rather than deleting the text from the screen, I just set the everything black ($00)  (COLBK, COLPF2, COLPF1).  

    When I put Players 0 and 1 over the place where this  text occurs in Altirra it looks like the text appears over the Players.

    I'm pretty sure that before this area of the screen  I have set PRIOR to $01 which should be normal GTIA mode, and the priority control that puts all Players over the playfield.

     

    So, I'm having a mental issue trying to figure out why the text is visible over the Players.  

     

    Earlier/higher up on the screen the code was using a DLI to game the GTIA 16 grey scale mode with 5th Player to make some color demo joy, and then this PRIOR setting is turned off.   Things on the screen below this point depend on normal GTIA color interpretation and it all looks fine, so I'm pretty sure the GTIA color interpretation mode does get set back to "normal".

     

    I've hacked up the DLIs to make sure  PRIOR reset is occurring, redundantly.  

    Below is a grab from the Altirra screen where the black text appears on the Players.

    The Blue background color is set immediately after the last occurrence of resetting PRIOR.


        lda #[GTIA_MODE_DEFAULT|$01]
        sta PRIOR

     

    where:

    GTIA_MODE_DEFAULT =  %00000000 ; Normal CTIA color interpretation

    and

    PRIOR =  $D01B ; Control Priority, Fifth Player and GTIA modes

     

    1nv_PMvMode2_screen.thumb.png.a8b7f433c851746c3723ceb57e02b9da.png

     

    and here is the GTIA layers visualization to make the text v Players more obvious.

    1nv_PMvMode2_gtialayer.thumb.png.e0139cd377e5e87c4d3b3bd1f9c30157.png

     

    Am I misunderstanding something about ANTIC Mode 2 and Players here?

     

    (and fyi, tested this on atari800 on linux which does not show the text above the Players, but it's known to not show things according to real hardware.)

     

    For reference, the current executable is at   https://github.com/kenjennings/Atari-1nvader/blob/master/ata_1nvader.xex

    It's just a graphics demo at the moment, not a working game.

     

    Thanks.


  4. 4 hours ago, Wrathchild said:

    @xxlNo real excuse for jumping directly into the OS these days?

     

    The $F2B0 routine in the XL OS is reflected in the Vector table at $E400 (so the E: PUT is at $E406), but stored as EOUTCH-1.

    Similarly SGETCH-1 is found at $E414.

     

    Is (was) the table guaranteed to stay there?   Would it be safer-ish, more compliant to get it from the open E: IOCB #0 table?   I've seen it done this way:

     

     
    IOCB = $0340 ; Base IO Control Block, Channel 0, E: by default
    
    ICPTL = IOCB+$06 ; Put char routine (low)
    
    ICPTH = IOCB+$07 ; Put char routine (high)
    
    ; . . . . .
    
    PutCH
    	sta OUTPUT ; Self modifying code - save the byte below.
    
    	lda ICPTH ; High byte for Put Char in E:/IOCB Channel 0.
    	pha       ; Push to stack
    
    	lda ICPTL ; Low byte for Put Char in E:/IOCB Channel 0.
    	pha       ; Push to stack
    
    OUTPUT = *+1
    	lda #$00 ; Modified at routine entry.
    
    ; This rts actually triggers calling the address of PutCH
    ; that was pushed onto the stack above.
    
    	rts 

     

     

     

     

    • Like 2

  5. I was wondering....   since you have four character sets. And you use a different characterset per line, but repeat the usage six times...

    0

    1

    2

    3

    0

    1

    2

    3

    . . .

     

    Wouldn't it be the same as just using one character set for six contiguous lines before switching character sets...

    0

    0

    0

    0

    0

    1

    1

    1

    1

    1

    1

    . . .

    Then there are fewer DLIs that need to change the current CHBAS.

     

    Thanks,

    Ken

     

    • Like 1

  6. 51 minutes ago, pseudografx said:

    Slightly off-topic:
    I remember seeing a demonstration of a side-by-side scrolling where half of the screen was scrolling (horizontally) in the opposite direction than the other. Can anyone remember that, too, and possibly know what the source thread was?

     

    Side by side in opposite directions.......  I can't think of a way to do that in hardware.  Maybe I lack imagination.   Pretty sure that would have to be done the hard way by actually drawing/updating the screen memory itself.  Maybe shifting images through a character set.  Either way it is still brute force code churning through memory. 

     


  7. 2 hours ago, Preppie said:

    Check out the rich dude! I dream of shopping in Asda, my shopping is done in Aldi :)0

    I love Aldi's.  That's the only place in South Florida that carries awesome groceries from Germany.   (My kid had to explain family heritage for a school project, and we spent days looking for a place to buy spaetzle.)

    • Like 1

  8. On 1/1/2020 at 5:24 PM, devwebcl said:

    That's the one I was thinking of.    I was bored at work and ported this to the PC and updated it to sort and draw filled triangles.  Pretty sure that disk is gone.  Then Turbo Silver came out on the Amiga and I stopped trying to write my own graphics software.

    • Like 1

  9. Of course it was broken.  I realized in the middle of the day that the DEC and flag checks for decrementing the length were a  broken, stupid idea.   Rebuilt.

     

    https://github.com/kenjennings/Atari-CheepTalk

     

    USR(39680)  is the CheepTalkInit routine for BASIC.

     

    USR(39728, ADR(STRINGVARIABLE), LEN(STRINGVARIABLE) ) is the CheepTalkSpeech routine for BASIC to pass the address and length of the phoneme string to the VBI.

     

    PEEK(39883) is a status byte that BASIC can check  to see if the VBI is busy running the speech. 

     

    • Like 2

  10. Just about done with V3.   Cut out a number of the ridiculously fast speed levels, so it is playable by mere humans with retired old people reflexes.  

     

    Last thing I'm working on it some weird screen flash when the frog reaches the safe beach at the top of the screen. 

    It doesn't crash, and it doesn't do the glitch every time.   But I need to find it  for OCD reasons.

     

    It's a pretty game but gets boring quickly.  Gameplay is intentionally limited to the scope of the original Pet game on purpose.   If I feel motivated to continue on to V4  that will add new things not done in the prior versions  -- other hazards, more animated things, etc.

     

    • Like 5

  11. I did a first pass at a simple BASIC interface for a VBI driver to run the speech synthesizer.

    It assembled (remarkably, first time), but I can't test this myself.  (No physical Atari available and no working CheepTalk).

    About 270 lines of assembly.  Any bets on if it actually runs?

     

    Code is here.

     

    https://github.com/kenjennings/Atari-CheepTalk

     

    The code is assembled at $9B00 (39680) through $9BC8 (less than one page.)   That is the page before the default GRAPHICS 0 display list for a 40K (or more) Atari running 8K Atari BASIC.   (Boot up with BASIC, go to DOS, binary load the AtariCheepTalk.xex file, then it should be in memory, and you can return to BASIC.  [I think].)

     

    USR(39680)  is the CheepTalkInit routine for BASIC.   It will set up the PIA port, and it will attach the VBI.

     

    USR(39728, ADR(STRINGVARIABLE), LEN(STRINGVARIABLE) ) is the CheepTalkSpeech routine for BASIC to pass the address and length of the phoneme string to the VBI.   The routine will sit and wait for the the VBI to finish sending a string to the speech synthesizer before loading up the address for the new string.   (Therefore, one string of phonemes at a time.  Do not modify/rebuild a string that is currently being serviced by the VBI.)

     

    PEEK(39876) is a status byte that BASIC can check  to see if the VBI is busy running the speech.   0 means the VBI is not servicing a speech string.  nonzero (2) means it is busy sending a string.

     

    • Like 2

  12. On 12/22/2019 at 10:16 PM, YB-49 said:

     

    Hello kenjennings.  A few weeks ago, I've pulled my A8 and ST gear out of the attic. After 30+ years, most of my floppies still work. I, too, built the voice synthesizer Cheap Talk based off the General Instrument SP0256 chip.  I had written some code in BASIC that assisted one in stringing together words and to make it sound halfway decent.  Yesterday I found my hardware and the software that I had written.  I intend to fire it up shortly to see if it still works. I would have liked to have seen your code- that Antic and Analog didn't publish!  I also found several more SP0256 chips still in the RadioShack packaging ready to go!

     

    Let me know if you still have the code you wrote, after all these years!

     

     

    - D

     

    Buried on a disk somewhere.

     

    I don't recall the  vertical blank driver being  very involved.   Keep a list of pointer to strings to send to the device, the number of bytes to send, and the current pointer.  Given the time to pronounce each phenome only one byte needs to go to the port each VBI at most.   I recall the only trick was that between hitting the bit to write to the port and then writing a value, the Atari had to do several NOPs for timing or the synthesizer would not get the value and then it would be saying gibberish. 

     

    I could probably retool this if I can find some time to look at the magazines' BASIC code to write the port.


  13. 27 minutes ago, +Adam+ said:

    Similar technique in GR.11 mode:

    - black + 15 hues which share the same luminance (playfield pixels)

    - black + 15 hues with another luminance (missiles as the 5th player over the playfield pixels, black is still black in this mode)

    - 6 colours of multicoloured players (additional colours made of P0+P1 pixels and P2+P3 pixels)

    Which means up to 37 colours in one scanline (picture attached, OlivierP palette).

    GR11_colours_in_scanline.png

     

    Are you done yet?  Anything more?    ;-)

     


  14. 2 minutes ago, +Adam+ said:

    Well, it's not really "the complete answer" :) - for example in graphics mode 9 one may use 38 colours in line (see the picture attached):

    - 16 shades of one colour (playfield pixels)

    - 16 shades of another colour (missiles as the 5th player over the playfield pixels)

    - 6 colours of multicoloured players (additional colours P0+P1 and P2+P3)

     

    GR9_colours_in_line_.png

     

    Super kewl.  I was not aware of that.  There's always another trick.  

     

    • Like 1

  15. 22 hours ago, PixelCrunch said:

    3: There can be X amount of colors on screen, but there can be multiple play fields to increase the amount of colors via Multiplexing.

     

     

    I don't completely understand this question.  The multi-plexing point suggests to me this question pre-supposes the capabilities of some other non-Atari, computer graphics hardware.  ( ? )

     

    Do you simply mean page flipping between two screens for each video frame?   This would be easy to do on the Atari, but it could also be done on any other computer that can monitor frame start, and switch screen registers/pointers.  The end result is simply the math of how many colors are present on each separate screen. That math would multiply out the colors the same way on any computer that supports the page flipping method.

     

     


  16. 22 hours ago, PixelCrunch said:

    2: There really can be only X Colors on screen at once, Perioid.

     

     

    Most of the time the palette is  128 colors, 8 shades of each base color.

     

    Using the GTIA option for 16 shades of one color, and interrupts to change the base color at different locations on the  screen this becomes a possible 256 colors.

     

    • Like 1

  17. 22 hours ago, PixelCrunch said:

    1: The Atari 8-Bit Series could have X Colors per Scanline (A-La The Atari 2600 and Atari Lynx) 

     

     

    The Atari hardware has several things than can be combined that can add/vary colors, so the simple answer to this is "it depends".

     

    The "Per Scanline" designation is important here, because all color options, and even graphics modes can be changed on each scan line.  Few games use only a full screen of a single graphics mode.  Multiple graphics modes mixed on screen is the norm.  Also, for the sake of the question this answer covers only what can be done strictly through inherent hardware capabilities that once set up requires no further CPU support to maintain.

     

    First, is the "normal" 14 graphics modes. Depending on the display mode there could be two, or four, or five colors (per scanline).

    However, Player/Missile graphics are separate color registers from the playfield and can add four more colors to this, so there could be up to nine colors (per scanline).  The Atari has nine color registers, so this would be the limit of colors created purely by color indirection (using the color registers.) (per scan line).

     

    BUT, different GTIA options provide other color interpretation possibilities beyond the "normal" modes.  This allows 9 colors as playfield graphics (using color registers), or 16 colors (all the same brightness), or 16 shades of one single color.  So, the answer can be sixteen colors (per scanline).

     

    HOWEVER, (there's always some other trick going on the Atari) color merging options in GTIA can mix playfield and player/missile graphics colors together, and the total number of colors possible doing this is 23 colors.  Nine of those come from color registers.  The rest of the colors are done by overlapping Player/Missile objects with each other and overlapping Playfield pixels with Player/Missiles pixels.  This would be a fairly contrived situation and has limitations, but it is do-able, and it is an inherent capability of the hardware.  So, the complete answer is the hardware can produce up to 23 colors (per scan line).

     

    • Like 2
×
×
  • Create New...