jaybird3rd

By all means, continue having fun with Logo! If you're just learning programming, and if you have to choose between BASIC and Logo on the Aquarius, I think Logo is a much better place to start. BASIC may have certain capabilities that Logo lacks, but its very old-fashioned, non-structured approach to programming encourages too many bad habits. If you learn with a language like Logo first, I think that experience will help you to avoid or mitigate the worst parts of BASIC. (I first learned programming in BASIC on the TI 99/4A and Atari computers, and that experience taught me many valuable things about computers, but it also proved to be a hindrance in certain ways. It took me the longest time to get used to the very idea of programming without line numbers!)

(Come to think of it, I might work up a quick proof of concept based on Martin's code. I can show you how to read the hand controllers and decode the directions and keys; it would only require a few additional lines of BASIC.)

"Machine code" refers to the native instructions of the hardware. BASIC and Logo are interpreted languages, meaning that every line of code must be translated from the human-readable language that it was originally written in (such as BASIC or Logo) into machine code, before the computer can execute it. The overhead incurred by this process is is one of the reasons that programs written in these languages tend to be slower than the equivalent programs written in pure machine code; by using machine code, you're talking to the hardware directly, without the need for any intermediary interpreter. The Aquarius uses a Z80 (or compatible) microprocessor, so the "machine code" in this case is Z80 machine code. (Incidentally, this is one of the nice things about the Aquarius: many other home computers also used the Z80, so there are lots of resources and examples that can be applied to the Aquarius, even if they were originally intended for very different machines.) Most programmers, however, generally do not write machine code directly; working at the level of zeroes and ones is very error-prone and time-consuming, especially for large programs. Instead, they work in assembly language, which is one level of abstraction higher. You see some examples of this in Martin's example hand controller code, which breaks down the individual opcodes used in the inline machine language program. LD, IN, and OUT are assembly language mnemonics: LD means "load" (as in, load a value into a memory location or register), and IN and OUT mean "input" and "output" (as in, read or write a value to an I/O port; in this case, the port numbers assigned to the PSG chip in the Mini Expander). These mnemonics and their operands are translated into the corresponding machine code by an assembler. Once you have the machine code—which, as with everything in computers, is nothing but numbers in memory—you can slip it in to a BASIC program as a series of DATA statements and execute it with a USR instruction, as Martin's program does. (That's what the numbers which follow the DATA statement in his program actually mean; they're the individual bytes of the machine code, entered into the program as a succession of decimal numbers.) If all this sounds intimidating, *please* don't let it deter you from your exploration of programming! You can work happily in BASIC or Logo, and write very excellent programs, without having to know anything about assembly or machine code. When you begin to run up against the limits of what these languages can do for you, that's when you would start to think about sprinkling in some machine code to overcome these limits.

Yes, you can read from the hand controller keys as well as the direction disc; it's all part of the same input code. You'd have to do some arithmetic to determine from the code which key(s) are being pressed, just as you would to decode the disc direction, but this is not too difficult. Anything you want to do can be theoretically be done in BASIC, though it might be a bit slow. A common approach was to build a prototype using pure BASIC, and then to add machine code routines (like the hand controller code I linked earlier) to speed up the most time-critical parts of the code. (I don't happen to remember if Aquarius Logo allows the use of machine code—some Logo implementations did, and others did not—which is why I recommended BASIC first.) Another example is filling the screen with a different color in a BASIC program. This is very slow if you do it in a FOR loop with a succession of POKE statements, as was often done, but very fast if you do it with machine code.

You could do that with either language, though BASIC might be more straightforward. You don't even need to use any Extended BASIC commands; the regular version of BASIC has all the language features you'd need. By adding a little inline machine code, you could even write a program to move the man with the hand controllers; Martin v.d. Steenoven provides a helpful tutorial on his website.

Awesome! Logo is a great introductory programming language, ideal for free-styling. Aquarius Logo suffers from the limits of its character-oriented display, but it's a good implementation of the core language, particularly for a 16K program cartridge. (I doubt that Mattel implemented Aquarius Logo from scratch, but I don't happen to know what version of Logo it would have been based on. Many home computers of the time used some version of LCSI Logo, but the packaging usually identified it as such, whereas the Aquarius version does not. The core language is fairly similar across most versions, so if you find an example Logo program for another home computer that you like, that doesn't rely on platform-specific features like sprites, you should be able to run it on the Aquarius with minimal modifications.) EDIT: Speaking of the display ... no, unfortunately there's no built-in way to increase the character size. The Aquarius is a strictly character-oriented system, so you get a 40x25 character matrix and the built-in character set, and that's it. (At least, for now ...)

Happy to be of service! I've actually found the Aquarius to be pretty good when it comes to the quality of the stock RF output, relatively speaking, but of course there are inherent limits to how good RF can be even at its best. Fortunately, we have better alternatives now; AtariAge member "1stage" has created a composite Aquarius A/V upgrade board ... https://www.ebay.com/itm/223672642110 ... and I know of at least one RGB upgrade that is in the works as well.

I'm sure we'd all greatly appreciate it if you would. This back-and-forth bickering is getting tiresome.

There is an Aquarius FAQ, originally written by Fred Horvat and updated by Sylvain De Chantal. The most recent version that I know of is this one, hosted by Digital Press: https://www.digitpress.com/faq/aquarius.htm

Thank you for posting the video! (I had to download and play the file locally to get audio and video; for some reason, I only get the audio when playing it in the browser.) I know we've already exchanged some suggestions via e-mail, but I'd like to post them here as well in case they would be helpful to others with a similar problem, or in case someone else can offer other suggestions. You might first try rearranging or rerouting the RF cable to isolate it as much as possible from the power supply and the Mini Expander. You might also try adjusting or re-tuning the channel while the Aquarius is on and displaying the Aquaricart main menu, and/or turning down the brightness slightly. Also, when using the Aquaricart and 32K RAM module together, if you start hearing noise, try switching to a different screen other than the main menu to see if the noise disappears or changes. (For example, press "9" to view the "About" screens, the first of which approximates the classic splash screen of an original Aquarius cartridge, or press "7" to display the "Guide to Home Computing" pages as plain white-on-black text.) I know that displaying certain types of pictures can cause some TVs to generate noise—pictures with lots of white, for example—and I'm wondering if the striped background pattern on the main menu, or even the bright highlight bar in the menu, might possibly be contributing to the problem. If you have another TV handy, I'd be curious to know if this happens with the other TV, or if it's something specific to this particular TV.

I simply cannot fathom why Brad wouldn't want to do business with some of you fun folks.

Yes, I think I know the exact source you're referring to, and that's what got me thinking as well! (I picked up 100 of those chips myself with the idea of doing my own recreation someday, but I'm more than happy that you got to it first. I already have another project in mind for mine.)

I agree, feature creep is fatal. Better to keep the features to a minimum. It would be nice if the DB25 printer port from the original could be retained, even if only as a pin header, but I can understand the decision to leave it out.

Glad to see you're working on this! (I was toying with the idea of doing this myself at some point.) Question: The original XEP-80 used the NS405-A12N, but the NS405-B12N is much more readily available. Will the -B work with the new board, or will it be necessary to stick with the -A?

Already posted here.

Here is a quick merge of the original pages into a PDF. As easy as "convert `ls *.jpg` AquariusPrinter.pdf"! AquariusPrinter.pdf At some point, I'll probably do an improved version. In particular, I notice that Mattel stamped in a few corrections and additions after the manuals had been printed, and it would be nice to patch the images to incorporate these changes into the original text.

Even better! When you get the chance, go ahead and package the individual page scans into an archive and post them here. I've got a few PDF utilities that could do the job.

No problem! Thank you for taking the time to scan it. It wouldn't be difficult to crop the images and collate them into a new PDF.

Aha, thank you! It doesn't tell you much more than the "Aquarius Guide to Home Computing" when it comes to using the printer, but it's great to have it scanned.

Well, it looks as if I spoke too soon: I seemed to recall coming across a scan of the Aquarius Printer manual in my archives, but when I opened it, it turned out to be a scan of EdgeOfPortal's Aquarius Plotter manual, which you already have. My Aquarius Printer was purchased CIB, so it must have come with a manual, but I haven't found it yet in the time I've had to look for it today. I'll keep looking.

Sorry to keep you waiting (been busy with work). I'll free up some time for this over the weekend.

^ ... and if anyone wants an idea of all that is involved to get the cartridges to this point, I documented the procedure that I use (which is similar) in this thread. Re-building them as new cartridges would also include assembling and testing the electronics, which is even more time-consuming.

I have scans of the printer manual in my archives. I'm away from them at the moment, but if they're still needed, I'll dig them out and post them when I can get to them.

Put me down for one, too!