Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by danwinslow

  1. Lots of cool stuff! But there's a difference between how many colors are possible in things like static pictures and splash screens and how many colors you can use for game programming purposes and still have system resources left over to run the game.
  2. yknow, I actually think this is part of why the A8 scene is still so active. The flexibility offered by the hardware allows people to come up with amazingly clever stuff, and it produces a real sense of accomplishment. If you use a machine that has a hard-defined and well known set of pre-determined graphics capability, then there's nothing to do. There isn't the same sense of the possible. So yeah, I agree, it's confusing and technically hard, but that's part of the draw. If all you want to do is plot pixels in colors then there's any number of modern machines available.
  3. I'd like a slightly ironic yet somewhat amused reaction, the kind that makes people wonder if you're being sarcastic or not.
  4. I think part of it is also that this 'spread out too much' effect is a side-effect of trying to do a truly 100% responsive UI that can seamlessly go on all devices. We have the same exact issue with our in-house product. Like others have said, I am reserving final judgement and I'd also like to thank Albert for all this hard work. I'm sure whatever we wind up with will be fine...I may not like it all but I'll get used to it I'm sure.
  5. Not a fan so far. The 'unread content' thread presentation is my most disliked aspect. So giant and blocky and facebook-ized, and it looks nothing like the forum list of threads. In general, so far I have to say I dislike the visual presentation. It seems like the same bad UI philosophy change that's been percolating through technology for the last 5 years or so...giant blocky wastes of screen space with big flat colorful buttons every where. I think that somebody somewhere back then decided that we can't handle dense lists, plus they are all desperate to turn everything into a phone. I'm sure the technical underpinnings are a big improvement, though, and I'll eventually get used to the visuals if history is any guide.
  6. From a developer's perspective : I never have done any 2600 programming, but I've watched a lot of in depth discussions go by here on AA. I get the impression that because the system is SO minimal, and SO hard to get anything playable on, that it becomes a real accomplishment to produce anything that's enjoyable to play. I've seen threads where people get into such depth that it's like watching a bunch of Zen masters discussing reality or a roomful of physics geniuses arguing about why string theory is a waste of time (it is). A 2600 programmer has to control every single last thing, and the opportunity for making a clever hack or doing something that no-one's ever thought of is very high. I mean, if I write a game to move balls around and do collisions with bricks using a modern computer and something like Visual Basic, I'd just get a pat on the head and congratulations for not being a complete moron. If I do the same on the 2600 from scratch, that's impressive. Some people like really hard stuff.
  7. Pedgarcia - yes that list ^ is the correct one.
  8. He just lowered it to $500...lol.
  9. I think this : https://www.kryoflux.com/ Is the key piece in the ultimate ability to preserve old floppy's...it's a magnetic flux recorder so it preserves everything period no matter the format or protections. You might want to contact the Atari Disk Preservation group here on AA, I know they take bulk media for preservation: http://atariage.com/forums/topic/234684-atari-8-bit-software-preservation-initiative/page-1?hl=+disk%20+preservation
  10. I suggest googling with the following keywords: ebay ibm 5.25 floppy drive unless I misunderstand, there's a ton of options, and not all on ebay, either.
  11. Steve's a great guy, and I really like RealDos and use it a lot. Glad to hear he's back in commission.
  12. i think the UV will 'bleach' some by snapping apart some of the pigment compounds, but it's also destroying the polymer integrity. UV is pretty active on organic bonds of all sorts.
  13. Good stuff, Thanks Yaron. I assume this is with the latest version of the compiler?
  14. Kurt Vendel might have some info about low-level corvus stuff, I know nothing about it, except that it had it's own add-on board in one of the 800 slots, which very well might have had buffering and a co-processor of some sort...maybe even a PIA...? *edit* I was thinking of the ADS Integrater http://atariage.com/forums/topic/182024-corvus-interface-ads-integrater/, that's the board, but it allowed BOOTING from the corvus. Here's some info on the actual interface, which was a separate device : The Corvus Hard Drive system exploited a little used ability of the powerful interface ports on the Atari 800 computer system. While almost everyone else was using the interface ports for plugging joysticks into and playing games. Corvus Systems used a very simple interface using about a dozen gate-chips to communicate with the PIA interface through joystick ports 3&4 of the Atari 800. Using a specially modified version of Atari DOS 2.0d (most users only had access to DOS 2.0s) or using an OS replacement board by David Small (Creator of MagicSac Mac emulator for the Atari ST's) called "The Integrator" an Atari 800 computer could access and use the Corvus hard drive as 8 DS/DD disk drives. If "The Integrator" was used, the OS board could be set to boot off of the Corvus hard drive and no 810 disk drive would be necessary. So I guess the ADS Integrater actually was a replacement for the external box.
  15. For my 2 cents, I think that an external component or add-on board of some sort is required here. Midi is a serial connection as far as I know (which isn't all that far), obviously works well enough for midi-maze but if it's significantly different from just SIO I don't know how. My experience with attempts at direct SIO networking lead me to believe it's not a good solution, especially for things like game traffic. Even when supported by an external TCP stack with an SIO interface, it just doesn't cut it for stuff like action games. Maybe if supported by a really fast SIO implementation it could work, but I never tested with anything above the standard SIO speeds commonly available. I would like to see a PBI device with a co-processor, thus avoiding the SIO part. On the device you could have a bare chip like the cs8900a or one of the available all-in-one TCP stack chips. The PBI device would directly drive the chip and would support bus-speed access to the data packets. If someone made the hardware, I'd gladly try to write a driver. PIA networking is a cool idea, but I think a lot of the comments about available CPU are valid. I also think that if it were really possible and worked well, then somebody would have done it by now.
  16. It's been a long time since I did any BASIC, but I think you can dim a string and then go into the symbol table and mess with the address such that BASIC thinks it is at the screen data location. Maybe that would allow faster processing, but not sure. I do think it would be pretty easy to have a small USR routine (with or without the string manipulation above) that would be REALLY fast.
  17. Wow, speaking of ambitious....seems kind of unlikely, but you never know I guess. *edit* Oh, I see, at first I thought it was like unity 3D world engine. Still seems kind of ambitious but he did do that racing game. Will check this out.
  18. Right, it will unroll and or remove some stuff during optimization. I always kept if off when debugging.
  19. That certainly works, but I'm not sure you can see the C source lines using CC65 compiler. Maybe that's been solved since last I tried. Yaron, my advice is to just go ahead and put in the effort to learn to code in assembler. C is easier, of course, but my experience has been that if you're doing any serious game programming you'll find you need to drop into assembler a lot anyway. I have done low-level stuff in CC65 like mouse drivers and communications, but the extra cost in size and speed is really not worth it in the end. When going for speed, you'll get to the point where you're pretty much using C as just a macro assembler anyway and at that point you might as well just write it in assembler. For a long time I switched to using C as just a wrapper around a bunch of assembler, because I wasn't sure how get the executable format directly from assembler, but there's tons of reading material and I eventually figured it out.
  20. I'm pretty sure that any code you find in C for that kind of thing would actually be mostly inline assembler. Also, 4 is a character mode, so smooth movement on a pixel basis is difficult but just moving the character is very easy, since the computer takes care of rendering the character bit pattern. I don't have any source handy, but I've experimented with mode E a bit. My efforts are nowhere near expert but I will say that lookup tables of various sorts (screen line address, mult and divide, color masks, etc.) are a requirement.
  21. For me it's partly nostalgia, but also it's just sheer admiration of how hard it is to make games for it. There's so little to work with, if you see an engaging game on the 2600 you know what kind of genius-level tomfoolery is involved.
  • Create New...