Jump to content

Nezgar

+AtariAge Subscriber
  • Content Count

    2,663
  • Joined

  • Last visited

Everything posted by Nezgar

  1. After lending a bit3 to Candle, lend it to tf_hh and maybe it can be replicated.
  2. No need to email apparently. With a little bit of searching, I found the ROM file they're using posted at the bottom of this page: http://www.eightbitclone.com/xf551.html The 16KB ROM, when split into two 8KB blocks has these 2 CRC32's: First: The first 4KB has CRC F3EEF923, 2nd 4KB is blank - Which matches a ROM I have noted as "Bob Woolley XF 720k" Second: E6D8F679 - Matches 8KB S.Dorndorf's Hyper-XF "B" for 720K 3.5" drives. (2nd 4KB is blank) So yes - locked in the "first" bank, you're using A "mostly" stock Atari XF-551 ROM, with Bob Wooley's patches for 3.5" use, as described here: https://www.atarimax.com/freenet/freenet_material/5.8-BitComputersSupportArea/7.TechnicalResourceCenter/showarticle.php?65 So indeed, you'll be limited to 38400bps "XF" highspeed protocol.
  3. Easiest method is using a cheap EPROM programmer to read it, such as the popular TL866, or inserting it into an Atari EPROM cartridge PCB. But thinking about this, its probably easier if I just email Zaxon and ask for a copy of what he's using.
  4. Got it working on real hardware (576K+UAV, no VBXE) , he he. I had an SCRDEF set to right column=39... i removed that and all good. It does seem to spend a lot of time drawing white lines on a dark background. Maybe it would be faster if it just changed the playfield colour to white, and drew dark characters, so as to use simpler E: whole line deletes and inserts? I'm sure all of this is way faster on the preferred VBXE hardware.
  5. Probably Pac-man, but that was not originally Atari... Anyhow, first thing that came to my mind was the cover of Jan 85 Antic Magazine:
  6. Intriguing - We've seen ATASCII animations on the 8-bit before, but not VT52! I remember those from the ST. Maybe the 80 column ones will work without VBXE by using RC_GR8.SYS + CON /E ? (I haven't tried yet) - albeit in monochrome only... Edit: Just tried - it appears to only use the left 40 columns, and leaves the right 40 columns blank/cut off. Edit 2: Woops, I probably need to SET VT52COL=80 - will try again later
  7. I'm curious about 2816 EEPROMS... would be handy for quick erase to test... Looks like the TL866 directly supports ATMEL AT28C16 which are readily available from eBay... Hah, well, now that I've looked, I couldn't help but pull trigger on 2 from here. https://www.ebay.com/itm/183371366623 We'll see if that gets cancelled too Looking at UV EPROM 2716's, they all seem to require 21V for programming, so will only work in a TL866 Rev 1, not the Rev 2, so I'm good there with my V1... But for now, its nice that 2732 EPROM's are a drop-in replacement in the PERCOM as well (using half of the ROM). I programmed your V1.2 into a fresh 2732 with the original 2KB content repeated twice since I don't know how the PERCOM keeps the highest address line, and it works fine. With more testing, I could figure out if it only needs the code in the higher or lower half of the 2732's 4KB ROM space. It will have to be in both if the highest address line floats.
  8. I re-dumped my VER 1.2 ROM while determining the process to use an Atari EPROM cart PCB for the job, saving out the cartridge memory area using DOS 2.5. This process consists of placing the 2KB 2716 EPROM into an Atari 16KB EPROM cart PCB C015783. With the 2716 EPROM in the right socket, the 2KB shows up at $A000-A7FF. With the EPROM in the left socket, it shows up at $B000 to $B7FF. Anyhow, using this process, my resulting CRC is 2372FAE6, with $FD at location $05CA, matching moonlight_mile's dump. The EPROM must just be marginal, maybe the TL866 programmer is reading it "too fast" compared to the real drive or the Atari computer. So I'll probably delete the bad dump from my prior post to prevent it's spread.
  9. Native trackball gray code support (not in joystick mode) Planetary Defense by Tom Hudson And followup Planetary Defense 2012 Maybe? I remember it for sure worked with my KoalaPad... Centipede Arcade - patched to use native trackball - this one's pretty fun Newer: Tempest Elite/xtreem
  10. Thanks phaeron for finding the definitive explanation on the TRS-80 front. It seems most plausible that Percom would just re-use their boards. I'd really like to see if a doubler board intended for a TRS-80 would work in an Atari Percom drive without having to spend $100+ to find out... I did see this on eBay: https://www.ebay.com/itm/153764663296 And the force was with you MrFish on finding that post by DavidMil - I'm going to followup with him!
  11. The ATR in your first post is NOT the same as the ATR from the post I linked to. Specifically: EA 40 sector boot skew align.zip
  12. Good news is the cracked ATR in this post works on my real drives, so should hopefully work with #FujiNet. And Diaperboy made a good writeup on the protections employed as well:
  13. First guess is timing... It reads sector 9 twice, suggesting a phantom sector check. if two consecutive reads don't return quickly = fail check.... But it gets past that part OK on a real drive as well as RespeQt just fine... But then farther along it does 21 reads of sector 1 and then starts jumping all over. It loads fine on RespeQt, (which has no inter-sector or inter-track latency....) I happened to have a Percom AT88-S1 connected so wrote out the ATR, and it indeed fails to boot -freezing - after the jumping around portion as well. It also fails to load on a Mini-Speedy with track buffering still enabled. Lastly.. it fails on a real STOCK 1050. FujiNet Track buffering may be inducing delays similar to a real drive, and the latency detection portions of the protection were not completely removed from this crack. Good news, FujiNet operates similarly to a real disk drive. 😁 [Disk 1] Mounted 'Pinball Construction Set.atr' as 'SD Diskette (90k)'." [Disk 1] Get status." [Disk 1] Read sector 1 (128 bytes)." [Disk 1] Read sector 2 (128 bytes)." [Disk 1] Read sector 3 (128 bytes)." [Disk 1] Read sector 4 (128 bytes)." [Disk 1] Read sector 5 (128 bytes)." [Disk 1] Read sector 6 (128 bytes)." [Disk 1] Read sector 49 (128 bytes)." [Disk 1] Read sector 50 (128 bytes)." [Disk 1] Read sector 51 (128 bytes)." [Disk 1] Read sector 52 (128 bytes)." [Disk 1] Read sector 9 (128 bytes)." [x2] [Disk 1] Read sector 10 (128 bytes)." [Disk 1] Read sector 11 (128 bytes)." [Disk 1] Read sector 12 (128 bytes)." [Disk 1] Read sector 13 (128 bytes)." [Disk 1] Read sector 14 (128 bytes)." [Disk 1] Read sector 15 (128 bytes)." [Disk 1] Read sector 16 (128 bytes)." [Disk 1] Read sector 17 (128 bytes)." [Disk 1] Read sector 18 (128 bytes)." [Disk 1] Read sector 19 (128 bytes)." [Disk 1] Read sector 20 (128 bytes)." [Disk 1] Read sector 21 (128 bytes)." [Disk 1] Read sector 22 (128 bytes)." [Disk 1] Read sector 23 (128 bytes)." [Disk 1] Read sector 24 (128 bytes)." [Disk 1] Read sector 25 (128 bytes)." [Disk 1] Read sector 26 (128 bytes)." [Disk 1] Read sector 27 (128 bytes)." [Disk 1] Read sector 28 (128 bytes)." [Disk 1] Read sector 29 (128 bytes)." [Disk 1] Read sector 30 (128 bytes)." [Disk 1] Read sector 31 (128 bytes)." [Disk 1] Read sector 32 (128 bytes)." [Disk 1] Read sector 33 (128 bytes)." [Disk 1] Read sector 34 (128 bytes)." [Disk 1] Read sector 35 (128 bytes)." [Disk 1] Read sector 36 (128 bytes)." [Disk 1] Read sector 37 (128 bytes)." [Disk 1] Read sector 38 (128 bytes)." [Disk 1] Read sector 39 (128 bytes)." [Disk 1] Read sector 40 (128 bytes)." [Disk 1] Read sector 1 (128 bytes)." [Disk 1] Read sector 9 (128 bytes)." [Disk 1] Read sector 50 (128 bytes)." [Disk 1] Read sector 41 (128 bytes)." [Disk 1] Read sector 1 (128 bytes)." [Disk 1] Read sector 54 (128 bytes)." [Disk 1] Read sector 1 (128 bytes)." [x21] [Disk 1] Read sector 217 (128 bytes)." [Disk 1] Read sector 19 (128 bytes)." [Disk 1] Read sector 145 (128 bytes)." [Disk 1] Read sector 37 (128 bytes)." [Disk 1] Read sector 253 (128 bytes)." [Disk 1] Read sector 55 (128 bytes)." [Disk 1] Read sector 37 (128 bytes)." [Disk 1] Read sector 73 (128 bytes)." [Disk 1] Read sector 1 (128 bytes)." [Disk 1] Read sector 91 (128 bytes)." [Disk 1] Read sector 19 (128 bytes)." [Disk 1] Read sector 109 (128 bytes)." [SNIP]
  14. "Normal" ROM would probably be one of the original Atari ROMs + patches by bob wooley for 3.5" 80 tracks. So it's probably only "highspeed" capable - 38400bps. If you can dump your 2764 and post here that can be confirmed...
  15. OK, that's a start. With phaeron's comments I would also lean toward Moonlight_Mile's dump since it burns less "extra cycles." Percom add-on drives do not contain controllers, and hence do not have any additional ROM/firmware. They are just bone stock standard PC compatible mechs in a case with a power supply and a card edge connector to connect with a ribbon cable to the drive with the controller. (up to 3 add on drives) The lower cost for additional drives was part of Percom's marketing pitch... http://www.vintagecomputing.com/wp-content/images/retroscan/percom_atari_large.jpg
  16. Thanks Phaeron - interesting. So basically we need more V1.20 dumps to tell if it's intentional, or a bit error. Or, maybe the earlier single density only ROM will help too. Stay tuned.
  17. Interesting, thanks - I didn't think to do a binary compare last night. I re-ran a verify on my EPROM 10x just now and got the same result. Moonlight: $FD = 11111101 Nezgar: $FC = 11111100 1 bit difference.... Since EPROM's erase to 1's, if this is due to EPROM bit-rot, it would suggest $FC as thecorrect byte. But a source code check might better tell us what it should be. If I'm reading @phaeron's dissassembly correctly, offset $05CA in the ROM equates to $FDCA in the AT88's memory map. The BNE istruction at $FDC8 would branch to the previous instruction forming a decrementing loop until 'equal' is met: FDC8: 4A DECA FDC9: 26FD BNE $FDC8 $FCC8 would branch to the middle of two instructions much earlier in the ROM, which appears nonsensical: FCC6: AEC810 LDX 16,U FCC9: 10AE4E LDY 14,U So... I believe Moonlight's dump with $FD at $05CA is correct. Interesting that bit-rot "programmed" that bit to a 0!
  18. Well, curiosity got my off of my arse and I dug out and cracked open my DD-capable AT88-S1, and dumped my ROM, and posted it over here: https://atariage.com/forums/topic/297197-need-help-percom-rfd-board/?do=findComment&comment=4493122 I also confirmed what we've been talking about here the Percom doubler PCB indeed has both WD1771 and WD1791 controllers. What silliness... Not sure if pictures of this PCB have been posted before, but I was unable to find any looking around yesterday and today, so here we are. Maybe a TRS-80 doubler is compatible? Maybe someone will recreate it one day in KiCad for OshPark?
  19. @moonlight_mile can you confirm what the ROM from your AT88-S1 label said? Because I just dumped the ROM from my double-density capable AT88-S1, labelled "460-0066-001 VER 1.2". The CRC32 of FD13A674 does not match yours, supporting @phaeron's guess that may be V1.3. This drive also does not have a printer port expansion, only the external drive connection card edge connector protruding from the back. The MPI mech has what looks like a QA tag and is stamped 2-20-84, bottom of mech Mfg date Oct 1983. With label removed, the EPROM is an NMC MM2716Q, mfg date June 27-July 3, 1983. * EDIT [Mar 31, 2020]: ROM dump removed - confirmed bad - see this post: https://atariage.com/forums/topic/297197-need-help-percom-rfd-board/?do=findComment&comment=4496546
  20. Yes, that is the case for most of the commercial "OSB" compatible ROM's.. PBI and International char set were often removed to make way for fun stuff. But was there ever a "highly 800 compatible" OS that retained PBI function? I can't think of one myself...
  21. 16KB of $FF is the same result you'd get from the TL866 with NO EPROM inserted in the reader... But yes, suggests a dead mask ROM ...
  22. Interesting about the lower/uppercase. I was wondering about that in the back of my mind too, it seemed out of place from Atari. It's all clear now if the original disk was uppercase, all pointing to someone's hacks. Thanks @bob1200xl for the authentic dump!
  23. TL866 is a cheap, popular programmer that supports a large number of retro EPROMs and other things: ie: Amazon: https://www.amazon.com/ARCELI-TL866II-Performance-EEPROM-Programmer/dp/B07CQQBGVK/ref=sr_1_140?dchild=1&keywords=tl866&qid=1585347425&sr=8-140 Ebay: https://www.ebay.com/itm/Programmer-TL866II-PLUS-for-ICSP-SPI-in-circuit-program-more-than-15000-ICs/192489415396?hash=item2cd14362e4:g:R9EAAOSwmgVdRDWS Aliexpress: https://www.aliexpress.com/item/32963724045.html?spm=a2g0o.productlist.0.0.43801c442pt1KD&algo_pvid=c99a8947-7d69-4e81-a154-d5590df3e8d4&algo_expid=c99a8947-7d69-4e81-a154-d5590df3e8d4-0&btsid=0be3764515853475222155538eb6f5&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_ Search around, you can get kits with a plethora of adapters for non-DIP size chips or save a few dollars and get just the base unit.
  24. I'd much rather see effort put into a PBI2PC-USB type device (or PBI2Ethernet or PBI2Wifi) Maybe functionality like FujiNet but orders of magnitude faster... FujuNet2? PBI2FujiNet? Like inconito/ultimate1MB PBI BIOS - PBI device drivers for disk, printer, serial, printer, N:, H: etc could all install automatically without any OS ROM modifications.
  25. Orientation looks correct according to the key embossed on top of the case next to the socket.
×
×
  • Create New...