Possible problem with cloned SGC and Minerva 1.98

Nagging hardware related question? Post here!
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Possible problem with cloned SGC and Minerva 1.98

Post 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...


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Possible problem with cloned SGC and Minerva 1.98

Post 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Possible problem with cloned SGC and Minerva 1.98

Post 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.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Possible problem with cloned SGC and Minerva 1.98

Post 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Possible problem with cloned SGC and Minerva 1.98

Post by martyn_hill »

Yes - I was hoping that wouldn't be the case, but I'm beginning to think it might...


Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Possible problem with cloned SGC and Minerva 1.98

Post 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.
Last edited by Derek_Stewart on Tue Mar 12, 2024 4:39 pm, edited 1 time in total.


Regards,

Derek
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Possible problem with cloned SGC and Minerva 1.98

Post 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...

:-)


User avatar
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

Post 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 :idea:

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


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Possible problem with cloned SGC and Minerva 1.98

Post 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 :-)


User avatar
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

Post 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.


Post Reply