Enterprise Forever
:UK => Hardware => Topic started by: gflorez on 2015.May.07. 15:26:03
-
Does he know something about the experimental "Sprite Generator" that utilises the Ext-Colour pins in the Expansion connector?
-
That is my interest as well.
-
I'm interested too,
however looking at these:
080h FIXBIAS
b0..b4
Colour bias to be used for top 5 bits of palette colours 8-15.
b5..b6
Controls priority of external colour inputs on EC0-EC3, allowing 16 colour sprites to be implemented. The external colour will only be selected when the /EXTC input is low and the display is active (not border)
=00
EC0-EC3 always select the corresponding palette colour.
=01
EC0-EC3 select the corresponding palette colour if the internal display is generating a palette colour in the range COL8-COL15.
=10
EC0-EC3 select the corresponding palette colour if the internal display is generating a palette colour in the range COL8-COL15 or the external colour is in the range COL0-COL7 (EC3 low).
=11
EC0-EC3 select the corresponding palette colour if the internal display is generating a palette colour in the range COL8-COL15 or the external colour is in the range COL0-COL3 or COL8-COL11 (EC2 low).
b7
VC1 output of the Nick Chip. Set it to disable the internal speaker in the Enterprise.
I fear that the sprite generator would work as the one the amstrad plus has (and that one is very limited I think)...
correct me if I'm wrong...
only 16 colors mode (what size of pixels?), fixed memory places (need to copy the data every time when you want to change the shape of the sprite), no zooming (like you can on the c64)...
-
only 16 colors mode (what size of pixels?),
I'm really sure it is possible in any mode.
And 99% sure 16 colors can be used in any mode for the sprites. For example the TEXT 80 use HIRES 2 graphics, and possible to use 8 colors. With the external color input don't need any trick just use the 4 bit data.
I'm not sure about the resolution. In 4 or 16 color mode the sprite resolution remain as in the 2 color mode, or also divided?
And I'm really sure nobody tried to use this function of the Nick :oops:
fixed memory places (need to copy the data every time when you want to change the shape of the sprite), no zooming (like you can on the c64)...
These are depend from the sprite hw.
I'm thinking about use Parallax Propeller chip (https://www.parallax.com/product/p8x32a-d40) for sprite hw. Just need some time for try it :oops:
I will ask Werner about the sprites, but I think he is also don't know anything.
-
About what I posted about amstrad plus hardware sprites... I should do some research before I post:oops:
Sprites:
Number: 16 high resolution sprites per line
Sizes: 16x16 (each sprite can be magnified 2x or 4x in X and Y)
Colours: Each sprite can use up to 15 colours
I'm really sure it is possible in any mode.
And 99% sure 16 colors can be used in any mode for the sprites. For example the TEXT 80 use HIRES 2 graphics, and possible to use 8 colors. With the external color input don't need any trick just use the 4 bit data.
What I meant earlier was that they'd be most probably always 16 colors (well 15 because one is for transparency?) independant of the screen mode.
I'm not sure about the resolution. In 4 or 16 color mode the sprite resolution remain as in the 2 color mode, or also divided?
I think that on the Amstrad+ the base sprite resolution (if no zooming) is the 2-color mode resolution but sprites use more colors...
However... I don't really know what I'm talking about anymore:???: ...
My point was that the info in nick documentation suggested me that the eventual hardware sprites that they would do for the enterprise would be very similar to the ones found later on the amstrad plus range (although that was going pretty far because there was only info about the 16 colors for sprites)...
And they're pretty bad from what I remember... For example you can't really multiplex them, and you need to copy data for changing the sprite matrix...
fixed memory places (need to copy the data every time when you want to change the shape of the sprite), no zooming (like you can on the c64)...
These are depend from the sprite hw.
oh...:oops:
I'm thinking about use Parallax Propeller chip for sprite hw. Just need some time for try it :oops:
I will ask Werner about the sprites, but I think he is also don't know anything.
:ds_icon_cheesygrin:
-
Does he know something about the experimental "Sprite Generator" that utilises the Ext-Colour pins in the Expansion connector?
I cannot remember any document or any circuit (diagram) about that matter - sorry.
-
I'm thinking about use Parallax Propeller chip (https://www.parallax.com/product/p8x32a-d40) for sprite hw. Just need some time for try it :oops:
Unfortunately it's still limited somewhat having "only" 32K of memory ("hub memory"), and externally added RAM is not so much fast enough for the propeller to fetch data from, I think. What would be simple and interesting: put a V9938 or something similar on the EXTCOL inputs. V9938 is familiar from the MSX world. It knows sprites but other things as well, and would allow for MSX softwares easier to port, etc. However that is not so much simple: first, you need to teach to the V9938 somehow to keep video signal in sync with Nick, where Nick is the "master". You can use Nick clock as the V9938 clock somehow, dunno it it can be done anyway. And oh, yes, I think V9938 has RGB analog outputs, not so easy to create 4 bits digital information from it. Also, some youtube video has been published with SymbOS/MSX using V9990 (gfx9000 or what was it) it can be done with EP too in theory to interface that chip, however again, it's much more realistic to have own separated video signal, rather than try to mix it back to the Nick via EXTcol inputs :(
-
What sprite chip? this (https://enterpriseforever.com/hardware/hw-sprites/msg46675/#msg46675)?
-
What sprite chip? this (https://enterpriseforever.com/hardware/hw-sprites/msg46675/#msg46675)?
Or Pear know some better magic with PLD chips :-)
-
I think he can do it... and more.... but first you must explain him what is needed.
-
How much information we have about the original "Sprite Generator"?
Seems that its integration on the EXOS 2.1 was already planned.
Can be that integration applicable or useful on another chip project?
-
Has anyone already tried to do sprite unit ?
Is there any specification or even the implementation on the emulator ?
How the sprite unit should be integrated with Nick ?
-
The designers of the Enterprise where also experimenting with a "Sprite Generator".
Some traces are still present, the /EXTC signal on the expansion connector, the C0-C3 bits on the FIXBIAS register of Nick, and the SPRITE system var(38) on EXOS 2.1.
Zozo can say more about that, but somewhere he has wrote that nobody(except Enterprise Computers) has tried those inputs of the Nick.
The original project is lost.
-
What we know:
Nick have a external 4 bit color input (16 colors): EC0-EC3 pins. And one control wire /EXTC which indicates the presence of external color on EC0-EC3.
Then Nick internal can mix the internal and external color informations:
-external color displayed instead the internal
-external color displayed if the internal are in COL8-COL15 range
-external color displayed if the internal are in COL8-COL15 range OR the external color in COL0-COL7 range (EC3 low)
-external color displayed if the internal are in COL8-COL15 range OR the external color in COL0-COL3 or COL8-COL11 range (EC2 low)
The last 3 modes can be used for mixing playfield elements (internal graphics) with sprites (external graphics).
What we don't know :oops: what will happen if send anything to these inputs. Probably only tested at the developers...
In 16 color graphics mode everything are logical. But what will happen in 2 or 4 colors mode?
I guess external 16 colors also can be used in 2 colors mode! Why? The Text 80 mode using hires 2 graphics with special settings, and 8 colors possible. Then I think very possible the Nick can read the external color information from the input pins at every pixel.
Firstly need some test electronics, which are send information to input pins, for example a simple counter of Nick clock will send a 00,01,...0E,0F. Then lets view which colors displayed in the screen.
My theory for the sprites:
The electronics will run on Nick clock (available on the bus). Will count the clock signals as pixel clock. The H and V sync also available on the bus, these can be used for reset the counters.
And if the counters in the sprite are then send the actual sprite pixel color to the EC0-EC3, and set EXT to low.
For store the sprite data probably some dual port SRAM are the optimal.
Then one sprite done :-)
For the next, more sprites, mixing these, how sprites move (CPU update the coordinates, or the sprite unit move these?), etc
Probably will be good make the sprite unit with similar features with exiting ones (MSX, CPC+, etc?) the easy can be ported existing sprite games.
Another usage (with more powerfull hw): the whole screen will be as "sprite". If my theory good then possible use 16 colors with hires 2 resolution! Add horizontal scroll features, which are really missing from the Nick...
Also possible more powerfull Spectrum emulation, the whole Spectrum screen genarated as "external ULA" then not need attribute conversion!
-
About the original "Sprite Generator" project, a similar project (https://enterpriseforever.com/hall-of-fame/en-vagyok-a-hibas-im-to-blame/msg33085/#msg33085) was impulsed but never released for the TVC(the Videoton, an Hungarian computer also designed by Intelligent Software).
The TVC had lower specs than the EP, but both where similar on hardware and mainly in software.
As the TVC computer was some years posterior to the EP, may be the EP sprite project was found on a dusty(big) drawer and recovered for the TVC.
-
Probably will be good make the sprite unit with similar features with exiting ones (MSX, CPC+, etc?) the easy can be ported existing sprite games.
I shouldn't be posting in such topics as I have no technical knowledge and no one likes when such wishlist starts but...
Please don't make the sprite hw work like the cpc+ one.
The sprite data are fixed so everytime you want to change animation frame you still need to copy data to the area.
I hope that the hw could work more like the c64 that the sprites can use the entire videoram and you specify which sprite matrix to use for given sprite. Can't remember how it was on the amiga... I think that there were registers that acted as 32bit data pointers for each sprite and sprites didn't have a fixed height but used a endsprite marker. But maybe I'm confusing something.
The sprite hw would have its own registers or could use only the free nick registers?
How would the sprites depend on the nick video mode chosen?
Or is it all depending on the sprite hw and "everything is possible"?
-
The external expansions ports of the TVC also have the /EXTC and other signals similar to the EP.
-
Sorry for the error, the original image has 9924x7014 pixels.
This is the schematics of the TVC expansion ports. They have the /EXTC pin and other necessary signals, like on the EP.
-
Please don't make the sprite hw work like the cpc+ one.
Ok :-) It is just a idea, because I not have any experience with these machines :oops:
Enought start thinking after one sprite displayed somewhere where we want :-)
The sprite hw would have its own registers or could use only the free nick registers?
It is will have own registers and/or memory area.
How would the sprites depend on the nick video mode chosen?
It is need to try it :-) my theory is: 16 color sprites can be also can be used in 4 and 2 colors mode. But need to verify the theory.
Or is it all depending on the sprite hw and "everything is possible"?
Yes. The Nick is only opening window in the screen, and what you see in this window will depend from the hw.
-
This is the schematics of the TVC expansion ports. They have the /EXTC pin and other necessary signals, like on the EP.
It is not a surprise, because the TVC also developed by the IS :-)
Prototype Sprite Modul exist. (http://tvc.homeserver.hu/html/sprite.html) But no more informations or schematic :-(
It is a real monster :-) But with today PLD technology will be possible in few chips. I hope it :-)
-
Seeing the photographs, it could be easy to follow the wires. It is complex but doesn't hide the connexions and components, all in sight.
-
Nice cabinet :shock:
There is nothing else like to think of the whole unit again :mrgreen:
At the moment I have started other projects, but I do not say "no" and the sprite unit join to the list.
-
I think that the sprite module works like a genlock, the objects are incrusted or mixed with the main image because they share the same synchronism. The collision have to be caculated by the programmer, because the module can't know where are the other objects on the main image, whith all the posibilities of modes and sizes.
On the Amiga computers there is also a genlock option, but a complete RGB signal is used for the mix.
I have found an experiment of a Spanish programmer. He created a Spectrum emulator, but also a virtual sprite chip...
https://translate.google.com/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=http%3A%2F%2Fwww.google.es%2Fsearch%3Fsclient%3Dtablet-gws%26safe%3Doff%26site%3D%26source%3Dhp%26q%3Dvirtual%2Bsprite%2Bchip%26oq%3Dvirtual%2Bsprite%2Bchip%26gs_l%3Dtablet-gws.3...1661.9200.0.10362.19.16.0.3.3.0.220.2423.0j15j1.16.0....0...1c.1.64.tablet-gws..0.15.1911...0j0i131k1j0i10k1j0i13k1j0i13i30k1j0i22i30k1.t3LacldGFPQ&edit-text=&act=url
Maybe we can begin doing the same.