| cunningfellow | Posted: 7 Nov 2019, 08:31 PM |
|---|---|
 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:52 AM |
 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:36 AM |
 yeah whatever Admin Posts: 566 Joined: 4-May 16 |
QUOTE (cunningfellow)
What is the upper limit on number of lines you can draw? 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. 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:33 PM |
|
Member Posts: 5 Joined: 7-November 19 |
QUOTE (mit)
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:51 AM |
 I love mcus Member Posts: 237 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:54 AM ------------- |
| [top] | |
| cunningfellow | Posted: 10 Nov 2019, 06:05 AM |
|
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). 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:36 AM |
|
yeah whatever Admin Posts: 566 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
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.The Uzebox should not be able to draw vectors with only 4K of RAM ------------- |
| [top] | |
| cunningfellow | Posted: 10 Nov 2019, 08:52 PM |
|
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. 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:52 AM |
|
Member Posts: 5 Joined: 7-November 19 |
QUOTE (larsbrinkhoff)
I'd like to piggyback on this topic. 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:41 PM |
|
Member Posts: 2 Joined: 8-November 19 |
QUOTE (cunningfellow)
Lars, I was just doing a bit of googling and came across these pages. Thank you, Trammell Hudson's vector stuff looks great! ------------- |
| [top] | |
| mit | Posted: 11 Nov 2019, 08:56 PM |
|
yeah whatever Admin Posts: 566 Joined: 4-May 16 |
QUOTE (cunningfellow)
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] | |
| kaisersozehongbatemp | Posted: 16 Jan 2020, 01:51 AM |
 Member Posts: 11 Joined: 16-January 20 |
I just wanted to express amazement and admiration at this project. I wondered if you'd considered writing a arpeggiator, sequencer, or even a tracker; Or a game cartridge mounted MIDI socket to control the on board synth, perhaps with a vector GUI and a snes controller front end. There's a youtuber you may be interested in, he's more circuit bending, occupies a different space, but he has some really fascinating projects and I'd guess you have mutual interests and you'd be able to help each other out. Regarding your game console, I wanted to draw your attention to a post where he hacks a crt and a stereo amp to function as an XY oscilloscope https://www.youtube.com/watch?v=QWh4wcPNwgM Don't know if that hack could be bent to your purpose, but I think he will be incredibly interested in the methodology of your 'midi to squarewave synth in a cable' project. I don't know the guy, you'd have better luck giving him a shout than me, if you're bothered. He's in England, couldn't say where, maybe local enough to pop round for brew... ------------- |
| [top] | |
| DAVID | Posted: 18 Jan 2020, 07:21 PM |
|
I love mcus Member Posts: 237 Joined: 10-September 17 |
I never thought that i was going to see a LMNC fan in here but let´s get to the point. QUOTE (kaisersozehongbatemp)
I wondered if you'd considered writing a arpeggiator, sequencer, or even a tracker; Or a game cartridge mounted MIDI socket to control the on board synth, perhaps with a vector GUI and a snes controller front end. That could possibly be done in Mit´s vector game console, but instead of having a MIDI header on the cartridge you might be able to use the game controller port. But then the "on-board synth" (which it´s done through software) only has 3 square-wave generators and 1 noise chan. And the voices doesn´t feature any controls of any sort by default so they need to be written from 0. All of this will just add an awful amount of work to be done so maybe going with making a synth (and Mit has done that too in the past) instead of a game console will be a better idea, then you can just add the "video" part later. Last edit by DAVID at 18 Jan 2020, 07:22 PM ------------- |
| [top] | |
Sign in to post a reply.