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

  5. Posted

    I'm developing some new stuff, and I'm currently experimenting with the Tigervision style bankswitching.

    When doing a 16kb Tigervision ROM (7 switchable 2kb banks first, the one static 2kb bank at the end) it works fine in Stella as long as I force 3E or 3F in the "Game options". However, on my Harmony cart, no matter if I use the .3e or .3f extension, the ROM does not work properly at all, it doesn't boot.

    I then padded it up to a 32kb ROM (15 switchable + 1 static) and it works fine in both Stella and on Harmony.

     

    Is there some issue with the Harmony and 3F 16KB Tigervision? In theory this bankswithcing scheme could work for any cart size that is a multiple of 2kb, but I guess this is not the case?

  6. Posted

    As the release of "Spaceman Splorf" draws closer, I've unfortunately had the following report regarding the NTSC version:

     

    "I’ve been testing the game on a 6-switch 2600, and it has been just fine. Readying for the show, I was going to use a 4-switch 2600, but for whatever reason, the game loses its vertical hold during game play (not on the main title screen)Have tried this on two 6-swtich units, and it works fine, and two 4-switch units which both have the vertical hold issue (on 3 different TV sets)."

     

    As I'm in PAL-land myself and only have a PAL2600Jr, I have no real way to test this. Linecount for the NTSC version is a steady 262.

     

    Anyone ran into this issue before?

     

    The only thing I can think of that I do that is "non-standard" is that ingame I have a displayable area that is a big bigger than 192 pixels (can't recall the exact count), but on the titlescreen (which apparently is working fine) it is a bit less.

     

    Could I be hitting some limit of minimum top/bottom VBLANK area size that is different on the 4-switchers compared to 6-switchers?

     

     

  9. Posted

    As I'm soon to release my first game, reading this topic has made me a bit apprehensive.

    Even if it's a quite simple game, the plan was to have a cartridge release as well, since, well, it's cool to have your game on physical media.

    And also for me, the actual making of money on something you have created just for fun is a cool feeling. As it is now, I will probably be looking at a $3 profit per cart sold, and if the game sells 10 copies, that means that one month when I pay my internet bill or something, I can think "well, this was actually paid for by the game!" :)

     

    Now, while the game is written in painfully hand-optimized assembler, it is a rather simplistic concept. We have tried to balance it and make it fun to play, and nice to look at, but it will not have every cool feature that everyone could imagine, and to me that is OK. I have other things I want to do, other demos and games I want to write, spending a year on polishing every detail to absolute perfection would make it "work". For me, creating games is "fun".

    • Like 1

  10. Posted · Edited by Sdw

    So there will by high score saving in the 2600 version too?

     

    Only in RAM. So you will need to have the 2600 powered on until everyone has had their go, or write it down on paper! :)

     

     

    If you are interested, you should share the code of the kernel, so that we can discuss potential improvement.

     

    Unfortunately it is hundreds of lines of seriously ugly code that is not fit for the publics eye! :)

     

    However, one of my main space-eating solutions is that I draw the player like this:

     

    lda (PLAYER_GRAPHICS_ZP),y

    sta GRP0

    lda (PLAYER_COLOR_ZP),y

    sta COLUP0

     

    Y-is the line counter in the kernel. Then I move the player up and down by modifying the ZP-vars. Works great and is very CPU-time efficient, but it means that I must have a buffer that is as high as my player, for both graphics and colors, and then duplicate this if I want more frames of animation!

     

     

    BTW: Any plans to use your new knowledge and create more games (or demos) for the 2600?

    I've actually written quite a few demos for the 2600 before, but this will be my first game.

    I will probably do more demos, and perhaps there will be more games, but I probably prefer democoding, where the challenge is to create the best looking visuals and any shortcuts can be taken, because you know *exactly* what is going to happen. With games, you have less freedom in the coding.

  11. Posted · Edited by Sdw

    Oh, forgot to comment on the 4kb question! The game will not be including the graphical intro from the C64, for space reasons.

    The game will still be an 8kb game though!

    It might be me that's not a very experienced coder, but writing the display kernel that allowed a player with single-line resolution move freely up and down a screen, and then have horizontal repositioning of the other objects (for asteroids and stars) while maintaining single-line resolution I ended up with quite a lot of duplicating code and large tables, so there's lots of ROM "wasted" on this. For me it was worth it though, to have the best graphical quality.

  12. Posted

    Thank you all for your comments.

     

    As for the suggestions for additions to the game, I understand that the game concept might seem a bit simple as it is, and it might not be for everyone, but the idea is to have a really, really easy to pick up "party" style game, where you get the controller and instantly know what to do!

    Press the button to go up, release to go down, avoid stuff, try to survive as long as possible to get a high score, and that's it!

    We had the C64 version up at a local gathering a while ago, and many seemed to enjoy it.

    As for the difficulty ramp-up, there was a bug in that in the version shown in the video, so it didn't quite work as expected.

    The game gets progressively harder, the asteroids spawn more often and move faster and faster the further you make it.

     

    Thanks Kylearan for the offer - I'll let Mermaid speak about the tracker itself, but the replayer is really good, light on both CPU time and memory usage, excellent!

  13. Posted

    A while ago I programmed a game for C64 called Spaceman Splorf, with graphics and music by Vanja Utne.

    Just for fun, we're now working on creating a version for the Atari 2600. we have tried to recreate gameplay and graphics experience as close to the original as you can come on the 2600.

    It's kind of a neat project, I guess this is what VCS coders way back had to deal with in many instances, trying to recreate something from a more advanced system within the constraints of the VCS/2600 hardware. :)

    Here's a preview video:

     

    https://www.youtube.com/watch?v=iCsrAk-R2LE

     

    You can read more on (and view videos) from the C64 original here:

     

    http://pondsoft.uk/splorf.html

    • Like 16

  14. Posted

    Thank you for your input guys!

     

    When it comes to PAL/NTSC, all my objects are using 16 bit coordinates, so I should be able to easily make the adjustments for 50/60Hz without going to PAL60.

     

    I will go with my 209 line display for now, perhaps try to track down someone with a NTSC console and TV to test it for me.

  15. Posted

    I am working on a small game, with versions both for PAL and NTSC.

    Since I'm in PAL-land, that's what I use for real-HW testing.

    Only using the "official" 192 lines of graphics leaves quite a lot of unused screen real estate on PAL, so I am trying to find a happy medium that shows at least some more lines on NTSC, but without losing too much on a normal TV.

    Right now instead of the standard 3VSYNC+37+192+30 for NTSC I am now running 3VSYNC+33+209+17, which is showing OK in Stella.

    Can someone who has developed and ran stuff on real consoles on NTSC TVs give any hint on how many lines you can see on an "average" TV?

    Is 209 lines completely out of the question?

  17. Posted

    Hello everyone!

     

    Finally my first "real" Atari 8-bit demo is done (I have released a small 1kb intro earlier this year, but now we are talking full-length demo :D)!

     

    Name: Triple Threat
    Groups: Noice^Agenda^Mystic Bytes
    Platform: Atari XL/XE, 128kb RAM
    Release Date: 2013-11-10
    Code: Shadow/Noice
    Graphics: Ripek/Agenda
    Music: BeWu/Mystic Bytes
    Coordination: Grey/Mystic Bytes

     

    http://www.pouet.net/prod_nfo.php?which=62125

     

    http://youtu.be/qGRj7YPpsQI

     

     

    62125.png

    • Like 13

  20. Posted

    I am trying to write some code that should run on a 130XE (and best case, other models with >=128kb RAM).

    I want full access to as much RAM as possible, so I run with PORTB ($d301) set to $F2 normally, that is BASIC off, OS off etc.

    That works fine, I can access all RAM except for $d000-$d7ff

    Now I am incorporating bankswitching as well, to gain access to the extra 64kb on the 130XE.

    The really strange thing is, I can't get the bankswitching to work without setting the lowest bit of PORTB, that is switching in OS stuff that eat up $c000-$ffff essentially.

     

    It makes no sense to me, in my test program I run with interrupts disabled (SEI) so there is no way that the CPU can be running code "without my knowledge", yet it still seems like it needs to have access to the OS for the bankswitching to work. WTF? What am I doing wrong?

     

    For example, this does NOT work, the second write to $4000 just overwrites the first.

     

    .pc = $3000 "Code"
sei
lda #$a2+0*4
sta PORTB
lda #$55
sta $4000
lda #$a2+1*4
sta PORTB
lda #$77
sta $4000

     

    However the following works:

    .pc = $3000 "Code"
sei
lda #$a3+0*4
sta PORTB
lda #$55
sta $4000
lda #$a3+1*4
sta PORTB
lda #$77
sta $4000

     

    ???

  21. Posted

    Alright, thanks for the info on bank-loading, I think I have the theory down, will need to sit down and implement some stuff soon!

    Going back to loading into "normal" memory, how high is it possible to go? Can you load all the way up to $cfff, or do you need to load one segment, run an init routine that disables OS and then load again? Or will disabling the OS mess up the loading altogether?

    Yeah, I know I could probably test all of this myself, but since I'm guessing people here already know the answers, it's easier to ask! :)

  22. Posted

    Thanks, I did as Rybags susggested and loaded to lower memareas and copied up afterwards.

    Now, a follow up question (that perhaps should have its own topic) - how do I load stuff to the additional banks on the 130XE?

    That is, I'd like to have data in that additional 64k as well, and now I can't solve this by loading and then copying afterward, as I need data in the lower 64k as well.

    Ideally I'd like to switch in a bank, load a 16kb segment, switch in another bank, load again etc. But is this possible somehow with the .xex format?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...