Jump to content
IGNORED

[AQUARIUS] Using the SuperCart I Cartridge Board


jaybird3rd

Recommended Posts

SuperCartI_back.jpg

 

Since there is an increasing interest in programming for the Aquarius, I thought it would be useful to post some technical information about the Aquarius cartridge board that I designed for my Aquaricart project, the SuperCart I.  The SuperCart I board is a completed and tested design, and it is available to any Aquarius programmers who are interested in using it for their own projects.  This thread describes how to use the bankswitching functionality of the SuperCart I to create Aquarius cartridges of up to a megabyte in size, far larger than the Aquarius's original 16K limitation.

 

(EDIT: The SuperCart I design has since been revised to fit the new Intellivision-style cartridge shells I am now using instead of Mattel's original Aquarius cartridges.  The changes are only to the physical layout, and to a few of the jumpers; the programming information given here is still applicable.  A successor, the SuperCart II, is currently in the works; this will be discussed in a separate thread.)

 

The SuperCart I uses standard EPROM memory, from 32K (a 27C256 EPROM) to 1024K (a 27C080 or 27C801 EPROM), and discrete logic chips.  This may be a somewhat old-fashioned solution in the age of flash and programmable logic, but I had my reasons: this was my first hardware design project and I wanted to keep it as simple and as inexpensive as possible, and I also wanted to make it possible for any Aquarius hobbyists to build their own cartridges using off-the-shelf components.  Besides the core components of the SuperCart I (listed below), all that is required is a standard EPROM programmer and the EPROMs themselves; these can be readily obtained, new or used.

 

I've broken this documentation into several posts, corresponding to its major sections, to make it easier to read and respond to.

  • Like 1
Link to comment
Share on other sites

AquariusMemoryMap.png

 

Cartridge Software on the Aquarius

 

The Aquarius memory map (shown above) reserves a total of 16K for the cartridge, from $C000 to $FFFF.

 

From the programmer's point of view, it is useful to think of this space as two contiguous 8K banks: the last/uppermost 8K bank, from $E000 to $FFFF, is where execution of the cartridge ROM begins.  In the original Aquarius cartridges that were 8K or less, this is the only bank that was used.

 

The first/lowermost 8K bank, from $C000 to $DFFF, could be used for extra code or data by cartridges that needed it.  AD&D Treasure of Tarmin was a 12K cartridge, so it used 4K of this space; most of the later releases used 8K, for a combined total of 16K of ROM.  These cartridges contained two ROM chips, one for each bank, along with some glue logic which made these chips appear to the Aquarius as a single ROM.

 

The process of booting from the cartridge begins at address $E000.  The OS looks for a valid 16-byte cartridge header at this address.  If it finds one, it begins executing the cartridge code immediately after it, at address $E010; if it does not, it aborts and falls back on the built-in BASIC interpreter.

Link to comment
Share on other sites

Using the SuperCart I

The SuperCart I supports ROM sizes from 32K up to 1024K (one megabyte).  It banks the ROM into the available 16K cartridge space in one of two ways, depending on which bankswitching mode is selected.  In both modes, the cartridge ROM is divided into banks of 8K each.  Depending on the selected mode, the programmer can swap one or two of these banks at a time in or out of the cartridge space as desired.

To use bankswitching, the programmer specifies the target bank number.  This number can be from 0 to a maximum of 127, depending on the size of the ROM.  The bank number is then written into a valid address within the cartridge space to perform the switch.  (For future compatibility with the SuperCart II, only addresses from $E000 and up should be used for bankswitching, to leave the lower bank available for writable memory.)

For example, if Bank 0 is to be selected, the programmer can use the following routine:

ld de,$e000    ; load the target address into register DE
ld a,$00       ; load the target bank number into the accumulator
ld (de),a      ; write the bank number into the cartridge space
jp nextaddress ; continue

The SuperCart hardware will detect this write attempt and will latch the bank number, selecting the corresponding bank within the ROM.  This bank then appears within the switchable region, where it can be accessed by the programmer like any other region of memory.

There are certain restrictions that are unique to each mode, as described below.

8K Mode

This mode splits the 16K cartridge space into one fixed region (from $E000 to $FFFF, the "primary" bank in memory) and one switchable region (from $C000 to $DFFF, the "secondary" bank in memory).  The fixed region always maps to the last/uppermost 8K bank in the ROM, but the programmer can map any of the 8K banks into the switchable region by selecting the bank number, as described above.

The advantage of this mode is that it establishes a permanently fixed region of memory, in which the startup code and other code or data can be stored.  The switchable region can then be used for additional ROM banks, or even writable memory, which can be swapped in and out as the application requires.  If more than 8K of code or data is needed at one time, it can be copied into RAM (provided enough RAM is available) from one of the other banks.

16K Mode

In this mode, the entire 16K is configured as a switchable region, with no fixed regions at all.  The programmer can select any contiguous pair of 8K banks; in other words, for every selected pair of ROM banks, the even-numbered bank is mapped to $C000-$DFFF, and the odd-numbered bank is mapped to $E000-$FFFF.  The least significant bit (Bit 0) of the bank number is ignored in this mode when the bank is selected.  For example, selecting Bank 0 or Bank 1 will have the same effect: Bank 0 will appear at $C000-$DFFF, and Bank 1 will appear at $E000-$FFFF.

This mode was implemented mainly for the Aquaricart, since several original Aquarius cartridges required a full 16K.  It has the advantage of a larger switchable region, allowing twice the amount of ROM to be banked in and out at one time.  However, since there is no permanently fixed region, any switching initiated from code in the cartridge space will cause the contents of this space to change, and the program may jump into garbage and crash.  The usual solution is to copy this code into RAM, so that bank switches can always be performed from a fixed location.  This "trampoline code" can be as short as the subroutine described above.

 

(There was also a "lockout feature" for disabling subsequent bank switches.  This was intended to support original Aquarius cartridge software which performed "wild writes" into the cartridge space, but this was later deemed unnecessary; instead, these cartridge images were patched for the Aquaricart.  So, if you're using a SuperCart for your own projects, simply join pins 2-3 of W10 to disable this feature.  This feature was removed from subsequent versions of the SuperCart design, so this is only an issue with the original SuperCart I.)

Link to comment
Share on other sites

supercart_populated.jpg

Configuring the SuperCart I

To configure the SuperCart I, it is necessary to set a series of jumpers to select the ROM size and the desired bankswitching mode. These are SMD solder jumpers, so to set them, you must use a soldering iron to add a bit of solder to the pads you wish to bridge, and then a little extra solder to connect them.

Here is a description of each of the jumper groups:


w1.jpg

W1: 28-Pin / 32-Pin

Jumper W1 is used to connect Pin 30 of the EPROM footprint either to A17 (for 32-pin devices) or to VCC (for 28-pin devices). This allows either a 28-pin or a 32-pin device to be installed in this footprint.

1-2: 28-Pin Devices (Pin 30 to VCC)
2-3: 32-Pin Devices (Pin 30 to A17)


w2-w3.jpg

W2-W3: Bankswitching Mode

W2 and W3 are used to specify the bankswitching mode. Both jumpers must be set together.

1-2: 16K Bankswitching Mode
2-3: 8K Bankswitching Mode


w4-w9.jpg

W4-W9: ROM Size

W4 through W9 are connected to the top address lines, A14 through A19. Any jumpers corresponding to the address lines used by the EPROM must be closed.

Here is a list of the supported EPROM sizes, and the corresponding jumper(s) that must be closed for each size:

SIZE         EPROM           JUMPER(S) CLOSED
==============================================
32K          27C256          W4
64K          27C512          W4,W5
128K         27C010          W4,W5,W6
256K         27C020          W4,W5,W6,W7
512K         27C040          W4,W5,W6,W7,W8
1024K (1M)   27C080/27C801   W4,W5,W6,W7,W8,W9

 

w10.jpg

W10: Lockout Chip Enable/Disable

(Since the "lockout" functionality was phased out of the SuperCart design, this jumper should always be set to 2-3.)


A "summary" of these jumper settings is silkscreened onto the top side of the board, inside the EPROM footprint, for easy reference:

supercart_top.jpg

 

Link to comment
Share on other sites

Emulator Support and Bankswitching Mode Detection

The idea of bankswitching is not new, nor is it difficult.  But since bankswitching is new to the Aquarius, no existing Aquarius emulators presently support it.  I'm hopeful that this will change in the near future, as this will greatly assist the development of new Aquarius cartridge software.  At present, the only way to test this software is to burn it to an EPROM for testing on the real hardware.  (EDIT: Starting with version 0.227, SuperCart emulation has since been added to MAME.)

One step toward this goal would be to provide a way for an emulator to automatically detect which of the two bankswitching modes is required for a particular cartridge ROM.  (This has been a problem with other classic platforms which had bankswitched cartridges: Atari 800 emulators, for example, must prompt the user to select the correct bankswitching scheme when a cartridge image larger than 16K is loaded, unless a cartridge header has been added to the image.)

The Aquarius cartridge format already includes a 16-byte header, which is validated by the OS on startup.  So, one approach is to use this existing header as a bankswitching mode identifier.  As part of the SuperCart standard, I'd like to establish a universal set of cartridge headers, one corresponding to each of the modes described above, that all programmers working with the SuperCart can use.  To detect the bankswitching mode, an emulator could simply check for these headers in the first 16 bytes of the cartridge when the image is loaded: the "8K header" would enable 8K mode, the "16K header" would enable 16K mode, and any other header would disable bankswitching altogether to preserve backward-compatibility with the original cartridges.

I'm in the process of writing a program to generate valid Aquarius cartridge headers, and once this is done, I'll create a set of headers and add them to this document. These will then be the cartridge headers that all SuperCart software should use.

EDIT: Thanks to Martin's assistance, I have created the set of cartridge headers. See below.

Link to comment
Share on other sites

I'm in the process of writing a program to generate valid Aquarius cartridge signatures

 

I used to do this with an Excel sheet. I have translated into English and added some colors.

I have also added an second sheet with all the known ROMS and their scramble codes.

You will need the Analysis toolpack add-in and have the Macros enabled because of an user defined function that I have created to do XOR calculations.

The Analysis toolpack add-in is standard with Excel 2003, but not always installed.

 

xOr-byte.xls

 

Regs,

Martin

  • Like 1
Link to comment
Share on other sites

Using the SuperCart 8K/16K Headers

 

Here are the SuperCart headers, which I created using Martin's tool. The first five bytes/characters of each header identify the corresponding bankswitching mode: "SC08K" is the 8K mode header, and "SC16K" is the 16K mode header ("SC" stands for "SuperCart"). Both of these headers use a scramble code of zero, so no scrambling of the cartridge data is required; just assemble your code/data and add the header to the last 8K bank, as described below. I have also placed the headers inside separate files (see the attached archive).

 

8K Mode Header:

53 43 30 38 4B 9C B5 B0 A8 6C AC 64 CC A8 06 70
 

16K Mode Header:

53 43 31 36 4B 9C B5 B0 A8 6C AC 64 CC A8 08 70
 

Use the sixteen-byte header corresponding to the bankswitching mode your program requires, so that Aquarius emulators will be able to detect the mode correctly; none of them presently support bankswitching, but when they do, they will need this information if your program is to work in the emulator. These sixteen bytes should be at the beginning of the last 8K bank in your cartridge binary.

 

For example, if you are creating a 32K cartridge which uses 8K bankswitching mode, you will have one fixed 8K bank and three 8K switchable banks; the switchable banks are numbered 0, 1, and 2. To create the 32K binary you would burn to the EPROM, follow these steps:

 

  1. Set $E000 as the base address, and add the header bytes as data to the beginning of your source file.  In this example, the assembled 8K binary file name is "FIXED.BIN".
  2. Prepare the other 8K banks of your program.  The header does not need to be added to these banks. (Note that, if these banks are to contain code as well as data, the code should be assembled with $C000 as the base address, since this is the first available address within the switchable bank.)
  3. Concatenate all of the banks together at the command line, placing the fixed bank last:
    COPY /B SWITCH0.BIN+SWITCH1.BIN+SWITCH2.BIN+FIXED.BIN 32KROM.BIN
     

In this example, the resulting file should be exactly 32K in size.

 

SuperCartHeaders.zip

Link to comment
Share on other sites

  • 4 weeks later...

I used my Supercart I for the first time today. I bought myself what I believe to be, a good EPROM programmer.

 

http://www.progshop.com/shop/programmer/BX40/index.html

 

Then I went ahead and decided to encode some two flicker graphics, to see which one would be the best first try.

 

7thgues.binhobbit.binpicard.binSIMPSONS.binsqtitle.bin

 

Of course, I had to use the picture of Mario and Sonic on the same screen.

 

sonicmar.bin

 

I went ahead and made my standard file, then I used a Hex editor to put the proper 8k header on it. (My program puts a header on the file inside the ASM code.) Anyway, after I changed the file, then I added 00's to the end of it until it was exactly 8192 bytes. Then I went ahead and created a file that is all zeros that is 64k-8k (65,536 - 8192 bytes) or 56k - duh. And then I copied the file using the /b in front of the program code that I made exactly 8192 bytes. Now I had a 64k file!

 

SONIC64K.BIN

 

So I burned the file to a 64K EPROM. (27C512) Luckily, and I think it is because I checked before I bought it, I had exactly the right EPROM for one of the boards that Jay configured for me. I used 8k switching, and that was set correctly as well.

 

Here it is on a real aquarius. I accidentally bought OTP chips, but I have some UV ones coming in.

 

I am not sure what to do next. If I had a 1 MEG Rom, then I could write a graphics viewer and fill it up with images, like a LOT of images - enough to get a feel for anything the Aquarius could do. Problem is that I'd have to write a loader, and put together a program with the image names and the memory location. If I had an emulator that supported bank switching, then I could develop it.

 

Lastly, my programmer wrote the ROM in like 4 seconds. I need to buy a lot of EPROMS, so that I can develop and then UV them when done for the night.

 

Not sure what to do next with the 'ol Aquarius...

 

Emulator Output:

 

post-20571-129999020912_thumb.jpg

 

On the real thing:

 

post-20571-129998951443_thumb.jpg

 

Looking at it closely, for some reasons I am getting the wrong Characters on the actual Aquarius - so now that's a mystery to me.

Edited by chjmartin2
Link to comment
Share on other sites

That looks great! I'm glad to see the cartridge boards are working for you. I'll try it on mine within the next few days; it will be nice to see one of your demos "in motion" on the real hardware!

 

For your next test, I would suggest a keyboard-driven "slideshow cartridge" (there are keyboard routines available in the Aquarius OS ROM, so you won't have to write those yourself). You could put the display routines in the fixed region ($E000-$FFFF) and the image data in the switchable region ($C000-$DFFF); with each keystroke, you would clear the screen, switch banks, and display the new image. If you test this in Virtual Aquarius, it will just keep displaying the same image over and over again (since it's not implementing the bankswitching), but it should work on the real hardware. Just remember to "initialize" the bankswitching hardware by switching it to the first valid image bank before you try to display anything, since both regions will be mapped to the fixed bank on startup!

 

It would indeed be very convenient to have bankswitching support in the emulators. Unfortunately, the only Aquarius emulator that seems to be actively maintained anymore is the Aquarius driver in MESS, and I don't know what would be involved in adding bankswitching support (I should contact the author to find out). It would also be nice to be able to download the code to a real Aquarius for testing without having to burn an EPROM, but that raises two immediate problems: there's no built-in bidirectional interface to the Aquarius (the cassette port doesn't count; it's way too slow), and there's nowhere in the Aquarius to store the code.

 

I'm thinking of building a simple battery-backed SRAM cartridge, somewhat like the DevOS RAM cartridges for the 7800, for those few of us who are interested in developing for the Aquarius. This would be a useful stop-gap solution until I add that functionality to the flash cartridge that I ultimately have in mind. As for the interface, I'm thinking of using the hand controller ports in the Mini-Expander as parallel I/O ports, and connecting them to a USB bridge chip to create an interface to the PC (this would actually be part of a more elaborate I/O board that would allow you to connect Atari joysticks and paddles to the Mini-Expander as well).

Link to comment
Share on other sites

That looks great! I'm glad to see the cartridge boards are working for you. I'll try it on mine within the next few days; it will be nice to see one of your demos "in motion" on the real hardware!

 

For your next test, I would suggest a keyboard-driven "slideshow cartridge" (there are keyboard routines available in the Aquarius OS ROM, so you won't have to write those yourself). You could put the display routines in the fixed region ($E000-$FFFF) and the image data in the switchable region ($C000-$DFFF); with each keystroke, you would clear the screen, switch banks, and display the new image. If you test this in Virtual Aquarius, it will just keep displaying the same image over and over again (since it's not implementing the bankswitching), but it should work on the real hardware. Just remember to "initialize" the bankswitching hardware by switching it to the first valid image bank before you try to display anything, since both regions will be mapped to the fixed bank on startup!

 

It would indeed be very convenient to have bankswitching support in the emulators. Unfortunately, the only Aquarius emulator that seems to be actively maintained anymore is the Aquarius driver in MESS, and I don't know what would be involved in adding bankswitching support (I should contact the author to find out). It would also be nice to be able to download the code to a real Aquarius for testing without having to burn an EPROM, but that raises two immediate problems: there's no built-in bidirectional interface to the Aquarius (the cassette port doesn't count; it's way too slow), and there's nowhere in the Aquarius to store the code.

 

I'm thinking of building a simple battery-backed SRAM cartridge, somewhat like the DevOS RAM cartridges for the 7800, for those few of us who are interested in developing for the Aquarius. This would be a useful stop-gap solution until I add that functionality to the flash cartridge that I ultimately have in mind. As for the interface, I'm thinking of using the hand controller ports in the Mini-Expander as parallel I/O ports, and connecting them to a USB bridge chip to create an interface to the PC (this would actually be part of a more elaborate I/O board that would allow you to connect Atari joysticks and paddles to the Mini-Expander as well).

 

A slideshow cart would be awesome. I need to debug the picture I showed first, because clearly there are characters that shouldn't even be there. It is very similar to the errors I had when I first tried to do the flicker on the emulator. I figure that if I had an 8k bank mode on a 1 meg chip then I could have 128 triflicker images or 256 flicker images or 512 static images. I could add a few animations. I think I would use 16k mode, because I would like to have 16k for the program. I'm not sure if I want to put the time into that though, as I'd have to learn how to read keyboard commands, then create a selection menu, store the bank and memory location of each graphic and the size (build a file allocation table or sorts) and then store four loaders (static, biflicker, triflicker and animation.) Not sure anybody would want a cart like that... but First - DEBUG THE FLICKER!

Link to comment
Share on other sites

A slideshow cart would be awesome. I need to debug the picture I showed first, because clearly there are characters that shouldn't even be there. It is very similar to the errors I had when I first tried to do the flicker on the emulator. I figure that if I had an 8k bank mode on a 1 meg chip then I could have 128 triflicker images or 256 flicker images or 512 static images. I could add a few animations. I think I would use 16k mode, because I would like to have 16k for the program. I'm not sure if I want to put the time into that though, as I'd have to learn how to read keyboard commands, then create a selection menu, store the bank and memory location of each graphic and the size (build a file allocation table or sorts) and then store four loaders (static, biflicker, triflicker and animation.) Not sure anybody would want a cart like that... but First - DEBUG THE FLICKER!

Well, remember that with 16K mode, the entire cartridge space is banked out, so there is no fixed region at all. You'd have to put the loader in the exact same place inside every pair of 8K banks, unless you copy it into RAM first and run it from there (which would require expanded RAM if the code is larger than ~1.7K). That's not an insuperable problem, to be sure, but it does mean that there will be a lot of duplication of code in the cartridge, and it will reduce the amount of space that is available for your data.

 

Once you get the bugs worked out, it would probably be a good idea to refactor the code a little bit: separate the code from the data if you haven't already done so (so you can have swappable data banks that are independent of the program code), and create one loader with multiple modes (static, biflicker, triflicker, etc.) instead of having to have a separate loader for each mode.

 

For the Aquaricart project, for example, I created a simple format for static screen data consisting of plain text (which is printed to the screen directly), followed by a list of "color points" (three bytes each) and "color vectors" (five bytes each regardless of length) which are then painted into the color matrix. This is the format I used to create the on-screen manuals, trivia, and other static screens, and it allowed me to exactly recreate the in-game graphics inside the manuals by building screens with multiple colors, using the same special characters that the games use. I added headers and other metadata to identify the format so that, if I ever needed to add different data types to the viewer, I could do so without touching the code for the format I was already using. The viewer code is currently 600 bytes long (including the routines for controlling it with the keyboard and hand controllers), so I was able to copy it entirely into RAM and use the full 16K in each pair of banks for the screen data.

Link to comment
Share on other sites

post-20571-130015930595_thumb.jpg

 

So I went ahead and decided to test out a theory. When I first did the Flicker demonstration program, it showed defects on the emulator, but not on the real Aquarius. The program was small enough that I could make a basic program, store the machine language in data statements and write a loader. Anyway, the flicker demo showed NO defects on the real Aquarius. Now, on the emulator, my first stab at creating a flicker screen resulted in some garbage characters that were flip flopped from one screen to the next. So, of course, I just had to try my original flickering code to see what would happen. Sure enough, the image got BETTER but still had garbage at the very top of the screen. What I am nervous about is that I don't have enough cycles to load the screen and then flicker to the next. I have no idea how many CPU cycles a screen refresh takes AND how many cycles it is between the Vertical Sync going high, then going low and then going high again - ugh. But, now I know that it has something to do with how I am waiting for the VSync - I may try to not wait for it at all and see what happens that way, but then I will get a defect somewhere else. If I added a user controllable pause, then I could set the time between frame refreshes rather than trying to use the Vsync, but that would require reading the Keyboard (more cycles) and how would I get the pause cycle count back unless I displayed it - also more cycles.

 

I also had a development idea. I don't like the idea of writing programs and then having to erase ROMs, etc, etc. I want to write then rewrite and develop - so... the solution... EEPROM. It just so happens that there is an EEPROM that is pin compatible with a 27C512...

 

http://www.icsupply.com/itemdetail.asp?id=B5D8CB11-08C5-48ED-A4F1-CB58FE5C5EB9

 

I wonder if I used one of these and programmed it, would it work in the Supercart I. Is it worth trying?!

Link to comment
Share on other sites

I also had a development idea. I don't like the idea of writing programs and then having to erase ROMs, etc, etc. I want to write then rewrite and develop - so... the solution... EEPROM. It just so happens that there is an EEPROM that is pin compatible with a 27C512...

 

http://www.icsupply.com/itemdetail.asp?id=B5D8CB11-08C5-48ED-A4F1-CB58FE5C5EB9

 

I wonder if I used one of these and programmed it, would it work in the Supercart I. Is it worth trying?!

If it's pin-compatible with a 27C512, it should work, but be sure that you get the right type: the part you linked to is an SMD (surface-mounted) chip, while the SuperCart I is designed for DIP (dual in-line package) chips. This is the through-hole mounted design used by traditional EPROM chips. I don't know whether the chip you're looking for is available in a DIP package or not, but I suppose you could use an SMD chip if you mounted it on a bridge board.

 

I designed the SuperCart I board for DIP chips because they're much easier to install by hand, and because I had a pile of EPROMs that I wanted to be able to use (and if I run out, more are readily available very cheaply on the used/recycled market). I considered adding a PLCC footprint to the board, inside the DIP footprint, but I just ran out of space.

Link to comment
Share on other sites

Yeah, I realized that after I posted it. I have found DIP 32 pin 29C512's. I want to get a ZIF Socket and solder that to the board and then get one of these EEPROMs, then I'd have a nice development set up. I keep having to delete EPROMS.

Yeah, unfortunately that's one of the shortcomings of the approach I chose for the SuperCart I design. It was intended to be an inexpensive and simple distribution medium for completed Aquarius software, not necessarily as an efficient tool for developing it. The ideal solution for development would be an SRAM cartridge, or some other type of temporary storage which would allow you to transfer software and run it on the Aquarius directly, without having to burn it to a chip first. I still intend to tackle that project once I get the Aquaricart off my back; believe me, I'd love to have such a cartridge for myself. It's a problem that has long since been solved on other systems, and the only thing which would make it more complicated on the Aquarius is the lack of built-in bidirectional I/O, but even that isn't an insuperable problem with the Mini Expander's hand controller ports.

Link to comment
Share on other sites

Yeah, I realized that after I posted it. I have found DIP 32 pin 29C512's. I want to get a ZIF Socket and solder that to the board and then get one of these EEPROMs, then I'd have a nice development set up. I keep having to delete EPROMS.

Yeah, unfortunately that's one of the shortcomings of the approach I chose for the SuperCart I design. It was intended to be an inexpensive and simple distribution medium for completed Aquarius software, not necessarily as an efficient tool for developing it. The ideal solution for development would be an SRAM cartridge, or some other type of temporary storage which would allow you to transfer software and run it on the Aquarius directly, without having to burn it to a chip first. I still intend to tackle that project once I get the Aquaricart off my back; believe me, I'd love to have such a cartridge for myself. It's a problem that has long since been solved on other systems, and the only thing which would make it more complicated on the Aquarius is the lack of built-in bidirectional I/O, but even that isn't an insuperable problem with the Mini Expander's hand controller ports.

 

Well... an EEPROM with a ZIF socket would be almost that to me, because my programmer goes very fast...

Link to comment
Share on other sites

I have done it!!!! I don't know why this works, but it works. I am waiting for the VSYNC to go low, then go high and then drawing. Here is how it looks:

 

Wait for VSYNC Low

Wait for VSYNC High

Draw Characters of Frame 1

Draw Colors of Frame 1

Wait for VSYNC Low

Wait for VSYNC High

Draw Characters of Frame 2

Draw Colors of Frame 2

Repeat

 

That code works perfect on the emulator, but on the real thing makes garbages, but for some reason, and I don't understand why, if I do this, then I get the right image:

 

Wait for VSYNC Low

Wait for VSYNC High

Draw Characters of Frame 2

Draw Colors of Frame 1

Wait for VSYNC Low

Wait for VSYNC High

Draw Characters of Frame 1

Draw Colors of Frame 2

Repeat

 

post-20571-0-57421200-1301415658_thumb.jpg

 

Frankly, I don't care why it works - because it works. I really would like to understand why, but for right now, I am very happy. I plan on making a few images, loading them to EPROM and doing a video cap of the output to make a Youtube video posting, so you can see it really in action.

  • Like 2
Link to comment
Share on other sites

Congratulations on solving the puzzle! I wonder if it has something to do with the technical speed limitations of the PLA responsible for the graphics (once again, I'm speaking out of ignorance.)

 

Thank you for sticking with it.

 

I'm looking forward to the days when I can use your tool(s) to make awesome graphics on a real Aquarius.

 

-Jason

Link to comment
Share on other sites

Funny thing is that it does not work on Virtual Aquarius - it is flip flopped, but that is what the real Aquarius looked like when I used the code that worked on VA. Strange right? I have no idea what it would do on a PAL Aquarius. Does a PAL Aquarius have the same colors?

Link to comment
Share on other sites

Yes, it has the same colors. I tried to look in the documentation to find an answer but couldn't explain it.

Look at the block diagram and it comments at Blue Sky Rangers, and search for the text "Color information from RAM U4". It said that there is a timing mechanism to get character and color information on screen at the same time. According to these documents the timing is being done by PLA1 and PLA2.

But there is a timing difference between NTSC and PAL;

 

   |<-    Active scan period   ->|V.sync |<-
   |      12.8 mS                |3.6 for PAL
   |                             |2.8 for NTSC
   +++++++++++++++++++++++++++++++       ++++++++++++
   +                             +       +
   +                             +       +
+++++                             +++++++++

 

So I am wondering; does the NTSC Aquarius has the same PLA' s as the PAL Aquarius, or would the longer PAL V.Sync give the system enough time to get the characters and colors in the same time?

 

Regs

Martin

Link to comment
Share on other sites

All day on the Composite Mod for the Aq. I got the audio - that was easy, used the same trace that Martin used in his picture on Yahoo boards. I built the circuit the way that the dude on Yahoo board built it. 270 ohm resistor in line with a 220 uf capacitor to pin 8 of the Tea, but, I got nothing. I wonder if the TEA puts out a PAL Compositie signal and if so, how does the RF modulator convert it? Or, does it come out as NTSC? Either way, not working with the video cap card, I will test it on the regular TV though. Very frustrating....

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