Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

456 Excellent

About danwinslow

  • Rank
    River Patroller
  1. 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.
  2. 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.
  3. 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.
  4. Pedgarcia - yes that list ^ is the correct one.
  5. He just lowered it to $500...lol.
  6. 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
  7. 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.
  8. Steve's a great guy, and I really like RealDos and use it a lot. Glad to hear he's back in commission.
  9. 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.
  10. Good stuff, Thanks Yaron. I assume this is with the latest version of the compiler?
  11. 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.
  12. 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.
  13. 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.
  • Create New...