Page 2 of 6
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 11:13 am
by martyn_hill
Thanks Marcel!
This is quite a find!
I'll also look at that scatter-load source (mdvsc_asm) - I note an explicit reference to that 4096 number in the comments - interesting that this is the same length threshold to trigger the crash...
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 11:32 am
by tofro
It would probably make sense to compare the original source to a disassembly of that part after patching. No time to do that, atm, though.
Tobias
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 6:32 pm
by martyn_hill
Hi team
I've started the (mind-numbing) effort to compare the dis-assemblies between original Min1.98 and after patching with SGC.
Whilst awaiting some clever soul to point out a much easier method, I've identified the following thus far by simply DIFF'ing the binaries of the first 48kB of the two ROM images:
Code: Select all
Start End
000D 002F
0069 006B
0081 00AF
0191 0191
0616 061B
0667 0667
06E8 06ED
0934 0939
1046 104B
43BA 43BF
451C 4528
4726 472B
4746 4751
47F8 47FD
AE5A AE67
Of the various routines patched by SGC, the MDV routines include the following - with 6 or 12 bytes replaced by absolute JMPs - in to the Upper 16kB IO space, where I guess SGC has mapped some more ROM/RAM.
Code: Select all
Start End xNumBytes
43BA 43BF x6
JMP HEX * Dec - Cross-ref to original Minerva Source
jmp $0001CA32 * 117,298 - Formats a microdrive medium: md/formt_asm (md_formt:89)
451C 4528 x12
jmp $0001CD62 * 118,114 - Select a microdrive: md/sedes_asm (md_selec:19)
jmp $0001CD5E * 118,110 - Deselect a microdrive: md/sedes_asm (md_desel:24)
4726 472B x6
jmp $0001CC30 * 117,808 - Microdrive read/verify facilities - Wait for Gap: md/read_asm (md_sectr:67)
4746 4751 x12
jmp $0001CC52 * 117,842 - Microdrive read/verify facilities - Read a sector: md/read_asm (md_read:92)
jmp $0001CC58 * 117,848 - Microdrive read/verify facilities - Verify a sector: md/read_asm (md_verin:96)
47F8 47FD x6
jmp $0001CBD2 * 117,714 - All microdrive write bits - Write a sector: md/write_asm(md_write:25)
None of the above include the MDV 'Scatter' routine, so I guess I'll need to keep looking at those other patched addresses... More to follow.
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 6:51 pm
by tofro
Well, the bug doesn't necessarily need to be in the patched areas of the ROMs - It could simply be some unfortunate timing on the faster GC and SGC...
Tobias
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 7:23 pm
by martyn_hill
Yes - I was hoping that wouldn't be the case, but I'm beginning to think it might...
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 7:35 pm
by Derek_Stewart
Hi,
There is an easier way to disassemble the code you require. Point the Disassembler at the part of the memory required, DISA, DEA can do this, also QMON can disassemble sections of memory. Assuming the correct memory area is known.
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 8:36 pm
by martyn_hill
Hi Derek
Thanks - yes, I have been using DEA to disassemble the routines around those 'patched' addresses and then, painstakingly, trying to match-up against the original Min v198 source - to discover which routines these represent...
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 9:29 pm
by mk79
martyn_hill wrote:I'll also look at that scatter-load source (mdvsc_asm) - I note an explicit reference to that 4096 number in the comments - interesting that this is the same length threshold to trigger the crash...
Below 4096 bytes the scatter load code is not used, the normal IOB.FMUL call takes over then... coincidence? I think not
I've started the (mind-numbing) effort to compare the dis-assemblies between original Min1.98 and after patching with SGC.
Don't waste your time! It's enough that I'm wasting mine here... I have understood and commented almost all of the (S)GC boot and patch code, it will be published once I'm finished. To complete the ROM I also need the FLP driver, which TT has promised to deliver but so far wasn't able to do so. But then the whole thing can be built from source again.
Interesting find of the day: the (S)GC doesn't have any static RAM, but still can remember some settings with the power off. How can this be
The solution: there is an "interrupt" register in the RTC chip that is not used as the interrupt is never enabled. But the register has 4 bits and the (S)GC firmware simply use the bits to hold its configuration
Anyway, the patching is definitely not the problem here. The scatter load briefly enables the interrupts, I expect the crash to happen there. But that is almost impossible to debug.
None of the above include the MDV 'Scatter' routine, so I guess I'll need to keep looking at those other patched addresses... More to follow.
The high level device driver is never patched, only the low level functions. Scatter load is part of the high level driver. JS doesn't have a sophisticated scatter load as far as I can tell, so doesn't expose the problem.
Marcel
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Sun Nov 11, 2018 10:04 pm
by martyn_hill
Thanks Marcel!
Meanwhile, I had satisfied myself that those low-level MDV routines (as used by the Scatter routine - md_read and md_sectr) that are patched by SGC are identical* to the original Minerva routines and definitely sit at the right memory locations (1CC30 and 1CC52).
* The only changes appear to be in md_endgp/gmr_wgap in how GAP-timing loop is set-up and that the default Minerva routine relies on the SP being manipulated in word-aligned increments. But otherwise identical.
I was wondering about that interrupt enable/disable couplet in dd/mdvsc
rep_enab
and.w #$f8ff,sr enable interrupts to allow in ext or poll
or.w #$0700,sr disable them again so i can have the whole ql
So, we might get an interrupt serviced between these two instructions... Is that what you were referring to?
I wonder if NOP'ing out those two instructions as a test might prove interesting... Time to burn another EPROM and see
Re: Possible problem with cloned SGC and Minerva 1.98
Posted: Mon Nov 12, 2018 11:39 am
by mk79
martyn_hill wrote:I was wondering about that interrupt enable/disable couplet in dd/mdvsc
rep_enab
and.w #$f8ff,sr enable interrupts to allow in ext or poll
or.w #$0700,sr disable them again so i can have the whole ql
So, we might get an interrupt serviced between these two instructions... Is that what you were referring to?
I wonder if NOP'ing out those two instructions as a test might prove interesting... Time to burn another EPROM and see
Yes, that would be my first try, too.