Jump to content

1050

Members
  • Content Count

    1,183
  • Joined

  • Last visited

Community Reputation

380 Excellent

About 1050

  • Rank
    Stargunner

Recent Profile Visitors

10,325 profile views
  1. My bad, never mind about the pin advice as they completely repurposed the pin's use at the chip level which means they also included a pull down resistor on the chip to ensure a non-floating pin even when it is cut off which is the new "purpose" for single sided drives only. But the above advice is still sound for most other pins, never leave one floating or you can expect random results.
  2. Not cut at the factory. One NEVER does that with a working brain stem, it needs to be told what to do and may be your entire problem. I would attempt to use a bit of thin wire stuck into the the socket and soldered onto what ever is left of the cut off pin right away. You don't leave pins to float since their logic state can change from internal chip leakage and that gets you random results any way you can slice that cake. I'm pretty sure it's not the stepper because it's not passing the RAM test or other section of Power On Self Test code written into the ROM. Stepper code isn't able to even be run because it keeps looping thru the failed POST test to start over and that is what is flashing the light as a clue and spinning up the main motor. 6810 isn't prohibitive in cost and you could use some extras to make a US Doubler out of it as well - why not get some and swap it just to be sure? The good news is it appears that the CPU and ROM are working, but something else isn't quite right. And the RAM test is quite extensive here reading mirrored data images in banks showing up at different addresses that another test might not be testing for.
  3. Spray the table you are using and then transfer it with a toothpick or any other device that suites you.
  4. When I had a real atari system, I would run it with a four drive stack with two D1: and two D2:, using the power switch on each drive to activate which pair I wanted. I found the only way to reliably allow this kind of swap to occur was to do the power down of drive to be abandoned, power up the drive to use and then most importantly do a RUN at 0x07E0 to effect a proper SIO init on all the disk drives and slap DOS up side the head while I'm at at. That might be what you are missing? Until I got into that habit I would often have the most confusing array of issues trying to use the newly powered up drives. At the top of that list was a drive that failed to do anything like it wasn't there at all.
  5. Eventually I find the ar0 file on the disks is NOT an autorun file as depicted in post #4 as I first suspected and suggested. You were supposed to hop right up and fix that right away... David wrote a broken MyDOS that loads and runs anything for autorun files and is the only type 2 AtariDOS that will do that. I see no reason to change anything. You just need to fix your files to the standard. Here is the fixed ar0 file. NDEV.AR0 And here is the original NDEV.BAK See if you can spot the difference and then realize why a good hex editor is handy. The reason one doesn't want that behavior is due to the fact that the RUN vector is only run when the IOCB block is finally closed if that mode is allowed and the INIT addresses are run during the load process at each sector of the incoming file. This will lead to out of order code running and would make this mess look like a piece of cake - which is it is in fact. In the old days, they built their single autorun files like a swiss clock and with care and things worked out fine. But it takes detailed work fraught with additional problems of sector lengths and file endings needing to be whole sectors or the last half of the sector of the next autorun function wanted could be trashed by the INIT run. David's brilliant cure to that insane nightmare is the ar0 method with incrementing file names, but then he does the load in the wrong mode. One of the many reasons I just stole his some of his ideas and not his code.
  6. Looking around to see where and how I might fix this, I come to a conclusion. I'm all wet about my suggestions so far. The first thing David does is reset the ar0 count to zero before he ever runs the autorun file load during the DOSINI run. So it doesn't matter what the number is as stored on the boot disk - it's getting set to zero anyway. Which leaves the only possibility of being that something tschak909 is doing has affected the STATE equate at 0x07BE to the effect of doing a warmstart bypass to DUP.SYS screen and it doesn't run the load autorun file because it thinks it already has done that even on an actual cold start. Which is the weird part, STATE on his disk is the same as a "normal" disk and I can't fathom how it's getting changed around on the fly. Especially before he gets to even run his autorun file... Somewhere DOS.SYS has been corrupted somehow??? It's looking like my short term solution would be to build a 2nd work disk but not from/with this DOS.SYS - DUP.SYS pair. Get those files from a "clean" new source and copy only the other files over to the new disk. This is a deep mystery to me at this time.
  7. Well, I've never had the problem either, but tschak909's disk is quite large and stuffed to the gills with many items. Somewhere along the line, he wrote DOS files back to the boot disk after it found and ran a proper autorun file. I'm thinking it's just this one disk, this rare time that the issue has finally come up. But it's a very real issue. So doing M. Run at Address 7e0 is the same as doing a DOSINI run and in that string of code is where David reset the number for the ar0 series back to zero. I did the same, it should instead be upon failing to find the next ar0 series or completion of loading the last one possible ar9. Never thought about it to be honest but without doing it right, it's kinda dirty code in need of a fix.
  8. Ok, it is genuinely broke. This beta 4 wants .ar1 because it did load ar0 at one time before, incremented and tried again but didn't find that file and then got H. Write DOS files to the boot disk preset to start looking for .ar1. I was not aware this could be an issue but it does need some correction somewhere so this doesn't happen again. Strange cure is to do M. Run at Address 07E0 and then H. Write DOS files to D1: and you should be good to go. I still don't have a good clue how this happened, but clearly resetting the extension to zero needs to also be done when H. Write DOS files to disk is done. Next version release will have it. A genuine bug - well done. As to blocking the autorun with a keypress, it will take some cogitation with MyRD in mind and how to keep one from messing with the other since there are already bootup keypresses at work with MyRD.ar0. But I'll keep it in mind for the next version release as well.
  9. So that's interesting. Have you tried autorun.sys as the file name? Please do. If it loads then that means somehow you have the wrong DOS.SYS while beta 4 DUP.SYS is giving you a fake news menu screen. It can occur rarely that DOS.SYS from one version is hooked up with DUP.SYS of another version. This is usually avoided with the ATR distribution method, but it's not perfect by far. And mistakes can still be made. Especially when H. Write DOS files to the boot device isn't done at that appropriate time needed. The code from 4.53 in this area of DOS.SYS is the same and is the source for 4.55 beta 4 so I'm at a loss to explain it so far. And first instance of this complaint so thanks for the bug report.
  10. Autorun files only ever did work if you call the INIT vectors at 0x02e2-0x02e3 at the end of the autorun file itself. It's not an autorun file if it's using the RUN vectors at 0x02e0-0x02e1 which are not allowed and just won't ever be processed. It's on you to make sure your autorun files comply with both these autorun rules. Not a MyDOS thing BTW. But it does comply to those strict pre-existing rules. So it's likely most have never even heard about those rules mainly because they don't use autorun files much. It's no big thing either way. Anyfile.ar0, anyfile.ar1, anyfile.ar2 work fine if the files are correctly vectored as actual autorun files. I guess we could have broke the mold and called them autoinit files instead?
  11. A quick look tells me this is an 800 rom layout with typical values for same at the last three vectors of the file. Which is a quandary due to ram disk involvement which typically works port b on XL/XE only, unless everything here is using an axlon ramdisk? At any rate, the dump is highly appreciated here as it can serve as an interesting disassembly with unique treatments of ramdisk operations - and I just LOVE that stuff. Thanks so much. So the self test data section is all zeros, it might be that they are actually written into the ROM as zeros. Which means it could be a toss up to burn this, pop it into an XL/XE and have it work right. Also unknown is if special disks bring in other code that needs this code to work, there seems to be an error message in atascii that complains of bad data on a disk - so there could be missing code for this toy on a disk somewhere. All I have at the moment and it was a hurried look thru it.
  12. Please keep us appraised of marketing plans for the boards, if when how much. I would like more than a few, less than a dozen, but six would be nice for starters.
  13. Just a wild guess, but one tenth of an inch? 2.54 millimeters. Hold up the legs of an IC to the holes and does it match? That's it then. So that's not diagonally of course, you'll need some math there.
  14. I'll always vote for the incompatibility reason. SD in FM and 26 sector per track MFM were "lifted" from 8 inch discs. Put 8 inch topology on a 5 1/4" and you have instant incompatibility with all other players. This is too perfect of a fit to ignore.
  15. It's a mess, but it has the same first sector pretty much as the Happy 7 disk. Then sector 2 is blank and that won't work for a boot sector at ALL. Hyper does replace text in often repeated similar patterns all the way to the end for both discs that make it look like a purposely made to be shit disc. No VTOC, No directory, how does it get this sideways without help? The 1st sector similarity has me thinking do you have the Happy 7 disks and have you tried to boot them? Until we get sector two with something in it and correct the "errors" in sector one which by rough guess would be about 20 bytes, we are not getting very far with this rocket. And then there's this feeling that if you booted Happy 7 you would find it says it's a Happy. So just an outright ripoff that somehow is not qualified for a full copyright infringement effort across the pond due to non working software supplied and on the phone the voice says to use the Happy software and don't bother me again.
×
×
  • Create New...