Search the Community
Showing results for tags 'GTIA'.
-
I was reading flashjazzcat's thread about his GUI project and saw his screenshots, and it got me thinking about artifacting (again). Artifacting, for those who aren't familiar with the term, is the effect on NTSC systems with a composite monitor where the LUM signal interferes with the COLOR signal, which causes half-size pixels to display with a colored "fringe". If you draw a whole row of even-numbered or odd-numbered pixels, you get one of two "fake" colors. By setting the background color to black and the foreground to white (or vice-versa), the effect is most pronounced. Anyway what got me thinking about it is, FJC showed (I believe) an 800XL with purple/green artifacting, and a 65XE with blue/orange. My XEGS does purple/green, and my old (long-dead) 800XL did blue/orange. I've also heard of yellow/blue though I've never seen it. So I'm wondering: what actually determines the color of the artifact? I doubt it's the (solely) IC because swapping GTIAs doesn't seem to affect it (with my limited sample set anyway). To answer this mystery I dug into the GTIA (and CGIA) data sheets to figure out exactly how this color timing works. Hope this comes out right: _____________ / LUM ------------------------------------------------------------------------------------------X LUM 0-F |<----------------------------------------------------------------------------------->|\_____________ | T(lum1) = Luma output delay (max 450ns) ___ | ________________________ __________________ \| / \ / OSC \ OSC low 140nS / OSC high 140nS \ / |\________________________/ \________________________/ | | T(inv) = Color output delay (max 190nS) |<-------------------------------->| ______________________________________|_________________________________________________________________ |/ COL / Color Reg = 0 (No color output) _____________________________________/ _________________________________________________________________________________________________ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ COL \ 1 \ 2 \ 3 \ 4 \ 5 \ 6 \ 7 \ 8 \ 9 \ A \ B \ C \ D \ E \ F \ \___\___\___\___\___\___\___\___\___\___\___\___\___\___\___\____ |<->| Δt = 16-25 You can see from the diagram the same thing I realized: the luma output for a given color clock comes much later than the color output! This seeming discrepancy is possibly explained by delay introduced by capacitance in the color output circuitry, which can work as an AC delay (technically [in a perfect capacitor] it causes the signal to be changed into the derivative of its input, for any calculus people out there). Now one thing you may be thinking is "What about the color adjustment pot?", which is a valid question. The CADJ signal is a voltage input to C/GTIA which adjusts the delta between different colors. Because this affects the delta, there is only one setting that is "right": too high or too low and your spectrum goes either above or below 360°. So given that only one setting is "right", it follows that you cannot change artifacting using this input without actually making "normal" colors incorrect. As you can see, every hue value corresponds to a 16-25 nS delay; thus a difference in delay of as little as 10s of nanoseconds in either the luma or color output can, without impacting normal color output, dramatically change the artifacting colors observed. So take this data and combine the fact that just about every Atari model (and, thanks to widespread modification, often multiple systems in the same model) has a different color output circuit, and the conclusion I come to is that the video output circuit used is a primary (if not THE primary) influence on the artifacting output. Interestingly when I added color output to my 600XL, I used the simple XE color circuit, and as a test I created a simple "composite" output by bridging the chroma to the luma via a capacitor, and observed the output - and the output was purple/green just like my XEGS with the identical color circuit. The only problem with my theory is the observations of FJC's demo output. He showed his 65XE with blue/orange and his XL with purple/green! This would seem to poke a big hole in my theory that I cannot explain - so FJC, did you happen to mix up the labels on those two screen grabs?
- 48 replies
-
- 2
-
- artifacting
- ntsc
-
(and 2 more)
Tagged with:
-
MusicStudio Engine for GTIA (source code) opt h+l+o+ gractl equ $d01d consol equ $d01f skctl equ $d20f dmactl equ $d400 nmien equ $d40e S_REG equ $f0 speed equ $f1 _channel equ $f2 ; 4 byte org $2000 run_adr sei lda #$00 sta nmien sta gractl sta dmactl music_studio_stack tsx stx S_REG ldx #$03 _lch lda _ch1,x sta _channel,x dex bpl _lch _loop lda skctl and #$04 bne _cont ldx S_REG txs rts _cont ldx #$00 _load lda (_channel,x) bpl _80_1 lda _ch1,x sta _channel,x lda _ch1+1,x sta _channel+1,x lda (_channel,x) _80_1 inc _channel,x bne _80_2 inc _channel+1,x _80_2 tay lda _nuty,y pha pha pha sec sbc #$01 pha beq _80_en1 lda #$08 _80_en1 pha lda #$00 pha txa eor #%10 tax bne _load tay ; =0 lda music_speed sta speed _iloop tsx _2kolej lda $0101,x sta consol dec $0105,x bne _2kl eor $0102,x sta $0101,x lda $0106,x sta $0105,x lda $0104,x cmp #$20 bcs _2kl inc $0106,x _2kl dec $0103,x bne _2kn lda $0101,x eor $0102,x sta $0101,x lda $0106,x sta $0103,x dec $0103,x _2kn txa ;clc ; too slow, replace with sbx ;adc #$06 ;tax sbx #$100-$06 ; +6 cpx S_REG bne _2kolej dey bne _iloop dec speed bne _iloop txs jmp _loop _nuty .byte $FF,$F0,$E3,$D7,$CB,$C0,$B4,$AB .byte $A1,$97,$90,$88,$80,$79,$72,$6C .byte $66,$60,$5B,$56,$51,$4C,$48,$44 .byte $40,$3D,$39,$36,$33,$30,$2D,$2B .byte $28,$26,$24,$22,$20,$1E,$1C,$1B .byte $19,$18,$17,$15,$14,$13,$12,$11 .byte $10,$01 music_speed .byte $0f _ch1 .word kanal1 _ch2 .word kanal2 kanal1 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $08,$14,$08,$14,$05,$11,$05,$11 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $08,$14,$08,$14,$05,$11,$05,$07 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $08,$14,$08,$14,$05,$11,$05,$07 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $08,$14,$08,$14,$05,$11,$05,$07 .byte $00,$0C,$25,$0C,$00,$0C,$25,$0C .byte $03,$0F,$25,$0F,$03,$0F,$25,$25 .byte $08,$14,$25,$14,$08,$14,$25,$14 .byte $05,$11,$25,$11,$05,$11,$25,$25 .byte $00,$0C,$25,$0C,$00,$0C,$00,$0C .byte $03,$0F,$25,$0F,$03,$0F,$25,$0F .byte $08,$14,$25,$14,$08,$14,$25,$14 .byte $05,$11,$25,$11,$07,$25,$25,$25 .byte $03,$0F,$25,$0F,$03,$0F,$25,$0F .byte $05,$11,$25,$11,$05,$11,$25,$25 .byte $00,$0C,$25,$0C,$00,$0C,$25,$0C .byte $0A,$16,$25,$16,$0A,$25,$0A,$25 .byte $03,$0F,$25,$0F,$03,$0F,$25,$25 .byte $05,$11,$25,$11,$05,$11,$25,$25 .byte $00,$0C,$25,$0C,$00,$0C,$25,$0C .byte $0A,$16,$25,$16,$0A,$25,$0A,$25 .byte $00,$0C,$25,$0C,$00,$0C,$25,$0C .byte $00,$0C,$25,$0C,$07,$05,$25,$25 .byte $00,$0C,$25,$0C,$00,$0C,$25,$0C .byte $00,$0C,$25,$0C,$07,$25,$03,$25 .byte $30,$30,$31,$30,$30,$31,$2D,$2D .byte $31,$2B,$2B,$31,$27,$31,$27,$31 .byte $30,$30,$30,$30,$30,$30,$2D,$2D .byte $2D,$2A,$2A,$2A,$27,$27,$27,$27 .byte $18,$1F,$18,$1D,$1F,$18,$22,$1F .byte $18,$1D,$1F,$18,$24,$1F,$22,$24 .byte $18,$1F,$22,$1D,$1F,$18,$22,$1F .byte $18,$1D,$1B,$1F,$1A,$1D,$16,$1A .byte $18,$1F,$18,$1D,$1F,$18,$22,$1F .byte $18,$1D,$1F,$18,$24,$1F,$22,$24 .byte $18,$1F,$22,$1D,$1F,$18,$22,$1F .byte $18,$1D,$1B,$18,$1A,$1B,$16,$1A .byte $ff kanal2 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $08,$14,$08,$14,$05,$11,$05,$11 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $08,$14,$08,$14,$05,$11,$05,$07 .byte $00,$0C,$25,$0C,$00,$0C,$25,$0C .byte $08,$14,$25,$14,$05,$11,$25,$25 .byte $00,$0C,$25,$0C,$00,$0C,$25,$0C .byte $08,$14,$25,$14,$05,$25,$05,$25 .byte $1F,$0C,$1F,$0C,$1D,$1F,$00,$18 .byte $03,$18,$1B,$18,$03,$18,$1B,$18 .byte $1F,$14,$1F,$14,$1D,$1F,$08,$18 .byte $05,$18,$1B,$18,$1F,$1D,$1B,$1D .byte $1F,$0C,$1F,$0C,$1D,$1B,$25,$18 .byte $03,$18,$1B,$18,$03,$18,$1F,$18 .byte $1F,$14,$1F,$14,$1D,$1B,$08,$18 .byte $05,$18,$1B,$1D,$1F,$1D,$1B,$1A .byte $18,$0F,$18,$0F,$16,$18,$03,$13 .byte $05,$18,$1B,$1D,$1F,$1D,$1B,$1D .byte $18,$0C,$1A,$0C,$1B,$18,$00,$1F .byte $0A,$1D,$1B,$1D,$1F,$1D,$1B,$1D .byte $18,$0F,$18,$0F,$16,$18,$03,$13 .byte $05,$1D,$1B,$1D,$1F,$1D,$1B,$1A .byte $18,$0C,$18,$1A,$1B,$18,$00,$1F .byte $0A,$1F,$1D,$1B,$1D,$1B,$1A,$16 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $00,$0C,$00,$0C,$07,$05,$03,$05 .byte $00,$0C,$00,$0C,$00,$0C,$00,$0C .byte $00,$0C,$00,$0C,$07,$05,$03,$02 .byte $30,$30,$30,$30,$30,$30,$2D,$2D .byte $2D,$2B,$2B,$2A,$27,$27,$27,$27 .byte $30,$30,$31,$30,$30,$31,$2D,$2D .byte $31,$2A,$2A,$31,$27,$31,$27,$31 .byte $18,$1F,$31,$1D,$1F,$31,$22,$1F .byte $31,$1D,$1F,$31,$24,$31,$22,$31 .byte $18,$1F,$31,$1D,$1F,$31,$22,$1F .byte $31,$1D,$1B,$31,$1A,$31,$16,$31 .byte $18,$1F,$31,$1D,$1F,$31,$22,$1F .byte $31,$1D,$1F,$31,$24,$31,$22,$31 .byte $18,$1F,$31,$1D,$1F,$31,$22,$1F .byte $31,$1D,$1B,$31,$1A,$31,$16,$31 .byte $ff org $2e0 .word a(run_adr) music_studio_stack.obx
-
Does anyone have or know of a complete list of ANTIC/GTIA graphics modes, in one place, to help developers make the right choice for a particular project? One that includes not only the "originals" (as in http://gury.atari8.info/ref/graphics_modes.php for example) but also the special ones discovered over time such as APAC, HIP, RIP, TIP and whatever else. Ideally including which color registers are used, limitations, tips, and any other pros and cons of each mode.
-
I have a hardware problem with Atari 800 XL. In every game that uses sprites they got corrupted after about 6 sec. since initializing them. In SysInfo there is a sprite collision test and it works, but soon after it finishes, garbage occurs: If I restart the test it works again fine. In River Raid, sprites become small letters of alphabet and player graphics is a full screen height column of capital letters (letter depends on the vertical position on the screen, so moving sprites scroll vertically across the alphabet): In Super Cobra it works for a while, but when it crashes for the first time, the heli crashes immediately after reappearing (it is a constant collision). In Pitfall II the demo doesn't scroll, and there is no character on the gamefield. All games work for ~6 sec. and then garbage appears on the screen. If I reset computer it works again for same time, and in SysInfo it is enough to re run the test, so it is unlikely to be thermal issue. I have swapped GTIA, RAM and OS ROM, but with no luck.
-
My friend has found an incredible treasure of 8 bit disks from the old Atari 8 Bit libray from our club in Kitchener, Ontario, Canada, in it are some disks from KWEST, some disks from TAF, and they were all stred inside an Indus GT case so they are in extremely good condition, don't yet know if they are readable. If some kind soul near by can send me a 5.25 inch drive for my old PC , (maybe my friend Don has one , but with my Windows 98 machine and a 5.25 inch drive I can back them all up with Omniflop and get them out in the community. Pleas if somene has an old 5.25 inch drive tat they are not using PM me and let me know if you want to part with it. Thank from the bottom of my heart, Russ Campbell
-
TRITONE (advanced beeper engine) is comming... played on GTIA: http://atari.pl/droid.mp3 http://atari.pl/ixerion.mp3 converter from .xm 2 GTIA soon
- 112 replies
-
- 21
-
I recently got my old first computer out of storage. It's a 130xe and it's been dead for 30 years, and I wanted to repair it. It shows a solid black screen when running. I ran a logic analyzer across a variety of pins on the system to see what seemed to be working. The address and data lines across all ram chips, the sally, antic, and gtia all seem to be good. The BASIC chip also has solid connectivity to these lines. The OS Rom chip was socketed by the former owner of the machine (I bought it in 1986 used,) and most of the pins on this socket aren't making contact to the address and data lines. This is likely the cause of the fault in the system. The socket doesn't seem to be gripping the pins very well and the chip comes out a bit too easily. But the other thing I found is that P5 on ANTIC, which goes to P20 on GTIA, and P23 on GTIA are all solid logic low, when the Sam's guide says they should be going back and forth between low and high. Most of the other pin the wave form is provided for seem to have good signals on the analyzer. (I don't have a scope to verify the waveforms though.) Would the OS chip being disconnected cause it to be a solid black screen all on its own, or could there be some other problems with the GTIA and ANTIC? I'm going to be ordering a new socket for that (and maybe a new ROM, just to be safe,) and wanted to order any other chips that could be bad at the same time so I don't need to wait around twice if the first thing doesn't fix it. (I already have sockets for the RAM chips, and new ram chips on the way, since I figured this is a common failure mode with a MT ram based 130xe's.)
-
This is a strange motherboard, runs for about two hours then locks up with video and audio random scrambles on the screen. When powered cycle it will run normally for another 1-2 hours. I tried swapping out the OS card, RAM, and POKEY with known working chips. The board was cleaned and so was the keyboard. Case was cleaned. A good candidate for retrobrite. It might be one electrolytic cap on the middle left of the main board that needs replacement. The keyboard port works, video port works, SIO port works, all the joystick ports work. Includes keyboard, power socket works. The electrolytc caps, and regulators on the power supply board were replaced and tested ok for voltages. Shipping from 98686 17lbs.
-
Wonder if you folks can help... I'm trying to restore a friend's 800, which is giving... well, just awful video. Using the RF mod, when powering on the 800, the screen definitely CHANGES, but the screen is close to static (you can almost see a distorted frame as the display cycles around). We attempted composite video from the 5-pin DIN, but didn't get much of a picture, although trying the O-scope on the composite port yielded the below picture; it's trying, but not giving a picture. We found the repair manual and followed the flowchart for grey/black screen, tracing all the clock pins (which all seemed to look OK). Pin 25 of the GTIA gives a nice clean (composite sync?) signal. Since the flowchart recommended replacing the GTIA, just in case, I bought a "known tested" CPU board from eBay, which gives the same results. So I don't think it's the GTIA, but maybe something in between it and the RF mod/DIN port. But I'm not sure what to check next. I found this schematic https://atariage.com/forums/uploads/monthly_06_2012/post-26063-0-46972400-1338873000.jpg, but it'll be mildly painful to trace the whole thing through and I'm not 100% sure what I'm looking for. Any suggestions for the next step? Thanks--it'd be quite a thrill to get this working again. Oh! One more clue (maybe?)--I haven't owned an 800, so I don't know; the speaker never seems to make any sound, either when powered on or when trying control-2 (which I hear buzzes). Is it supposed to? Not sure if that helps.
-
Hi, as some may know, I played quite a while with the A8 graphics modes to achieve unexpected output (like http://atariage.com/forums/topic/124933-new-true-color-mode/#entry1510330 or http://atariage.com/forums/topic/134852-atari-v-commodore/page-220#entry1737525). I never liked interlace or the scan line grille of APAC, so since several years I tried to cope with the restrictions and tried various things. Finally I have a result which I find convincing. The format is nothing really new, just works like HIP without interlace and can be coloured (the profile image of member 'pirx' seems to use this principle already), but I created a converter which is very easy to use, and at least I'm not aware of a similar one. Since I haven't found any description of this format in conjunction with a name, I named it 'JAG' (Just Another Graphics-(format)). The creation process is half automatic and a conversion takes about two dozens of clicks (colour assignments), which can be performed in a minute. (I had a fully automatic process, but results are less convincing.) When compared to RastaConverter (BIG LIKE!), the only disadvantages are the lower resolution and on NTSC systems the images are not that colourful, but the advantages are: * CO2 friendly: conversion is question of minutes * no affinity to banding (but depending on mode/selection slightly scan line grille) * no use of PMGs (less memory and DMA load) (and usable in game scenarios (even with limited colour possibilities) * simple to save & load * simple code for depiction * ATM moderate DLI load: converter supports a single palette for the complete image (this is subject to change, which can improve output quality a lot - depending on the input image) * easier to use in animation scenarios (generation is more 'stable', since available colours can be distributed more freely) * more shades (currently only the obvious theoretical 144 (9*16) per image, in the future all 256) There are still bugs in the converter I need to fix (some are detectable in the images below), output has to be beautified (e.g. top colour border) and I have to write some instructions too, but hopefully next week I can release V1 (if there is demand?). Have fun and stay tuned...
- 89 replies
-
- 13
-
I found my original 800xl from when I was a kid in the garage. Did not have a power supply so I picked up a 61982 off ebay. When I turn it on I see scrambled video and hear a buzz. This happens when I use the RF out and when using composite out via the monitor port. I recently had a similar issue with a 2600 and swapping out the TIA worked. Could this be as easy as replacing the GTIA or does the buzzing indicate another issue?
-
I'm away from a real Atari 8-bit computer and a scope, so I was hoping someone in the know can help me with this. What I am seeking is the typical audio output (at maximum volume, peak-to-peak voltage) straight out of POKEY's 'AUDIO' pin-37 with a typical 1K pull-up resistor, and the same for GTIA's 'BELL' pin-15. Thank you in advance, - Michael
-
Thanks to palettes that MrFish so kindly posted on another thread (here), it reminded me of this question: What would be some good universal palettes for 9 color gtia mode ? No Dli changes, no separate regions for different colors, any pixel can be any out of 9 colors. Besides going for simple solution similar to first 8 colors of C64 or Zx spectrum (Black, White, Red, Cyan, Purple, Green, Blue, Yellow) plus maybe Grey, what other combo would work well in some scenarios ? Something like platform game with lots of vegetation and earth would benefit from more brown and green colors. Something 'technical' in space would need more shades of grey for example. Bellow are example images scaled, cropped, converted to Atari pal palette and reduced number of colors to 9. My guess is that custom palette and new graphics could look even better. Turrican screenshot from Amiga: Dragon Ninja screenshot from Amstrad: What do you think ?
-
Since her sister Maria received new clothes and Stella received new clothes, it was only a matter of time. Download the Atari 5200 palette files here: Pam2XX_Palettes_20131108.zip The 'Pam' palette files are presented with the same options as the 'Maria' palette files. There is a "base" palette plus the following options: x0 = Saturation Increase x1 x2 = Gamma Increase and Saturation Deltas x3 x4 x5 = Gamma and Saturation Increase with Contrast Deltas x6 x7 x8 = Saturation Increase with Contrast Deltas x9 Also like the Maria and Stella palettes, we have Phase Shifts 24.7 through 27.7 degrees in 0.5 degree increments. In addition to palette files with the '*.pal' file extension, the complete set above is also presented with the '*.act' file extension (Used with Atari 5200 emulators such as Atari800Win Plus, Jum52, & kat5200). Phase Shifting examples follow utilizing the x0 [saturation increase only] NTSC palette in the following order... Pam247NTSCx0 --> Pam252NTSCx0 --> Pam257NTSCx0 --> Pam262NTSCx0 --> Pam267NTSCx0 --> Pam272NTSCx0 --> Pam277NTSCx0. Pole Position: Joust: The next few are highlighting the two ends of the phase shift spectrum and a logical 'middle' ground (See explanation below): Pam247NTSCx0 --> Pam262NTSCx0 --> Pam277NTSCx0 Astro Chase: Moon Patrol: Mr. Do's Castle: Ms. Pac-Man: Pitfall II: Here are examples showcasing the different options within each phase shift. Phase Shift 26.2 degrees is selected in this order: PAM262NTSC --> PAM262NTSCx0 --> PAM262NTSCx1 --> PAM262NTSCx2 --> PAM262NTSCx3 --> PAM262NTSCx4 --> PAM262NTSCx5 --> PAM262NTSCx6 --> PAM262NTSCx7 --> PAM262NTSCx8 --> PAM262NTSCx9 Frogger: Pitfall: Color Bars with Reference from PAM Diagnostic [sALT] Cart v1.1: Pam247NTSC --> Pam252NTSC --> Pam257NTSC --> Pam262NTSC --> Pam267NTSC --> Pam272NTSC --> Pam277NTSC. GTIA CHIP - NTSC C014805 Official Document Color Order: Atari 5200 Field Service Manual: Per the technical documents referenced above the following can be deduced: Directions were given for the color just below and above the (grey) reference bar to be within one shade of each other. Under the same reference document, directions are given for it to be the same color. Phase Shift 25.7 degrees - matching Hue 1x, 15x and the color below the reference grey bar fits making it the same color. Accounting for system 'warm-up'/phase shifting as well as the instructions for it to be within one shade of each other would make Phase Shift 26.2 a realistic logical choice. It also collaborates with the official document color order: Hue 1x = Gold, Hue 2x = Orange, Hue 15x/F$ = Light-Orange; Phase Shift 26.2 places Hue 15x/F$ between Hue 1x, gold and Hue 2x, orange; a light orange in color. Here is an alternative capture of the color bars from the PAM Diagnostic [sALT] Cart v1.1 with Phase Shift 26.2 degrees in place by utilizing the 'Pam262NTSC' palette within kat5200's NTSC video simulation mode along with a few game captures: (Click on the capture to remove some of the distortion) Hue 1x for NTSC is intended to be gold, not green-yellow/yellow-green. Gold is how Hue 1x appears under a CRT - the original and intended display device for the system. A green-yellow/yellow-green Hue 1x is how the NTSC 5200 palette is manipulated and modified (in part) under a modern flat panel (I.E. LCD/LED/Plasma) display. The above harmonizes with what has been documented for the Atari 2600 and Atari 7800 systems as well, regarding their NTSC color palette. Although there is no Atari 5200 PAL system the palettes offered in the download for the PAL region are theoretical ones based upon how the colors align under the Atari 7800 PAL system (Since Atari 5200 NTSC and Atari 7800 NTSC share essentially the same palette when viewed on a CRT). However, it should be noted that PAL 8-bit (400/800) Atari computer systems appear to provide the same - or an *extremely* similar - palette of NTSC Atari 5200 consoles displayed on a CRT. Additionally, that would also mean that Atari 8-bit NTSC and PAL palettes are the same (Or extremely similar) from at least the 'base' level. Once actually processed through display circuitry from their respective region as well as slight hardware system differences (There is an additional oscillator for 8-bit PAL systems driving color frequencies), other items such as NTSC color 'artifacting' would not be present under PAL. A thorough summary of Atari 2600/5200/7800 console system palettes is here.
- 1 reply
-
- 2
-
- atari 5200
- palette
-
(and 8 more)
Tagged with:
-
test version: http://atari.pl/veeblefetzer.mp3 http://atari.pl/veeblefetzer.xex about Phaser1: http://battleofthebits.org/lyceum/View/Phaser1
-
Hi, Let me present the new XXL's collection of tracks played by GTIA chip, called Beep'em All 5. It uses one of the newest 1-bit engines Phaser1 (in DIGI and SYNTH version). All the works from this collection were composed by Jredd with Beepola PC editor. Title screen was created by Odyn1ec, while the graphics of the "faces" synchronised with the music - by me There are 4096 different combinations of those “heads” and they were originally prepared for “Calamanis” game. The graphics had to be implemented in low-resolution mode (GR.3), otherwise sound quality would suffer. The controls (SPACE on the title screen - help): up / down - change of pace SPACE - DMA ON / OFF 1/2/3 - channels ON shift +1/2/3 - channels OFF ESC - return to the main screen “Beep'em All 5” can be downloaded from here code: Krzysztof "XXL" Dudek music: Trevin "Jredd" Hughes graphics: Odyn1ec, Adam Wachowski
-
Use Beepola (PC Tracker-like editor) http://atarionline.pl/v01/index.php?subaction=showfull&id=1390392565&archive=&start_from=0&ucat=1&ct=nowinki
-
New 1-bit GTIA player. 3-channels, samples (3-4KB LZ4 packed). http://atari.pl/stellar.mp3 music by MisterBEEP
- 10 replies
-
- 15
-
http://battleofthebits.org/arena/Entry/Baladinah+Monstra+2_+The+Robo+Party/11921/ and Atari GTIA version: http://atari.pl/zxbeep.wav zxbeep.xex
-
I have a CTIA Atari 800 that is in great cosmetic condition. I also have a later 800 that I'm using for parts, and I was wondering whether "upgrading" the CTIA on the original 800 would be as simple as swapping the CPU daughtercards (see photo). Or can I swap the GTIA for the GTIA directly? I'm not positive I want to do this because I like having the "original" CTIA 800, but I just wanted to know if I could. Thanks for any advice.
-
I was wondering if anyone might know some specific details about the PAL GTIA. The data sheets that are out in the wild seem only to cover NTSC. Here are my questions: From the schematics of various Ataris, it appears that the PAL pin acts as an input (?) for the PAL color carrier frequency line. Is this right? From my understanding, PAL switches color polarity every line and indicates this via changing the polarity of the color burst. Does the PAL GTIA do this? Does this manifest as every other line having inverted hue (i.e. 15-hue), or shifted hue (i.e. 7+hue%15), or what? Is the PAL color palette really substantially different from NTSC? On NTSC systems, the color clock (one gr.7 or 15 pixel) is 279.4 nS long. For color pixels (hue != 0), the COLOR line goes low at one of fifteen possible times, and the delta between each possible color can be (depending on the CADJ voltage level) anywhere between 16 to 35 nS (that's according to the various data sheets; though only values on or slightly below 18.6 nS would make for "correct" color output, as anything beyond that would result in higher color values bumping into the next pixel). On PAL systems, how does this timing work? Is it relative to the color carrier (PAL line?), or OSC like NTSC? If it's relative to the color carrier, does that mean the possible delay values are much shorter than 16-35 nS? Does anyone have any real-world timing measurements for PAL GTIA, or know of a PAL GTIA data sheet? Thanks in advance...
-
http://www.youtube.com/watch?v=_SPIG-pi4Ro&feature=youtu.be Gtia 1-bit Music 0:00-2:20 - Atascii (FastTracker > LyndonSharp Engine) 2:20-4:05 - Atascii ii (FastTracker > LyndonSharp Engine) 4:05-5:00 - Hurry! (1Tracker > LyndonSharp Engine) stuff: http://www.un8bg.com/stuff/g2012p1.atr http://www.un8bg.com/stuff/g2012p2.atr
-
Don't get too exited... This is just a very basic BASIC thing that does some simple system checks like revision info, GTIA check, audio output and things like that. For a much better tool you should get SI. Main purpose for me is to check what's in an XE, like what BASIC/O.S. revision it has and if it has the good or the bad GTIA and if the basic functions of pokey are working. It had to work on a system with no keyboard attached so the few available options can be selected with a joystick in either port #0 or #1. A connected mouse will probably cause issues. Just make it autorun from DOS when booted. SIMSYS.BAS