From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:aed:21da:: with SMTP id m26mr22179578qtc.197.1595855925779; Mon, 27 Jul 2020 06:18:45 -0700 (PDT) X-Received: by 2002:ac8:4451:: with SMTP id m17mr6262472qtn.299.1595855925539; Mon, 27 Jul 2020 06:18:45 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 27 Jul 2020 06:18:44 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=95.250.125.238; posting-account=JRF_-woAAABYlsAtkCl_CUxBuQy2SsaQ NNTP-Posting-Host: 95.250.125.238 References: <748b7abb-4bda-4174-aa37-367daaf1c02ao@googlegroups.com> <6cbf26a5-2047-4685-a87b-381bc5fedd5bo@googlegroups.com> <4472b2d0-e872-46c9-8665-af1fea1cc8c4n@googlegroups.com> <62b1618d-e93d-42f4-9970-314685e2c01ao@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: SweetAda 0.1e released From: gabriele.galeotti.xyz@gmail.com Injection-Date: Mon, 27 Jul 2020 13:18:45 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59547 List-Id: On Monday, July 27, 2020 at 1:34:28 PM UTC+2, Roger Mc wrote: > On Monday, July 27, 2020 at 8:51:55 PM UTC+10, gabriele.g...@gmail.com wr= ote: > > On Sunday, July 26, 2020 at 3:51:41 AM UTC+2, Roger Mc wrote:=20 > > > I reinstalled 0.1e and now it works, at least to the extent that 0.1d= works.=20 > > > Quite strange as I had the same problem on both my computers.=20 > > > The only thing that I can think of is that on the previous 01e instal= l I just used=20 > > > ./menu.sh ( without target selection)=20 > > > which was the method I used for 0.1d. Perhaps this messed something u= p?=20 > > > When that didn't work, I inspected 0.1e menu.sh and discovered the ne= ed to use target selection;=20 > > > however, on using target selection, in the order stated in your advic= e (perhaps eventually), I had the reported problem.=20 > > > It seems, somehow I messed something up; somehow on both computers!= =20 > > > Thanks for your much appreciated advice.=20 > > >=20 > > > I still haven't tracked down the Catalina problem. Inspiration comes = slowly.=20 > > > Certainly, the Ada code is working correctly but, somehow the assembl= y coded outb instructions in x86_64-io don't seem to be having any effect.= =20 > > > Possibly being blocked by Catalina security features?=20 > > > I currently don't know how to track outb functionality.=20 > > > I'll keep trying (slooowly) > > Hi Roger.=20 > >=20 > > Fine, the most important thing is that we have verified that tools run = correctly. Maybe it could be useful to delete everything (after a backup) a= nd repeat a fresh installation, so you could check that you have a perfectl= y aligned layout, without previous mistakes.=20 > > > I just received your message recommending awaiting the next release.=20 >=20 > > Correct me if I'm wrong, I understood that IOEMU window is working and = shows I/O widgets cycling, but not in Catalina, is that correct?=20 > Thats correct. I had the IOEMU window working and showing I/O widgets cy= cling under High Sierra but still not under Catalina. > >=20 > > In this case maybe there is either a problem in the GUI code or in Cata= lina handling of windows.=20 > >=20 > > But you can assume safely that Ada code is working since you should see= some output in serial terminal.=20 > Yes I'm very confident that the Ada code is working and certainly see ou= tput in the serial terminal and the QEMU window. > >=20 > > About the outb instruction, please explain me (even writing down your c= ode) what you are trying to do. outb instructions should behave fine, other= wise you should see a totally dead system.=20 > The outb instructions that I was referring to are those in X86_64-io.adb = which are invoked by pc.PIC procedures which I have been trying to understa= nd. > My current understanding is that it is PIC procedures in pc.adb that shou= ld drive the I/O widgets cycling in the IOEMU window via the in X86_64-io= outb instructions? > >=20 > > By the way, apologies if I repeat myself, but try to isolate your code = in an application file like the standard one, I'm changing some with/use an= d simplify units, so expect some minor changes in future release. This way = you can change very little in your code. For example, unit x86_64.IO is lik= ely to change in CPU.IO. Ask me if you have difficulties recompiling your c= ode.=20 >=20 > Understood. But, at the moment I'm nowhere near producing my own code and= am essentially trying to "reverse engineer" your code in order to understa= nd how things work. >=20 > I have spent today coming to grips with MPLAB via various MPLAB tutorials= , which also included tutorials on PIC hardware and interfacing. This, eve= ntually has been quite rewarding but I still have some way to go to reach a= dequate knowledge. >=20 > I've not tried sending files via Google Groups before so I don't know if = this works! > If it does this shows my current understanding of the system > /System/Volumes/Data/QEMU/sweetada_run.pdf.zip OK. Maybe the Catalina problem is an issue we could solve in the near futur= e. If you have an environment that does work, that is very fine, so we have= a common base. Now for the outb instructions. No, pc.pic instructions do not drive IOEMU graphics widgets. Let me explain= . I say again, I do not known your level of knowledge so I will go deep in = order to not be misunderstood. Sorry for trivial things. You are inside an emulated virtual machine, thanks to QEMU. This machine is= a more or less standard x86-64 cpu PC machine. In the current PC-x86-64 pl= atform development there are no calls to PC.PIC unit. This is done in the 3= 2-bit platform, which isn't your choice. Maybe you mean PC.PPI, which is th= e parallel port. I hope you are not confusing the PIC (programmable interrupt controller) in= the PC chipset) with a PIC microcontroller, which are two entirely differe= nt context. And this is done because I had to reprogram the Programmable Interrupt Cont= roller (PIC) that's inside the chipset of every PC. It is needed for proper= handling of interrupts (that I have yet to write down for x86-64, unlike t= he 32-bit platform, which is more "mature"). I/O widgets are excited by instructions in applications.adb. Now, there are= two sets of "visible" I/O. One set is 3 I/O ports of the parallel port int= erface.=20 By calling PC.PPI... you read or write something in this ports. So: applications.adb: calls PPI_DataOut (Value) pc.adb: PPI_DataOut() implements a calls to CPU.IO.PortOut (Value) Note that pc.adb with's CPU.ads Inside cpu.ads, CPU.IO.PortOut is a renaming of x86_64.IO package. Inside package x86_64.IO, finally, PortOut is implemented as on outb/outw/o= utl, whatever instructions is picked up by the compiler thanks to overloadi= ng on the proper size of the data to be handled. If you want to output an U= nsigned_8 value (the right choice because it's an 8-bit port), then procedure PortOut (Port : in Unsigned_16; Value : in Unsigned_8) is picked up. The same also for "control" and "status". Every port is then tied to a widg= et by IOEMU, which visualize it in real-time. The there is another set of I/O ports available to be shown in IOEMU, you c= an read their addresses when QEMU start. You can create an I/O section in q= emu.cfg and assign to these ports a widget and then make a PortOut also on = them. If you want to send me a piece of code, you can try gabriele.galeotti@sweet= ada.org