Jump to content

danwinslow

Members
  • Content Count

    2,767
  • Joined

  • Last visited

Posts posted by danwinslow


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


  2.  

    Sorry if I'm missing the point but ... Wouldn't it be most natural to just extend AspeQt to listen on some socket beside opening some serial port?

     

    To me it's one of the major benefits of TCP/IP that it's available on every modern machine without jump through loops like Serial2USB dongles etc. I mean, if you just want to connect a few Ataris together you don't need TCP/IP. You could as well use raw Ethernet frames. This would allow to just stay with the CS8900A (or use the W5100 in Raw Mode). Interacting with non-Ataris is the point in TCP/IP, isn't it?

     

    I am pretty sure BOOTP is UDP, but I agree with Oliver, the point would be to use the LAN. I have no idea how AspectQt could arrange to boot an OS from a remote disk, but if it's possible that would be pretty cool too.

     

    Hello Dan

     

     

    Why not use a NAS? Or maybe even a Mac or PC (kinda like SIO2PC, but over ethernet via a router and/or switch)?

     

    Sincerely

     

    Mathy

     

    Hi, Mathy. Sure, I think that would be fine too, I just think the idea of a remote disk system between two ataris would be cool. Like NFS, but based on low level sector calls that get mapped across the LAN.

     

    You are making it way too difficult. BOOTP/TFTP was specifically created for this scenario. A very small boot ROM (like 1-2kB) and everything else is done by the code that's loaded over the network. So no difficult protocols like http/ftp/smb/nfs or whatever. Trivial File Transfer Protocol. Just to boot, like reading sequential sectors of a boot disk, it reads of a network stream. And BOOTP is your poor man's DHCP.

     

    Regards,

    Graybeard Ivo ;)

     

    Edit: about popularity, it might not be that popular anymore to boot over a network (used to be "thin" clients and diskless workstations, etc..) but it's still easily available on current OSes. MacOS and Linux distros have it by default and on win32/64 you can install cygwin or MINGW and have the same daemons for bootp and tftpd.

     

    Yeah, that's the essence, you would need some kind of small bootstrapper on the client atari, just enough to get the stack active and support fetches and loads (either bootp or custom, whatever). No matter the transport mechanism, you'd need this small bootstrapping OS, and it would need to be somewhere that wouldn't get overwritten by the real OS.

     

    Anyways, kind of getting ahead of ourselves here. I was totally just blue-sky imagining possibilities. The actual machine OS is the hard part, just DOS boots from remote machines would be easier.

     

    *EDIT*

    Hmm, after reading up a bit, BOOTP is just an earlier version of DHCP, all it does is get an IP. There's a 'netboot' protocol that does what we're talking about, but it seems like it doesn't define an actual transport mechanism, just says "most implementations use TFTP"

    https://en.wikipedia.org/wiki/Network_booting


  3. Yes, I think so, for DOS loads especially. I've thought about this. What's needed is a 'shared disk' over the network. One atari acts as a disk server and contains disk images for bootable environments and a server program that accepts incoming disk requests. The client atari would have a hook in DOS init that loaded the handler (from ROM or something on the cart or PBI/ECI) and would hack the startup such that all low level disk calls that go to the disk drive D1: instead get vectored out through the handler to the server as just get/put disk sectors and stuff. As far as the client atari would know it would have a boot disk locally as per normal.

     

    Doing an OS load would be harder because you'd need an active handler of some sort on the client machine. Maybe a small mini-OS could boot from the PBI or something and load a real OS from the handler.


  4. So, this sounds like a good idea. Since it is not related at all to the original dragoncart, I would prefer that the name be different. The original was a 5v cs8900a chip and support glue attached to a cartridge, without it's own internal IP stack. From a quick thread skim, I'm not sure if the item being discussed is a cartridge, or an ECI/PBI, or maybe it's both. I think that the ECI/PBI is a better implementation than the cartridge, but if the cartridge has a pass through then I think it's kind of moot but I'd still prefer the ECI/PBI.

     

    Please put me down for 2 of either the PBI/ECI (if available) or 2 of the carts. Actually, I'll probably buy 2 of both, but lets start with what's being discussed.

     

    As far as software goes, I do have a stack written as a device handler using the I: device and driven by VBI, so it's accessible from any language that can use CIO calls. It supports a stack with ARP/ICMP/BOOTP/DNS/UDP, but the TCP part was about 1/3 done when I ran out of gas. It's freely available to anyone who is interested. Using a chip with it's own stack will change things greatly, but it's a good proof of concept for using an interrupt-driven CIO handler. It will probably be much easier using the new chip. For gaming, what you typically need is a really fast UDP implementation and so the makers should concentrate of the speed of mioving things off of the chip and into memory.

     

    1. davidcalgary29 - 1 cart
    2. xrbrevin - 1 cart
    3. skriegel - 2 carts
    4. Marius - 2 carts
    5. brenski - 1 cart
    6. AtariSociety - 1 cart
    7. Mathy - 2 carts
    8. Haightc - 1 cart
    9. Markk - 1 cart
    10. Sleepy - 2 carts
    11. Nezgar - 1 cart
    12. Gunstar - 1 cart
    13. Chaosfaktor - 1 cart
    14. Wadeford - 1 cart
    15. sanny - 1 cart
    16. DNA128k - 1 cart
    17. Senor Rossie - 3 carts
    18. KlasO - 2 carts
    19. NML32 - 1 cart
    20. CharlieChaplin - 1 cart.
    21. slx - 1 cart
    22. David_P - 1 cart
    23. Rainier - 1 cart
    24. AtariPortal - 2 carts
    25. patjomki - 1 cart
    26. Allan - 1 cart
    27. Toddtmw 1 cart
    28. TheNameOfTheGame 1 cart
    29. adam242 1 cart
    30. Dan Winslow - 2 carts
    31. Jinroh - 1 Cart
    32. Philsan - 1 Cart
    33. Lastic - 1 Cart
    34. invisible kid - 1 cart
    35. gozar- 1 Cart
    36. pixelmischief - 1 cart
    37. BigBen - 1 cart
    38.
    39. Ransom - 1 cart
    40. TemplarXB - 1 cart
    41. tuf - 1 cart
    42. mariusz - 1 cart
    43.
    44. Firedawg - 1 cart
    45.

    • Like 1

  5. Be aware that this is not an easy goal, even if you already have programming experience. Aside from Karl's question above -

    Have you searched for threads about 'how to program 2600' here? There are many such threads.

    It's too big of a subject area to just say 'please help'. There are also other online resources about programming for the 2600.

    • Like 1

  6. I didn't care for it, and I don't think it will be particularly successful. Bethesda doesn't seem to really understand what most people (I think) loved about the earlier fallouts. Even fallout 4, which I liked well enough but didn't love, suffered from it.

    Here's the deal -

     

    I don't want to build things. I don't want to play civ. I don't want fancy decorations or to play dress-up with armor colors or hair/face/body editing. I don't want bouncy colorful happy-time emoticons. I don't want to have to deal with some 12 year old trying to kill me or even just having to listen to him or have him wave and show me stupid emoticons. I don't want to have to cook and/or make routine things. I don't want an open-world multiplayer Farmville. I don't want a battle-royal that keeps replaying in a cartoon-style world.

     

    What I DO want is story immersion, yet to still have open-world freedom. I want to shoot naughty things and blow lots of things up.I want to feel like the decisions I make make a real difference in the story line. I want to have goals to help people that mean something. I want good plots and lots of good side quests. I want interaction with NPCs, including the decision to just shoot them and to experience the consequences thereof. I want a dirty, gritty world that looks like a nuclear strategic war happened. I want story continuity. I want to be pressed hard to scavenge and explore for survival.

     

    So,as a lot of people like me feel, New Vegas was the pinnacle of Fallout greatness. Fallout 4 was OK, but they had started the process of dropping things like faction systems and skill advancements. The story lines were actually pretty good, but really it totally did not matter what you did in NPC conversations other than maybe shorten steps via charisma checks. Faction had no real meaning other than at the very highest story level. It had a good weapon and engagement system, but they dropped some mechanics around weapon repair, and yet oddly kept them for power armor. I hated that so much work went into the stupid 'let's build outposts and beds and paintings and walls and pictures and lets have to deal with directing a bunch of mindless NPCs to dig carrots' that could have gone into things like a meaningful faction system and a conversation system that was more than 'pick an aggressive or cynical or sarcastic or sympathetic response but don't worry because it won't really matter'.

     

    Fallout 76 is too pretty, too cartoony, too simplistic. It's Fortnite with a Fallout-like skin on. There seems to be essentially no actual story line except some lame stuff about 'find the overseer' and popup quests. It's only 25 years after the bombs fell but already you see the full range of canon entities like the brotherhood and super-mutants where they do not exist in the timeline. I could theoretically see a multiplayer Fallout but it would have to be on totally different terms. This just feels like they are trying to skip having to do the hard work of story creation, voice acting, and complex quest trees and have us 'create our own adventure'. They tried to do online multiplayer, and also tried to keep some of the single player fallout feel, but those two things are incompatible and they wound up doing neither well.

     

    BAH I say, BAH. You kids GET OFF MY LAWN!

    • Like 6

  7. while ( *( (unsigned char *)(0xD40B))) might work too.

    But I'm confused - if you are drawing graphics in a normal way, outside of the vertical blanks, then you are by definition not going to be drawing them while the vb is happening, so there's no point in waiting. Any cycles your program gets are always 'after the Vblank', right? Unless the goal is to draw a complete screen before the next vblank happens...?

    Anyway, I don't really understand what he's trying to do, so I'm probably off base.

     

    Sanny - I didn't really give him a solution, just showed some examples of how to use a little bit of inline assembler to handle interrupts. He's asking for something else i think.

    • Like 1

  8.  

    well, that is the safest way to draw things on screen without messing things up right?

     

    As far as I know, you don't have to wait for vblank to be over. You just draw your stuff, you'll be interrupted at some point but you won't know it and your routine will pick back up where it left off. The VBI won't mess with your graphics at all. It just increments some system values and does other housekeeping.


  9.  

    ok. thanks for all responses, i think i understand.

     

    a differnt question:

     

    if i use this method:

    int isVBLANK()
    {
              // get the currect raster line
              raster_line = PEEK(54283);
    
    
              // if it reaches line 120 = VBLANK
              distance = abs(120-raster_line);
              return (distance == 0);
    }

    if i use the number 120, everything seems to work ok. if i choose bigger number, things start to mess up......

    any idea? any suggestions for improvements?

     

     

     

    Yaron -

    Why are you trying to wait until vblank is finished?


  10. If one saves all the registers (AXYP) and restore them at the end (both with asm()), can one execute C code in between? (like update a global variable)

    Yep, sure can. Again, probably stay away from c lib stuff, but any regular c stuff would be fine, as long as time constraints are paid attention to.

     

    *edit*

    P I don't normally worry about, but I guess you could.


  11. A parameter-less C function (void func(void) ) is indistinguishable from an assembler call. If you set up a vbi() function and put it's address into the vbi pointers and do the other necessary settings for a VBI setup, your routine will be called each vblank. You do need to jump back correctly, and that requires an asm("RTI") and stuff, but its pretty easy to use the asm() functions in C.

     

    You can hook dli's too, but I am not sure how you would save the regs you need without asm. See the below functions. Using the asm() stuff in C is pretty easy if all you do is save regs, set a few things, and return.

    #define DLIST  *((unsigned int *)560)
    #define LMS_MASK 0x40
    #define DLI_MASK 0x80
    #define JVB      0x41
    #define JMP      0x01
    #define SCAN_GR0 0x02
    #define SCAN_GR4 0x04
    
    unsigned char color_save;
    unsigned char bloo=(7 << 4 )+1;
    unsigned char noo=(7 << 4 )+15;
    char dl[256];
    
    void dli0( void )
    {
    
    asm("     PHA      "); //save a
    
    //chain to next DLI
    asm("     LDA #<_dli1");
    asm("     STA $0200");
    asm("     LDA #>_dli1");
    asm("     STA $0201");
    
    //save color
    asm("     LDA $2c6       ");
    asm("     STA _color_save");
    
    //load up color
    asm("     LDA #1    ");
        asm("     STA $D40A "); // wsync
        asm("     STA $D018 ");
    
    //restore a
    asm("     PLA      ");
    asm("     RTI      ");
    }
    
    void dli1( void )
    {
    
    asm("     PHA      "); //save a
    
    //load up color
    asm("     LDA #3   ");
    asm("     STA $D40A"); // wsync
    asm("     STA $D018 ");
    
    //chain to next DLI
    asm("     LDA #<_dli2");
    asm("     STA $0200");
    asm("     LDA #>_dli2");
    asm("     STA $0201");
    
    //restore a
    asm("     PLA      ");
    asm("     RTI      ");
    }
    
    void dli2( void )
    {
    
    asm("     PHA      "); //save a
    
    asm("     LDA #7   ");
    asm("     STA $D40A"); // wsync
    asm("     STA $D018 ");
    
    //chain to next DLI
    asm("     LDA #<_dli3");
    asm("     STA $0200");
    asm("     LDA #>_dli3");
    asm("     STA $0201");
    
    //restore a
    asm("     PLA      ");
    asm("     RTI      ");
    }
    
    void dli3( void )
    {
    
    asm("     PHA      "); //save a
    
    //load up color
    asm("     LDA _color_save");
    asm("     STA $D40A "); // wsync
        asm("     STA $2c6  ");
    asm("     STA $D018 ");
    
    //chain to next DLI
    asm("     LDA #<_dli0");
    asm("     STA $0200");
    asm("     LDA #>_dli0");
    asm("     STA $0201");
    
    //restore a
    asm("     PLA      ");
    asm("     RTI      ");
    }
    
    void setup_dli_chain( void )
    {
      *(unsigned int  *)(0x0200)=&dli0;
      *(unsigned char *)(0xD40E)=*(unsigned char *)(0xD40E) | 0x80;
    }
    
    unsigned int next;
    
    void build_dl( void )
    {
    int sl=0;
    
    dl[sl++]=0x70;
    dl[sl++]=0x70;
    //dl[sl++]=0x70;
    dl[sl++]=SCAN_GR0 | LMS_MASK;
    dl[sl++]=(int)&screen1 & 0xFF;
    dl[sl++]=((int)(&screen1) & 0xFF00) >>8;
    dl[sl++]=0;
    
        dl[sl++]=SCAN_GR0;
        dl[sl++]=SCAN_GR0;
        //dl[sl+0]=SCAN_GR0;
        //dl[sl+1]=JMP;
    //next=(unsigned int)&dl[sl+4];
    //dl[sl+2]=( next & 0xFF );
    //dl[sl+3]=( (next >> 8 ) & 0xFF );
    //sl+=4;
    
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0 | DLI_MASK;
    dl[sl++]=SCAN_GR0 | DLI_MASK;
    dl[sl++]=SCAN_GR0 | DLI_MASK;
    dl[sl++]=SCAN_GR0 | DLI_MASK;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
    dl[sl++]=SCAN_GR0;
        dl[sl++]=JVB;
    dl[sl++]=(int)&dl & 0xFF;           ;
    dl[sl++]=((int)(&dl) & 0xFF00) >>8; ;
    }
    
    
    void activate_dls ( void )
    {
      //set screen
      *(unsigned int *)(88)=&screen1;
      //kill antic by storing 0 into $22f
      *(unsigned char *)(0x22F)=0;
      //Then store the address of the new display list into $230 and $231 (low then high).
      DLIST=&dl;
      //Lastly, turn ANTIC back on with a $22 into SDMCTL.
      *(unsigned char *)(0x22F)=0x22;
    }
    
    • Like 1

  12. Do you have anything in your source code named 'once'?

     

    See this: https://forums.nesdev.com/viewtopic.php?f=10&t=14315

     

    It indicates that you have a 'once' segment setup, but you did not give it a definition in the cfg. Look for anything in yoru source called 'once' (especially a .segment). If you don't find anything, examine the files you are linking. If you are including any other files in your link than those that were directly produced by your source code, they may have that segment defined.


  13. Yaron - I was in exactly the same place as you a couple of years ago. Then I decided to get over my config phobia and I just started working with it and learning. It makes sense once you get used to it, and it makes serious development MUCH easier in the long run. Well worth the effort. I wound up using it to define overlays and EXT ram loadable stuff and all kinds of things. Well worth the time investment.

    • Like 1

  14.  

    Did you have a bad Taco or something? ;-)

    Hah, no, that was a line of Burroughs 3500 OS command. See, WAY up above in post #12727 pacman said something about a burroughs mainframe. So, naturally I thought if I posted like 20 posts later it would make perfect sense, and all of the ex-Burroughs computer programmers here would have a hearty chortle.

    • Like 6

  15. The list is now:

    PM Respondents so far, in order of contact:

    #1 Nir Dary - claimed carts, so they are gone

    #2 Brentarian - the whole thing Citing potential spouse aggro, he now wants all 1200's - maybe some leftover 800's.

    #3 _The Doctor_ - whatever he can

    #4 eebuckeye - wants a single working 1200. Not doing that yet and these all do not work in some fashion.

    #5 Brenski - 1200's and 1050's

    #6 Clauseb - wants the sinclair pile.

    #7 Remo - wants a 1050. Not doing that yet.

    #8 Kheller2 - wants the entire atari pile.

    #9 Keneg - wants some of the drives. Not doing that yet.


  16. OK, - counts -

    7 1200's all in varying stages of working. None work completely, some may be dead - most common issue is keyboard.

    3 800's - unknown if they work or not, but they came from the 'something's wrong' pile

    7 1050's

    1 Rana (not indus, that was a mistake)

    1 810

    No 130's after all - was wrong about that

    1 600 - found that at the bottom

     

    Weights -

    1200's are around 6 pounds, 800's are 4 pounds, the drives are like 3 pounds each. So everything would be 7*6+3*4+9*3=81 pounds..lets say its about 90 pounds to be on the safe side, I'm using a bathroom scale.

    A quick check of USPS indicate it would be around 155 dollars to the east coast, so lets say about 175 to go anywhere US for the whole lot.

     

    The sinclair pile weighs around 50 pounds.

     

    And also, I'm looking for people who want to get all or most of these in one transaction, I don't want to worry about who gets what and if it's broken or not. All 1200's, all 1200's+800s, all disks, that kind of thing.

     

    The list is now:

    PM Respondents so far, in order of contact:

     

    #1 Nir Dary - claimed carts, so they are gone

    #2 Brentarian - the whole thing Citing potential spouse aggro, he now wants all 1200's - maybe some leftover 800's.

    #3 _The Doctor_ - whatever he can

    #4 eebuckeye - wants a single working 1200. Not doing that yet and these all do not work in some fashion.

    #5 Brenski - 1200's and 1050's

    #6 Clauseb - wants the sinclair pile.

    #7 Remo - wants a 1050. Not doing that yet.


  17. PM Respondents so far, in order of contact:

     

    #1 Nir Dary - claimed carts, so they are gone

    #2 Brentarian - the whole thing

    #3 _The Doctor_ - whatever he can

    #4 eebuckeye - wants a single working 1200. Not doing that yet and these all do not work in some fashion.

    #5 Brenski - 1200's and 1050's

     

    I want to make sure everyone understands the consoles all don't work in some way. The drives I don't know about. Right now I am going to get Brentarian a total weight, I'll post it here.

    The carts are gone. The rest I will weigh out over the next week (sorry, I'm busy) and will post here. I'll do it by system type.

    Things that are left will be offered to the next folks down the list unttil it's all gone or people don't want it.

     

    Thanks. You can still PM, I'll keep track of it and post it here, but it's not likely much will be left.

×
×
  • Create New...