Re: SweetAda 0.1e released

[gabriele.galeotti.xyz@gmail.com]

On Monday, July 27, 2020 at 4:02:48 PM UTC+2, Roger Mc wrote:
> On Monday, July 27, 2020 at 11:18:47 PM UTC+10, gabriele.g...@gmail.com wrote:
> > 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 wrote: 
> > > > On Sunday, July 26, 2020 at 3:51:41 AM UTC+2, Roger Mc wrote: 
> > > > > I reinstalled 0.1e and now it works, at least to the extent that 0.1d works. 
> > > > > Quite strange as I had the same problem on both my computers. 
> > > > > The only thing that I can think of is that on the previous 01e install I just used 
> > > > > ./menu.sh ( without target selection) 
> > > > > which was the method I used for 0.1d. Perhaps this messed something up? 
> > > > > When that didn't work, I inspected 0.1e menu.sh and discovered the need to use target selection; 
> > > > > however, on using target selection, in the order stated in your advice (perhaps eventually), I had the reported problem. 
> > > > > It seems, somehow I messed something up; somehow on both computers! 
> > > > > Thanks for your much appreciated advice. 
> > > > > 
> > > > > I still haven't tracked down the Catalina problem. Inspiration comes slowly. 
> > > > > Certainly, the Ada code is working correctly but, somehow the assembly coded outb instructions in x86_64-io don't seem to be having any effect. 
> > > > > Possibly being blocked by Catalina security features? 
> > > > > I currently don't know how to track outb functionality. 
> > > > > I'll keep trying (slooowly) 
> > > > Hi Roger. 
> > > > 
> > > > 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) and repeat a fresh installation, so you could check that you have a perfectly aligned layout, without previous mistakes. 
> > > > 
> > > I just received your message recommending awaiting the next release. 
> > > 
> > > > 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? 
> > > Thats correct. I had the IOEMU window working and showing I/O widgets cycling under High Sierra but still not under Catalina. 
> > > > 
> > > > In this case maybe there is either a problem in the GUI code or in Catalina handling of windows. 
> > > > 
> > > > But you can assume safely that Ada code is working since you should see some output in serial terminal. 
> > > Yes I'm very confident that the Ada code is working and certainly see output in the serial terminal and the QEMU window. 
> > > > 
> > > > About the outb instruction, please explain me (even writing down your code) what you are trying to do. outb instructions should behave fine, otherwise you should see a totally dead system. 
> > > 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 understand. 
> > > My current understanding is that it is PIC procedures in pc.adb that should drive the I/O widgets cycling in the IOEMU window via the in X86_64-io outb instructions? 
> > > > 
> > > > 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 and 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 likely to change in CPU.IO. Ask me if you have difficulties recompiling your code. 
> > > 
> > > 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 understand how things work. 
> > > 
> > > I have spent today coming to grips with MPLAB via various MPLAB tutorials, which also included tutorials on PIC hardware and interfacing. This, eventually has been quite rewarding but I still have some way to go to reach adequate knowledge. 
> > > 
> > > 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 future. 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 platform development there are no calls to PC.PIC unit. This is done in the 32-bit platform, which isn't your choice. Maybe you mean PC.PPI, which is the 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 different context. 
> > 
> > And this is done because I had to reprogram the Programmable Interrupt Controller (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 the 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 interface. 
> > 
> > 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/outl, whatever instructions is picked up by the compiler thanks to overloading on the proper size of the data to be handled. If you want to output an Unsigned_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 widget by IOEMU, which visualize it in real-time. 
> > 
> > The there is another set of I/O ports available to be shown in IOEMU, you can read their addresses when QEMU start. You can create an I/O section in qemu.cfg and assign to these ports a widget and then make a PortOut also on them. 
> > 
> 
> Many thanks for this which I will study in detail. Nothing is trivial. My "level of knowledge" in this context is low.
> I have been confusing the PIC (programmable interrupt controller) in the PC chipset) with a PIC microcontroller which I thought i8259 PIC was referring to.
> I think I need to study QEMU and  IOEMU in depth which I hadn't got around to yet.
> Actually, perhaps demonstrating my level of ignorance, I'm baffled as to just where QEMU and  IOEMU "are" in the sweetada distribution?
> Presumably such a question demonstrates my limited knowledge.
> My only clues at the moment are that QEMU and  IOEMU are windows which must be generated somewhere; but so far I haven't been able to discover the "somewhere".
> When I first started looking at sweetada, I did install a QEMU system to get some understanding and successfully installed Ubuntu it. But that was just a familiarity exercise which I have since deleted. 
> 
> > If you want to send me a piece of code, you can try gabriele...@sweetada.org
> This was actually a diagram which I will now update in conformance with your description.
> Apparently this Groups message editor is supposed to have a format toolbar from which attachments can be made but no such toolbar shows up on either of my Macs.
> Again, your explanations are much appreciated,
> Roger

I sensed the strange PIC problem.

In sweetada context, QEMU is a more or less normal QEMU that is used as an aid in development. e.g.,if you want to try sweetada code on a MIPS cpu, or a PowerPC, maybe it is better to exercise on an virtual machine. That's why exists a QEMU. QEMU is patched so that every machine it could emulates has additional I/Os that normally do not exist in that machine. Like a generic I/O card inside a computer. For example, if you choose a SPARC cpu (an thus an emulated machine like a SPARCstation5), it is difficult to have immediate evidence, because you have to low-level program a huge number of things, like the video framebuffer. Instead, you manipulate those simple I/O and IOEMU lets you visualize them on his own window. QEMU package is a normal QEMU distribution (apart the patches, that I have to make public soon, just the time to adjust them in a decent form), and IOEMU is an indipendent library added inside the distribution, but it's nothing more that a GUI manager for widgets, together with a parser for ioemu.cfg configuration files. Again I will release the source once that the code is cleaned up and stable. I make huge changes everyday, and don't want ugly things spreading off the net.

By the way, you can run QEMU without IOEMU, just delete the library file. Then supply QEMU with your own firmware by standard command line options. QEMU for sweetada has nothing different.

To be honest, if you want to study QEMU from a low-level point of view, prepare yourself for a long journey. It's incredibly complicated. And Sweetada does help you very little in doing that. The focus of sweetada is currently to adapt Ada code to machines.

G