Dr. Jim's QL Dumping Ground

Anything QL Software or Programming Related.
User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: Dr. Jim's QL Dumping Ground

Post by RalfR »

So it seems, uQLx can be a bit like the Atari Extended Mode4 adapter, but whithout saying so.


4E75 7000
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Dr. Jim's QL Dumping Ground

Post by pjw »

XorA wrote:<>Depends if the bug is fixed in Minerva, uQLx only supports the extended screenmodes when running Minerva!
Ah, Id forgotten that. You can have a larger-than-screen display, am I right?
Reading about it in the S*BASIC manual, there appears to have been a lot of trouble with FILL throughout its history..


Per
dont be happy. worry
- ?
User avatar
TMD2003
Trump Card
Posts: 168
Joined: Sat Oct 10, 2020 12:18 pm

Re: Dr. Jim's QL Dumping Ground

Post by TMD2003 »

It seems that what I post here is getting some attention from those who would like to examine it, pull it apart, and see what improvements can be made. Such is the way with a more technical forum than anything likely to be found in Spectrumville. So, for your delectation, delight and hopefully not disgust, I present:

Image

Get it here: ALL YOUR BASE ARE BELONG TO US

This was all sparked by my recent efforts trying to get a ZX80 to do something - anything, even - with machine code. It started with a Hex Bin Converter, a 16K ZX81 BASIC listing that would convert between decimal, hex and binary with a two-byte limit, and do so with string and array manipulation. As I'd been looking into the Z80's bit manipulation instructions, I then wrote a really simple routine on the Spectrum to poke a value from 0 to 255 into a specific address, pick it apart bit by bit and shove those bits into other addresses where they needed to be and perform a few additions here and there, leaving two addresses which can be fed into CHR$ when PEEKed to reveal the hex equivalent, and eight further addresses all containing either 0 or 1 that can also be PEEKed without the intervention of CHR$ to reveal the binary. This was then converted to the ZX81, and simplified as there's no need to account for the letters being held in a different block of the character set from the numbers - they follow on immediately afterwards. And as the only functions needed to read the data from BASIC are CHR$ and PEEK (as well as USR to make the machine code work in the first place), that meant I could convert it for the ZX80 and achieve my goal. Here's the evidence.

The advantage that the QL brings to the table, and once which I've used before, is is wide MODE 4 screen which can hold 85 characters. Could I make a QL version of Hex Bin Converter that would extend the range of values as far as 18,446,744,073,709,551,615? Who is ever going to need to count to 18 quintillion anyway? Why not just use WolframAlpha? As with all my QL programs, it's more of an exercise to see if I can do it. And, as you can see, I can. Numbers as huge as those this program can handle are best contained either in strings, or in arrays where each element houses one digit each. As this program was put together bit by bit - I'd get the decimal conversion working first, and then adapt it to the other bases later - I've used a bit of both each time. It's easier to use arrays to handle the conversion between bases, and strings to handle the display format.

And talking of the display format, there are more windows in this program than in a concrete tower block in the grimmest parts of any city in the former Soviet Union. #0, #1 and #2 are all redefined to TV-mode size (but retained in MODE 4), #3 displays the decimal output, #8 handles octal, #4-#7 are used for the "D/H/B/O" menu, and the hex and binary outputs get eight windows each - #11-18 and #21-28 - for a total of 25 windows defined, although window #2 is never used, it's just there to maintain compatibility if the program needs to be stopped and LISTed. So 24 windows will see action along the course of this program.

I make no guarantees that the code is perfect - it may look like a bit of a mess, but I've tried to keep all the procedures in one place, so the 1000s are the printing procedures, the 2000s-5000s are the conversions (2000 = decimal, 3000 = hex, 4000 = binary, 5000 = octal), the 6000s are any shared conversion sub-procedures, the 7000s ask which base is required, the 8000s ask for the value, and the 9000s are setting up the arrays and screen. With any error-trapping procedures, I've tried to make sure they're watertight, but the decimal input was so tricky (seeing as it's checking for a value that's higher than the QL can store accurately and isn't just a string of repeating digits) that this is the one most likely to be less than perfect.

Anyway, have fun with this - what's the longest word you can make using only hex digits, and what's its value in decimal?


Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: Dr. Jim's QL Dumping Ground

Post by EmmBee »

Hi,

Get it here: ALL YOUR BASE ARE BELONG TO US

Many thanks for your Super QL Hex Bin Converter. Your programs are always welcome.
I tried your program. Entering Decimal 16 gives Hex "G" which is outside the hexadecimal range. Octal and Binary also go wrong.

The next stage would be to try to find out where in the program the problem lies. I put this code through my tracker, but all it was able to do was list out the routines traversed. So, I added the parameters d$ and h$ to the routines convert_dec, dec_inquiry, print_dec and print_hex. The reason is that my tracker can print out the values of these parameters. See the attached report file in the zip, I'll also list it here ...

Code: Select all

#   110 main_screen_turn_on 
#  9390 main_screen_turn_on  ENDDEF
#   120 fixed_arrays 
#  9990 fixed_arrays  ENDDEF
#   140 calc_arrays 
#  9795 calc_arrays  ENDDEF
#   150 base_inquiry 
#  7150   ping 
#  9690   ping  ENDDEF
#  7295 base_inquiry  ENDDEF
#   170 convert_dec "18,446,744,073,709,551,615", ""
#  2020   dec_inquiry "18,446,744,073,709,551,615"
#  8050     dec_input_ok()
#  8150     dec_input_ok() RETurn 1
#  8090   dec_inquiry "16" ENDDEF
#  2030   print_dec "16"
#  1815   print_dec "16" ENDDEF
#  2220   print_hex "000000000000000G"
#  1090   print_hex "000000000000000G" ENDDEF
#  2230   hex_to_bin 
#  6590   hex_to_bin  ENDDEF
#  2240   print_bin 
#  1190   print_bin  ENDDEF
#  2250   bin_to_oct 
#  6190   bin_to_oct  ENDDEF
#  2260   print_oct 
#  1290     get_oct 
#  1490     get_oct  ENDDEF
#  1340   print_oct  ENDDEF
#  2270   ping 
#  9690   ping  ENDDEF
#  2290 convert_dec "16", "000000000000000G" ENDDEF
#   140 calc_arrays 
#  9795 calc_arrays  ENDDEF
#   150 base_inquiry 
# At line 7130 Ctrl Space pressed
My guess is the bug lies somewhere in convert_dec. I notice there is a routine get_dec, which is not linked in. Also at line 7280 should be CLOSE #n.
Hope that helps.

EmmBee
ayb.zip
(6.95 KiB) Downloaded 84 times


User avatar
TMD2003
Trump Card
Posts: 168
Joined: Sat Oct 10, 2020 12:18 pm

Re: Dr. Jim's QL Dumping Ground

Post by TMD2003 »

I did see a "G" in the hex once, but only when the procedure to test if the decimal value was too high was all wrong - it accepted a value of 20x10^18, and one of the hex bytes was "CG". But I'd never thought to test it with such a tiny value...

Originally, I had the program convert decimal to binary first, then convert the binary to hex and octal - but it took over three minutes at regular BBQL speed. Once I'd finished the next phase, which was hex conversion, the method I'd used to convert hex to decimal was a lot faster so I thought it'd be best to rework the decimal conversion routine to make the hex first, convert that to binary, then binary to hex.

I think get_dec was only required when the decimal input was being converted to binary first. As for that CLOSE # error... that'd explain why I sometimes saw windows hanging around on screen when they shouldn't be. That was just a typo that I didn't notice.

I've tried a few small values - 16 produces 0G (urgh!), but 32 and 48 are fine (20 and 30, as I'd expect, and then... 256 produces G0 (gah!), 4096 is G00 and so on. As the binary and octal are derived from the hex value, that's what screws them up. I did derive it from what I'd already written for the hex-to-decimal conversion and it seemed to work OK, and at least when I'm converting the other way, 10h is converted to 16, 100h to 256, and so on.

I'll have to take another look at this, because I'm not going to let this one lie. It'll keep me awake at night. It's like that episode of Futurama when Bender had a nightmare - he was dreaming about his vision filling up with 0s and 1s... "and I thought I saw a 2!"


Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: Dr. Jim's QL Dumping Ground

Post by stevepoole »

Hi TMD,

You said :
<<I think get_dec was only required when the decimal input was being converted to binary first....I'll have to take another look at this, because I'm not going to let this one lie. It'll keep me awake at night.>>

How did you get on with your revisons ? I have been writing some decimal to binary (and back) routines for 32 bit operations, and tested them OK. But 64 bit ones would require some clever arithmetic to operate. How did you manage this on a 31 bit QL system ?


Steve.
_____________


User avatar
TMD2003
Trump Card
Posts: 168
Joined: Sat Oct 10, 2020 12:18 pm

Re: Dr. Jim's QL Dumping Ground

Post by TMD2003 »

No revisions have happened yet - there was a very sudden need to get on with the decorating in the lounge that was just as suddenly removed, but I ploughed on through it and after seven days of scraping (plus one day at the seaside during that mini-heatwave)... I now have a lounge that has no paint on the walls and a lot of very scarred and haphazardly repaired plaster. I intend to get the job done by the end of September... though there's going to have to be another break for winemaking as the lounge is the only place that will house the four large buckets I need for the first week. In that time, I'll investigate what went wrong with the hex converter. And, likely as not, paint the doors.

My original direct decimal-to-binary converter used much the same principle as decimal-to-hex, except that it started with long binary strings, each one representing a power of 10 in 64-bit binary, and converted those to integer arrays containing 0 or 1 in each element. That array was then repeatedly added and the digits carried in the final result - but as it involved 64 digits instead of 16, it took rather longer to process than the final version. However, because hex results from binary rather than from decimal, there's no chance whatsoever of a marauding G appearing in the hex.

hbc8_bas is an early working version of the complete converter before I changed it to the decimal-to-hex version. Run this on an original QL, try the value 9,999,999,999,999,999,999 and see how long it takes (this is the value with the longest conversion time). It'll still be instant on SMSQ/E, so no cheating with that!

EDIT: crikey, I've reached "Over Heated PSU" status. I'd better sit in the fridge for a while.
Attachments
hbc8_bas.zip
(5.96 KiB) Downloaded 78 times


Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: Dr. Jim's QL Dumping Ground

Post by stevepoole »

Hi TMD,

I just tried hbc8_bas and on my QPC2 setup and get correct results so far ! ( No dec 16 = G.....).
My tests are for 31 bit values, using the toolkit BIN$() function for verification. However for 64 bit string$, no testing done yet.

I am using a 64 bit PC, but a 32 bit machine should be OK too, since you are using bit-shifting to access double_long values.... Very neat !

Excellent work if the double_longs are all correct too. Will try some more tests and report back if necessary.

Steve.
_______________


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: Dr. Jim's QL Dumping Ground

Post by stevepoole »

Hi TMD,

Testing is going on fine for 31 bit values.....

Of course QL 32 bit numbers are negatives, which users of your program must bear in mind if they use it.

Congratulations again on your tantalising program, which reminds us that QL maths cannot use 63 bit numbers (yet?).

However my PC does handle 64 bit numbers natively using C++ or JavaScript etc, but they are harder to write than on a QL system.

If anyone wants QL 31 bit random numbers, I can supply a fully tested program to produce them....

Steve.
________________


User avatar
TMD2003
Trump Card
Posts: 168
Joined: Sat Oct 10, 2020 12:18 pm

Re: Dr. Jim's QL Dumping Ground

Post by TMD2003 »

Your best bet to test 33-64 bit values is to put them into WolframAlpha. That's how I got hold of the binary and hex equivalents of the powers of 10, and also what I used to check the "test" value was working properly. I don't see any reason why the over-32-bit values would translate badly, because they're using exactly the same routine, just with not quite so many zeroes on the front of the binary.

I've got decorating and CSSCGC stuff to attend to - as well as a much-needed HD backup that's nearly done that meant me moving over to Linux for an entire day - but I will get that "G" problem fixed. Somehow...


Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
Post Reply