How can PK$save be stopped from adding an extra byte 'FF'?

[Lostgallifreyan]

It's a lot of effort to disassemble and comment a ROM, though, and it would have ot be a multi-person effort.

Hi amenjet, can your tracer be used in the following method? It will be very helpful if you can get a trace for this.. It might be the fastest way in.

Background: The problem is solved for 33-LA.rom, any non-zero value put in address $2408 immediately before calling PK$save, but it only works for that early ROM despite there being relatively few differences between the relevant code there and in 36-LA.rom, and there are three TST $2408 instructions, and I don't know which if any is the right one to examine closely. If references to the address are made in the form of offset relative to address in X, the possibilities might be too many to discover easily.

What might narrow it down is if you can run the test program twice for 33-LA.rom with a change of the value in $2408 from 0 to NOT 0, tracing to get a different result in each case, comparing those traces might find the best info yet.

The following code is a variant of the one in the previous post, but instead of forcing a byte value, it uses OIM to set bits because from what I've seen in code, Psion like doing this, so I assume that there may be existing bits they want left alone during the process. For now, this is not important, it will likely only apply to ROM later than 33-LA, so knowing how 33-LA changes its actions when that byte at $2408 is set or reset immediately before calling PK$save is enough to work with for now.

Code: Select all

A:
LOCAL M$(12),C%(13)
M$="PK$save Test"
OPEN "B:MAIN",A,A$ :FIRST :CLOSE :rem saves a lot of machine code if you do this first.

C%(1)=$3F2D :rem SWI FL$frec
C%(2)=$DC41 :rem LDAB 0m
C%(3)=$3F60 :rem SWI PK$sadd

C%(4)=$01CE :rem NOP,LDX byte address.
C%(5)=$2408 :rem Byte address for tests.
C%(6)=$0162 :rem NOP,OIM BYTE at OFFSET from X
C%(7)=$FF00 :rem FF OR BYTE at $2408 (maybe try $2407 too).

C%(8)=$01CC :rem NOP,LDD Byte count
C%(9)=12    :rem BYTE COUNT
C%(10)=$01CE :rem NOP,LDX Source string
C%(11)=ADDR(M$)+1
C%(12)=$3F61 :rem SWI PK$save
C%(13)=$3900

USR(ADDR(C%()),1)

Also, if I got the byte order wrong for the arguments in C%(7) for the OIM instruction, please let me know. I had to think about that one, the docs looked ambiguous, so it may be wrong here.

[Zenerdiode]

If anyone tests this on hardware, please let me know what you find.

Just tested on an LZ64 V4.2 (must have been an early device) and writes a $FF block.

[Lostgallifreyan]

If anyone tests this on hardware, please let me know what you find.

Just tested on an LZ64 V4.2 (must have been an early device) and writes a $FF block.

True, but I changed the title of the thread in my previous post (and again here), to indicate for the most recent knowledge.

I've reduced the task to a need for a trace using my test program and the 33-LA ROM, and a setting of the byte at address $2408 to either zero, or non-zero. This is meaningful because it's the only event known to provoke a relevant change in the behaviour of the program. Knowing how the code branches based on this change will reveal differences in branching, flags, etc. Knowing exactly where it does this will help to find exactly how the other ROM versions use the byte at address $2408 (and maybe $2407 as well) to determine how to change the action.

The problem is at least partly solved, because in 33-LA.rom, the result is exactly as wanted (though it may still be possible that other unseen consequences occur.)

EDIT:

Code: Select all

A:
LOCAL M$(12),C%(13)
M$="PK$save Test"
OPEN "B:MAIN",A,A$ :FIRST :A.A$="ZoodleWurdle14" :UPDATE

C%(1)=$3F2D :rem SWI FL$frec
C%(2)=$DC41 :rem LDAB 0m
C%(3)=$3F60 :rem SWI PK$sadd

C%(4)=$01CE :rem NOP,LDX byte address.
C%(5)=$2408 :rem Byte address for tests.
C%(6)=$0162 :rem NOP,OIM BYTE at OFFSET from X
C%(7)=$FF00 :rem FF OR BYTE at $2408 (maybe try $2407 too).

C%(8)=$01CC :rem NOP,LDD Byte count
C%(9)=12    :rem BYTE COUNT
C%(10)=$01CE :rem NOP,LDX Source string
C%(11)=ADDR(M$)+1
C%(12)=$3F61 :rem SWI PK$save
C%(13)=$3900

USR(ADDR(C%()),1)
FIRST :PRINT A.A$ :CLOSE :GET

I should have done that before. It's a minimal change but it saves no end of poking around with FIND and SAVE on B:MAIN to view a result and reset it for another test. Just make sure that B:MAIN has only one record, with one field in it. The test program will handle everything else.

I tried OR-ing each bit at $2408 to set it (using C%(7)'s second byte), and trying the low integers 3 and 5, hoping to find some obvious possible switch value, but none worked on ROM 36-LA.

[amenjet]

I'm having trouble running that ROM due to the speed it runs at I think, so I'm not sure if I can get that trace. The keyboard scanning is too unreliable to use.

[Lostgallifreyan]

I'm having trouble running that ROM due to the speed it runs at I think, so I'm not sure if I can get that trace. The keyboard scanning is too unreliable to use.

No worries, and thanks for having a go. I knew it might be a big ask. I doubt even Psion have done this before because they'd have had original commented code.

I had the bright (dumb) idea to brute-force the thing on ROM 36-LA by iterating 65535 tries of a WORD at $2407, and looking for an occurrence of '1' instead of value $FF at the spot indicated, as a way to stop running and print that WORD so I know the first rising value that results in no $FF, if any. I'll try that later. It eliminates a lot of boring possibilities even if it fails.

[amenjet]

Maybe Jape has a debugger? That is a 6303 emulator and so can run the ode, all you need is a way to single step and examine registers. The code is available so could be modified, I think.

[Lostgallifreyan]

Maybe Jape has a debugger? That is a 6303 emulator and so can run the ode, all you need is a way to single step and examine registers. The code is available so could be modified, I think.

He might, but he's still silent even after I recently told him his latest suggestion was basically correct. I won't push, it would reduce the chances of him responding in future if he didn't want to do it now..

Also, he did not know about the extra 'FF' written after the requested write, so while his tools may reveal some changes in branching of code, I doubt they could result in a reliable test of outcomes. There may be some other reason he missed that 'FF' (perhaps merely because it's usually written where one already exists!), but unless he tells me I can never know. It's (probably) important that Jape does not cause the extra 'FF' even though the ROM code used is the same. All of this indicates that even correct use of the code may not be enough to solve the problem for all hardware.

[Lostgallifreyan]

Maybe that routine is working with a concept like the OPL records? They are manipulated then written later, I think. The actual write must be done in some other call.

Did it look like there was some other call to a subroutine right after points you identified already? If the first branch that looked specific to PK$save was actually some buffer-copying routine (likely enough), then it had to return to just after a call, and there may even be a series of those in one location.

I looked at your main series of posts on page 3 of the thread, and if I have to start detailed examination and notation, this is where I'm going to do it, but ten days of bronchitis are still slowing me down (more than usual), so if you can identify a node that might be a major branching of preparations for more than one service, ultimately heading for the routine that does the $9703 pack write data setting in at least one instance, that will give me a useful chance of containing the area I have to work on. I suspect that code for RAM pack writing might well be the shortest route between the two points. :)