Iron - About the inexhaustible possibilities of NeoGS.

 NeoGS can do more!                      
 yu Alone Coder                         
                                                                
NeoGS has a CPLD that is only partially filled. Yes        
source codes (by Lord Vader), which I don’t understand anything about. Yeslm  
if there was a fan, we could put a mathematical one in there    
coprocessor - for example, to spin a much nicer 
3D than in The Link demo. I'm not just talking about lighting. B    
in particular, for normal 3D you need textures of at least 128x128, 
and with the possibility of looping or cutting off overflow,  
moreover, they must be pulled onto the object, and not onto        
a separate edge. Large resolutions, clipping/looping -   
all this is inconvenient for the Z80, but convenient for the CPLD. And in general,       
with a coprocessor, the speed of calculations and rendering will jump      
several times.                                                
                                                                
Communication with the coprocessor is via ports with 8-bit addressing, 
something like this:                                                   
ld a,h                                                          
out (port1),ald a,l                                                          
out (port2),a                                                   
ld a,d                                                          
out (port3),a                                                   
ld a,e                                                          
out (port4),a                                                   
in a,(port5)                                                    
                                                                
The coprocessor counts several results simultaneously, puts  
them into different registers. They can be read from different ports.      
                                                                
Signed arithmetic is required.                               
                                                                
I would like to be able to read the value with a shift (have 
a bunch of ports from which it is read with different shifts).           
                                                                
You may need to be able to write to the Nth byte of the register with  
by clearing all lower bytes of this register or writing with
spreading the sign to all higher bytes of this         
register.Possible tasks:                                               
1. JPEG Decoding                                           
2. Coordinate spinner with perspective                            
3. Recalculation of polygon parameters (different for different shaders) -  
requires branching or sorting 3 records                      
4. Tekctypuhr                                                   
5. Blitting                                                     
The bow can also be accelerated - instead of 37 clock cycles (pop hl:add hl,bc: 
ldi) get ini+three memory accesses.                       
                                                                
Blitting:                                                       
We cannot intercept the recording, but we can give an already superimposed    
byte. According to ini (from a specific port), the following happens:     
                                                                
Tl=(RA++)                                                       
Th=(RB++)                                                       
The contents of the cell (ThTl) are displayed - the most significant bits of the address are taken from
a separate central register.                                        
                                                                
This is a special case of the "tile tekctypuhr" operation               
(withdU=dU`=256, dV=dV`=1), but the task of clipping sprites is here 
not resolved.                                                      
                                                                
JPEG decoding requires faster operations:                  
1. IDCT, 2. bit decoding, 3. YUV->RGB conversion.      
IDCT requires a bunch of registers (with summation of products),   
either DMA or the ztnik will stick it in and out all the time  
data. We need to find the optimal number of registers and                
sequence of actions for the last option.            
Bit decoding:                                        
1. “read byte” (produces Rb; Rb=(RA++); RC=8) - to          
free the register pair.                                    
2. “read bit” (produces Rb; Rb<<=1; RC--; if RC==0, then       
Rb=(RA++),RC=8) - so that you can inf:jp p or                 
in l,(c):add hl,hl.                                             
                                                                
Tekctypuhr:                                                     
By ini (from a specific port) the following happens:U+=dU (16-bit with overflow cut-off at 14(15) bits,   
i.e. when overflowing upwards, the result is 63(127)+most significant bits, when
overflow down - 0+high bits)                             
V+=dV (16-bit with overflow cut-off at 14(15) bits)   
The contents of the cell (VU) are displayed - the address is composed of the highest 
8 bits V and U - the most significant bits of the address can be taken from the memory model
for a zettennik, or better from a separate register!                    
                                                                
The same operation can be used for lighting.               
The same operation can be used to draw walls in Wolf 3D 
(floors and ceilings will be created automatically).                       
Single-pixel accuracy (with horizontal tekctypuhre) based on
this operation can be achieved like this: in l,(c):in a,(N):      
ld h,a:ld d/e,(hl):1/2*push de (с=N) (39.5 clock cycles per 2 pixels,   
970752 bars full screen)                                     
                                                                
Tekctypuhr with lighting:                                        
By ini (from a specific port) the following happens:           
                                                                
U+=dU (16-bit with overflow cut-off at 14(15) bits)   
V+=dV(16-bit with overflow cut-off at 14(15) bits)   
Tl=(VU) - the address is made up of the most significant 8 bits V and U - the most significant 
the address bits can be taken from the memory model for the zettenik, or from
separate register.                                            
U`+=dU` (16-bit with overflow cut-off at 14(15) bits) 
V`+=dV` (16-bit with overflow cut-off at 14(15) bits) 
Th=(V`U`) - the address is made up of the highest 8 bits V` and U` -     
the most significant bits of the address can be taken from the memory model for the network,   
or maybe from a separate register.                                 
The contents of the cell (ThTl) are displayed - the most significant bits of the address can be   
take it from the memory model for the zettenik, or you can take it from a separate one       
register.                                                       
                                                                
The same operation can be used for regular tekctypuhra (or
rotator) with pixel-by-pixel (not 2-pixel) precision.         
The same operation can be used to draw walls in Wolf 3D 
with pixel-by-pixel accuracy (floors and ceilings will be              
automatically).                                                 
Drawing monsters in Wolf 3D: in d,(с):ld e,(hl):ld a,(de):     
ld (hl),a:inc l (37 clock cycles per byte)                             
                                                                
Tile tekctypuhr:                                            
For tekctypuhra 128x128 with 8x8 tiles with 2-pixel  
it is necessary to redo the operation "tekctypuhr with lighting" with accuracy:   
1. cut off in U, V by 15 bits (or without cutting        
in general), and Tl=(VU) must necessarily take the most significant bits from     
central register, and not the memory model of the zetnik.                       
2. in U`, V` do not cut off 14 (15) bits, but loop  
(14-15 bits do not change when U`+=dU`, V`+=dV`).                  
Single-pixel precision based on this operation can be        
achieved as follows: in l,(с):in a,(N):ld h,a:ld d/e,(hl):            
1/2*push de (с=N) (39.5 cycles per 2 pixels, 970752 cycles for the whole 
screen).                                                         
                                                                
Perspective tekctypuhr with Z-buffer and lighting:              
Scary formulas, but also possible.