Jump to content
IGNORED

Atari++ with VBXE supported released!


candle

Recommended Posts

Long waited support for VBXE graphics card is now released including source code

 

you can download it from here

 

Candle,

Are there any sample programs that we can use to try out the VBXE extension?

LMAO :D

 

*** D'oh - that's not the link I thought it was. It's past my bedtime.

Use this link fro mpost #26 http://www.atariage.com/forums/index.php?a...t&id=130093

Also http://spiflash.org/files/vbxeslide.zip

 

Stephen Anderson

Edited by Stephen
Link to comment
Share on other sites

and with the latest 1.55 build the test atr crashes with illegial opcode?

I get the same thing. CPU crashed at $f2b3 due to Illegal opcode $02

 

Stephen Anderson

 

DOS II+/D 6.4 installed in this image requires original Atari OS (due to illegal calls as I presume). Just mount the image as D2: and boot from other disk.

Link to comment
Share on other sites

I get the same thing. CPU crashed at $f2b3 due to Illegal opcode $02

DOS II+/D 6.4 installed in this image requires original Atari OS (due to illegal calls as I presume). Just mount the image as D2: and boot from other disk.

 

Actually, the vbmp.com app also crashes with the built-in Atari++ OS, so you need the real atarixl.rom for that even if you're loading it from D2:

Link to comment
Share on other sites

Hello peteym5

 

Maybe if we used carts big enough to include both VBXE and Standard Graphics versions.

You can put a lot of code on a 16MB partition/ATR. Which you can put on a USB-stick, SD-card of a CD-ROM. All of these can be used with an Atari 8 bit computer.

 

greetings

 

Mathy (who has to admit that it's been a while since he booted his Atari off of a CD-ROM which was specially burned for this purpose)

Link to comment
Share on other sites

  • 3 weeks later...

I've updated the emulation.

 

Built against Atari++ 1.56.

Emulates interlace mode invented by Rybags (but currently odd frame detection is trivial and might detect bad frames that won't work on real hardware).

Fixes bug crashing emulator when referencing VBXE memory should wrap around (Thanks to DamageX).

Patched sources should now compile under linux. X11 is not supported though -> ./configure --disable-X11 (Thanks to Urchlay).

Atari__VBXE_build_205_.zip

Link to comment
Share on other sites

I just got the message from candle about this latest release.

 

Re detecting Interlaced field...

 

On the real machine it requires 2 things:

- initiation of the "scanline 240 bug". This is done in one of 2 ways. If the last scanline of normal display is in a hires mode.

or, if the last Display List instruction is for a hires mode, and DMACTL is set such that no further DList Instruction fetches are performed.

 

AND

 

- half scanline extension of "blank level" in the first scanline of VSync. This is done by my routine by setting DMACTL lower 2 bits to "11" - then around halfway through the scanline back to "00".

 

I also create the extra HSync pulses at the midpoint of the following 2 scanlines, which closer approximates a "real" interlaced VSync sequence, but my feeling is that the above 2 criteria are more than enough to detect an interlaced field in emulation.

 

I'm not sure how laoo does it and haven't checked it out in the emu... but the picture he posted over at Atariarea.pl seems to confirm it's working.

Link to comment
Share on other sites

I've updated the emulation.

 

Built against Atari++ 1.56.

Emulates interlace mode invented by Rybags (but currently odd frame detection is trivial and might detect bad frames that won't work on real hardware).

Fixes bug crashing emulator when referencing VBXE memory should wrap around (Thanks to DamageX).

Patched sources should now compile under linux. X11 is not supported though -> ./configure --disable-X11 (Thanks to Urchlay).

 

Sorry that I haven't reacted earlier, but I'm currently completely snowed under by work, and haven't had any time to look into that. Would it be possible to submit a patch so I can move that back into the main development branch? Sorry for the delay, as said, too much work here (my current statistics say that I'm approximately one week at home in this summer - and greetings from the San Francisco Bay area, BTW - I'm not here for vacation, unfortunately.)

 

So long,

Thomas

Link to comment
Share on other sites

Any word on when color ram scrolling will be implemented?

 

I need test suits. When someone will write a code using these features I'll write support to it.

 

Re detecting Interlaced field...

 

On the real machine it requires 2 things:

- initiation of the "scanline 240 bug". This is done in one of 2 ways. If the last scanline of normal display is in a hires mode.

or, if the last Display List instruction is for a hires mode, and DMACTL is set such that no further DList Instruction fetches are performed.

 

AND

 

- half scanline extension of "blank level" in the first scanline of VSync. This is done by my routine by setting DMACTL lower 2 bits to "11" - then around halfway through the scanline back to "00".

 

I also create the extra HSync pulses at the midpoint of the following 2 scanlines, which closer approximates a "real" interlaced VSync sequence, but my feeling is that the above 2 criteria are more than enough to detect an interlaced field in emulation.

 

I'm not sure how laoo does it and haven't checked it out in the emu... but the picture he posted over at Atariarea.pl seems to confirm it's working.

 

Currently I've implemented very primitive method for detecting odd frames that works for superset of situations that really force interlace on real hardware. I'll be working on narrowing it in the near future. I'm sampling DMACTL in CPU cycles 25 and 75 for lines 275, 276 and 277. 6 samples. I do detect odd frame when samples 2-6 are all the same and sample 1 is different :) I've warned it's primitive :)

 

[...]Would it be possible to submit a patch so I can move that back into the main development branch? [...]

 

VBXE is quite incompatible with traditional 256 color atari display and requires screen of resolution 672*480 true-color pixels, therefore I needed to assert many constraints on the display that practically cripples the emulator. For seamless intergration with main branch many parts would needed reimplementation. I'll try to work on it.

Edited by laoo
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...