jaybird3rd Posted April 4, 2011 Author Share Posted April 4, 2011 I was able to get composite video from the TEA1002 when I tried the mod on my Aquarius. It worked on a standard NTSC television, but the colors were off and a little too dark for my tastes. I also tried a modified composite mod designed for the Intellivision, since the Intellivision and Aquarius use exactly the same RF modulator, and although that worked better, I got some annoying vertical striping. This was probably because of the way I built the mod, since I had the same problem when I tried it in an Intellivision, but I never got around to troubleshooting it further. I'd check to make sure that the RF input on the VCR(s) you're using is even working correctly. Have you gotten it to receive anything from another RF console or computer? It just seems really odd to me that it wouldn't be compatible with the Aquarius at all; the Aquarius outputs a standard RF signal, and in my experience, a fairly high-quality one at that. Do all your testing on a standard television (preferably a CRT television, if you have one handy) before trying it with any specialized video capture hardware; it's best to keep your testbed as simple and as close to the original specifications as possible. Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted April 5, 2011 Share Posted April 5, 2011 The output of Color IC Ul2 is composite video containing all information necessary for presentation to the RF modulator and transmission to a television set. It is, however, in the PAL (Phase Alternation by Line) format used in Europe and must be converted to the NTSC (National Television Standards Committee) format used in the United States, Canada, and Mexico. This conversion is handled by circuitry at the output of U12, presenting an NTSC signal to the RF Modulator. I found this out. The TEA puts out a PAL Composite signal - I could grab that, but then I'd have a PAL Aquarius! I tried to grab the NTSC Signal going into the RF Modulator, and that is REALLY close. It has a shaky left bar on the side of the screen, and it is not very clear. I imagine that I need to put an RC in series with it, but as to what values to use, no idea. Any thoughts? Also, this is now in a thread where it probably doesn't belong? I just reread Jay's post about using an Intellivison mod because the RF Modulator is the same - that will be my next plan! Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted May 25, 2011 Share Posted May 25, 2011 Jay, How do you go about compiling and writing code that uses the second 8K of ROM? I have only used 8K for all of my programs up to this point, but I am now finding I want to experiment with larger programs, but the problem is that I use Assembler to deal with all of my memory locations. What I mean is this, when I create a program, I will use the reference for memory locations and jumps: ld hl, SAMPLE (Set HL to Sample Memory Location) ... SAMPLE: db. $00,$00,$00 When I try to make a 16K program and assemble it, the assembler pukes all over it and won't run. I have to keep the size below 8K. Do I have to hard code the upper ROM location and then pad my program to 8K and then copy the data/sample/switchable area to the end of the program? Thanks in advance. Chris Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted May 28, 2011 Author Share Posted May 28, 2011 Sorry to have kept you waiting, Chris. I've been crazy busy. The second 8K bank is in the region from $C000-$DFFF, before the main 8K bank where the cartridge begins execution. To use this region for code, keep it separate from the code in the main bank, and use $C000 as the starting address. Here is an example, using a slightly modified version of the "screen fill" demo that I posted in the other thread: ; Begin Extra 8K Bank ($C000-$DFFF) .org $C000 fill ld de,$03ff ; Set Byte Counter to 1K loop ld (hl),b ; Write byte inc hl dec de ; Decrement counter ld a,d ; Has counter reached zero? or e jr nz,loop ; If not, repeat loop ret ; End Extra 8K Bank ($C000-$DFFF) ; Begin Main 8K Bank ($E000-$FFFF) .org $E000 ; Aquarius Cartridge Header (SuperCart I, 8K Mode) .byte $53,$43,$30,$38,$4B,$9C,$B5,$B0,$A8,$6C,$AC,$64,$CC,$A8,$06,$70 main ld hl,$3400 ; Select Color Matrix ld b,$31 ; Set Color Code (yellow on red) call fill ; Fill Color Matrix ld hl,$3000 ; Select Character Matrix ld b,$C8 ; Set Character Code (a "cross") call fill ; Fill Character Matrix halt ; Terminate ; End Main 8K Bank ($E000-$FFFF) ; Zero-Fill Remainder of Cartridge ROM .org $FFFF .byte $00 .end In this version of the program, I've moved the "fill" subroutine and its inner loop into the extra 8K region ($C000-$DFFF). The main 8K region ($E000-$FFFF) starts with the cartridge header, as the Aquarius requires, then calls the "fill" subroutine after setting some parameters. Notice that I'm using a separate starting address for the code in each region. The assembler starts at $C000, and when it encounters the ".org $E000" directive (at the beginning of the main region), the Program Counter jumps forward to $E000, and the skipped bytes are filled with zeroes in the cartridge binary. Just be sure that the code and data in the extra region remains under 8K in total size, or else it won't fit! The third ".org" directive at the very end of the program causes the remainder of the cartridge to be filled with zeroes in the same way, saving you the trouble of manually "padding" it to 16K (there might be a better way of doing this that I'm not aware of). This is about all you need to do to create a full 16K Aquarius cartridge image. You must use bankswitching to go beyond 16K, but this requires a little more work. I discuss this process further in my next post, for whenever you're ready to take that step. EDIT: There is one extra step you might need to do before you can test your code on the real hardware with the SuperCart board. If your board is configured for 8K bankswitching mode (as I believe yours are), both the "fixed" and the "switchable" banks will be pointed to the last bank in the cartridge ROM on powerup, so it will be necessary to "initialize" the bankswitching hardware before you can use any of the extra 8K banks. For example, if you are burning a 16K image (such as the example program) to a 64K ROM, and if you plan to put multiple copies together to fill the ROM, you should be able to safely initialize the switchable bank to Bank 0. Add the following lines to the beginning of your program (in the example, just under the "main" label): 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 After you compile your code, put multiple copies together to fill the ROM, like so: COPY /B 16K.BIN+16K.BIN+16K.BIN+16K.BIN FINAL64K.BIN Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted May 28, 2011 Author Share Posted May 28, 2011 To use bankswitching, you would assemble your code and data into 8K chunks and then piece them together into a complete ROM image, as I described earlier. For example, let's say you want to create a 64K cartridge: 8 banks of 8K each, numbered 0 through 7. Bank 7 (the last bank in the ROM) will become the "fixed" region, always present at $E000-$FFFF in the Aquarius address space. This is also the bank where your program will begin execution. You've been using this bank already for your programs, filling the rest of the ROM with zeroes or with identical copies. The procedure for using bankswitching will depend to some extent on whether you're using the extra banks for code or for data. For data, you would prepare it in such a way that it is broken up into 8K chunks, then assign each of them to a particular bank so they can be swapped into the "switchable" region (from $C000-$DFFF) as needed. I've done this for the documentation in the Aquaricart, for example: the largest of the instruction manuals spans four 16K banks, but because I'm dynamically swapping them in and out of memory, a user can jump around within the manual, or read it from beginning to end, without ever realizing that they're switching banks. Using the extra banks for code is a little more complicated. My understanding is that programmers generally use the "fixed" bank for the main program and the "switchable" banks for subroutines, so that they can be banked in only when they need to be called. I did something similar in my example above: the "fill" subroutine is independent code can be stored in a bank by itself, so I pulled it out of the fixed region and into the switchable region. You will need to decide which parts of your programs can be run from the switchable banks. Assemble each of these banks separately, always using $C000 as the starting address. The code in each bank will "think" it's the only code that will use the region from $C000 to $DFFF; when you bank it in, it "appears" in the right location, unaware of the code in the other banks. You would also need a table somewhere in the "fixed" bank which holds the bank number and the starting address for each subroutine; when you're ready to use one of them, you would simply look it up in the table, bank it in, and then jump to its starting address. Unfortunately, unless your assembler provides some sort of automatic support for bankswitching, preparing and putting together the extra banks will have to be done manually. You'll also need to make sure that each bank is exactly 8K in size before you put them together into a final ROM image. You can "pad" the code banks to 8K using a technique similar to the one I used in my example; for data, you might need to pad it to 8K manually. To create the ROM image, you would concatenate the banks at the command prompt, like so: COPY /B BANK0.BIN+BANK1.BIN+BANK2.BIN+BANK3.BIN+BANK4.BIN+BANK5.BIN+BANK6.BIN+BANK7.BIN FINAL64K.BIN Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted June 15, 2011 Share Posted June 15, 2011 Another program, and more help needed debugging. Here is my code: ; Program to Create Sound .org $E000 .db $b6, $b7, $24, $2a, $8d, $9c, $42, $b0 .db $53, $6c, $90, $64, $89, $a8, $f9, $70 BANKMAIN: ld de,$c000 ; load the target address into register DE ld a,0 ; load the target bank number into the accumulator ld (de),a ; write the bank number into the cartridge space call main ld de,$c000 ; load the target address into register DE ld a,1 ; load the target bank number into the accumulator ld (de),a ; write the bank number into the cartridge space call main ld de,$c000 ; load the target address into register DE ld a,2 ; load the target bank number into the accumulator ld (de),a ; write the bank number into the cartridge space call main ld de,$c000 ; load the target address into register DE ld a,3 ; load the target bank number into the accumulator ld (de),a ; write the bank number into the cartridge space call main ld de,$c000 ; load the target address into register DE ld a,4 ; load the target bank number into the accumulator ld (de),a ; write the bank number into the cartridge space call main ld de,$c000 ; load the target address into register DE ld a,5 ; load the target bank number into the accumulator ld (de),a ; write the bank number into the cartridge space call main ld de,$c000 ; load the target address into register DE ld a,6 ; load the target bank number into the accumulator ld (de),a ; write the bank number into the cartridge space call main halt main: ld hl, $C000 ; Memory Location to ROM Sample ld bc, 8192 ; Number of Samples push bc ; send BC to the stack replay: ld d, 8 ; Sub-Samples ld e, (hl) ; load sample into e ld c, $FC ; I/O port for sound ld ($3002),hl ; show the HL register in upperleft corner of screen subsamp: rl e ; 7th bit of register E will rotate left into the carrier flag ld a, $FF ; default value 255 bit 7 for i/o has been set jp nc, Output ; Was the carrier set during the "rl d" command ld a, $FE ; Carrier was set -> reset bit 7 for I/O Output: out ($FC),a ; sending I/O ld a, 7 ; delay loop Delay: dec a ; decrease a jr nz, Delay ; repeast until a is zero dec d ; countdown ld a, d ; check on d jp nz, subsamp ; repeat until 8 samples inc hl pop bc ; get back BC dec bc ; Decrement Sample Counter push bc ; back to the stack with you BC ld a, c ; Load C or b ; Is BC Zero jp nz, replay ; If it isn't zero, keep playing FINISH: ret ; Zero-Fill Remainder of Cartridge ROM .org $FFFF .byte $00 .end I realize that Jay will want me to OR $80 before sending the bankswitching command, but, since I have the lockout disabled (in fact, my board doesn't even have the lockout chip) I don't need to send Bit 7 high. Anyway, the program loops forever. At the beginning of the file, I loaded a 64k ROM, with the first 56k filled with a bit audio sample. It doesn't appear to bankswitch. Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted June 16, 2011 Author Share Posted June 16, 2011 Since your board doesn't include the lockout feature, the OR $80 step doesn't really matter, especially since you're only testing. I haven't looked at this code in depth yet, but it seems like it should work. A "stupid" question first: in the first 56K of the ROM, is each 8K bank filled with different data, or is it the same 8K of data in each bank? If it's the same data, you wouldn't be able to tell if the cartridge is switching banks or not. If it's different data, we'll need to make sure that the cartridge is working properly (although I'm sure I tested it before I sent it out to you). Let me dig out my 64K diagnostic ROM, which exercises the bankswitching circuitry and reports any data errors. I'll try to post it within the next few days. In the meantime, it also wouldn't be difficult to write your own simple test: for example, you could put a string in the first bytes of each bank, then write a program to rotate banks and print the string. Quote Link to comment Share on other sites More sharing options...
catsfolly Posted June 17, 2011 Share Posted June 17, 2011 Chjmartin2, Well, I've never tried to use Aquarius Bank switching. But in the code you posted, I think you need a "pop bc" instruction after the "FINISH" label, otherwise the "ret" instruction will pull the value of bc off the stack (currently 0) and attempt to return to that address. David 1 Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted June 17, 2011 Author Share Posted June 17, 2011 Ah, good catch! Thank you. That would explain why the program appears to repeat the first bank over and over. In effect, the "ret" instruction is "warm-booting" the Aquarius, since address $0000 is the starting address. Unless I'm mistaken, the last "push bc" instruction doesn't need to be there at all. Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted June 17, 2011 Share Posted June 17, 2011 Ah, good catch! Thank you. That would explain why the program appears to repeat the first bank over and over. In effect, the "ret" instruction is "warm-booting" the Aquarius, since address $0000 is the starting address. Unless I'm mistaken, the last "push bc" instruction doesn't need to be there at all. OMG... if that is it then I will just hit myself. Why does it take other people to find my stupid mistakes?! Quote Link to comment Share on other sites More sharing options...
catsfolly Posted June 17, 2011 Share Posted June 17, 2011 Well, when the code loops, the value of bc needs to be pushed on the stack. Probably the cleanest way to do this would be to move the "push bc" instruction to be after the "replay" label. Current code: main: ld hl, $C000 ; Memory Location to ROM Sample ld bc, 8192 ; Number of Samples push bc ; send BC to the stack replay: ; code that does stuff pop bc ; get back BC dec bc ; Decrement Sample Counter push bc ; back to the stack with you BC ld a, c ; Load C or b ; Is BC Zero jp nz, replay ; If it isn't zero, keep playing FINISH: pop bc ret New version: main: ld hl, $C000 ; Memory Location to ROM Sample ld bc, 8192 ; Number of Samples replay: push bc ; send BC to the stack ; code that does stuff pop bc ; get back BC dec bc ; Decrement Sample Counter ld a, c ; Load C or b ; Is BC Zero jp nz, replay ; If it isn't zero, keep playing FINISH: ret Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted June 17, 2011 Share Posted June 17, 2011 Nice... Got bankswitching working... now more work to do. Thanks for your help! Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted June 17, 2011 Author Share Posted June 17, 2011 Nice... Got bankswitching working... now more work to do. Thanks for your help! Excellent! It's great to see someone exploring new frontiers on the Aquarius, and with up to a megabyte of space to play with. I'm glad to hear the bankswitching is working for you, and I'm looking forward to seeing what you can accomplish now that you're not limited to 8K anymore! Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted June 17, 2011 Share Posted June 17, 2011 Nice... Got bankswitching working... now more work to do. Thanks for your help! Excellent! It's great to see someone exploring new frontiers on the Aquarius, and with up to a megabyte of space to play with. I'm glad to hear the bankswitching is working for you, and I'm looking forward to seeing what you can accomplish now that you're not limited to 8K anymore! Prepared to be wow... well... not that much... prepare to say "oh... that's pretty good." Ha! Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted March 9, 2012 Share Posted March 9, 2012 Jay, Would an W27E010 work on the Supercart I? Here is the datasheet: http://pdf1.alldatasheet.com/datasheet-pdf/view/47655/WINBOND/W27E010.html Thanks, Chris Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted March 9, 2012 Author Share Posted March 9, 2012 The SuperCart board won't allow in-place programming, of course, but it looks as if this EEPROM should be compatible; the pinout appears to be the same as a 27C010. Just remember to close jumpers W4 through W6, and to clear W7 through W9, to configure the board for a 128K ROM. (I still need to get an inexpensive SRAM cartridge together to make prototyping easier ... if only I had enough free time these days... ) By the way, seeing this thread again reminds me that some of the information in it is obsolete. In particular, the portions of Post #3 which concern the "lockout feature" can be ignored. I added that feature as a last-minute hack for the Aquaricart, to fix some old cartridge images which were triggering "involuntary bankswitches"; as it turns out, these were caused by unchecked boundaries, uninitialized pointers, and other programming errors. For reasons I won't bore everyone with now, having the option of locking out bank switches caused more trouble than it was worth, so for the final Aquaricart design, I simply patched the images and omitted the "lockout chip". It will be removed entirely from subsequent iterations of the SuperCart design. Quote Link to comment Share on other sites More sharing options...
chjmartin2 Posted March 9, 2012 Share Posted March 9, 2012 Ugh... I thought that it was a 1 meg. I am looking for a 1 meg EEPROM that I can use because I hate fighting with the UV eraser. There were some pins that didn't match exactly, at least from what I could tell. (A19?) Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted March 9, 2012 Author Share Posted March 9, 2012 Ugh... I thought that it was a 1 meg. I am looking for a 1 meg EEPROM that I can use because I hate fighting with the UV eraser. I know what you mean; that's why I still think it would be great to have an SRAM cartridge. The SuperCart board is a good, inexpensive distribution medium, but it isn't very convenient for frequent prototyping (nor was it designed primarily for that purpose). A battery-backed SRAM cartridge with an integrated PC interface would be ideal, but again, it's not something I've had time to work on lately. I'm sure I'll want one for myself when I (finally!) begin working on some of the Aquarius games I have in mind: Aquarius emulators are still pretty far behind the new territory we've been exploring, so their usefulness for testing new software is sadly limited. Quote Link to comment Share on other sites More sharing options...
nitrofurano Posted July 11, 2014 Share Posted July 11, 2014 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? how can we find which are the exact colours used on Aquarius (both NTSC and PAL)? - like most of what we find at http://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_palettes , i guess it was designed using the YPbPr colourspace as well, and a frame grabbing (digitizing or from a dvd-recorded video frame) would help us to figure out which they are, based on the picked RGB colourspace information? and the lack of accuracy brings some concerns, specially on tha disastrous result we see from Mess emulator - http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=95021Post95021 (that dark grey from colour #15 that seems to appear almost as black on real Aquarius, looks as bright grey on Mess... :S - i guess we need to (or we must) help Mess development somehow there ) Quote Link to comment Share on other sites More sharing options...
Atirez Posted July 25, 2014 Share Posted July 25, 2014 (edited) Perhaps this is the wrong place to post this but you seem to have a lot of knowledge about creating cartridges/electronics stuff. I was wondering how would I go about creating a board that could plug in to the aquarius cartridge slot using home electronics equipment? I dont need to print PCBs or anything, I just wanted to get to know the system better so was going to try and hook up the aquarius to the raspberry pi (via GPIO) but need to build the connector to fit the aquarius. Edited July 25, 2014 by Atirez 1 Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted July 25, 2014 Author Share Posted July 25, 2014 This is the perfect place to ask! It's always great to see someone doing something new with the Aquarius! The Aquarius cartridge port uses a 44-pin card edge connector, 0.1" (2.54 mm) pin pitch. Martin provided a pinout for the connector on his Web site. Perhaps the easiest way to tap into the cartridge port signals is to do what I did when I was first designing the SuperCart: get an old Aquarius cartridge (a 4K RAM module would work nicely), pop it open, pull the chips off the board, and connect your project to the solder points on the bare board. Quote Link to comment Share on other sites More sharing options...
Atirez Posted July 26, 2014 Share Posted July 26, 2014 Sounds like a plan, just need to find a cheap 4k cartidge . Thanks for the help. Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted July 26, 2014 Author Share Posted July 26, 2014 Sounds like a plan, just need to find a cheap 4k cartidge . Thanks for the help. I think I have an extra 4K board that I can send you; the shell and RF shielding have already been removed, so all you have to do is pop the chips. PM me if you're interested. Quote Link to comment Share on other sites More sharing options...
barnieg Posted June 28, 2015 Share Posted June 28, 2015 Jaybird3d I might be needing a supercart with socket for eprom (or eeprom?) in the near future what I would like is to share dev tools with eproms that are compatible with those listed here: http://www.cpcwiki.eu/index.php/GX4000_cartridge#EPROMs Questions: 1. Whats a decent eprom programmer that will work with Linux? 2. Are there eproms that I could use for both the supercart and the GX4000 carts? Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted June 28, 2015 Author Share Posted June 28, 2015 Jaybird3d I might be needing a supercart with socket for eprom (or eeprom?) in the near future what I would like is to share dev tools with eproms that are compatible with those listed here: http://www.cpcwiki.eu/index.php/GX4000_cartridge#EPROMs Questions: 1. Whats a decent eprom programmer that will work with Linux? 2. Are there eproms that I could use for both the supercart and the GX4000 carts? No problem! Just let me know what you need. The SuperCart board can be useful for testing during game development, if that's what you have in mind, but it isn't the most convenient setup due to the need to burn an EPROM every time you want to test your code. I'm working on a 512K RAM cartridge which will use the same 8K bankswitching scheme as the SuperCart board, and a USB cable for transferring code to/from a PC, but I don't have a working prototype yet. I'll let everyone know as soon as I have something to show; I'm hoping it will be soon, since I need this cartridge for my own games, too! I'm afraid I'm not familiar with Linux-friendly EPROM burners. The one I use the most these days is an inexpensive TOP853, which seems to be Windows only (the PC on my bench runs Windows XP). The EPROMs listed on the page you linked to should all be compatible with the SuperCart; it supports the 27C256 (32K) all the way up to the 27C080 (1M). If your game requires only 16K or less, the SuperCart can also be jumper-configured for a 27C128 EPROM, without the bankswitching logic. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.