Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

51 Excellent

About RobS

  • Rank
    Star Raider

Recent Profile Visitors

3,006 profile views
  1. Yes it is very odd. It resided on an external drive for a long time (v 2.9) and never did this. I moved it to an internal drive and nothing changed, then when I set up 3.2 now both versions exhibit this behavior. I tried to a full settings reset then made it portable, hoping to "fix" this (thinking something with the settings being stored in the reg might be doing something weird or retaining some previous settings or something). The other odd thing is it also hard-locks (goes non-responding) if you plug or unplug any USB device - anything, even a charging cable. Maybe my windows is just screwed up (windows 7). Works a treat otherwise!
  2. Can anyone tell me why this takes 1-2 minutes to start up?? I moved the previous version I had from an external to an internal drive, installed this new version (3.2) reset all settings, and made it portable. All I get is "not responding" for almost 2 minutes before it boots into anything. Thank you.
  3. Thanks for ruining the forum search. Didn't need to be changed, but make sure to change it anyway and remove all the things that make search useful. Now I cant even search any posts by just an author, since you HAVE TO also include some other search term/tag.

    1. Show previous comments  4 more
    2. Random Terrain

      Random Terrain

      That's the main thing I used it for, something I posted.

    3. CPUWIZ


      I suggest purchasing a subscription, instead of being a whiny little kid.

    4. RobS


      Albert, ok that is fair. You definitely would want it to be more efficient vis-a-vis resources. I didn't know it was still building, as I was getting 0 results from ANY search at first.

  4. I got it figured out! I took apart the connector, and one of the pins was pushed all the way back, so I gently pushed it back into the connector and I heard it "click" securely into place and now it works in the drive chain! I am using my home-grown custom sector copier program and so far it seems to be working, I was able to boot from it and sector copy a disk from D1 (sio2sd) to a physical disk in D2. Thank you all!
  5. Thank you for the confirmation. So I was sold a bad SIO2SD then. It will only work plugged directly in to an Atari. -Rob
  6. Ok so I now also have acquired a 1050 drive with another data cable, and the SIO2SD still will not work in the chain. All 3 physical drives work on the 2 computers, and the SIO2SD works when directly connected to the computers, but it does not work (doesn't even light up) when connected in any combination of drives, cables or drive# selectors. Unfortunately, this makes the device useless to me as I am developing on the PC and need to be able to transfer the images to real disks to do actual testing. Unless there is some other trick to getting one of these to work with physical drives??
  7. I suppose it could be, but I have 2 drives and 3 cables, I cant imagine they are all bad in that specific way when they boot and run fine with the drives otherwise.
  8. I think I got it! I have to do more testing, and validate various blocks in upper mem ($c0, $c1, etc) but a quick test so far seems to work. What I didnt know I had to do was to re-establish the initial vector for the DLI before turning everything back on. I have a "chained" DLI that changes the character set twice - so it flips from a 0 screen to a mode 4, then back to 0 for the bottom part of the screen. This is what was getting messed up when I tried to access the ram under the rom. For my test, I loaded an alternate character set (that represents the game tiles for Towns) into mem, then copied it to $c0 under the rom. then, after I press a key, it copies it back from $c0 to the location of the tiles character set and bam! the tiles on screen changed, the DL and DLI are still intact, and it seems to be working. Thank you all for the suggestions and advice, it helped me think around the problem a bit and suss out what I needed to do. If anyone is interested, I could post my code, since it should work generically enough to drop in to most any program and work.
  9. I would like to ask a follow-on question for anyone who may have knowledge or experience with this. I have 2 Indus GT drives, and a 65XE. The SIO2SD powers on when plugged into the 65XE directly, but when daisy-chained as described above, it has no power at all. Has anyone gotten this to work with an Indus, or is that a non-starter due to some design of the Indus' SIO port? Both Induses otherwise work and boot disks when set as Drive 1 and plugged directly into the 65XE. Thank you.
  10. To follow on a bit, I finally got a SIO2SD so I can try some of this on a real Atari. I have a 65XE and an 800xl, but the XL doesnt power on the SIO2SD, so working with the 65XE for now. The behavior I have found so far is this: xbios will boot but does NOT use the .cfg file when run on a real Atari (at least via an .atr image). I can manually run the loader program for my game, but the CFG has a custom place for the sector buffer and that isnt getting picked up. Any ideas on why that might happen, but work fine otherwise in an emulator? Everything else in the game works, including loading sectors and running other files. Also the screen just goes blank instead of flickering when doing disk access, which I guess is better but I still would wonder if it couldnt be made to work without turning it all off. Other times when I compiled this game from the original basic code in MMG, the screen always stayed on when accessing the disks.
  11. Ok I have done some experimenting, and have it working except for placing xBIOS in the upper memory area. This is the exact config I compile and use: OPT h-f+ ; no bootable/no headers, one segment .byte $43 ; for xB 4.3 .byte c'LDR ' ; autorun filename .byte >$0800 ; xB adress .byte >$b000 ; buffer adress .word $02e2 ; INITAD adress .word $02e0 ; RUNAD adress .word $0000 ; I/O module adress – $0000 means xB build in SIO .word $0000 ; I/O relocator adress - $0000 means xB build in .byte $ff ; PORTB, without BASIC .byte $40 ; NMIEN .byte $c0 ; IRQEN This moves the buffer so I can use the entire page 6 and 7 block. This works fine, but if I alter the XB address to any memory ref above c000, it hard locks the emulator. Don't know if that is supposed to automatically work just making it, say, d800, or if something else is needed. I would also like to get an answer on if there is any way to prevent xBIOS from flashing/blanking the screen on disk reads. When my game tries to load a file or get sectors, the screen blanks out intermittently (flashes black) during the data xfer. This one is perhaps more important, as I can work around the first problem (or just not relocate xBIOS) but having the screen display stay up when getting map sectors from disk would make everything look a lot more professional. Thank you.
  12. Still no joy, get a hard lock. I may have to just give up on this as I am only working on Altirra right now and dont have a SDSIO device yet so I can see how this stuff runs on real hardware. 2 quick questions for now: 1) The screen blanks during disk access, is this normal? Any way to prevent it? 2) Where might I find the location or equate to call to to get the "status" of a drive as in this example: I get the first 2 lines of this, but what "status" address are we calling to validate the existence of the drive? Is that a function within xbios?
  13. I used the same one as all the other examples on here. This is what I have in MADS and comiple: OPT h-f+ ; no bootable/no headers, one segment .byte $43 ; for xB 4.3 .byte c'XAUTORUN ' ; autorun filename .byte >$F000 ; xB adress .byte >$0700 ; buffer adress .word $02e2 ; INITAD adress .word $02e0 ; RUNAD adress .word $0000 ; I/O module adress – $0000 means xB build in SIO .word $0000 ; I/O relocator adress - $0000 means xB build in .byte $ff ; PORTB, without BASIC .byte $40 ; NMIEN .byte $c0 ; IRQEN
  14. I understand that, but I am not wanting to place it using the D000 range, just in c000-CFFF or above d800. The example above uses f000 but that fails as well. And as to "why", because then I could use the main memory down to $800 (instead of $c00 with xbios loaded low)
  15. Well I cannot get this to work. The CFG file does work now, so at least it doesnt fail or lockup, so I must finally have the correct format for it. But if I change the relocator addr of xbios to anywhere above $c000, it locks, does weird things, or returns to the main xbios menu with a messed up screen (ie some other screen mode). I am using $ff (and tried $fe) for the portb setting, same results either way. I am running the OS (OS not disabled) but this does not seem to be putting itself under the ROM without crashing.
  • Create New...