Aquarius Graphics Editor and "SuperFont" Upgrade Idea

[+MattelAquarius]

Perhaps you could dump the Aquarius Videotex character ROM and include it in the set (if it is deemed interesting and/or worthy). The loose rom has been sitting around for many years, even before it came into my possession over a decade ago.

[barnieg]

Would it be possible to tie the Superfont and RAM upgrade together i.e if you have to make internal mods for the Superfont ROM allow part of the RAM cartridge to act as a fake character ROM?

Edited June 20, 2011 by barnieg

[jaybird3rd]

Would it be possible to tie the Superfont and RAM upgrade together i.e if you have to make internal mods for the Superfont ROM allow part of the RAM cartridge to act as a fake character ROM?

I'm still thinking about my options for implementing the character ROM and RAM, and that's a very good possibility: to allow the 32K RAM module to double as character RAM instead of adding dedicated internal RAM for that purpose. I'll already be adding logic to allow the user to select a character bank within the SuperFont ROM (possibly by writing a value to an I/O port), and it probably wouldn't be much extra work to also bank in portions of the extended RAM and connect it directly to the character generator. What I like about that idea is that it would make it very easy to change the character data: you could set up the character sets by copying the data directly into the correct region of RAM, and you could even programmatically change individual characters to create some nice animation effects.

 

The main question I would have is whether this would create any conflicts, given the way the character data is accessed. Here's how it currently works: the RAM chip containing the character matrix (one of the two 2K RAM chips in the Aquarius) is connected directly to the original character ROM's top address lines. When the character generator scans this matrix, the character codes appear on the RAM's data outputs, and the corresponding bitmaps within the character ROM are automatically selected. The bitmaps are then read by the character generator and combined with the color data to create the on-screen graphics. I don't know whether using system RAM both as the source of the character codes and as the source of the bitmap data will create any timing issues. I'll definitely investigate it further.

[jaybird3rd]

Perhaps you could dump the Aquarius Videotex character ROM and include it in the set (if it is deemed interesting and/or worthy). The loose rom has been sitting around for many years, even before it came into my possession over a decade ago.

Absolutely. If I have the opportunity to dump it, I'll see if the characters in it will fit into an Aquarius character set, and if they do, I'll certainly add it to my list.

 

Incidentally (and somewhat off-topic), I also dumped the character ROM from a Cromemco C-10 computer, which included a character set dedicated entirely to chess graphics. I used to play chess all the time on the C-10 years ago, and I wanted to have those graphics available in the ROM so I could use them with a modified version of Aquarius Chess.

[barnieg]

The Sinclair ZX-81 had a few ROM boards created with some games created to use the extended graphics characters last time I looked it wasn’t too hard to find the ROMS to download and I'm pretty sure some of the ZX-81 emulators include these ROM boards as part of the emulation

 

Barnie

Edited June 20, 2011 by barnieg

[+MattelAquarius]

Perhaps you could dump the Aquarius Videotex character ROM and include it in the set (if it is deemed interesting and/or worthy). The loose rom has been sitting around for many years, even before it came into my possession over a decade ago.

Absolutely. If I have the opportunity to dump it, I'll see if the characters in it will fit into an Aquarius character set, and if they do, I'll certainly add it to my list.

 

As far as I know, it should be a perfect match, since it was designed for the Aquarius.

 

Here are some shots of brochure featuring the device it was designed for:

 

 

 

Incidentally (and somewhat off-topic), I also dumped the character ROM from a Cromemco C-10 computer, which included a character set dedicated entirely to chess graphics. I used to play chess all the time on the C-10 years ago, and I wanted to have those graphics available in the ROM so I could use them with a modified version of Aquarius Chess.

 

 

Fancier chess pieces would certainly be welcome. I can see this project is really going to redefine the Aquarius capabilities.

[+MattelAquarius]

Not to go off topic, but I wonder how they would have dealt with the problem of a custom character ROM in the Videotex Aquarius when it came time for a user to print the screen.

 

After all, the Aquarius printer had the standard character matrix built in. Hmm. No print option?

[Aquaman]

Would it also be possible with the help of the Superfont Upgrade Idea to upgrade the "Bitmap" possibilities and getting it from 80x72 up to the usual 320x192? Are these not stored somewhere in the same ROM space? In my opinion it doesn't really feel like a real bitmap mode and more of a text mode being used in a different way(they overwrite each other on the screen), but please correct me if I am wrong.

[+MattelAquarius]

Would it also be possible with the help of the Superfont Upgrade Idea to upgrade the "Bitmap" possibilities and getting it from 80x72 up to the usual 320x192? Are these not stored somewhere in the same ROM space? In my opinion it doesn't really feel like a real bitmap mode and more of a text mode being used in a different way(they overwrite each other on the screen), but please correct me if I am wrong.

 

You are not wrong. More specifically, there is only one "mode" on the Aquarius. Everything you see on the Aquarius screen is made from its 256 built-in characters. The 80x72 PSET characters are all part of the 256, as well.

 

So, just like it is impossible to have an "A" character in the same space as the letter "B", so it is impossible to have a PSET character share the same block as text.

[Aquaman]

Would it also be possible with the help of the Superfont Upgrade Idea to upgrade the "Bitmap" possibilities and getting it from 80x72 up to the usual 320x192? Are these not stored somewhere in the same ROM space? In my opinion it doesn't really feel like a real bitmap mode and more of a text mode being used in a different way(they overwrite each other on the screen), but please correct me if I am wrong.

 

You are not wrong. More specifically, there is only one "mode" on the Aquarius. Everything you see on the Aquarius screen is made from its 256 built-in characters. The 80x72 PSET characters are all part of the 256, as well.

 

So, just like it is impossible to have an "A" character in the same space as the letter "B", so it is impossible to have a PSET character share the same block as text.

 

So it seems the problem lies within the pset capability of dividing the characters in different bits. Do you think there is some way around this to utilize the full graphic capabilities?

[+MattelAquarius]

Would it also be possible with the help of the Superfont Upgrade Idea to upgrade the "Bitmap" possibilities and getting it from 80x72 up to the usual 320x192? Are these not stored somewhere in the same ROM space? In my opinion it doesn't really feel like a real bitmap mode and more of a text mode being used in a different way(they overwrite each other on the screen), but please correct me if I am wrong.

 

You are not wrong. More specifically, there is only one "mode" on the Aquarius. Everything you see on the Aquarius screen is made from its 256 built-in characters. The 80x72 PSET characters are all part of the 256, as well.

 

So, just like it is impossible to have an "A" character in the same space as the letter "B", so it is impossible to have a PSET character share the same block as text.

 

So it seems the problem lies within the pset capability of dividing the characters in different bits. Do you think there is some way around this to utilize the full graphic capabilities?

 

Actually, there is no "PSET capability." PSET is merely a shorthand for poking one of the (PSET block looking) 256 alpha/graphic characters onto the screen using pseudo 80x72 coordinates.

 

It does not seem there will ever be a way to exceed the Aquarius 256 character display limitation. The best we can hope for is Jaybird3rd's plan to at least make the 256 characters changeable.

[Aquaman]

Would it also be possible with the help of the Superfont Upgrade Idea to upgrade the "Bitmap" possibilities and getting it from 80x72 up to the usual 320x192? Are these not stored somewhere in the same ROM space? In my opinion it doesn't really feel like a real bitmap mode and more of a text mode being used in a different way(they overwrite each other on the screen), but please correct me if I am wrong.

 

You are not wrong. More specifically, there is only one "mode" on the Aquarius. Everything you see on the Aquarius screen is made from its 256 built-in characters. The 80x72 PSET characters are all part of the 256, as well.

 

So, just like it is impossible to have an "A" character in the same space as the letter "B", so it is impossible to have a PSET character share the same block as text.

 

So it seems the problem lies within the pset capability of dividing the characters in different bits. Do you think there is some way around this to utilize the full graphic capabilities?

 

Actually, there is no "PSET capability." PSET is merely a shorthand for poking one of the (PSET block looking) 256 alpha/graphic characters onto the screen using pseudo 80x72 coordinates.

 

It does not seem there will ever be a way to exceed the Aquarius 256 character display limitation. The best we can hope for is Jaybird3rd's plan to at least make the 256 characters changeable.

 

Yes, let's hope he succeeds. That would already be a huge step for the Aquarius capabilities. Thanks for the input!

[jaybird3rd]

The way they handled the PSET graphics is pretty interesting. I added a note about them to the Astrosmash trivia in the Aquaricart, since that game relies pretty heavily on them. Here's part of what I wrote:

 

Fortunately, Mattel's artists had the foresight to include a collection of general-purpose block character cells. These cells were divided into two-by-three grids of "pixels" (or "bloxels", since they were larger than the actual screen pixels), and every possible combination of bloxels was included as a separate cell. By carefully combining these cells, a programmer could create the illusion of a fully programmable, low-resolution, pixel-oriented display.

 

These cells were arranged within the character set in an interesting way. Every bloxel in the 2x3 grid is given a value:

 

+----+----+
|  1 |  2 |
|----|----|
|  4 |  8 |
|----|----|
| 16 | 32 |
+----+----+

By determining which bloxels need to be "on" or "off" within a given cell, and by computing the total value of the bloxels which are "on", the programmer can locate the corresponding character within the character set using a simple calculation: if the total value is less than 32 (that is, if the last bloxel is "off"), it is added to the number 160. If the total value is equal to or greater than 32 (that is, if the last bloxel is "on"), it is added to 192. In both cases, the result is the character code.

So, when you use a PSET command in BASIC, the computer is actually determining which character cell on the screen the specified "bloxel" should appear in, checking the code already in the cell (if any), and calculating what to replace it with to make it appear as if the new "bloxel" is being individually turned on.

 

Unfortunately, this is really the best you can do with the Aquarius. As I said earlier, the character RAM and the character set ROM are literally hardwired together. It's a pretty closed system, as far as graphics are concerned.

[Aquaman]

The way they handled the PSET graphics is pretty interesting. I added a note about them to the Astrosmash trivia in the Aquaricart, since that game relies pretty heavily on them. Here's part of what I wrote:

 

Fortunately, Mattel's artists had the foresight to include a collection of general-purpose block character cells. These cells were divided into two-by-three grids of "pixels" (or "bloxels", since they were larger than the actual screen pixels), and every possible combination of bloxels was included as a separate cell. By carefully combining these cells, a programmer could create the illusion of a fully programmable, low-resolution, pixel-oriented display.

 

These cells were arranged within the character set in an interesting way. Every bloxel in the 2x3 grid is given a value:

 

+----+----+
|  1 |  2 |
|----|----|
|  4 |  8 |
|----|----|
| 16 | 32 |
+----+----+

By determining which bloxels need to be "on" or "off" within a given cell, and by computing the total value of the bloxels which are "on", the programmer can locate the corresponding character within the character set using a simple calculation: if the total value is less than 32 (that is, if the last bloxel is "off"), it is added to the number 160. If the total value is equal to or greater than 32 (that is, if the last bloxel is "on"), it is added to 192. In both cases, the result is the character code.

So, when you use a PSET command in BASIC, the computer is actually determining which character cell on the screen the specified "bloxel" should appear in, checking the code already in the cell (if any), and calculating what to replace it with to make it appear as if the new "bloxel" is being individually turned on.

 

Unfortunately, this is really the best you can do with the Aquarius. As I said earlier, the character RAM and the character set ROM are literally hardwired together. It's a pretty closed system, as far as graphics are concerned.

 

Indeed a very interesting way of creating an illusion of having some kind of bitmap mode. Just a pity it is only using these six pixels, some more refinement would have been nice. But anyway thanks for giving me more insight in the way this is done.

[GroovyBee]

I don't know anything about the Aquarius hardware, but if you have access to a register or interrupt that tells you that you are in VBLANK you could do some neat programming tricks to get a full high resolution bitmap display. Only if jaybird3rd supports such an idea in hardware. How about having quite a few RAM "slots" for a full set of font data and a latch to select between them on the fly (to redirect the video access hardware)? That way, every few character lines on the display you could swap over to a new font (with a write to the latch) using a precision software timed loop (or timer interrupt). With each of the fonts being RAM based you'll get a full 1bpp, pixel addressable bitmap display.

 

No idea if it would work.... .

[jaybird3rd]

I don't know anything about the Aquarius hardware, but if you have access to a register or interrupt that tells you that you are in VBLANK you could do some neat programming tricks to get a full high resolution bitmap display. Only if jaybird3rd supports such an idea in hardware. How about having quite a few RAM "slots" for a full set of font data and a latch to select between them on the fly (to redirect the video access hardware)? That way, every few character lines on the display you could swap over to a new font (with a write to the latch) using a precision software timed loop (or timer interrupt). With each of the fonts being RAM based you'll get a full 1bpp, pixel addressable bitmap display.

 

No idea if it would work.... .

I'm definitely thinking along those lines (a latched character RAM and ROM); my little experiment with a bankswitched ROM seems to indicate that this would work. There is indeed a VBLANK register that one can check, and an 8K character RAM would give you enough character sets for a fully pixel-addressable bitmap display (although the colors would still be limited to 8x8 cells). There are any number of ways this could be done, and I'll be investigating my options once I'm free to concentrate on it "full time".

[mvdsteenoven]

So, when you use a PSET command in BASIC, the computer is actually determining which character cell on the screen the specified "bloxel" should appear in, checking the code already in the cell (if any), and calculating what to replace it with to make it appear as if the new "bloxel" is being individually turned on.

I've found this piece of code in the ROM as well, and was pretty amazed about the simplicity of the code and the intelligence in the way the Aquarius characterset was build.

Jay, are you disassembling all carts? Which disassembler do you use? Personally i use dz80w, it allows you to create your own script during disassembly. I've created a script that write comments when common Aquarius adresses are being used.

 

Regs,

Martin

[mvdsteenoven]

So, when you use a PSET command in BASIC, the computer is actually determining which character cell on the screen the specified "bloxel" should appear in, checking the code already in the cell (if any), and calculating what to replace it with to make it appear as if the new "bloxel" is being individually turned on.

I've found this piece of code in the ROM as well, and was pretty amazed about the simplicity of the code and the intelligence in the way the Aquarius characterset was build.

Jay, are you disassembling all carts? Which disassembler do you use? Personally i use dz80w, it allows you to create your own script during disassembly. I've created a script that write comments when common Aquarius adresses are being used.

 

Regs,

Martin

[mvdsteenoven]

Edit: Accidently posted twice......

 

Martin

Edited August 5, 2011 by mvdsteenoven

[jaybird3rd]

I've found this piece of code in the ROM as well, and was pretty amazed about the simplicity of the code and the intelligence in the way the Aquarius characterset was build.

I was impressed with it, too. When I first saw the complete Aquarius character set, I couldn't understand why it was designed the way it was: I saw lots of shapes that could have been created by reversing the colors on other shapes, and some that were even duplicates. It's a pretty elegant solution considering the restrictions they had to work with.

 

Jay, are you disassembling all carts? Which disassembler do you use? Personally i use dz80w, it allows you to create your own script during disassembly. I've created a script that write comments when common Aquarius adresses are being used.

I use a disassembler called DASMx. I don't think it allows the use of scripts, so I'll definitely try dz80w because I'd like to have that functionality (I still have a hard time making sense of disassembled code). I haven't disassembled all the cartridges yet, but I've learned some interesting things from the ones I've looked at so far.

 

Here's one example, even though this goes somewhat off-topic: I disassembled BurgerTime because I wanted to create a version that allows up to 99 lives and peppers instead of just nine (this version will be included in the Aquaricart as "BurgerTime Plus"). I found the code that implements both of these limits, but for some reason, it's done in two different ways. The program never increments the number of lives if it has already reached nine, but it always increments the number of peppers, then checks it after the fact and decrements it again if it has reached ten. Very strange.

[mvdsteenoven]

Here's one example, even though this goes somewhat off-topic: I disassembled BurgerTime because I wanted to create a version that allows up to 99 lives and peppers instead of just nine (this version will be included in the Aquaricart as "BurgerTime Plus"). I found the code that implements both of these limits, but for some reason, it's done in two different ways. The program never increments the number of lives if it has already reached nine, but it always increments the number of peppers, then checks it after the fact and decrements it again if it has reached ten. Very strange.

I have not looked into the game carts, but did some experimenting with Extended Basic and the QD ROM.

I have written an article on dZ80w and added it to the Aquarius programming resources topic.

 

Regs,

Martin

[Pset]

How's this editor and font thing coming along?

 

I found BitFontMaker today while looking for solutions to fix the true type Aquarius fonts.

 

I noticed it has an interesting output option?

This is characters Aquarius characters lower case j and then 253 to 255.

{"106":[0,0,8,0,0,8,8,8,8,8,8,8,8,8,4,0],
"253":[0,0,0,0,0,0,0,0,1020,1020,1020,1020,0,0,0,0],
"254":[0,0,0,0,60,60,60,60,1020,1020,1020,1020,0,0,0,0],
"255":[0,0,0,0,960,960,960,960,1020,1020,1020,1020,0,0,0,0],
"name":"fontname","copy":"author","letterspace":"64"}

Maybe we can use that for something?

Perhaps add I/O options for that data in the Character Editor.

How exactly does the character editor write a ROM anyway?

 

Also BitFontMaker has some great basic features the Aquarius Character Editor is missing.

Copy and paste between frames and nudge are great tools in small bit map drawing environments.

If you look at the Aquarius graphics you'll note they are mirrored and rotated often as well.

 

Thought I'd mention all that in case you were looking at your code again.

 

 

 

Edited November 24, 2013 by Pset

[jaybird3rd]

How's this editor and font thing coming along?

 

I certainly haven't forgotten about them, but my ideas about how to implement them have changed quite a bit. When I started this thread, I was fixed on the idea of an internal upgrade that would have required desoldering the character ROM and replacing it with an upgrade board. This would have been a very labor-intensive installation, however, so after taking a closer look at the Aquarius schematics, I found a way to do it by running a couple of wires and perhaps pulling one pin or cutting one trace on the mainboard. Nothing irreversible, and nothing that should take any longer than about fifteen minutes. I've also decided against the idea of a dedicated upgrade; I'm going to instead try to make it a part of a new Mini Expander, which will also include 32K of expanded RAM onboard, a second PSG sound chip, and a bunch of other nifty features, all in one "plug and play" package. As I presently envision the design, you would load one or more new character sets into 2K "windows" inside the 32K expanded RAM, and then enable the SuperFont upgrade, which would switch from the built-in character set to one of the ones in the RAM.

 

The character editor was something that I put together in a couple of hours so I could have something to use to create my own alternate character sets, when I was first experimenting with this idea. It's very primitive, both in the way it's written and in the features it offers, so we definitely need something better. I'm eventually going to make it a part of my Aquarius Screen Editor (here is a screenshot of my prototype), and I'll definitely include the features that you mention, and even a "sketchpad" in which you can create simple animation cycles using a sequence of characters. Think of TheDraw (the old DOS ANSI editor that was popular for BBS character graphics) combined with the character editor, and you've got the idea of what I want the Screen Editor to be.

 

Once I get the Aquaricart Volume II collection finished, I'll revisit the "Mini Expander II" project. I'll need to have it working (at least in prototype form) before I can move on to my own games, since I'd obviously like them to support it.

[+Gemintronic]

So, one must custom mod an Aquarius and aquire the Jaybird3rd expansion? Not complaining - just trying to understand

[jaybird3rd]

So, one must custom mod an Aquarius and aquire the Jaybird3rd expansion? Not complaining - just trying to understand

Only if you want to be able to change the characters. If you'd rather not crack your computer open, you can simply plug in the new Mini Expander and use its other features while sticking with the default character set, or not get a Mini Expander at all. There will be a way for new homebrew games to detect whether these upgrades are present or absent, and I don't foresee writing a game which would require them, so it's all optional.