Jump to content

danwinslow

Members
  • Content Count

    2,893
  • Joined

  • Last visited

Everything posted by danwinslow

  1. 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
  2. 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.
  3. Steve's a great guy, and I really like RealDos and use it a lot. Glad to hear he's back in commission.
  4. 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.
  5. Good stuff, Thanks Yaron. I assume this is with the latest version of the compiler?
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Right, it will unroll and or remove some stuff during optimization. I always kept if off when debugging.
  11. 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.
  12. 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.
  13. 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.
  14. yeah, just buy a cheap soldering station of some sort, and do it. Practice on bits of wires, look at a few you tubes. Just tacking down one of the giant wires that the atari's use is not hard. You just have to practice a bit. If I can do it, anyone can, beleive me.
  15. Does that .so exist on your system? If not, you probably need to install the QT package. If QT is on your system, then you might have a bad LD_LIBRARY_PATH setting.
  16. I'm in for testing and eventual purchase.
  17. Looks very nice. No idea what kind of load it's putting on the cpu through. Is there enough left over for a game or is this strictly a demo? Either way, looks great, and well done.
  18. In 5 days? Some of these threads are lucky to get an update in 5 months.
  19. Definitely great interest here. Willing to help if I can in any way. I would suggest as a title : De Rursus Atari (once again atari).
  20. C is basically just a macro assembler anyway. Doing this stuff in C is the same as doing it in assembler for the most part. You will spend a lot of time driving the chips and registers with stuff like TIA.somereg = somevalue which is pretty much the same as LDA somevalue STA somereg You won't be able to use much of the C library, no printf's or fopens or anything like that. You won't gain anything in particular from using C anyways, other than the syntax for bit twiddling and testing if you know it better in C and some extra slowness.
  21. been trying to follow these threads....are there really 2 sets of people developing DragonCart II or whatever....? I thought it was just two threads by the same folks. That seems a bit much. I don't care about one of them being DC II, but not both, that's just silly. And the 'dragon' part anyway came from the Dragon IP chipset that was in our cart, seems these folks are talking about the wxxxx boards from WizNet, which are totally different implementations. I'm glad to see interest in this topic again, I think it's a very interesting development but two things named DragonCart II we don't need. Maybe NetWiz or AtariWiz or something. Anyway it's a good chip, and it will be interesting to see what happens. I also prefer a PBI/ECI device but a cart would be OK especially if it has a pass-through.
  22. I initially thought a new name would be better too but don't feel all that strongly about it. If people are used to thinking 'ethernet' when they hear Dragoncart then just having the II after the name seems legit, it would be clear that this is a different device. Plus the logo is cool For the PBI/ECI, yeah Dragon Bus just sounds kind of comical. At any rate, I certainly would buy a couple of either one of these.
×
×
  • Create New...