Possible problem with cloned SGC and Minerva 1.98
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: Possible problem with cloned SGC and Minerva 1.98
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...
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
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
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: Possible problem with cloned SGC and Minerva 1.98
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:
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.
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.
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
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)
Re: Possible problem with cloned SGC and Minerva 1.98
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
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: Possible problem with cloned SGC and Minerva 1.98
Yes - I was hoping that wouldn't be the case, but I'm beginning to think it might...
-
- Font of All Knowledge
- Posts: 3973
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Possible problem with cloned SGC and Minerva 1.98
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.
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.
Last edited by Derek_Stewart on Tue Mar 12, 2024 4:39 pm, edited 1 time in total.
Regards,
Derek
Derek
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: Possible problem with cloned SGC and Minerva 1.98
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...
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...
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Possible problem with cloned SGC and Minerva 1.98
Below 4096 bytes the scatter load code is not used, the normal IOB.FMUL call takes over then... coincidence? I think notmartyn_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...
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.I've started the (mind-numbing) effort to compare the dis-assemblies between original Min1.98 and after patching with SGC.
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.
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.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.
Marcel
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: Possible problem with cloned SGC and Minerva 1.98
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
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
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Possible problem with cloned SGC and Minerva 1.98
Yes, that would be my first try, too.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