Jump to content

Bruce Abbott

Members
  • Content Count

    122
  • Joined

  • Last visited

Community Reputation

264 Excellent

1 Follower

About Bruce Abbott

  • Rank
    Chopper Commander
  • Birthday 11/01/1957

Profile Information

  • Gender
    Male

Recent Profile Visitors

5,103 profile views
  1. You can append binary code to the end of a BASIC tape file and it will be loaded in with the program, but there is a catch - the end of the tape file is marked with 10 zero bytes, so if your code has 10 consecutive zero bytes in it the tape loader will quit at that point. If you can ensure that the binary doesn't have any more than 9 consecutive zero bytes in it then you're fine, otherwise you have to mangle the data and restore it after loading. CLOAD loads BASIC programs into the memory location stored in $384F,50 (14415,6). In a stock Aquarius this will be $3901, but extended BASIC needs more system variable space so it moves the start of BASIC up to a higher memory location. That means any code you embed in the file will also be moved up, so you can't rely on it being at a fixed memory location. The solution is to compile your code for a location that is guaranteed to be beyond the end of the BASIC loader (eg. $4000), then in your loader move the code to its correct location before jumping into it. On a real Aquarius loading from tape is very slow and unreliable, so it might be better to put it in a cartridge ROM.
  2. Does this mean you fixed the problem you were having with wrong colors? If the color is good on a normal monitor it should be similar on the XRGB, unless it has different terminations (should be 75 Ohms to ground on the R G and B lines. If it doesn't have this then you may need to add resistors, and perhaps buffer amps to maintain the correct signal level and impedance).
  3. I am happy to have another beta tester. However grips03 is having some problems with his board (it only works when the PCB is severely flexed, and 2 resistors are bad) so I would prefer to wait until this has been resolved before sending out another one. From now on I will ship via parcel post only (an extra $10) to lessen the risk of damage. I will also make a test circuit to ensure that it works 100% before shipping!
  4. I don't have an Intellivision (and no way of getting one) so I cannot test it. However since I have couple of spare boards and enough parts, I am happy to sell you one at cost on the understanding that there is no guarantee it will work properly in the Inty. Do you have the skills and equipment to install it and work through any problems that might occur? Are you willing to be a 'beta' tester? Cost of PCB with parts installed (no wires or connectors):- PCB $7 GAL22V10 (programmed) $4 24 pin IC socket $1 10 x smd resistors, 2 x caps $3 Total component cost: $15 If it will fit in an envelope (max. thickness 10mm) then postage will be $5, for a total of $20.
  5. Not being satisfied with the composite video output, I bread-boarded a circuit using an AD724 RGB to NTSC/PAL Encoder. The results so far are quite encouraging - no streaking or noise, and of course no pixel distortion because the signal is going through the RGB GAL. The encoder circuit draws about 35mA, about the same as the THS7314 video buffer. For this test I used an external 14.318MHz oscillator, which introduced some shimmer due to not being phase locked to the Aquarius. Next I will try using the Aquarius internal 3.57MHz clock. The AD724 can also output S-video, which should produce an even better picture on TVs which have S-video input. Though the AD724 encoder could be added to my RGB board it might be better as an external add-on, then it could be used with other devices. This could have its own oscillator (perhaps with both NTSC and PAL crystals) or use the Aquarius 3.57MHz clock (NTSC only) fed through the RGB connector. Now that I know how good composite video can be, I will also investigate further to see whether the streaking and noise on the stock Aquarius composite signal can be reduced.
  6. Here is the result. Colors are based on the chart in this post by Snafu-1982. I took the 8 bit RGB values and simply divided them by 32 to get 3 bit values. My camera didn't do a very good job - in reality the colors are more vibrant and closer to the chart. I think it looks pretty good! IVRGB.pld.txt
  7. Looks like it should be able to do it. The AY-3-8915 color encoder in the Intellivision has 5 digital inputs which select 1 of 16 colors plus blanking and sync. This is similar to the Aquarius except that it encodes everything into the 5 bits instead of having a separate sync bit. I will calculate the required RGB levels and try it out on the Aquarius!
  8. A 4.7uF capacitor across the 5V supply removed the faint vertical lines on RGB. Total current draw varied from 30-46mA depending on screen content (3-18mA of this being consumed by the 75 Ohm terminations in the TV). With the video amp installed and terminated (RGB output disconnected) the total current draw was 45-55mA. As expected the composite image is blurry and muddy, with horizontal streaks and vertical lines sometimes visible, but still much better than the original rf signal. Colors are better than the images below suggest, as my camera tends to oversaturate red and blue.
  9. Success! At first the colors were messed up and I couldn't figure out why. All the color mapping equations looked correct, cables were wired correctly - what could be wrong? Then I realized that I had programmed the input signals in the wrong order. No problem - simply reassign the pins in WinCUPL, reprogram the GAL and now it's working perfectly! The GAL draws 26~28mA (varying slightly with pixel density) which is less than I expected. Next step: install and test the composite video and audio circuits. The PCB could do with a few minor changes. Unfortunately the 8 pin socket I choose turned out to be the type 'B' version with 41º pins, and the PCB layout for type 'A' sockets is different. This is not a problem if you use a panel-mount socket. I can see faint vertical lines on some colors, indicating that the +5V supply needs more filtering. So far I have only programmed the GAL with the stock Aquarius color palette. This is using up 6 out of 10 available product terms on one of the Blue outputs, which may limit what other palettes can be installed. Now I have to decide what second palette I want and see if it will fit.
  10. 9 outputs produces 512 colors, which is the same as the Atari St. I could use all 10 outputs (4 outputs on green) to get 1024 colors. The circuit should able to work with a variety of machines. CGA doesn't have a pixel clock so it would simply run unclocked like my earlier RGB interface, and CBLK won't be needed if the RGB signals are already low during the sync period.
  11. PCB design sent. Boards expected to arrive in about 3 weeks.
  12. Here is my latest design. Two big changes:- 1. 8 pin DIN socket wired to MSX II standard, with solder bridge jumpers and an 8 pin header for using different pinouts and/or sockets. 2. Using an ATF22V10CQZ SPLD (equivalent to GAL22V10 but lower power) to convert from digital to analog RGB. This requires fewer parts and is more flexible than hard-wired logic. Previously I had resisted using a GAL because a standard 22V10 draws up to 130mA. Also a special programmer is required and nobody makes GALs anymore. However I recently discovered the Atmel/Microchip ATF22V10CQZ, which has current draw proportional to clock speed (estimating 30-40mA at video frequencies) and is still in production. I designed a simple ATF Blaster for DIYers who don't want to spend $100+ on a suitable commercial programmer. Hopefully this will also do the CQZ version - will find out when I receive them! (it's worked with every chip I have tried so far). The SPLD converts Aquarius 4 bit digital RGBI into 9 bit digital RGB (3 bits per color) using a lookup table, then clocks its output registers with the pixel clock to synchronize the colors. The 3 bit digital RGB outputs are finally converted to analog using resistors. This only uses 7 of the SPLD's 12 inputs, so other inputs can be used to select different color palettes, eg. original Aquarius, ZX spectrum, MSX, C64 etc. I intended to use the RF channel switch to switch between palettes, but it could be controlled programmatically using eg. the printer TXD or CP/M I/O pin. I haven't built a fully working circuit yet. Initial tests and calculations show that it should be able to reproduce the original Aquarius colors fairly accurately (at least as good if not better than my discrete logic design) so rather than wasting time and energy building a prototype on matrix board I will just get some PCBs made. If for some reason the SPLD doesn't do the job then I will go back to the discrete design. Due to the thickness of the PCB the DIN socket sits a bit higher than the cassette port. The hole obviously needs to be enlarged, but there should be just enough room without having to cut into the lip at the top of the case (the photo below shows it even higher because I didn't trim the pins). Alternatively you could use a panel-mount socket and connect it to the RGB board via a short cable and 8 pin plug. Panel-mount sockets fit into the existing hole from the outside, which doesn't look quite as nice as internal mounting but is simple and robust. You could fix it with screws, or hot glue it from the inside if you don't want to drill holes in the case. The RGB circuit board is designed to fit in the same space as the modulator, with GND connections aligned to the modulator ground tabs and Audio / Video / +12V / RF_switch inputs lining up with the modulator inputs. Wires connecting between these points hold the PCB in place. +12V is required to turn on the SCART port in a TV. In the Aquarius this normally powers the RF modulator. It is fed through a 180 Ohm resistor on the motherboard, so should be fairly safe against accidental shorts. Instead of changing color palettes the RF switch could be used to switch the SCART port between composite video and RGB. On SCART this is done by putting a signal on the 'Fast Blanking' pin which tells it to overlay an RGB image on top of the composite video. The RF switch input goes into the SPLD, so it can be programmed to use either CSYNC or CBLK to control fast blanking, or it could just produce a constant +1V - depending on what works best (some TVs apparently don't like true fast blanking and prefer to have a fixed voltage on the FB pin). SCART normally extracts sync pulses from the composite video signal, though it can also use CSYNC for this purpose. If you are not using SCART this is not an issue, but you will probably want CSYNC somewhere on the RGB socket. The solder bridge pads connect between the signals named (which also go to the 8 pin header) and the DIN socket. If you need a different pinout (eg, for a different MSX computer or ZX Spectrum +2/3) then you can solder wires from the DIN side of the pads to different pads on the other side or to the 8 pin header holes. This combination of pads and pin headers should support any pinout that you might need.
  13. I am thinking it could be soldered to the motherboard using the same holes as the RF modulator. I could also pick up GND, +5V, composite Video and audio from the same pads. Good idea! The only question is what pinout to use - MSX perhaps? The hole in the case will have to be enlarged slightly, but this should be easy to do (certainly not as difficult as cutting out the holes for a DE-15 VGA connector!).
  14. I did did the PCB layout for RGB + Composite video today. Eagle's autorouter only managed to do 81% of the tracks and was really messy, so I routed the whole board by hand. For buffering the composite video I used a THS7314 triple video amp, which has AC coupling with sync tip clamp so it is not affected by DC voltage on the input, and 8.5MHz low pass filtering to reduce noise. Seems a pity to have the other two channels lying idle, but I have yet to find a single channel chip with the same features. It's been so long since I used the composite output on my Aquarius that I had forgotten how bad it is. The THS7314 does much a better job than the single transistor buffer I was using before, but it can't make up for the general crappyness of the NTSC signal. Still better than RF though. The board is designed to fit in place of the RF modulator. The composite video socket should go through the existing RF output hole, but another hole will have to be cut into the case to fit the RGB connector (which holds the board in place).
  15. In this post I explain how to run machine code tape (CAQ) programs from disk. In most cases all you have to do is load the BASIC program and edit the line that loads the machine code array. For example, here is the BASIC program for D-Fender:- 5 U=0 10 X=0 20 DIMA(2429) 30 CLOAD*A 40 POKE14340,PEEK(14552)+7 50 POKE14341,PEEK(14553) 60 X=USR(0) Change line 30 to this:- 30 LOAD"DFEND_A.CAQ",*A Then save the BASIC program as eg. "DFEND.BAS", and you can run the game by simply typing RUN"DFEND Arrays are stored in memory after the end of BASIC text and variables, so changing anything in the BASIC program may cause the array address to change. Usually this is taken care of by the machine code which relocates itself to a higher address. However some programs expect the array to be at a fixed address, so they crash. Machine code complied with zcc suffers from this issue. Here is one example, "vtdemo_BAS.CAQ":- 5 U=0 10 X=0 20 DIMA(00953) 30 CLOAD*A 40 POKE14340,PEEK(14552)+7 50 POKE14341,PEEK(14553) 60 X=USR(0) Though lines 40-50 correctly calculate the actual load address, the C code was originally compiled to run at 14712 and does not relocate itself. So the machine code is entered at the correct address, but crashes shortly afterwards because all the fixed addresses in it are wrong. To fix this we need some way to adjust the size of the BASIC program so the array address matches what the code was compiled for. Unfortunately this is not just a simple matter of matching files sizes, because when run the modified BASIC program may allocate a different amount of variable space, which also affects the array address! By trail and error I have determined that the following code works when the BASIC file size is adjusted to 132 bytes. 5 U=0 10 X=0 20 DIMA(00953) 30 LOAD"VTDEMO_A.CAQ",*A:REM... 40 POKE14340,120 50 POKE14341,57 60 X=USR(0) Lines 40-50 poke a fixed value of 14712 into the USR address. This reduces the size of the BASIC program so we have enough space to add the filename. Line 30 is modified as usual (change CLOAD to LOAD, add filename etc.). The final file size is then adjusted to 132 bytes by changing the number of dots after the REM statement on the same line (this will vary depending on the filename length). Save the program with eg. SAVE "VT_DEMO.BAS" and then do DIR to check that the file size is 132 bytes. If not then edit line 30 and change the number of dots after the REM, then save it again. Note that programs which expect the array to be at a fixed address will also fail if using a version of BASIC which has a different start of BASIC text. BASIC programs are relocated after loading so this is not a problem for them. However machine code programs must either have a relocator built in, or be loaded to a specified address. Unfortunately standard Aquarius BASIC cannot load machine code to a specified address, but my USB BASIC does - with LOAD "filename", <address>. This provides a safer way to load machine code rather than using an array whose address can change. To use this method with CAQ tape files you should first remove (using eg. a HEX editor) the 19 byte CAQ header, then save the file as raw binary.
×
×
  • Create New...