Spectrum Computing

This is a program I've had kicking around since at least 2002, and I've occasionally added to it since then (though not since 2006). It generates UK number plates, in white and yellow.

So I picked it up again (after watching a lot of HubNut videos, if you must know), and over the last couple of days I streamlined the BASIC - cleaning up variables, subroutines and the like that were a bit of a mess - and got that working with very few visual changes to what it was 14 years ago. Here's what it generates:
- 2001-present style plates up to the "20" series (i.e. AB20CDE)
- 1963-1983 suffix plates (i.e. ABC123A) and 1983-2001 prefix plates (i.e. A123ABC), including Q prefixes for kit cars
- Basic Northern Ireland plates with the most recent three letters, four numbers combination (e.g. ABZ1234, AIB1234)

The screenshot above is what I did today, making as good an approximation as I can get of the Charles Wright Narrow font that fits into two character squares. Letters are defined using capitals for the top half and lower case for the bottom half, numbers use their standard character for the top half and "CODE minus 176" (space to closed bracket) for the bottom half, most of which correspond to SYMBOL SHIFT plus the number.

There are a few "quirks and features", as Doug DeMuro would say, where I've done as much as I think I can to make the plates realistic:
- Plates up to a J suffix (31 July 1971) always appear as white on black.
- The Doovla specifies "undesirable" three-letter combinations that it will never issue (e.g. SEX, GOD, JEW and some odd ones like ABF) that I've held in a DATA statement - these are excluded, and so are the Manx three-letter combinations MAN and *MN.
- Likewise, "undesirable" two-letter combinations in 2001 plates (e.g. FU, NF) or others set aside for special use (e.g. GO, DR) as well as the J*, T*, U* and XG-XY combinations that were not assigned to regions have been excluded.
- Also excluded were the number combinations from prefix plates that were set aside for special use (i.e. 1-20, and all multiples of 10, 11, 100 and 111). Such numbers on suffix plates are fine, as the Doovla hadn't yet worked out there was money to be made that way.
- There are other oddities such as the abolition of X* as regional identifiers in the 1963-2001 plates after 1974 (and some had already been scrapped in 1964). I've taken this into account in a compromised way, in that *X* combinations can only occur on a black plate. Hence, you'll never see Richard's Rover SD3 from early episodes of Keeping Up Appearances (D541EXL, which is invalid), but you might see its replacement when the BBC realised their mistake (D541EFL) or the 1966 reverse version (EXL541D, which is valid and would appear white on black).
- Some regional identifiers were scrapped (e.g. *SY) or never used, but even though a table of these is available it's far too much hassle to implement it correctly so I haven't bothered. Plus it would slow down the program far too much more than it already is.
- Northern Ireland plates only show regional identifiers that have been used in Northern Ireland with the current system (three letters, four numbers) - so it's not just a random I or Z thrown into the second or third letter. For example: Belfast uses or has used *OI, *XI, *AZ, *CZ, *EZ, *FZ and *GZ as the second and third of the three letters; reverse combinations with a Z in the middle, for instance, were all used in the Republic of Ireland before the 1987 reform and are not included here. There's no way of knowing how far the current registrations have progressed, so I've allowed any combination from the current series (i.e. anything from AGZ1001, which is almost certain to have been issued, through to YGZ9998, which has not). The only recent combination I missed out was *YZ, used in County Londonderry (careful now) since January 2020, so there are barely any of them out there.

It's unlikely anyone will want to see this program in action, and besides I've got a bigger plan for it, so I'm not putting it on general release just yet, unless anyone wants to ask for a copy.

(Potentially) useful utility time!

This is a short(ish) program that I found I needed when trying to grab data from the display file and dump it elsewhere. For instance, for any given PRINT AT position, what are the eight addresses for the eight rows in the display file, and what address are the attributes held at?

I didn't have such a program, so I wrote it, with a lot of fiddling around with a spreadsheet. It also has PLOT positions thrown in for good measure.

Input PRINT AT coordinates (including the use of rows 22 and 23, i.e. the INPUT area) and the program returns the range of PLOT values in that square, the eight addresses for the display file, and the attribute address. PLOT coordinates will not be given for the INPUT area.

Input PLOT coordinates and the program returns the PRINT AT square the pixel is located in, the eight addresses for the display file, the attribute address, and a POKE for the display file that will insert a pixel at that position. Note that multiple pixels on the same row will require the values for the POKE to be added together - but you all know how the display file works, don't you?

Input a display file address and the program will first check to see if it is where pixels or attributes are stored. The program returns the PRINT AT coordinates, the PLOT range for that square, all eight display file addresses for that square, and - if the input is in the pixel range - the attribute address.





GET IT HERE, said Blackadder one day in a fit of desperation...

This looks excellent [mention]TMD2003[/mention]. Thank you for sharing.

See this thread for more details...

Here's the original C64/PET program - "Computer Haiku" by Commodore Educational Software, 1983

Once I'd discovered the original program was written in BASIC I thought I'd examine the listing and convert it for the Spectrum. Obviously, all the colours were going to be different and the layout was probably going to be different seeing as the Commie can handle 40 columns at a time.

Most of the original code was discarded as the Bread Bin has no PRINT AT or colour commands, and uses massive strings of system variables, POKEs and control characters instead - so the title screen, menu and instructions sections were all rewritten to make them look like the original, just in different colours. More system variables and control characters had to be worked round from line 1000 in the original (660 in this version), to make the haiku appear as it should. Generating it in the first place was more complicated on the Commie as - for reasons only known to the original programmer - the random number generator was set by the system timer. I thought it unnecessary to PEEK 23672 (the Spectrum's equivalent) and translate that - it's just using RANDOMIZE at the start of the program and then taking whatever comes from then onwards. The second line had to be generated first, so that the length of the line could be checked and junked if it was over 32 characters - one place the Commie had an advantage. I think my introduction and exit screens are far better than the original, though.

The original was full of error-checking routines which were unnecessary on the C64 but which would stop the program in its tracks if it was run on a PET that couldn't handle it. (There was probably a VIC-20 version as well, but with its horrifically limited text screen, everything would spill over onto two lines.) None of these were needed - all I had to do was condense the program after I found out it couldn't be loaded on a 16K Spectrum (see that as the equivalent of a PET in this case). This involved removing all the REM statements - which I've shown below just in case anyone wants to examine the structure of the program and make it easier - but it also meant wheeling out the old 1K ZX81 trick of using NOT PI, SGN PI, INT PI and a ton of VALs every time a numerical value appeared... and there were a lot of them. Still, that meant plenty of bytes were saved, and the program would run on the smallest Spectrum with ease. It now looks like a complete mess, but at least on a Spectrum the memory-saving tricks don't slow the process down anywhere near as noticeably as they did on a ZX81.



Download the program
Write computing-based haiku
You have much honour.

In the beginning (28th March 2020), there was the Spectrum Hexadecimal Fraction Converter. A day later (and definitely not a dollar shorter), it spawned a slightly cut-down (and a lot slower) ZX81 version.

Later, in August 2020, a Dozenal Fraction Converter for both machines joined the Hexadecimal counterparts.

And now... it's time to unleash the awesome thromping power of... THE QUANTUM LEAP.









I've combined both programs, and converted them for the QL. Look at the result, there, in all its majesty.

The reasons are obvious: the Spectrum's accuracy for conversion was limited by the number of digits after the radix point that could be kept on screen at any one time, if we want to see the computer show its working. The Spectrum could handle 30 digits, by cunning use of user-defined graphics for the numbers 10 to 15 (as well as those for "dek" and "el" in the dozenal system). The ZX81 had no such facility, so had to sacrifice one of those digits. The QL, in Mode 4, can display 85 digits across its screen. So there's only four colours available - but colour isn't important, this is all about accuracy. Knowing that there would need to be space for two digits in front of the radix point, this meant that it could accommodate 82 digits after the radix point - giving us a level of accuracy that still won't trouble WolframAlpha (where do you think I found all the values of the constants in two non-decimal number bases?) but will blow the Spectrum into the weeds.

The principle is exactly the same as before - take the string of numbers after the radix point, multiply the block by 16 or 12, the digit that appears before the radix point becomes the next digit in the final sequence, then this is subtracted to leave only the digits after the radix point, and the process repeats. As with the Spectrum and ZX81 versions, it's all shown on screen.

The other reason for converting this program to the QL was to get to grips with its far more convoluted user-defined graphics. The QL's character set has a whole load of foreign characters and symbols between CHR$ 128 and 190, all of which can be redefined if you know what you're doing, though the process is more similar to redefining an entire character set on the Spectrum, in that if one character is redefined, the rest disappear into oblivion. So even though I only needed two characters - for the dozenal "dek" and "el", I had to redefine the down-arrow, pi and phi symbols, and threw in an empty box for good measure. It look a long, hard, frustrating amount of battling with POKEs and PEEKs and channel pointers to understand it, and members of the QL Forum are trying to tell me I'm doing it the hard way, and these days with QL Toolkit II there's a CHAR_USE command which allows easy access to custom characters on multiple channels. Well, in the words of Frank Sinatra, I did it my way.

Or, rather, I did it David Nowotnik's way, because the routine I used is based heavily on the "Lunar Lander" program from his "QL Characteristics" article in the October/November 1985 issue of ZX Computing. By starting out with a routine that would print his UDGs in window #3, I eventually managed to get them to be defined to any channel from 0 to 8, and then start defining the block from a character other than CHR$ 128 (161 is an ideal start point, so that the characters are produced by CTRL+SHIFT+A, CTRL+SHIFT+B, and so on).

The QL is a faster computer than the Spectrum, but it has 82 digits to contend with rather than 30, so it isn't too surprising that it takes a chunky 13 minutes, 24 seconds to produce a full answer. Here's the comparison below with the real values, as well as how the QL measures up against its older Z80-based siblings.

And a bonus point - this program also showed me I had made a mistake in the value of pi in the Spectrum and ZX81 programs, so these have all been updated to version 1.1 and the accuracy of their calculations has been corrected accordingly! And, strangest of all - the ZX81 was MORE accurate than the Spectrum for both hexadecimal and dozenal calculations of pi!)

Download the NEW version 1.1 of the Hexadecimal Fraction Converters for the Spectrum & ZX81

Download the NEW version 1.1 of the Dozenal Fraction Converters for the Spectrum & ZX81

Download the all-singing*, all-dancing Hexadecimal & Dozenal Fraction Converter for the QL


* NOTE: may not be "all-singing", or if it is, it'll all be off-key due to the QL's horrific implementation of sound in SuperBASIC. Think of Edith in 'Allo! 'Allo! and you'll get the idea. But despite its sonic shortcomings, this package does come with information about QL emulators and loading instructions for the raw beginner, which I was until April this year.

There's an F.A. Cup simulation from ZX Computing in 1983, which I typed in back in the day. This is its original version, though I've spotted a bug in the listing, and whoever typed it in thought "aha, I've fixed a bug!" but actually introduced one instead. I'll get that corrected soon enough. I've also modified it quite heavily, improved the sounds, tidied up the colours, and added a 42-character print routine (the one I was trying to find the origin of the other day) so that the teams could have 18 characters in their name.

However, for this season, Hampton & Richmond Borough have come all the way through the qualifying rounds to reach the First Round proper. And with 26 characters in their name, they're going to need a bigger boat... I mean, screen.

lrun mdv1_dr_jim_writes_for_the_ql_again_bas



Of course, the QL comes to the rescue. There were a few slightly annoying roadblocks in converting this program to QL SuperBASIC, but I reckon it's all there. The QL isn't known for its colours in Mode 4 but I thought green for one season and red for the other would suffice - and I've included the teams from the 1982-83 season, i.e. when this program was first written, and 2020-21, where we are now. The fortunes of some of the teams have changed - not least Notts County, who were in the old Division One for the 1982-83 season, but aren't even involved in the 2020-21 First Round as some of their players tested positive for the Chinese-Bubonic-Plague-meets-Ebola-meets-Leprosy and they had to withdraw - but given that they should never have found themselves in the position they are now, in the National League, they really only have themselves (and their catastrophic mismanagement) to blame. (King's Lynn Town are in their place, which should make Martin Brundle and George Russell happy, at least.)

The same restriction applies to this QL version as in the original - that multiple replays always result in the teams being reversed from the original replay, i.e the home team in the original draw will always be the away team in all the replays. Then again, this was a type-in, not a commercial release. Other than that, I wonder if the QL has a different way of generating random numbers; even accounting for the built-in (and intended) bias towards home teams and the difference between the divisions, the first time I ran this simulation with the 2020-21 teams, Harrogate Town - newly-promoted into the Football League this season - beat Blackburn Rovers in the final. (The second run saw Chelsea win, which is more realistic, but still, anything's possible here).

And despite the QL's horrifically wobbly sound capability (in SuperBASIC at least - machine code may be able to do a lot better), I've made it beep out an off-key version of Back Home, which was resurrected int he mid-1990s as the theme tune from Frank Skinner & David Baddiel's Fantasy Football League. This is a Fantasy Football Cup, but let's not argue over small differences. All together now: "Saint aaaaaaaand Greavsie talk about the Endsleigh League, as if it's iiiiiiiiimportaaaaaant..."

Download the QL F.A. Cup - includes detailed loading instructions for QL noobs.

The BASIC Dumping Ground has been rather quiet recently, mainly because I've been experimenting with machine code... and two-timing the Spectrum with other machines. Actually, it's more like four-timing, or if you count everything I had to load up for a few rounds of multi-platform Ghostbusters recently, it was (I think) nine-timing. Anyway, enough of my electronic harem, let's make some noise...



MACHINE CODE BEEP SEQUENCER

This is a program I wrote in a few hours when [mention]R-Tape[/mention] started asking me for more BEEP sequenced programs than what I'd already done. I'd only sent the bassline for Deee-Lite's "Groove Is In The Heart" in a series of BASIC BEEP statements, to make it absolutely unambiguous what the pitch was to be and how long each note was to go on for (as well as putting a few PAUSE statements in there as well). Dave then sent me the assembler, so I could load it in Spin and check that the lengths and pitches were correct. This was, indirectly, how I found out about machine code BEEPing - plus I'd seen a routine somewhere that used CALL 949, so I thought... this must be how it's done. Load HL with the pitch, load DE with the duration, CALL 949... except, it's not that simple because DE is the number of cycles to be BEEPed, rather than a specific amount of time - write BEEP x,y in BASIC and the ROM routine to handle BEEP translates x and y into HL and DE values for each note.

So if I was going to make my own rudimentary machine code tunes, I'd need to write a program to work out all the HL and DE values I'd ever need. After analysing as many different HL values as I could by piping them into Audacity and measuring the length of the cycle, eventually I gave up trying to work out the exact frequency that a given HL value outputs, and opted for Jonathan Cauldwell's method in his "How to write Spectrum games" guide. Start with a pitch, work out HL from that, and then work out DE from the duration, and HL, and a duration-multiplier that acts as an effective control of tempo.

That's what this program does. It accepts an input of any note from A0 to C8 - the span of a full-size piano keyboard. It will show the note given, the BEEP pitch for BASIC, and the HL value that corresponds to that pitch, loaded from a Number Array: block. The rest of that Number Array: contains the values of DE for exactly one second, which correspond to the frequency of that note in Hz.

Input the note first - A to G, upper or lower case, with "#" or "b" for a sharp or flat. Input "O" to change the octave at this point instead of a note. Then input the duration in beats - the time in seconds will be shown on screen, but the number of beats will be stored in the array that holds the whole tune. The HL and DE values will appear on screen. Input "P" to play the sequence, then you can adjust the tempo, print the entire sequence, add some notes, or edit the sequence from a particular point.

I have probably made this program sound more complicated than it is - really, it's a very crude routine that could serve as some kind of introduction to machine code BEEP sequences for those who have never tried it before. It can't handle pauses so your input will have to be a constant stream of sound. So it's a very, very long way from BEEPola - but it might still be useful to someone, somewhere, at some stage.

I've tried to download your games, but most enhanced type-in files can not be downloaded. The links point to .../zx/(program).zip when the actual files are placed on .../zx/files/(program).zip.

Thanks.

zup wrote: ↑Wed Dec 23, 2020 6:44 am I've tried to download your games, but most enhanced type-in files can not be downloaded. The links point to .../zx/(program).zip when the actual files are placed on .../zx/files/(program).zip

Well spotted. As I don't have to download my own files, I'd probably never have noticed. Every link except Apple Thief was broken, and I also found a row of ****************** in the links for Hex Bin Converter, Pencil and Stunt Rider that needed filling in - they're not listed on ZXDB and I'd probably meant to put something like a link to the listing in.

The links are now all fixed. I'm going to have to test the whole site now to see if anything else has escaped my attention!

Time to wake up this thread! Seeing as I'm running an entirely different programming competition that I can't contribute to, I've been rather quiet on the programming front. I've got a few ideas in development, but this is the only one so far this year... and it was written in one evening. In short, I'd always wondered if I could translate Stephen Keevil's Lissajous Figures, from the July 1983 issue of Sinclair Programs, for the QL, using its more powerful graphics. So I did... well, sort of. In effect, after I'd defined custom windows, all the input and error-checking procedures, and adapting the one line that actually calculates the points that form the figures, there was just about nothing left of the original...

But anyway, here it is. Take the Spectribution page or the direct download, either will do. It'll run on an unregistered version of QemuLator at regular speed, though if I can ever adapt this to make it into an animated version with constantly changing phase angle, it'll probably need a 640K+ QL and probably a Gold Card as well.

I must wake the BASIC Dumping Ground once more to offer something that might, possibly, be of help to those who haven't yet worked out machine code. There were a few who were giving it a shot, such as [mention]Ingerson[/mention] who's new here and made a thread about it, and I've found another one from [mention]Freespirit[/mention] further down the Programming forum.

Presenting the generically-titled Text & Screen Tools:



This is what you can do with it - the demonstration program that comes with the machine code (all 178 bytes of it!) tries to explain it all briefly, but I can do a bit better when I have some text space to spare.

First, prime the machine code with the PRINT AT position of what you want to affect. POKE 60000,(row) and POKE 60001,(column) - a subroutine within the machine code will be CALLed to translate these two one-byte values into a two-byte value that is the first row of pixels for that position in the display file. It can be done in one line of BASIC (thanks to Dilwyn Jones, incidentally, in the days before he became "Mr QL"), but even though the machine code looks complicated (and contains a multiplication routine from "40 Best Machine Code Routines" by Hewson Consultants) it can be worked through and achieves the same result, only a lot faster.

Now, RANDOMIZE USR 60056 and that character square will be turned into bold text. What it does is it takes each row of pixels, shifts them one place to the right and ORs them with a copy of the original. Do this twice on the same square and you'll have an ultra-bold version that Ste L. Cork was very fond of using on his games (e.g. Sector-90, Colony, Wibstars).

Or, you could RANDOMIZE USR 60071 on the square instead, and the bottom four rows of pixels will be shifted left by one place, producing an italic text effect as used by BASin (at least, BASin For Beginners, which I still use because it does what I need it to do, even though I'm a long way from being a beginner in BASIC).

What I find useful when making screens for my Crap Games - and this is why I've done it now, because I'm preparing my assault on the 2022 CSSCGC already - is that BMP2SCR's algorithm outputs character squares that I find are the wrong way round when I try to edit the screens in ZX-Paintbrush. Each time I'll be drawing away with a dark ink colour on a light paper, and then suddenly a square will invert, and I have to manually swap the paper and ink to continue editing. So I'll use this program to hard-invert the offending squares before editing them. It can do the following, again after 60000 and 60001 have been POKEd with the desired PRINT AT position:
- Hard-invert the square - i.e. all eight rows of pixels will be CPLed to their inverse, and the INK and PAPER colour will be swapped in the attributes. RANDOMIZE USR 60002 to make this happen.
- You will also need to check that the inversion has happened by examining the screen with attributes turned off (i.e. completely turned to 56 which is black on white). RANDOMIZE USR 60140 to store the attributes at 62528 (i.e. 40000 above where they usually are), RANDOMIZE USR 60152 to turn the screen to black on white, and RANDOMIZE USR 60166 to get the attributes back again. All three are simple LDIR routines.

So if you're struggling with machine code, take a look at this. I've provided a fully-annotated .ASM file in the package, so that I can still understand how it works after several months away, and by changing the ORG value it can be reassembled to a different address - just remember to note where all the routines start.

Following on from the Lissajous Figures conversion on the previous page, here's something I promised to the QL forum: Spirograph.



There are two screenshots here forced into the black-box-QL aspect ratio.

It's another conversion from a Spectrum original - here's the original listing - it's short but managed to pack in a (rather messy) intro screen as well as its ability to draw the familiar Spirograph patterns. I've retained everything the original had, including the facility to overprint one pattern onto another (and I don't think I needed to set OVER 1 to do that, although I did), and load and save screens from/to microdrive. (SBYTES mdv1_filename_bin,131072,32768 is the equivalent of SAVE "filename" CODE 16384,6912 a.k.a. SAVE "filename" SCREEN$ for those who were curious.) What I've added to this version is the layout - a square main window #1, around which I'd fit everything else - so window #2 is the status display on the right (that's still a usable 27 characters across) and window #0 has been crammed into the bottom right - that's just the input area, as you'd expect.

I wonder whether the formula used to draw the patterns is correct - I've transferred it directly from the Spectrum original and can confirm that the same input of the three radii required will produce the same pattern on both Spectrum and QL. I remember, though, when I had a real Spirograph when I was a nipper, there was some combination of gearwheels with the pen right at the edge of the inner gear that would make narrow loops right the way across the drawing area. I haven't been able to replicate that with any combination of radii that I've tried, and I don't have a real Spirograph to test it with now (and, realistically, why would I?) And I was quite rubbish with Spirograph, really - I never had the coordination to keep the pen in place while keeping the inner gear meshed with the outer gear, so everything I tried to draw looked like the mess that it was always going to be.

Who here has kids in single figures? Show them this. They might even want a real Spirograph for about five minutes.

"Dr. Jim's BASIC dumping ground" is increasingly as badly-named as "The Hitchhiker's Guide To The Galaxy Trilogy", as I present yet another foray into machine code, but this time, it's a big one. Relatively speaking.

Hex Bin Converter is a listing from the March/April issue of Sinclair Programs that I've found very useful, enough to convert it for the Spectrum for ease of use, rather than keep whipping out EightyOne to load it. It uses string arrays and manipulation to forcibly convert any two-byte input in decimal, hex or binary to the other two. Most of what I'd need, though, is the conversion of decimal into hex or binary (the latter being the reverse of the Spectrum's BIN function), and I thought I'd tackle this with machine code.

So I wrote a simpler routine that takes a one-byte input, POKEs it into a single address (which is obviously held in binary), and then uses the BIT instructions to analyse the value bit by bit, and LD either a 0 or a 1 into eight further addresses, thus producing a binary equivalent of the decimal input that's easily readable from BASIC using PEEK. The decimal value is then further analysed, blanking half of it off with AND 240 (followed by four RRCAs) or AND 15, to split it into two values from 0-15, which are then converted to the character codes of 0-9 or A-F.

This took 114 bytes, which was long because all those BIT instructions are two bytes each, all needing that CB "shift", and they can't be looped.

So I made a "Mark II" version, where the BITs were replaced by a couple of nested loops in which the bit analysis is done with AND 128, AND 64, AND 32 etc. - and that can be looped, because the ever-halving value can be held in a register and RRed. This cut the routine down to 69 bytes.

The next step was to transfer the "Mark II" routine to the ZX81, which resulted in a further reduction to 57 bytes as there was no longer any need for a subroutine that checks whether the values in the hex conversion are 0-9 or A-F. Whatever the value, add 28 to it and that's the hex digit equivalent of 0-15, as the letters - capitals only on a ZX81! - follow immediately after the numbers. Weren't the ROM programmers thoughtful, not using ASCII?

And then came the big challenge. With a bit of assistance from [mention]1024MAK[/mention] and other users of Sinclair ZX World (where most of you aren't looking), I've managed to bash the ZX80 into some sort of suitability for machine code. For those of you who the old yoghurt pot completely passed by, it's not usually possible to hold machine code in a REM statement on the ZX80 as any character code from 64 to 127 is unprintable and will either corrupt the display or crash the computer - and that's where most of the useful LD instructions are. Toni Baker's method of using the ZX80's variables area to store machine code is, by the looks of things, the best way: for a program of length X bytes, put DIM Q(X/2) as your opening line to make sure this is the first variable in the area. Then, you have to run the machine code starting at "two more than VARS" - which will change according to the length of the program.

Mark's example of how it's done on SZXW has twice the number of BASIC lines that it needs. Rather than a series of POKEs, I installed the machine code with LETs, having first worked out what the combination of two consecutive bytes U and V would be. (In this program, U = 30 and V = 255 for LD E,255; U+256*V = 65310, and as this is greater than 32767 we require a negative number, in this case 65310-65536 = -226.)

With the code installed, the entire program was deleted, except for the initial REM statement, which holds the hex and binary output from the routine. And that's fine, because all that's ever going to be contained in it are the characters 0-9, A-F, CHR$ 0 (space) or CHR$ 1 (quotation mark).

Then the demonstration program was entered, and the result was a little over 400 bytes, including the machine code stored in the invisible array, for a program that's (sort of) user friendly. I could probably expand it to a two-byte version, but seeing as that involves calculating the low and high byte values in BASIC first so that they can be POKEd (in the absence of the QL's two-byte POKE_W), you may as well just work out the low and high bytes, and run the machine code twice with each byte.

Looking at the ZX81 listing and the way it uses string slicing to achieve its goals, it looks like it would be extremely difficult - maybe impossible - to make a decimal to hex and binary converter in ZX80 BASIC. It would certainly need a serious memory expansion But, as you can see here, it is possible (a) to do so in machine code, (b) to do so on an unexpanded 1K model, and (c) to actually get any machine code to work on the ZX80 in the first place without being a Level 60 Mage like Paul Farrow.

And for anyone who wants to know how it was done (fellow machine code noobs, watch and learn), I've put a fully annotated listing in the ZIP package, along with a spreadsheet that worked out all the values I had to put into the array Q.





Hex Bin Converter for ZX80 - grab it here!

TMD2003 wrote: ↑Tue Aug 17, 2021 9:31 pm Mark's example of how it's done on SZXW has twice the number of BASIC lines that it needs.

The program linked to was for demonstration purposes only. WARNING This program has Commodore 64 influence. This program is not to be used for life support, in any part of any critical system, in any part of any nuclear reactor or power station control system, or for any commercial purposes. This program may fail to entertain if used in an entertainment application. No income tax, no VAT. No money back, no guarantee… You are strongly recommended to be sitting on your towel just in case of any problems

Mark

Nice Lissajous curves. I have a bit of an interest in them. Did my own project in Z88dk. https://github.com/andydansby/Lissajou ... ose-Curves.

I use a sine estimation to speed mine up as well as compiling the code.

Andy Dansby

I've been away in QL-land for the last week to keep me amused, in the absence of CSSCGC entries that aren't completely broken and have me tearing my hair out (because nature hasn't done that for me and I'd perfer to keep it that way for as long as possible). Over on the QL Forum, what I post there gets attention from those who like to examine it, pull it apart, and see what improvements can be made - such is the way with a more technical forum. Meanwhile, my latest attempt to show what can be done on Sir Clive's four-coloured business machine is this:



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, that culminated in the program a few posts above this one. With that completed and running successfully, why not turn my hand to the QL again? 68000 machine code is still beyond me, so we're back to strictly (Super)BASIC for this one.

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?

Crikey o'blimey. Is it a year and a half since I've been mucking about with bits and pieces of BASIC?

Anyway... seeing as I had cause to make a character set out of what Final Fantasy provided for the FF Jukebox, and also needed a few hiragana characters for the loading screen, I thought I'd go all the way and make a short demo of Japanese character sets swiped from FF1 (the American release) and FF2 (which only ever emerged in Japan at the time).





I'm quite impressed at how even the more complicated hiragana characters can still just about be crammed into an 8×8 pixel square and still be legible (to those who can read it, anyway). Maybe one day, this will be of use to someone with an interest in all things Japanese. Preferably someone who doesn't wear pink cat ears on top of an impossibly spiky blue hairdo. So, if you wish to have much honour:

GET IT HERE