Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Vectrex32

Pages: 1 2 [3] 4 5 ... 8
General Discussion / Re: Development on PC environment possible?
« on: April 19, 2017, 10:32:46 PM »
You can run V32 programs on the Vectrex without having it connected to a PC. Just copy a BASIC program to the V32's flash. If its name is autorun.bas, it will run when the Vectrex is turned on, regardless of whether a PC is connected. Alternatively, you can use the autorun.bas program that comes with V32; it displays a menu of all the BASIC programs on the V32 and lets you select one and run it.

Having the V32 send 6809 code over the USB to the PC is problematic, not just because of USB's speed but because Windows is not a real-time operating system; there's no guarantee that Windows will read the USB 30 times per second. In any case, it would be simpler to port the V32 code to Windows and have it interact with a Vectrex emulator.

"Simpler" is a relative term, though. It would still be a lot of work.

- Bob

General Discussion / Re: Development on PC environment possible?
« on: April 19, 2017, 09:42:55 AM »
I actually don't think it would be too hard to build a nice graphical environment for the Vectrex32 to combine both terminals into one. If I have time after these blasted exams are done I'll write it in Java and post the source to Git. I may even be able to put it into Eclipse, haha.

Check out VIDE first to make sure it isn't already doing what you want. If it does not do what you want, one possible approach is to work with Malban to add the features.

Allow the thing to run off of USB power! That way 90% of testing can be done with the Vectrex off

I've thought about this, and I've even experimented with it. But how useful would it really be? You could run the program, but you wouldn't see any of the shapes or any of the motion, you wouldn't hear any sound, you couldn't feed it any input. All it would really do is check your program's syntax.

- Bob

News and Updates / Vectrex32s available for purchase
« on: April 04, 2017, 04:31:06 PM »
I have ten Vectrex32s available for purchase. If you'd like one, you can buy it here.

- Bob

General Discussion / Re: 3D frustum clipping
« on: January 11, 2017, 09:00:23 AM »
Oh cool, but if it can go behind the camera and look right surely there must be more to it than just doing the perspective and then clipping in 2D? Plus there's the risk of division by zero if a point has the exact same z coordinate as the camera?

Right. It's a different chunk of code doing the behind-the-camera clipping.

Please keep us up to date on your Vectrex32 work. It sounds interesting.

- Bob

General Discussion / Re: VIDE Support?
« on: January 11, 2017, 08:47:43 AM »
Malban can address this better than I can, but I believe it offers a text editor that you can use for writing the program, a file explorer for viewing the files on the Vectrex32, and a terminal emulator for typing commands to the Vectrex32.

You would not use VIDE's Vectrex emulator while developing V32 games.

- Bob

General Discussion / Re: 3D frustum clipping
« on: January 10, 2017, 10:50:00 PM »
I was thinking of writing a Tail Gunner game which would have enemy spaceships flying towards and then behind the camera. So I wrote the Vectrex32 code to do the necessary clipping of a line that goes behind the camera. Don't write your own frustum clipping until you test the built-in capabilities.

- Bob

General Discussion / Re: 3D frustum clipping
« on: January 10, 2017, 11:17:22 AM »
Vectrex32 has a clipping feature for 2D sprites. The way to do 3D fustrum clipping is to apply the 2D clipping feature to the view, after the perspective transform has been done (since, after the perspective transform, 3D sprites have been flattened to 2D). In the Vectrex32 manual, see sections 7.9.5 and

- Bob

News and Updates / Version 1.14 Released
« on: December 12, 2016, 01:16:32 PM »
Version 1.14 has been released, with new features, a new game, and a new video. If you already own Vectrex 1.10 or newer, you can download the firmware here. If you still have version 1.00, please read this.

Feature Requests and Bug Reports / Re: Frustrated
« on: November 19, 2016, 10:40:20 AM »
Hi Pic,

I've fixed the problem and released a firmware upgrade, version 1.13. I'm now able to load and run your program, even with that large, memory consuming test function you added. You can download the firmware from and follow the instructions to install it.

Keep in mind that Vectrex32 compiles your BASIC program into an intermediate form that consumes a lot more memory than the BASIC code itself does. Still, I was able to find several opportunities for reducing memory usage.

I'm a little puzzled by the way you make Lines sprites. You create arrays with "M" and "D" values, then copy them into new arrays, replacing the strings with MoveTo and DrawTo. MoveTo and DrawTo are just built-in constants that are the integers 0 and 1; they consume a lot less memory than the strings "M" and "D". Creating new arrays and copying the values over also uses memory, time, and complicates your code. Why not just define the original arrays with MoveTo and DrawTo?

My only guess is that you were trying to reduce the amount of typing. But if this is the case, you could create global variables M = MoveTo and D = DrawTo, and use those when creating the arrays.

BTW, when I ran your game, it looked very intriguing. I'm looking forward to seeing the finished product.

I hope this helps.

- Bob

News and Updates / Version 1.13 Released
« on: November 19, 2016, 10:24:47 AM »
Version 1.13 has been released. There are no new features, but memory usage has been improved to allow larger programs.

You can read more about it here and download it from here.

Feature Requests and Bug Reports / Re: Frustrated
« on: November 17, 2016, 04:06:51 PM »
I am able to reproduce the problem. I'm looking into it.

- Bob

General Discussion / Re: Vectrex side processor in the 2K shared space.
« on: November 16, 2016, 08:05:39 AM »
But there are a lot of line drawing series optimizations you can do on the server side.

I wouldn't want to try that in Vectrex32 code. If the user has two lines in a sprite, they are guaranteed to be joined at an endpoint. If you split those lines apart in an attempt to optimize, that connection will not be perfect. Also, to avoid pen drift, you need to return the pen to the origin periodically.

It's certainly something you can experiment with in BASIC (same for your raster graphics idea) but I wouldn't implement it in firmware.

- Bob

General Discussion / Re: Vectrex side processor in the 2K shared space.
« on: November 15, 2016, 11:08:15 PM »
Is real space time curved?  Yes, it has virtuial particals stored in it.  The larger mass you have the more virtual particles you can store on short time frames.  Thus gravity comes from increased density of virtuial particals creating extra energy in local fields.  But if they don't effect the magnetic field then you can find a splitting.

I don't know how late it is in your part of the world, but I think you're getting a little punchy. Time to log off and go to bed. ;-)

- Bob

General Discussion / Re: Vectrex side processor in the 2K shared space.
« on: November 15, 2016, 11:05:02 PM »
There's 2K of shared memory. Subtract a bit for overhead and assume three bytes per vector or pen movement, and you've got maybe 500 lines. You need to refresh at 30 frames per second or better to avoid flicker. So that's 15,000 lines per second. I'm pretty sure the Vectrex analog circuitry is nowhere near fast enough to do that.

I don't think the sort of analysis and optimization you're thinking of is really necessary (and of course, I wouldn't expect typical BASIC programmers to want to get into that sort of stuff).

- Bob

General Discussion / Re: Vectrex side processor in the 2K shared space.
« on: November 15, 2016, 10:41:34 PM »
In some frames, you might draw a lot of lines. In other frames, you might draw only a few. And yet it's important that the frame rate be constant (otherwise the apparent brightness of the lines would vary). So even if I could look at a drawing list and figure out how long the 6809 will take to draw it (which would be a very difficult thing to do) it would not be a good idea to adjust the frame rate based on that.

- Bob

Pages: 1 2 [3] 4 5 ... 8