letzter Beitrag von mega65 am
C65 Next Generation MEGA65
- tulan
- Erledigt
-
-
Hat eigentlich jemand schonmal die Möglichkeit angesprochen, ob es eine passende Unterschale für ein C64 Board geben könnte und man somit vielleicht hier mit einer höheren Produktionsanzahl der Gehäuse eine neue Wohnung für C64 Platinen anbieten könnte?
-
Das koennte glaube ich etwas eng werden. Vielleicht mit einem Shortboard oder U64, aber zumindest das Laufwerk muss dann halt auch raus. Und irgendwie faende ich es glaube ich komisch, in einem C65-Gehaeuse dann einen C64 zu betreiben zumal der C65/MEGA65 ja auch einen C64 beherbergt. Und es gibt ja eh schon neue C64C-Gehaeuse, warum also ein C65-Gehaeuse fuer einen C64? Was noch fehlt sind neue Brotkasten-Gehaeuse...
-
Das zielte in Richtung "neues Komplettgehäuse", da es ja hier auch für eine voraussichtlich überschaubare Menge an Geräten auch komplett existiert, aber für jedes "neue C64" Gehäuse eine funktionierende Tastatur fehlt. Solange ein "echter C64" umzieht mag das ja klar gehen, aber für alle alternativen Varianten... Oder nicht mehr so schöne Originaltastaturen...
-
Gut, Tastaturen gibts noch keine wirklich neuen, das ist richtig. Aber trotzdem finde ich die Verwendung eines C65/MEGA65-Gehaeuses irgendwie dann doch falsch/seltsam, zumal ja auch die Tastatur ein anderes Layout hat. Aber da das MEGA-Team ja nun Erfahrungen hat mit der Herstellung neuer Tastaturen in einem komplett custom-maessigen Layout, koennte man ja vielleicht hoffen dass es auf diesem Wege auch neue C64-Tastaturen geben koennte? Es koennte hoechstens sein dass die Tastenkappen ein Problem werden, denn die sind beim C65 ja von der Form her "moderner" und somit vermutlich leichter aufzutreiben gewesen als es bei C64-Kappen der Fall waere, die man da dann auch neu herstellen muesste.
-
Naja, ob ein CEVI da rein gehöhrt ist wohl Ansichtssache.
Aber ein Markt für die Gehäuse aleine wäre wohl schon da - von Arduino über das Raspberry, bis zum Mini-PC-Board, könnte ich mir da einiges drin vorstellen.
-
Ist aber halt auch die Frage, ob man nicht erstmal dem MEGA65 selbst eine Chance geben moechte, anstatt sein Gehaeuse gleich noch parallel dazu als Leergehaeuse fuer allen moeglichen Schnickschnack zu vermarkten...
Das erinnert mich fast schon an diese Dental-Kamera oder was das war, die das Atari-Jaguar-Gehaeuse bekommen hat, weil sie die Formen guenstig gekauft haben
-
Ein c64 Board würde nicht in das MEGA65 Gehäuse passen, ausserdem gibt es ja die Spritzgussformen für den
c64c noch, daher sollte es an Gehäusen für den c64 nicht eng werden.
Ich glaube aber, ich weis, auf was Hagtrix hinausmöchte, er würde warscheinlich gerne die neue Tastatur am Original Cevie benutzen.
Ich glaube die einzige Lösung für diesen Anwendungszweck wäre, einen reinen c64 core zu porten/schreiben, ähnlich wie
beim TC und dann den MEGA65 als reinen c64 zu verwenden (was aber in meinen Augen Käse ist, da der c65/MEGA65 einen Cevie eingebaut
hat).
Oder man entwickelt einen Adapter (das ist möglich, da die MEGA65 Tastatur einen eigenen CPLD hat) der dann den normalen c64 Tastaturanschluss hat,
sägt sich bei einem c64c Gehäuse, die Oberschale zurecht (Das habe ich schon gemacht und das passt) und dann könnte man die MEGA65 Tastatur am
c64 verwenden.
Was für eine Idee mir aber dabei gekommen ist, wäre evtl. die Oberschale des MEGA65 so zu gestalten, dass man eine Platte auswechseln könnte und dann entweder die MEGA65 Tastatur oder eine Original Cevie Tastatur einsetzen könnte. Dann könnte jemand der Geld sparen möchte, sich nur dass Gehäuse mit Board (und mit Floppy oder auch nicht) kaufen und sich eine c64 Tastatur einsetzen. Das würde den Preis natürlich auch senken und derjenige hätte einen MEGA65 (mit integriertem c64 eingebaut)
Hmmm. interessante Idee, aber wie gesagt, nur eine Gedankenspinnerei von mir. Aber ich glaube, das könnte ich dem Team mal vorschlagen,
weil die c64 Tastaturen sind ja eigentlich unkaputtbar und bis auf ein paar fehlende Tasten, ist die Matrix von der C64 und c65 Tastatur identisch.
-
Stelle ich mir absolut grauenvoll vor, solche Frankenstein-Projekte direkt von offizieller Seite aus zu unterstützen, indem der MEGA65 in Stücken verkauft wird. Ob man sich damit einen Gefallen tut?
Der MEGA65 soll doch ein Komplettrechner sein. Also würde ich den auch als solchen vermarkten, und nicht als Bastelset. Klar, man könnte Board, Gehäuse und Tastatur auch einzeln anbieten als Ersatzteile, aber aktiv die Nutzung einer C64-Tastatur zu unterstützen über irgendwelche Adapter-Platten finde ich nicht gut. Zumal dadurch im Extremfall auch wieder weniger MEGA65-Tastaturen benötigt würden, was den Preis auch wieder in die Höhe treiben kann.
-
ZeHa Stimmt, da hast du auch recht. Wie gesagt, war nur eine gedankliche Spinnerei von mir, nicht vom Team
Obwohl die Widgetboard version vom MEGA65 (NexysA7-100T & DM65pic) eigentlich genau das ist, ein Bastelobjekt ! und das Widgetboard bietet, von Haus aus, nur einen Anschluss für eine echte c65 Tastatur und eine echte c64 Tastatur. (Obwohl man warscheinlich über einen der freien PMODs auch die MEGA65 Tastatur anklemmen kann). Dann fehlt aber noch das Gehäuse. (Da habe ich z.B. ein c64c Gehäuse "zerschnippelt", um den Widget Mega65 einzubauen).
Aber mit dem c65 Gehäuse hast du schon recht, es würde warscheinlich einiges an Stabilität und "Feeling" flöten gehen, wenn man da eine abnehmbare Topplatte einbauen würde. Es reicht, wenn auf die Rückseite noch eine kleine, herausnehmbare Platte, für den Userport oder so, eingeplant wird.
-
wärs nicht schlauer mal bei dem tastaturhersteller anzufragen ob man nicht m65 und c64 tastaturen herstellen kann ?
wenn z.b. die tastenkappen identisch wären, wären doch die abzunehmenden stückzahlen deutlich höher. und der preis
würde was die kappen anbelangt schon mal günstiger werden. der m65 hätte davon ja auch schon mal was.
vielleicht können die dann auch zu einem vertretbaren komplette c64 tastaturen anbieten. ich weiß das es das
mechboard(heißt doch so ?) gibt. aber das ist ja nun wirklich sehr teuer.
-
MC64 : Im Prinzip hast du eigentlich recht, aber wir haben schon ewig gebraucht, bis wir das Design der MEGA65 Tastatur so hatten, dass wir, als alte 8-bit freaks ,damit zufrieden waren. (Schwarz eloxierts Aluminiumplatte mit Cherry-MX-Keys und customised Keycaps).
Unser Hauptaugenmerk liegt halt beim MEGA65 und da haben wir immer noch genug Baustellen offen, als dass wir uns momentan um so ein Seitenprojekt kümmern könnten, auch wenn die Idee selber schon gut ist.
Eine solche c64 Tastatur müsste mit der selben Sorgfalt designed werden, wie die MEGA65 Tastatur, da ja die Keycaps beim c64 doch anders sind als beim C65/MEGA65. Die C65 Tastatur lässt sich eher mit dem C128 vergleichen als mit dem C64 und selbst dieser Vergleich hinkt noch. Schau mal hier.
Wir haben die MEGA65 Tastatur so gut nachdesigned, dass man im MEGA Gehäuse, eine echte c65 Tastatur und im c65 Gehäuse, eine MEGA65 Tastatur verwenden könnte. passt beides.
Wie gesagt, gut ist die Idee, aber wir (M-E-G-A) haben im Moment keine Zeit oder Resourcen/Manpower, um dieser Idee weiter nachzugehen.
-
Das Hauptaugenmerk sollte auf dem eigentlichen Projekt liegen. Was es wohl auch macht. Dennoch wird es immer jemanden geben der anfängt Sachen zu modifizieren. Daraus sich schon viele Jungendsünden aber auch tolle Projekte entstanden. Von daher wäre es sicher toll wenn nach Release einzelne Komponenten frei verfügbar wären. Ich hätte da sogar schon einen Anwendungsfall.
Vielleicht ist es auch finanziell ein Vorteil. Mit steigender Stückzahl sinkt oft der Stückpreis in der Herstellung.
LG -
Natuerlich kann jeder modden wie er lustig ist. Warum man aber das Gehaeuse von offizieller Seite aus extra so designen sollte, dass man ueber den Austausch einer Befestigungsvorrichtung auch eine C64-Tastatur einbauen soll, obwohl es sich um ein C65-Gehaeuse handelt, das erschliesst sich mir halt nicht. So war das gemeint.
-
Ich wollte jetzt keinesfalls in das Mega65 Projekt reingrätschen bzw. unmögliche Dinge fordern
Und ja, der C64 ist haltbar, keine Frage. Aber dennoch bekommst Du heute quasi fast "alles in neu". Seien es die SID-Chips, komplett redesignte FPGA-Boards, Gehäuse... nur einfach nie Tastaturen. Oder zumindest fast denn sogar ein Tastatur Unterbau geht ja noch, dann aber fehlen die Keycaps.
Und da dachte ich eben auch, wie oben schon angemerkt, könnte es die vorraussichtlich nicht so riesige Produktionsmenge des C65 supporten, wenn Teile des Projekts eben auch für echte 64er und/odere andere Nachbau-Projekte verwendbar gewesen wären.
Aber lasst uns es jetzt erstmal damit aufhören und beim 65er bleiben.
Edit: Gerade den Threadsplit gesehen
-
Modded nur!
Ich kauf dann in 10 Jahren die kuriosen Umbauten davon!
-
Im Prinzip hat DeSegi recht.
Was wir entwickeln, ist und soll eine Bastelmaschine sein. Ich benutze den Prototyp den ich bei mir habe so, wie ich den
c64 auch gehandhabt habe..."Du, der muss dass ab..."
Gerade das FPGA board lädt eigentlich direkt zum basteln ein, da es noch so viele unbenutzte Leitungen und PMOD Schnittstellen gibt, an denen man Erweiterungen anbringen kann. 8-Bit auf ein neues Niveau gehoben !
Der MEGA65 soll ein Rechner für Kinder und Jugendliche sein, die darauf die Grundlagen kennen lernen können, wie ein Rechner (8-Bit) eigentlich arbeitet und er soll natürlich auch für uns, die ältere Generation sein, die
mit einem lachenden und einem weinenden Auge auf die 80er zurückblicken und den c64 glorifizieren und heute erfahrene Bastler sind. Jeder in seinem Metier.
Ich hätte nicht gedacht, dass ich nochmal einen Rechner finde, der mir soviel Spaß macht, darauf rumzubasteln und zu zocken.
(Naja, ist ja auch c64 inside....Di, Ding, Di, Ding)
Genau aus diesem Grund gibt es ja auch die Widget Version vom MEGA65, dass man sich für kleineres Geld seinen MEGA65 (mit c64 inside) zusammenbasteln kann..... ....und DeSegi in 10 Jahren die gemoddeten Kisten kauft
-
Oder man entwickelt einen Adapter (das ist möglich, da die MEGA65 Tastatur einen eigenen CPLD hat) der dann den normalen c64 Tastaturanschluss hat,
sägt sich bei einem c64c Gehäuse, die Oberschale zurecht (Das habe ich schon gemacht und das passt) und dann könnte man die MEGA65 Tastatur am
c64 verwenden.
Was für eine Idee mir aber dabei gekommen ist, wäre evtl. die Oberschale des MEGA65 so zu gestalten, dass man eine Platte auswechseln könnte und dann entweder die MEGA65 Tastatur oder eine Original Cevie Tastatur einsetzen könnte. Dann könnte jemand der Geld sparen möchte, sich nur dass Gehäuse mit Board (und mit Floppy oder auch nicht) kaufen und sich eine c64 Tastatur einsetzen. Das würde den Preis natürlich auch senken und derjenige hätte einen MEGA65 (mit integriertem c64 eingebaut)
Hmmm. interessante Idee, aber wie gesagt, nur eine Gedankenspinnerei von mir. Aber ich glaube, das könnte ich dem Team mal vorschlagen,
weil die c64 Tastaturen sind ja eigentlich unkaputtbar und bis auf ein paar fehlende Tasten, ist die Matrix von der C64 und c65 Tastatur identisch.
Boah, was für ein Weg: Durch den Fuß über die Brust ins Auge!
Die elegante Lösung wäre doch einfach mal zu warten bis der MEGA64 rausgekommen ist, Gideon und Wiesel einen zur Verfügung gestellt bekommen und dann abzuwarten, dass auf dem nächsten Ultimate-64-Board und dem einem "umgekehrten" Keyrah ein Port für die neue Tastatur auftauchen.
Wenn das geschaft ist und das MEGA65-Projekt die Anfragen kaum bedienen kann und short mit Diskettenlaufwerken läuft, wird evtl. auch der Wunsch nach dem "Classroom"-C64/MEGA65 erhöhrt. Dort passt ja die Tastatur unverändert rein. Das wäre doch was, drei Classroom-Pressformen: Einmal die Oberseite für alle und dann eine Unterseite, in die ein MEGA65-Board passt und eine Unterseite, in die man ein C64-Board stecken kann . Oder mache ich da einen Denkfehler, ist der Classroom-C65 schmaler als ein C64-Board?
Ich merke, meine C65-Ablehnung legt sich langsam. Wenn ich bedenke, dass aktuell beim FPGATED wieder was läuft, könnte ich mir schon vorstellen, eine anthrazitfarbene Sonderpressung des MEGA65 (mit 90° gedrehten Streifen im MEGA-Logo) und 264er Emulation haben zu wollen. Meinetwegen dann auch mit fingerstoßendem Diskettenlaufwerk.
-
A brandnew update from Paul.
As usually you can find the Blog entry over at Paul's Blog.
He did alot of work on the Video out in general, which positivly affects the Ethernet port as well
And he got good results on the HDMI output, with this work done, the MEGA65 will improve again in compatibility towards the c64
enough talking from me:
here you can read it yourself it's a (quite long but) VERY interesting post:
Thank you Paul for the insight !!!
Monday, 11 November 2019
Improving raster timing accuracy / Preparing for HDMI output
While the video PAL and NTSC modes for the MEGA65 are already kind of okay, they are far from perfect for various reasons:
1. Current timing is rather approximate, in terms of cycles per raster and rasters per frame. We need to be able to have this exactly match the C64, if we want better compatibility.
2. For HDMI output, we also need to use "real" video modes.
3. The different pixel clocks for PAL and NTSC modes causes various annoying problems.
In looking through all this, I have decided that the video modes that make the most sense are:
PAL: 720x576 50Hz
NTSC: 720x480 60Hz
These are widely supported HDMI-compatible modes used for TV, and which have the added advantage that they both use a 27MHz pixel clock -- which means we can in theory ditch all the complexity I previously added for supporting 30MHz and 40MHz pixel rates for the old VGA-style modes I was using.
The first question I had was whether VGA-input monitors are able to display these modes. My initial experimentation with my monitors here, and those of the MEGA team seems to indicate that that this is no big problem -- although some fine-tuning is required to get the best picture on the most screens. VGA is really only intended as a backup to the HDMI connector, in any case, so we are willing to accept moderate compromises on the VGA output, if required.
So first step, modify the clock generator in the FPGA to provide me with 27MHz for the pixel clock, and some multiples of it, for when I need to do things within a clock tick. This was a bit of a pain, because the MEGA65's clock generator was generated using the old Xilinx ISE toolset, which we no longer use, and which even when we have tried to reinstall seems to refuse to generate the updated clocking file.
The solution here was to run the ISE generator as far as I could, so that it would tell me the clock multiplier and divider values for the PLL, and then import those by hand into my existing file. Of course, this is a process prone to errors, so I generated a bitstream that just exports the clocks to some pins on a connector, so that I can verify that the frequencies are correct. After a few false starts, I managed to get this sorted.
(One side-effect of this, is that I couldn't use exactly the same 40MHz CPU clock, but had to increase the CPU clock to 40.625MHz. That shouldn't hurt the timing closure too much, but will be a welcome 1.5% CPU speed increase.)
Okay, but now I have a problem: We need a 650MHz so that we can divide it in various ways to generate the 27MHz video pixel clock oriented clocks, while also generating being able to generate the ~40MHz CPU clock. This works because 162 = 27x6 ~= 650/4, and 40.5 = 162/4. So that's all fine to better than 1% error. The problem comes that I also need a 200MHz clock for the ethernet TX phase control. There is no integer n, which satisfies 200n = 650*. So I have a problem.
(* Excluding the possibility of assistance from Stupid Bloody Johnson.)
One approach to solving this, would be if the FPGA we are using has two such clock units, that I could configure separately. Reading the datasheet, it seems as though there should be 6 of them -- so I should just be able to create the 200MHz clock on a second one. This would normally be problematic, because the phase of the 200MHz clock would have no relationship to that of the 50MHz fundamental clock for the ethernet. However, in this case, as the 200MHz clock is only used to adjust the phase of the ethernet TX clock versus that of the TX bits, we might be able to avoid it. In fact, we could in theory use a different clock frequency for this function. Quite possibly just 100MHz, and allow only 2 instead of 4 phase offsets for the ethernet. This should probably be enough, and solves the problem for us, so that's what I will do.
So now I have the correct clocks. Next step is to rework the frame generators, so that they natively use the 27MHz pixel clock to generate the frames. In theory this should remove a pile of complexity from those files. The MythTV database lists them as:ModeLine "720x480" 27.00 720 736 798 858 480 489 495 525 -HSync -VSync
ModeLine "720x576" 27.00 720 732 796 864 576 581 586 625 -HSync -VSync480 31.4685 kHz 576 31.25 kHz
First, we see that the redraw rates are approximately double what we would expect, with ~31KHz corresponding (coincidentally) to about 31 usec per raster. That's okay, because we are using double-scanning instead of interlace, so we expect this. The VIC-IV internally manages this, so we can ignore it (for now).
So, these look pretty good -- except that the NTSC C64 has 65 usec per raster compared with 63 usec per raster for a PAL C64. This means that if we want accurate timing, we need to adjust the lengths of the NTSC mode to be 65/63 the duration of the PAL mode. We'll come back to this, after we actually get the modes working correctly.
Now, previously I had a FIFO buffer that took the pixels generated by the VIC-IV on the 80MHz pixel clock, and allowed them to be read out using the 30 or 40MHz pixel clock of the actual display mode. In theory, it should work quite well. However, in practice, it seemed to always have jitter problems from somewhere, where the pixel positions would vary sideways a little. Thus I am taking the FIFO out, and requiring that the pixels have explicit X positions when being written, so that the jitter cannot happen. This buffer will get read out at the native 27MHz pixel clock rate, which should also completely eliminate the fat/skinny pixel problems caused by the video mode not matching what monitors expect, and thus trying to latch the pixels at some rate other than 27MHz.
The only challenge with this re-work, is that we need to make sure there is no vertical tear line, when the VIC-IV catches up with the pixel driver outputting from the buffer. I'll work on that once I get it working, as there are a few ways to deal with this.
Actually, stop press on that... The VIC-IV's pixel clock is now 81MHz and the video pixel clock is 27MHz, because we had to make them related to generate them all from the one clock on the FPGA. This means that the VIC-IV's internal pixel clock is 3x the real pixel clock. This means we can just clock a pixel out every 3 cycles, and completely dispense with the FIFO, buffer or whatever AND avoid the vertical tear line AND free-up a precious 4KB BRAM in the FPGA in the process. I'm not sure why it took so long for me to realise this...
Anyway, now that I have realised it, I am in the process of restructuring everything to use this property. It's really nice in that it is allowing me to strip a pile of complexity out of the system. It took a few hours to get the pixeltest bitstream working with it, but it now displays a nice stable pattern in both the 50Hz and 60Hz PAL and NTSC video modes.
The next step was integrating the changes into the main targets for the MEGA65 PCB and Nexys4 boards. This wasn't too hard, but there were a few places where I had to adjust the display fetch logic, to account for the fact that the display is now 720 pixels wide, instead of 800. In particular, this was preventing the character / sprite / bitplane fetch logic from occurring each raster line, because it was waiting for the X position to reach 800, which of course would now never happen.
There was then about a two month pause, while I had too much workload at work to have any real spare time to investigate any further. After this involuntary pause, I started looking more seriously into the ADV7511 HDMI controller chip that we are using.
I'd previously had trouble talking to the I2C interface on this chip. So I started with trying to waggle the SDA and SCL lines of the device. This revealed that I had one of the pin numbers of the FPGA incorrrectly recorded. After fixing that, I finally was able to communicate with the 7511. This was quite a nice step forward. However, while I could read all the registers, it was refusing to write to most registers. After some hunting around, I discovered that this was because it hadn't detected a monitor, and that causes it to stay in power-down mode, in which you can't write to most of the registers.
The mystery of why it was stuck in power-down when I clearly had a monitor connected took a little bit of exploration to work out. I hadn't realised that the MEGA65 main board has a kind of helper chip to protect the 7511 from static and other over-voltage hazards. That chip has an output enable line, that if not asserted prevents its built-in level converter from connecting the 7511 to the actual HDMI port. Once I figured that out, I was able to activate the output enable, and then I was suddenly able to get the 7511 to power-up, and even to read the EDID information from the connected monitor, which can be seen in the lowest two rows of hex in the second image. The first image shows the registers before being configured. You can play spot the differences to work out some of the register settings I used
The next step was to configure all the various registers of the 7511 for operation. The documentation for the 7511 lists a whole bunch of mandatory register settings that are required for correct operation. It also lists a whole bunch of other registers that control video format and other things. It's quite hard to know exactly the right settings.
After some trial and error, and a general lack of HDMI picture appearing. I had a look at Mike Field's example VHDL for driving the same chip. I'm not sure why I hadn't discovered this a long time ago. It took a few hours to adapt his code to run on the MEGA65 main board, since it was intended for another board. However, it too failed to show any display initially. At which point I was quite despondent, as I had really expected his code to work, and to thus give me a starting point from which to slowly adapt across to my purposes. It was also midnight, so I sensibly gave up and went to bed.
It wasn't until this evening that I sat down again to look at this, and it occurred to me that Mike's code might have been assuming the incorrect I2C address for the 7511, since it supports two different addresses. It was wrong, but fixing it didn't fix the problem. However, my own code had shown me that sometimes you have to send the I2C commands to the 7511 twice instead of once, if the monitor disconnects and reconnects again. It seems that both of my HDMI montiors do this. So I wrote a little routine to trigger the sending of these commands to the 7511 every second. And FINALLY I had some sort of picture showing up on the HDMI output:So here we see a couple of problems with the HDMI (right screen) vs VGA (left screen), as well as me writing this blog post on my laptop
1. The HDMI output has the same colour for every pixel on a raster.
2. The colours are All Wrong.
For (1), I don't (yet) have any firm idea, but it could be something to do with the way Mike's program generates the HDMI frame using some complicated DDR output mode that I don't need for our 27MHz pixel clock, and thus haven't really tried to understand.
For (2), amongst the pile of reading I have done on the ADV7511, I know that this is likely a colour-space conversion problem, because RGB black becomes green in the YCbCr colour space. That should thus be easy enough to fix by changing the default register setup.
Of these, (2) looks the easiest to fix for now. So I'll start there. There are two main registers on the 7511 that control the pixel format and related things:
The upper-nybl of $15 controls the audio sample format, which we are not yet ready to worry about. The lower nybl, however, controls the pixel format. $x6 indicates YCbCr, which is what Mike's code was using. That would explain things. So I'll try $x0 instead, which should tell it to use RGB 4:4:4 (i.e., RGB where each colour channel is sampled at the same rate, i.e., Stink Normal RGB). And indeed it makes quite a difference:Note that while we can now see lots of pixels, which probably means that (1) is not really a problem, but was some weird artefact, that not all the colours are being produced the same on both outputs. The keen observer will also notice that the image is slightly rotated horizontally. We'll also worry about that later.
The next register of interest is register $16, which controls a number of things related to pixel format. Mike's code sets it to $37. In my code, I had it set to $30. The difference is that my value has "Not valid" instead of "Style 2" for the pin assignments for the pixels coming to the 7511. That's definitely a possible problem. Bit 1 controls DDR rising/falling edge for certain modes, which shouldn't matter for us. Bit 0 selects the input colour space, where 0 is RGB and 1 is YCbCr. I'm going to try $30 in Mike's code, and see if it breaks the display of the image, and then if that's the case, try $34, which I think should work in my code. Except... that it seems to make no difference to Mike's program when I do that (or to my code when I try the different settings).
So then I tried copying in the colour space conversion registers, but also without any visible effect in my code.
Now I'm a bit confused. Basically it seems to me that the only two differences are the use of the DDR versus simple delivery of pixels, and the video mode. Neither of which should prevent the thing from displaying an image. The video mode in particular should be fine, since the 7511 even reports that it detects the mode correctly as the EDTV 576p or 480p video mode, which means it thinks that the HSYNC and VSYNC timing are all just fine.
But just in case, and also to make it easier to progressively converge Mike's working code and my not working code, I am converting Mike's code to produce a 576p EDTV PAL image. If that displays on HDMI, then I know it isn't the mode, and must presumably be to do with the pixel format, and that I might have to use DDR pixel delivery after all.
Okay, so video mode switched to 576p 50Hz, and with Mike's code, it still displays just fine. Well, fine-ish, since I have messed with the colour space stuff. In adapting Mike's code to produce 576p, I ended up using a slightly different pixel clock of 1400/52=26.9something MHz.
The monitor shows the mode correctly as 720x576 @ 50Hz, so this might be a good option for the MEGA65 to use, since it might get us back to a simpler set of clock frequencies. But that's for another day. First, let's try to get some sensible pixel colours happening again, by making sure we have the pixel format set to RGB etc, and finally, we have a working HDMI image:
After simplifying the code, and re-working it to use the MEGA65-style externally supplied 27MHz pixelclock, this is now VERY similar in operation to my own HDMI driver that doesn't work. This is really quite mysterious. The main difference I can see so far, is Mike's code has an I2C sender that does the initialisation of the HDMI controller automatically, instead of having to be bit-bashed as I do it in mine. I've checked the registers that it sends, and I am pretty sure I do all of them. But I have a sneaking suspicion that there is still some subtle difference there. So I might just try incorporating that into the MEGA65 target next. -
Good Luck !
Brotscheibe