Jump to content

Shawn Jefferson

  • Content Count

  • Joined

  • Last visited

  • Days Won


Shawn Jefferson last won the day on January 5 2011

Shawn Jefferson had the most liked content!

Community Reputation

257 Excellent

About Shawn Jefferson

  • Rank
    River Patroller
  • Birthday 12/22/1973

Contact / Social Media

Profile Information

  • Gender
  • Location
    Victoria, Canada
  • Interests
    Atari, Karate, IT Security, vintage gaming, old british cars (MGB)

Recent Profile Visitors

20,431 profile views
  1. I would really love to see games ported to my most beloved platforms, like the Atari Lynx (and Atari 8-bit computers), but generally I can understand why programmers aren't jumping up to do these ports. You have to really, really like a game to spend the time to port it to another platform, especially without source code. It's probably better to write a game based on a similar idea, so you won't have to deal with all the people that will tell you all the things you did wrong in porting it, how it doesn't play 100% like the original, look as good, control as well, etc. The lynx, while having great graphics hardware, has some crippling drawbacks: the small screen, and the cartridge system, which makes it fun but also frustrating to code for. So you also have to love the platform you're porting to as well. Whenever it does get done, and done well, like the Space Harrier port to the Atari 8-bit, I'm amazed and happy to see it.
  2. Your code also becomes non-reentrant, which means that you have to be very careful with leaf functions. I suppose that would have to be a somewhat complex program though (??), but still, that may be a nasty surprise if you aren't ready for it. On the Moria port, I had to be careful of that when I was moving local variables from the stack into zeropage. I believe I did find a few examples where I couldn't move the variables easily off the stack. Using the register keyword avoids the problem I mentioned above, but there are only 6 bytes available (I shouldn't have said 6 register variables, since an int will use up two byes. And the code to push and pull them off the stack that allows your functions to be reentrant. A good compromise solution for some extra speed without changing the program much. I thought posting a reply would be good for anyone who's looking at CC65 for programming, and add to the points you made in your document. I didn't think you'd needed the advice, you've been using the suite for a long time now! I've been away from it for a while now, but I do have a more recent version I should upload that has some bugfixes and more polishing. There's still a bit left to do, to truly call it done. They are an interesting game genre, and I played them a lot through high school and at jobs where I had only had a monochrome PC at work.
  3. Very nice article @ilmenit! That should be very helpful for people who are programming in cc65. I wasn't sure if you mentioned __fastcall__, but that may be a default behaviour of cc65 now. I find that if you are used to the way that cc65 does things, you learn to program in the "cc65" way. Generating assembly listings and map files when you compile is mandatory, and you should get in the habit of looking at them to figure out what cc65 is doing both from a code generation point of view, but also memory usage (in larger projects). In larger projects I don't see how you can really use static locals (you'll run out of memory), but maybe there would be some cases where that might work. When I was porting Moria to the Atari 8-bit, mostly I started optimizing in this order: 1. Making sure all the data types were the smallest possible (unsigned char instead of int). 2. Using the register keyword to have some local variables in zeropage (cc65 only has 6 zeropage "register" variables), and there is a little overhead to save and restore the contents. Usually loop variables and pointers are good candidates. 3. Any large local variables, were changed into globals. Some of those could be shared (if very careful), like buffer string space. 4. Moved heavily used globals to zeropage, both to optimize memory and speed. 5. Lookup tables, for speed mainly. 6. With Moria, I needed space and would often be trying to eke out bytes to get things to fix in cartridge banks. Including making sure that read-only data was stored in the cartridge bank and not in the main memory RODATA bank. Memory management is a huge thing with a small 64k machine.
  4. I ported Moria v5.5 to the Atari (using the VBXE2 for the 80 column mode), which is likely a similar problem to Rogue. One of the big things you will have to deal with is the 40-column screen. Most of these rogue-likes were written for an 80-column screen and you will face a lot of issues porting to a 40-column screen. Another thing is the memory use. In Moria I am doing A LOT of cartridge banking, as well as VBXE banking. The map itself is around 24k in Moria, and is dynamically created each time you enter a level. There's one function in Moria that had to be split across two cartridge banks even. The game was just not designed for small memory footprint computers. I've started working on a 40-column port of Moria, but the game is going to have to be changed quite a bit, even to the extent that the names of the items will have to change as some of them are much longer than 40 characters and just won't fit on the screen even. I got a bit disillusioned with that though and basically stopped, but I may pick it up again someday.
  5. Time Pilot 46,000 The controls take a bit of getting used to, that's for sure! Never played it in the arcade, neat game.
  6. Hi Karri, LOWCODE is used on quite a few targets that have banking windows, like the Atari 8-bit. It just ensures that code that needs to be "low" in memory, is in fact in low memory. The Atari 8-bit has standard banking windows at $4000, $9000 and $A000. I believe that IRQ code in the library would be in LOWCODE so hopefully it doesn't get banked out during an interrupt. On the Lynx it isn't really required since there's no concept of memory banks, but this became standard in cc65 since quite a few of the targets have the same issue. I'm not entirely sure when that happened. You could just change that to "CODE" on the lynx if that's an issue.
  7. I doubt they have the rights to this game as well.
  8. Does cc65 still use environment variables to locate the lib and include dirs?
  9. Karri, with what you know about the Lynx, do you think it's possible? I guess you'd have to load data in an interrupt, and then you'd have to deal with the block/offset issue. For an 8-way scrolling game that is going to be pretty ugly... there's probably no good way to organize the data for faster loading. I haven't actually looked at the SDcard API, so maybe it would be possible, and practical... I guess someone will have to do it to prove it can be done. One thing that probably would be possible and quite interesting, is to release a game that could load levels from SD card, so that users can create their own levels and just put them on SDcard along with the ROM of the original game. Or an RPG with additional maps/quests, etc...
  10. I looks like he is just counting up to 75 in _playtime, and when that reaches 75, he increments _playtime+1, and when that rolls over to zero, he increments _playtime+2. That's a pretty common method of time keeping, used in the Atari 8-bit computer OS too. You then just have to grab the value of _playtime in your mainline code, and then grab it again, subtract the values and do some division to get elapsed time. It's easier if the VBI is running at 60hz.
  11. I think it opens up some possibilities for games to have very large maps or more levels, but not much else unfortunately. On the Lynx everything has to fit inside the 64k, and you can't use the trick of bank-switching the cartridge into a large memory space (8k/16k) like on other consoles or computers. Loading stuff from the Lynx cartridge is also not very fast-it's not random access. It acts much like a tape drive (the original design I believe), and you actually have to "seek" to the location in the block that you want to load into memory, by reading the values from cartridge and discarding them. It's one of the (beloved/hated?) limitations of the Lynx.
  12. It's not possible for anything on the cartridge to do DMA to the lynx RAM, the "cartridge" is presented in memory as one byte and is not memory mapped like on other systems. What's possible on other systems is not possible on the Lynx for this reason. It's great that you have these ideas, but you should read up on the hardware design to ground them in some reality as well. That taxi demo isn't "streaming" the video from the cartridge, since that is really impossible (from what I know about the hardware... someone could correct me if I'm wrong and explain how that would work.) Yea, it would be cool, but we're stuck with a legacy from when the Lynx designers wanted to put a tape drive in Handy. (dumb)
  13. Now you are really talking about a program with only two users... Nice work on the zx emulation, makes me wish I had to rapidus.
  14. This sounds like "sector skew", which I believe some of the 1050 enhancements could also do, but mostly it wasn't used much from what I remember, since while it could speed up disk operations on one type of drive, another might end up being slower. Once we all had Happy drives, we were reading a track at a time anyway.
  • Create New...