Hi,
I recently created a patched version of Exile to run over Econet, which has been working fine until a few days ago, when I ran into an issue where the loader does not always detect SWR banks. In the unpatched version, the following snippet of code is executed at the start of the loader:
This piece of code was preventing the loader from loading the main game code from the Econet File Server. So what I did was remove this piece of code from the loader, and instead I added this code to the start of the main game code (which doesn't access the filesystem at all).
With this modification in place, what I suspect is going wrong is that there is unrelated traffic on the econet network, and it is generating excessive NMIs, which is somehow impacting the SWR detection code.
This is the SWR detection code:
A couple of things I'm not very clear on:
TIA!
I recently created a patched version of Exile to run over Econet, which has been working fine until a few days ago, when I ran into an issue where the loader does not always detect SWR banks. In the unpatched version, the following snippet of code is executed at the start of the loader:
Code:
lda #osbyte_issue_service_request ldx #&0c ldy #&ff jsr osbyte ; Issue paged ROM service call, Reason X=12 - NMI claimWith this modification in place, what I suspect is going wrong is that there is unrelated traffic on the econet network, and it is generating excessive NMIs, which is somehow impacting the SWR detection code.
This is the SWR detection code:
Code:
.sei_test_for_swram sei jsr test_for_swram cli rts.test_for_swram{ ldx #maxBank.loop_01 lda #&0fIF SWRAM_FE6x = TRUE sta user_via_ddrb stx user_via_orb_irbELIF SWRAM_FE6x = NOP nop:nop:nop nop:nop:nopENDIF stx lfe32 stx romsel ldy #<swram_base_addr sty zp_various_1b lda #>swram_base_addr sta zp_various_1c.loop_02 lda (zp_various_1b),y sta zp_various_b lda #%10101010 sta (zp_various_1b),y cmp (zp_various_1b),y bne test_next_bank lda #%01010101 sta (zp_various_1b),y cmp (zp_various_1b),y bne test_next_bank lda zp_various_b sta (zp_various_1b),y iny bne loop_02 inc zp_various_1c lda zp_various_1c cmp #>(swram_base_addr + swram_bank_size) bcc loop_02 rts.test_next_bank dex bpl loop_01 clc rts}- When the original (unpatched) loader claims the NMI code area, there doesn't appear to be any code in the loader that updates the NMI code area. From reading the BeebWiki, I would have thought it necessary to at least write RTI to &0D00.
- The unpatched version of the loader is designed to run from disk, so is possible that &0D00 would already contain RTI if DISC was the selected FS?
- I notice from the Wiki that the contents of Y (File system ID) should be saved when claiming the NMI code area so, when releasing the NMI code area, the original file system can reinstall its background NMI service routine. However, Y doesn't seem to get saved when claiming the NMI code area. I assume this step is unnecessary because the loader never attempts to release the NMI code area?
- If NFS is the active file system, and the loader code doesn't claim the NMI code area, why would a busy econet bus (with associated NMIs) cause the above SWRAM test to fail?
TIA!
Statistics: Posted by KenLowe — Tue Jun 10, 2025 1:44 am