Enterprise Forever
:UK => Hardware => Display => Topic started by: gflorez on 2016.December.02. 12:51:27
-
TVC ugyanaz EXTCOL \ és EC0, EC1, EC2, EC3 jeleket.
Milyen interface ez?
Volt gyakori, hogy a korszak?
Tud elérjék a Sprite prototípus?
------------------------------------
TVC has the same EXTCOL\ and EC0, EC1, EC2, EC3 signals.
What kind of interface is it?
Was it common on that era?
Can you reach the Sprites Prototype to study it?
-
TVC ugyanaz EXTCOL \ és EC0, EC1, EC2, EC3 jeleket.
Milyen interface ez?
Külső színbemenet, ugyanúgy mint az EP-n
Volt gyakori, hogy a korszak?
Nem hinném. De az EP-t és a TVC-t ugyanaz a csapat tervezte.
Tud elérjék a Sprite prototípus?
Csak a neten lévő képeket ismerem :-(
------------------------------------
TVC has the same EXTCOL\ and EC0, EC1, EC2, EC3 signals.
What kind of interface is it?
External color input, same as on EP.
Was it common on that era?
I don't think it. But same team developed the EP and TVC.
Can you reach the Sprites Prototype to study it?
I only know the photos on the net about it :-(
-
Dokumentáció az van bőven :-)
Are there available any schematics ? I read that this computer has been built entirely without the use of specialized chips. I could try to clone it.
---------------------------
Vannak-e rendelkezésre olyan rajzok? Azt olvastam, hogy ez a számítógép épült teljesen használata nélkül speciális chipek. Megpróbálhatnám klónozza azt.
-
Are there available any schematics ? I read that this computer has been built entirely without the use of specialized chips. I could try to clone it.
---------------------------
Vannak-e rendelkezésre olyan rajzok? Azt olvastam, hogy ez a számítógép épült teljesen használata nélkül speciális chipek. Megpróbálhatnám klónozza azt.
Well, it's Hungarian book, but there are many hw related info and some "bit abstracted" schematics too (with description how it works, but in Hungarian ...): http://tvc.homeserver.hu/doc/konyvek/tvchardver.pdf However this is not exactly a precise schematics you would expect, I think! I'm not sure if there is a detailed, full-featured schematics on the computer ...
Btw, if you want to clone, there is another - even more simple - Hungarian computer, the "Primo" (and it's b&w, the advanced colour model was not even released later but planned, if I know well) which does not even use "complex" chips (other than the Z80/U880, U880 is a hmm an "eastern block" clone of Z80 hehe ...), unlike the TVC here which contains a specialized chip at least (though a common one!) the 6845 CRTC. Though it was already done it seems: http://primo.homeserver.hu/html/epitesutanepites.html
-
I ask about TVC64 not coincidentally. It is most similar to the Enterprise.
Maybe it would be easier for me to recognize how works the inputs EXTC and EC0-EC3. I'm afraid a little of doing experiments on expensive original EP.
The 6845 CRTC chip is quite easily accessible. It was widely used in many computers (Amstrad/Schneider CPC, early PC graphic cards MDA and CGA).
-
I ask about TVC64 not coincidentally. It is most similar to the Enterprise.
Maybe it would be easier for me to recognize how works the inputs EXTC and EC0-EC3. I'm afraid a little of doing experiments on expensive original EP.
The 6845 CRTC chip is quite easily accessible. It was widely used in many computers (Amstrad/Schneider CPC, early PC graphic cards MDA and CGA).
Yeah, I see, I just mentioned Primo, since it's an interesting stuff, that there is no special IC (AFAIK!) in it, other than Z80, not even something like the CRTC, or custom stuff, like the ULA in Speccy, or Dave/Nick in EP, etc. But surely, I see your point. I think, you can't damage an EP with those inputs too much ... AFAIK, EC0-EC3 and EXTC both of all are inputs, normal logical evel, etc, so you can even build some buffer between them, etc.
In theory, EC0-EC3 are colour inputs which are treated if EXTC is driven active (low active, if I remember correctly). Also, some Nick I/O ports, you can tell how they are should be used. Since I *still* (please do not comment, hehe) don't have a usable EP for real, I can't try, but I already suggested, that somebody should try to drive EXTC active externally and only put a constant "colour" onto EC0-3 (eg, ground all of them, maybe on some resistor though, just to be safe). Then on 0x80 port of Nick, the handling of external colour input should be "set up" for as you like, and you can try, what happens on the screen when you drive EXTC active or inactive, or even setting EC0-EC3. My idea, that it should display that colour. Since it's more or less a constant value on EC0-3, and not sync'ed to the pixel clock, etc, surely it looks all on the screen or so, but it's a good and quite simple start to see, if it works this way at all. That's what I think you should not cause any damage, since they are inputs etc, but hey, I can't be sure for sure :) sure-sure :D
-
There are some interesting questions though, eg how external colour values are interpreted in different Nick colour mode LPBs, and for example can you "command" the max resolution even in the case when you have 256 colour mode, so Nick can produce only "blocky" graphics at all. Another interesting fact, that with external colour, - at least according to my idea ... - some can implement an "extra high 16 colour mode" using external hardware providing the pixel data. Then you can even "mix it" with internal Nick graphics in some way. So not only for sprites it can be interesting - maybe there can be SymbOS higher resolution mode this way :) ... though the problem that the 'video ram' is external than to the additional hardware ...
-
Or totally the contrary, a smoth scrolling background and using Nick-Z80 to move the sprites...
-
At now, I only research the subject, but curiosity consumed me :idea:
-
:) I guess, somebody with the needed site admin rights should move the conversation of external colour into its place, somewhere in the :UK section :-D
-
Are there available any schematics ?
You can download from here. (http://tvc.hu/html/hardvertervrajzok.html)
-
TVC Spectrum emulator (http://tvc.hu/html/pic/speccy/tvc_spec%20monitorra.png) generate the Spectrum screen to the external color input.
Using this method also will be good idea for new Enterprise Spectrum emulator, because no attributom conversion needed.
-
TVC Spectrum emulator (http://tvc.hu/html/pic/speccy/tvc_spec%20monitorra.png) generate the Spectrum screen to the external color input.
Using this method also will be good idea for new Enterprise Spectrum emulator, because no attributom conversion needed.
Wow! I haven't known if there was _any_ usage of the external colour input feature. Nice :)
-
On Enterprise, I suggest this as first try: put a 4 bit counter to the Nick clock, these 4 bit connected to the EC0-EC3, and lets see what happening when EXTC active.
What I wait: external color input will select one of the 16 colors, instead the current pixel colour (priority can be selected, see the Nick documentation). And I'm 99% sure 16 colors can be used with Hires 2 resolution. See the Text 80, it is use 8 colors in this mode.
-
Exciting :) Using the "dot clock" basically will create some kind of "chessboard" or "vertical stripes" like stuff if I am correct exactly at hires pixel "wide". What would be interesting to set up an LPT with more LPBs with different colour + video modes, and watching what happens, is there any effect Nick take account in relation of the external input based in its internal mode. it's interesting though what would happen with like 256 colour LPIXEL mode, which is kinda blocky with Nick, can external colour only override a "Nick pixel" always, or the atomic smallest possible pixel even in this case. And surely also the question what the 4 bit external colour is interpreted as if the mode is palette based or not (ie: 256 colour mode, where there is no palette ... though the external colour may use the LPB palette + BIAS even in this case?).
-
In 256 color I think about two cases: it is select from the first 16 colors, or it is don't used.
Interesting question what happen in attribute mode? It is replace the attribute byte?
And in hw character mode? Select the ink colour? Or paper color? Or both? :-)
And also interesting what happen if the external colors using better resolution? For example 640 pixels, in 4 colors 320 pixels Nick mode. It is keep the original wide pixels, or can make smaller pixels?
-
Surely, just guessing. Just it's 4 bits info, thus 16 colours, that mades me thinking it's similar to the 16 colour Nick "internal" mode. But I can be totally wrong :D Anyway, since it is designed for future sprite support there should be some "sane logic" how it should work, just needs to be figured out. For attribute mode: I would _guess_ (!!!!) that it does not matter. It may be implemented simply, that Nick generates its pixel whatever it is video and colour mode. And the external colour mode generated pixel just shown "above" (better say "instead") the Nick generated pixel, that is, simple "priority decoder" or something like that.
Btw! Just come into my mind: if I remember correctly, we have some kind of Nick internals document or something ... Hasn't that contain some information to answer these kind of questions?
-
Yes, documents DPC11 (http://enterprise.iko.hu/technical/NICK-Old-VDC-ELITE-description.pdf) and DPC12 (http://enterprise.iko.hu/technical/NICK-Internal-timing-of-VDC-Elite.pdf) have information about the internals of Nick, and we also have the schematics here (http://enterprise.iko.hu/schematics/3006-0000-22_Sheet-1.pdf) and here (http://enterprise.iko.hu/schematics/3006-0000-22_Sheet-2.pdf), but very high technical knowledge is needed to understand them. Surely Pear has it...
-
Wow, finally some specifics :)
I had not thought before about TVC64. Only recently I learned about its history, and that is very similar to the Enterprise.
Something else is analyzing the schematics on the paper, and something totally different opportunity to see in the operation of the actual hardware, without fear that the feeler "will fall to the place in which can cause the most damage" (according to Murphy's Law).
Thank you very much for the links.
Could use even the contents of ROM-s. Please :)
-
What Roms, for EP or for TVC?
There is disassembly for the two computers, with Hungarian commentaries:
EP 0 Segment (http://enterprise.iko.hu/books/Segment_0.pdf).
EP 1 Segment (http://enterprise.iko.hu/books/Segment_1.pdf).
TVC Rom (http://tvc.homeserver.hu/doc/konyvek/tvcrom.pdf).
Zozo keeps a lot of EP information on his Web page (http://enterprise.iko.hu/).
And there is the official TVC Page (http://tvc.homeserver.hu/).
-
My idea was, that a sprite unit would work this way: it has two "data structures" for a sprite. First, there is the "shape information". That is, controls /EXTC, this is 1 bit info per sprite pixel. Can be also thought as the "alpha channel" in modern gfx things, just we have only on/off, no "semi-transparency" etc. And then there is 4 bits of colour info for the given pixel, which does not count at all if /EXTC is not (low) active. Now it's interesting that it _seems_ I was right, in the "palette-less" 256 colour mode, the external colour still uses the palette. That makes sense, as this external colour feature is created for "sprites" keeping in mind in the future, this it would be a bit odd, that sprites can have only fixed colours for the first 16 EP palette colours. And anyway, in 256 colour mode the palette by Nick internal pixel generation is not used, so it's kinda handy to use it for something at least :-D Surely, for a more simple sprite unit, some can say, that external colour value 0 means the transparency, then no need for shape/colour info, but only a simple logic, to drive /EXTC for low active if 4 bits of EC are all zero. This would mean - if I am correct - that 0 would mean transparent, 1-15 would select the corresponding internal Nick palette (8 LPB palette values + FIXBIAS for the second 8). Thus we lost one colour with this technique. The price for not having separated sprite "shape" and "colour" info in the external sprite unit ...
-
Could use even the contents of ROM-s. Please :)
Which ROM-s?
TVC ROMs (http://tvc.hu/html/hardverrom.html). Basic, DOS
TVC Spectrum emu ROM (http://tvc.hu/html/pic/speccy/eprom/tvc_spec.128)
-
They mention a camera input. May be the easiest way to experiment is to try a video input, with some circuit slicing a synchronised composite signal into its 4 bit EP-colour components, with Extcol always active.
-
Now I have already all. Thank you.
Evenings are long. Slowly I redraw TVC and try to build a clone.
-
They mention a camera input. May be the easiest way to experiment is to try a video input, with some circuit slicing a synchronised composite signal into its 4 bit EP-colour components, with Extcol always active.
Yes, I guess. That's about the same what I meant about having a "nice resolution 16 colour mode" generated externally on the external colour inputs. As far as I see then, on TVC this method was used by the hardware ZX Spectrum emulator as well, basically, what Zozo mentioned above? Ok, that's TVC and not EP, but I think the theory is the same, after all.
-
There is the interesting question: Nick is a custom chip, what the developers wanted it, putted in.
But at the TVC used a existing chip (6845). How adapted this special features? And fully adapted?
-
There is the interesting question: Nick is a custom chip, what the developers wanted it, putted in.
But at the TVC used a existing chip (6845). How adapted this special features? And fully adapted?
As far as I can see, TVC uses also a custom "logic", not "a single chip" though, as with EP/Nick. In TVC, the 6845 only generates memory addresses, sync pulses, and things like that, but the actual pixel creation, modes, memory reading, CPU/video bus "sharing", etc are not task of the CRTC at all (and it seems these are all implemented by discrete logic?). Maybe that was (the part) of TVC's problem for being too costly to manufacture: it basically uses "discrete logic" for the task, where this was built-in all in a custom chip in the EP (it's another question, that a relatively high-integration custom stuff is also costly ... some must find the balance ...).
-
...Maybe that was (the part) of TVC's problem for being too costly to manufacture: it basically uses "discrete logic" for the task, where this was built-in all in a custom chip in the EP (it's another question, that a relatively high-integration custom stuff is also costly ... some must find the balance ...).
The problem with custom chips at the time the TVC was designed was that "the west" was not allowed to export custom chip technology to a soviet-bloc country (regulations known as COCOM) - that is why the TVC could not use Nick & Dave (in case the Soviet Union used them in missiles! :lol: ) This was right at the end of the Soviet era (but we didn't know that was going to the the case at the time!) but I'm not sure exactly when things changed - obviously by the time all the EPs were sold to Hungary it was OK but this must have been right at the changeover point. Or maybe it was possible to export complete computers but not individual chips, I can't remember.
-
Interesting, but it sounds me funny, if TVC would use Dave/Nick, it would be exactly an EP128, and not a TVC :) Well, or maybe they would have manufactured EPs for real, just "made in Hungary" and that was not possible? Anyway, I see USSR launching missiles but programming LPBs first for Nick in them :D
-
The TVC Spectrum emulator schematics (http://tvc.homeserver.hu/html/pic/speccy/tvc_spec%20monitorra.pdf) are very clear for my poor knowledge. Extc\ is always put to ground, and it seems that Col0 is used for transparency, leaving Col1-Col3 for the colour input.
-
Maybe Col0 is brightness. ZX Spectrum has 8 colors (3 bits Col1-Col3) plus brightness.
-
The TVC Spectrum emulator schematics (http://tvc.homeserver.hu/html/pic/speccy/tvc_spec%20monitorra.pdf) are very clear for my poor knowledge. Extc\ is always put to ground, and it seems that Col0 is used for transparency, leaving Col1-Col3 for the colour input.
\EXTC is on ground (low active) since the whole screen wanted to be "driven" externally, not just a part of the screen, as eg. a sprite, or such. I think.
-
Pear! What do you think: the TVC Spectrum Emulator do anything than emulate the Spectrum screen?
If I see right then it is only modified Spectrum ROM (keyboard reading, sound. Probably tape?) with the emulated screen. Then it is only enought for a BASIC program running.
-
\EXTC is on ground (low active) since the whole screen wanted to be "driven" externally, not just a part of the screen, as eg. a sprite, or such.
Yes. And it is also possible do on Enterprise.
If my theory right about the EC lines in Hires 2 -> 16 color then possible 640x resolution with 16 colors on external graphics! (736x300 if full borderless)
But for this need some hw acceleration: scroll registers, block operations (copy, fill, etc)...
Plus the sprites :-)
-
Yes. And it is also possible do on Enterprise.
If my theory right about the EC lines in Hires 2 -> 16 color then possible 640x resolution with 16 colors on external graphics! (736x300 if full borderless)
But for this need some hw acceleration: scroll registers, block operations (copy, fill, etc)...
Plus the sprites :-)
This was my idea too, SymbOS would look great for example :-D Basically it's almost the user experience of GFX9000 etc then :D Though those stuffs are fast enough even using "private to the video chip" VRAM, since there is some hardware acceleration, what you say above exactly, Zozo. It would be rather interesting (though a complex project, I guess it would need an FPGA already ...) to implement something like the video chip used by MSX2 or even better the V9990 (or what is that which is used in GFX9000?). The extra value of this, if it's implemented in a way, that the "main screen" of the emulated entity can be even turned off, and just its sprites remains:
* there can be a Nick + sprites like configuration, by switching the "main external screen" off, but not the sprites
* maybe even MSX emulation (!) on EP at some level at least, since then the external gfx unit can be MSX/MSX2 compatible, or whatever
* you can even mix Nick/external gfx if the latter can use the /EXTC line from memory too
* other tricky mixes, by using the two bits on port 0x80 which controls the process
* to simply get a nice, high resolution screen as whole, ie that 736x300 16 colour and similar
Then it's kinda multi-purpose stuff, however this is far more than a "little logic" ... Unfortunately - I think - a real V9958 or such cannot be used, as it hasn't got digital (?) outputs to feed on external colour inputs of EP, and even if it has, maybe it's not possible to "sync" on the video clock (and custom vsync, dictated by vsync mode LPBs etc) of Nick ...
Surely, there are limits, like the 16 colour, a V9958 and V9990 would know more than "only" 16 colours, but that's another question.
-
Pear! What do you think: the TVC Spectrum Emulator do anything than emulate the Spectrum screen?
If I see right then it is only modified Spectrum ROM (keyboard reading, sound. Probably tape?) with the emulated screen. Then it is only enought for a BASIC program running.
It's possible. I have not watch in detail yet.
-
http://web.archive.org/20040825042007/www.xs4all.nl/~ronholst/map/resources/video/yamaha_v9958.pdf
It has also a switch pin and analog RGB output.
-
Where the Enterprise designers thinking on CGA or EGA when they created the expansion port colour inputs?
There are similarities: CGA and Enterprise inputs have a colour deep of 4 bits, with digital signals. But IBM's CGA works on fixed RGB colours while the Enterprise has a palette, like EGA, that has 6 bit of colour deep, with digital signals.
Also the lower graphics resolution of the IBM modes work on near 15Khz horizontal frequency like the Enterprise. But IBM has 60Hz(NTSC) and the Enterprise 50Hz(PAL) of vertical frequency.
On the other side, IBM modes are planar, made of a mix of one layer per colour(+ intensity), while on the Enterprise the colour is on only one layer.
CGA was introduced on 1981, while EGA was released on 1984
-
Where the Enterprise designers thinking on CGA or EGA when they created the expansion port colour inputs?
I'm not sure I get your point. On EP, these are inputs, they're not suitable to connect a monitor where they're also input. Oh, or you think that using EP "as a monitor", by another computer, so its CGA/etc signal is fed on the EP? It wouldn't work I guess for a simple reason. Not the external stuff (which is connected to the EP) "dictates" the pixel clock, and SYNC pulses ... It's the task of the Nick, and the device connected to the EP's colour inputs should "accept this rule". So it's not the very same issue.
-
I mean about signals. There was a time when the computer video information was managed digitally. Then things changed and all gone analogic, Composite video, SVHS, RGB, VGA.
Now, with LCD panels generalised, we return again to digital signals with HDMI.
The Spectrum emulator of the TVC is a good example on how to interface directly that strange colour inputs.
But they wrote about to inject a video image to the Enterprise. What digital standard of year 1984 the Enterprise creators mean? Or was it their own new method with some sort of synchronising interface?
-
Also, I have been looking for a Enterprise contemporaneous graphics chip that outputs some sort of digital signals, but all are analogic.
Is for that I have been reading about CGA and EGA chip sets.
-
The MSX chips, TMS9918, V9938, and V9958, all only output analog RGB.
But the Yamaha V9990, (http://map.grauw.nl/resources/video/yamaha_v9958.pdf)used on Sunrise GFX9000 and Tecnobytes V9990 Powergraph(supported by Prodatron in his SymbOS), have a digital output of its internal Color Bus.
See mode 4B\D, I think that it fits the Enterprise if synchronised.
-
On the MSX graphics cartridge the memory can't be acessed directly, but on an Enterprise approach that memory could be paginated just like is done for Nick.
For the higer modes, an external RGB connector can be provided, like on the MSX cartridges..
-
On the MSX graphics cartridge the memory can't be acessed directly, but on an Enterprise approach that memory could be paginated just like is done for Nick.
For the higer modes, an external RGB connector can be provided, like on the MSX cartridges..
That wouldn't be a problem. As on MSX, video RAM can be local to the video chip and used through the I/O ports. Using a shared memory, ie what is can be accessed via the CPU too is tricky, specially for a system which is not designed for that (like these V* chips). I wouldn't do that. Maybe it's possible via dual-port memory, or some other complicated way, but why would do that, if it's not done by their "main usagers" eithers, ie the MSX computers? :) So it even helps things to be easy, just some I/O ports are needed on the EP, and that's all.
-
It was said long time ago. MSX has a bottle neck with the graphic solutions on cartridge, because graphics have to be loaded indirectly. On Eps whe can paginate the added memory.
-
It was said long time ago. MSX has a bottle neck with the graphic solutions on cartridge, because graphics have to be loaded indirectly. On Eps whe can paginate the added memory.
At the other hand (especially the V9990, I think) has hw accelerated stuffs, I guess better than what you can do with a Z80 ... But good luck with that, I guess these chips are designed for "private VRAM" (unlike eg Nick in EP, where there is still private VRAM, the CPU can r/w "directly" the VRAM through the Nick, maybe with some speed decrease because of the clock signal "strech" done by Nick to avoid access collusion between itself and the CPU) so almost impossible to do that, especially if V9990 and similar stuffs doing sprite + gfx + own commands running, etc etc. I don't even know there would be free "access time slots" and even if, I doubt if anybody can do it without a horror monster logic ... Maybe dual port memory, but even today it's kinda expensive for hobby purposes, I think.
-
Now I understand you.
V9990 is a very complex way to "simply" inject sprites on an EP.
-
It will not be easy task.
Perhaps this will be a second computer (GPU?).
-
It will not be easy task.
Perhaps this will be a second computer (GPU?).
Indeed, sprites are hard. I believe this, because designers of C64's VIC-II stated, that 70% of the chip area was spent only for the sprites, all other functionalities are the rest ... For generating the full screen it's much easier :) Maybe that's also not accident, that TVC prototype sprite unit is so a monster sized one "tower" when built from discrete logic (what it did, I guess ...).
-
Then, we have to search a way to inject a whole screen from a standard video signal.
By little steps. First, synchronising it , and second, splitting in five(four+ transparency) the colour signal.
-
... and then the collision detection of objects, vector graphics commands, and we make a little, neat accelerator: D
-
I remember an Amiga schematic to build a genlock. I have to search it.
-
I don't think it is too difficult, there are a lot of chips used for Teletext or OSD that can serve to test the strange Enterprise colour inputs.
Examples:
Cypress MB90050 (http://www.cypress.com/file/243061/download)
STV5730 (http://pdf.datasheetcatalog.com/datasheet/SGSThomsonMicroelectronics/mXuyvxz.pdf)
MAX7456 (https://datasheets.maximintegrated.com/en/ds/MAX7456.pdf)
-
... and then the collision detection of objects, vector graphics commands, and we make a little, neat accelerator: D
Ah yes, Z-buffering, phong shading, blah-blah shadow casting, and whatever what I even't don't know what means exactly :-) :-) I guess somewhere some say should STOP! :-D :-D
-
On the TVC expansion ports schematics (http://tvc.homeserver.hu/doc/tervrajzok/TVC_HBA_rajzok.pdf) it is specified the direction of the signals:
EXTC\ input
EC0 input
EC1 input
EC2 input
EC3 input
HSYNC\ input
VSYNC\ input
BORDER input
If the Enterprise inputs work the same, this means for me that Nick will be forced to synchronise its video with the incoming signal, so "only" remains the task to split the analogue colour to digital.
-
At Enterprise (http://enterprise.iko.hu/schematics/EP64-3~0.jpg) the Hsync/Vsync are output (same as on the monitor connector), then the external device need to be synchronized with the Nick.
-
Balagesz tried it!!!
All my suppositions are correct: 16 colors can be used on any display mode, with the highest horizontal resolution, Nick clock are the pixel clock.
1. (https://enterpriseforever.com/hardver/teszteles/msg61131/#msg61131)
Two counters used. One 10 bit counter for the Nick clock (pixel clock). HSYNC clear it, then it is the horizontal position. Bit 9 of this activate the EXTCOL. Another 9 bit counter count the HSYNC, and cleared by the VSYNC. This is the vertical position. Bit 7,6,5,4 connected to EC3,2,1,0
2. (https://enterpriseforever.com/hardver/teszteles/msg61136/#msg61136)
More complex try out hardware: the horizontal counter used for RAM A9-A0, vertical counter for A18-A10. Every byte one pixel. Bit 3,2,1,0 go to EC3,2,1,0, and Bit 7=1 activate the EXTCOL.
3. (https://enterpriseforever.com/hardver/teszteles/msg61147/#msg61147)
Same test as the 1), but now on Iview image. You can see the rectangles using palette colors are changing colours, which are using BIAS colors are fixed. (Second pics: the external color RAM filled with random values at power on.)
-
I have to read and re-read it to try to understand what it does, but this seems a very big discovery.
It is a miracle to think that all EPs where already made to react as this.
Can he show the hardware he is using?
-
I have to read and re-read it to try to understand what it does, but this seems a very big discovery.
It is a miracle to think that all EPs where already made to react as this.
Can he show the hardware he is using?
There's no miracle or very big discovery. This was the capability of NICK from the very beginning. And it is documented in its description. You don't have to understand what and how it does. That's only a test hardware balagesz made to do some experiments on the external colour inputs (EC0..EC3, /EXTC).
-
And it is documented in its description.
But not fully. Many properties only guessed until now.
-
I have read Nick's description many times. It is not the same to be able, potentially, thirty years, than seing that real results on the screen just today.