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.
If you don't have a suitable T-Disc to take the barcode from, here is one:
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.
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:
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.
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? ☺
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).
So, at this point, we have:
Essentially, four different incarnations of Zap from four different places. Can you say clusterbeep?
- The official release
- Extras to make the official release work on modern machines
- Extras to make the extras work
- Extras to make the extras of the extras work
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).
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.
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
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. ☺
The problem was somewhere in the
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.
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):
MOV R0,#0 ; blat cache
MOV R1,#0 ; blat cache
SWI XDebugger_Disassemble ; blat cache
SWIVC XOS_ConvertHex8 ; start off with the address in hex
FNcallc Zap_MiniPrompt,VC ; prompt = address + colon
FNcallc Zap_ReadWord,VC ; get the instruction
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:
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.
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:
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.
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
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.
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.
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!]
So that, I guess, is the status of Zap...
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
List all b.log entries
Return to the site index
PS: Don't try to be clever.
It's a simple substring match.
Last read at 07:27 on 2020/07/09.
© 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.