Jump to content

glurk

Members
  • Content Count

    140
  • Joined

  • Last visited

Community Reputation

206 Excellent

1 Follower

About glurk

  • Rank
    Chopper Commander

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Nah, not that one, the OTHER hole. I have the Gotek setup, and plan to put a real working floppy in the top drive bay, but I don't have one right now. So, I'm looking for the original Radio Shack "Drive Blankers" like those that came with cassette models with no disk drives. And hoping that somebody out there actually kept one and still has it... I'm trying to be "historically accurate" I guess...
  2. OK, I've got this TRS-80 almost finished, I guess. I got the Gotek from arcadeshopper here, and it works great. I only had to change the drive select jumper. But I want to ask anyone here a couple of things... First off, does anyone have one of the 5 1/4" drive "blanking plates" that came in a non-disk model? I want to fill in that hole, and I'd love to have one of the original ones. I'll buy one if the price is reasonable!! I know some must be out there somewhere... Second, I'm having a really hard time finding software. With the Atari stuff, there are a million sites with ATR images, etc... For the TRS-80, not so much. In fact, I've found pretty much nothing. I'm having a hard time even finding bootable DOS images of LDOS, NewDOS, etc... Isn't there a darn TRS-80 archive out there somewhere!! I've found a few dead sites, sigh. Please help!!
  3. OK, this was a lot of work, I spent several days on it. What I have is the ROM disassembly for the Percom RFD's Version 2.1 that DavidMil supplied, and pharon commented. What I've done is add labels, and structure to the code so that it's fairly easy to read (if you can read 6809 assembly) which I've kind of learned to do now... And... It's fully assemble-ble with the A09 6809 assembler: https://www.hermannseib.com/english/opensource.htm, and it assembles right back into the same exact 2K ROM. But this time, it can be modified and re-assembled. However, it's a really FULL 2K ROM, so it would be challenging to add much. It would be EASY to change the sector interleaves, or the motor timeout, or other things like that. One thing I'm looking at is the annoying fact that Percom's "motor-ons" every attached drive when one of them is selected. And it MIGHT be possible to add a new SIO command. The code can be shortened/optimized to get some more free bytes, by changing long branches to short ones as phareron noted. I've done that, and a few other things in a "custom" version I was playing around with, but only saved about 28 bytes, lol! It's pretty well coded from what I can tell. If it were a 4K ROM, I guess all sorts of things could be done... Anyways, I hope someone finds this useful. It suits my hacker mentality to be able to build a custom firmware for the drive I own. 50K full assembly code below: Percom-RFD-21.asm
  4. I'll just post it, but pretty sure it will compile only with ATASM now, and it's unfinished. But it does assemble and work. SECTZAP.zip I think I'm not going to do DD (or enhanced), it would require starting all over, too much hard-coded stuff in there. Plus I don't see a clean way to do it, because a whole sector should be on-screen at one time, IMO. This was written way back when SD was basically it, and almost all commercial software ever released was SD anyways... This is for fun, anyways. My fun. The moment it turns into a "job" or work, I'll do something else. I'm still open to ideas, but it's going to be single density only...
  5. It's not that the back is a poor heat sink, it's that Percom put the insulators BETWEEN the regulators and the case. I did put heat sinks on mine, on the back of the case. It's in the photos in the very first post I made at the start of this thread.
  6. That Percom Primer is where I first read about the issue with the mounting of the voltage regulators. I would have never thought about that, otherwise. And mine WERE mounted wrongly. However, I do think some of the info in there is wrong... Sigh. Meanwhile, I REALLY like this f9dasm/A09 combo. Using the author's pre-built A09 binary under Win7, I can just drag-and-drop the ASM file on it, and it spits out a 2K binary that binary compares exactly against the original ROM. And it was really not too much work. Now, moving all of phaeron's comments over is a bit of work, LOL. But I'm motivated. Even if no one else does, I think it's just a great idea to have the ASM code that will compile back into a working Percom firmware. And I really doubt, at this late stage, that any better ROM is going to show up! Even if one somehow does, the changes can be easily added back in. And I now have a foolproof ROM backup method. So I'm happy. Also, with Phaeron's great emulator, it's possible to change the ROM, load it into Altirra, and test it right there!
  7. Ok, I've spent a little time on this already, and I now have an ASM file that assembles back into the exact binary. Used f9dasm disassembler, and it's companion A09 assembler. Really easy. Now just have to add the comments back in, I guess. out.asm
  8. I had this same idea too, even though the "family" of Percom owners is fairly small, we now have the "latest-greatest" firmware, disassembled and documented. So, if we as a community, took that, fixed all the known bugs, and optimized it for size, taking out all the redundant code and tightening it all up, we could have the "perfect" firmware with added free space to put into EPROM and use. And new features too, no idea what. Certainly can change around the step-rate, sector skew, etc. Maybe even add enhanced density, or 77-track support, or whatever. And I'm TOTALLY willing to help with this!! No problem. Except: I'm not a 6809 guy. Someone else would be better suited. And I have no idea how to optimize/test a whole bunch of interdependent floppy disk drive timing-critical settings. My idea to start would be to get the source to compile back into the original first. Then optimize it for size, taking out all the unneeded code and jumps, etc., without changing functionality. Then there would be X number of free bytes to add things. And that would be a community decision, or leave it open for individuals to decide, having more free space in there. Maybe different ROMs with different features, etc. ABSOLUTELY I'm willing to do what I can. It's not stuff that is really my forte, but whatever I can. I'm really pretty good at optimizing code, but really just in 6502.... But I can learn.... And I have the time and inclination to do it. I love my Percom, LOL, and I'd like to make it the best possible.
  9. Well, I <AM> still actively working on it, and it's really meant to BE a programmer's tool. And I use it myself, which is why I wrote it to begin with, LOL. I could make it into a cart at any time, but I have been putting that off so far, because I'm still adding stuff!! So far it now also reads/displays the VTOC, does a short Boot Sector analysis that I was planning to expand, and I just added a feature that reads/displays the Percom block. I could make it write one also, it wouldn't be hard. And it's all in fairly tight, optimized assembly. It's just over 5K, so I still have 3K more left in which to add even more. I recently re-wrote large parts of it, and have been breaking it out into sections to be more manageable, it was getting to be too big for me to keep track of everything. It's not the world's cleanest-written code, but I think it's mostly bug-free. I don't like to ever release anything that I know has bugs in it. With that all said, it's just my hobby project, and it's based on the original code from like 1983 or something. I know a lot more now than I did then, so I'm trying to modernize it too. If someone wanted to help, with coding, or new ideas/features to add, whatever, that would be welcome as well. It's free for anyone to use, that was always my plan, I'm a supporter of open source. I have no deadline, and was not planning to set one, I just add stuff as I think of it. I'm willing to share the code at any time, but it's a bit of a mess right now!! I code stuff fast and then clean up later, I've always coded like that. I was honestly thinking of calling it "done" when I managed to put as much in the 8K as I can get in there, haha!! If you want the current code, just ask. I'm really very easy-going on this stuff, it's just a fun hobby for me. Let me know! Here's a working XEX of 1.5, incomplete and may still have bugs: SECTZAP.xex
  10. DavidMil will have to answer that, I don't think he mentioned it. He said it came from an old broken Percom he had. What I put it in was an RFD44-S1. In the meanwhile, I found phaeron's disassembly of the 1.2 ROM, MUCH better annotated than my sorry effort at it! I compared them, and there are very few differences between the 1.2 and this new (to me) 2.1 version. What I found, in the actual disassemblys, was the $1A1A sector fill bytes were changed to $0000 and also the DD fill bytes $9249 also zeroed. I also found the "format timeout" was changed to $8C from $7A or $7B or so (I forgot). Increased by a small amount, in any case. Also, a "check deleted sector" bit-compare flag value was changed from $20 to $28. I don't know what that does. Other than those 4 things, and some code moved around, they are otherwise identical, I believe. I only spent a couple hours looking at it, 6809 code is complex as heck! I think phaeron is supposed to be going over it too, and he'll do a better job than me, but I had the dump-file, and I had the time, so I did my best at it. It's a 2048 byte 2K ROM, and it's almost "full." I was hoping/thinking that some kind of upgrades/changes might be possible, but they would have to be small things, I believe.
  11. Ok, replying to myself, I did the necessary subtractions to get the skew orders from 1-18. Here they are: SD: 02,04,06,08,10,12,14,16,18,01,03,05,07,09,11,13,15,17 DD: 18,12,06,13,07,01,14,08,02,15,09,03,16,10,04,17,11,05 I'm just absolutely certain that these must be correct.
  12. So I made a trade with DavidMil, and I got him to send me an EPROM of his 2.1 ROM, which I have been testing in my real drive. Here is the dumpfile of it: RFDV21.BIN I installed it in my drive, and everything seems to work. SSSS, SSDD, DSDD, and it works with a 3.5" drive as D2: (I could do all of this with my old 1.1 also... ) And I "think" I like this new one better than my previous ROM. It seems a bit faster overall, and one thing for SURE! My old ROM, when formatting a disk would fill each sector with $1A bytes when formatting in SD, and two odd bytes ($92,$49 I think) when formatting DD. This new ROM properly ZEROES the sectors, as it should. This is good, because the non-zero sectors could confuse some sector copiers, and they would then copy all of them, instead of skipping the blank ones. As well, and I know almost NOTHING about 6809 assembly, I ran the ROM through the first disassembler I found (f9dasm) and took a stab at making sense of the code. Knowing that the ROM must handle Percom blocks, I annotated some of the disassembly, and also put blank lines after all RTS and absolute branch instructions, to make it into sections. Everything in my annotations is "guesses" but I'm pretty certain on some of it. If I spent more time, I could probably figure out more, but hasn't someone done this already? I think I read that, but I've never seen a disassembly released. I bet someone else (maybe a CoCo programmer) would have better luck with it. I've never done ANYTHING in 6809 before.... For what it's worth, here is my slightly annotated disassembly of the 2.1 ROM, with likely mistakes in it: output.rtf EDIT TO ADD: Ok, at the start of the disassembly, there are 18 non-repeating bytes, followed by 0, then 18 more non-repeating bytes, again followed by 0. These series are all within 18 values of each other. These MUST BE the sector-skew layout for both single and double density. This would explain the speed increase, I suppose. Also, there seems to be NOTHING in there that looks like support for 77 track disks. I'm quite sure that the Percoms just do not support that. Or Enhanced density either.
  13. erichenneke- I have a Percom drive (RFD44-S1) and a "similar" setup, with a PC-style 3.5" drive as the slave drive (set to DS1, as they usually are). Must use a STRAIGHT cable, no twists! Both work A-OK, DSDD and all. Like you, I also managed to put a ton of files on one 720K 3.5" disk. Here is what works for me. On the master drive, I have all 4 DIP switches set to ON. Contrary to the docs, but it works. On start-up, the slave drive must be powered on FIRST, then the master. Then power the computer. I also use MyDOS, and set the 3.5" drive to 80 tracks, double-sided, step rate 1. This is all working perfectly for me. Maybe try all 4 DIP settings to "ON". Also, my master drive has a shunt, which is like a hardwired DIP switch with no switches, and the only connections are DS0 and HM. Which is Atari D1: and HM is motor control. The Percoms seem to "motor-on" all attached drives normally, no way around that, I believe. See if this works for you. Much of the documentation seems to be error-prone. This setup is what worked for me.
  14. erichenneke- Hey, could you please post some specifics on HOW you got this to work? With the Percom or the ATR8000? Or both? What settings? What DOS? and etc., etc. etc... This could be helpful to other people too, if it were explained a bit more. I know it would be helpful to me, LOL!! Thanks!
  15. Haha, I'm just the world's least organized programmer. I think I sometimes edited it in Notepad++, sometimes in Windows Wordpad, and sometimes in Windows Notepad. So it probably has a mishmash of tabs, LF's, CR's and no telling what in there. As long as ATASM compiles it, I don't even think about it. And now I have a WIP 1.5 version, and I completely re-wrote large sections of it, and broke it out into multiple source files, because it was getting too big for me to find anything in there. You don't even want to see that source code, and I doubt that it would compile with MAC/65 anymore, since (i think) I used some features that are specific to ATASM - which is an assembler I do like. Once it get it all put together, I was planning to make it into an 8K cartridge format. It doesn't need or use DOS at all, anyway, and I think a super fast loading, cart-based disk utility would be handy. I still like using old floppy drives, I'm just from that era, I guess. Here's two new screens:
×
×
  • Create New...