Jump to content

danwinslow

Members
  • Content Count

    2,767
  • Joined

  • Last visited

Posts 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

    • Like 2

  2. 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.

    • Like 1

  3. 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.

    • Like 2

  4. I don't think Yaron is interested at the moment but with the upcoming 8bit-Unity it is possible to make crossplatform (A8, Apple II, C64) multiplayer online games using C language.

     

    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.

    • Like 1

  5. 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.


  6. 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.


  7. 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.


  8. 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.

×
×
  • Create New...