warerat
-
Content Count
441 -
Joined
Posts posted by warerat
-
-
Thanks for trusting me to be your hands and eyes on the other side of the world to get this to you. Once I started unpacking and sorting through things to strategize how to best pack everything, it became apparent how special and one-of-a-kind this collection is. This was/is a substantial investment in software. I saw many titles I recognized but this was dwarfed by many more I didn't (some of them new in original shrink wrap, completely unaware they were now in the 21st century), as well as an extravaganza of cassettes. It was truly like stepping into a time machine and being transported back to that golden era. There are some real gems in this lot.
On a comical note, this shipment of four boxes made quite a commotion at the UPS store. Apparently the clerk normally only deals with small domestic packages and packing up cable modems to ship back to their providers. This was the most expensive international shipment that he had ever handled and was affirmed with gasps of astonishment and curiosity from the other patrons behind me at the total cost (this weighed a little over 160 lbs) and the contents of these boxes that would warrant such an expense. While working my way through the stack of customs forms and singing away, it was reminiscent of applying for a large loan. The best was the amusingly sardonic exchange with the clerk that went something like this through out this long process:
UPS Clerk: OK, I need to know... No. Sorry. CUSTOMS needs to know what is in these boxes
Me: Old computer stuff
UPS Clerk: Old computers? They don't have old computers in France?!?
Me: This is a special collection that is 30-40 years old.
UPS Clerk: No idea why someone would want to use a computer that old today, but we will make sure it gets to France; sign and initial here.
Lesson learned: If you're shipping something UPS, especially internationally, beware of using their website to estimate the cost. I had exact dimensions and weight and it still provided a rather under-valued total when done in person.
-
17
-
4
-
-
Also in Houston in the Clear Lake area.
-
1
-
-
I ordered an FD1797 from here a few years ago, don't know if they still have any: https://www.unicornelectronics.com/IC/CRT.html
U46 is a bi-polar PROM that loads the counter for the data separator and it does run hot.
-
2
-
-
10 hours ago, Nezgar said:No arcade connection that I know of. But got me thinking it might be audio data, so tried importing it as raw audio into Audacity but mostly sounds like random data there too.
The filenames are no hint, I dumped this data from unlabelled EPROM's myself, so had to name them something.
Labels covering the windows were removed, so it's possible that the data on them was from a 3rd party and the chips were intended to be erased and re-programmed.
Anyhow.. it's interesting the first 255 bytes are the same between the two differing dumps:
Not 6502, but close. It is 6800 (or close derivative). I’m using the 01 file. Look at the last eight bytes. There’s four big-endian addresses. The reset vector goes to $F259, the NMI vector goes to $E4C1.
In 6800-speak at $F259 you have:
1251 C1 AA cmpb #$AA 1253 27 03 beq $1258 1255 73 00 1C com $001C 1258 39 rts 1259 0F sei 125A 8E 00 7E lds #$007E 125D 86 66 ldaa #$66 125F B7 40 00 staa $4000 1262 CE 00 00 ldx #$0000 1265 86 AA ldaa #$AA 1267 A7 00 staa $00,x 1269 E6 00 ldab $00,x 126B 11 cba 126C 26 C3 bne $1231 126E 43 coma 126F 2A F6 bpl $1267 1271 6F 00 clr $00,x 1273 08 inx 1274 8C 00 80 cpx #$0080 1277 26 EC bne $1265 1279 86 20 ldaa #$20 127B 97 1F staa $1F 127D 86 31 ldaa #$31 127F 97 30 staa $30 1281 CE 01 A0 ldx #$01A0 1284 DF 5D stx $5D 1286 BD F2 23 jsr $F223Looks like a valid sequence for memory test code to me, including disabling interrupts on power up. That's no coincidence.
The NMI vector code at $E4C1:
04B8 86 02 ldaa #$02 04BA 8D 89 bsr $0445 04BC 8D D0 bsr $048E 04BE 8D A1 bsr $0461 04C0 39 rts 04C1 C6 57 ldab #$57 04C3 BD F1 F0 jsr $F1F0 04C6 3B rtiEven terminates with an RTI, that's no coincidence either.
-
8
-
-
3 hours ago, tschak909 said:Now that I think about it, I need to look at Avery's RHND850 replacement, as there is a relocator there (it's in the Altirra sources)
-Thom
I did some work on this a few years ago as I wanted the ability to build the 850 ROM code from the source Curt provided, but obviously the relocation code is missing. My guess is they had some helper program generate the offsets in the relocator table. This is part of the source I use with an automated build script that generates the 850 ROM in five phases (relocatable handler, handler arithmetic checksum, relocator, relocator arithmetic checksum, and main code). The only part that is missing is dynamically generating the offsets in the table (right now it is hard-coded), although some of the values I can get from the ATASM label dump.
DDEVIC = $0300 DBUFLO = $0304 DBUFHI = $0305 DBYTLO = $0308 DBYTHI = $0309 DTIMLO = $0306 DUNIT = $0301 DSTATS = $0303 DCOMND = $0302 SIOV = $E459 MEMLO = $02E7 DOSINI = $000C ZPTMP = $80 ORIGIN = $0500 *= ORIGIN .BYTE 0,3 ; FLAGS, SECTOR COUNT .WORD ORIGIN ; ENTRY ADDRESS .WORD $E4C0 ; ADDRESS OF RTS INSTRUCTION IN OS !!!!!!!!!! LDA #$50 STA DDEVIC LDA MEMLO STA DBUFLO LDA MEMLO+1 STA DBUFHI ; Original 850 Handler is 1425 bytes in size LDA #< HANDLL STA DBYTLO LDA #> HANDLL STA DBYTHI STA DTIMLO LDA #$01 STA DUNIT LDA #$40 STA DSTATS LDA #$26 STA DCOMND JSR SIOV BPL RELOC SEC RTS RELOC LDX # RELOCTABLEND - RELOCTABL ADJOFFSET CLC LDA RELOCTABL-2,X ADC MEMLO STA RELOCTABL-2,X LDA RELOCTABL-1,X ADC MEMLO+1 STA RELOCTABL-1,X DEX DEX BNE ADJOFFSET LDY #$00 STY TEMP1 JSR SETADDR ; Substitute variables LOOP1 LDA (ZPTMP),Y TAX INY LDA (ZPTMP),Y PHA LDA VARTABL+1,X STA (ZPTMP),Y DEY LDA VARTABL,X STA (ZPTMP),Y PLA JSR DECADDR BNE LOOP1 LDX #$02 JSR SETADDR LOOP2 LDA (ZPTMP),Y TAX LDA VARTABL,X STA (ZPTMP),Y LDX TEMP1 INC TEMP1 LDA DELTATABL,X JSR DECADDR BNE LOOP2 LDX #$04 ; set WRMXIT JSR SETADDR LDA DOSINI STA (ZPTMP),Y INY LDA DOSINI+1 STA (ZPTMP),Y LDA RINVEC STA DOSINI LDA RINVEC+1 STA DOSINI+1 LDX #$0C ; JMP to handler start .BYTE $4C RELOCTABL .WORD $03E9 ;RINCLD VARSTART ; $05AB .word $058F ; RVECTS+4 .word $04C2 ; PREPT+2 .word $03FC ; WRMXIT+1 VARTABL .WORD $0543 ;RDVTST 0 .WORD $069C ;IOCTRL-1 2 .WORD $0694 ;PUTCTR-1 4 .WORD $0698 ;RERROR-1 6 .WORD $06BD ;ACTSTR 8 .WORD $04B4 ;PREPUT 10 .WORD $06BC ;ALLDUN 12 .WORD $06BA ;RMAINV 14 .WORD $06BB ;RMAINV+1 16 .WORD $06B4 ;RVSAVE 18 .WORD $06B3 ;OUSTAT 20 .WORD $055B ;MAKDCB 22 .WORD $06BE ;RSCHAR 24 .WORD $06A0 ;RTRANS-1 26 .WORD $00C8 ;PAROUT 28 .WORD $04F0 ;CLHIBT 30 .WORD $04D2 ;PARITY 32 .WORD $0502 ;X32M1 34 .WORD $0611 ;OUTBAS 36 .WORD $04F9 ;CIRCIN 38 .WORD $0515 ;CMP16B 40 .WORD $06AF ;NXTOUT 42 .WORD $06B0 ;NXTOUT+1 44 .WORD $06B1 ;INSTAT 46 .WORD $06B2 ;INSTAT+1 48 .WORD $0525 ;CIN16B 50 .WORD $06A4 ;RSPRCH-1 52 .WORD $06B0 ;NXTOUT+1 54 .WORD $0582 ;JMPTABL+1 56 .WORD $0581 ;JMPTABL 58 .WORD $06AB ;BOBUF 60 .WORD $06A9 ;TOBUF 62 .WORD $06AC ;BOBUF+1 64 .WORD $06AA ;TOBUF+1 66 .WORD $0536 ;CINTRY 68 .WORD $0690 ;GETCTR-1 70 .WORD $06BC ;ALLDUN 72 .WORD $058B ;RVECTS 74 .WORD $0115 ;PTBFUL 76 .WORD $04DD ;SETRNS 78 .WORD $054F ;SPCDCB 80 .WORD $0223 ;STFUNK 82 .WORD $0571 ;HANDVS 84 .WORD $0413 ;RIN 86 .WORD $06AD ;NEXTIN 88 .WORD $06AE ;NEXTIN+1 90 .WORD $050C ;INC16B 92 ; These are offsets from ORIGIN ; HANDVS table .WORD $FFFF ;RHOPEN-1 .WORD $0025 ;RHCLOS-1 .WORD $015E ;RHGET-1 .WORD $006D ;RHPUT-1 .WORD $020C ;RHSTAT-1 .WORD $0256 ;RHSPEC-1 ; JMPTBL .WORD $0370 ;FORCE-1 .WORD $0395 ;CONTRL-1 .WORD $0389 ;CONFIG-1 .WORD $039C ;TRANSL-1 .WORD $0271 ;STREAM-1 .WORD $0473 ;ROUT RINVEC .WORD $03B3 ;RINWRM .WORD $0591 ;INBASE .WORD $03FE ;RBREAK RELOCTABLEND DECADDR STA TEMP2 SEC LDA ZPTMP SBC TEMP2 STA ZPTMP BCS DECXIT DEC ZPTMP+1 DECXIT LDA TEMP2 RTS SETADDR LDA VARSTART,X STA ZPTMP LDA VARSTART+1,X STA ZPTMP+1 RTS DELTATABL ; Table at $064B - what are these? .BYTE $0A .BYTE $E6 .BYTE $05 .BYTE $85 .BYTE $0B .BYTE $48 .BYTE $05 .BYTE $37 .BYTE $05 .BYTE $00 TEMP1 .DS 1 ;$0655 TEMP2 .DS 1 ;$0656-
1
-
-
7 hours ago, evilmoo said:Would it be possible for you to dump the ROM(s) from the Co-Power 88?
Thanks in advance.
This is from my 1MB Co-Power 88
-
5
-
-
Thanks for the helpful suggestions, but I'll pass on releasing anything because per your criteria you didn't pay me and I'm not the creator.
But don't despair. My efforts have already been disclosed to the relevant party, free of charge. However, I'm happy to take your money too so I can use it to spruce up my shitty video and release it to you in Beta format. This way you can view it in its ORIGINAL non-self-glorified professionally color calibrated splendor, in Dolby. Watch it a couple of times to understand how maybe turning your Ferenc-speak towards people that can help you down one notch can bear fruit. Because your formula obviously isn't working here.
But in all seriousness, I think a good starting point for you to help fix your problem can be found here: https://www.mayoclinic.org/diseases-conditions/narcissistic-personality-disorder/symptoms-causes/syc-20366662-
8
-
-
I guess I really do know what I'm talking about.
-
6
-
-
This is not going to work for hardware and software reasons, regardless of any settings.
There are incorrect assumptions about there being missing signals on Slot 3, or other memory slots need to be populated; this is all wrong. The only thing that makes Slot 3 is unique from the other two memory slots is D5XX-, D6XX-, and EXSEL- are present. That's it, no magic there. EXSEL- disconnects the CPU databus from everything physically behind Slot 1 (personality module, PIA, carts, POKEY). On Incognito, this signal is also connected to EXTSEL- on the PBI connector. They are not the same signal or function. This signal is part of the problem.
The logic needs to be modified to disable the bus in Colleen mode when this signal is asserted. That will allow the ROM to appear in the 256-byte window in $D600.
Once that is addressed then the next problem is that the Bit3 firmware itself uses some memory in the stack page at $100 that it assumes is free (zero) but has Incognito code written to it when reset is pressed that wreaks havoc on the bank switching.
But then again, what do I know as I was labeled a "third party" who can't possibly know anything about the internals by someone waxing poetic about the 800's super-duper architecture. 🤐
-
11
-
-
2 hours ago, MEtalGuy66 said:How much Charmin is this one worth?
Wow! That brings back some memories of late nights with a logic analyzer debugging the memory circuit on that thing. And the realization it was a miracle that it even worked with all those timing issues.
-
20 hours ago, MrFish said:What's up with the MIO v1.4.1 firmware that's on Rasterline.com? When I look inside the ROM file, I see "Multi-I/O Configuration v1.4.2". I also see references to an MIO v1.4.2 in some other threads: ICD MIO and ACard, Altirra 3.20 Released
I'd have to dig through my files and look at the code to see what was changed as it was quite some time ago, but I suspect it wasn't anything earth shattering between 1.4.1 and 1.4.2. I vaguely remember even regressing back to an earlier version.
-
21 hours ago, MEtalGuy66 said:I have 2 of them sitting right. Here. I was gonna sell them to Curt Vendell. But if you'll buy out his rights, Id be glad to price-gouge them to the highest bidder..
I'll trade you two packages of 9-count Charmin Ultra-Soft Mega rolls and 500rds of Russian 7.62x39 sealed in original wax for both.
-
2
-
-
10 hours ago, Nezgar said:Never knew of 1.2 and 1.3 until now. I'm interested, but it's been 30+ years already, so no rush.
Are 1.2/1.3 of ICD origin, or earlier improvements by @warerat on the journey to the current 1.41?
I would also hope it's been long enough now that the source code, at least for the ICD revisions, could be shared publicly.
As far as the differences between the 256K and 1MB versions of the MIO, the official ICD ROMs were created from the same assembly source, with a macro defining which version to build (their comments, not mine):
if ameg
jsr comkey ; waste 3 bytes... 1Meg and 256K versions
lda #$10 ; are not same size
else
lda #$04
endifThis is why there is an offset between both ICD versions. My guess is they did this to obfuscate the differences to discourage folks from upgrading themselves and having them do the memory upgrade for you. The other variants you might find out there likely just have one-byte difference ($04 vs $10). All this means is someone just patched the max bank byte on the 256K version to run on a 1MB, otherwise they are identical.
I know 1.2 is of ICD origin, but doesn't really have any major changes. Use at your own risk.
-
3
-
1
-
-
20 hours ago, Faicuai said:If you ask because your management is giving you trouble, let me know, I may be able to help. I do work in Management, as I directly oversee money, as well as dealing with Legal. So you can imagine the formula.
Now, leaving off-topics behind, and going back to what really matters, here's the list of open questions, condensed (one more time) for your convenience:
- Is the 800's dual floating data-buses preserved with Incognito, or is it implementing a "unified" data-bus, a-la 130XE?
- Direct readings from $D031 (TRIG3) under XL/XE mode yield in floating bus-data... They don't read 0 or 1, as expected. Why?
- Is it possible for CPLD to emulate actual $D013 (TRIG3) behavior on XL/XE mode (RD5 "virtual" wiring to GTIA's TRIG3), while, at the same time, reading TRIG3 inputs from Joystick 3 (&4) per underlying 800 HW (ACTUAL wiring of Joystick3 input into GTIA)?
Hopefully, this would help cutting the chase.
1. Mainly the latter but there are conditions where accessing ANTIC and GTIA I/O space disables the databus buffer and there are conditions where it is enabled because the personality board, cart slots, PIA, and POKEY need to be connected to the CPU.
2. Because the logic qualifying when to connect the data bus to the other half that isn't local to the CPU needs a small adjustment.
3. Yes, the internal I/O decoder select needs a couple more address lines (A5-A7) to qualify when to turn off GTIA so the foldback addresses don't trigger the internal register.
Chase ended and mystery solved.
-
2
-
On 6/25/2019 at 7:09 AM, slx said:Is there any OS that preserves normal 800XL functions but just replaces the self-test with the Rainbow splash screen? I'd like to put that in my Ultimate 1200XL to make the boot up look more "original".
I took that 1200XL splash screen file and reworked it to go into the self-test code space. The 6502 code in that 1200XL splash xex posted is pretty... baroque. I hope that wasn't Atari coding because I did the same thing with almost 200 less bytes. I also made one with a colorful ANTIC 4 fuji I ripped from some Atari music tutorial disk. To see them, boot up with no disk drives or BYE from BASIC.
It appears the self test code isn't computed in the main checksum so you can just drop that 2K into the ROM without any other changes.
atarixl-rev2-1200xlselftest.rom atarixl-rev2-fujiselftest.rom
-
6
-
1
-
-
Possible bad 3086. Swap A109 with A110 or one of the other CA3086.Quoting one of my earlier posts in this topic.
DavidMil kindly sent me a spare original ROM to try in my 850, but it also didn't work. Then I re-dumped both chips using a socketed Atari 8K cartridge PCB (showing at $B000-BFFF) and was happy to confirm that BOTH ROMs are actually still good, and verify CRC32 2CF990B9.I then replaced the ROM socket on the 850 PCB with a new machine socket not trusting the original that I had also partially damaged, also to no avail with either ROM. (absolutely no audible difference to the boot sound with the 850 attached or not with no disk drive attached)
Swapped the 6507 into a 1050, and it works there, so the CPU is OK.
I reseated every other chip on the board, and even reversed the two identical RIOTs between the two sockets. (I guess I could test them individually in a 1050 as well...)
A quick DMM Ohms check on each capacitor in-circuit showed expected slow gain to 0 ohms indicating it is taking up some charge, not seeing and obvious direct shorts or lack of continuity.
Full disclaimer: I'm pretty sure this 850 didn't work before I started all this now , but I'm interested to figure it out if anyone has any ideas...
-
1
-
-
I always wanted one of these back in the day. Anyone actually have one?
-
6
-
-
Modified to write unique filename based on CRC32 (for example D1:9201359A.ROM) so you don't overwrite the same file.
-
6
-
-
It seems to be generally pretty well accepted that the code in the 850 ROM has no capability to individually address each data line, similar to how there is no way to print a $9B (Decimal 155) byte, as there was no way to escape it in the firmware.
However, with exploitation of the undocumented "test and execute" command in the source code as warerat has done with his utility to download the firmware from the 850, I think this should be possible by using custom uploaded code to directly manipulate the PIA parallel port lines.
For about a year I've been trying to find a way to individually address the eight data lines of the printer port on the
850. Even thought a lot of people have said it's not possible, I keep looking. I came across this program in my
searches. I thought it was an interesting little program. That's all.
DavidMil
This is actually how I did the proof of concept to see if the 850 was executing anything. I connected a LED between pins 7 and 11 and wrote a loop to incrementally write all of the values to the printer port and if the D7 LED blinked I knew it worked.
If you want to do this in BASIC:
10 FOR I=0 TO 5:READ A:POKE 1536+I,A:NEXT I
20 DATA 96,1,130,141,0,169
30 POKE 768,80:POKE 769,1:POKE 770,32:POKE 771,128:POKE 772,0:POKE 773,6:POKE 776,6:POKE 777,0:POKE 778,6
40 POKE 779,0
50 INPUT VAL
60 POKE 1540,VAL
70 X=USR(ADR("hLYd"))
80 GOTO 30
IMPORTANT: The lowercase d inside the ADR in line 70 is inverse video.
When you run it, whatever value you input is written directly to the 8-bit printer port D0-D7 without intervention from the printer driver.
-
5
-
-
A 2532 EPROM? Further suggesting 'early release'.
But that gets me thinking.. I have some 2532s, I didn't think of trying one in my 850 because I got one working in a 1050 in the 2332 mask ROM jumper configuration, but it required inversion of the CS/PD (A14/Pin 20) signal to get it to work, otherwise it gets a permanent 'low' causing it to never disable and clobbers (repeats itself) in the lower 4K in the memory map. Will be interesting to compare what that 850 board does compared to one shipped with a mask ROM. I'll have to try it.
It's possible the behaviour of that early 850 was modified to put an inverted signal on pin 20. I recall the assembly instructions for the bare board had optional steps for using a 2732, which implies an inverted A14/CS/PD signal is available somewhere on the board.
There are two traces cut (one on top and one on bottom) and a transistor is used as an inverter.
-
4
-
-
You're welcome Nezgar!
Okay My testing method was not precise. I've re-tested both 850's here. The both behave the same. My previous invalid tests I was doing SELECT+RESET (U1MB cold boot) and that does NOT allow reloading of the R: handler. However a proper power off then power on of the computer itself allows the R: handler to be downloaded again without power cycling of either of my 850's.
However both 850's do not allow multiple loading of the R: in the same powered-on session of the 800XL (so it seems), except if I power cycle the 850 then I can download the R: handler again as many times as I want without rebooting the Atari. This is fun now that I'm mid-life.
That R: handler beep is a great nostalgia sound for me! hahaNot really an issue anymore. I wrote a reset program, just run it to cold start the 850 with out powering anything off: http://atariage.com/forums/topic/289938-bare-850-printed-circuit-board/?p=4267216
-
1
-
-
Dude! Nice early black metal case.
It would suggest an earlier revision ROM...Can you post the 9201359A ROM file here?
Could you also post a picture of the chip in that box?
Pretty unremarkable, really. Just a 2532 EPROM with a handwritten label.
-
2
-
-
I pulled out my 850's and set up a test machine in a corner. I knew at least one of my 850's was guaranteed to have different firmware.
-
6
-
-
Sorry for hijacking this thread one last time.
I did a code shrink/optimization (saved over 60 bytes) so it shaved a few seconds off the download time, plus you get some progress feedback now in the form of a period every 256 bytes while it's downloading (16 dots = 4K). It takes about a minute because there is a high SIO call overhead to pull the 850 firmware into local memory. There are three SIO commands sent for every two bytes extracted (6144 SIO command frames in total): one test/execute command that uploads 6502 code to read a pair of ROM addresses, and two direct back-to-back status commands from R1: and R2: to read that byte pair back.
-
5
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
800xl not reading any cartridges
in Atari 8-Bit Computers
Posted
I suspect the MMU, but you’re going to need some other tools (hardware and software) besides a continuity test to validate this. There’s nothing particularly special about the MMU, it’s simply an address decoder with lots of inputs and all logic equations are known. People like to throw shade on the built-in self test as the RAM tester isn’t particularly rigorous, but at the very least it will checksum the OS. So if your self test shows green on both ROM blocks, you can reasonably assume your OS chip is OK. If it fails, it can be the MMU or the OS chip. I'm going to assume it's not the OS because you can jump into BASIC. If you have a device programmer you can make your own MMU with a GAL or a PAL16L8.
If you examine the schematic of the cartridge slot and the logic associated with it, the relevant pins to focus on the MMU are 7, 8, 12, and 19. Pins 7 and 8 are the “ROM Detect” lines that disable the onboard RAM when there is an 8K block of ROM present. These are pins pulled high on the cartridge PCB to change the memory topology depending on whether it needs an 8K or 16K hole in the address space. RD4 (pin 7) and RD5 (pin
disable the system RAM at $8000-$9FFF and $A000-$BFFF, respectively, and also enable the active-low ROM chip selects S4- (pin 19) and S5- (pin 12) for cartridge. They both have pull-down resistors to ground in their normal (no cartridge) state.
Step one is to see if the RD lines are working from the cart slot to the MMU pins. I’m assuming you know how to use a voltage meter or better yet, have a logic probe.
No cartridge: pin 7 low, pin 8 low
Star Raiders: pin 7 low, pin 8 high
Pole Position: pin 7 high, pin 8 high
If you don’t see those logic levels on the MMU pins, you have either have an internal short in the MMU or a bad connection from the cart PCB <-> cart slot <-> MMU. To isolate the MMU, simply remove it from the socket and test those same pins without it present. If don’t you see those levels without the MMU in the socket (the machine obviously won’t work), then you have a physical connection issue. Otherwise, if you see the right levels with the MMU removed, then the MMU is at fault.
Step two is to see if the ROM selects are actually triggering. With Star Raiders, you should see activity on pin 12. You have a use a logic probe or oscilloscope for that, as the transitions will be too fast to register a voltage meter. If you don’t see pulsing on pin 12 after you push reset, then the MMU is most likely bad or there is a connection issue (or the cart is toast, but you've tried too many). Alternatively, if the machine is otherwise working and you have a way to boot something, I’ve used a tool called DEBUG+ for years that I modified to load into low memory (by default it loads into $A100, which obviously won’t work with a cartridge inserted so the custom version loads into $2100). You can actually use whatever tool you want really, as long as it doesn’t load into the cartridge area. The premise here is you want to examine the memory to trigger accesses to the cartridge address space and see if there are pulses on pin 19 for $8000-$9FFF, or pin 12 for $A000-$BFFF. The pulses will only be present in those ranges if the corresponding RD line is high. The benefit of using a memory debugging tool like this is you can also see if there is valid data when the ROM is enabled, so you could also conceivably diagnose a data bus or address bus fault if you know what is supposed to be there. If the selects aren't enabling the ROM, the bus will float and you’ll see data values corresponding to the upper address byte that will change when you cross a page boundary. What this looks like can be simulated by pulling the ROM chips on a cartridge.
The moral of the story is: troubleshoot before shotgunning chips. I’ve got a stack of arcade boards I’ve repaired where previous owners replaced dozens of chips but completely missed the blatantly obvious problem that would have made it a ridiculously simple repair (along time and money saved) had they spent 5-10 minutes with a logic probe in a critical area.