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

Sdw

Members
 View Profile  See their activity

  • Content Count

    86

  • Joined

  • Last visited

Posts posted by Sdw

  2. Posted

    I think one of the requirements should be "works on real hardware". Also, I'm quite jealous of those coders that seem to allow multiple colors on the same playfield row :P

     

    All demos work perfectly fine on real hardware, I've run them personally using my Harmony cart.

  3. Posted

    The Sillyventure Atari demo party in Poland last weekend had a dedicated compo for 2600 demos.

    Four entries competed, but I've only been able to find three of them released online.

     

    1st place: ISO by JAC!

    http://pouet.net/prod.php?which=58044

     

    2nd place (my entry): Sphaera Stellarum by Noice

    http://pouet.net/prod.php?which=58034

     

    3rd place: Minute and a Bit by Tjoppen

    http://pouet.net/prod.php?which=58038

     

    Links contains both download to the ROMs and video recordings ready for viewing!

    • Like 7

  4. Posted

    I've just released a new demo for the Atari VCS/2600 (PAL).

    You can view a full-framerate video capture here:

    http://capped.tv/noice_mystic_bytes-sv2k11_invitro

     

    Or you can download the binary:

    http://www.ag1976.com/files/noc_msb-sv2k11.zip

     

    Code by Shadow/Noice (that's me....), graphics by Piesiu/MysticBytes^Agenda and music by Jakub Husak.

    This is my first experiment with bankswitching (using F8-scheme).

     

    (btw. notice anything peculiar with the scroller? :))

  5. Posted

    What is more common/would you suggest: Code for NTSC or for PAL? And will NTSC code run and display correctly on an European (PAL) real 2600?

     

    The Atari 2600 demo scene (the few of us there are...) tends to work for PAL, so I'd recommend going with that.

    At least on my 2600jr NTSC carts just produce rolling image, so if you want me to be able to see your demo, go with PAL! ;)

  6. Posted

    Thanks for your comments.

     

    Maybe I should have mentioned that this was for a demo, because I agree that for a game there is no need to hold back, just use whatever is necessary.

    However, when doing a demo the goal is often is about stretching an old machine to see what can be done and then it might be considered cheating to utilize modern hardware.

     

    But it seems like both those bankswitching methods were available back then, even if not used extensively.

     

    I think I'll start with the FA one as it was much more straightforward. 256 bytes should hold me over for a while anyway! :)

     

    Btw. nice to see you here as well JAC! I heard that maybe you were working on a 2600 demo as well, seems like there were some truths to those rumors then! :)

  7. Posted

    I have been messing around a bit with 2600 development. At first I used only normal 4k cart as target, now I've moved on to a F8-style bankswitched 8k cart target as I needed some more space.

     

    Lately I've been reading up a bit about the different bankswitching schemes and the fact that some of them also had extra RAM.

    And some extra RAM would open up some interesting possibilities, that's for sure!

     

    I do my testing in Stella and then on a real 2600 with a Harmony cart, so almost all bankswitching modes are available to me - however, I'd like to stay "historically correct", that is, not use any fancy features that has been invented after the commercial life of the 2600, or that would not have been commercially viable to produce back then.

     

    I've been looking at:

    FA (CBS RAM+, 12kb ROM and 256 bytes RAM)

    E7 (M-network, ??kb ROM and a whopping 2kb of RAM)

     

    Were any of these widely used back in the day (say up to the mid-80ies or so) so that I can use them with a clean conscience?

  8. Posted

    Nice to see that the demos found their way to this site as well! (I'm the coder of the Noice demo btw.)

     

    Regarding scroller, I'm not at all familiar with bB (I prefer pure asm for all oldschool platforms). However if what ilmarque says about 26 bytes RAM limit is true, then it would be difficult. My scroller uses least 32 bytes of RAM if I recall correctly (6 bytes x 5 rows = 30 bytes for storing the playfield data, 1 byte for the finescroll value and 1 byte to keep track of the position in the scrolltext).

  10. Posted

    Nowadays we are spoiled with fast crossassemblers where we can edit our code on highres screens on PCs.

    Then we fire up Stella and get all the debug info we need, and then just put the .bin file on a SD-card and put it in our Harmony cart to testrun on real hardware.

     

    But how did things look back in the 70ies/80ies?

     

    Anyone know what host systems were used for assembling the binaries?

    How was the result then code tested? I know there are prototype carts, so I'm assuming EPROM burns were done, but was that the only option or were there any special "dev"-versions of the console where you could load code via a serial cable to RAM instead or something?

  11. Posted

    I've had mine for almost exactly on year now (bought one of the production samples, so I got in early! :D) and it is indeed a wonderful piece of hardware.

    If only all other retro systems had such cheap, professional and easy-to-use solutions, my homebrew development would be so much easier!

  12. Posted

    I have a 2600jr (PAL version).

    It seems to have a very weird sound issue. It works perfectly for a while, but after maybe 5 minutes or so, some sounds starts to sound 'off', ie. being cut off, and then maybe 30 seconds later, they are totally gone. However, not ALL sound is affected.

     

    For example, say I play Asteroids. At first everything sounds fine, the shot-sounds from the ship, the 'music' or whatever you call that beep-beep-beep sound, and the explosions when the asteroids are hit.

    After a couple minutes, the shot-sounds and music start to sound strange, and then completely disappear. The asteroid-explosions however still sound fine, and continue to do so.

    Turning the machine on/off does not help, it needs to be turned off for a long period of time.

     

    What could be causing this? To me, it almost seems like one of the sound channels only is affected (can anyone confirm this, ie. does that match my Asteroids-experience)? Also since it is dependent on the time the machine is on, maybe it could be some component gone bad (capacitor?) that fails when it reaches a certain temperature.

    As you can tell, I'm just guessing! Are there some known hardware error that gives this behavior and that I could try to fix?

  13. Posted · Edited by Sdw

    I am very interested in this, but have a couple of (maybe stupid) questions:

     

    • Will this be sold via the Atariage shop, or are you handling it yourself?

     

    If it is not via the Atariage shop, the following questions apply:

    • Will you ship to international destinations (Sweden in my case)
    • If so, what approx will the shipping costs be (don't want to preorder a $50 item if it costs another $50 to ship it!)
    • What payment options will be available, Paypal perhaps?

  15. Posted

    I think I got things working:

     

    frameloop:
  // Start of vertical blank processing
  lda #0
  sta VBLANK
  lda #2
  sta VSYNC

  // 3 scanlines of VSYNCH signal...
  sta WSYNC
  sta WSYNC
  sta WSYNC

  lda #0
  sta VSYNC		  

  // 37 scanlines of vertical blank...
  lda #127+44
  sta TIM64T
  
  // DO VARIABLE TIME STUFF HERE!!!
  
!wait:   
  lda INTIM
  and #$80
  bne !wait-
  sta WSYNC
  
  // 242 scanlines of picture here (not included)...   
  
  // end of screen - enter blanking
  lda #%01000010
  sta VBLANK		
  
  // 30 scanlines of overscan...
  lda #127+35
  sta TIM64T
  
  // DO VARIABLE TIME STUFF HERE!!!
  
!wait:   
  lda INTIM
  and #$80
  bne !wait-
  sta WSYNC

  jmp frameloop

     

    At least in STELLA it seems to display a stable 23712 cycles/frame, which I guess means things should be OK.

  16. Posted

    Well,

    since some of the mentioned demos are Gr.9 or GTIA demos, it might be you have a faulty GTIA chip. These faulty GTIA chips are very common in XE computers that were built in China. The Abbuc forum also shows some nice pics, even if you cannot read/understand german language scroll down to the pics - pic 1, 3 and 5 shows correct GTIA (how it should be) and pic 2, 4 and 6 shows the faulty GTIA...

     

    http://www.abbuc.de/modules.php?name=Forum...opic&t=4275

     

    greetings, Andreas Koch.

     

    Looking at those pictures it seems that a faulty GTIA is much more severe than what I have.

    Actually, if you look closely at the first "good-GTIA" picture of Demo 1 in that forum thread, you can see this luma-line in the middle there as well, looking very similar to mine so it must be a common issue.

  17. Posted

    Nice project batari! Good to hear that there might be an alternative to the Chimera. I need something so I can test my homebrew, at the moment I use EPROMs, but I have no UV-eraser, so I have to be VERY selective on when it is time to test something! :D

     

    Do you have any idea on which price-point it might end up at? Are we talking like $50 or so, which means that even a casual developer like me would be interested in picking one up, or is it more of $200 premium item for the hardcore crowd?

  18. Posted

    I've seen that behavior on my 1200xl composite video, and was very thrilled that it was gone after I did the video upgrade. I remember this demo in particular, "EXE" showed the problem, a single dark line messing it up, really annoying.

     

    http://atari.fandal.cz/detail.php?files_id=325

     

    Yes! I noticed it in that demo too. Also in for examle this:

     

    http://atari.fandal.cz/detail.php?files_id=5198

    and this:

    http://atari.fandal.cz/detail.php?files_id=5545

    it was very visible. Well, I guess it will be extra visible in any demo that uses those GTIA 16-gradient modes, as you often get the luma 7->8 transition there.

     

    Anyway, thanks to all for the info, good to know at least that it is a common problem and not a hardware failure.

  19. Posted

    So much for that theory!

     

    How'bout this one: luma bits turn off faster than they turn on? The GTIA luma outputs appear to be open-collector because they have pull-up resistors, so this theory makes sense.

     

    I'm not that knowledgeable about hardware, so what you said about open-collector and pull-up was a bit beyond me, but something is strange, that's for sure! ;)

    I just got my SIO2PC so I've been able to run some demos/games/programs now, and this artifact is visible and rather annoying in many things that use smooth gradients. Has anyone else seen anything like this on their machine, or is it me that has ended up with a faulty HW?

  20. Posted · Edited by Sdw

    I'm a newbie when it comes to 2600-coding, but I've got some 6502 experience from C64 coding and after spending a few hours glancing through the Andrew Davie tutorials (very good btw!), I have a general grasp of things and have got some code up and running.

    However, I was wondering - is there no way to be able to run segments of code that you don't have cycle-exact predictions for? During the drawing of the screen I guess you need to be in cycle-exact mode, however in the overscan and VBL areas, I'd like to be able to do something like start a timer or set an IRQ (but the 2600 doesn't have any IRQs...?), then run some code that I know will take less than 30 rasterlines (but not EXACTLY how much) and then somehow use the timer/IRQ to get back in sync for the three lines of vertical vertical synchro or start of screen, depending on if you are in VBL or overscan.

    Can this be somehow done? Or is the only solution to split your code into segments that are less one scanline of cycles and use a series of STA WSYNC and keep the line-count intact?

     

    -edit-

     

    Well, what do you know, I might have been onto something after all. I found this quote in the "main" 2600 programming forum:

     

    But for the most part, the timer is usually only used to time the overscan and vertical blank periods. Set a timer, do a whole lot of stuff involving branches, then eat up the remaining time...each frame will reach the end of the loop at exactly the same time.

     

    That is pretty much exactly how I wanted it to work. Now I need to learn how to set up the timer, what values are appropriate for a full VBL/full overscan (I'm programming for PAL)?

  21. Posted

    Notice that the worst artifact is between luma values 7 and 8, where all 4 luma bits change. Apparently the lower bits change faster than the upper bits, so the luma goes darker before it gets lighter. The effect is less noticable between lumas 3 and 4 and between 11 and 12, where only 3 bits change. To test this explanation, plot the bars in reverse order and see if the artifacts are light instead of dark.

     

    That's an interesting theory! I did the test and here is the result:

     

    videotest_130xe2.jpg

     

    Looks like the artifacts are still dark. However you are definitely onto something with the bit values, because even in this direction, the worst artifact is in the 7->8 transition.

    Also note that the other interference-looking stuff is coming from taking the picture. Other than the darker lines, the image looks good in real-life.

  22. Posted

    So I bought myself a little christmas present - a 130XE! So at age 32 I own my first Atari computer ever (about time, eh?)

     

    Now I've read quite a bit about that dreaded GTIA-bug, but as I understood it, it mostly concerned the 65XE model.

    Anyway, I typed in the little BASIC test-code I found here:

     

    (Polish Atari site I think, auto-translated to English)

     

    My computer displays all different gradients correctly, however there are small (can't tell if it is exactly 1 pixel or what) dark regions between some of the gradients. Here's a photo of the screen:

     

    videotest_130xe.jpg

     

    However if I change the code to show the gradients as long horizontal bars instead, the artifact is not present.

    Am I right in assuming this is some kind of TV-intereference or something, and not a faulty GTIA since it only appears between vertical bars?

  23. Posted

    P.S.: The faulty XE`s (65XE, 130XE and 800XE) were all "made in China" in 1991 and they have faulty GTIA`s (with GTIA modes gr. 9, 10, 11 not working correctly)... think most if not all of these XE`s were PAL versions for the eastern european market...

     

    Is it enough to check for a "made in china" sign somewhere on the computer to spot a computer with a faulty GTIA or is there some other way to make sure...?

    Right now I have a couple of computers that I'm considering putting a bid on, and I'd want to have something that I can ask the seller to make sure it is a correct GTIA without him having to do the whole "hook computer up => download demo that use GTIA => transfer to Atari => test run"-deal.

  24. Posted

    Thank you Allas, that was a comprehensive report!

    So there was a bit of difference between the very first models, good to know. Now I will be looking for a computer with GTIA chip (and preferably expanded to 64kb or more) but the model isn't really that important.

    However I recall reading something about some specific European models (I'm in Sweden, so I'm looking for PAL models) came with a faulty chip?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...