|
|
Re: developing amiga 68000 clone
|
Posted on: Yesterday 18:21
#21
|
Just popping in
|
@HypexQuote: Hypex wrote:@kerravon Are you using the Amiga and Exec as an m68k base standard?
I'm not 100% sure I understand the question - but if I am, the answer is "yes" - I am not interested in the Atari or Mac - I'm only interested in the Amiga - but I want to be able to run my Amiga software on those other platforms (Mac, Atari, Linux) - if that's all I have access to. Furthermore - I'm mainly interested in Linux being installed on the Mac/Atari hardware, such that the only thing I need to do is make sure that my "mini Amiga clone" runs under Linux 68000, with Linux being treated as a glorified BIOS. However, I'm not against having a native Atari/Mac version of my Amiga emulator. It's not a lot of work to support a new platform (in PDPCLIB), but it's not a priority. Quote: Kinda like how Mac became the PowerPC de facto standard for PowerPC? With OpenFirmware.
I'm not familiar with that and I don't understand that. Quote: That's one way about it. I thought that may make it hard though. You have to take every Exec function and then DOS as it happens I expect and write an Amiga Exec wrapper to Atari, or Mac, or any other 68K platform.
Or am I misunderstanding here?
I'm not sure if you're misunderstanding because I'm not quite understanding the question. So let me just restate how things work. First - I'm only interested in a very select number of Amiga functions: [kerravon@paul-pinebook pdpclib]$ grep -i globl amisupa.asm | grep -v _ .globl Read .globl Write .globl Input .globl Output .globl AllocMem .globl FreeMem .globl Open .globl Close .globl Seek .globl DateStamp .globl DeleteFile .globl Rename [kerravon@paul-pinebook pdpclib]$ That's all I need in order to get basically any C90 program (that I have source code to) to run on an Amiga (real or my mini-clone). So e.g. I need to provide my own Write function (since I am AmigaDOS now), and here it is: .globl _Write _Write: link a6, #0 movem.l d1/d2/d3, -(sp) jsr _c_Write lea 12(sp), sp unlk a6 rts int c_Write(void *handle, void *buf, int len) { int rc; rc = fwrite(buf, 1, len, handle); return (rc); } So you can see that an Amiga C program (which would normally use fwrite()) calls Write() and then my mini-clone (it's not really an emulator I think), simply turns around and calls fwrite again. But this fwrite is on Linux (could be another platform - could even be a real Amiga - e.g. if you wanted it to operate on FAT32 emulated disks), and this fwrite is simply another flavor of PDPCLIB for the 68000 (currently I have the Amiga and Linux implemented in the PDPCLIB C library - but there is no restriction on adding others and it's not a lot of work). So basically fwrite for a (perfectly valid, conforming) Amiga program turns around and calls fwrite on the host platform - normally Linux 68000 - and normally that itself is indeed done via CPU emulation (qemu-m68k - not qemu-system-m68k - it would take more work to make the latter work). Quote: I thought arg[0] was usually the binary filename?
Yes, but I don't know how to retrieve that on an Amiga, so my Amiga executables in the startup code just set it to "UNKNOWN" - only the bit after the executable is passed in d0/a0 I believe. There may be a way of retrieving that information, but it hasn't been priority to find out how, and then implement that. I was more interested in proving concepts than making the world's best product. My interest is in create a public domain base - from which freeware or commercial products can be based on. And proving what is technically possible. I may choose to flesh out a public domain and/or a commercial derivative personally, but I'm setting things up so that at least nominally I am only one actor. And doing either isn't really a priority at the moment - I'm expecting to switch back to ARM32 and work on PdAndro again now.
|
|
|
|
Re: developing amiga 68000 clone
|
Posted on: Yesterday 17:24
#22
|
Not too shy to talk
|
@kerravon Quote: No, I can't do that, because absolute address 4 may not be available for me to use on an Atari etc etc. Well, no it wouldn't, because Atari uses TOS. Quote: When run on Atari, or Linux, I am "rewriting core kernel" - there is no alternative - the Amiga doesn't exist at all. Are you using the Amiga and Exec as an m68k base standard? Kinda like how Mac became the PowerPC de facto standard for PowerPC? With OpenFirmware. That's one way about it. I thought that may make it hard though. You have to take every Exec function and then DOS as it happens I expect and write an Amiga Exec wrapper to Atari, or Mac, or any other 68K platform. Or am I misunderstanding here? Quote: Anyway, here is the current state: I thought arg[0] was usually the binary filename? 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. For a function like printf() stack makes sense. Since it can have variable arguments. And C like to stack! Indeed, when I compiled from C to ASM by hand, even though I was rewriting it myself in ASM I did it the "proper" C way and stacked all the function parameters. Quote: If there was a reason to there could be an alternate interface, but that's what I use on all environments (e.g. 80386). For x86 it makes sense since it's pretty much a stack based architecture. The base 68000 has more GPRs to play with but x86 did catch up. If your code is mainly C this makes sense. Since C likes to use stack in its ABI.
|
|
|
|
Re: MPlayer 1.5 released!
|
Posted on: Yesterday 17:24
#23
|
Not too shy to talk
|
@smarkusg
Hi,
Figured I should follow up on the sporadic issue of static YT streams ending a few seconds (5-15secs) before their proper ends....
I tried a bunch of different combinations of the suggested forceidx, cache-min & cache arguments in the config file, tried repeatedly playing the same streams over and over until YT seemed to lock me out (for the day).
Unfortunately, I still kept getting the sporadic early endings.
It's not the end of the world by any whatsoever means... All in all MPlayer has otherwise been working great.
Thanks for the efforts in any case!
PJS
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: Yesterday 17:02
#24
|
Not too shy to talk
|
@MamePPCA1 Might be easier to just use a Workbench program. Do you have Ranger on the pendrive? If not download here and you can copy it across to you X5000 over another USB stick as one option. Then run Ranger and look for the Kickstart modules tab. See if SmartFilesytem is listed as Kickstart module. Or just look in pendrive Kickstart drawer. http://os4depot.net/?function=showfil ... e=utility/misc/ranger.lha
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: Yesterday 16:56
#25
|
Not too shy to talk
|
@smf Quote: The format has not changed, it's just that the "old" sfs does not support new machines like tabor and X5000 so for you it will be safe. Ah, I see. Another one of those version checks in any software with Joerg written on it. Now this is the X5000 inside information that's needed here. Quote: But it's sure a little bit complicated for X5000 customers atm as they need to know how to prepare their own emergency boot pendrive if they want to run a better filesystem than what was offered when the latest os4.1 iso was shipped in case they run into problems. That would go for everyone. To my knowledge this was a dealer setup recovery drive so easier for the user. Unfortunately not fully tested it seems to actually be useful as a recovery tool. But at least X5000 users can boot off USB. Even if there is not yet a program to build a recovery volume like in OS3.9. On my X1000 there's no USB boot support at current. Quote: A-eon has created a great emergency boot iso for the tabor, they should do it for the X5000 too. I expect in due course it will be. So an ISO image that can be burnt to CDR or USB?
|
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: Yesterday 16:47
#26
|
Just can't stay away
|
@kas1e Quote: PS. Also, did i understand it correctly, that they (os4 devs) tried to get rid of Varargs functions mostly from API ? Why i ask about, is that they say there https://wiki.amigaos.net/wiki/Linker_Libraries , that:
Intuition
CallHook() and CallHookA()
These functions invoke hooks. CallHook() expects a parameter packet ("message") on the stack, while CallHookA() takes a pointer to the message.
Replaced by IUtility->CallHookPkt() in V50.
Like, both were deprecated in favor of single CallHookPkt() , so to not have varargs function. Even if they have CallHook() still in utility.library (probably side effect of easy porting from os3 back in times), it all looks like that they want to get rid of Varargs one. Maybe because Varargs ones is potetialy not safe-ones, as can corrupt the stack in some conditions , etc, and that is the reassons they want non-varargs one to be used always ? It's most likely not related to varargs at all, but that only utility.library CallHookPkt() includes the required check and different way to execute the Hook function depending on if it's emulated m68k code or PPC native code. The same could have been added in the amiga.lib/libamiga.a hook functions, instead of removing them, but why? It would have been duplicated code, and statically linked code is always bad if you have the same functions in a shared library where bugs can be fixed or new features added without having to recompile all software using it as it's the case for static link libraries such as libamiga.a or the clib2 libc.a. I don't know if there were usable OS3 utility.library sources which could have been used for the OS4 implementation, but I guess it was the same as with exec (and several other OS3 sources): Useless m68k assembler code reimplemented from scratch for OS4.
|
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: Yesterday 12:29
#27
|
Home away from home
|
@joerg Quote: The reason for CallHookA() in amiga.lib can only be AmigaOS 1.x compatibility, as written in the NOTES of the autodoc.
Very strange.. If that of course were true that AmigaOS1.x have no single hooks usage not internally not externally (just for a little time , for 6 months, of internal coding).. From another side, maybe at this time, when assembler were too popular in amiga coding, they think that if one use amiga.lib , and it's vararg based CallHook(), then, if developers want non vararg based, then he should't have the needs to open utility.library (some additional code), and use CallHookPkt(), while, he can just use CallHookA() from amiga.lib at the same time. But then, it didn't explain why then utility.library have only CallHookPkt() and didn't have CallHook_varargs() or similiar to amiga.lib's CallHook() or something so to fill the logic gap :) But maybe i were falsely informed, and utility.library wasn't the only and single one using hooks internaly and there were released with them for public, before CallHookA() and CallHook() were implemented in amiga.lib I was told that it was like this: Alpha 5 of AmigaOS 2.0 (known as AmigaOS 1.4) in 8 June 1989 introduce iHook and CHook(). And 1.4 it is V35 (not V34). So the first (and even named different) hooking functionality were added to intuition. How it is possible that in amiga.lib autodic, they wrote about support of "v34"... Like this is all wrong about first introduce of iHook and CHook() ? Then, i was told that right after 6 months, after Alpha 5, in the Beta 1 of AmigaOS 2.0 in Kickstart 36.8 introduce CallHookPkt() , in 22 December 1989. Then in amiga.lib with Kickstart v37 they introduce CallHook() and CallHookA(). But what data exactly, what exactly subversionof kickstart : dunno. There seems some bug in the dates then, if amiga.lib told that "all should work with V34" , which is amigaos 1.3 , and not 1.4 where first hooks were introduced (seems not, then?) PS. Also, did i understand it correctly, that they (os4 devs) tried to get rid of Varargs functions mostly from API ? Why i ask about, is that they say there https://wiki.amigaos.net/wiki/Linker_Libraries , that:
Intuition
CallHook() and CallHookA()
These functions invoke hooks. CallHook() expects a parameter packet ("message") on the stack, while CallHookA() takes a pointer to the message.
Replaced by IUtility->CallHookPkt() in V50.
Like, both were deprecated in favor of single CallHookPkt() , so to not have varargs function. Even if they have CallHook() still in utility.library (probably side effect of easy porting from os3 back in times), it all looks like that they want to get rid of Varargs one. Maybe because Varargs ones is potetialy not safe-ones, as can corrupt the stack in some conditions , etc, and that is the reassons they want non-varargs one to be used always ?
Edited by kas1e on 2024/5/19 12:51:18
|
|
|
|
SPEED TEST: Simons' BASIC vs. C128 BASIC vs. Vision BASIC
|
Posted on: Yesterday 3:37
#28
|
Just popping in
|
Retro Old Guy has released a new video comparing Simons' BASIC with C128 BASIC and Vision BASIC:
https://www.youtube.com/watch?v=WJiK-EI7ed0
There's a mismatch clearance sale over at the Vision BASIC website, where they're practically giving away a few copies of the product:
https://visionbasic.net/purchase/
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 5/18 22:21
#29
|
Just popping in
|
@MamePPCA1
if version can't find smartfilesystem then it's not loaded into memory when the kickstart is loaded so you have to fix that
|
|
|
|
Re: SoDIMM DDR3 testing on A1222
|
Posted on: 5/18 18:10
#30
|
Just can't stay away
|
@Maijestro Quote: Can AmigaOs4.1 access 4/8 GB of memory at all or is the maximum usage 2GB? For 99% of the software on AmigaOS 4.1 the limit is still 2 GB, using more requires adding support for the "ExtMem" feature in the software. For example the "RAM Disk:" handler supports it, i.e. for files you copy to RAM: it doesn't use the first 2 GB, which all software can access, but can use the upper 2 GB instead software not supporting ExtMem can't use. Special note for your QEmu setup: ExtMem isn't supported in the Pegasos 2 kernels, no matter if real or emulated hardware. I don't know why, but probably differences to U-Boot or bugs in the hardware/DIMM setup of the Pegagsos 2 SmartFirmare for more than 2 GB RAM. More than 4 GB is theoretically possible even on the old systems (G2, G3 and G4 CPUs support 36 bit physical address space, i.e. 64 GB RAM), but none of the 32 bit hardware (classic Amiga with Blizzard/CyberStormPPC, AmigaOne, Pegasso2) supports it. On the 4x0 CPUs it's IIRC 41 bit, 2 TB = 2048 GB RAM, but I doubt the Sam440/460 supports more than 4 GB. Only the systems with 64 bit CPUs, X1000, X5000 and A1222, may support more than 4 GB.
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 5/18 18:00
#31
|
Quite a regular
|
@K-L
Yeah,yeah But I make with keyboard the commands and nothing happensa except one error as shown on recent posts by smf user and I.
|
Amiga 500 1MB Chip RAM with ACA 500+ACA1232,CD32,Amiga 1300 030/50 Mhz,32MB (now on my hands at least)and Amiga One G3 XE PPC 800 Mhz,ATI Radeon 9250 128 MB,256 MB RAM,Seagate 200 GB HD,2 working DVD drives,X-Arcade double for MAME,Sil0680,4 USB ports,LG
|
|
|
Re: Tracing of callhookpkt()/callhook()
|
Posted on: 5/18 17:46
#32
|
Just can't stay away
|
@kas1e Quote: I mean, it didn't looks like for support OS1.x From amiga_lib.doc.txt CallHook() and CallHookA()
NOTES
This function first appeared in the V37 release of amiga.lib.
However, it does not depend on any particular version of the OS,
and works fine even in V34.
Quote: 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 ? amiga.lib CallHook() is a varargs function using the stack (on m68k) for the message, utility.library CallHookPkt() uses registers with a pointer to the message, similar to TagItem functions (always two versions, one with a pointer to a TagItem array in a register, one using varargs on the stack instead). However, that doesn't explain why amiga.lib has CallHookA() as well, which is identical to utility.library CallHookPkt() (except for maybe utility.library using 3 registers for the arguments, amiga.lib using 3 arguments on the stack instead, not sure). The reason for CallHookA() in amiga.lib can only be AmigaOS 1.x compatibility, as written in the NOTES of the autodoc.
|
|
|
|
Re: A1222+ and Enhancer 2.2 Question
|
Posted on: 5/18 17:25
#33
|
Just popping in
|
I have exactly the same problem with my 1222 I reported this to my seller and to amisphere for several weeks but 0 responses...
|
|
|
|
Re: sam460: new uboot update to handle RadeonRX coming soon!
|
Posted on: 5/18 16:43
#34
|
Just popping in
|
The update is now available at the ACube Systems online shop.
|
|
|
|
Re: SoDIMM DDR3 testing on A1222
|
Posted on: 5/18 15:48
#35
|
Quite a regular
|
@dooz @sailor Great, thanks for the test and the information. I had asked about this before but it wasn't answered. https://www.amigans.net/modules/newbb/ ... id=148528#forumpost148528It seems that a 4GB SoDIMM with 1333Mhz would be a good choice. Can AmigaOs4.1 access 4/8 GB of memory at all or is the maximum usage 2GB?
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
|
|
|
Re: SoDIMM DDR3 testing on A1222
|
Posted on: 5/18 15:22
#36
|
Not too shy to talk
|
Quote: dooz wrote:I tested several kinds of DDR3 in A1222. I tested two kind of 1333 MHz and one 1066 MHz. All worked ok.
I *didnt tested* 1600 MHz because the ones I have are *DDR3L* declared as 1.35V. DDR3 is usually 1.5V. Both are pin compatible but I simply didnt want to test that to avoid possible problems or to damaged board. Cant find any info that A1222 is compatible with DDR3L - maybe someone else can confirm?
Also other test results and compatibility reports from other A1222s out there are also usefull. DDR3 SoDIMM can be found in old PC laptops.
-dooz Thanks for testing. You can use DDR3L memory on DDR3 slot. But DDR3 memory in DDR3L motherboard not works. DDR3L memory stick are dual voltage. Dell article.I tested Kingston 8GB DDRL KF318LS11IB/8 and it works fine, results are similar like your 4GB module:
Function Best Rate MB/s Avg time Min time Max time
Copy: 787.1 0.204503 0.203269 0.208423
Scale: 492.9 0.326322 0.324588 0.329637
Add: 568.0 0.424966 0.422508 0.427871
Triad: 541.6 0.445014 0.443115 0.449225
|
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
|
|
|
Re: A1222+ and Enhancer 2.2 Question
|
Posted on: 5/18 15:13
#37
|
Just popping in
|
The licence code I received for my A1222 only seems to have Personal Paint and ImageFX Studio show up as purchased items on the Updater tool. They don't appear on AmiStore as items I own.
I haven't purchased the Enhancer software in the past.
Kind regards,
Francis
|
|
|
|
Re: developing amiga 68000 clone
|
Posted on: 5/18 12:44
#38
|
Just popping in
|
@kerravonQuote: 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.
It took the whole day but it is now working, source and executables are published already.
|
|
|
|
SoDIMM DDR3 testing on A1222
|
Posted on: 5/18 11:03
#39
|
Just popping in
|
I tested several kinds of DDR3 in A1222. I also done also speed test to see if there is some diference. I was suprised that one module gives better performance. Test was done with SPE compiled STREAM benchmark that is on Aminet/OS4depot (stream-5.10-AOS).
I tested two kind of 1333 MHz and one 1066 MHz. All worked ok.
GoldenMars GMB20028SOX829-1333 MHz 2GB DDR3: Function Best Rate MB/s Avg time Min time Max time Copy: 853.5 0.190645 0.187454 0.205199 Scale: 530.4 0.314437 0.301685 0.333246 Add: 608.5 0.406054 0.394389 0.417909 Triad: 579.4 0.423509 0.414206 0.437765
KINGMAX FSFF65F-D6KQ9 BEE 1333 MHz 4 GB DDR3: Function Best Rate MB/s Avg time Min time Max time Copy: 787.8 0.208007 0.203093 0.217850 Scale: 479.9 0.340636 0.333376 0.346968 Add: 568.6 0.430306 0.422055 0.441371 Triad: 550.5 0.449238 0.435952 0.468612
KINGSTOM KVR1066D3S7/1G 1066 MHz 1 GB DDR3: Function Best Rate MB/s Avg time Min time Max time Copy: 859.0 0.189459 0.186271 0.195421 Scale: 557.1 0.296775 0.287192 0.304756 Add: 635.8 0.386305 0.377477 0.397208 Triad: 598.6 0.406753 0.400919 0.418826
So not every DDR3 gives the same speed on A1222. All DDR3 I tested are 1.5V.
I *didnt tested* 1600 MHz because the ones I have are *DDR3L* declared as 1.35V. DDR3 is usually 1.5V. Both are pin compatible but I simply didnt want to test that to avoid possible problems or to damaged board. Cant find any info that A1222 is compatible with DDR3L - maybe someone else can confirm?
Also other test results and compatibility reports from other A1222s out there are also usefull. DDR3 SoDIMM can be found in old PC laptops.
-dooz
Edited by dooz on 2024/5/18 12:51:16
|
|
|
|
Re: updating sgit
|
Posted on: 5/18 10:48
#40
|
Not too shy to talk
|
@MartinW
Now I see on your video , you build from makefiles.aos4*. I didn't do it that way. I did with cmake directly. build libgit2 in the first place you have the declarations in makefile.aos4 then build simplegit
|
|
|
|