Jump to content

Photo

[AQUARIUS] Using the SuperCart I Cartridge Board


47 replies to this topic

#1 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • 7,066 posts
  • Location:806.4616.0110

Posted Mon Feb 7, 2011 6:24 PM

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 Aquaricart software is still in development (and nearing completion!), but the SuperCart I board is a completed and tested design, and is available to any Aquarius programmers who are interested in using it for their own projects. This document 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.

The SuperCart I supports standard EPROM memory chips, from 32K (a 27C256 EPROM) to 1024K (a 27C080 or 27C801 EPROM), and was designed using only traditional TTL integrated circuits. This may be a somewhat old-fashioned solution in the age of flash and programmable logic chips, 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 SuperCart I cartridges, without having to have access to a PLD programmer. Besides the core components of the SuperCart I (listed below), all that is required is a standard EPROM programmer, an ultraviolet eraser, and the EPROMs themselves, all of which can be obtained very inexpensively on the used market.

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

#2 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Mon Feb 7, 2011 7:08 PM

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, but most of the later releases used the full 8K. The original Mattel cartridges which made use of this extra space contained two ROM chips, one for each cartridge 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.

#3 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Mon Feb 7, 2011 7:09 PM

Using the SuperCart I

The SuperCart I supports ROM sizes from 32K up to 1024K (one megabyte), and it implements a direct extension of the bankswitching schema used by the Atari 7800. It banks the ROM into the available 16K cartridge space in one of two ways, depending on which bankswitching mode is selected. These modes, described below, differ mainly in the amount of ROM that can be banked into the cartridge space at one time.

In both modes, the cartridge ROM is divided into banks of 8K each. Depending on the bankswitching 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 would specify the target bank number. This number can be from 0 to a maximum of 127, depending on the size of the ROM, and is stored in the accumulator (Z80 register A). Next, a logical OR with $80 must be performed to force the most significant bit (Bit 7) of the bank number to 1, for reasons I will explain below. The bank number can then be written from the accumulator into any valid address within the cartridge space to perform the switch.

For example, if Bank 0 is to be selected, the programmer would execute the following routine:

   ld   de,$c000      ; load the target address into register DE
   ld   a,$00         ; load the target bank number into the accumulator
   or   $80           ; force the MSB high
   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 of the cartridge space, where it can be accessed by the programmer like any other region of memory.

There are certain restrictions that are unique to each bankswitching 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 the memory map) and one switchable region (from $C000 to $DFFF, the "secondary" bank in the memory map). The fixed region always "maps" to the last/uppermost 8K bank in the ROM, but the programmer can "map" any of the other 8K banks into the switchable region by writing the bank number into the cartridge space, as described above. By default, the fixed and switchable regions are both "mapped" to the same ROM bank, so it is necessary to "initialize" the switchable region on startup by selecting another bank.

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

16K Mode

In this mode, the entire 16K cartridge space is configured as a switchable region, with no fixed regions at all. The programmer can "map" any pair of 8K banks into the cartridge space, the only restriction being that these banks must be contiguous within the ROM. In other words, for every pair of ROM banks, the even-numbered bank is "mapped" to $C000-$DFFF, and the odd-numbered bank is "mapped" to $E000-$FFFF.

In this mode, the least significant bit (Bit 0) of the bank number is discarded when it is written to the SuperCart, so 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. On startup, the last/uppermost pair of 8K ROM banks is mapped into the cartridge space.

This mode was implemented mainly for use with the Aquaricart software (although it is certainly usable by other applications also): since several of the original Aquarius cartridges used the full 16K of cartridge space, a bankswitching mode that could accommodate this requirement was needed. This mode has the advantage of a larger switchable region, allowing twice the amount of ROM to be banked in and out at one time. However, the programmer should remember that, since there is no permanently fixed region in this mode, any bankswitch command that is executed from within the cartridge space will cause the contents of this space to change, and the program will likely jump into garbage and crash. One solution is to copy the bankswitching routine into RAM, so that any bank switches and jumps in and out of the cartridge space can be performed from a fixed location. This "trampoline code" can be as short as the subroutine described above.

The "Lockout Feature"

As mentioned earlier, it is necessary to logical OR the bank number with $80 before it can be written to the SuperCart. This is because the bankswitching hardware is only enabled as long as the most significant bit (Bit 7) of the latch is high (set to "1"). If it is forced low (set to "0") when the bank number is written, the bank is switched, but subsequent bank switches are locked out.

This "lockout feature" was added as a last-minute workaround to a problem I discovered as I was testing the Aquaricart software: about half of the original Aquarius cartridges intermittently wrote data into the cartridge space, which caused a switch to an arbitrary bank. This caused the program to jump into garbage, resulting in a system crash. I have not determined why these writes are occurring, but it seems likely that they were a form of copy protection, intended to disable pirated copies of the cartridges running from RAM. Most of the affected cartridges would crash right away, but some (such as BurgerTime) would crash a few seconds after the title screen, while others (such as Utopia) would appear to function normally for several minutes before crashing.

Since it was not feasible to patch and test all of the affected cartridges, I made a last-minute change to the hardware. The maximum number of banks that the SuperCart I can support is 127, which requires the first seven outputs of the latch (in this case, a 74LS374). This left one unused output, which I used as an "on/off switch" for the bankswitching hardware. The outputs are all high ("1") by default, and as long as the eighth output remains high, the bankswitching hardware works normally. But by forcing the eighth output low ("0") during a bank switch, the programmer can "freeze" the bankswitching hardware at the specified bank. This allowed me to safely bank in the "self-modifying" legacy cartridges in the Aquaricart, which then behaved normally.

#4 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Mon Feb 7, 2011 7:11 PM

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

W10 was added to enable or disable the "lockout chip": an 74LVC1G57GW IC, at location U5 (visible in the picture), which was added to the Aquaricart and configured as an AND gate to implement the lockout functionality. Because this IC is only available in a very small SOT-363 package, it is difficult to install by hand, and I wanted a way to leave it off of SuperCart boards that do not require it (basically, any board that is not being used for the Aquaricart). If this jumper is set to "disable", the chip can be omitted.

1-2: Enable
2-3: Disable


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

#5 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Mon Feb 7, 2011 7:24 PM

Emulator Support and Bankswitching Mode Detection

Since these modes of bankswitching are new to the Aquarius, none of the Aquarius emulators presently support them, but I'm hopeful that they will be emulated in the near future. This will greatly assist the development of new bankswitched 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.

One step toward this goal would be to provide a way for the emulators 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 use bankswitched cartridges: several Atari 800 emulators, for example, must prompt the user to select the correct bankswitching scheme when a cartridge image larger than 16K is loaded.

It occurs to me that one way to achieve this is to use the sixteen-byte cartridge header--which must be present in all Aquarius cartridges--as a bankswitching mode identifier. As part of the SuperCart standard, I'd like to establish a pair 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, the emulator(s) could simply check for these headers when the binary 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.

#6 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Tue Feb 8, 2011 8:25 AM

I cannot wait to get my cart in! My EPROM writer and UV eraser are on the way!!!

#7 mvdsteenoven OFFLINE  

mvdsteenoven

    Chopper Commander

  • 162 posts
  • Location:Netherlands

Posted Wed Feb 9, 2011 4:05 PM

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.

Attached File  xOr-byte.xls   51.5KB   126 downloads

Regs,
Martin

#8 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Wed Feb 9, 2011 9:01 PM

WOW! Thank you, Martin! This will make it easy to create the headers, once I have access to a compatible version of Excel. I'll test them in the emulator before posting them here.

Thanks again!

#9 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Mon Feb 14, 2011 3:51 PM

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

  • Use the ORG directive in your assembler to set $E010 as the base address (this is the address immediately after the header), and assemble the code you wish to place inside the fixed bank. In this example, the assembled binary file name is "FIXED.BIN".
  • Add the 8K cartridge header to the beginning of this binary (the file "08K.BIN" can be found inside the archive). This is most easily done at the command line. The following will create a new copy with the header attached, called "FIXED2.BIN":
    COPY /B 08K.BIN+FIXED.BIN FIXED2.BIN
  • Pad the end of this binary with zeroes (if necessary) so that its total length is exactly 8K. You can do this with any hex editor.
  • Pad the switchable bank files with zeroes so that they are exactly 8K in length as well. 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.)
  • Concatenate all of the banks together at the command line, placing the fixed bank last:
    COPY /B SWITCH0.BIN+SWITCH1.BIN+SWITCH2.BIN+FIXED2.BIN 32KROM.BIN
In this example, the resulting file should be exactly 32K in size.

Once you get used to it, this procedure really isn't as complicated as it might sound. At some point, I should look into creating a set of macros for popular text editors so that the process can be automated somewhat.

Attached File  SuperCartHeaders.zip   234bytes   117 downloads

#10 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Sat Mar 12, 2011 10:15 PM

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

Attached File  7thgues.bin   3.86KB   112 downloadsAttached File  hobbit.bin   3.86KB   109 downloadsAttached File  picard.bin   3.86KB   109 downloadsAttached File  SIMPSONS.bin   3.86KB   109 downloadsAttached File  sqtitle.bin   3.86KB   122 downloads

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

Attached File  sonicmar.bin   3.86KB   113 downloads

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!

Attached File  SONIC64K.BIN   64KB   107 downloads

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:

smshower.jpg

On the real thing:

sonmar.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, Sat Mar 12, 2011 10:29 PM.


#11 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Sun Mar 13, 2011 12:19 PM

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

#12 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Sun Mar 13, 2011 1:36 PM

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!

#13 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Sun Mar 13, 2011 2:09 PM

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.

#14 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Sun Mar 13, 2011 6:20 PM

Well... Right now I have to focus on figuring out why I am getting weird characters. I went ahead and created a test pattern. (I attached the original compiled version.) And of course, no bugs on the display!! So, now I need to create a test pattern with different characters.

Attached Files



#15 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Mon Mar 14, 2011 9:31 PM

IMG_0890.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....F1-CB58FE5C5EB9

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

#16 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Sun Mar 20, 2011 11:38 AM

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

#17 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Sun Mar 20, 2011 6:43 PM

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.

#18 jaybird3rd ONLINE  

jaybird3rd

    Quadrunner

  • Topic Starter
  • 7,066 posts
  • Location:806.4616.0110

Posted Mon Mar 21, 2011 2:20 PM

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.

#19 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Tue Mar 22, 2011 7:00 AM

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

#20 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Tue Mar 29, 2011 10:22 AM

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

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

#21 Jay Silverheels OFFLINE  

Jay Silverheels

    Moonsweeper

  • 407 posts
  • Location:Washington D.C.

Posted Tue Mar 29, 2011 5:56 PM

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

#22 mvdsteenoven OFFLINE  

mvdsteenoven

    Chopper Commander

  • 162 posts
  • Location:Netherlands

Posted Wed Mar 30, 2011 11:15 AM

I have done it!!!! I don't know why this works, but it works.


Cool! :D :D
And is it still working on the Virtual Aquarius?
Are you using an NTSC system? How would it work on PAL?

Looking forward to your video!

Regs
Martin

#23 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Wed Mar 30, 2011 6:09 PM

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?

#24 mvdsteenoven OFFLINE  

mvdsteenoven

    Chopper Commander

  • 162 posts
  • Location:Netherlands

Posted Thu Mar 31, 2011 11:24 AM

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

#25 chjmartin2 OFFLINE  

chjmartin2

    Moonsweeper

  • 277 posts
  • Location:Massachusetts

Posted Sun Apr 3, 2011 8:42 PM

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




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users