Dr. Jim's BASIC dumping ground

Show us what you're working on, (preferably with screenshots).
User avatar
TMD2003
Manic Miner
Posts: 274
Joined: Fri Apr 10, 2020 9:23 am
Location: Airstrip One
Contact:

Dr. Jim's BASIC dumping ground

Post by TMD2003 »

I figured that now I'm here, I may as well showcase (again, in some cases) what I've been up to when I've dug back into Spectrum programming and stuck with it long enough to see a project through to the end. What I'll put here is anything that won't be submitted to CSSCGC or the like - non-game programs I wrote, many of which will be something to do with maths, UDGs/character sets and PLAY commands, because I find that easy to program without getting well and truly stuck (like Sticky the stick insect on a sticky bun). Maybe it'll all get drowned here in a sea of machine code, and what I know about that can be written on a pinhead. Then again, magazine covertapes contained plenty along the lines of what I've done here, and I wouldn't mind betting I could have sent some of this to 16/48, Outlet or similar, had I been there at the time.

Anyway, I'll start with today's effort...

============================================================================

Image

Dr. Jim's Mighty Musical Character Sets

I'd been thinking of making another Crap Game - even though I have two in the pipeline that have been submitted for publication but haven't been revealed yet. Anyway, I was thinking of something musically-themed, and realised I would need some graphics for it. They've come out rather larger than I imagined - the treble clef is 3 x 8 character squares - so even though the two character sets together take up only 1.5K, the screen size will make the game somewhat limited (thus making it premium CSSCGC material).

There's a TZX in this package of the two character sets held separately as 768 byte files called "C1" and "C2", and another TZX of the two combined as one 1.5K file... with a 26.5K demonstration program that is a long, long, long listing of PRINT AT (...AT, AT, AT, AT, AT and AT again...) statements, with a sniff of PLOT and DRAW. Any BEEPs to accompany the notes will be minimal until the very end.

Provided amongst the graphics are:
- G, F and C clefs, which can be positioned at any line on the stave - everything is designed to fit around the stave being drawn as a series of symbol-shift-0 underlines.
- Crotchet and minim note heads, for notes on lines and in spaces, with instructions on how to convert PRINT AT coordinates into PLOT positions to draw the stems.
- Semibreves, for line and space (and it's not the same as a minim head) - note that the "modern" breve and longa can be derived from this with a few DRAW lines, but you'll have to figure those out yourself.
- Archaic long notes (breve, longa, maxima) for line and space, in the rectangular style, with PLOT positions for the longa and maxima stems.
- A dot! It always fits in the space. It could also be used for staccato, but will be slightly off-centre.
- Quaver crooks in all orientations, with extra fill-in characters that stack perfectly to make quaver fractions.
- Rests, everything from maxima to demisemiquaver - and again, the fractional quaver rests have stacking characters.
- Accidentials - sharp, flat, natural, double-sharp, for line and space.
- Time signatures - digits available are 1-9 and 12, and common time C. A quick PLOT and DRAW will turn the C into the alla breve symbol, but you'll have to work that one out yourself.

I could have gone on, adding more and more graphics into more and more character sets, but I figured this is enough for now. Character set "C3" would probably involve dynamic marks (if it's possible to define a single f, p and m and print them alongside each other to form ff, pp, mf etc.), segno, coda, fermata, trill, mordant, accent, a proper staccato dot... there's loads left. And if it ran to a "C4" character set, that might have weird things such as half-flat, half-sharp, sharp-and-a-half, that only really odd people who think they have more finely tuned ears than the rest of us plebs will ever deal with.
6 x
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!

User avatar
R-Tape
Site Admin
Posts: 3537
Joined: Thu Nov 09, 2017 11:46 am

Re: Dr. Jim's BASIC dumping ground

Post by R-Tape »

I'm one of the least musically minded people out there, but even I know that's a beautiful treble clef.

Please keep dumping—PM sent.
0 x

User avatar
Ast A. Moore
Dynamite Dan
Posts: 1789
Joined: Mon Nov 13, 2017 3:16 pm

Re: Dr. Jim's BASIC dumping ground

Post by Ast A. Moore »

R-Tape wrote:
Sat Apr 18, 2020 10:13 pm
I'm one of the least musically minded people out there, but even I know that's a beautiful treble clef.
Indeed. However, the bass clef looks a little undersized compared to it.
0 x
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.

User avatar
R-Tape
Site Admin
Posts: 3537
Joined: Thu Nov 09, 2017 11:46 am

Re: Dr. Jim's BASIC dumping ground

Post by R-Tape »

Ast A. Moore wrote:
Sat Apr 18, 2020 10:19 pm
Indeed. However, the bass clef looks a little undersized compared to it.
R-Tape wrote:
Sat Apr 18, 2020 10:13 pm
I'm one of the least musically minded people out there, but even I know that's a beautiful treble clef.
Haannnng on. I mean quavers. I think. Beautiful quavers there :?
0 x

User avatar
Ast A. Moore
Dynamite Dan
Posts: 1789
Joined: Mon Nov 13, 2017 3:16 pm

Re: Dr. Jim's BASIC dumping ground

Post by Ast A. Moore »

R-Tape wrote:
Sat Apr 18, 2020 10:27 pm
I mean quavers. I think. Beautiful quavers there :?
Damn amateurs and classical musicians and their fondness for calling eighth notes “quavers”! :evil: Can’t bloody tell a clef from a note . . .

:lol:

Yeah, I was confused whether you were joking or not, so I downloaded the demo, launched it and sure enough, the first thing I saw was this:

Image
1 x
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.

User avatar
TMD2003
Manic Miner
Posts: 274
Joined: Fri Apr 10, 2020 9:23 am
Location: Airstrip One
Contact:

Re: Dr. Jim's BASIC dumping ground

Post by TMD2003 »

To clear up any concerns:

What I did here was, I took screenshots of musical scores from Wikipedia initially - that's where the clefs came from - then found that a lot of their diagrams were hosted in tiny PNG files where the stave was smaller than it had to be on the Spectrum screen - i.e. that the distance between the lines was less than seven pixels. Ideally I needed the symbols to be as large as possible, so I opened MuseScore (which I'd recently downloaded as a more recent freeware equivalent of Noteworthy Composer, to check out some MIDI files) and played around with the various notes, rests and symbols available, with the zoom set at 800%. Print Screen, paste to GIMP, brightness down, contrast up, scale so that there would be seven pixels between the lines, drop to two colours, paste into an XCF file with a transparent 8x8 grid on one layer... and then start typing in the binary codes. Lots and lots of binary codes. A near-continuous soundtrack provided by Clutch and Iron Maiden may have helped here.

One thing is certain: everything is the correct scale relative to everything else, so if the bass clef looks small, look at it again with the stave superimposed, and then loot at a real musical score. It's absolutely bang on. The only tiny compromise I made was to shift the crotchet rest up one pixel so that it would fit into six squares; also, the 12 and 1 in the time signatures aren't exactly centred, but it allowed the 12 to fit into six squares and the leftmost squares to be re-used to make the 1. Then, the top right character of the 1 could be re-used to form 40% of the breve rest. It's unlikely anyone would ever notice these one-pixel shifts had I not pointed them out.

This post has generated rather more interest than I'd thought. Maybe I should get on with that Crap Game before someone steals my thunder! Though I've got those last few Sinclair User listings to type in, I can't let that drop now.
0 x
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!

User avatar
TMD2003
Manic Miner
Posts: 274
Joined: Fri Apr 10, 2020 9:23 am
Location: Airstrip One
Contact:

Re: Dr. Jim's BASIC dumping ground

Post by TMD2003 »

R-Tape wrote:
Sat Apr 18, 2020 10:13 pm
Please keep dumping.
Time for Dump Number Two (ooer, sounds a bit rude!): something I made in my last Spectrum-programming-frenzy that didn't last quite as long as I'd intended, but still made this. Presented as it was then... mostly.

INITIAL IMPORTANT NOTE BEFORE ANYONE ASKS ME: Although these were written on Spectaculator and just about everyone will only ever test them for two minutes on an emulator, they were written to be as easy as possible to use on a real Spectrum - right down to the original rubber-keys model which needed SYMBOL SHIFT for the decimal point and the simple mathematical functions. So I made the keypresses shift-free, i.e.:
To multiply 2.4 by 0.3 you'd need to press: 2, M, 4, ENTER (to put 2.4 on the stack), M, 3, B.

Were I to make a third "Spectrum Brain RPN calculator" I'd check for all the shifted keypresses (with either shift key), and probably run it though a compiler to see if that could make it any less slow. But I've got plenty more to be getting on with for now!

-------------------------------------------------------------------------
MARCH 2017...

I set myself a small challenge. Back in the mid-90s when I was still at school, my physics teacher, who was something of an Apple devotee (it was probably his decision that the school used Mac Plus, Classic and LC II models) as well as Hewlett-Packard RPN scientific calculators. He showed us how RPN worked and how it was different to the Casio and Sharp models we all had, and he showed us an RPN calculator program he'd written on an Apple IIe.

I could have done the same in my first enthusiastic stint here alongside the CCSCGC programs, but for whatever reason, it took until 2017 for me to get the idea that if my physics teacher of 20 years ago could write an RPN calculator program, why couldn't I? Why had I never tried to do it before?

So I did.

Image

Download link: http://www.rickdangerous.co.uk/hammer/ms/zx/rpn.zip (contains all versions on this thread)

I'd already written a screen-drawing routine for a "ZX81 Brain" version when I realised, it was a bit ambitious to make a calculator with all the scientific functions I could fit on it, until I'd tested the routines I'd need to set up on a simpler four-function version which I've called the "ZX80 Brain". (Such names were the bottom two skill levels of Starfire, the early, mostly BASIC-based release from Virgin Games that Codemasters would have called "Super Star Trek Simulator" - which is obvious when the game draws the ship's top and side views.) And I'm quite pleased that I've made some routines work in BASIC that I could never have come up with when I was a nipper:

- Loaded in the ZX80 character set (which I'd saved ages ago and I have a program to make defining character sets really easy).
- The number keys are all centralised into 2x2 squares by PRINTing them where I've put the stack with INK and PAPER the same, then reading the 6x7 areas with the POINT function and PLOTting them in the right place. If they'd only had to be centralised between two rows I could have used POKE 23606 to shift them vertically, but I needed to do it horizontally as well.
- Shown a "keypress on the screen" by temporarily turning on the BRIGHT channel for that 2x2 square and turning it off again when the process was done, with a POKE of the display file where the attributes are held. It may seem excessive to define an array - DIM z(90) - with 90 values, most of which are unused, but I'd read the keypress with LET i=CODE INKEY$, then z(i) would hold the address that needed to be POKEd (up or down by 64) for the top-left of the 2x2 square that I'd defined for that key on screen. It's four POKEs in total (value, +1, +32, +33).

I am not an advanced programmer by any means, I know next to nothing about machine code. But seeing as this is my level, shown here, imagine my delight when I managed to get those last two routines above to work without consulting anyone who would be able to do it in five seconds. That's the crucial point. (NOTE: the BRIGHT channel POKE is something I'd use a lot more regularly these days, now that I know how it's done.)

Other things I managed to check for, given that the number at the bottom of the stack has to be held in a string and that makes it harder, is:

- only keys shown on screen will actually do anything
- you're not trying to divide by zero
- the stack won't fill beyond 17 values or empty beyond a zero stored at the bottom
- the decimal point can't be entered twice
- there's no exponential key (in this version) but it checks to see if there is one anyway, for calculated values that are beyond 99,999,999
- leading zeroes aren't entered

It's slow, I know that - because I've written it in +3 BASIC which goes mad if I try to use redefined character sets on the BASIC editor, I've had to POKE 23607,249 every time I want to PRINT something on the stack, and POKE 23607,60 at the end of the subroutine every time. Hence I thought the "ZX80 Brain" was an appropriate name. For the "ZX81 Brain" version I could use the standard character set, but I thought I'd make it a bit like the early Sinclair RPN calculators and redefine 0-9, E and + to make it look like a seven-segment LED display in the stack, so I'll have to keep those POKEs in.

I know what you're all thinking: "...but the ZX80 couldn't handle decimals!" Well... like a "ZX80-and-a-half", if you like, it can handle decimals, but doesn't always get it right when checking that there is one. I've set two variables as flags - d and e, set to either 0 or 1. d=1 if there's a decimal point in the value at the bottom of the stack, e=1 if there's an E+ value in there; if one appears as the result of a calculation, d and e are both automatically set to 1. I've set d to 1 if the M key (for .) is pressed, and both d and e back to 0 once the ENTER key is pressed and that number is moved up the stack. I've used the variable o to hold the result of a calculation before the stack is moved, and I've checked:
IF o=INT o THEN LET d=0
IF o<>INT o THEN LET d=1 (both lines are in just to make sure)
IF o>=1e8 THEN LET d=1: LET e=1 (because such a number will be held in scientific notation, and even if it's one digit with no decimal point such as 1E+8, the decimal point key needs to be disabled anyway until this number is put into the stack).

Whatever I do, I find the decimal point flag gets stuck on and it beeps at me as if there's a decimal point there, even when there isn't. Sometimes it's because the display is holding a non-integer value but it can't display the decimal point because there are too many digits, other times it's a mystery.

And just to make it look like I'm doing a thorough job, the ZIP package contains the program in tape, +3 disc and microdrive formats, all with the LOAD command for the character set modified appropriately!

-------------------------------------------------------------------------
LATER IN MARCH 2017...

Hey! Great news! I've upgraded the "ZX80 Brain" calculator to the new "ZX81 Brain" version, complete with scientific functions - at least, as many as I could jam onto the screen and make work.

Image

Download link: http://www.rickdangerous.co.uk/hammer/ms/zx/rpn.zip (contains all versions on this thread)

Updated package includes:
- Tape (.TZX), microdrive (.MDR), +3 disc (.DSK) formats;
- Each of these contains the program, separate screenshot and redefined character set for the ZX80 Brain and ZX81 Brain versions of the calculator;
- ZX Printer listings for both the ZX80 Brain and ZX81 Brain calculators, taken from the tape format - in Spectrum graphics as a .PNG image and outputted to text as a .TXT file;
- Documentation, mostly adapted from the wordy waffle in these two posts.

The screen for the "ZX81 Brain" calculator was designed first, with 30 keys in a 6 × 5 array - the space for the top two rows in the "ZX80 Brain" version was instead filled with the ZX80 logo. I hadn't decided what extra scientific functions should be added on the top two rows when I switched to the "ZX80 Brain" version, so it gave me time to work out the best permutation of such functions.

For the "ZX81 Brain" version I could have used the standard character set, but I thought I'd make it a bit more like the early Sinclair calculators and redefine 0-9, E, + and - to make it look like a seven-segment LED display in the stack. This has meant I have had to keep all the constant swapping between the redefined character set (POKE 23607,249) and the standard character set (POKE 23607,60) to ensure the screen doesn't fill with junk in 128/+3 BASIC. (It's annoying, because I'd have liked to see the listing for the "ZX80 Brain" calculator in the authentic ZX80 font!)

The extra features the "ZX81 Brain" calculator adds over the "ZX80 Brain" are:

- a fifth "regular" function, the power key;
- the plus/minus key and the ABS function to convert any value to always positive (which was really a result of me having one key spare and not wanting to waste it...);
= a routine will disable trying to negate zero; ABS has no effect on zero
- trigonometric functions SIN, COS, TAN;
= the routine can check for values where TAN has an asymptote, but though it is correctly coded it won't always work (see "known problems" below)
- logarithmic functions, ln and log10;
= a routine disables taking logarithms of zero or negative numbers
- pi key
- reciprocal key;
= a routine will disable taking the reciprocal of zero
- square root key;
= a routine will disable square roots of negative numbers
= this is intended as a short cut, other roots are available by calculating powers of reciprocals e.g. cube root of x = x^(1/3)
- an exponential key allows values up to 10^38 to be entered (beyond which the program will stop with "6 Number too big" - see "known problems" below);
- an inverse function key, which inverts five functions and extends the exponent
= press it and the BRIGHT channel stays on until the next key press
= logarithm functions are inverted; ln becomes e^x, log10 becomes 10^x
= trigonometric functions are inverted; SIN, COS, TAN become ASN, ACS, ATN respectively
= a routine disables calculating ASN and ACS for values greater than +1 or less than -1
= using the INV key before the EXP key produces "E-" on the current entry instead of "E+" and allows entry of reciprocal scientific notation
= the key is always reset after the second key press; it will have no effect on any keys other than these six
- a redesigned screen to reflect the black, red and white of the ZX81;
- the aforementioned seven-segment character set, in bright red to look like glowing LEDs.

In a horrible twist of irony, the extra features added to the "ZX81 Brain" calculator - which mean many more key presses to check for in each program cycle - have slowed it down to the point where it really struggles with a full stack, particularly when executing a single-value function - there are more of these and five have inverses, which means there are a lot of lines of code to execute every time one is used! So the "ZX80 Brain" calculator is faster for the basics, the "ZX81 Brain" calculator can do more. (Of course, you could just use the Spectrum's functions in BASIC, I've just made them look flash with all my screen POKEs!)

Features I haven't managed to get on this calculator (and would never have been likely to anyway) are:
- non-decimal number bases (binary and hexadecimal at least) and the ability to convert between them;
- complex numbers;
- logical operators NOT, AND, OR and XOR;
- angle measurements other than radians (degrees, mils, grads... whatever they are!);
- degree-minute-second notation;
- fractions;
- hyperbolic functions (though these can be calculated with exponential identities);
- derived trigonometric functions (SEC, CSC, COT - though these can also be calculated with reciprocals of COS, SIN and TAN respectively, and has anyone ever seen these on a scientific calculator, let alone an 8-bit micro?)
- average and standard deviation calculated from all the values entered into the stack.

Known problems:
- doesn't always recognise when a number no longer has a decimal point, usually because there is a very small decimal in the string that the number display can't handle when it tries to print VAL of the string.
- no exponent key, but the calculator can handle numbers from 10^8 to (somewhere between 10^38 and 10^39) as the result of a calculation. Any calculation that exceeds 10^38, or an attempt to press number keys that take the exponent above 10^38, will crash the program with "6 Number too big". (This also happens with exponents below -38.)
- exponent key added; so far there appears to be no easy way to prevent the exponent from exceeding 10^38 accidentally, or as the result of a calculation. (Believe me, I tried, and setting the correct flags, trying to read the exponent as a separate part of a string called f$ and a numerical value f (=VAL f$) at the same time without one or the other getting out of hand was huge, convoluted, slowed the program down even further, and never worked properly. Just be careful around large numbers, right?)
- PI is stored to 7 decimal places. Trig functions work OK except in certain cases where the value of the trig function should be 0 but the accuracy of the stored value of PI is not enough and the function returns the value 7.3145904E-10.
= e.g.: if X = PI*0.5, COS X should be 0 but returns 7.3145904E-10; the same result occurs with COS of-PI*0.5. Strangely, using PI/2 returns the correct value 0. Higher values of X where COS X should equal 0 - i.e. PI*1.5, PI*2.5, etc - are fine whether using PI*1.5 or 3*PI/2. TAN of -PI does the same and TAN of multiples of -PI returns the same multiple of the inaccurate value - i.e. X = 2*PI, TAN X = 2*(7.1345904E-10).
= annoyingly, this means the attempt to check for asymptotes in the TAN function fails for any value of X for which this program will return COS X = 7.1345904E-10; this is because it does not recognise the variable OT = ((s(1)+(PI/2))/PI as being an integer (because it's very slightly off, not even enough for the display to handle) and an attempt to evaluate TAN X returns a very large value that crashes the program with "6 Number too big". The routine does at least work in theory - divide PI by 2 (don't multiply by 0.5!), COS returns 0, TAN will beep for an error.

-------------------------------------------------------------------------

As I've been asked to do, when I'm done with these weekly dumps (and there might only be one more unless I get digging) I'll allow them for submission to ZXDB. Anyway, have fun with this little lot, if you weren't too traumatised by maths lessons at school all those years ago.
4 x
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!

User avatar
TMD2003
Manic Miner
Posts: 274
Joined: Fri Apr 10, 2020 9:23 am
Location: Airstrip One
Contact:

Re: Dr. Jim's BASIC dumping ground

Post by TMD2003 »

Dump Mark Two didn't get a hint of interest in two weeks and that makes me a saaaaaaaaaaad panda. So, I expect little more success with Dump Mark Three as it's more maths-related programming, though at least this is more up to date. T'other forum had gone walkabout last weekend, and I needed it to return to recover the post, which is here now for your confusion and dismay.

-------------------------------------------------------------------------------------------------
FROM 29 MARCH 2020:

In a break from typing in listings from 37-year-old magazines, I had a sudden urge to write a maths-related program, as I do, occasionally. Some, such as a cubic equation solver, remain unfinished as I still don't quite understand the methods behind it (but I'll probably have another go at some stage). And others, such as the RPN Calculators I made three years ago (SEE ABOVE), I've made public because I thought they were good enough to show off and the listing would probably have been snapped up by Sinclair Programs, had I been in my 30s or 40s in 1983 (I wasn't... I was a tenth of that) and had a huge stack of tapes, and a printer, and an enormous amount of that shiny paper to print out the listing until I could work out how and why it was going wrong, when at least these days I have an emulator with savestates to make the programming process a whole lot easier.

So this is what I did.

Image

Download the package here: http://www.rickdangerous.co.uk/hammer/ms/zx/hexfrac.zip
(and see also below...)

In short, I thought it was possible to make a program to convert fractional decimals into their hex equivalents - and include some test examples - pi, e, and the usual suspects. After one very false start after which I almost abandoned the whole idea, I went through with the process of "multiply by 16, take the value before the point as the next hex bit, replace that with a zero and continue". For the most part it works, and the input will take a string of 30 digits after the decimal point. Decimal expressions that terminate within those 30 digits will come out exact; irrational numbers and recurring decimals, because they are 30-digit approximations of the actual value, will not be so accurate. I found pi would calculate to 13 hex digits after the point; e, the golden ratio and the square root of 2 were all accurate to 24 digits. The final result will be printed in just under four minutes, so even on real hardware you can give your input, start the process, make a mug of tea and come back to find it's nearly done.

Not bad for a day's programming, that - and I now further wonder if it could be down-converted for a ZX81. Even once the colour information and the UDGs are removed (which requires the maximum number of digits to be cut to 29 at most), would 16K be enough memory to handle the same process? I suppose there's only one way to find out...

-------------------------------------------------------------------------------------------------
LATER, THAT SAME DAY: (I think I must have posted the Spectrum version just after midnight...)

It is doable, and I've done it, in the space of a morning:

Image

The graphical compromise that was the loss of colour has been compensated for by (a) using the ZX81's "shades of grey" graphics around the input and output values, and using inverse video to show the build-up of the hex bits instead of BRIGHT. The number of accessible digits after the decimal point is reduced to 29, and you'll know if your input is too long as the "L" cursor, with quotes intact, will spill onto a second line (and the BEEP-less error routine compensates for this). This is so that there's two character spaces for input integers from 10 to 15.

Otherwise, the program works as I'd expect, and the accuracy hasn't been reduced by much for the loss of that one decimal place - the golden ratio loses two digits of accuracy but pi, e and root 2 are unaffected (although the digits after this point are different).

The major difference is in the speed the program works. I've just tested the Spectrum version on a real +2B, and it reaches a result for a 30-digit input in three and a half minutes. The ZX81, handling 29 digits, will get there... in 17 minutes, at least on the EightyOne emulator running at normal speed. I don't have a real ZX81 to test it with, but if anyone does, feel free to convert the .P to .WAV and give it a shot.

It's lunchtime, so I've earned myself a corned beef sandwich - at least I would have if all my tins of corned beef weren't stashed away in a Corona-chan Doomsday Box, which I refuse to open unless absolutely necessary. So yesterday's freshly-baked bread - yes, I've been trying that myself - will have to be filled with something else. But I'll find something, that's for sure.

Also, anyone who wants to translate these two programs into machine code to see how they run that way, fire away. I'd be expecting the Spectrum to zip through the routine in no time at all.

I further wonder now, if it's possible to do anything similar on a (16K and probably emulated) ZX80 - losing the PRINT AT commands will be tough, losing floating-point arithmetic will be even worse, and the long multiplication routine as I've written it needs that facility.
0 x
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!

User avatar
TMD2003
Manic Miner
Posts: 274
Joined: Fri Apr 10, 2020 9:23 am
Location: Airstrip One
Contact:

Re: Dr. Jim's BASIC dumping ground

Post by TMD2003 »

I am rather less of a saaaaaaaaaaaaaad panda this time because I didn't have anything more to add to this thread after last time (that I thought worth it, anyway). And to break the silence, here's something I made... this evening. Well... here's something I modified this evening, at least, and that's why it didn't take long.

I've taken the hexadecimal fraction converter from the post above and adapted it for dozenal, to satisfy all those who demand that we should have evolved to have six fingers on each hand and thus count in base 12, or who want to go back to the good old days of pounds, shillings and pence.

Both the Spectrum and ZX81 versions of the hex fraction converter program have been adapted.

Spectrum version:
Image

ZX81 version:
Image

There are many representations for the extra digits ("dek" and "el") required for the values of 10 and 11 - A and B, X and E, T and E, chi and epsilon, or the upside-down 2 and 3 that look like a very mangled T and curly E (or epsilon). On the ZX81 it was far easier to keep them as A and B rather than try to fanny about with X and E(which was the original plan), seeing as A and B follow on directly from 9 in the ZX81 character set. As they don't on the Spectrum there had to be separate lines to represent any digits beyond 9 (which was also the case in the hex program), so I defined upside-down 2 and 3 UDGs to make them look like the Dozenal Society of Great Britain would want them to.

Also, the semicolon isn't a mistake, it's how the radix point is denoted in dozenal.

Download the package here: http://www.rickdangerous.co.uk/public_html/hammer/ms/zx/dozfrac.zip
1 x
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!

User avatar
TMD2003
Manic Miner
Posts: 274
Joined: Fri Apr 10, 2020 9:23 am
Location: Airstrip One
Contact:

Re: Dr. Jim's BASIC dumping ground

Post by TMD2003 »

Who's been a brainlet? Hands up here.

The link should be: http://www.rickdangerous.co.uk/hammer/ms/zx/dozfrac.zip

But you all worked that out already, right?

If these Hex/Doz fraction converters are worth including on ZXDB I'll probably combine them into one package (i.e. both programs on one tape, disc or microdrive) for the Spectrum version at least.
0 x
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