Hi, Disclaimer: I don't know what Server64 is or really the scope of environment is your describing but I caught that there was connections to some control lines and possible code changes. I don't know how the PC is connected or what function is serves from the description Using the symptoms of C128 runs when speed booted into C64 mode and possible runs if hooked up after booted then I would start to think of a race condition during the initialization phases or something grabbing a hard control line like the reset which runs everywhere. 1) Scope the reset line where it comes up to the 6502/8510 and see if it is active and that it didn't do any kind of stutter step that that confuses the internals of the '02. 2) Consider that lines like the NMI and IRQ are valid lines to toggle but if they are active at the wrong time, I.E. before the MMU is set up for example then they could result in attempting to jump to an interrupt while memory or map is in an illegal state. * Check if /IRQ is already low or goes low early after /Reset. If you are hooking the code doesn't let a CLI get executed until the system really is ready for an interrupt. Sometimes this means not calling a "normal" call too early as it may CLI so that interrupts can nest or if something clears the mask to early. * Check if there is an /NMI edge way early, again the processor is forced to jump to the NMI Reset vector and if _anything_ needed to execute the code is missing or not initialized it could/should crash. * Honestly I forget the order of things, I used to be able to trigger on something near the end of the initialization stuff but I have long since forgotten the details. The concern would be more of the same if code is hooked or an interrupt and NTSC hasn't been set yet, or all of the sources of real interrupts haven't been enabled so that you actually cant clear an interrupt. Check that /IRQ's are already stuck low before crash, once times are set they could go low after the crash. Maybe successfully executed interrupt but didn't have anything to return to or it is stuck processing nothing but interrupts. One time it took 15 minutes to boot because it would execute exactly one instruction before going back into /IRQ. (Missing pullup syndrome, how to make your system crawl over a $.01 part) Bil -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Baltissen, GJPAA (Ruud) Sent: Thursday, February 23, 2012 9:43 AM To: firstname.lastname@example.org Subject: ATN trap needed for C128 as well? Hallo allemaal, I was given a PC case made of Perspex. It is quite wide and that gave me the idea of placing a C128 left of the drives and in such a way that all connectors were accessible. As the C128 was placed on the left side, there would be no room for the original PC board. But before cutting the needed holes, I got the weird idea to exchange the side plates and turn the back plate upside down. This still enabled me to install a PC as well! My IEEE drive emulator originates from Server64. At that time I replaced the IEC routines by IEEE ones. The idea rose to add the IEC routines so I could use this PC as IEC drive emulator. I started with the original program to make sure things worked out fine. But it didn't. two problems: after a reset READY wouldn't appear until I disconnected the cable and directories didn't appear on the screen as they should. (I didn't try more things) I remembered that that happend as well when I tried to improve the program 15 years ago. But at that time I bcame more interested in the CBM's and decided to use for IEEE drives alone. But yesterday evening I booted the C128 into the 64 mode by pressing the C= key and things ran fine, but why ??? Today I had a look at CBM-HD to see what I had to change. With an exception everything was quite low-level so I didn't forsee many problems. The exception were the routines to de/activate the ATN trap. I first thought about adding a line in the sprit of "if it is an IEC devive, simply exit the routine now". But then I realised that this phenomen looked like the problems I had with the IEEE drives years ago (that is, IIRC). If this is indeed the case, I have to have another look at the software to see if I can create a ATN trap there: Nick Coplin's 64HDD can do it as well! In the worst case I have to tinker a bit with my hardware. But I have no idea what causes the C128 NOT to start up as long as the PC is connected. I see on the screen that Server64 goes into action the moment the C128 has been reseted but haven't any idea yet what it is waiting for. Anyone an idea (could save me some time)? Many thanks! -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| URL: Ruud.C64.org De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. APG Algemene Pensioen Groep NV is gevestigd te Heerlen en is ingeschreven in het handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617 The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose it's contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. APG Algemene Pensioen Groep NV is registered in the trade register of the Chamber of Commerce Limburg, The Netherlands, registration number: 14099617 Message was sent through the cbm-hackers mailing list Message was sent through the cbm-hackers mailing listReceived on 2012-02-24 19:00:06
Archive generated by hypermail 2.2.0.