I wish @Lostgallifreyan would pop his head around the door; as I think I may have found a small bug in Org-Link. If I back up a FLASHPAK to an .opk, when restored back to the FLASHPAK it is rendered Read Only. Digging in to the binary; Org-Link is changing the PACK-ID Byte from 0x2E to 0x26. If I use a Hex editor and edit the ID back, save and use Org-Link to Make the FLASHPAK, it is formatted/sized correctly and works again R/W no problem.
However, he may have read the Tech Manual for the FLASHPAK that states the PACK-ID Byte is ‘normally’ 0x26 for a FLASHPAK - it’s not, it is indeed 0x2E.
In my experimenting, flipping bit 3 of the PACK-ID Byte achieves the write enabling/protection as a conventional EPROM pack and flipping the MSB of byte 8 (bit 7) as detailed in the TRM leads to unpredictable results. In my case MAIN disappeared but the FLASHPAK remained writable. The TRM is clear to state the PACK-ID Byte R/W bit is clear so if a FLASHPAK is used without the driver it will appear as Read Only. Again this is not true. If the PACK-ID Byte R/W bit is set for Write Enable but the driver has not been booted in, the FLASHPAK acts as a Read Only Pack. Anyone verify my observations?
You do not have the required permissions to view the files attached to this post.
Christopher. - Check out my TRAP message, it’s not difficult to decode and is sometimes uttered under the breath when said message appears…
(1) I've emailed Lostgallifreyan so he can come and have a look at your post.
(2) I'm interested in the 'error' you found in the tech ref manual.. 'However, he may have read the Tech Manual for the FLASHPAK that states the PACK-ID Byte is ‘normally’ 0x26 for a FLASHPAK - it’s not, it is indeed 0x2E.'
I can't update any online versions but I'm trying to keep the re-published PDF up to date.. You will see for example that Andrew and MartinP have made observations that I've included (Appendix D for example) If you can point me to the exact 'location' of what you think is the error and give what you consider to be the correct text I will endeavour to update the PDF copy.
Thanks Martin for letting me know there was a post here. (I've been working on very different stuff for a year or more, a phase modulation synthesiser called BlueStar that emulates Yamaha's original DX5, now with Steinberg licensed ASIO code so it performs very well through many USB2 audio hardware boxes, so if you want to try it, it's on my site where ORG-Link is..).
The pack write-protect flag problem is one I didn't know of. I used existing Psion code for that task, with minor modifications to allow both slots to work. To track this down, two things will help: 1, is it the same regardless of slot used? 2. Does the same thing happen when using the UNMAKE.BIN code from "devpack.zip"? (356400 bytes, can be found on sites various..)
If it happens with both slots, it's probably due to original code. If it happens with Psion's original programs that will confirm it.
The UNMAKE.BIN code from devpack.zip is what got used in ORG-Link. The modifications are mostly cosmetic, affecting consistency of appearance of messages during operation. If the original Psion code does the same thing, then Psion must have had a reason, but it may be possible to override it in the code. I'm reluctant to do it though, because ORG-Link aims to replicate all original methods (apart from what I thought were ugly message texts, and to add the ability to choose either slot.)
I'll check back in a day or three to see if anyone posts results of tests, or info about why Psion might have done things this way (if it was them who did it!) To maintain the detailed ability to handle this depends on continued familiarity with the Organiser (and the sometimes conflicting documentation), so I don't trust myself to do this without seeing input from people who are a lot closer to the subject than I have been for two years or more now..
NOTE: I was aware that to set state on a Flask pack needed different locations in addition to the original used for datapacks, but my method was to leave well alone. I limited my scope to replicating original behaviour, except in specific detail mentioned above.. In particular, I made sure that all traffic on the comms lines was identical to Psion's original comms, as I considered that to be non-negotiable. That had to be done with careful observation and testing to try not to miss anything, but I don't think the flag-setting thing is related to a problem with communications between devices.
If this gets resolved, it's likely that adding a switch to the config file might be best, to enable an override for those who want one, but only if we're all sure, because there are laws of unforeseen consequences..
A little update. @Lostgallifreyan - I shouldn’t have doubted you. Here’s what’s happening; and typical of PSION, there’s a lot going on under the hood.
When Org-Link transfers the FLASHPAK header creating the .opk, it does it perfectly byte for byte. I was wrong to say it may have altered the PACK-ID Byte. I was reading the 10 byte header from pkt_id which is the 4 element 10 byte long array in the system variables that acts as a RAM copy of the Pack headers; and comparing that with the .opk file created. This is where I discovered the PACK-ID is $2E in RAM, but is stored as $26 in the .opk.
I wrote a bit of machine code to read the actual header bytes on the pack itself and it remains $26 always, it has to if you think about it, flash memory bits start as a bit 1 and are blown 0. You can only get them back to bit 1 by a full format.
If a FLASHPAK is placed in the Organiser and read as is, the RAM header matches the real pack header and the pack shows as Read Only in Utils. When the pack is booted and the driver loaded; the driver is altering the RAM header PACK-ID Byte from $26 to $2E after reading if the MSB of the header byte-8 is set, as described in the FLASHPAK manual.
However, a FLASHPAK that is created from a (correct) .opk remains Read Only whether the driver is booted in or not. What’s happening to cause this? Reading the real header from the pack this time shows the PACK-ID Byte is $26 as above and in the .opk; but the FLASHPAK R/W bit is being cleared, (MSB of byte-8 in the header.) This is not recoverable as the bits on the pack can’t be set again.
A workaround is to edit your .opk with a hex editor - find the $26 and change to $2E, then make your pack with that. The PACK-ID Byte and FLASHPAK R/W byte are written correctly ($26 and $8E respectively).
Finally, I haven’t been able to check this with any of the other tools that Make a pack. From the TRM for FLASHPAKs,
“MAKE - version 3.20 and above will allow Flash Datapaks to be made in the ordinary way.”
Christopher. - Check out my TRAP message, it’s not difficult to decode and is sometimes uttered under the breath when said message appears…
Zenerdiode wrote: ↑Tue Oct 01, 2024 9:23 pm
A workaround is to edit your .opk with a hex editor - find the $26 and change to $2E, then make your pack with that. The PACK-ID Byte and FLASHPAK R/W byte are written correctly ($26 and $8E respectively).
Finally, I haven’t been able to check this with any of the other tools that Make a pack. From the TRM for FLASHPAKs,
“MAKE - version 3.20 and above will allow Flash Datapaks to be made in the ordinary way.”
I thought it might come down to that. :) Changing that byte to $2E after reception by ORG-Link, and before saving as a file, is probably the best default action, because as you say, we can set a bit to 0 once, but not back to 1 without formatting. If a person wanted to force write protection on, they'd set that bit to 0 in the OPK before making a pack. I'm not sure whether defaulting to 1 has weird implications for making a Flash pack from the writeable OPK image because Flash uses an extra byte elsewhere to determine driver access and actions, and it may need to 'think' that Flash is read-only to go on to use the other byte correctly. If this workround edit has no unforseen consequences for Flash vs EPROM, I think adding it to ORG-Link is the thing to do (as an option editable directly in the config file).
There may be a MAKE v3.3, I'm not sure why I think that, too many fading memories and different documentations. I tried to find it a few days ago but failed. ORG-Link has at least v3.2 though, I remember that much. I used the latest I could find any well-established precedent for using.
ORG-Link is using inbuilt Psion code that is sent to the Organiser. Unless my modification to allow the other slot missed something, identical action can be proved by comparing results of using the original Devpack system with those from ORG-Link. I'll risk predicting that they'd be the same.
