Enterprise Forever
:UK => Programming => Topic started by: ssr86 on 2015.September.21. 20:56:40
-
I just wanted to ask if maybe Nick has some useful bugs like c64's vic has... Maybe something to "shift" the screen by half byte or somwething like that. I know Nick is a very "elastic" video chip but maybe there's something worth mentioning.
-
hm this is very very interesting
I wanted to open a topic like this right now :)
I am interesting any hardware bugs (useful bugs) in any 8 bit machine :)
-
I just wanted to ask if maybe Nick has some useful bugs like c64's vic has... Maybe something to "shift" the screen by half byte or somwething like that. I know Nick is a very "elastic" video chip but maybe there's something worth mentioning.
but as a big nick user (I made many demos and games) I dont know any... useful or useless
I have a demo where I use something to "bend" (offset to left) some raster rows. but I think it works only on some tvs
-
I don't really know how such "bug" could be found...
If I remember how some vic hardware bugs are used -they basically change some register or registers at the right time during a rasterline... or something like that... So I guess on the nick it could be also something similar? Although the margin registers are used only at the horizontal blanking and changing them in the middle of a line won't change anything. Oh and will nick know about the lpt change automatically?
Although many useful things can be done by Nick "normally" - like repeating lines, "opening borders", rasterbars, scroll(?).
And how easy it is to make a vertical rasterbars "demo":) and how little code it needs - one line of graphics stretched to fill the entire scrren and animate this one line.;P
But being able (for example) to somehow scroll the screen by halfbytes and offset margins by one byte instead of two would be great...
Also I don't know what you could achieve with changing some modline parameters in the middle of a line...
-
I tried to change palette in the mid of the line, unfortunately nothing changed, and I think nothing will change if you change anything else ,I tested it on emulator only, but if I remember well Nick reads the LPB value in the beginning in the line and it will not reread it in the same line.
István found a Nick bug which he used for timing of his Scroll demo, which works well only on a real EP, on emulator we had to start a lua script before starting the demo.
You can contact him for details, and for more "bug" bug info if there are.
-
I tried to change palette in the mid of the line, unfortunately nothing changed, and I think nothing will change if you change anything else ,I tested it on emulator only, but if I remember well Nick reads the LPB value in the beginning in the line and it will not reread it in the same line.
Could something be achieved by having the right and left marging at 0 and 63? I think that with this the nick can't update properly...
Still not a bug, but I remember that I managed to make the screen "open" from the middle when I was experimenting with the margin screen transition effects in march (the border "opened" at the middle of the screen)... but I can't find that file. I thought that it could be used for a closing door or gates animation. The minus was that the screen needed to be of max width.
-
From http://ep.lgb.hu/doc/ports.html
Built-in: Nick (video chip) I/O ports
Nick has only four I/O ports; most parameters are described with an in-memory list called as the LPT (Line Parameter Table) including the video and colour mode, video memory addresses and the vsync itself too, even at scanline level if you want. The rest of the 0x80-0x8F port range contains "echoes" of the Nick registers above 0x83. Important: Nick ports are read-only! There is some odd behaviour that you can read the (Nick's) bus state on these I/O ports. In theory it can be used for some video effects. I can't say I can understand that very well though :)
Could someone elaborate on the "odd behaviour"?
-
From http://ep.lgb.hu/doc/ports.html
Could someone elaborate on the "odd behaviour"?
But it is written there. NICK ports are read only. So, when you read them they won't echo the last written value. However, the read value is actually the value NICK fetched in probably the previous memory access. Probably means that I don't know, I don't have actual experiences. Actually, I don't have an Enterprise either, I'm only a fan. You should make some tests or check the ep128emu sources.
-
But it is written there. NICK ports are read only. So, when you read them they won't echo the last written value. However, the read value is actually the value NICK fetched in probably the previous memory access. Probably means that I don't know, I don't have actual experiences. Actually, I don't have an Enterprise either, I'm only a fan. You should make some tests or check the ep128emu sources.
I've meant it in context to the sentence "In theory it can be used for some video effects." - what video effects etc.. Sorry for being unclear.
-
I've meant it in context to the sentence "In theory it can be used for some video effects." - what video effects etc.. Sorry for being unclear.
István used this "bug" for timing of BIAS scroll , if I remember well the program reads Nick port, but I do not remember exactly.
The others are mainly documented, even the 4 colour character mode also, and Attribute mode could be placed into col4 or col16 mode, but these attrib modes are useless
-
I've meant it in context to the sentence "In theory it can be used for some video effects." - what video effects etc.. Sorry for being unclear.
I think that was only somebody's imagination running wild. Once NICK set up the video line from the LPB, the user has no intervention in the video signal generation, except the setting of BIAS, or forcefully reloading the LPT. That's how I understand NICK's operation.
-
István used this "bug" for timing of BIAS scroll
There is it. (https://enterpriseforever.com/hardver/nick/msg34003/#msg34003) It is run properly on real machine. The LUA script try to correct the emulation on ep128emu.
This video from real EP. (https://enterpriseforever.com/hardver/nick/msg34007/#msg34007)
-
I tried to change palette in the mid of the line, unfortunately nothing changed, and I think nothing will change if you change anything else ,I tested it on emulator only, but if I remember well Nick reads the LPB value in the beginning in the line and it will not reread it in the same line.
Yes, NICK can read only 2 bytes per character, and 8 characters (16 bytes) at the beginning of a line are used to (re-)read the current LPB, while the last 3 characters are reserved for DRAM (video RAM) refresh. That leaves 46 usable characters out of 57 per line.
István used this "bug" for timing of BIAS scroll , if I remember well the program reads Nick port, but I do not remember exactly.
It uses the port reading (which returns the last byte from the data bus of NICK) and an "invisible" line with black palette colors that contains a sequence of numbers as the pixel data to determine the current horizontal position, and then waits the necessary number of cycles based on that to make the timing of the BIAS writes stable.
-
There is it. (https://enterpriseforever.com/hardver/nick/msg34003/#msg34003) It is run properly on real machine. The LUA script try to correct the emulation on ep128emu.
This video from real EP. (https://enterpriseforever.com/hardver/nick/msg34007/#msg34007)
there are many cool effects collected on this forum, we can make a "gigademo" using them :)
-
There is it. (https://enterpriseforever.com/hardver/nick/msg34003/#msg34003) It is run properly on real machine. The LUA script try to correct the emulation on ep128emu.
Here is also the source package:
[attachurl=#]
-
there are many cool effects collected on this forum, we can make a "gigademo" using them :)
In the above program, it would also be possible to use the first 8 colors on the palette as "foreground" pixels where the scroll is not visible.