Search the Community

Fellows who have VBXE and use SDX + S_VBXE driver + 80-column CON: driver (CON.SYS), please enable the 80-column mode (CON 80 at the DOS prompt), then enter a BASIC interpreter (BASIC, TB, UBI), and run this program: 5 ? CHR$(125):A=PEEK(711) 10 FOR X=0 TO 15 15 FOR Y=0 TO 15 20 POKE 711,X*16+Y:POSITION Y,X:? CHR$(32+128); 25 NEXT Y 30 NEXT X 35 POKE 711,A If the display looks like this: and not like this: you have the CON.SYS driver to replace. Please try this one: vcon.zip (of course backing up the old one just in case).

It seems it's not clear to the public on how to use VBXE with VGA monitors, so i've made something to cover this hope this helps somebody. As mentioned in the document, VGA for PAL systems is hit and miss, especially with LCD monitor since most of them don't know how to handle 31khz HSYNC with 50HZ VSYNC signals - CRT should don't care and display it flowlessly, but i guess it's not the point. For NTSC regions this might be a perfect choice since there is no real RGB capable LCD monitors out there, and NTSC VBXE VGA generated signal is up to the specs for these and should pose no problems. happy hacking. Please read carefully whats in the documentation about RDY/CSYNC pin, and if you're unsure, or can't really solder - let someone else who can do it. FPGA chips are not that fragile, but still, they don't grow on trees and replacing one if damaged won't be plesant thing to do. vbxe2-vga.pdf

VBXE owners: do any of you have positive experiences with 15KHz RGB to HDMI converters, and if so, which models are recommended? I have a client who wants good video output over HDMI but since Sophia 2 is not available and he's interested in VBXE's feature set, he wants to go with VBXE. I can't really advise since I use SCART-enabled TVs and the only upscaler I own is a GBS-8200, which does a decent job of converting 15KHz RGB to VGA.

After this little discussion: it came to my mind that it should be fairly easy to reproduce this effect using mostly VBXE blitter with little CPU intervention, also making it moving. The result is attached (the archive also contains the source code @tschak909). PS. One of the darkest shades of grey looks blueish. A bug probably. PS. 2. On Altirra the movement does not look smooth, on real hardware it does. I do not know, why. landvbxe.arc

Sometime last year, I realized what great potential the VBXE has for BBS'ers. Having a full 256 character font, 80 columns, and the potential to support 8 background and 16 foreground colors means it could be used for a full ANSI/ECMA-48 terminal emulator. Right now, I have a demo program which does 80 column 16 color text on VBXE, with an IBMPC font (lots of ANSI BBS'es assumed this font for the extended graphics characters), interprets ASCII control codes (otherwise known as the C0 control character set as defined by the ECMA) and I just got scrolling done yesterday. It reads from a file right now, rather than an R: device. So I have zipped up the files with the source (don't copy without crediting me please) and put them here for people to see. ANSIVBXETERM.zip

I've got almost the entire Mines of Moria rogue-like game ported to the Atari, using VBXE and an Atarimax Flash 8Mbit cartridge. The only gameplay thing left to port is the "look" command. I will be adding joystick control, and a few other cosmetic things, and I will look into prerendering some levels and depacking from cartridge, as the random level generation is still around 30 seconds per level. I would appreciate any testing and bug reports though! Especially when it comes to the various spells, prayers, wands, staffs and potions and monsters. '?' brings up the help screen. CTRL-W enters wizard mode, which lets you cheat. CTRL-directions work in Altirra too, so you can use your direction keys (for up, down, right and left anyway.) A good page for Moria information: http://beej.us/moria/ The cart image is an Atarimax 8Mbit old style banking (cart 42 in Altirra). You need VBXE. The current colors are set for PAL. A couple of questions: What about colors of objects? I have some objects colored white and some blue. I couldn't decide whether to color all objects blue or white... monsters are currently red, which I think works fine. In some of the inventory screens there is a solid line below the inventory listing and in some there isn't. Which looks better? I restored some of the things I had initially changed (the history of messages are at 20 now), but monster recall/memories are currently not implemented. They will take a lot of memory and further cartridge banking, which may slow the game a bit. Are they important to the game play or not? (old moria players this question is for you.) Any questions or comments welcome. AtariMoria_55_alpha2.bin

I am not sure if anyone was doing it before... on ST there are the so called VT-52 demos, which in fact are text mode animations, and the "executable file" is a text file containing a stream of the VT-52 terminal emulator commands. On the ST you just "view" such a file to replay the animation. I have found four such animations on the net, and wrote a program for SpartaDOS X to replay them. Here is the archive containing the four animations and the player: vt52play.arc To run the player you will need SpartaDOS X 4.47 or newer, and an amount of memory in your Atari allowing to load the data files. The longest of them is ~180k so probably nothing less than 192k will allow to replay it. The player (VT52.COM) is a crude VT52 emulator, which translates VT-52 Escape sequences into the commands of the Atari 8-bit system console (the E: and K: devices). Like everyone else I of course realize that this task can be made a better way, so that the animation goes faster, smoother etc. but the point was that the originals use the system's console only feeding it with control codes. So the VT52.COM player does not touch any hardware I/O or such things, it makes the system console calls (sending ASCII data and control codes) only to accomplish the task. To run the player you basically type VT52 filename at the DOS prompt. There are some things to know about the particular animation files, though: 1) SCHNAH.TXT This is a B/W animation for the ST low resolution (40x24 text resolution, 16 colors). It can be replayed on the standard 40-column GR.0 console, because, as said above, it is originally black-and-white only. Having QUICKED.SYS loaded speeds the animation up. It requires about 95k of free RAM to get replayed. 2) SYNERGY.TXT This is a color animation for the ST low resolution. Therefore this one requires colors (6 colors, to be specific), but it still can be replayed on the standard 40-column GR.0 console, because the VT52.COM program, when it is running on the standard GR.0 display, maps different background colors onto different ASCII characters. As above, it is good to have QUICKED.SYS loaded. But if you have VBXE, better load S_VBXE and the CON driver attached here: Since it is a 40-column animation, before running the VT52.COM program do SET VT52COL=40 at the DOS prompt to tell the VT52.COM program that it has to take only 40 columns of the screen into account (this step matters in the 80-column mode only). The animation requires about 180k of free RAM to run. 3) FUJIBOIN.TXT This animation is done for the ST medium resolution (80x24, 4 colors), so no replay without VBXE and its drivers, sorry. Before running it, make sure that you have done SET VT52COL=80 (alternatively you can delete the variable). 60k free RAM required. 4) COMMANDO.TXT As above, this is for the ST medium resolution, so VBXE+drivers+SET VT52COL=80. Out of all four, this is the only one where having an accelerated Atari does not help: quite contrary, the stock speed helps to follow the, uhm, storyline. 100k free RAM to go. Have fun

How many mods has someone actually squeezed into a 600XL? I love the small size, but realistically I know there is limited real estate inside. It would be great to have everything: U1MB, VBXE, stereo pokey board, u-switch, TK-II or AKI, Rapidus, and I'd have to do the 64k and a/v mods. Is it doable or do I need to play it safe with a larger model?

This is very preliminary, and not everything works as it should, but it does do something... board is connected through standard vbxe breakout board for atari xe series that was soldered in as low as it was possible on CPU board, and then ribbon cable with male and female connectors was fed through the cutout in expansion bay plastic cover just under aluminium casting as for clock, you need to remove Q103 and connec a wire from VBXE 3.5mhz clock out signal to pin D of CPU board connector D6xx signal is present on pin P of SLOT3 expansion connector and all the other signal are provided by Incognito PBI connector for CSYNC, output from LUMA signal (R189) was used and this concludes current state of the installation do not treat this as a definitive guide, as just some things do work, but maybe some of you would like to try to install it anyways

Hi everyone, is anyone aware of an VBXE compatibility issue with the legendary "Great American Cross-Country Road Race" ? I usually don't experience any issues with my setup (130XE with VBXE) but I can't get it to work on my hardware. The games seems to start normal but after the introduction sequence with the credits, the screen turns into black and the game seem to crash. I know that a very very small set of atari games have indeed VBXE issues (for instance Gyruss). I don't recall the technical reason for it, but would be interesting to know though. greetings, twh

I'm slowly working through my VBXE install in an 800XL. I have it installed I think, and when I turn it on, the machine works and I have a picture (just composite for now). Unfortunately, it's in black and white. Where do I start troubleshooting? Here's a pic of the install (large picture!):

Atari Moria v55 beta2: - added joystick control (joystick is only read if at least two vblanks have passed, which seems to provide the right feel.) Joystick button can be used for most any key prompts. Joystick button and direction digs a tunnel. - fixed a few bugs, many are probably still there (report them if you see any!) - added a pause at startup to get better randomization. - added creating items to wizard mode (you'll need the source, or some of the information on Moria websites to do this properly.) - added a player structure display to wizard mode (Ctrl-C), to aid in debugging. - added the rest '*' command to rest until healed and mana restored The game is playable and should even be able to be completed in the state it's in. It seems to work well with CPU accelerators (in Altirra anyway!) Game Requirements: - VBXE - AtariMax 8mb flashcart (currently old style banking, bank 127 active at boot.) - 64k (uses RAM under the OS) AtariMoria_55beta2.bin

I am hooking up an Atari 130XE to a DLP video projector. Because of the large size of the projection screen, I need the highest quality video possible, which is the RGB output of the VBXE. However, I want to occasionally play games that use artifacting. Instead of using the noisy composite out, can I use the RGB through an RGB to composite converter to get artifacting? I know I could just use the composite out, but I would suspect RGB --> Composite will give a better result.

I'm choosing a host for my VBXE (Candle, V2), and I'm leaning toward a 64K, 600XL. Has anyone done this or know a reason why it would be more difficult than an 800XL or XE? -Larry

I am looking at installing a vbxe unit into a 600xl. should i do the video mod on the 600xl prior to installation of vbxe? Douglas

Who makes and sells VBXE...? Regularly with something resembling reliable response time? Is there an online store? US ideally, but if I have to go international, that's OK.

With all the sio2pc-usb mkII finished, I am opening the VBXE production run pre-order thread... Details: This will be a run of the VBXE V2, exactly as candle made the last run (well i am using his files, so they should be the same ;'). You will have a choice of NTSC or PAL (I need a PAL machine, anyone have one cheap ;'), and the latest standard firmware or the VGA firmware. As long as there is atleast 10 orders, these WILL be made, but the more who order, the cheaper it will be and prices are in US Dollars... pricing: Inside US/outside US (price includes priority international shipping) $150/$160 - for up to 30 total orders $140/$150 - for up to 50 total orders $135/$145 - for anything over 65 orders... Pre-Ordering will last until December 9th. that is when the final pricing will be known, if by some stampede there is more then 30 pre-orders, then refunds will be given to the final price (honestly, I hope there is more, but with the interest expressed in the past, i dont expect more then 10-15 orders...) Delivery estimate is currently the 2nd or 3rd week of January, I was hoping for sooner by ordering the PCB's already, but real life had other plans for me... If you have ANY questions at all please ask... Also, anyone in a country outside of the US, if you live near others, and can combine international shipping, this would lower the price immediately atleast on that part... sloopy.

Hi all, Two questions I've been speculating about - as someone not very deeply knowledgable (yet) on the hardware side of things... 1. Does a standard light-gun still work on a VBXE modified machine - on a CRT screen of course? Does VBXE modify the Atari's timing/syncing abilities, if the RF modulator is no longer present for instance? 2. A wider question... since especially with VBXE, LCD/projectors are commonly in use for us, I wondered whether it is at all conceivable/possible to interface to something like a Nintendo Wii controller with an Atari - hence light gun use on modern/very large projected screens - and without having to flash to a white screen to get enough contrast. It would be fun, but some way beyond my current skill to see whether or not there's any scope... Thanks, Wes

At SillyVenture 2k12 Lamers group presented simple intro called OldSchool in 16kB Intro Competition. Now we're proud to present remastered version for VBXE card It's just the beginning but we think it can be a good start to bring some life to the Scene in that area as a lot of people have that extension already. Let's support it! People that have no that luck to have it, can use Altirra emulator that emulates VBXE fully, or see it on . Pouet: http://pouet.net/prod.php?which=61078 Direct download: http://lamers.art.pl...school_vbxe.zip YT:

I am looking to have an option to have a game cartridge be able to detect VBXE and load the image into VBXE memory. I see a few samples use the DAP file format but I am trying to figure out how to convert to the format from a Windows BMP file. I am using GIMP to edit the sprites at the moment and will be divided up for each sprite.

Just in case anyone's interested, in my posting here, the attached program is capable of exporting compressed images. This is useful as a full screen VBXE standard resolution would be 80640 bytes if not compressed so it's a waste of disk/cartridge space. Currently, it uses deflate on 8kb blocks, although it will not compress a block if the compressed data comes out longer. This typically gives a 1/3 reduction in file size, but files from Amiga, C64 etc. give much better compression ratios due to the smaller palette count. For instance, this 320x200 picture would be 62.5k uncompressed: The PNG file is 30k, and the corresponding XEF file is 26.3k (I had to change the extension to .zip to upload): dotc.zip This format is currently in the less than useful position of not having an associated viewer on the Atari (although they can be previewed through the application, choose File | Open XeFlate...). I'm working on this at the moment, but if anyone would like to save me the trouble or comment on the format I'm working on, here are the details. The file is structured as follows: *************** * File Header * *************** Name Length (Bytes) Comment ----------------- --------------------- -------------------------------------------- Bits Per Pixel 1 Either 4 or 8 depending on the mode Graphics Mode 1 Values: 0x1F = VBXE standard 0x2F = VBXE low resolution 0x3F = VBXE high resolution Image Width 2* Width in bytes Image Height 2* Height in scan lines Block Count 2* The number of blocks of data in the file Palette Length 2* The number of palette entries in the file. If zero, the laoo.act palette can be assumed if the palette is not specified elsewhere. Palette Entries 3 x [Palette Length] The palette entries as (R, G, B) three byte tuples * Low byte first Then, there are [block Count] blocks, as follows: ********* * Block * ********* N.B. The data is currently compressed so that each block is <= 8kb in length when uncompresssed, due to the 8k bank switching arrangement used by VBXE this seemed expecient! Name Length (Bytes) Comment ----------------- --------------------- -------------------------------------------- Compression Type 1 The compression method used: 0x00 = None 0x01 = Deflate Further methods will be added e.g. RLE Compressed Length 2* The length of the block's data, in bytes, not including the 3 block header bytes. Data [Compressed Length] The block's data * Low byte first The following C# snippet illustrates loading an XEF file into a Windows Bitmap: // Read the file header // Mode byte bitsPerPixel = r.ReadByte(); byte graphicsMode = r.ReadByte(); // Size ushort imageWidthBytes = (ushort)(r.ReadByte() | (r.ReadByte() << ); ushort imageHeightScanLines = (ushort)(r.ReadByte() | (r.ReadByte() << ); int width = imageWidthBytes * (8 / bitsPerPixel); int height = imageHeightScanLines; byte blockCount = r.ReadByte(); // Palette (if specified - otherwise, assume the default VBXE palette) ushort paletteLength = (ushort)(r.ReadByte() | (r.ReadByte() << ); Color[] palette = null; if (paletteLength > 0) { palette = new Color[paletteLength]; for (int color = 0; color < paletteLength; color++) { byte red = r.ReadByte(); byte green = r.ReadByte(); byte blue = r.ReadByte(); palette[color] = Color.FromArgb(red, green, blue); } } else { // Otheriwse, use whatever colors we've currently got loaded palette = Atari.Colors.BrushColors; } int x = 0; int y = 0; Bitmap result = new Bitmap(width, height, System.Drawing.Imaging.PixelFormat.Format24bppRgb); // Read the blocks for (int block = 0; block < blockCount; block++) { // Get the compressed length byte blockCompressionType = r.ReadByte(); ushort blockLength = (ushort)(r.ReadByte() | (r.ReadByte() << ); System.Diagnostics.Debug.WriteLine(string.Format("Block {0} -> {1} bytes ({2})", block + 1, blockLength, Enum.ToObject(typeof(BlockCompressionType), blockCompressionType))); byte[] compressed = r.ReadBytes(blockLength); byte[] decompressed = null; int decompressedLength = 0; // On Atari - switch in the correct bank from VBXE memory and decompress to there switch (blockCompressionType) { case 0x00: // Uncompressed - copy straight to VBXE bank decompressed = compressed; decompressedLength = blockLength; break; case 0x01: // Deflate - http://atariarea.krap.pl/x-asm/inflate.html decompressed = new byte[0x2000]; using (MemoryStream ms = new MemoryStream(compressed)) { ms.Position = 0; using (DeflateStream ds = new DeflateStream(ms, CompressionMode.Decompress, true)) { decompressedLength = ds.Read(decompressed, 0, 0x2000); ds.Close(); } } break; } #region Plot the data on the bitmap (obviously redundant on Atari!) for (int i = 0; i < decompressedLength; i++) { result.SetPixel(x, y, palette[decompressed[i]]); x++; if (x >= width) { x = 0; y++; } } #endregion } #region Set the pixel aspect ratio (or set the XDL on Atari!) switch (graphicsMode) { case 0x1F: // Vbxe standard break; case 0x2F: #region Vbxe Low Resolution - rescale to 2 x width Bitmap scaledUpBitmap = new Bitmap(result.Width * 2, result.Height, result.PixelFormat); using (Graphics graphics = Graphics.FromImage(scaledUpBitmap)) { graphics.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.NearestNeighbor; graphics.CompositingMode = System.Drawing.Drawing2D.CompositingMode.SourceCopy; graphics.CompositingQuality = System.Drawing.Drawing2D.CompositingQuality.HighQuality; graphics.PixelOffsetMode = System.Drawing.Drawing2D.PixelOffsetMode.HighQuality; graphics.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.HighSpeed; graphics.DrawImage(result, 0, 0, scaledUpBitmap.Width, scaledUpBitmap.Height); } result.Dispose(); result = scaledUpBitmap; #endregion break; case 0x3F: #region VbxeHighResolution - rescale to 1/2 width (Windows doesn't like rectangular pixels) Bitmap scaledDownBitmap = new Bitmap(result.Width >> 1, result.Height, result.PixelFormat); using (Graphics graphics = Graphics.FromImage(scaledDownBitmap)) { graphics.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic; graphics.CompositingMode = System.Drawing.Drawing2D.CompositingMode.SourceCopy; graphics.CompositingQuality = System.Drawing.Drawing2D.CompositingQuality.HighQuality; graphics.PixelOffsetMode = System.Drawing.Drawing2D.PixelOffsetMode.HighQuality; graphics.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.HighQuality; graphics.DrawImage(result, 0, 0, scaledDownBitmap.Width, scaledDownBitmap.Height); } result.Dispose(); result = scaledDownBitmap; #endregion break; } #endregion return result;