Rick's b.log - 2018/04/28
You are 18.118.28.89, pleased to meet you!
|
Rick's b.log - 2018/04/28 |
| It is the 18th of December 2024 You are 18.118.28.89, pleased to meet you! |
|
mailto: blog -at- heyrick -dot- eu
If you don't have a suitable T-Disc to take the barcode from, here is one:
All was fine, but I didn't fancy taking over maintaining Zap; what with it's licence status mostly "undefined" (such things were not a big issue in the mid '90s). The licence says:
I am breaking this licence, since those who used to maintain Zap have moved on, and - well - where's the official "works on my Pi" release? ☺
So, at this point, we have:
So I've held off doing anything with Zap.
Until this week.
When a peculiar bug turned up.
You see, back in the 26 bit days, we had two Debuggers. We had the standard Acorn Debugger module that was functional but rather crap. Then we had Darren Salt's enhanced Debugger (many extra features, understands stuff like ADRL, NOP, LDRL, fixed some of the weird issues with Debugger, etc etc).
Anyway, I digress. Darren made a Debugger, and he gave it version number 2.something to distinguish it from the standard Debugger.
Zap used the version number to detect which Debugger was loaded. And, well, with RISC OS 5.25 and the various enhancements to Debugger along the way, it has itself incremented to version 2.00.
At which point a useful feature of Zap, the ability to modify an instruction in-situ, suddenly stopped working.
Now Zap predates DADebug, so I had to "debug" (term used loosely) by using the time honoured tradition of dropping in
The problem was somewhere in the
Part of the code that builds the content of the minibuffer (the part that appears at the bottom of the window) is (this has been tidied):
Now look at the first block of code again. It's pretty much all conditional on V being clear, until we fall out on the FNRTS in the penultimate line.
That is why the minibuffer was failing. The code incorrectly believed DebuggerPlus was present, issued a SWI not understood by regular Debugger, and the V set meant everything else would just not happen.
My fix was to do this:
You can pick up my latest tweaks here (version "rick-02").
For the hell of it, I built Zed, the Zap font editor. It's a bit crashy-crashy with UCS fonts, but otherwise seems to mostly work.
I have also disabled the
An outstanding problem is that the helper programs "MakeMenus" and "MenuConf" are not 32 bit. They appear to require "libgnu" and "coopt" - neither of which I have been able to find.
So that, I guess, is the status of Zap...
Easy tea
I've not had the time or inclination to mess around with the Tassimo barcodes to work out the correct bit assignments. So for now, the simplest option is to simply cut out the barcode from the English Breakfast tea, and stick it to the service/cleaning disc.
This will gently dose out around 280ml of very hot water. Perfect for placing a mug underneath with a teabag and sugar inside. And a lot quicker than waiting for a kettle to boil.
Print it out in a rectangle that is 24mm wide and 10mm tall. Stick it over the original service disc barcode, with the code number towards the inside of the disc.
Try it to make sure it can read it, the barcode may need to be repositioned. Then when it works, stick it down firmly (I use surgical tape as it is more water resistant than sellotape).
More to do with Zap
A while back I tried putting together an "ultimate distribution of Zap" after having discovered that the ZapMJE extension (colourises C and assembler source, you can see why I depend upon it!) no longer worked due to ARMv7 incompatibilities.
Copyright of the application `Zap' is held by its authors 1992-2002.
No guarantee is made as to the reliability/stability of any part of Zap.
You may distribute Zap freely; however we request that you do not distribute Zap, except as you received it. This request is made in order to try to ensure that the options remain in their default state, and all help text is included. This should help make Zap easier to use for subsequent receivers of the program.
That said, tank has made releases of Zap (mostly work to bring it up to speed on a real 32 bit system), then André Timmermans (fixing zero page issues), then me (some other fixes).
Essentially, four different incarnations of Zap from four different places. Can you say clusterbeep?
While Debugger these days is a lot more powerful (plus up to date), it is still lacking the flexibility of Darren's one. For instance, ADRL is now flagged as a Long ADR, but it appears in the disassembly as:
ADR R1,&00000580 ; Long ADR
ADD R1,R1,#&10 ; =16
Where it would have been better to replace that with something like:
ADR R1,&00000580 ; Long ADR
ADRL R1,&00000560 ; Long ADR target
In this way, you could press right arrow to follow the address in Zap; and maybe Zap could spot this and annotate what was at that location (; -> code: at &00000560 or ; -> string: "meh"). It's little things like that which make life simpler.
SWI 256+7, which is essentially a VDU7 command. Then I'd put on headphones and run the code, waiting for the BEEP!. After a few times, I turned the volume down a tad. ☺
ASSEMBLE command, which is embedded directly into Zap in the Mode4 handler (that which handles the disassembly), but as it turns out, the command is not provided by Zap itself, but by the ZapBASIC extension.
prompt$l
BL loaddisasm
MOV R0,#0 ; blat cache
MOV R1,#0 ; blat cache
SWI XDebugger_Disassemble ; blat cache
BLVC carefully_getdisasmdata
STRVC R0,local_disasmdata
LDRVC R0,localrfive
FNLDR R1,buf_detoken,VC
MOVVC R2,#&100
SWIVC XOS_ConvertHex8 ; start off with the address in hex
FNLDR R0,buf_detoken,VC
FNcallc Zap_MiniPrompt,VC ; prompt = address + colon
MOVVC R0,R6
FNcallc Zap_ReadWord,VC ; get the instruction
LDRVC R1,localrfive
MOVVC R7,R0
BLVC like_Debugger_Disassemble
FNRTS VS
FNLDR R2,buf_detoken ; buffer to copy detokenised line
The first line calls loaddisasm, which checks to see if the user wants to auto-load DebuggerPlus, and will load it if it's not present. It uses version 2.00 as it's version check, so it will think DebuggerPlus is already loaded.
Then we come to carefully_getdisasmdata, which is this:
carefully_getdisasmdata
FNJSR
BL checkseeifdisasmloaded
BVS gracefully_do_nothing
MOV R0,#0
MOV R1,#0
SWI XDebugger_63
FNRTS
gracefully_do_nothing
SUBS R14,R14,R14
FNRTS
This, as you can see, checks to see once again if DebuggerPlus is loaded. Now, again, it will think that DebuggerPlus is loaded, so what it'll do is call XDebugger_63 thinking that it's a supported SWI. It isn't. So it'll return with V set.
carefully_getdisasmdata
FNJSR
FNRTS ; ##RICK##
; ##RICK## This appears to do something unusual if DebuggerPlus
; is loaded, and it has the side effect of setting V
; if not which messes up the rest of the Assemble function.
; Fixes bug where the minibuffer doesn't work in RISC OS 5.25.
BL checkseeifdisasmloaded
BVS gracefully_do_nothing
MOV R0,#0
MOV R1,#0
SWI XDebugger_63
FNRTS
gracefully_do_nothing
SUBS R14,R14,R14
FNRTS
DELWORDSTART and DELWORDEND commands (mapped in as Shift keypad * and #). These delete from the cursor position to the start/end of the current word, only it doesn't work. Crashes.
I have some source for "libgnu", but it won't build with the older AOF-compatible version of GCC because that isn't ARMv7 friendly; and I have no idea what the hell is going on with the current ELF version of GCC - can it even create AOF libraries? But, then, without coopt (whatever that is), I'm really no further forward.
The moral of this story - if your code depends upon some weirdo libraries, ensure that they (plus source) are available, or have some way of being found! [just tried Arcade, isn't there either!]
No comments yet...
| © 2018 Rick Murray |
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted. RIPA notice: No consent is given for interception of page transmission. |