@davec555 @MartinW

I will comfort you or sadden you ... and yes sgit will not work.
As I wrote earlier I did a quick compilation test.
I checked my sources but ... my mistake was that I did not check what @Raziel wrote
https://www.amigans.net/modules/newbb/ ... id=145316#forumpost145316

The fact that the program compiles is not everything. It's not a problem with SSL, it's a problem with the old libgit2 library.
It overruns the right ranges and therefore does not work. Who will fix it? I do not know
I hope I am wrong and @billyfish finds a solution and refutes my thinking

@AmigaOldie

Some CDs can deteriorate over time, although it could be a combination of factors such as the lens alignment or laser quality of the drive. As you have a system that is able to read the discs, it might be worthwhile doing a 1:1 copy of them to new good quality discs (I'd recommend Verbatim CD-Rs).

Or, you could create an ISO image of the CDs and use DiskImage to mount it on the A1222, which is probably easier.

Kind regards,

Francis

@smf

I typed what sou say and it said:

"VERSION: object not found"

Even with "smartfilesystem" as lowercase

@joerg
I was told that the first hook (Even wasn't called callhook, but some older initial version) was the one which is used internally in the utility.library, for the string gadget. And it was in Alpha 15 of AOS2 (~1.4 somewhere in ks 35.xx). Prior to that, there wasn't any hooks usage inside the amigaos at all (in any function). I.e., no amigaos prior 1.4 have inside internally any hooking functionality of any sort, just direct usage of function and pointers, etc. By date it was in 8 june 1989. So it was first time of first hook internal (!) usage in utility.library, not even user-allowed code was. And it was Alpha of amigaos2 (So wasn't released anything prior with giving hooking functionality).

Then after 6 months, in the same "internal" code changes, in the beta1 of amigaos2.0, they made CallHookPkt(). So, fresh function, all fine, nothing released to anyone (except maybe this "beta of os2, named 1.4 for a3000). And then, in amiga.lib v37 (i do not know date exactly, and dunno what ks it was with it), then created CallHook/A in.

Taking into account that internally only utility.library use it (and when it use it, it wasn't called callhook, but just some internal name) , and that they have utility.library with callhookpkt already, i fail to see why they create CallHook/A.

I mean, it didn't looks like for support OS1.x, because not internally, not externaly hooking vere done for OS1.x. Maybe issues was all this C compilers (and maybe assembler ones?) asking for things to be on stack, so to make live of assembler programmers easy or something ? There should be another reasson, i just want to understand what one :) To fully fill the whole historical picture in OS3, before further annoying everyone about OS4 :))

@smf

Yes

@HypexQuote:
No, I can't do that, because absolute address 4 may not be available for me to use on an Atari etc etc.

Do you need an alternative to ExecBase? Any program can read it from $4 (or 0x4) any time it likes. An alternative implies you are replacing it and I don't think you intend to rewrite an existing core kernel.
[/quote]
When run on Atari, or Linux, I am "rewriting core kernel" - there is no alternative - the Amiga doesn't exist at all.

Anyway, here is the current state:

[kerravon@paul-pinebook xxx]$ qemu-m68k ./bios.exe pdptest.exe "abc def"

bios starting
about to execute program with entry point C080202C
welcome to pdptest
main function is at C0802200
allocating 10 bytes
in callocmem
m1 is C0CC7008
allocating 20 bytes
in callocmem
m2 is C0CC8008
stack is around C07FFE70
printing arguments
argc = 4
arg 0 is <UNKNOWN>
arg 1 is <pdptest.exe>
arg 2 is <abc>
arg 3 is <def>
Segmentation fault (core dumped)
[kerravon@paul-pinebook xxx]$

I'll investigate the remaining things "tomorrow". Source is in sourceforge and those two executables are available as an attachment on the other forum I mentioned previously.

So that's the Amiga emulator.

Now on to PDOS-generic for the 68000 which could run under Amigados as an example ...

Quote:
The standard - or indeed - definition - of PDOS-generic is that it takes a pointer on the stack to a list of functions such as printf. And that has been working for something like 6-12 months (can't remember - but could look it up) and those executables are available from pdos.org but until now I had no ability to personally test them.

If there was a reason to there could be an alternate interface, but that's what I use on all environments (e.g. 80386).

@smarkusg I gather your new build is from the latest simple git on github from sba1?

If so, do you mind post8ng the new binary?

Thanks
Dave.

Ps. Old version is working for me, but I need to see what the size of the project that I am using it with is.

@kas1e
Quote:After AmigaOS 2.0 was released for at least 5 years, maybe even longer, most AmigaOS software was still built to work on AmigaOS 1.x as well.
Even if there are no Hooks in AmigaOS 1.x itself user code of that time built for both AmigaOS 1.x and 2.x probably used them internally, for example in functions used on AmigaOS 1.x only adding support/replacements for new AmigaOS 2.x features, as well as in the AmigaOS 2.x parts.

Except for AmigaOS 1.x support there is no reason at all to have a CallHook[A]() function in amiga.lib since CallHookPkt() is available in the AmigaOS 2.0+ utility.library.

@dfstudios

Welcome. I too, am in the process of building my A1222.
Nice to see others doing that too

@smarkusg, @all

I think it's still publishing, but in case it helps anyone. Although I doubt it!

As it says at the end of the video, the sun is shining for once here in the UK, so I'm going out

@Joerg
Quote:

That is strange, because as far as i know, there wasn't any callhook/callhookpkt until V36.8 (i.e. till amigaos 1.4 there wasn't any user-possible-used callhook() or callhookpkt() ). Even more, the single mention of first hooks in internal os3 code (checked by os3 developers), is dated by alpha 15 of amigaos2.0, with only internal use for utility.library. Only starting from beta1 of amigaos2.0 there were introduced callhookpkt(), and then a bit later were introduced callhook()/callhooka() in amiga.lib.

In other words, there wasn't any reasons to support 1.x code, as there wasn't any hooks at 1.4 times. It was a fresh addition from scratch. There should be some other reasons why they make 2 different functions doing the same, but called different and one placed in utility.library and another in amiga.lib (and the later on is surely worse, as take more stack space, right? )

@MartinW

larger downloads without any problem) . But as I wrote I don't use this tool. I'm sure you can do better and adapt it to your needs. I just recompiled sgit for a test and out of curiosity. If you need anything let me know.

@smarkusg so, firstly, the fact that sgit works for you there is highly likely down to the size of the repo you are checking out. 1.6MB will likely be fine. My repo is around 19MB and it fails at 98%. Like I said, I cut it down to a smaller repo which isn't a desperately sustainable solution and it did complete the checkout, but then it choked on a symlink.

But more importantly, it would be good to know how you built it. Because cloning simplegit to my Mac, then running the build inside the docker cross compiler didn't work. And I don't believe I'm alone in that. If it worked then we could look into things.

Maybe later today I can find some time to go back to it, have another go and post some of the problems.

[edit] I need to try the idea of cloning to the ram drive. That speedup could get round the SSL error on the larger repo. Only could because I think the speed issue comes from the network on OS4, not the disk.

@MartinW

i don't use this tool, but i quickly recompiled it under openssl and something works there....
i haven't checked anything else but clone and chechout



you can definitely do it

@thread

I've been following this thread with interest because I, too, have been building up my A1222+ and also have CD/DVD issues, although I think, in my case, it may be the particular CDs I'm trying to read.

I have a copy of Wordworth Office 6 and a copy of Vulcanology (the first 9 or so games by Vulcan Software - Bograts, etc), neither of which even show up on the desktop.

I have tried other CDs (mainly Amiga Future cover discs), which read OK.

The two particular ones I have problems with, I have tried in an iMac and a 2012 laptop, with no result, then in a 2015 laptop, where they do read.

The Amiga Future cover discs are professionally produced, whereas the Wordworth and Vulcanology are licensed copies, but produced by the vendor. I'm thinking that the professionally produced CDs were produced using a stronger laser, perhaps.

I seem to remember I used to have a CD/DVD writer and a CD writer in my old A1-XE, one of which was better at reading certain disks than the other.


The unit I have at present in my A1222+ is a new Asus CD/DVD/DL writer. I do have a slot loading CD/DVD writer which I'll try and see if that improves matters. I do also have an external drive which I'll try out.

Would be great if you could spare the time, even if it's just to see if we can work out why we can't build the existing sources so that we can dig into the issues. I'll have to go back and have a look at why the build was failing when trying to build simplegit source itself. It wasn't the easiest of things to track down though as it was downloading stuff and patching stuff and doing a lot of things beyond simply building.

@MartinW
Quote:

That's ok :) You are not the first one and sadly not the last one who by some reasons at first think that obscure AmigaOS4 it is something which worth _that_ much. And that it have all the tools and languages available, and have a lot of developers and users. That of course was never and never will the case. Remaining of us trying to fix it in one or another way, but there are just not so many of us (and never will).

Any obscure OS will have lack of tools, many strange things, lots of unfinished and unreleased stuff (and even released, but then removed), and lots of pure strange and unlogical things. Some of us tried as hard as possible to explain that for every newcomer about, that they not need to hold a lot of hope for, a lot of praise for, and there are no needs to make os4 looks as it didn't look like: in real is just obscure OS for the fanatics, hackers, low-level coders and all sort of ppls who in interest in “strange” things. But it will never be "usual OS where all available".

The usage of the cross-compiler is simply better at current time because of above reasons : we have few developers, they all busy with everything else, so instead of spend their time on making native version of sgit , or awk, or whatever, they will be better use bug free, 100% times tested by 1000..xx users and developers around the world from compiler version to produce _native_ version of their tools. Not native building ? Yes, of course not native! Is it bad ? In current realm we should be happy that we even have cross-compilers , so we have a way to make work to be done with less issues, or to be done at all : for example, if not cross-compiler, there will be no Odyssye before, because even compilation of Odyssey few years ago for me on normal modern notebook take a hour. When we compile "only" gui parts on X1000 natively (8% of whole code), it take as much as it takes to build whole webkit (remain 92% of code). So you can imagine no one want to spend 2 days on building a thing, which can be build for a hour (and even faster today), only for "we can build it native" reasons :)

Of course, that not mean we not need native development tools. Of course, we require them too and better to have them too. But if we should choose, then we have what we have and what developers find better, at least for now, in the current state of things.


You shouldn't think that is issue with OS4 only : same happens with any obscure OS (And not only PPC and Amiga based ones). Even for ZX Spectrum all the games, all the art, all the coding done on PC tools and cross-compiler tools, and then adapted/polished natively. That just the reality of obscure and unpopular OSes and hardware.

In other words, don't put OS4 where is not. In reality, it is an obscure OS with the developers-hackers and users who understand it issues, some of which, sadly, will never be fixed. And some will be even worse. If you can enjoy it as it, and accept — then there will be a fun for you. If you will “hope” for more and more and be it like you wanted it to be, or like you see it at first, then it will be just rage-quit, burn out, and all that stuff.

Another practice can be applied to all this amigaos stuff: once you feel you are start to be annoyed, disappointed by anything , just take a rest for a month, or two, or a year, and then back when you will have motivation : at least that how some of us did :)

@billyfish
Btw, MightyMax taken over GDB porting, and few days ago were dealt with breakpoint/tracing stuff (he develops on qemu with peg2 emulation). So at least after few years there are progress in :)

Hi all

Blimey it's been a while! I lost my dev set up on my old computer but I can take a look at rebuilding it again.

So my memory is like a sieve but I'm pretty sure that I had the option to build it so that it would use the amissl shared libraries rather than statically linking to openssl. The main issue was that at some point libgit2 moved over to using mmap () and munmap () and we didn't have support for those at the time.

Over the weekend I'll see if I can get it all set up again and see what I can do.

cheers

billy

@Hans, yes, for me everything has been too big and it dies. It also lacks the options to be able to limit the size of the checkout. I found the source but it fails miserably to build just like a lot of other stuff. I even tried to create a smaller project by not including a whole section of the project and the checkout worked, then it failed because there’s a symlink in the repo and it died on that. At that point I gave up. Too many concessions having to be made to bother.

@kerravonQuote:

Generally that wouldn't be considered hosted as the OS would need to interface with any firmware. Unless there was a boot loader in between. But even then that usually acts as a middle man.

Quote:

I wouldn't say that's cheating. I would interpret hosted as running on a full OS and usually loaded by hand. But unless you have driver sources for all drivers you need you cannot be expected to fully take over the hardware.

Modern UEFI is similar to Amiga ROM2.0+. With mouse and GUI. But in many ways surpassed a basic early startup menu.

You can make use of WinUAE or any UAE to emulate an Amiga so you don't need a physical machine all the time.

I can see what you mean by duplicating unnecessary work. A few years back I wrote a Linux chain loader for the newer AmigaOS4 machines that use a boot loader (called AmigaBoot) for menu between firmware and AmigaOS. Now I could have written a full boot loader that also presented submenus to chose from. But I would have need to write a ton more code and handle file loading myself as well the user needing to manually add it to the firmware menu as an option. I decided to make use of the existing menu loader, adding menu entries with a dedicated boot partition, and letting the boot loader load all the files in for me. I just needed to iterate through a list of files and it gave me freedom to support other compression formats.

Quote:

Ok so $4 is also known as ABSEXECBASE. It's the only consistent address in the whole Amiga OS. What I don't know iss why the OS just didn't pass it in a register and avoid using a 68000 vector. But the OS does use it on reboot. So you just need to read the pointer at $4 and store it as ExecBase.

For arguments A0/D0 can be saved as well. But keep in mind it's just a string. Address and length. The C lib would read it and split it into an array of arg vectors. I've written ASM macros in the past that did this.

You could also access it from the process CLI structure. That would avoid relying on registers. But again it's just a string that needs splitting. Unlike what I read about /proc/pid/cmdline containing null bytes. That looked like a bad idea when I read it at first. Using a null terminator as delimiter in a string.

Quote:

Do you need an alternative to ExecBase? Any program can read it from $4 (or 0x4) any time it likes. An alternative implies you are replacing it and I don't think you intend to rewrite an existing core kernel. You could save it or stack but it's always the same. Good idea to cache it as $4 is in chip RAM and incurs a slight penalty.

So, AmigaOS or the AmigaDOS startup code doesn't stack anything for you. The AmigaOS ABI doesn't work that way. All OS functions take parameters in registers. In this respect it's somewhat like a RISC ABI. The 68000 provides 8 data and almost 8 address registers for use. The OS uses them. The only main exception is Intuition hooks where message data for lists is pushed to stack. And some other esoteric functions. Plus most C compilers would use stack based calling conventions.

Quote:

Okay I can understand that. Well, the kernel is there to provide all that, so you might as well use it. So you have two basic ways about it. You could create a boot disk that has boot code to boot strap PDOS. That allows you to take over instantly. But also be able to use OS to read in disk blocks. From your own file system. Of course, though nice for testing, not very practical relying on floppy.

The other way is for PDOS to be a shell. It simply runs as a command on startup and can take over that way. Cover disk menus also did this. The user can exit back DOS. Or run it independently. This would make use of Amiga filesystem and could be installed to a bootable partition at will. Either way this would be hosted but making use of core OS components. It is called PDOS and in this case AmigaPDOS so obviously a DOS interface and not entire OS replacement. It can customise a console to run inside a PDOS window.

So drivers. This would be the easy bit. Device drivers for most hardware are added by the OS from the Zorro card ROMs. Plug and play so to speak. You just need to know the device driver name. There is Exec name and DOS name. Reverse name look ups from DOS name to Exec name are convoluted for some reason. Unless you need to write directly to disk blocks you don't need it. DOS is enough to read files from and SYS: is always assigned as boot volume. The only concern is 68040 and up need CPU libraries or it can crash.

At this point, since you are still working on it, is how a PDOS binary will interface with PDOS. You could provide a PDOS library that all PDOS binaries open on startup. Standard Amiga binaries could be tested that way. But, the intention is for ELF binaries, so obviously this needs to executed by a PDOS shell. In that case you have full control over how PDOS passes itself. You will need an ELF loader as well. And I imagine a pass through for standard hunk binaries if that is supported. The user may be confused if running an Amiga binary doesn't work. But same user would be aware they are running in PDOS.