Datapak Sizing

[Zenerdiode]

The Technical Reference Manual is incredibly detailed and descriptive in parts, but very woolly in others. I'm looking through the Datapak addressing sections - Chapter 9. I understand the page counting and segments from my 'breadboard RAMPAK', the Pack ID string and that the OS call PK$SETP does it all. Section 9.5.1 sets out explaining what PK$SETP does, again I understand that, but how does it work out the size and addressing type?

I can't see what the feedback mechanism is. I was thinking maybe it toggled the address counter with SCLK until it wrapped around, but can't see how that overflow would be detected. Also, it would probably have to start checking if it was a segmented pack first; otherwise it would be inefficient to start with the smaller pak addressing schemes. Just plonking the segment address on the databus, I can't see the feedback path to tell PK$SETP 'I don't support segment addressing.' Maybe it does a checksum of the whole datapak memory array (after all, it reports if the pak is not blank, all $FF).

I feel I'm missing something incredibly and fundamentally simple here.

[amenjet]

This is something I've wondered about. When Martin P and i worked on the datapack tool, one of the features that was worked on was a 'detection' option. That attempts to determine the addressing type of the datapack that is plugged in. It manages to determine paged or linear most of the time and does that by looking at pages and seeing that the data is or is not the same. This all falls down when the pack is an empty EPROM pack as everything is 0xFF. The Psion ROm must do some wort of addressing determination when it sizes a datapack. How it does this I don't know but maybe it writes the header and then looks at where that header is repeated throughout the pages and segments?
The code that does this determination must have been written with the full address range in mind as it happily determines the correct sizes of 256K RAM packs and 512K flash packs. I think the theoretical largest pack is 2Mbytes and so it probably looks for all sizes up to that limit.
So, no, I don't think you have missed anything, a disassembly of the ROM would be needed to work out exactly what is going on.

[Zenerdiode]

Code: Select all

4.  Log on the current slot.  The logon procedure is as follows:

                Read first byte of pack.  (Known as  the  ID  byte  of  the
                pack)

                If zero then return with ER_PK_NP (no pack in slot) and set
                first byte of ID string to 0.

                If $FF then blow to $7f, work out size  and  type  of  pack
                then save ID string to pack.

You know, sometimes just bouncing an idea off someone really helps. The snippet above is from the TRM describing PK$SETP. The last line describes what you're saying - and is the feedback from the pack that I'm looking for. So blowing $7F is just clearing bit 7 of the Pak ID byte. It then must spin through the addresses, counting up until it reads $7F again. And because all valid (MkII) paks have the Pak ID (Byte 0) bit 7 clear, it can just 're-blow' this byte if it needs to clear the copy or write protect flag bits etc.

After that, it has all the information to blow the remaining 9 bytes if the PAK ID string. It may indeed read every byte in the process; as it will report a 'PAK NOT BLANK' error during SIZING if it hasn't cooked long enough in the UV.

I appreciate you and MartinP did a lot of work on the datapack tool too.

[amenjet]

Code: Select all

4.  Log on the current slot.  The logon procedure is as follows:

                Read first byte of pack.  (Known as  the  ID  byte  of  the
                pack)

                If zero then return with ER_PK_NP (no pack in slot) and set
                first byte of ID string to 0.

                If $FF then blow to $7f, work out size  and  type  of  pack
                then save ID string to pack.

You know, sometimes just bouncing an idea off someone really helps.

This is known around here as 'talking to the pot plant' after people were told by a university tutor to talk to a pot plant or pet about any problems they had as just explaining a problem can sometimes help solve it.

The snippet above is from the TRM describing PK$SETP. The last line describes what you're saying - and is the feedback from the pack that I'm looking for. So blowing $7F is just clearing bit 7 of the Pak ID byte. It then must spin through the addresses, counting up until it reads $7F again. And because all valid (MkII) paks have the Pak ID (Byte 0) bit 7 clear, it can just 're-blow' this byte if it needs to clear the copy or write protect flag bits etc.

After that, it has all the information to blow the remaining 9 bytes if the PAK ID string. It may indeed read every byte in the process; as it will report a 'PAK NOT BLANK' error during SIZING if it hasn't cooked long enough in the UV.

That does indeed look like the way that the addressing is determined. It would be interesting to find it and see exactly what it does, maybe it could be used in the datapack tool.
It should be possible to track it down somewhere in the PK$SETP code path.