Jump to content
IGNORED

Aquarius 320x200 Bitmap Graphics Hack


Bruce Abbott

Recommended Posts

I finally achieved something I have wanted to do for 30 years - give the Aquarius programmable characters and true bitmap graphics! (perhaps if it had this built in originally, it might not have bombed so badly when launched back in 1983).

 

My first goal was to just replace the character ROM with a 2k static RAM and multiplexer circuit, allowing individual character patterns to be redefined if desired. This worked well, but then I realized that with just one more logic chip I could boost the number of programmable characters from 256 to 1024 (4 banks of 256). By selecting each bank of characters in a different horizontal section of the screen, I could create a 320x200 true bitmap graphics mode.

 

Below are a few monochrome bitmap images displayed on my Aquarius. To process these and get them into my machine I used a hodgepodge of various software tools:-

 

- Corel Photo-Paint 7: crop, scale, reduce colors, save as 320x200 BMP image.

- BMPAQV41 by Moonsweeper: modified to convert BMP file into character patterns and save as asm include file.

- Zmac macro assembler: convert asm source to binary file.

- AQ_tapeldprep: convert binary file to CAQ tape format for use with McNamara & Dubois BASIC loader.

- CAQ2WAV: convert CAQ file to WAV audio.

- VLC media player: play WAV file through PC sound card to Aquarius tape port.

 

 

lethal%20weapon.jpg

 

geos.jpg

 

aquarius.jpg

 

And here is a YouTube video showing the above image loading from tape. The psychedelic moire effect is caused by interaction between my cellphone camera and the monitor screen. I think it enhances the video - makes it look like it was produced back in the 1970's :)

 

https://www.youtube.com/watch?v=R_XPQFocHBo

 

Of course no existing software can make use of this enhancement - so was it worth doing, or is it just a pointless hack? What do you think?

 

 

Aquarius 8k PCG Eagle CAD.zip

  • Like 12
Link to comment
Share on other sites

Excellent! I'm glad that you got this working.

 

Since the video upgrades that we've both been working on include 32K of video RAM, I think it makes perfect sense to get the most out of it and include a fullscreen bitmapped graphics "mode." From your schematic, it does indeed look like a simple extension: you appear to be using the top address lines from the character matrix to select the correct 2K "bank" in the character RAM, which is a much more straightforward method than I had envisioned. I'd like to add this functionality to my design as well, and with the approach I'm taking with it, I can even see a way to allow a 32K character RAM to be divided into four bitmapped screens, or sixteen separate character sets, or different combinations of the two, all selectable by the user.

  • Like 2
Link to comment
Share on other sites

Since I'm also working on my Aquarius Screen Editor prototype, I think it would be useful to add a bitmap import feature, to automatically slice a 320x200 graphic file into four sets of 8x8 characters. To help BASIC programmers make use of it in their programs, I'll also add an option to export directly to a BASIC program listing.

  • Like 2
Link to comment
Share on other sites

Excellent work! I don't think its pointless as it appears to be a reasonably transparent way to upgrade capabilities, would certainly make ports from something like the spectrum relatively easy (in theory), I still think there is life left in chunky vision :) Maybe going forward coding homebrew to fallback to a reasonably well chosen set of characters? or an alternative character selection option?

 

Barnie

 

 

 

Of course no existing software can make use of this enhancement - so was it worth doing, or is it just a pointless hack? What do you think?

 

 

  • Like 1
Link to comment
Share on other sites

I finally achieved something I have wanted to do for 30 years - give the Aquarius programmable characters and true bitmap graphics! (perhaps if it had this built in originally, it might not have bombed so badly when launched back in 1983).

 

Of course no existing software can make use of this enhancement - so was it worth doing, or is it just a pointless hack? What do you think?

 

 

Wow, great job! :thumbsup:

 

I also really think, that if the Aquarius was originally build with graphical possibilities like programmable graphics, it would have been much more popular. If I am not mistaken, with the help of the Mini-Expander and the 16K RAM extension, the overall specs would have been better than the common ZX Spectrum 16K?

 

Something like this is not pointless, because it still makes use of the main computer and can be seen as a genuine upgrade (which could have been the Aquarius II/III). As for the software side, this opens a lot more possibilities for programmers. I think a lot of potential home-brew programmers where put off, because of the lack of programmable characters. Maybe they come on board now :-D

  • Like 2
Link to comment
Share on other sites

Excellent work! I don't think its pointless as it appears to be a reasonably transparent way to upgrade capabilities, would certainly make ports from something like the spectrum relatively easy (in theory), I still think there is life left in chunky vision :) Maybe going forward coding homebrew to fallback to a reasonably well chosen set of characters? or an alternative character selection option?

 

Barnie

This upgrade will certainly make it easier to do different kinds of games, but there are still certain limits to what it can do. The Aquarius is still a character-based system at heart, and I wouldn't want to change that; the fullscreen bitmap upgrade simply allows the Aquarius to switch between four character sets within one frame, to create the illusion of a continuous bitmapped display.

 

Bruce's upgrade and my "SuperFont" upgrade will use similar methods for accessing the character RAM; the main difference will be the location of the RAM and how much of it will be accessible at once. But neither design presently allows the contents of the RAM to be read (it can only be written), which would make it more difficult to create overlapping "sprites" or implement collision detection in software. In addition, the color map must still be applied in 8x8 blocks, so you still won't be able to get three or more colors inside one character cell.

 

As for the character sets ... what I want to do with "SuperFont" is to leave the original character ROM intact, so that when you start the Aquarius, you'll still have the same character set that you had before. To use alternative character set(s), you would first copy the character data into one or more banks of the character RAM, and then enable the "SuperFont" upgrade and select the correct bank in your program (there will be room for up to sixteen different character sets in the RAM). New character sets can be created right now using the Character Builder tool that I posted here, but I'll soon have a much better tool ready to share.

  • Like 2
Link to comment
Share on other sites

This upgrade will certainly make it easier to do different kinds of games, but there are still certain limits to what it can do. The Aquarius is still a character-based system at heart; the fullscreen bitmap upgrade simply allows the Aquarius to switch between four character sets within one frame.

 

Bruce's version of the upgrade and mine will use similar methods for accessing the character RAM; the main difference will be the location and how much of the RAM will be accessible at once. But neither design presently allows the contents of the RAM to be read (it can only be written), which would make it more difficult to create overlapping sprites or implement collision detection. In addition, the color map must still be applied in 8x8 blocks, so you won't be able to get three or more colors inside one character cell.

Of course it will still be character based with it's obvious limitations, but a lot of computers at that time where. I am not quite sure why collision detection would be more difficult? You mean a altered game character consisting of one or more 8x8 blocks could not detect the collision with an other game character? When I look at certain ZX spectrum games even overlapping seems possible (Uridium for example), is this then all due to the fact the Spectrum can read and write the RAM contents?

Link to comment
Share on other sites

The Spectrum has a full bitmap screen, so I believe this makes software sprites etc somewhat easier.

 

http://wordpress.animatez.co.uk/computers/zx-spectrum/screen-memory-layout/

 

However on a straight port from a Spectrum if 256x192 res was used that would leave some "redundant" characters which could be used to shift defined graphics which may allow for smoother scrolling etc

 

 

 

 

Of course it will still be character based with it's obvious limitations, but a lot of computers at that time where. I am not quite sure why collision detection would be more difficult? You mean a altered game character consisting of one or more 8x8 blocks could not detect the collision with an other game character? When I look at certain ZX spectrum games even overlapping seems possible (Uridium for example), is this then all due to the fact the Spectrum can read and write the RAM contents?

  • Like 1
Link to comment
Share on other sites

I am not quite sure why collision detection would be more difficult?

Because you can't read the screen, it's not possible to detect a collision by simply XORing the sprite against the background. Also you can't draw a sprite without wiping out the screen area under it. However these limitations can be overcome by keeping the background in main memory to combine with the sprite, then copying the final result to the screen. This technique is often used in games because it reduces flicker.

 

A downside of full bitmap graphics is more memory and processing power required to manipulate it. A character based system needs only 1/8th as much memory and less even processing power, but of course is limited to preset characters. With a screen full of programmable characters the display can be optimized for any combination of speed, resolution and memory usage. For example an adventure game could use the top half of the screen for bitmap graphics, and still have a fast text display on the bottom half - with a fancy font!

 

I could make the RAM readable, but some area of memory must be allocated to read it from. Switching out the 8k BASIC ROM while reading RAM at the same location should work, provided the ROM is switched back in before calling any functions in it! I might try doing this, using the CP/M I/O bit (which I currently have disconnected) to do the switching.

 

Another possibility is to read and write the PCG RAM through an I/O port. This would have the advantage of not conflicting with any memory devices, and could be much easier to install (fewer wires to connect to the motherboard). However the lack of direct random access could make bitmap animation slower. I think this may be the best way to do it on the Aquarius, as ease of installation is probably more important than having fast bitmap graphics.

Edited by Bruce Abbott
  • Like 3
Link to comment
Share on other sites

From your schematic, it does indeed look like a simple extension: you appear to be using the top address lines from the character matrix to select the correct 2K "bank" in the character RAM

The video RAM address is continuously advanced as each character is displayed, so I just used A8 and A9 to switch character sets as it rolls over to the next (256 byte) page. The only annoying part is that the rollovers all occur somewhere in the middle of a line rather than at the end.

 

I'd like to add this functionality to my design as well, and with the approach I'm taking with it, I can even see a way to allow a 32K character RAM to be divided into four bitmapped screens, or sixteen separate character sets, or different combinations of the two, all selectable by the user.

 

I think my circuit suffers from having too many wires going to the motherboard. Does your design have a way around that? It would be nice to have a board that just plugs into the character ROM position, with a minimum of extra wiring (A8, A9, ????). Space is very tight under the keyboard, but the CPU area has more headroom. Perhaps a socket could be soldered on top of the CPU to plug an I/O board into, then read/write data and control signals sent from there to the character ROM board.

Edited by Bruce Abbott
  • Like 1
Link to comment
Share on other sites

 

- BMPAQV41 by Moonsweeper: modified to convert BMP file into character patterns and save as asm include file.

 

 

Who changed my name to Moonsweeper? This is a great achievement with this machine - the screen shots look great! Have you tried with color? How did you modify BMPAQ - meaning - you need to get the right character data out of it as well no? The 8x8 block color limitation would seem to suggest that color would look blocky but cartoons might do really well. In addition, an atkinson dither typically does better reducing the blocky effect versus floyd-steinberg. How do you get your custom characters loaded into memory? Do you reuse characters or did you just make the whole character set in order?

 

I wish I had your mod and some type of larger high speed data storage (Compact Flash, or other) because we could probably do 60 HZ full motion video with sigma delta audio at 40 KHz or so - would sound ok and look fantastic. Oh the possibilities!

 

Nice work. We need more screenshots to really appreciate it and a color cartoon would probably do really well. :)

 

Chris

  • Like 1
Link to comment
Share on other sites

 

Who changed my name to Moonsweeper?

Sorry about that. I looked at the text above your avatar and thought it was your username!

 

How did you modify BMPAQ - meaning - you need to get the right character data out of it as well no?

 

I replaced the part that creates the character based screen with my own code that generates a character pattern map instead (I thought it would be easy, but I spent most of the day just trying to get your source code to compile in FreeBasic! Then the real fun began...).

 

 

How do you get your custom characters loaded into memory? Do you reuse characters or did you just make the whole character set in order?

 

The programmable character RAM is mapped on top of the BASIC ROM, so getting the data into it is simply a matter of loading an 8k binary file at address $0000. Currently I am just using the whole character set in order, repeated 4 times over. Next step is to reuse characters that already have the correct pattern, then for higher compression start choosing those that are 'close enough'. I also want to add color, but I haven't yet figured out a good way to do it (other programs that I have tried seem to make a mess of 'colorizing' high resolution images).

 

I wish I had your mod and some type of larger high speed data storage (Compact Flash, or other) because we could probably do 60 HZ full motion video with sigma delta audio at 40 KHz or so - would sound ok and look fantastic. Oh the possibilities!

 

I was amazed by your Dallas video. With a well crafted custom character set it could be even better! So many possibilities...

 

But first I have to put more memory and I/O into my Aquarius. Only having the stock 4k of main RAM and tape storage makes for a very slow and frustrating development cycle.

  • Like 3
Link to comment
Share on other sites

But first I have to put more memory and I/O into my Aquarius. Only having the stock 4k of main RAM and tape storage makes for a very slow and frustrating development cycle.

I've designed a simple 32K RAM cartridge for the Aquarius, as well as a bankswitched EPROM cartridge board which allows up to eight megabits of storage. If you're interested, I'd be more than happy to send them to you; just send me a PM. I also have a design for a bankswitched SRAM cartridge and a USB download cable, which will avoid the need to burn a ROM for testing code. I'll have it finished as soon as I can find time to work on it again.

  • Like 2
Link to comment
Share on other sites

Because you can't read the screen, it's not possible to detect a collision by simply XORing the sprite against the background. Also you can't draw a sprite without wiping out the screen area under it. However these limitations can be overcome by keeping the background in main memory to combine with the sprite, then copying the final result to the screen. This technique is often used in games because it reduces flicker.

 

A downside of full bitmap graphics is more memory and processing power required to manipulate it. A character based system needs only 1/8th as much memory and less even processing power, but of course is limited to preset characters. With a screen full of programmable characters the display can be optimized for any combination of speed, resolution and memory usage. For example an adventure game could use the top half of the screen for bitmap graphics, and still have a fast text display on the bottom half - with a fancy font!

 

I could make the RAM readable, but some area of memory must be allocated to read it from. Switching out the 8k BASIC ROM while reading RAM at the same location should work, provided the ROM is switched back in before calling any functions in it! I might try doing this, using the CP/M I/O bit (which I currently have disconnected) to do the switching.

 

Another possibility is to read and write the PCG RAM through an I/O port. This would have the advantage of not conflicting with any memory devices, and could be much easier to install (fewer wires to connect to the motherboard). However the lack of direct random access could make bitmap animation slower. I think this may be the best way to do it on the Aquarius, as ease of installation is probably more important than having fast bitmap graphics.

I agree; I think the approach you've taken is a good tradeoff. It adds a great deal of flexibility to the Aquarius's character-oriented display, without trying to change it into something else. Having to do collision detection and other stuff in system RAM is a bit more complicated than a full bitmapped display would be, but now that we have an inexpensive RAM upgrade solution (see above), RAM isn't much of an issue anymore.

 

The problem that I see with using the CP/M bit to expose the character RAM for reading is that it drastically changes the Aquarius memory map, which would probably wreak havoc with cartridge-based software (now that I have new Aquarius cartridge boards and shells, most of the homebrew games I plan to produce will be cartridge-based).

  • Like 1
Link to comment
Share on other sites

The video RAM address is continuously advanced as each character is displayed, so I just used A8 and A9 to switch character sets as it rolls over to the next (256 byte) page. The only annoying part is that the rollovers all occur somewhere in the middle of a line rather than at the end.

Yes. It's a brilliantly economical solution. The main disadvantage is that the four "zones" of character data are not contiguous inside the RAM, so it will be necessary to make adjustments for objects which need to move vertically between zones (among other situations), but this is certainly not an insuperable problem.

 

I think my circuit suffers from having too many wires going to the motherboard. Does your design have a way around that? It would be nice to have a board that just plugs into the character ROM position, with a minimum of extra wiring (A8, A9, ????). Space is very tight under the keyboard, but the CPU area has more headroom. Perhaps a socket could be soldered on top of the CPU to plug an I/O board into, then read/write data and control signals sent from there to the character ROM board.

I've been thinking about this problem a lot since my first "SuperFont" experimentations about three years ago, and I've debated several different approaches. I thought for a long time about simply socketing the character ROM and designing a small plug-in daughterboard, as you suggest, but I moved away from that idea for two reasons: one, I'm not sure there is enough clearance inside the Aquarius case for a plug-in board in that area, and two, from the initial feedback that I received from Aquarius owners, desoldering chips is well beyond their level of comfort with a soldering iron.

 

What I'm considering now is an upgrade that does not require desoldering any chips, perhaps a small daughterboard that can be mounted on top of the RF modulator with adhesive tape. My current idea is to leave both the character and OS ROMs in place, but pull up the /OE pins and generate new signals for them on the new board, so that the character RAM and ROM can be toggled in software (with the ROM enabled by default on startup). This also avoids the need to change the OS to add the initial character data, since the original character ROM is still there.

 

The main disadvantage, as you say, is that it involves running a lot more wires: right now, I've got eight wires for the system data bus, another eight for the character RAM/ROM data, another twelve for the address bus, and a few extra wires for the character row pins, /ROM signal, /RD and /WR signals, etc. But, compared to desoldering chips, running a few extra wires is much less intimidating, and would also reduce the possibility of damaging the hardware during installation. By putting the board on top of the RF modulator (or inside its footprint, for those who choose to remove it), I should at least be able to keep the cable length to a minimum.

  • Like 2
Link to comment
Share on other sites

... but then again, to think aloud here for a moment ... if we were to make "SuperFont" into a plug-in replacement for the character ROM, it would leave the space above the RF modulator free for a dedicated RGB/Composite upgrade, while greatly reducing the number of wires to be installed. Leaving the two upgrades (RGB and "SuperFont") as separate boards might actually make for an easier installation overall than trying to combine them into one board, given how spread out the solder points are.

 

I should take some new measurements, to find out for certain if a plug-in module would be feasible.

  • Like 2
Link to comment
Share on other sites

I might have mentioned this idea before what about replicating the Aquarius output on an external cart with something like a 6845* or similar with ram and direct graphic output on the cart? I've been looking at the display systems of other retro systems, the colour genie for example was similar to the Aquarius in capability but used a 6845 and did allow reprogrammable graphics.

 

*or maybe even a parallax propeller

 

If we can get the building work finished at home I might finally have the space to play with some of these ideas :-D

Link to comment
Share on other sites

I might have mentioned this idea before what about replicating the Aquarius output on an external cart with something like a 6845* or similar with ram and direct graphic output on the cart? I've been looking at the display systems of other retro systems, the colour genie for example was similar to the Aquarius in capability but used a 6845 and did allow reprogrammable graphics.

 

*or maybe even a parallax propeller

 

If we can get the building work finished at home I might finally have the space to play with some of these ideas :-D

I rather like the upgrade to be more consistent with the official Aquarius itself. It's a pity we have never seen the alleged schematics how Mattel/Radofin intended to implement programmable graphics in the Aquarius II/III. http://atariage.com/forums/topic/208660-has-anybody-ever-see-these-aquarius-schematics/?hl=%2Bschematics&do=findComment&comment=2736341

Link to comment
Share on other sites

In my opinion Bruce and Jay are on the right track, to get programmable graphics on the Aquarius. Maybe they should team up to get the best possible solution :)

Thanks! Indirectly, I think we already have: "SuperFont" is an idea that I've been toying with for a long time, but I hadn't worked out all the implementation details, so Bruce's work on his own CG RAM design has given me lots of good ideas. There are still some specifics to be worked out (such as where to put it inside that cramped little machine!), but I don't think these will take long.

  • Like 3
Link to comment
Share on other sites

Of course it would be nice to have an affordable Aquarius + Mini Expander to add these goodies to :)

 

Note: When they do pop up on ebay they are usually at extortionate prices or look like they have been stored in a damp cellar for 20 years, that's not even considering the ebay sales of only the computer boxes :grin:

Link to comment
Share on other sites

Of course it would be nice to have an affordable Aquarius + Mini Expander to add these goodies to :)

 

Note: When they do pop up on ebay they are usually at extortionate prices or look like they have been stored in a damp cellar for 20 years, that's not even considering the ebay sales of only the computer boxes :grin:

I agree. When I first got into the Aquarius back in early 2010, not many people were interested in it outside of a small(er) community of devoted collectors, so they were still fairly plentiful and inexpensive. Since then, its profile has risen (I'm sure the Aquaricart had something to do with that), so the demand has gone up, and with it the prices. Mini Expanders in particular have become highly sought after, especially ones with good hand controllers, which is one reason I want to get my "Mini Expander II" project back on track next summer. I think it would be great to be able to offer new Mini Expanders to Aquarius owners who only have the stock computer to work with, and I have all kinds of ideas for new features to add to it, in addition to what the original Mini Expander had.

  • Like 2
Link to comment
Share on other sites

The problem that I see with using the CP/M bit to expose the character RAM for reading is that it drastically changes the Aquarius memory map,

There is a very simple solution to that problem. Simply cut the track going from PLA1 pin 44 to U15 (74LS86) and connect U15 pins 5 and 9 to ground, then CP/M mode is disabled and the I/O bit is available for other use. I did this because I wanted to get a control bit without having to add my own I/O port.

 

it drastically changes the Aquarius memory map, which would probably wreak havoc with cartridge-based software

 

CP/M mode inverts the memory map for internal RAM and ROM but doesn't change the cartridge address, so yes it would wreak havoc - which is why I figured that it is not worth retaining and re-purposing it would be safe.

 

I suspect that the I/O bit was originally designed for something else. Then somebody (at Mattel?) decided that the Aquarius needed CP/M compatibility, so an external circuit was added to reconfigure the memory map. This would explain why that external circuit was needed to swap A14 and A15, rather than using logic gates inside PLA1.

Link to comment
Share on other sites

I want to get my "Mini Expander II" project back on track next summer. I think it would be great to be able to offer new Mini Expanders to Aquarius owners who only have the stock computer to work with, and I have all kinds of ideas for new features to add to it, in addition to what the original Mini Expander had.

Good idea! I never liked the 'mini' expander because it stuck too far out the back of the computer, and added too little for the price.

 

I am building a 'micro' expander that combines 32k RAM, 128k ROM, an AY-3-8910 and joystick ports in the stock cartridge port area. There will be two boards, one stacked on top of the other. Here's what I have done so far...

 

micro-expander.jpg

  • Like 3
Link to comment
Share on other sites

... but then again, to think aloud here for a moment ... if we were to make "SuperFont" into a plug-in replacement for the character ROM, it would leave the space above the RF modulator free for a dedicated RGB/Composite upgrade, while greatly reducing the number of wires to be installed. Leaving the two upgrades (RGB and "SuperFont") as separate boards might actually make for an easier installation overall than trying to combine them into one board, given how spread out the solder points are.

 

I should take some new measurements, to find out for certain if a plug-in module would be feasible.

A plug-in board should fit fine so long as it uses all surface-mount components.

 

Some skill would be required to replace the character ROM with a socket, but it's a lot easier to do if the original ROM doesn't have to be preserved. Just cut all the pins off the chip with a knife or narrow side cutters, then unsolder them one by one.

 

I only removed my ROM intact because I wasn't sure if my circuit would work, so I might have had to put it back in. Although I could have just soldered my RAM on top of the ROM, I didn't want to because the ROM is quite power hungry (draws almost 100mA!) and I was worried that it might overheat with another chip on top of it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...