@Lou

Quote:

Of course Chunky to Planar or reverse conversion is always needed under the hood. For example to display AMIGA PLANAR ICONS on an RTG Workbench

notice the part about "reverse", not C2P, what says is useful is P2C and I agree.

Converting slowness to fastness is better, then converting everything to slowness.



Naturally, you have to convert things to and from, but you can maybe get away with converting the icons into more optimal format and store it on disk, you easily have icons in two different formats, and you wont need the real time conversion. yes take more disk space, but who notice.

And as for games like doom it was made for Chunky, so way display it on a Planar screen?

Last edited by NutsAboutAmiga on 18-Jun-2021 at 05:29 PM.
Last edited by NutsAboutAmiga on 18-Jun-2021 at 05:26 PM.
Last edited by NutsAboutAmiga on 18-Jun-2021 at 05:13 PM.
Last edited by NutsAboutAmiga on 18-Jun-2021 at 05:09 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Lou Quote: Of course Chunky to Planar or reverse conversion is always needed under the hood. For example to display AMIGA PLANAR ICONS on an RTG Workbench notice the part about "reverse", not C2P, what says is useful is P2C and I agree. Converting slowness to fastness is better, then converting everything to slowness. Naturally, you have convert things one and the other way, but you can maybe get away with converting the icons into more optimal format, you easily have icons in two different formats, and you wont need the real time conversion. yes take more disk space, but who notice.

It's called 'C2P' but if you pass it chunky data, it becomes planar. All it's doing is reorganizing the input bits.

@Lou

C2P = Chunky To Planar.

Reverse the letters, and you get.

P2C = Planar to Chunky.

Quote:

All it's doing is reorganizing the input bits.

Akiko might reorganizing input bits, and do what you ask it to do, I agree.

Last edited by NutsAboutAmiga on 18-Jun-2021 at 05:32 PM.
Last edited by NutsAboutAmiga on 18-Jun-2021 at 05:32 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Lou C2P = Chunky To Planar. Reverse the letters, and you get. P2C = Planar to Chunky. Quote: All it's doing is reorganizing the input bits. Akiko might reorganizing input bits, and do what you ask it to do, I agree.

I know what the acronyms represent. The chip itself doesn't care. It's an input stream that just gets rewired to the output...that's why it does it so fast. It doesn't care if you pass it chunky or planar data.

If you pass it one set of data and then take that output and pass it back in, you are left with the original input data. So C2P or P2C ... it doesn't care. You could call it more accurately: PCI ... aka Planar/Chunky Interchange. Who cares?

Watch this video from the 42 minute mark on:
https://www.youtube.com/watch?v=eOJ7XVQlnB8

Last edited by Lou on 18-Jun-2021 at 05:57 PM.

@Lou

Offload work to another chip is good idea, unless it takes more time than doing it on the CPU, naturally combine power is more than one or the other, but if amount of data is more than you can handle with Akiko, then only option becomes the CPU, unless you divide the image, schedule just right amount to slower chip, but this be bad, if the chip is improved and you feed it less data then it handles, a good routine need to benchmark and optimize for the hardware you have, the chance is that everyone write there one software routines, and in some cases they writhe code optimized for Vampire/Akiko, or write software optimized for CD32/Akiko, but is unable handle but cases.

It’s like most (or all) demos on Amiga are programed for 320x200 mode, 640x200, or 640x480 modes, they won’t upscale to better screen mode, or adapt to different aspect ratios. They are hardcoded to one screen mode, nothing changes that. Unless developer who wrote updates it. but if he is not around, or don’t care, then nothing happens. In that case the better hardware is useless.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Lou Offload work to another chip is good idea, unless it takes more time than doing it on the CPU, naturally combine power is more than one or the other, but if amount of data is more than you can handle with Akiko, then only option becomes the CPU, unless you divide the image, schedule just right amount to slower chip, but this be bad, if the chip is improved and you feed it less data then it handles, a good routine need to benchmark and optimize for the hardware you have, the chance is that everyone write there one software routines, and in some cases they writhe code optimized for Vampire/Akiko, or write software optimized for CD32/Akiko, but is unable handle but cases. It’s like most (or all) demos on Amiga are programed for 320x200 mode, 640x200, or 640x480 modes, they won’t upscale to better screen mode, or adapt to different aspect ratios. They are hardcoded to one screen mode, nothing changes that. Unless developer who wrote updates it. but if he is not around, or don’t care, then nothing happens. In that case the better hardware is useless.

If you read Gunnar's comments before and after implementing AKIKO...
He dogged it because a faster cpu could do it faster taking into account the setup from the cpu ... then forgot to take into account how much faster his memory bus is which again gave the advantage back to the AKIKO...

My whole complaint about the mythical SAGA 'chipset' is that it's not a chipset at all. That's why I mentioned enhancing the actual Amiga chipset which is what the name -SAGA - would lead you to believe is actually happening. We all now know it's just the other thread of the '080 doing cpu blitting and cpu audio...

Since CD-1200 was going to be an actual product and contained an AKIKO chip in it (AKIKO is also the IDE driver) that plugged into the A1200 trap door... Kudos to him for finally realizing it's true Amiga legacy...but he is still a ... ... needs to learn some manners and humility.

It's also why I am looking forward to the Buffee, because it's embedded ARM SOC does have a gpu within it....so someday the designer may be able to exploit it.

Last edited by Lou on 18-Jun-2021 at 08:55 PM.
Last edited by Lou on 18-Jun-2021 at 08:50 PM.
Last edited by Lou on 18-Jun-2021 at 08:47 PM.

Lou Quote:

If you read Gunnar's comments before and after implementing AKIKO... He dogged it because a faster cpu could do it faster taking into account the setup from the cpu ... then forgot to take into account how much faster his memory bus is which again gave the advantage back to the AKIKO...

The Akiko C2P hardware support was a minor addition as chunky is supported and the CPU cores are fast enough to handle C2P (the SIMD unit has a C2P instruction). It was good to add Akiko support as it improves CD32 compatibility and pulls the CIA chips into SAGA in a standard way. The C2P hardware is very simple (cheap) and it looks like it is flexible enough to do P2C as well. Modern consoles have a big SoC with crazy amounts of custom logic to not only offload the CPU cores but also reduce the power use.

Lou Quote:

My whole complaint about the mythical SAGA 'chipset' is that it's not a chipset at all. That's why I mentioned enhancing the actual Amiga chipset which is what the name -SAGA - would lead you to believe is actually happening. We all now know it's just the other thread of the '080 doing cpu blitting and cpu audio...

I do *not* believe what you say about SAGA is true and it is repeated false statements like this that likely resulted in your ban from the Apollo forum. I believe SAGA uses a CPU core thread to emulate the Blitter but that is only one part of SAGA and one of two coprocessors which execute code. I don't think the Apollo core is fast enough to emulate the Copper. There is a significant amount of logic which does not qualify as a coprocessor such as the Akiko C2P conversion logic.

The Blitter could be implemented in hardware and it would be much faster but it may be too fast. Programs which forgot WaitBlit() may be more obvious reducing compatibility. It should be possible to reduce the default clock of the Blitter and speed it up on setup for new programs but most newer programs are going to use SAGA chunky (the Blitter is primarily for planar gfx). The setup time of a modernized Blitter is likely to take longer than the processing time. Chunky gfx processing can be done in an SIMD unit without as much setup overhead as the Blitter. A CPU thread for the Blitter uses what would otherwise be wasted wait times (bubbles) in the CPU core pipeline. What do you hope to achieve with a hardware Blitter?

Lou Quote:

Since CD-1200 was going to be an actual product and contained an AKIKO chip in it (AKIKO is also the IDE driver) that plugged into the A1200 trap door... Kudos to him for finally realizing it's true Amiga legacy...but he is still a ... ... needs to learn some manners and humility.

Akiko accessed through the Zorro bus was not the best design for the CD-1200. Chunky should have already been supported in AGA and the CIAs should have been integrated for AGA. CBM was always too little too late and never had a clear upgrade path for the Amiga.

Lou Quote:

It's also why I am looking forward to the Buffee, because it's embedded ARM SOC does have a gpu within it....so someday the designer may be able to exploit it.

Buffee is another cool hack but not the way to develop the 68k Amiga.

Last edited by matthey on 18-Jun-2021 at 10:49 PM.
Last edited by matthey on 18-Jun-2021 at 10:46 PM.

@matthey

Quote:

Akiko accessed through the Zorro bus was not the best design for the CD-1200. Chunky should have already been supported in AGA and the CIAs should have been integrated for AGA. CBM was always too little too late and never had a clear upgrade path for the Amiga.

The CD1200 looked cool but it was impractical and used up the accelerator port rather than using the PCMCIA slot like the Squirrel etc.

The Amiga was just a McGuffin for Commodore management rather than a platform with generations like it should have been. In fact plans were already afoot with Hombre to kill the Amiga compatibility so they were obviously sure a Commodore McGuffin had inherent value! Guess what? It didn’t! The Amiga was special but Commodore sucked with no profits back into R&D. Once the McGuffin’s specs were outdated they needed another McGuffin but they’d sacked all engineering staff and had no money to buy another startup so in many ways they went out on a high with the CD32 and A4000T.

Last edited by BigD on 19-Jun-2021 at 12:11 AM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

BigD Quote:

The CD1200 looked cool but it was impractical and used up the accelerator port rather than using the PCMCIA slot like the Squirrel etc.

There was a 68030 socket and SIMM socket in the CD1200 at least. The way it was all put together was not well integrated. The Amiga 1200 could have been designed with a slim drive bay for a CD-ROM and AGA could have supported chunky so that adding a CD-ROM drive and CD32 compatibility was not such an after thought.

BigD Quote:

The Amiga was just a McGuffin for Commodore management rather than a platform with generations like it should have been. In fact plans were already afoot with Hombre to kill the Amiga compatibility so they were obviously sure a Commodore McGuffin had inherent value! Guess what? It didn’t! The Amiga was special but Commodore sucked with no profits back into R&D. Once the McGuffin’s specs were outdated they needed another McGuffin but they’d sacked all engineering staff and had no money to buy another startup so in many ways they went out on a high with the CD32 and A4000T.

Hombre was planned as both a gfx card which could be used for an Amiga and as a standalone game machine which would not have been compatible with the Amiga. There was plans to license the 68k from Motorola for a SoC so the 68k Amiga wasn't quite dead. RISC looked like the future when first introduced as the simpler designs allowed to clock up the processors but higher clock speeds used more power than expected and the inferior code density created an instruction fetch bottleneck and wasted caches and memory. Once CISC had pipelining, single cycle instructions and superscalar processing, the demise of CISC was uncertain although RISC designs have been favored because they are cheaper to design even though most have had disappointing performance. PA-RISC cores as used in Hombre were no exception. The 68060 likely outperformed a PA-RISC core in integer performance at the same die size and the SIMD unit of PA-RISC, which was one of the earliest, was likely needed to outperform the 68060 in multimedia processing and then not by much.

http://eab.abime.net/showpost.php?s=30256e7fd3022c6a5c4667aabd77724f&p=1142968&postcount=22

Last edited by matthey on 20-Jun-2021 at 03:59 AM.

@matthey

Quote:

matthey wrote: ... I do *not* believe what you say about SAGA is true ... ...

you are under no obligation to believe it but this was confirmed in other posts on that forum

Gunnar wants to build the 'ultimate' cpu. I called it hubris, just like the CELL processor. Even Sony realized they needed a dedicated gpu... So all my thoughts were - why not actually enhance the chipset ... but that's not what they did.

Didn't take long after that. The official reason was I called sferrels a duncecap. #zero_effs_given

Like I said - once it came out that the SAGA 'chipset' was just the cpu-thread that AmigaOS knows nothing about running code ... the magic was gone...

Quote:

Buffee is another cool hack but not the way to develop the 68k Amiga.

funny, the same many have said about apollo-core...
it's not even using the fastest ARM soc...and since it's software-based, it could offer all the same features of cpus up to and beyond the 68060 eventually...

Last edited by Lou on 19-Jun-2021 at 03:52 PM.
Last edited by Lou on 19-Jun-2021 at 03:43 PM.
Last edited by Lou on 19-Jun-2021 at 03:42 PM.
Last edited by Lou on 19-Jun-2021 at 03:27 PM.

Lou Quote:

you are under no obligation to believe it but this was confirmed in other posts on that forum

Did you understand the posts correctly? Do you believe other FPGA hardware uses Amiga custom chipsets in FPGA? Have you looked at the VHDL source code of any of these other Amiga custom chipsets (there are at least three AGA compatible chipsets)? Where did this conspiracy theory come from?

SAGA was originally written in AHDL for the Natami project (likely converted to VHDL later). It is the logic of enhanced Amiga custom chips so far implemented in an FPGA. An old 68k CPU or FPGA 68k CPU core may not have enough performance to emulate the Amiga chipset. Even early Raspberry Pis had trouble emulating the Amiga chipset without stuttering so how can a slower processor emulate it?

Thomas Hirsch Quote:

First true enhancement For the first time on the MX board it is getting exciting, even for me. Till now I was "only" adapting the LX design to the new board. OK, by doing that I made quite huge progress in stability and usability. The board can now even be operated stand-alone. But this were just all the many mandatory things needed for the completeness of the system itself. But now... I was able (and had the time) to improve, or rather extend ECS. As you (hopefully) know, OCS had a hard wired frame generator. Because of that there were two different Agnus chips, one for NTSC and one for PAL. With ECS this issue was resolved in a quite superior manner. They did not only implement a NTSC/PAL switch but also added a complete set set of frame generation registers. From that on there was no limitation to the screen size anymore. Even the A2024 resolutions (1024x1024) were possible. This was a lot more than a common PC could offer that time (in 1988). With the ECS frame generator it was even possible to display some VGA screen modes as 640x480. But there was still one limitation. The pixel clock was limited to fixed 28MHz. For the A2024 this was no problem, the refresh rate was set to 10Hz and the monitor itself had a built in frame buffer to display the image content at a much higher frequency. VGA and Multisync monitors had no internal memory. So this technique could not be used and resolutions that high as the A2024 were not possible to display on them. And even the 800x600 resolution needed to be in interlace because of the in comparison low pixel frequency. AGA did increase the color depth and the overall number of colors available, but left the pixel clock unchangeable. The pixel clock on the Natami is not generated by an external oscillator. It is synthesized by a programmable PLL (Phase Locked Loop). Its frequency can be changed at run time. I now implemented an interface which allows the PLL being accessed through DFF registers. With that I am able to set up a basic screen resolution of 1280x1024 in 60Hz for a functionality test. Not system friendly, just a part of a memory field and mouse pointer. But it actually works. I have known it from the beginning that it is possible and will work, but seeing that the Natami can now match the native resolution of my test TFT is something different! I`ll send a design update to Annika as soon as I can. And the second good news is that with the new resolution I was able to confirm that the digital portion of DVI is also working. Chipset Features (new) Frame generation .......... ECS and variable pixel clock -> UCS SyncZorro Interface ....... preliminary version Copper .................... fully implemented, with buffered data fetch Video DMA ................. fully implemented 256 color registers ....... fully implemented AGA HAM8 .................. fully implemented Sprites ................... 16bit linebuffer blitter ................... basic implementation. Block and fill mode only, line to come Video priority ............ half implemented Scandoubler ............... fully implemented Interrupts ................ fully implemented Paula DMA control ......... fully implemented Audio out ................. fully implemented Disk DMA .................. 880k and 1760k, read only Serial Port Paula UART .... fully implemented Slow peripheral I/O ....... fully implemented (Joy/Mouse/Keyb/PRT/DSK/SER) PC mouse and kbd support .. o CIAs ...................... fully implemented Board Features VGA out (DVI-A) ........... working (new) DVI out (DVI-D) ........... working PCI ....................... transfer only, arbiter and config missing IDE ....................... PIO mode 0 working Compact Flash connector ... o NEC USB PCI ............... o RTL 8110 LAN .............. o Battery-backed up clock.... working 15k Video out (module) .... o 15k Video in (module) ..... o Audio in .................. o

https://web.archive.org/web/20110530112338/http://www.natami.net/knowledge.php?b=1¬e=33366&x=14

This was the last entry of the Natami "MX Bringup Thread". Notice that the Blitter was *not* fully implemented at that time. As I recall, ThoR made a software patch to use the CPU instead of the Blitter but this was already being done on Amigas with faster CPU cores as CBM never upgraded the performance of the Blitter. Other parts of SAGA are fully implemented and practically necessary for a functional Amiga like the Natami MX.

Lou Quote:

Gunnar wants to build the 'ultimate' cpu. I called it hubris, just like the CELL processor. Even Sony realized they needed a dedicated gpu... So all my thoughts were - why not actually enhance the chipset ... but that's not what they did. Didn't take long after that. The official reason was I called sferrels a duncecap. #zero_effs_given Like I said - once it came out that the SAGA 'chipset' was just the cpu-thread that AmigaOS knows nothing about running code ... the magic was gone...

Once again I believe you are wrong about SAGA. I agree that Gunnar has *not* always been truthful and has been the source of exaggerations and propaganda but I believe Thomas Hirsch and ThoR to be honest and reliable. Gunnar is good at making enemies and some spread false rumors to make him look bad in retaliation. Gunnar spread false rumors that Meynaf and I tried to sabotage the Apollo project and that I was kicked out of the Apollo team which led to attacks on EAB and me getting banned (EAB moderators punished the victim which is not surprising). I could be a hater too and make false claims back but I am a more ethical person than him. I believe the truth remains that SAGA is as real as the N68k core (I have the VHDL source code) and the Apollo core and that they hold great potential. I believe there are developers in our Amiga community who are very valuable and if they worked together could create the next generation of Amiga, with or without Gunnar.

Lou Quote:

funny, the same many have said about apollo-core... it's not even using the fastest ARM soc...and since it's software-based, it could offer all the same features of cpus up to and beyond the 68060 eventually...

The Apollo core and N68k are developed how a CPU core is professionally developed. This is usually optimized for and made into an ASIC where Gunnar has optimized for an FPGA (including the ISA) and plans for the core to stay in FPGA forever. This is planning for failure in my opinion as the core is not competitive and unlikely to receive support in FPGA.

Buffee uses 68k emulation which is inefficient. A large portion of performance is lost, resources are wasted and energy is wasted in emulation. Buffee uses a decade old embedded TI SoC with relatively low performance ARM core because of the unique ability of the SoC to adapt to the memory bus of early Amigas. It is cheap but there is a limited upgrade path with no future. It is a nice hack from another talented developer who didn't get along with Gunnar.

Last edited by matthey on 19-Jun-2021 at 10:12 PM.
Last edited by matthey on 19-Jun-2021 at 09:54 PM.

@matthey

There is a reason the Natami died...and why it took so long to create the V1200 SA.
The Apollo team hadn't re-implemented the chipset. Also the Natami cpu back then was an '050 and '070. The Natami was Thomas' baby and Gunnar wanted it to be more than what Thomas wanted. Thomas is the one that re-implemented the chipset.

All a blitter is - is a memory mover. It's not that complicated. Re-iterates my point about why the stand-alone took so long. In many ways they had to start from scratch since Gunnar was all into the cpu... So none of this Natami talk is much applicable to Vampire.

Doesn't disprove anything I've said and as I've said - as much was admitted by a couple of developers.

Also, I am glad they implemented AKIKO. That was my ask. What irks me is the flack I got about it and then a year later AKIKO is a wonder chip that improves performance, simplifies the logic for CIAs, gives us a CDROM IDE driver ... like duh.

Let me simplify:
2018 Apollo Team: AKIKO is useless; ban users demanding AKIKO support
2020 Apollo Team: AKIKO is amazing

I'm sure there's a good MEME to go along with this somewhere.

Last edited by Lou on 20-Jun-2021 at 02:17 AM.

Lou Quote:

There is a reason the Natami died...and why it took so long to create the V1200 SA. The Apollo team hadn't re-implemented the chipset. Also the Natami cpu back then was an '050 and '070. The Natami was Thomas' baby and Gunnar wanted it to be more than what Thomas wanted. Thomas is the one that re-implemented the chipset.

Gunnar contacted me by e-mail and asked me to join the Apollo team on July 25, 2016. I was one of the earliest additions to the core three developers (Gunnar, Jens and Chris). The new team members were Philippe "Meynaf" Guichardon, Rune Strensland and me. The focus was purely on developing what was the N68070 core which was now renamed the Apollo core. The only hardware using the Apollo core at that time was generic FPGA boards and Natami boards (Gunnar owned one). I read Majsta's website about how he was struggling to get the TG68 core working in his accelerator design and suggested Gunnar help him to potentially form a partnership which worked out well. Chris also designed a sandwich board accelerator which was a custom board attached to a commodity FPGA board but it never made it into production. Majsta designed more powerful FPGA accelerator boards instead which were needed as his original board had too small of an FPGA for the full Apollo core. The new board would have a larger FPGA but the cost would go up significantly so I suggested adding RTG and perhaps AGA compatibility to improve value for this Amiga accelerator for ECS Amigas which later became the Vampire 500 accelerator. Gunnar contacted Thomas Hirsch and worked out a deal to use SAGA. SAGA was already working other than the Blitter and has been enhanced further.

Lou Quote:

All a blitter is - is a memory mover. It's not that complicated. Re-iterates my point about why the stand-alone took so long. In many ways they had to start from scratch since Gunnar was all into the cpu... So none of this Natami talk is much applicable to Vampire.

A Blitter is a coprocessor that is more complicated than you say and HDL programming is more difficult than traditional programming. For whatever reason, Thomas had trouble fully implementing it (the line mode) and he wanted it fully implemented in hardware (FPGA). Gunnar wanted to replace the Blitter with the SIMD unit of the Apollo core so it appears he did not fix the Blitter support of SAGA. The Blitter does not work as is with new chunky gfx and the setup times likely make it slower than using an SIMD unit so this is a reasonable decision even if finishing the hardware support and throttling the Blitter by default would likely be better for compatibility.

Lou Quote:

Doesn't disprove anything I've said and as I've said - as much was admitted by a couple of developers.

Was it Renee Cousins who insinuated the Apollo core was based on a weak ColdFire core or a complete hoax using ARM emulation underneath? She should have known better than to make absurd suggestions like this no matter how angry she was at Gunnar. Gunnar is secretive and only allowed access to the source code to a select few HDL coders which is why I did not see it too. This can cause suspicion and conspiracy theories. Natami development was more open and more developers had access to the HDL code (I have N68050 sources). I was an Apollo team member before Renee and have first hand knowledge of what I wrote above. Majsta wrote on his web site about getting the TG68 core working in his accelerator and then the performance boost of getting the cut down Apollo core working. If you don't believe Majsta and I, contact Meynaf and ask him if he remembers anything differently or has any doubts about the existence of the Apollo core or SAGA (he has less reason to stand up for Gunnar than I do but he is also honest). Sorry, get your information straight before repeatedly spreading false rumors.

Last edited by matthey on 20-Jun-2021 at 03:44 AM.

@matthey

SAGA is mostly hot air, I don’t grasp how you can call it “a success” unless you ONLY believe what you read without having access to actually USE it. Also, “success” implies wide spread availability and support. Nope.

I still haven’t seen Slamtilt with multiball on SAGA, it requires interlaced mode - Minimig core can do it, but can SAGA on V4? I’d love to see a demonstration on youtube if it is possible.

As for Gunnar being secretive… four years and one month ago:

http://www.apollo-core.com/knowledge.php?b=1¬e=5768

“Release early and release often”

Last edited by kolla on 20-Jun-2021 at 07:20 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

Was it Renee Cousins who insinuated the Apollo core was based on a weak ColdFire core or a complete hoax using ARM emulation underneath?

“based on ColdFire core” yes (and why not in its early incarnations, the apollo-core.com site was eager to point out CF compatibility as well)

The ARM stuff you are now just making up on the fly, noone ever claimed that.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Read the last post on this page:
http://apollo-core.com/knowledge.php?b=4¬e=17188&order=&x=7

I believe it was also mentioned and expanded upon else where. This is all I found with a quick search.

FYI, I did take a course in digital circuit design back around 1991 and even back then there was visual (GUI) software were we could link transistors to create complicated circuits. The semester long project was to create an integer ALU. The software was available even to MACs.

I eventually switched from engineering to information science...

So I understand the differences but it's not the voodoo and black magic to me that it would look like to non-technical people.

Also your story about the deal between Thomas and Gunnar doesn't line up. Gunnar was the cpu guy...so it would make more sense that Gunnar was allowed to re-use the cpu for Apollo core...and again since they has none of the custom chips in FPGA, that was the years long delay of the stand-alone. As far as SAGA, the one thing that probably did carry over is what takes an image and sound and converts it to an HDMI signal. I'd hardly call a frame buffer and DSP - SAGA... but if you want to - feel free.

This reminds me of an old saying this is what happened to me asking for AKIKO implementation:
All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.

I think I am actually unbanned now as my posts have my name again and under it says "Needs Verification" ... as if I'd ever rejoin that poop-show... Do I have to return my badge of honor for being banned now?

Last edited by Lou on 20-Jun-2021 at 07:23 PM.
Last edited by Lou on 20-Jun-2021 at 07:20 PM.
Last edited by Lou on 20-Jun-2021 at 07:17 PM.
Last edited by Lou on 20-Jun-2021 at 06:58 PM.

@NutsAboutAmiga

You mean working for free and keeping all the money for himself? Yes indeed

kolla Quote:

SAGA is mostly hot air, I don’t grasp how you can call it “a success” unless you ONLY believe what you read without having access to actually USE it. Also, “success” implies wide spread availability and support. Nope.

Success to me is how enhanced SAGA is without breaking compatibility.

kolla Quote:

I still haven’t seen Slamtilt with multiball on SAGA, it requires interlaced mode - Minimig core can do it, but can SAGA on V4? I’d love to see a demonstration on youtube if it is possible.

Are the capabilities of your monitor detected which doesn't support outdated interlace modes? Ok, it would be nice to deinterlace the display into a similar non-interlaced resolution while preserving the aspect ratio and while letting the game think the display is interlaced. These kinds of enhancements may need some configuration and tweaking. Props to other AGA chipsets too. Their focus is even more on compatibility but some have nice enhancements to support modern hardware too.

kolla Quote:

As for Gunnar being secretive… four years and one month ago: http://www.apollo-core.com/knowledge.php?b=1¬e=5768 “Release early and release often”

Where is the SAGA source code available?

Gunnar may have been required to open source the SAGA source code as part of the agreement with Thomas. It doesn't sound like Gunnar although the Apollo core is his focus and not SAGA.

kolla Quote:

“based on ColdFire core” yes (and why not in its early incarnations, the apollo-core.com site was eager to point out CF compatibility as well)

ColdFire was evaluated for the Natami project. Freescale was contacted and a developer kit and documentation obtained. It was about a 200 MHz ColdFire v4 as I recall. Performance was close to that of the slower clocked 68060 for ColdFire optimized code but poor for 68k code. There was a superscalar v5 ColdFire created that clocks over 300 MHz with a design and performance similar to the 68060 but it isn't available in off the shelf chips. The ColdFire source code that was released was for a primitive ColdFire like the v2.

68060 110 MIPS @ 75 MHz (0.50 um) in 1994
CF2Core 25 MIPS @ 33 MHz (0.80 um) in 1995
CF5{e}Core 610 MIPS @ 333 MHz (0.13 um) in 2002

The numbers come from Motorola/Freescale ASICs and the performance would normally be slower in FPGA but this is such an old process that an affordable FPGA may be able to achieve similar performance as the v2 ColdFire with some tweaking and likely a higher clock rate. It would take quite a few changes for 68k compatibility and performance enhancing features. There would have been nothing wrong with the the Apollo core had it originated from the ColdFire core. I have the N68050 sources and I haven't noticed anthing about ColdFire origins. There are copyrights from someone else besides Jens in some of the code (code from a non-68k core?) so he didn't create it all from scratch but it looks like he did almost all of the work.

P.S. Motorola/Freescale was asked if they had any objections to developing a 68k core after the CF core was rejected for the Natami project. They had no objections but the trademarks were expired anyway.

Lou Quote:

Read the last post on this page: http://apollo-core.com/knowledge.php?b=4¬e=17188&order=&x=7 I believe it was also mentioned and expanded upon else where. This is all I found with a quick search.

The link doesn't work. I have read the accusations from Renee before (originally on EAB?) and I don't think she has enough information to warrant the accusations. I don't have all the information needed to evaluate her claims either but what I do have and know does not agree with her accusations.

Lou Quote:

FYI, I did take a course in digital circuit design back around 1991 and even back then there was visual (GUI) software were we could link transistors to create complicated circuits. The semester long project was to create an integer ALU. The software was available even to MACs. I eventually switched from engineering to information science... So I understand the differences but it's not the voodoo and black magic to me that it would look like to non-technical people.

Good. Now use a little non-computer logic (critical thinking) to go with your computer logic.

Lou Quote:

Also your story about the deal between Thomas and Gunnar doesn't line up. Gunnar was the cpu guy...so it would make more sense that Gunnar was allowed to re-use the cpu for Apollo core...and again since they has none of the custom chips in FPGA, that was the years long delay of the stand-alone. As far as SAGA, the one thing that probably did carry over is what takes an image and sound and converts it to an HDMI signal. I'd hardly call a frame buffer and DSP - SAGA... but if you want to - feel free.

Gunnar is interested in more than the CPU core. Gunnar was involved in creating a 3D gfx card for the Amiga. He tried to get Thomas to convert the SAGA AHDL sources to VHDL. He was interested in creating 3D for the Natami project as well and drew the wrong kind of attention to the Natami project which may have been a distraction for Thomas. Gunnar is supposedly working on 3D acceleration for the Vampire right now. Thomas may not have been happy with some of Gunnar's activities in the Natami project but that doesn't mean he would withhold SAGA from him, especially if he thought the effort might be advanced by doing so.

People didn't believe the MiniMig was real either and it wasn't even the first FPGA project. The Boxer and Clone-A came before it even though they were never released. Now there are so many FPGA projects that it is easier to borrow someone else's Amiga chipset code or CPU core code than to emulate the hardware but people still don't believe.

Lou Quote:

This reminds me of an old saying this is what happened to me asking for AKIKO implementation: All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.

Gunnar could be more open minded and more polite to people making requests. Do realize that most requests which he agrees to require a significant amount of work and testing. While the C2P logic is simpler than say a Blitter coprocessor, simulating most of Akiko is better for compatibility and no small job.

Last edited by matthey on 20-Jun-2021 at 11:11 PM.

@matthey

Quote:

matthey wrote: The link doesn't work. I have read the accusations from Renee before (originally on EAB?) and I don't think she has enough information to warrant the accusations. I don't have all the information needed to evaluate her claims either but what I do have and know does not agree with her accusations.

Samuel Crow let the cat out of the bag.
I know nothing of Renee and EAB. Please link it to me.

Quote:

Good. Now use a little non-computer logic (critical thinking) to go with your computer logic.

My point exactly. How was 'compatibility' maintained? By throwing everything into the cpu.

Quote:

Gunnar is interested in more than the CPU core. Gunnar was involved in creating a 3D gfx card for the Amiga. He tried to get Thomas to convert the SAGA AHDL sources to VHDL. He was interested in creating 3D for the Natami project as well and drew the wrong kind of attention to the Natami project which may have been a distraction for Thomas. Gunnar is supposedly working on 3D acceleration for the Vampire right now. Thomas may not have been happy with some of Gunnar's activities in the Natami project but that doesn't mean he would withhold SAGA from him, especially if he thought the effort might be advanced by doing so.

He didn't create a 3D accelerator, he created a 2D video card that plugged into a Zorro slot.
He thought AMMX would be enough but it isn't.

I'm detecting Stockholm syndrome.