seppoman

Hi, whoops, I missed one important connection: The upper 9V AC connector is also directly connected to ground, so it´s no surprise one can get a short cirquit... But I still don´t know what to do about... Doc: No problem - I may misunderstand a lot more things than you here because of my limited knowledge ;) Seppoman

Hi Doc, thanks for your reply :) The schematic above is not what I intend to build. I tried to show what happens in the NanoVerb behind the plug. It is driven by a normal AC wall wart. I hope the schematic shows all parts in the correct connection. After the +/-5 V points I don´t see anything that could influence the voltage anymore. But my electronics knowledge is limited... So I suppose I´d have to generate -5V in another way, rip everything shown above out and connect this -5V and the normal 5 V line to the cirquit? The last possibility would be putting another jack in the case and plugging in the normal wall wart of the alesis. But I´d like to avoid this - too many cables... Seppoman

Hi Thorsten, woran das mit dem USE_GLCD liegt, kann ich auch nicht sagen. Ich hab mir das nochmal angeschaut, und das Flag wird eigentlich nicht ausgewertet, aber trotzdem hab ich die Applikation gerade zweimal compiliert, mit dem einzigen Unterschied, daß dieses Flag einmal gelöscht und einmal nicht gelöscht wird. Und eben einmal der MLCD-Treiber und einmal der USER LCD treiber aktiviert wird. Naja, wenn Du sagst, daß es nichts macht diese Zeile rauszulassen, dann kann der Grund ja eigentlich egal sein... Das interne GLCD-Flag ist CS_STAT_DISPLAY_GLCD? Das steht ja wenn ich das richtig sehe in keinem Zusammenhang zum MIOS_BOX_CFG0_USE_GLCD? Kann es sein, daß dieses immer gesetzt wird, wenn Display Type > 0 ist? ----- ;; set CS_STAT_DISPLAY_GLCD depending on LCD mode bcf CS_STAT, CS_STAT_DISPLAY_GLCD call MIOS_LCD_TypeGet skpz bsf CS_STAT, CS_STAT_DISPLAY_GLCD ---- Wegen Timeout: Wenn ein Timeout eintritt, wird das Display dauerhaft deaktiviert? Ich habe gerade mal die Geschwindigkeit des Displays versucht zu testen. Wenn ich in die WaitUnbusy-Routine eine Schleife einbaue, die nach 127 Runden (Bit 7 gesetzt) rausspringt und die Zeichenausgabe überspringt, fehlen ca. die Hälfte der Zeichen, das ist also wohl schon zu schnell... Wäre es nicht allgemein sinnvoll, die Displayausgabe so zu bauen, daß sie erstmal in einen Buffer geht, der erst rausgeschrieben wird, wenn echtzeitabhängige Dinge komplett erledigt sind? Bzw. beim Ändern von Parametern während des Spielens könnte man ja auch auf die Anzeige ein paar zwischenliegender Werte einer Drehbewegung verzichten - Wenn ich spiele und dabei z.B. am Filter drehe, ist es ja nicht so schlimm, wenn der zugehörige Wert erst ne Viertelsekunde später angezeigt wird. Ich vermute nur, das würde wohl ziemlich kompliziert werden? iXe: Mit Durchschalten meine ich, Patche mit einer schnellen Drehung umzuschalten. Ist schon klar, daß da ziemlich viel passiert. BTW: So extrem auf billig fixiert bin ich nicht - wenn das mit dem CS Companion in Zukunft kommt, würden mich die 20 Euro nicht davon abhalten, wenn es Vorteile bringt :) Wäre es dann damit auch möglich, den Companion für die Ansteuerung meines Displays zu nutzen, wenn dort der Custom Treiber installiert wird? Nachdem ich sowieso während dem Spielen nicht unbedingt an allen Parametern gleichzeitig rumschraube, könnte ich mir behelfsmäßig das Dummy-Update bei Mod-Wheel events ausbauen, und meinen "Lieblings-Parameter" einfach per Mod-Wheel steuern. Überhaupt stelle ich komischerweise auch nicht bei allen Sequencer/Arpeggiator-Sounds Timing-Probleme fest, das beschränkt sich auf ein paar Sounds, die so richtig aus dem Tritt kommen (z.B. Arpseq Three, muß mal schauen, was an den betroffenen Sounds anders ist...) Bis dann, Seppoman

Hi Thorsten, I made a schematic from the PSU section, I hope I got everything right: First I thought it would be possible to simply desolder the 7805 and connect the 5 V supply there, but there´s also negative voltage involved (named LSP2 in the schematic, Eagle didn´t want to rename this output...). About where to get ground from an AC voltage, I don´t know anything about. Perhaps you can tell from the schematic. Do you see any solution? Thanks, Seppoman

Hi Thorsten, just tried 1.5b - works perfectly, no note hangs/squeaks anymore :) :) :) Seppoman

Hi Thorsten, zur Abwechslung mal wieder auf Deutsch :) weiß nicht ob Du meine Mail bekommen hast mit dem Treiber, aber das "in einen Custom Treiber umwandeln" hat sich eventuell erledigt (außer die Sonderzeichen-Geschichte). Ich hab mir den iic Treiber mal angeschaut und festgestellt, daß Du im iic Treiber kein ;; notify that no graphical LCD is connected bcf MIOS_BOX_CFG0, MIOS_BOX_CFG0_USE_GLCD drin hast, obwohl das laut Datenblatt auch ein CLCD ist. Deshalb hab ich die Zeile aus meinem Treiber mal rausgenommen, mit dem Ergebnis, daß er jetzt problemlos als Custom Treiber mit nomalem MIOS drunter funktioniert. Ist damit die Sache ok, oder hat es irgendwelche Nachteile (Timing), diese GLCD-Einstellung zu haben? Wenn ich das richtig gesehen habe, wird dadurch bei der Cursor-Positionierung eine GLCD-Routine verwendet, die einige Operationen mehr durchführt. Timeout-Routine hab ich mal versucht, allerdings weiß ich ehrlich gesagt nicht, ob sie funktioniert. Bei den ARPSEQ-Sounds führt das schnelle Hinundherdrehen von Mod-Wheel oder Encodern zu Timing-Problemen, die aber mit dem Timeout-Versuch auch nicht anders sind. Kannst Du die Auswirkungen der Timeout-Flags etwas erklären? Wozu gibt es .._TIMEOUT0 und .._TIMEOUT1? Wird bei Timeout das Display-Update zurückgestellt und erst wieder versucht, wenn dazwischen Realtime-bezogene Sachen erledigt wurden? Wenn das so ist, würde es dem Timing helfen, wenn der Timeout-Loop nicht bis 0xff zählt (wie im CLCD-Treiber) sondern früher abbricht? Wie Du siehst, hab ich mich noch nicht ganz damit abgefunden, das Display aufzugeben, weil 1. es einfach geil aussieht, und - wichtiger - ich letzte Woche schon das Loch dafür in die Frontplatte geschnitten habe... Übrigens hab ich gesehen, daß mit meinem 2x16-LCD die iXe auch beim Durchschalten zu erkennen sind. Bei dem haben allerdings Mod-Wheel-Bewegungen nur minimalen Einfluß aufs Timing. Bis dann, Seppoman

Hi, I built my MidiBox SID with the PSU Optimized cirquit. Because I want to integrate an Alesis NanoVerb in the box, I now added pins directly behind the power plug where I can get the required 9V AC out. The audio out from my two SIDs leads to 6,3 mm "direct out" jacks which combine the signals via 10k resistors to a mono signal for the NanoVerb when nothing is plugged in. So I just connected everything and when I switched the box on the fuse of the PSU blew. I checked the "direct out board for errors or short cirquits - everything ok. I admit I don´t fully understand how the PSU Optimized cirquit gets 14 V from the two voltages. Could it be that with this cirquit it is not possible to get the 9V out at the same time? Without load (nothing connected) I measure all three voltages correctly. The Alesis works fine when everything else is disconnected. Also the output board makes no problems when connected to the synth. Power consumption can´t be the problem either - I measure DC 5V 650 mA, AC 9V 10 mA without the Alesis, and the Alesis needs about 250 mA. So what´s the reason for the blown fuse? Thanks, Seppoman

Ok, sorry, I didn´t know the MidiMon before. When I send Midi from the computer, also the display is 2 lines behind the events, so I guess this is normal. So there remain only these empty lines as possible cause. happens especially if two keys are depressed at the same time: c2+d2 on -> Note C_2 80, Note 54 c2+d2 off -> Note C_2 0, Note 0 (two events added to read out what happened...) So the note pitch of the second one is omitted.. Seppoman so the

Hi Thorsten, I tested with Midimon: When turning the Mod wheel it looks like this: 1 I ModWheel 19 1 I ModWheel 23 1 I ->-> 27 1 I ->-> 31 1 I ModWheel 34 1 I ->-> 36 [...] Does this ->-> mean that this is a controller no. 27, 31 and so on? When playing notes display´s also very strange: What I play - What is displayed Switch on core -> 8 Lines No Event, 8 Lines FE Active sensing (Filter Button was not pressed yet) C4 on -> FE... C4 off -> FE... C2 on -> C_4 76 C2 off -> C_4 0 C2 on -> C_2 74 C2 off -> C_2 0 D2 on -> C_3 68 ; ??? C_3 was not played at all... D2 off -> C_3 0 D2 and E2 on -> D_2 76 and D_2 0 both off again -> D_2 56 and "Note 51" C2 on -> E_2 0 C2 off -> "Note 0" and so on. Looks as if the Midi Monitor gets behind the events or perhaps starts to read the wrong position in the buffer. Except the "Note 51" lines, which is nonsense, the normal events are remembered correctly but displayed when another event takes place. When I press the Filter button even a minute later, I get the missing events on the display, until the FE messages are also displayed. Seppoman

Just tested your FE example. I get: 00186DDB 1 -- B0 01 00 1 --- CC: Modulation 00186DDF 1 -- FE -- -- -- --- Active Sensing 00186DDF 1 -- B0 01 01 1 --- CC: Modulation 00186DE0 1 -- FE -- -- -- --- Active Sensing 00186DE0 1 -- B0 01 02 1 --- CC: Modulation 00186DE2 1 -- FE -- -- -- --- Active Sensing 00186DE1 1 -- B0 01 03 1 --- CC: Modulation 00186DE3 1 -- FE -- -- -- --- Active Sensing 00186DE4 1 -- FE -- -- -- --- Active Sensing 00186DE3 1 -- B0 01 04 1 --- CC: Modulation 00186DE5 1 -- FE -- -- -- --- Active Sensing 00186DE4 1 -- B0 01 05 1 --- CC: Modulation So the active sensing seems to be no problem... Seppoman

Hi Thorsten, I use a Terratec EWS88 Soundcard (also for Midi). For these examples I connected Midi Out (Yamaha) -> Midi In (SID), Midi Out (SID) -> Midi In (Terratec). So basically you see what data the slave gets from the master. Now I´ve made another one: Yamaha -> PC -> SID, so you see what the PC gets from the Yamaha: (...link removed...) This time the Mod wheel has no effect. I think the timing differences between the two channels/SIDs (which is about 30 ms) must be some Cubase/ASIO problem in my setup as there´s no audible Master/Slave delay when midi is routed through MIDI-OX. Doc: I think you have to put your image on some web space. When writing the message you click on the image frame symbol above the angry smiley and insert the URL between the image tags. Seppoman

Hi TK, here are the recordings: (...links removed...) This is for the Mod-wheel issue: I used ARPSEQ Three sound, played one note and turned the mod wheel up and down. Left channel is the master output, right channel the slave output, so use pan pot to hear one solo. (...links removed...) This is hanging note/squeak example: I played the Axel F theme with Internal Patch, so you know how it should sound... Both examples were recorded with cubase. I noticed that in Cubase the note on event is BEHIND the start of the sound. Possibly a config problem with Cubase, because when MIDI Out is connected to the master, I suppose the event should already have been sent to both slave and computer when the slave starts playing... Seppoman P.S. both recordings made with standard MIOS/SID versions and 2x16 display connected

Hi Doc, yes, I definitely need AC-multiconnectors, but 5 times isn´t quite enough ;) wanted to post a picture of my racks but my flash card reader has disappeared, so another time :) I just had a look on the C64 PCB. Directly behind the power jack there´s a µH thing (don´t know the english word, "Drossel") with eight pins and a condenser. I suppose the C64 PSU doesn´t filter the 9V AC line and this is done here in the C64. I will desolder the parts to see how they´re connected. Perhaps it would be sufficient to build a filter in the 9V AC line, so the 14V DC for the SIDs gets cleaner. Thanks for the hint regarding the disconnect problem. I just tested it and SID shutdown gets at least less likely with the shielded cable. Perhaps a shielded cable between core and sid module would also help further? Hum filter: I didn´t mean to filter the hum out of the audio out. Would be senseless to filter out deep frequencies from a fat synthesizer. What I meant is to build a LPF in the power supply for the display, because the display injects hum to the 5V DC line in my opinion (no oscilloscope so I can´t check this theory). If you´d get a filter with 5 Hz cutoff and 6 dB/octave (to keep it simple) in there, anything around 50 Hz or higher should be cut out quite effectively. The 6581 is just more responsive to this hum. I don´t know if it´s possible to build a LPF with that low cutoff. I will also ask the electronics professor at university next week about these issues. BTW: Could you confirm this "mod wheel slowdown" thing with your Yamaha? Select e.g. "ARPSEQ Three" and play it on Master and Slave while turning Mod wheel up and down. TK: I´ll produce the recordings for you this afternoon. Later, Seppoman

Hi Thorsten, sure I can, but I doubt it would be good for anything, because when I play through the MIDI interface, everything is OK, so a MIDI file of it would also play without a problem. If you like, I could e.g. play a few notes with Mod wheel with link mode on, record midi out and audio from the SID and send you .mid file plus .mp3 of the different results. So you could see what data the slave module gets. BTW: just found out that the SIDs stop working not only because of the fridge but also when I unplug/plug the audio out. Is this normal? Seppoman

Hi Thorsten, the note hang/squeak problem is also there with the standard MIOS/SID/LCD. I tested the slowdown thing again, I found "slowdown" only occurs (both with normal setup and VFD) when e.g. the ARPSEQ sounds are played by the slave. Sounds somewhat like the Mod wheel had become a sample scrub wheel... On the Master SID interestingly the Mod wheel turns down the volume quite smoothly when the kb is connected (also in both configs) - although MCC is set to 0 !? Perhaps when playing on both SIDs with a lot of CCs the VFD could cause some timing problems (not tested yet), but I´m absolutely certain that the problems with directly connected keyboard have nothing to do with the display (as I said everything tested in normal config). Also when playing single note lines with a bit of mod wheel, I didn´t find noticeable latency yet. Seppoman

Doc: Thanks for your suggestion :) . Is there a way to do power filtering also in the DC domain? I don´t even like external power supplys, so I would rather not be carrying around another box. Another filtering issue I have: When the VFD display Thorsten mentioned is connected to power I get a faint hum on the 6581 SID (not on the 8580 slave). This also occurs when the display is not connected to the core, so I think it can´t be a grounding issue either but the display injects ripple to the 5V cirquit. I thought perhaps a very low low pass filter in the 5V line could help this, but don´t have enough electronics experience to tell if this could help (and what type of filter should be used). Do you have any suggestion about that? TK: No, normally the keyboard doesn´t send CCs (and isn´t gm/xg compatible either). But I just noticed another strange thing: When connected to the keyboard, all WT sounds are extremely slowed down when I send aftertouch or turn the mod wheel. Routed through the computer this doesn´t happen (and as far as I can tell the Midi-Thru from MIDI-OX doesn´t filter anything, so except the Active Sensing or perhaps some electrical issue the SID should receive the same informations). Seppoman

Hi Thorsten, I see you´re also doing a night shift today :) the display can´t be the reason: I bought a cheap 2x16 hd44780 for testing before I got the VFD and this effect also occurs with standard MIOS/SID version. And with VFD connected it also only occurs when the Yamaha keyboard is directly connected to the SID. With the computer inbetween, everything is ok. Thanks for the timeout hint, I´ll check that tomorrow (and also will answer your other msg - I´ve got to get up again in 3 hours ;) ) Seppoman

Hi, But isn´t a ground loop normally a 50hz hum? This sound also is not always present but after some notes have been played there´s either a hanging note or this squeak (which sounds a bit like an extremely high note hanging). Both can be stopped sometimes by playing a lot of notes at the same time. I also tested this with Midi-Out N/C and DIN Plug away from the case. And I´ve got 18F version, so this is not the cause either. Seppoman

Hallo Thorsten, so, nachdem ich mal nen Tag Auszeit von Assembler gebraucht und ein paar Sachen an der Hardware weiter gebaut habe, bin ich wieder am Treiber. Das mit MIOS_LCD_Cmd / Data ist jetzt klar, die müssen ja beim Custom Treiber gar nicht von außen angesprochen werden. Die iXe hab ich inzwischen gefunden. In CS_MENU baust Du die erste Zeile des Menüs auf, indem Du erst "Pxxx C xx ----" schreibst, und dann die tatsächlichen Informationen drüberschreibst. Wenn man den String einfach in "P C " ändert, sieht man auch keine iXe mehr. Liegt also tatsächlich daran, daß das Display wohl recht langsam ist. Interessant fand ich, daß auch wenn man z.B. das Mod-Wheel bewegt, bei jedem MIDI-Event das Display upgedated wird, was ja im Hauptmenü auf jeden Fall unnötig ist. Meinst Du, daß das fürs Timing nachteilig ist (weil MIOS evtl. aufs Display wartet), oder ist das egal? Im Save-Menü flackert die erste Zeile, was wohl auch an der Geschwindigkeit liegt. und sobald man hier in P# geht, blinken erste und zweite Zeile abwechselnd. Ist das normal? Wenn nein, hast Du ne Idee, was man dagegen machen kann? Jedenfalls maile ich Dir gleich mal die mios_clcd zu. Vielen Dank schon mal! Und schon wieder ne neue Frage: Ich baue mir gerade die Frontplatte, auf der (u.A. wegen dem großen Display) nicht genug Platz ist, um sowohl für OSC als auch für ENV 5 Encoder zu montieren. Jetzt hab ich mir überlegt, daß ich ja dem OSC-Encoder-Layer-Schalter noch ne vierte Ebene samt LED verpassen könnte, so daß man zwischen OSC Envelope, OSC Misc, ENV Envelope und Assign (Menu_P1..P5) schalten kann. Ist das ein großer Aufwand? Viele Grüße, Seppoman

Hi, i´ve got exactly the same problem (squeezing note). I´m also using a Yamaha keyboard (SY77), which is sending Active Sensing. I´ve got some old Ensoniq keyboard, but it´s in the basement of my parents, 600 kms away, so I can´t test with this synth right now. If Active Sensing is the problem, it should occur with almost any synth connected as I haven´t seen a synth without active sensing yet. A.S. is a very unnecessary thing IMHO, it just makes LEDs on bigger interface boxes flicker and takes up bandwith... I´ve found no solution yet, except routing MIDI through MIDI-OX, which doesn´t help me very much because I mostly play keyboards in a band. So there´s no computer at the rehearsal room or on stage. I just checked the grounding issue. Grounding the middle pin to c64 PSU 5V negative line or to security ground of the wall outlet doesn´t help. Another problem: Every time my fridge starts or stops humming, the SID doesn´t output notes anymore until I change the patch up and down again. Possibly coming from bad power source in the house, but how can I avoid this? On stage, power supply mostly isn´t good and clean either (because of the light dimmers etc.). Any help is appreciated :) Seppoman

Hi Thorsten, ich bastle weiter am Treiber-Einbinden herum, ohne Erfolg. Jetzt wollte ich versuchen, in MIOS den CLCD-Treiber einfach direkt anzupassen. Compilieren konnte ich das MIOS, aber das hex2syx hat mit folgendem Fehler abgebrochen: You are trying to overwrite the MIOS adress range.[..] Ich hab jetzt mal versucht, einfach den Original-Quelltext zu compilieren, mit dem gleichen Ergebnis. Ist da in Deinem Release noch irgendein kleiner Fehler, oder mache ich was falsch? Bis dann, Seppoman --------------------------------------- Edit: durch die Frage von psytron in Latest News bin ich selber draufgekommen  ::) Ist natürlich klar, daß, wenn man MIOS hochlädt, man den MIOS Adress Range überschreibt. Peinlich, peinlich :) Der Treiber funktioniert wunderbar, einzige kleine Macke: beim Durchschalten der Patches flackern in der ersten Zeile manchmal kleine "x" an den Stellen vor den Zahlen auf. Werd mir mal die CS_MENU-Routinen anschauen, ob diese iXe auch so gesendet werden und mein Display einfach träger als normal ist, oder obs doch noch irgendwie am Treiber liegt. Für Sonderzeichen hab ich provisorisch einfach x00 und x01 auf die ASCII-Symbole "Doppelpfeil" umgelenkt, da das allgemeingültig-MIOS-konforme Definieren von Zeichen etwas aufwendig ist - Das VFD hat nur 5x7 Pixel, also müßte man erstmal die Tabelle umwandeln, und die Pixel werden verschachtelt übertragen, also erstes Byte ist Zeile 1[1..5],Zeile 2[1..3] usw. Die SID-Applikation gibt ja sowieso nur die Pfeile aus, und dafür reicht << und >> erstmal. Trotzdem wäre es natürlich gut, den Treiber als User LCD einbauen zu können, damit man 1. nicht bei MIOS-Updates jedesmal im Code rumpfuschen muß und 2. der Treiber genauso wie die anderen Custom Treiber einzubinden ist - wenn ich alles fertig habe, wäre es wohl schon für den einen oder anderen nützlich, wenn der Treiber hier in die Sammlung aufgenommen würde und dann nicht alles anders ist als sonst. Warum wird bei MIOS_LCD_Cmd und MIOS_LCD_Data eigentlich bei Typ 7 nicht USER_LCD_Cmd/Data aufgerufen? Wenn ich das richtig sehe, macht _Cmd bei Typ6 und Typ7 gar nichts, _Data nur bei Typ7 nichts? Wobei das ja eigentlich nicht der Grund für die fehlende Ausgabe bei der SID-Applikation sein kann, denn bei der CLCD7-Beispiel-Applikation gehts ja auch. Jedenfalls Langer Rede Kurzer Sinn: Wie integriere ich einen Custom Treiber in die Applikation, so daß er auch wirklich verwendet wird und nicht das MLCD aktiviert wird? Vielen Dank, Seppoman

Hi Thorsten, Noch eine Frage (sorry wenns langsam etwas viele auf einmal werden...): Ich versuche gerade, den Treiber in die SID-Applikation einzubauen. habe app_lcd getauscht. PIC ID sowohl mit Typ 0 als auch Typ 7 gesetzt. MIOS 1.5 unverändert hochgeladen. In SID sowohl mit als auch ohne USER_INIT movlw 0x07 call MIOS_LCD_TypeSet probiert. und bekomme nur entweder wirres Zeug (wohl wenn typ0 oder auto) oder MIDI-Display per SysEx. Woran liegt das, hab ich was vergessen? Vielen Dank, Seppoman

Hallo Thorsten, Vielen Dank, mit Deinem Code funktioniert das Ganze wunderbar :) Zu meiner Routine: Laut PIC-ASM-Referenz im Datenblatt erlauben call/return einen zweiten Parameter: Syntax: [ label ] CALL k [,s] [...] If &#8217;s&#8217; = 1, the W, STATUS and BSR registers are also pushed into their respective shadow registers, WS, STATUSS and BSRS. If 's' = 0, no update occurs (default). Then, the 20-bit value &#8217;k&#8217; is loaded into PC<20:1>. Bei return genauso. So ganz verstehe ich die ganze Register/Adressierungs-Geschichte nicht, aber ich hatte den Eindruck, daß irgendwie WREG nicht vernünftig verarbeitet wird, und die 1 dazu bringt das Ganze wenigstens irgendwie zum Laufen... Warum das weder mit noch ohne 1 geht, verstehe ich nicht. falls W > 3F, sprung, dort den Teil unter 40 holen und 28 dazu Wenn W z.B. 40h ist, müßte andlw 0x3F -> W=0 ergeben. 28h dazu -> 1.Zeichen 2. Zeile... Naja, ist nicht so wichtig, mit der BIFSET-Lösung ist ja alles OK. Die Subroutine hab ich auch nur gebaut, weil ich nicht wußte, wie man mit einem einzigen Befehl einen Wert abzieht, da die subXX-Befehle ja immer W von etwas abziehen und nicht umgekehrt.... Sonderzeichen: Wie funktioniert das mit den Vektoren, bzw. woher weiß ich, wohin der Vektor zeigen muß? (wie gesagt, mit der ganzen Speicherverwaltung kenne ich mich noch nicht aus) Wegen Netzteil: Ich verwende C64-PSU-Optimized. Momentan hängt daran außer dem VFD nur der Core und eine SID-Platine. Interessanterweise gibt es keine Random-Events, wenn man beim SID-Modul die 14V-Leitung abklemmt, auch nicht, wenn ich das zweite SID-Modul auch noch mit 5V anschließe. Das C64-Netzteil hat 1,5 A bei 5 V, Das Display zieht max. (also wohl beim Einschalten) 1 A. nur 1 Core und 1 Sid werden keine 500 mA brauchen? Viele Grüße, Seppoman

Hallo, so, nach einer langen Nacht geht das Ganze jetzt einigermaßen. Das Einzige was noch nicht richtig funktioniert, ist die Cursor-Positionierung. ---------------------------------------------------------- USER_LCD_CursorSet movlw 0x10 ;Cursor positionieren call USER_LCD_Cmd SET_BSR MIOS_LCD_CURSOR_POS movf MIOS_LCD_CURSOR_POS, W, BANKED cpfsgt 0x3F call USER_LCD_CursorSet_Y1, 1 rgoto USER_LCD_Cmd USER_LCD_CursorSet_Y1 andlw 0x3F addlw 0x28 return 1 ------------------------------------------------------------- Hierbei wird die zweite Zeile nicht korrekt verarbeitet. Weshalb die 1 bei call/return sein muß, weiß ich nicht, geht ja sonst auch ohne, aber hier Chaos. Mit 1 kann man in der ersten Zeile positionieren, die zweite ist aber falsch - das Display zählt in der zweiten Zeile direkt weiter, 28h ist also das erste Zeichen. Wenn ich z.B. auf (MIOS)Zeichen 40h will, springt das Programm in die Unterroutine (hab ich überprüft), ändert aber anscheinend trotzdem nichts an der Positionsadresse, d.h., das Zeichen erscheint bei 40h nach Zählung des Displays. Was irgendwie komisch ist, denn selbst wenn ich in der Y1-Routine einen Denkfehler hätte, irgendwas müßte sich trotzdem ändern. Hast Du ne Idee? Zu den Sonderzeichen: Das VFD kann auch selbstdefinierte Zeichen. Kann man die über den Custom-Treiber auch einbinden, oder müßte ich dafür die CLCD-Routine direkt ändern? Und gleich noch ne Frage: Seitdem ich das VFD dran habe (hatte vorher testweise ein kleines LCD) zeigt mir MIDI-OX immer beim Einschalten ein Bündel beliebiger MIDI-Daten (Noten, Controller, Realtime usw.). Das Display produziert also wohl beim Start irgendwelche Störungen. Kann man die mithilfe von z.B. einem dicken Elko an der Display-Versorgung vermeiden? So, nachdem die Nachbarn schon wieder wach werden, muß ich doch mal Schlafen gehen ;) Viele Grüße, Seppoman

Hi Thorsten, tausend Dank für die ausführlichen Infos :) Ich habe gestern abend schon den MIOS Quellcode runtergeladen und die ganze Nacht mit der PIC-Assembler-Referenz und der CLCD Routine verbracht. Zumindest teilweise verstehe ich glaube ich, was da passiert. Mit Deinen Tips hast Du mir aber wohl mindestens 1-2 Tage Nachdenken erspart ;) Wegen Initialisierung: Laut Datenblat ist das Display nach dem Einschalten in Vertical Scroll mode mit aktiviertem Cursor. Wird das Display sowieso wo anders auf Normal ohne Cursor gesetzt, oder muß ich das doch hier machen? Naja, ich werd mich heute Abend mal ausführlich damit beschäftigen und weiter berichten :) Viele Grüße, Seppoman