mitxela.com forum
Welcome. Please log in or register.

Vector Game Console
cunningfellow Posted: 7 Nov 2019, 08:11 PM
Avatar


Member
Posts: 5
Joined: 7-November 19
What is the upper limit on number of lines you can draw?

Would a port of Tempest or Star Wars be possible?

-------------
[top]
larsbrinkhoff Posted: 8 Nov 2019, 07:11 AM
Avatar


Member
Posts: 2
Joined: 8-November 19
I'd like to piggyback on this topic.

I have an interest in recreating something close to the historical DEC Type 340 vector display. For short distances, it had an XY settling time of 1 microsecond, followed by 0.5 microseconds of illumination at one of 8 levels. Coordinate resolution was 10 bits.

So I'm curious if the vector console design could be extended to do this, or higher end parts would be necessary?

-------------
[top]
mit Posted: 9 Nov 2019, 09:11 AM
Avatar
yeah whatever

Admin
Posts: 209
Joined: 4-May 16
QUOTE (cunningfellow)
What is the upper limit on number of lines you can draw?

Would a port of Tempest or Star Wars be possible?

Anything is possible with enough effort and determination.

The display output is via two 8-bit DACs, so the screen resolution is 256 by 256, and the audio-grade op-amps limit the slew rate quite a bit.

QUOTE (larsbrinkhoff)
I'd like to piggyback on this topic.

I have an interest in recreating something close to the historical DEC Type 340 vector display. For short distances, it had an XY settling time of 1 microsecond, followed by 0.5 microseconds of illumination at one of 8 levels. Coordinate resolution was 10 bits.

So I'm curious if the vector console design could be extended to do this, or higher end parts would be necessary?

This is an interesting question and I'm not familiar with that vector display. The hardest part I suspect will be getting a big round CRT. An oscilloscope screen generally has a much, much better response time than the numbers you've mentioned, my scope is rated for 60MHz signals. I think this is due to the deflection method used (magnetic vs electrostatic?).

The game console would be a poor starting point due to its low resolution output and poor slew rate, but fit a couple of higher resolution DACs to a microcontroller and you'd be set.

-------------
[top]
cunningfellow Posted: 9 Nov 2019, 10:11 PM
Avatar


Member
Posts: 5
Joined: 7-November 19
QUOTE (mit)
QUOTE (cunningfellow)
What is the upper limit on number of lines you can draw?

Would a port of Tempest or Star Wars be possible?

Anything is possible with enough effort and determination.

The display output is via two 8-bit DACs, so the screen resolution is 256 by 256, and the audio-grade op-amps limit the slew rate quite a bit.


I might knock up copy of the hardware and see how I go.

I have done a back port of the 64 bit Tempest2000 Jaguar game down to the 8 bit Uzebox. https://www.youtube.com/watch?v=UnpNuFsHPSs

The Uzebox should not be able to draw vectors with only 4K of RAM. So doing it on a machine designed for vectors should be a walk in the park if it has a high enough draw rate.

-------------
[top]
DAVID Posted: 10 Nov 2019, 12:11 AM
Avatar
avrs + midi = best diy synths

Member
Posts: 211
Joined: 10-September 17
I just saw it and immediately became impressed by it. I never thought that an AVR was capable of making a somewhat 3d game while producing the music (and doesn´t get choppy).
How did you make this?
Was there already a base code containing some API´s for sound, video, game controller input, etc...
Was that 3d engine made from scratch?

Last edit by DAVID at 10 Nov 2019, 12:11 AM

-------------
[top]
cunningfellow Posted: 10 Nov 2019, 06:11 AM
Avatar


Member
Posts: 5
Joined: 7-November 19
QUOTE (DAVID)
I just saw it and immediately became impressed by it. I never thought that an AVR was capable of making a somewhat 3d game while producing the music (and doesn´t get choppy).
How did you make this?
Was there already a base code containing some API´s for sound, video, game controller input, etc...
Was that 3d engine made from scratch?

It is on a Uzebox. The Uzebox has a "kernel" with a lot of built in functions. These cover audio (3 channel sound + 1 noise). Playing Midi files. Reading SNES gamepads. A lot of general housekeeping.

Being in an ATMega644 it only has 4K of RAM so most the games are developed in video modes that are tile based. Tile graphics live in FLASH and the video pages are the only thing needing to be in RAM.

The Tempest clone uses a custom video mode I made just for that game though. 4K is not enough to have a full bitmap screen for the vector graphics so there are lots of tricks going on to get it happening.

256x224 pixels by 4 colours (2Bpp) would be 14K of RAM just for the screen.

The game is actually 5 colours on the screen with the dark blue webs being pre calculated and read from SD card.

The craziest trick however is actually bit banging out the NTSC video in this mode. The AVR only has five CPU clocks per pixel. So every five CPU clocks you have to read some RAM, make some decision on that RAM and output a value to PortC.

Apart from the video code, the line drawing routines and a couple of other things - most of the game is written in C.

There is nothing that is really 3D in the game - though the AVR has plenty of horses for doing 3D calculations.

-------------
[top]
mit Posted: 10 Nov 2019, 09:11 AM
Avatar
yeah whatever

Admin
Posts: 209
Joined: 4-May 16
The graphics on the Uzebox are really impressive. The vector output on my console is much simpler and more importantly, it doesn't really care if you mess up the timing.

QUOTE
The Uzebox should not be able to draw vectors with only 4K of RAM
I'm not sure if RAM matters too much for this - in fact, the ATmega128 in the vector console also only has 4K of RAM. It doesn't do anything like video memory, it just draws on the fly with various delay routines. There's no kernel and no interrupts at all while the game is running. The ATmega is clocked at just 8MHz, it sends the X,Y position to the DACs and then waits a few cycles before sending another coordinate. In most of the games, all of the logic happens at the start of the frame and the rest of the time is spent drawing, then it waits for the 60Hz timer to tick before starting the next frame. On menus and highscore tables and stuff, it doesn't even bother with 60Hz, it just starts the next frame as soon as it's finished the current one.

-------------
[top]
cunningfellow Posted: 10 Nov 2019, 08:11 PM
Avatar


Member
Posts: 5
Joined: 7-November 19
QUOTE (mit)
The graphics on the Uzebox are really impressive. The vector output on my console is much simpler and more importantly, it doesn't really care if you mess up the timing.

QUOTE
The Uzebox should not be able to draw vectors with only 4K of RAM
I'm not sure if RAM matters too much for this - in fact, the ATmega128 in the vector console also only has 4K of RAM. It doesn't do anything like video memory, it just draws on the fly with various delay routines. There's no kernel and no interrupts at all while the game is running. The ATmega is clocked at just 8MHz, it sends the X,Y position to the DACs and then waits a few cycles before sending another coordinate. In most of the games, all of the logic happens at the start of the frame and the rest of the time is spent drawing, then it waits for the 60Hz timer to tick before starting the next frame. On menus and highscore tables and stuff, it doesn't even bother with 60Hz, it just starts the next frame as soon as it's finished the current one.

Ah - I should have been clearer in what I meant. The AVR in the Uzebox should not be able to do those vector graphics on an NTSC screen in only 4K of RAM.

Yes just doing vectors out the X/Y CRT on a scope would be very light on RAM.

In fact the NTSC screen on the Uzebox games takes up 2944 bytes of the available 4096 bytes of RAM. So all the X/Y vector stuff in Tempest must have to fit into 1152 bytes.

Anyways - I will have to knock up some hardware to see how your true X/Y vector display looks on my scope. It only has a 640x480 LCD on it so won't look anywhere near as nice as a real CRT.

-------------
[top]
cunningfellow Posted: 11 Nov 2019, 05:11 AM
Avatar


Member
Posts: 5
Joined: 7-November 19
QUOTE (larsbrinkhoff)
I'd like to piggyback on this topic.

I have an interest in recreating something close to the historical DEC Type 340 vector display. For short distances, it had an XY settling time of 1 microsecond, followed by 0.5 microseconds of illumination at one of 8 levels. Coordinate resolution was 10 bits.

So I'm curious if the vector console design could be extended to do this, or higher end parts would be necessary?

Lars, I was just doing a bit of googling and came across these pages.

https://trmm.net/Vector_games_32c3
https://trmm.net/V.st

Which might suit you better.


-------------
[top]
larsbrinkhoff Posted: 11 Nov 2019, 12:11 PM
Avatar


Member
Posts: 2
Joined: 8-November 19
QUOTE (cunningfellow)
Lars, I was just doing a bit of googling and came across these pages.

https://trmm.net/Vector_games_32c3
https://trmm.net/V.st

Which might suit you better.

Thank you, Trammell Hudson's vector stuff looks great!

-------------
[top]
mit Posted: 11 Nov 2019, 08:11 PM
Avatar
yeah whatever

Admin
Posts: 209
Joined: 4-May 16
QUOTE (cunningfellow)

Ah - I should have been clearer in what I meant. The AVR in the Uzebox should not be able to do those vector graphics on an NTSC screen in only 4K of RAM.

Ah, that makes more sense. Good luck with the scope experiments, in my experience digital scopes really aren't great in XY mode. Nothing beats a good old CRT...

-------------
[top]

Sign in to post a reply.