Aquarius 320x200 Bitmap Graphics Hack

[Aquaman]

 

#5: I'm going to be leaving the original OS ROM intact, but there are other alternatives for adding "SuperFont" functionality to BASIC. I could provide some inline assembly routines that the users can add to their programs (along with plenty of documentation!), or for those who would prefer to have additional BASIC statements to use, I could provide a modified Extended BASIC cartridge with the extra commands built in. Using inline assembly in BASIC will bypass the POKE restrictions, and will also be a lot faster than using POKE. Eventually, the new statements will be a part of the "Mini Expander II" Extended BASIC ROM, and since this will be field upgradeable, we'll have the option of adding more statements (for software sprites, etc) later.

 

Why not build the ME II Extended Basic version, by using and upgrading the BLBasic Rom, already made by Martin? Or better still, if memory space isn't an issue, take the 1541 V2 Extended Basic ROM+the new commands from Marin and in due course add some new statements like you suggested?

[jaybird3rd]

Why not build the ME II Extended Basic version, by using and upgrading the BLBasic Rom, already made by Martin? Or better still, if memory space isn't an issue, take the 1541 V2 Extended Basic ROM+the new commands from Marin and in due course add some new statements like you suggested?

The Mini Expander II Extended BASIC ROM will have a little bit of everything. I don't see why it couldn't include the functionality that Martin added with his BLBasic ROM (with his permission, of course), as well as the 1541 OS additions. I wouldn't be able to use those exact ROMs, however, because the Extended BASIC ROM will be in a different memory location ($2000-$2FFF) and will also be bankswitched. It shouldn't be a problem to refactor the code for the new statements into 2K banks, however, and we should still have lots of room left over for other cool stuff.

 

We also shouldn't have to worry about any conflicts with cartridge software, by the way, because the Aquarius OS will only attempt to use the Extended BASIC ROM extensions if a cartridge is not detected; if a cartridge is present, it takes priority, and the software in the cartridge can use the Extended BASIC ROM or ignore it completely as the programmer desires. It's a beautifully open-ended way of adding extensions to the original OS ROM, and it should create some exciting new possibilities for the Aquarius. I can even supply some sample code that others can use to create their own custom Extended BASIC ROM images if they want.

[Bruce Abbott]

This looks very promising! I hope to see some Aquarius generated pics very soon

Here you go...

[chjmartin2]

Here you go...

 

FANTASTIC!!!!!!!

[chjmartin2]

Dude - I want your Aquarius now - we can make it play video. We have the technology. It can be done.

 

So, let's see... We have 1 meg of RAM if we use Jay's largest cart. One frame of video is going to be 1024 characters and 256 attribute bytes so 1,280 bytes per frame. With 1 meg you get 819 frames. At 60 FPS we only get 13.7 seconds of video - still could do an amazing loop. I see the below from Algo and it inspires me because he optimized 8x8 blocks for the C64 and makes it REALLY small.

 

 

Anyway, I have found that the Aquarius really feels like it has a lot of cycles when you are running data on the ROM. We can get a throughput TO THE SPEAKER of >100 KHz. So, I wonder if we could do some type of intra-frame coding and use the blocks over and over. Need a codebook encoder, and a player. So, even if you only got 50% compression you are now at 26 seconds, if you reduced the frame rate then you could do better.

 

Ultimately the final cheevo, would be to run sound and video at the same time and flicker between subsequent frames. A friend of mine and I are working on a PC CGA demo that does just that. (But, to be honest, he did all of the coding work and I am a bit lax as I have multiple distractions and work long hours.) Anyway, you would run the video at 10 fps, but you would alternate between frames at 60 fps, so 20 fps of data per second. (Each "frame" needs two screens worth of data in order to get 4 colors per attribute cell - I will be giving you a preview of what that will look like.) If we created a code book of frames using an optimized set of TWO codebooks and encode the video from that, then we could get nice compression. (Each combination of "characters" becomes an option for use in a frame.)

 

These would be the steps if you wanted to venture there:

 

1. Get a Super Cart I from Jay and buy yourself a Batronix BX40 or better if you don't already have one.

2. First create assembler program to display the regular image, get everything right. (you are likely already done with that)

3. Create an encoder to play video using the current 320x200 with 2 colors per 8x8 cell.

4. Create an encoder of single frame flicker to get to a 320x200 with 4 colors per 8x8 cell from 136 combinations.

5. Create a player as described above.

 

Long journey. I have code for a bunch of it, but it would have to be modified to work on your new display. I never did get to the point where I used the Mini-expander to play digitized audio, that was a remaining task. Anyway, I have a bunch of part way done projects that I need to finish. So many retro-devices and so little time.

 

Chris

[Bruce Abbott]

Dude - I want your Aquarius now - we can make it play video. We have the technology. It can be done.

 

So, let's see... We have 1 meg of RAM if we use Jay's largest cart. One frame of video is going to be 1024 characters and 256 attribute bytes so 1,280 bytes per frame. With 1 meg you get 819 frames. At 60 FPS we only get 13.7 seconds of video - still could do an amazing loop.

A full 320x200 bitmap + color attributes uses 9000 bytes. Using the CPU to copy this data from main memory to the screen would give a maximum frame rate of about 20fps.

 

But we can do better. Since the CG RAM can be separated from the CPU bus, we could add a simple DMA controller which reads from main memory and writes to CG RAM in a single cycle, achieving up to 99fps. Of course we still need to copy the color attributes and generate sound, but 60fps should be easily achievable.

 

Another option might be to add an SD card slot which can be read into main memory or directly into the CG RAM. With Gigabytes of storage available you could have hours of video!

[chjmartin2]

An SD card? OMG - that's right - we already modded the computer - why not mod it more. Holy cow. SD Card slot - wow.

 

Gigabytes - drool. Full motion 60 fps video. Well. You need a lot of cycles to make good sound. If you can build an SD card reader - then we don't need Jay's board.

Edited January 10, 2015 by chjmartin2

[jaybird3rd]

I'm thinking along those lines, too! Having cartridges as large as 1MB is great for software, but if you're dealing with large volumes of data, you want something a little more open-ended that can also provide fast I/O. That's why I want to put an IDE controller in the Mini Expander II: being able to put a Flash module in there (something like one of these) would open up many such possibilities. That option seems "cleaner" to me than an SD card because, with a parallel interface, an IDE module would be much more efficient to control with only the Aquarius's Z80 processor, whereas an SD card would really require a microcontroller to handle the I/O (unless you want to access it serially through SPI, which would be much slower than IDE). I'd just like to avoid adding any more hardware to the Aquarius than necessary. There will be plenty of space in the Mini Expander II ROM for native FAT drivers, too, so we won't even need to come up with our own proprietary filesystem.

[Aquaman]

Here you go...

These screen shots look truly amazing!

[barnieg]

I'm thinking along those lines, too! Having cartridges as large as 1MB is great for software, but if you're dealing with large volumes of data, you want something a little more open-ended that can also provide fast I/O. That's why I want to put an IDE controller in the Mini Expander II: being able to put a Flash module in there (something like one of these) would open up many such possibilities. That option seems "cleaner" to me than an SD card because, with a parallel interface, an IDE module would be much more efficient to control with only the Aquarius's Z80 processor, whereas an SD card would really require a microcontroller to handle the I/O (unless you want to access it serially through SPI, which would be much slower than IDE). I'd just like to avoid adding any more hardware to the Aquarius than necessary. There will be plenty of space in the Mini Expander II ROM for native FAT drivers, too, so we won't even need to come up with our own proprietary filesystem.

 

 

Could a design like this be adapted to the Aquarius? Is the Z80 socketed?

 

http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/mass-storage-%28816-bit-ide%29-for-cpc4646128-project/

[jaybird3rd]

Could a design like this be adapted to the Aquarius? Is the Z80 socketed?

 

http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/mass-storage-%28816-bit-ide%29-for-cpc4646128-project/

It would almost certainly be very similar to that. An IDE controller is relatively simple to build: the MyIDE interface for the Atari 8-bit computers, for example, is only a few extra chips; I built one inside my XEGS by piggybacking them onto the existing chips. All the necessary signals are on the Aquarius cartridge port, so it should be possible to fit one inside the Mini Expander II, without having to socket the processor. A true Plug-and-Play design! One could even use CF cards with this design instead of a permanent Flash module.

[chjmartin2]

It would almost certainly be very similar to that. An IDE controller is relatively simple to build: the MyIDE interface for the Atari 8-bit computers, for example, is only a few extra chips; I built one inside my XEGS by piggybacking them onto the existing chips. All the necessary signals are on the Aquarius cartridge port, so it should be possible to fit one inside the Mini Expander II, without having to socket the processor. A true Plug-and-Play design! One could even use CF cards with this design instead of a permanent Flash module.

 

Finish!

[jaybird3rd]

Finish!

I'm trying, I really am!

 

The beginning of the semester is always a very hectic time for me, but I should have enough leisure time soon to finish the SuperFont upgrade and Bruce's RBG/Composite upgrade. Once those are finished (before this summer, I hope), I'll get back to work on the Mini Expander II. I've got the board measured out, and I have an offboard Mini Expander II ROM cartridge working, so at least part of it is finished.

[Bruce Abbott]

an SD card would really require a microcontroller to handle the I/O (unless you want to access it serially through SPI, which would be much slower than IDE).

A high speed parallel SPI interface should be quite simple to implement with standard logic. If I can get that to work then a small MCU or CPLD will do the job. I am going to try it because I want a solution that is small, cheap, and easy to transfer data from a PC.

[jaybird3rd]

A high speed parallel SPI interface should be quite simple to implement with standard logic. If I can get that to work then a small MCU or CPLD will do the job. I am going to try it because I want a solution that is small, cheap, and easy to transfer data from a PC.

Interesting! I'll be curious to see how it works out. I figured that an SD card would still be an option, even with an IDE port, through a bridge adapter like this (which would also give the users the option of mounting it outside the case if they want). Perhaps that would be an option for your own use, too, since it looks like this adapter already does what you're wanting to do with your interface.

 

I suppose another reason I shied away from standardizing on an SD card, at least for the Mini Expander II, is because of the long-term compatibility problems I've seen with other SD-based devices for vintage systems. Certain multi-carts (such as the Cuttle Cart 2 and Cuttle Cart 3) were designed for the latest versions of the SD and MMC standards at the time they were made, but of course the standards changed, and users eventually had to resort to scrounging around for old cards in certain sizes from certain vendors in order to find compatible media. I didn't want my users to have to do the same thing a few years down the road. I know the IDE interface is getting pretty long in the tooth, too, but it's easy to implement and seemed like a more universal option: you can use it with a hard drive, or a flash module, or a CF or SD card with the right adapters.

[Bruce Abbott]

I wasn't happy with the mess of wires inside my Aquarius, so I ripped out the 'dead bug' circuit and put the chips on a plug-in card. I also redesigned the circuit to map over color attribute RAM (at $3400~$37FF) instead of over the system ROM. This has reduced the number of chips from 7 to 5, and the number of wires going to the motherboard from 27 to 11. Now I can easily return my Aquarius to stock operation by simply unplugging the PCG card, inserting a 2 pin jumper into the wiring connector, and plugging the original character ROM back into its socket.

 

This version uses the 'CP/M' I/O bit (port $fd, bit 0) to access the PCG RAM. In comparison to the old circuit which simply wrote to the ROM, this has the advantage of being immune to buggy programs that write to low addresses. One disadvantage is that you can't access PCG RAM directly from BASIC (since it doesn't have any I/O port commands). However it only takes a few bytes of machine code to turn on the bit. Once the CP/M bit has been turned on the PCG RAM can be accessed with normal POKE commands (just have to remember to turn it off again before trying to change character colors!).

 

Currently this new design has the same functionality as the previous one. However you may notice an extra 74HC374 on the board that isn't in the circuit diagram. This will be used to switch between up to four 320x200 bitmap screens, turn the 320x200 mode on and off, or switch in an EPROM with up to 32 character sets in it. Unfortunately there isn't room to install an EPROM on the card and still get the keyboard to go down over it, so after I have proved that it works I will have to design a surface mount pcb to replace it.

 

Without a ROM on board I still have to use an extended 12k system ROM to load the stock character set into PCG RAM. Once I get an EPROM onto the PCG card this won't be necessary, but since the extra 4k of system ROM could be handy for other things I will keep it. I have simplified the system ROM expansion circuit so it now only needs one chip instead of two. This is still wired up 'dead bug' style because there only 3 wires going to it and it's not worth making another pcb just for one 14 pin chip!

 

[jaybird3rd]

Nice! The idea of putting the character RAM "underneath" the color matrix is an interesting alternative to using the OS space, and it also avoids the need to generate a new CE signal for the OS ROM.

 

I've been working on my prototype some more, too, and I've also gravitated more toward using an I/O port for control. One of the main reasons is that, using a write-only memory-mapped interface, there's no way to detect the presence of the upgrade in software! I'd like my games to automatically enable the upgrade if it is present, or fall back on the built-in character set if it is not, just by checking the control port. I probably won't use $FD for this—the Aquarius already uses it for the VSYNC signal—so I'll have to choose another unused port address (there are plenty to choose from). Your use of a '374 to bankswitch the CG ROM and RAM is very similar to what I'm doing with my design.

 

I just wish that the inside of the Aquarius wasn't so cramped! I'm reluctant to design my board to overlap the RAM chips, since these are socketed in several Aquarius computers I've opened. Inbetween other tasks, I've also been putting together some new character sets for my 32K character ROM. BASIC programmers will be able to create their own sets, of course, but I've managed to put together a nice collection of characters that everyone can use as a starting point.

[Bruce Abbott]

 

Your use of a '374 to bankswitch the CG ROM and RAM is very similar to what I'm doing with my design.

 

 

I only used a '374 because I have some on hand. In the final design it will be a '273, which has a reset pin for clearing it on power up.

 

The latest circuit diagram and board layout are attached. Note that it is not quite finished (still have to add a few bypass caps and thicken up the power rails in some places). I think the the layout is good but there are a lot of vias on it - might turn out a bit more expensive than I wanted. I spent most of today trying to work out how to do it with an MCU (using its internal RAM/ROM and serial I/O) but that has it own problems. Perhaps a CPLD will be the answer (thinking XC9536). OTOH I might just enlarge the board so it isn't so cramped, and perhaps reorient it to clear socketed RAM chips.

32k PCG eagle cad.zip

[Bruce Abbott]

 

I spent most of today trying to work out how to do it with an MCU (using its internal RAM/ROM and serial I/O) but that has it own problems. Perhaps a CPLD will be the answer

Well I bought a bunch of different MCUs and CPLDs, agonized over which might do the job best, and finally settled on one to try out. I selected the ATmega1284 because it has plenty of ROM (128k), enough RAM (16k), and runs on 5V (so no regulators or level shifters required). To get a bit more speed I overclocked it from 20MHz to 25MHz. Timing is extremely tight, but it works!

 

My original idea was to control it via a serial port, using either the stock Aquarius printer port or bitbanging the CPM bit. With this setup I would only need ONE chip! However a serial port is bound to be slower than direct memory access, and I liked the idea of being able to POKE it from BASIC. So I added a 74HCT688 which addresses the Atmega in the last 16 bytes of color RAM (normally free because the display only uses the first 1000 bytes out of 1024). That's still only TWO chips, compared to the 7 chips in my earlier version.

 

The firmware isn't quite finished yet (need to add character set selection and bitmap mode) but I have attached the current source code in case anybody wants to see how it works. The prototpe is very bulky because I mounted the MCU on an adapter board. Once the circuit is finalized I will design a much smaller board with all smd parts. It will feature an ISP header for flashing the MCU using a USBasp or similar AVR programmer.

PCG_asm.zip

Edited May 20, 2015 by Bruce Abbott

[Aquaman]

I'm trying, I really am!

 

The beginning of the semester is always a very hectic time for me, but I should have enough leisure time soon to finish the SuperFont upgrade and Bruce's RBG/Composite upgrade. Once those are finished (before this summer, I hope), I'll get back to work on the Mini Expander II. I've got the board measured out, and I have an offboard Mini Expander II ROM cartridge working, so at least part of it is finished.

I just hope that your new job doesn't mean that you have even less spare time to spend on your hobbies?

[jaybird3rd]

Glad to see you back, Bruce! Thanks for the update!

 

I just hope that your new job doesn't mean that you have even less spare time to spend on your hobbies?

Don't worry, if something is important enough, I make the time! I'll have some updates of my own to share shortly.

[chjmartin2]

Well I bought a bunch of different MCUs and CPLDs, agonized over which might do the job best, and finally settled on one to try out. I selected the ATmega1284 because it has plenty of ROM (128k), enough RAM (16k), and runs on 5V (so no regulators or level shifters required). To get a bit more speed I overclocked it from 20MHz to 25MHz. Timing is extremely tight, but it works!

 

My original idea was to control it via a serial port, using either the stock Aquarius printer port or bitbanging the CPM bit. With this setup I would only need ONE chip! However a serial port is bound to be slower than direct memory access, and I liked the idea of being able to POKE it from BASIC. So I added a 74HCT688 which addresses the Atmega in the last 16 bytes of color RAM (normally free because the display only uses the first 1000 bytes out of 1024). That's still only TWO chips, compared to the 7 chips in my earlier version.

 

The firmware isn't quite finished yet (need to add character set selection and bitmap mode) but I have attached the current source code in case anybody wants to see how it works. The prototpe is very bulky because I mounted the MCU on an adapter board. Once the circuit is finalized I will design a much smaller board with all smd parts. It will feature an ISP header for flashing the MCU using a USBasp or similar AVR programmer.

 

 

I finally saw this. Wow - ok - so help me understand what the upgrade will enable and how it will be controlled. We have 1 Meg of space with Jay's card and 4 screens of 320x200 bitmap data? How quickly can the updates be done? Can we update an entire frame in faster than the raster beam trace? What are the total degrees of freedom?

[Bruce Abbott]

 

 

I finally saw this. Wow - ok - so help me understand what the upgrade will enable and how it will be controlled. We have 1 Meg of space with Jay's card and 4 screens of 320x200 bitmap data? How quickly can the updates be done? Can we update an entire frame in faster than the raster beam trace? What are the total degrees of freedom?

It is accessed through 16 bytes of memory shared with the video RAM at $37F0-FF. These locations are effectively write-only registers that do things like setting the screen mode, selecting a character set, and loading pattern data into it. In 320x200 mode you first select character set 0, select the starting character number (usually 0), then write consecutive bytes to the pattern register until every character has been defined (256 characters = 2048 bytes). The second, third and fourth character sets are loaded in the same way.

 

In my current design only one 320x200 bitmap screen is available (this could possibly be stretched to 2 screens). Theoretically it can be updated at a rate of one byte per VRAM cycle (1.12us) giving a frame time of just over 10ms. However this speed can only be achieved using DMA from an external device. Using the Z80 CPU to move data from main memory would take ~5.6ms per byte (50ms per frame). Even at this lower speed it should be possible to get smooth 15fps video with sound.

 

The main reason I went for an MCU was to reduce the number of chips and get the price down. Secondary purpose was for greater flexibility and ease of adding extra functions. The ATmega1284 does the job, but has barely enough horsepower. I have just received an STM32F103C8 board for evaluation, hoping it will have better performance - perhaps enough to do full speed DMA from an on board SD card (then the Z80 only has to handle color and sound when playing video). Downside of the STM32 is that it needs a 3.3V regulator and some level translators (unfortunately not all pins are 5V tolerant!).

 

Here is my PCB design for the Atmega1284. The board is around 3" x 1". Once I have proved that all the software works reliably and the PCB layout is correct I will get a few boards made.

[barnieg]

Hi Bruce,

 

Any chance you will produce any of these micro expanders or schematics for a self build?

 

Regarding the joystick ports, do the take standard atari type?

 

thanks

Barnie

 

 

 

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...

 

[jaybird3rd]

Hi Bruce,

 

Any chance you will produce any of these micro expanders or schematics for a self build?

 

Regarding the joystick ports, do the take standard atari type?

 

thanks

Barnie

I don't know what Bruce's plans are, but I'm doing the board layout now for an internal Mini Expander upgrade. Things have gotten busy for me yet again (GAH!), but I'll post an update as soon as I get and test my first prototypes.

 

The Aquarius hand controller ports aren't directly compatible with an Atari joystick, but it is possible to build a very simple adapter which will give you all eight directions plus the first action button (I posted a wiring diagram in another thread).