HAOUI wrote:pjw wrote:
... Wherever possible, if I need an extension I try to write is in assembler. This is because I started out with a 4K computer and still find it traumatic to use 16K to implement an UPPER$ function. But dont mind me. You never know when you might need some extra kit in your toolbox!
I totaly agree, as you, I've always written extensions in assembler, but being older and busier man, I found some benefits to write some BASIC programs (quicker to write and run for start but much longer to make reliable) especially for Proof Of Concept. Memory no more limited with QPC2...
I am very pleased to hear that you are both enthusiastic about assembler. About the decompiled Q_Liberator, I have been thinking of the future, where we are going, etc.
Per, you have mentioned recently about hex%, bin% and the PEEK variety wanting to be included for. We are needing to get inside "NEXT_TOKEN", which is a machine code procedure which reads the next token. This would need to be disassembled, amended to cope with the above-mentioned features and re-assembled. I don't do any assembly myself, so would not know how difficult this would be. So, may I ask you both, would you be interested in investigating this, please?
There are 2 routines actually, NEXT_TOKEN with 6 parameters and RNAME with 4 parameters. The full spec is ..
NEXT_TOKEN sym1%, sym2%, sym3, sym4$, End_of_Stmt%, End_of_Line%
RNAME name_adr(sym3), p0%, struct_base%, FOR_ranges%
The above appears in the program at lines 19440 and 19480. The reason why RNAME is important is that in the case of PEEK, sym1% will obtain a value of 6, which means a name, and here, the ON GOTO will jump to the line number that calls RNAME, so this may affect matters or not, I don't know.
This is certainly very exciting. If it cannot be done, we could always try to do this in S*BASIC, but my guess is that assembly language would be more appropriate here. I look forward to hearing what you think.
Michael (EmmBee)