Jump to content

Technoid Mutant

  • Content Count

  • Joined

  • Last visited

Community Reputation

67 Excellent

About Technoid Mutant

  • Rank
    Chopper Commander
  • Birthday 06/12/1970

Contact / Social Media

Profile Information

  • Custom Status
  • Gender
  • Location
    Miami, Florida, U.S. of A.
  • Interests
    Atari 8-bit computers, Vintage computers, Operating Systems,
  • Currently Playing
    Installing and updating Antonia board (Altera code update), installing and updating a U1Mb (Xilinix code update), building a lot of ten 512k ram upgrade boards for the Atari 800, generally having fun. Playing Gauntletak a little
  • Playing Next
    Burning a new rom for my broken 850 in hopes that's the problem, building a US Doubler for my stock 1050, building a couple of 512k ram upgrades for 800xl machines.

Recent Profile Visitors

116 profile views
  1. Ah! Gavin's come with the pins and the screw/nut for a little more. Nice. I don't need the screw because I need to remove a chunk of the posts anyway to make room for the serial to usb breakout board I'm inserting, but for making cables, his would be the trick. Jeff
  2. I saw this on ebay and wanted to buy them but thought they might be kinda crappy. I finally caved and bought four of them. The shipping was four bucks and the four connectors were about seven. So for eleven bucks I got four really high quality connectors. They are 3d printed, but with what kind of printer I can't imagine. The plastic is sturdy, well-finished, and the fit is really precise. For those doing projects that require sio connnectors, I recommend these whole-heartedly. Here's a link to the connectors, and to the pins, which are available on both Mouser and on Digikey. Connectors: https://www.ebay.com/itm/Pair-Of-Atari-SIO-Cable-Plugs/173981990336?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 Pins (Mouser): https://www.mouser.com/ProductDetail/Molex/08-50-0105-Cut-Strip?qs=%2Fha2pyFaduhNDBcrHuwseTYc47dazYPMn9k8MYjpwRQa2Qjm3iOogQ%3D%3D I bought 200 pins, so I can make a whole lotta sio2usb's. Anyone want one? The prices are hard to beat on Lotharek and on Amigabythelake. Theirs are only 18.00, but I might make a few pretties for myself and local friends. Best, Jeff
  3. Wow man. I think you may have wrecked the very same trace that I wrecked. Wow.
  4. Here are photos for you. They are as good as my camera will do. If you need microscope shots, give me the area of the board you want and I'll do that right away. Best, Jeff
  5. Sure. I will do that when I get home I have a microscope, which I used to make my fix, so if you send me pics of your broken board I can take photos of the areas of damage and send them to you as well. It is now 1620 my time, I should be home and working on this by 1830. Don't worry. We'll get this going. BTW. my problem with this was that I pulled up a trace and the trace fragment actually crossed to contact an unbroken trace right next to it. This was possible because in breaking the first I failed to break it's neighbor but did manage to skin the solder mask off. The board acted completely dead in this condition when reinstalled. If you don't have magnification, this would be really hard to spot. My eyes aren't what they used to be, but I doubt anyone's eyes are THAT good. Oh, hit me up in a private message with your email address so I can send you hi res photos directly. They look good posted here, but there is a level of translation I think. Best, Jeff
  6. I've been curious about that QD term myself in this application. The term was never an official one and dates at least to my early Atari days, referring to 80-track (or 77-track) drives: sssd - Single Sided Single Density (128 byte sectors, 18 sectors per track) 40 tracks are assumed. ssdd - Single Sided Double Density (256 byte sectors, 18 sectors per track ) ssed - Single Sided Enhanced Density (also called Dual Density, or 'Density-and-a-half' (128 byte sectors, 26 sectors per track) QD - Denotes 80 tracks, 18 sectors per track, double-sided, for a yield of 720kb, but which term was generically applied to any disk mechanism capable of storing this format, though these mechanisms could produce 80-track single- or enhanced-density formats as well. So the term is sloppy and ill-suited to the task in either RespeQT, or AtariSIO (what I use and which is the root of RespeQT), from which latter I suspect RespeQT inherited the QD description. Best, Jeff
  7. No, I haven't actually tested the Persistence of the time-date commands, so I can't answer what I think you're asking. What I used the Time/Date commands for was to see if that would resolve Moe's issue with Side2 in a single session ala the jiffy clock, which does work. I will test further, answer the question of persistence (does the Time/Date command actually SET the clock's time and date) with one and then the other clock installed, and will test sio and U1MB with the newest version of the driver (side2 on u1mb was the only configuration that was using the latest version) and report. Which clock gets precedence when the combination of Side2 and U1MB are used? There's a mode bit there in one or ther other I'm sure. Best, Jeff
  8. RIght, DOS, the TDline gets the date correctly regardless. (Though I don't know which clock it is referencing), but I thought it strange that with Side plugged into the machine, Moe doesn't get the date right. That seemed interesting, a hardware interaction maybe worth knowing about if not actually fixing. Updating Moe from Basic via the Z: device works in all configurations. With Side2 and U1MB I tried actually entering the date manually to see if Time and Date commands reset the issue, but it still gets the default date with Side2 on U1MB, which is strange. No great crisis or anything, but interesting. Without Side2 installed I was using, I think, the u1mb only version of the driver, come to think of it. With Side2 installed I'm using the latest version. I will update SIO boot to the same version and re-test. Best, Jeff
  9. Yesterday I tried a stock xl booting from sio with sd32g and the standard tdline etc. Moe got the time right. I tried a u1mb, booting from sio and it got the time right. I tried U1MB booting from Side2 and it gets the wrong date (1985 or 1994) depending on Moe version. I then tried Side2 with u1mb booting from sio -- same problem. There is some interaction between the two on-board rtc's that is creating this issue. Does Side2's rtc work much differently from RT8 or U1MB? This is a duplicable issue. Best, Jeff
  10. LOL! It's mosly occupied by a steganographic ode to Steve Cardin that fortunately no longer bumps memlo. The previous version displayed the ode at run time and then kept the ram... Best, Jeff
  11. I've heard that RealDos is just SD32 in drag, but there are a whole lotta utilities added on. I thought it might be an incarnation of Tom Hunt's dos I was beta testing in the early 90's. He stripped everything out, had an incredibly low memlo, a path for .com files. Everything was external, copy, everything. Maybe even dir. I'm trying to remember what he called it. He had a hard disk crash and lost the code. I mentioned it online and he got in touch. I got him the executables again, but I"VE since lost them. AH! I remember now, SRP dos. I was running my Carina on a MUX using MUXSRP.DOS. Jeff
  12. Wow, I hate to report that it works in Spartados 3.2g and xd32z.dos with either tdline from the Carina kit or the original 1985 tdline, but Moe doesn't get the time. It either reports 000000000 for time/date (Ansi26/27 moe), or the 18th of September 1985 for earlier versions of Moe. It looks like moe is using some other vector to get time/date. I know that TDLINE is required, and that TDline after being loaded must be TD OFF-ed, before loading MOE. I tried all orders of loading the files, Rverter, ultd, tdline, td off, (insert version of moe here), but all failed. I did notice that Moe bombed if I loaded the tdline and ultd before the rs232 handler, but that is the only crashy behavior I saw and is normal. What could MOE be doing to get the time/date? I can give you a hint, I think. Moe updates it's time/date during the login process by some mechanism provided by the gateway module. It happens at, I think, line 4080, but I've not been able to dial it any closer than that. That is an area where it gets a time from a file that reflects the time to enter network mode and suspend user access. It does some machine language call that I suspect may be the culprit, but since variables aren't set up after break, I can't make it do it when I want. It does it each time you log on. So Moe updates itself from tdline if tdline was set from an rtime8 automatically or if gateway lines 4000-4090 do thier magic, or if the user manually configures time and date before or after loading tdline, but Not from the ultd.sys (I renamed it .com for convenience) whether tdline is loaded or not or whether tdline is on or off. How wierd. I don't know the deep coding stuff you do, but I am guessing that there is a mechanism that the RT8 handler built into tdline? uses and that the time/date commands use that the Ultd.sys module is not using? Best, Jeff
  13. You don't actually need the ACCEL driver.  If you are testing, it may be best to omit it.  It is a screen accelerator.

  14. Oh, the xbbs.bat file is the one I was using to test under sdx.  It would work if Moe didn't crash.


  15. Ah. I have no clue why it crashes under SDX. It is for sure MOE though. There are several copies of MOE on the disk. All display the same behavior. I'd try it working, so you can get an idea of what it looks like and then go to SDX... If you haven't already. The option key in Moe drops the dli screen down a notch, to see status of user online etc. Another Option press will drop the whole screen down and allow you to edit the user in real-time. Option again will disappear the dli screen entirely, and once again will display the partial dli screen, which is the default mode. Oh, I neglected to creat the d1:>dos>x32g directory, where my batch file looks for the rverter handler. You can change this line in the batch file to reflect the location of rverter.com in the root directory (it is there), or mkdir >dos>x32g and then copy >rverter.com >dos>x32g> to resolve this. The software won't work without an R: handler installed. you can get some clues from the error.dat file on D7: The error.dat file is freely deletable, so if you don't want to wade through several sessions of errors, just delete the file and start the software. It will recreate the file as needed. /s
  • Create New...