1 Odpowiedź przez Rybags

(91 odpowiedzi, napisanych Sprzęt - 8bit)

What I would like for VBXE:

Translate function on Blitter.  Programmer supplies a 256 byte lookup table, and source data is used as index into table which selects each byte to write to destination.
With that we can then perform easy shift/rotate operations, the data is precalculated for us.  A 7 way set of Rotate lookup tables costs us less than 1.5 K

Graphics remapping function.  e.g. for doing C64 conversions, it'd be great to be able to just take 1 or 2 bit per pixel source data and have it automatically remapped to full byte destination per pixel.  Use of existing OR function allows easily giving each sprite it's unique range of colours.

ADD operation on 16-bit data.

Blit operation which loads data into a Palette.  As it is, it's not very practical to do pics with >1024 colours.  If a blit op could do a palette reload, then greatly increased colour range would be a reality.

I'd gladly give up 2 palettes to be able to do that stuff.

Idź do forum: Sprzęt - 8bit

2 Odpowiedź przez Rybags

(7 odpowiedzi, napisanych Scena - 8bit)

Here is the final release version, as was included in the VBXE 1.24 package.

Idź do forum: Scena - 8bit

3 Odpowiedź przez Rybags

(7 odpowiedzi, napisanych Scena - 8bit)

The game is almost finished, first release will be bundled with the Package for the 1.24 Core version of VBXE firmware, likely within days from now.

Due to a slight bug in the older VBXE firmware, upgrading will be necessary for the proper "look" of the game.  I tried a couple of workarounds with the older firmware version but they didn't work.

Also worth keeping an eye on the Altirra page, VBXE emulation is improving there all the time.

Idź do forum: Scena - 8bit

4 Temat przez Rybags

(7 odpowiedzi, napisanych Scena - 8bit)

Hi guys.

New game - conversion from Plus4 source code with thanks to original author "Csabo".

VBXE required, or use a recent version of Altirra (hires mixed in multicolour modes only works in 1.8 or later).

http://i3.photobucket.com/albums/y55/rybags/Atari/Quad1sml.jpg



Still in late development, spent about 30 hours over 2 weeks on it.

Idź do forum: Scena - 8bit

5 Odpowiedź przez Rybags

(544 odpowiedzi, napisanych Fabryka - 8bit)

Source code for interlaced pic loader http://users.tpg.com.au/rybags/Atari/ivb2.asm

It's for AtAsm.

Or, you can just use the loader code, but it will have my title text in it:
http://users.tpg.com.au/rybags/Atari/ivb2.65o

To use the loader code, create a file as follows:

1.  File ivb2.65o at start.  File has the necessary binary header for load address already.

2.  Append an init segment (2e2,2e3) with init address $5800

3.  Create a data segment of 768 bytes that loads at $7000-72FF.  Palette data is loaded into PAL1, should be stored as byte sequence of RGB,RGB.. etc - 256 entries covering colour 0-255.

3.  Create an init segment with INIT address $5803 - loader program has code to setup VBXE bitmap and load palette data into registers.

4.  Next up, the picture data.  The loader program clears enough VBXE RAM such that smaller pics will display OK, although won't be centred.
Since we're dealing with interlace, potentially the picture can be 320x480 bytes.
The picture data should be split into data segments of exactly 4K which are loaded to $8000-8FFF.  Each segment should be followed by an INIT segment which calls $5806.
Routine at $5806 increments VBXE bank so the picture loads sequentially.  Last segment of picture can be truncated without problems.

5. After picture data, an INIT segment to $5809.  This sets up interlace.

6.  Finally, RUN segment.  This can be your own program, e.g. to play music etc.  If you just want static pic, use $580C (endless loop).

Idź do forum: Fabryka - 8bit

6 Odpowiedź przez Rybags

(544 odpowiedzi, napisanych Fabryka - 8bit)

Zoomer is the next experiment on the way.

Idź do forum: Fabryka - 8bit

7 Odpowiedź przez Rybags

(544 odpowiedzi, napisanych Fabryka - 8bit)

http://i3.photobucket.com/albums/y55/rybags/Atari/MFalconxex.jpg

First interlaced pic from me... 320 x 480 using single 256 colour palette.

Downloadable here http://users.tpg.com.au/rybags/Atari/falcon1.zip

XEX should load from any DOS or menu loader.

Idź do forum: Fabryka - 8bit

8 Odpowiedź przez Rybags

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Final (hopefully) release of Stellar Shuttle 480i

http://users.tpg.com.au/rybags/Atari/Stelr480i.xex

Reworked load sequence so now should load with any DOS.
Title screen changed, 8x16 Font incorporated into game.
Annoying bug in original game where UFO sometimes flashed onscreen and killed player fixed.

Idź do forum: Programowanie - 8 bit

9 Odpowiedź przez Rybags

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Stellar Shuttle 480i - game revamped.

Doubled vertical resolution and 16 step rotation of the asteroids and rocks.

http://www.atariage.com/forums/index.ph … pic=147770

Idź do forum: Programowanie - 8 bit

10 Odpowiedź przez Rybags

(108 odpowiedzi, napisanych Programowanie - 8 bit)

You're free to increase resolution of both playfield and PMGs if and when you choose.

e.g. you could if you wanted have a Score/Status area done in Graphics 2 in it's normal resolution, have a play area in Multicolour character mode 4 using 2 character sets to double the vertical resolution.

You could have the Player's character in doubled vertical resolution too by storing to 2 PMG areas and toggling PMBASE each field.

If you don't utilise the added resolution, of course, you will notice a slight jittering, especially where there's great contrast between adjacent vertical pixels.

Using interlace is a little bit like the rules (horizontally) when using the hires 320 pixel modes, except this time in the vertical orientation ... lone pixels or lines don't always work the way you want - you're often better off doing lines 2 pixels thick.

Idź do forum: Programowanie - 8 bit

11 Odpowiedź przez Rybags

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Greetings all.  I've used Google Translate to read some of your posts with some success but I won't bother trying to use it to communicate in Polish (I've read it's not so great for that).

I started experimenting with the "Scanline 240 bug" which is a design fault in ANTIC, back around the start of this year.  I had thought for a long time that somehow it might be able to be exploited to give us an interlaced signal.  In fact in the past I'd tried various things but they mainly involved simply triggering the bug every second frame.

My first efforts involved just changing Color Register COLPF1 to see if anything could be achieved there... I soon found that to be the wrong approach.

The second approach I tried (with almost immediate success) was just a program that plugged some predefined Random numbers into DMACTL 3 times per scanline in the scanlines around VSync.
Once success was attained, the next step was to investigate just what I was doing... for that I used the PC soundcard for a while to read the video signal but 200 KHz sampling just wasn't enough so I had to go and buy and oscilloscope.

The whole interlace thing is possible thanks to Antic's little bug:  If the last line possible for the normal display is a 320 pixel mode, or if you interrupt a 320 pixel mode by turning off Playfield DMA at the right time (ie before the next DList Instruction is able to be read), then you trigger the bug.

What the bug means is that the AN2 line from Antic gets stuck on "1", which means that we have some control in the offscreen area over GTIAs behaviour so far as what it displays and when it sends HSync pulses.  We can simply force AN2 to toggle between 1 and 0 by changing the Playfield Width setting in Antic's DMACTL (typically bitsetting the lsbs to 00 or 11).

Just imagine the Playfield area if we're in "Widescreen" mode - pretty much within that area we can fool GTIA into sending a Sync Pulse.

During the 3 scanlines of VSync, we can also alter the signal.   What I do is the "simplest form" way I've discovered to force interlace.  The Atari by default doesn't create a standard VSync pulse train, however it seems it is sufficient for most TVs out there.

The standard Atari VSync signal actually does not contain pre or post equalisation pulses, and also doesn't use the half-scanline pulsewidth VSync pulses.  I've verified all this many times with an oscilloscope.

I earlier did a version that generates all the pre and post signals as well as the half-scanline width VSync pulses - a right mess of a program with lots of NOPs - I canned that version and started from scratch again because it was messy code.

This latest one simply changes DMACTL back to Wide Playfield during what should be the first half scanline of the first line of VSync, which is sufficient to force the next field to be the 1/2 Atari scanline offset.

Idź do forum: Programowanie - 8 bit