Amiga ppc was success. It was at least as fast as good as cheap pc from win95 era.
Something that real Amiga 68k never reach.
And that level Amiga ppc reach many years ago.
Apollo/Natami/Vampire still is two times slower that ps1 in 3D graphics.
I appreciate what gvb do in cpu but graphics is still very very slow and outdated.
It is just atari jaguar style blitter. Without clipping.
Without supoort for trangles. just line drawing with texture.
Still far away from cheap pc from win95 era.
After so many years.
After Apollo/Natami/Vampire failure Amiga 68k users should accept graphics card concept.
Amiga 68k users should revert to last up to date Commodore chipset ECS.
And for any never graphics use graphcis cards.

@ppcamiga1
Quote:

After Apollo/Natami/Vampire failure Amiga 68k users should accept graphics card concept. Amiga 68k users should revert to last up to date Commodore chipset ECS.

Oh, should they ?
I think not.
When this PPC Amiga came out, it was significantly more expensive than a PC, and not really compatible with C='s the Amiga. So, why bother ? Because I was in exactly this situation.
I moved on, bought a decent PC, and installed Linux. Which can run a decent Amiga emulation as well, which allows me to reuse almost all my original Amiga software.

I always viewed the PPC Amiga as stillborn. Neither able to attract new customers, for whom it had to compete with PCs and game consoles, nor able to convince the nostalgic Amiga enthusiasts to drop their beloved platform.

@IntuitionAmiga

Quote:

IntuitionAmiga wrote: @Lou I have written several 6502 emulators, 8080/8085/z80, 68k, even created a CPU of my own design which 32bit 6502 style ISA you might like to try it. I’m planning on writing a 6809 emulator next and then a 486, just because I can. They are all fun to code for and quirky in their own ways but the 68000 ISA is the peak of engineering perfection for anyone who actually knows how to code in various assembly dialects or write emulators. I mention all this because it demonstrates I know these architectures intimately unlike you. You still using Visual Basic?

I haven't done Visual Basic since ~ 2002. I moved onto VB.Net after that and C#.
I still prefer VB.Net syntax over C#, but most of my work now is C# since I'm focusing on Blazor now.

One of my points a while back is, most people use compilers. Roslyn is open-sourced. Should have been ported a long time ago.

Only the most extreme weird people usually with Asperger's syndrome care about assembly and a cpu's ISA.

If your compiler is outputting bad assembly...then fix your compiler.
So great - it's ISA perfection! It's also dead and inefficient. 1K of 6502 code typically requires 3K of 68K code. That's what always requiring more bits gets you.

The fact that you mention Visual Basic, means you probably don't know the difference between Visual Basic and Visual Basic.Net(VB.Net).

I mention this because I actually know useful high-level programming languages intimately, that I use professionally, unlike you.


You sound like another one of those weirdos who thinks Amiga OS and Amiga hardware poops gold nuggets.

There nothing special about a multi-tasking OS on 68K hardware.
OS-9 (not to be confused with Mac OS 9) was doing it on 8 bits way before 'Amiga OS' and it was (unlike Amiga OS) multi-user. Infact Windows almost became a port of OS-9 when Microsoft tried to buy the rights to it in 1989.

So - there's nothing special about 'Amiga OS'.
There's nothing special about 68K.
Considering the PC Engine was outputting 565x240 in 482 colors and 64 sprites in 1987, there's nothing special about the chipset either.

All this defending of 68K is hilarious. It's dead junk. ARM won. AROS-64bit is here and newsflash, it won't run on 68K. Move on. Drop the stupid 'Amiga' trademark and all it's baggage and support AROS64. Maybe also port the Roslyn compiler and then maybe the platform would attract more actual developers rather than just weirdos.

Last edited by Lou on 24-Apr-2025 at 05:17 PM.

@matthey

Quote:

...a bunch of malarky breaking down an entire post sentence-by-sentence hence missing the point...

So - to summarize your post: ARM won.


I said that months ago. Glad you agree.

Also, I limited it to 90's. So - Nintendo going to PPC was 2001. You really need, like the moron mentioned in a previous post, to start digesting the post as a whole rather than a collection of sentences for you to take out of context.

You didn't used to be like this but this forum and its nut-jobs probably got you into that habit.

Last edited by Lou on 24-Apr-2025 at 05:41 PM.

@Lou

Aww aren’t you a cute little boy?

You need to get laid methinks.

I don’t know high level languages? loool

Unlike you I don’t have code for a living, the DoD pay me far more than lowly software developers earn for my other more specific skills. I’m just one of those weirdos who codes for fun because it’s easy.

_________________

@IntuitionAmiga

Quote:

IntuitionAmiga wrote: @Lou Aww aren’t you a cute little boy? You need to get laid methinks. I don’t know high level languages? loool Unlike you I don’t have code for a living, the DoD pay me far more than lowly software developers earn for my other more specific skills. I’m just one of those weirdos who codes for fun because it’s easy.

Well, you thinking I'm a cute little boy says all that needs to be said about you.

@Lou

50 years old and nothing better to do than talk like a 12yr old kid on obscure forums..

https://www.linkedin.com/in/louis-dias-7b111276

No activity on your linkedin i see. Would be a shame if a bunch of nutjob autists got you fired from AIPSO for bringing them into disrepute.

_________________

Lou Quote:

One of my points a while back is, most people use compilers. Roslyn is open-sourced. Should have been ported a long time ago. Only the most extreme weird people usually with Asperger's syndrome care about assembly and a cpu's ISA.

The assembly/machine language and ISA gives the the lowest level code which is the foundation of all code on an architecture. It is important and why 6502 is a bad choice if using a compiler.

Lou Quote:

If your compiler is outputting bad assembly...then fix your compiler. So great - it's ISA perfection! It's also dead and inefficient. 1K of 6502 code typically requires 3K of 68K code. That's what always requiring more bits gets you.

The 68k easily has better code density (smaller code) than the 6502.

http://deater.net/weave/vmwprod/asm/ll/ll.html Quote:

Linux_Logo total executable size Architecture | Size in bytes m68k 870 6502 1130 (+30%)

The 6502 executable is 30% larger than the 68k executable. It should actually be more as we submitted a change that reduced the 68k executable to 854 bytes. Source codes are available so feel free to improve the 6502 assembly code if you can. The 6502 has one of the worst code densities in its categories. The Z80 and 808x have excellent code density.

Lou Quote:

There nothing special about a multi-tasking OS on 68K hardware. OS-9 (not to be confused with Mac OS 9) was doing it on 8 bits way before 'Amiga OS' and it was (unlike Amiga OS) multi-user. Infact Windows almost became a port of OS-9 when Microsoft tried to buy the rights to it in 1989.

OS-9 originally targeted the Motorola 6809 which added high level OS and compiler features. The 68000 and 6809 share many of these same features which is why the first architecture OS-9 was ported to was the 68000. The 6809 and 68000 were close enough to allow the 6809 assembly language code to be ported to the 68000 which is normally very difficult. All the other ports came after the OS-9 assembly code was converted to C. Your example shows that CPUs like the 6809 and 68000 were favored by advanced OSs. The advanced Sinclair QL 68k QDOS was the first preemptive multitasking OS that came with a PC and influenced Linus Torvalds to create another preemptive multitasking OS called Linux. The Linux predecessor Unix was popular on 68k workstations. Then there is the preemptive multitasking AmigaOS which you say was nothing special like the 68k. Why do you think the most influential preemptive multitasking OSs of the 1980s came out on the advanced 68k instead of primitive 6502?

Lou Quote:

So - there's nothing special about 'Amiga OS'. There's nothing special about 68K. Considering the PC Engine was outputting 565x240 in 482 colors and 64 sprites in 1987, there's nothing special about the chipset either.

The X68000 also came out in 1987 with a 68000@10MHz and a better chipset than the Amiga and PC Engine. It is also upgradeable to a 68060 like the Amiga and many times more memory. It was more advanced OSs on CPUs like the 68k that made upgradability possible so early. The 68000 Genesis/Mega Drive and Neo Geo consoles missed out by not including enough of an OS but the CD32 also allows a 68060 as likely one of the earliest consoles that could be upgraded to many times the performance and memory while retaining good compatibility. The 6502 could barely use an OS and support expandability mostly with hacks and workarounds so forget upgradable 6502 PCs and consoles without losing most compatibility.

Lou Quote:

So - to summarize your post: ARM won. I said that months ago. Glad you agree. Also, I limited it to 90's. So - Nintendo going to PPC was 2001. You really need, like the moron mentioned in a previous post, to start digesting the post as a whole rather than a collection of sentences for you to take out of context. You didn't used to be like this but this forum and its nut-jobs probably got you into that habit.

You just want to focus on ARM in the 1980s and 1990s?

Acorn: NS SC/MP -> 6502 -> NS32k -> Olivetti gained control -> ARM -> dead

3DO: ARM -> dead

ARM died on the desktop with Acorn and ARM died in the console market with 3DO. The successor to the 3DO was planned to be PPC by the way.

ARM survived in the embedded market but they were #4 in 1997 for 32-bit chips where about 8 times as many 68k chips were shipped.

RISC Volume Gains But 68K Still Reigns
https://websrv.cecs.uci.edu/~papers/mpr/MPR/19980126/120102.pdf

ARM found a small niche in mobile chips. The ARM based Apple Newton was a commercial failure but it paved the way for the iPod, iPhone and iPad which were successes. ARM had a slow start and looked nearly dead before rebounding. The major change in fortunes for ARM came in 1994 with the Thumb ISA introduction from licensing SuperH from Hitachi, a 2nd source for the 68000. Code density like the 68k allowed to use cheaper memory to better compete in the embedded market.

@Lou

Quote:

Lou wrote: Only the most extreme weird people usually with Asperger's syndrome care about assembly and a cpu's ISA. If your compiler is outputting bad assembly...then fix your compiler.

'Fix your compiler'... without caring about assembly and the CPU's ISA? Good luck with that.

Quote:

I mention this because I actually know useful high-level programming languages intimately, that I use professionally, unlike you.

Using is not the same as creating. The entire purpose of a compiler is to avoid having to work in assembly language. So the job is pushed onto the compiler writer, who tries to make it do the translation as efficiently as possible. It takes intimate knowledge of the CPU's ISA and a lot of effort to make a good C compiler. GCC has 15 million lines of source code. A huge amount of effort was put into it over many years so users like you could write code in a high level language without caring about the CPU's ISA.

BTW guess which CPU ISA was the first target for GCC? That's right, 68k! Specifically the 68020. It was created in 1987 by Richard Stallman. Here's what he said about it at the time:-
Quote:

The GNU C compiler is now available for ftp... This compiler compiles itself correctly on the 68020 and did so recently on the vax. It recently compiled Emacs correctly on the 68020, and has also compiled tex-in-C and Kyoto Common Lisp

In The GNU Project he talks about the process:-
Quote:

Hoping to avoid the need to write the whole compiler myself, I obtained the source code for the Pastel compiler, which was a multi-platform compiler developed at Lawrence Livermore Lab. It supported, and was written in, an extended version of Pascal, designed to be a system-programming language. I added a C front end, and began porting it to the Motorola 68000 computer. But I had to give that up when I discovered that the compiler needed many megabytes of stack space, and the available 68000 Unix system would only allow 64k. I then realized that the Pastel compiler functioned by parsing the entire input file into a syntax tree, converting the whole syntax tree into a chain of "instructions", and then generating the whole output file, without ever freeing any storage. At this point, I concluded I would have to write a new compiler from scratch. That new compiler is now known as GCC; none of the Pastel compiler is used in it, but I managed to adapt and use the C front end that I had written.

Before crowing about your elite HLL programming skills you should spare a thought for the 'extreme weird people usually with Asperger's syndrome' who made it possible.

You might also want to consider that many of us are competent in various HLLs too, and yet still enjoy programming some systems in asm. Perhaps that makes us weird, but it was a big part of the home computer scene and so is entirely appropriate for a retro computer like the Amiga. Many of us cut our teeth on earlier home computers which needed all the coding efficiency they could get, and we didn't have access to or couldn't afford compilers for them anyway. Asm - or even raw machine code - was the key to getting the performance we wanted.

Many famous developers started out coding in asm, including Bill Gates and Paul Allen - who along with Monte Davidoff ported BASIC to the Altair 8800 using a PDP-10 assembler modified to output 8080 machine code. That software put 'Micro Soft' on the map, and soon they were porting MicroSoft BASIC to many popular home computers including the Apple II, TRS80 and Commodore PET (and later MSX). With that pedigree they got the contract from IBM to make PC-DOS, which was also written in asm (it was basically a port of CP/M - also written in asm). Of course they also ported Microsoft BASIC to the PC - still written in asm!

But Microsoft wasn't the only 'professional' software house to prefer asm over an HLL. The PC's 'killer app' Lotus 123 was written primarily in asm, making it significantly faster than the competition. That other 'killer app', Word Perfect, was also written primarily in asm. Perhaps today only weirdos with Asperger's prefer asm, but back in the 1980's it was the key to success. Bill Gates wouldn't be worth $106 billion today without it.

@coder76

Quote:

coder76 wrote: @cdimauro Quote: The reason is already on the video that you've shared: nowadays the 3D is done in a completely different way compared to the PS1-like way that you've shown. Yes, though the quality of texturemapping is better with SAGA, PS1 uses affine texturemapping, and fixed point arithmetic for vertex calculations, the texture mapping quality is indeed poor. Gunnar said he aims for something like PS2 quality, but I'm not sure how performance of SAGA compares to PS2. For me, PS2 quality/performance 3D in a 68k Amiga would be more than enough.

That's not possibile with the current, limited resources of the FPGA being used, and the clock frequencies that it can reach.

PS2 specs: https://en.wikipedia.org/wiki/PlayStation_2_technical_specifications
Quote:

Quote: As I've already stated, AGA specs weren't published by Commodore, for good reasons. And, BTW, AGA is another example of very Bad-By-Design hardware: a horrible patch over ECS. I have programmed the AGA chipset, and wouldn't say it's a horrible patch, most annoying is that when e.g. resolutions of sprite coordinates and screen sizes have been improved, the bits have been scattered over several registers, so you got. e.g. bits 0-7 in one register, and bits 8-10 in another. The extension of bitplanes from 6->8 was well done, as they left space for 2 additional planes. Color bank switching in AGA was also a nice idea, with copper being able to change a whole bank of colors with a single command. The extension of color resolution from 12 bits to 24 bits resulted in that more than one copper command is needed to load a 24 bit color register instead of one, perhaps a bad thing, but you can still use 12 bit colors in AGA too. Fetchmode 2x and 4x was also added in AGA for greater bitplane bandwidth, these caused a problem with a lot of sprites being disabled with scrolling, as minimum area was now 32 and 64 pixels on both sides of screen, a problem many coders have been complaining about. VGA and DBLPAL screenmodes also disabled a lot of sprites, even if not using any scrolling, so not ideal either.

I've also programmed the AGA at the time, and it was good only because it was cheap and builtin on my A1200.

You can see yourself, from what you've reported above, that it's a very bad, and the only useful thing is the bank switching that on other platforms is done and works much better.

I've written another series of articles which better covers this topic. This is the last one: Missed opportunities to improve the Amiga chipset
At the bottom you'll find the list of all previous articles. The #5 covers AGA (and all chips/chipset that was produced by Commodore for the Amiga) and you can read my technical analysis of why it was too little, too late, too bad.
Quote:

Regarding the SAGA, you can look at SAGA docs how Gunnar added his new hardware registers into $dff000, one can choose to extend old registers, or just make entirely new registers, like he did for e.g. 16x16 bit audio channels.

I already know it, but Gunnar follows the same "principle" of the Commodore engineers that substituted the original ones: adding patches to the chipset to quickly get what they need.

So, the design is very bad.

The audio channels example that you've reported is showing exactly this: a bad patch over the existing chip (just duplicating the audio registers bank), instead of a proper designing.

You can see on the above series how audio could be improved (article #1) in a better way, also taking advantage of the increased frequencies (#3) and increased memory bus width (#4), going specific details for 16, 32, and 64+ memory bus widths.

In a short sentence: a much cleaner and future-proof evolution of the chipset.

@ppcamiga1

Quote:

ppcamiga1 wrote: Amiga ppc was success.

Where, in your parallel universe?
Quote:

It was at least as fast as good as cheap pc from win95 era.

LOL So, a PC from 1995: just one year after Commodore gone bankrupt.

What a GIANT step in technology advance.
Quote:

Something that real Amiga 68k never reach.

On 1995 we had Amigas with 68060 which competed with PCs running Windows '95, so clearly no: PowerPCs machines running post-Amiga OSes weren't certainly better.
Quote:

And that level Amiga ppc reach many years ago.

Which furtherly proved it, thanks!
Quote:

Apollo/Natami/Vampire still is two times slower that ps1 in 3D graphics. I appreciate what gvb do in cpu but graphics is still very very slow and outdated. It is just atari jaguar style blitter. Without clipping. Without supoort for trangles. just line drawing with texture. Still far away from cheap pc from win95 era. After so many years. After Apollo/Natami/Vampire failure Amiga 68k users should accept graphics card concept.

Great that you're sponsoring PiStorm now!
Quote:

Amiga 68k users should revert to last up to date Commodore chipset ECS.

Which was AGA. Memory failure?
Quote:

And for any never graphics use graphcis cards.

I reveal you a secret: Amigas can use graphics cards already since DECADES.

Again, memory failure?

@Lou

Quote:

Lou wrote: @IntuitionAmiga Quote: IntuitionAmiga wrote: @Lou I have written several 6502 emulators, 8080/8085/z80, 68k, even created a CPU of my own design which 32bit 6502 style ISA you might like to try it. I’m planning on writing a 6809 emulator next and then a 486, just because I can. They are all fun to code for and quirky in their own ways but the 68000 ISA is the peak of engineering perfection for anyone who actually knows how to code in various assembly dialects or write emulators. I mention all this because it demonstrates I know these architectures intimately unlike you. You still using Visual Basic? I haven't done Visual Basic since ~ 2002. I moved onto VB.Net after that and C#. I still prefer VB.Net syntax over C#, but most of my work now is C# since I'm focusing on Blazor now.

Oh, now it emerges the truth: you're a BASIC fanboy which never had the capability to use assembly or, even worse, machine language.

The classic quiche eater!
Quote:

One of my points a while back is, most people use compilers.

I reveal you a secret: assemblers are... compilers!
Quote:

Roslyn is open-sourced. Should have been ported a long time ago.

Then please go on and do it!
Quote:

Only the most extreme weird people usually with Asperger's syndrome care about assembly and a cpu's ISA.

Guess what: pure personal offences by a quiche easter which can't sustain the discussion.
Quote:

If your compiler is outputting bad assembly...then fix your compiler.

Here talks the quiche eater which only used BASIC in the past, so he's incapable of understanding not only the assembly language, but it's (still) so important.
Quote:

So great - it's ISA perfection! It's also dead and inefficient. 1K of 6502 code typically requires 3K of 68K code. That's what always requiring more bits gets you.

This is the most stupid and totally absurd thing that you have written about your crappy 65xx compared to the Ferrari of the microprocessors (the 68k, of course).

You clearly have no idea, at all, of what you talk about, because you live on a parallel universe.

Here's the source code of the challenge that YOU've proposed here:

void increment_array_elements(int *a, int n)
{
    while (n--)
        ++*a++;
}

increment_array_elements(int*, int):
        move.l 4(%sp),%a0
        move.l 8(%sp),%d1
        move.l %d1,%d0
        subq.l #1,%d0
        tst.l %d1
        jeq .L1
.L3:
        addq.l #4,%a0
        addq.l #1,-4(%a0)
        dbra %d0,.L3
        clr.w %d0
        subq.l #1,%d0
        jcc .L3
.L1:
        rts

        * = 2049                        ; 
        lda #$00                ; 
        sta $4f                 ; 
        jmp main                ; 
        lda $66                 ; mov r18,r24      ;  a, tmp55
        sta $60                 ; mov r18,r24      ;  a, tmp55
        lda $67                 ; mov r19,r25      ;  a, tmp56
        sta $61                 ; mov r19,r25      ;  a, tmp56
        lda $64                 ; mov r20,r22      ;  n, tmp57
        sta $62                 ; mov r20,r22      ;  n, tmp57
        lda $65                 ; mov r21,r23      ;  n, tmp58
        sta $63                 ; mov r21,r23      ;  n, tmp58
        lda $62                 ; cp r20,__zero_reg__      ;  n
        sec                     ; cp r20,__zero_reg__      ;  n
        sbc #0                  ; replaced use of register 1 with a literal 0, because of AVR GCC __zero_reg__  ;         sbc $4f                 ; cp r20,__zero_reg__      ;  n
        tax                     ; cp r20,__zero_reg__      ;  n
        lda $63                 ; cpc r21,__zero_reg__     ;  n
        sbc #0                  ; replaced use of register 1 with a literal 0, because of AVR GCC __zero_reg__  ;         sbc $4f                 ; cpc r21,__zero_reg__     ;  n
        bmi fixup_16_bit_op_flags34     ; cpc r21,__zero_reg__     ;  n
        bne fixup_16_bit_op_flags34     ; cpc r21,__zero_reg__     ;  n
        txa                     ; cpc r21,__zero_reg__     ;  n
        bpl fixup_16_bit_op_flags34     ; cpc r21,__zero_reg__     ;  n
        lda #1                  ; cpc r21,__zero_reg__     ;  n
fixup_16_bit_op_flags34
        bne patch_1             ; breq .L1                 ; ,
        jmp L1                  ; breq .L1                 ; ,
patch_1
        asl $62                 ; lsl r20  ;  tmp50
        rol $63                 ; rol r21  ;  tmp50
        clc                     ; add r20,r18      ;  _12, a
        lda $62                 ; add r20,r18      ;  _12, a
        adc $60                 ; add r20,r18      ;  _12, a
        sta $62                 ; add r20,r18      ;  _12, a
        lda $63                 ; adc r21,r19      ;  _12, a
        adc $61                 ; adc r21,r19      ;  _12, a
        sta $63                 ; adc r21,r19      ;  _12, a
L3
        lda $61                 ; mov r31,r19      ;  a, a
        sta $6d                 ; mov r31,r19      ;  a, a
        lda $60                 ; mov r30,r18      ;  a, a
        sta $6c                 ; mov r30,r18      ;  a, a
        sec                     ; subi r18,-2      ;  a,
        sbc #LESS-2                ; subi r18,-2      ;  a,
        sta $60                 ; subi r18,-2      ;  a,
        lda $61                 ; sbci r19,-1      ;  a,
        sbc #LESS-1                ; sbci r19,-1      ;  a,
        sta $61                 ; sbci r19,-1      ;  a,
        ldy #0                  ; ld r24,Z         ;  MEM[(int *)a_5], MEM[(int *)a_5]
        lda ($6c), Y            ; ld r24,Z         ;  MEM[(int *)a_5], MEM[(int *)a_5]
        sta $66                 ; ld r24,Z         ;  MEM[(int *)a_5], MEM[(int *)a_5]
        ldy #1                  ; ldd r25,Z+1      ;  MEM[(int *)a_5], MEM[(int *)a_5]
        lda ($6c), Y            ; ldd r25,Z+1      ;  MEM[(int *)a_5], MEM[(int *)a_5]
        sta $67                 ; ldd r25,Z+1      ;  MEM[(int *)a_5], MEM[(int *)a_5]
        clc                     ; adiw r24,1       ;  tmp51,
        lda $66                 ; adiw r24,1       ;  tmp51,
        adc #(1)                ; adiw r24,1       ;  tmp51,
        sta $66                 ; adiw r24,1       ;  tmp51,
        lda $67                 ; adiw r24,1       ;  tmp51,
        adc #0                  ; adiw r24,1       ;  tmp51,
        sta $67                 ; adiw r24,1       ;  tmp51,
        sta ($6c), Y            ; std Z+1,r25      ;  MEM[(int *)a_5], tmp51
        lda $66                 ; st Z,r24         ;  MEM[(int *)a_5], tmp51
        ldy #0                  ; st Z,r24         ;  MEM[(int *)a_5], tmp51
        sta ($6c), Y            ; st Z,r24         ;  MEM[(int *)a_5], tmp51
        lda $60                 ; cp r18,r20       ;  a, _12
        sec                     ; cp r18,r20       ;  a, _12
        sbc $62                 ; cp r18,r20       ;  a, _12
        tax                     ; cp r18,r20       ;  a, _12
        lda $61                 ; cpc r19,r21      ;  a, _12
        sbc $63                 ; cpc r19,r21      ;  a, _12
        bmi fixup_16_bit_op_flags113    ; cpc r19,r21    ;  a, _12
        bne fixup_16_bit_op_flags113    ; cpc r19,r21    ;  a, _12
        txa                     ; cpc r19,r21      ;  a, _12
        bpl fixup_16_bit_op_flags113    ; cpc r19,r21    ;  a, _12
        lda #1                  ; cpc r19,r21      ;  a, _12
fixup_16_bit_op_flags113
        beq patch_2             ; brne .L3                 ; ,
        jmp L3                  ; brne .L3                 ; ,
patch_2
L1
        rts                     ; ret     

increment_array_elements(int*, int):
        sta     __rc4
        txa
        bne     .LBB0_2
        lda     __rc4
        beq     .LBB0_9
.LBB0_2:
        ldy     #1
        bra     .LBB0_4
.LBB0_3:
        sta     (__rc2)
        lda     __rc5
        sta     (__rc2),y
        lda     __rc6
        sta     __rc2
        lda     __rc7
        sta     __rc3
        txa
        beq     .LBB0_8
.LBB0_4:
        lda     #255
        dec     __rc4
        cmp     __rc4
        bne     .LBB0_6
        dex
.LBB0_6:
        lda     __rc2
        clc
        adc     #2
        sta     __rc6
        lda     __rc3
        adc     #0
        sta     __rc7
        lda     (__rc2)
        sta     __rc8
        lda     (__rc2),y
        sta     __rc5
        lda     __rc8
        inc
        bne     .LBB0_3
        inc     __rc5
        bra     .LBB0_3
.LBB0_8:
        lda     __rc4
        bne     .LBB0_4
.LBB0_9:
        rts

@IntuitionAmiga

Quote:

IntuitionAmiga wrote: @Lou 50 years old and nothing better to do than talk like a 12yr old kid on obscure forums.. https://www.linkedin.com/in/louis-dias-7b111276 No activity on your linkedin i see. Would be a shame if a bunch of nutjob autists got you fired from AIPSO for bringing them into disrepute.

LOL. He's an average Joe BASIC developer that never had the chance to go low-level.

His profile is funny when he tries to list the things that he did or knows with each work experience, and he made me ROFL when he's reporting OOP every time.

@cdimauro

He’s hilarious.

Social skills of a child who didn’t have a daddy to tell him how to be a man. Can’t code in any language worth using, but thinks the people who developed the toy languages he loves are idiots.

He’s been doing this routine for 20+ years. I remember him from amiga.org back in the day.

As you pointed out he just resorts to ad-hominem because he doesn’t understand the technology he mentions.

You ever hire a programmer that doesn’t code “weird� pet projects outside of work? I know I haven’t and I never will because they are just trained monkeys with no creativity.

_________________

bhabbott Quote:

'Fix your compiler'... without caring about assembly and the CPU's ISA? Good luck with that.

There is a comment in the recent "68000 - The CPU ahead of its time" video that is applicable to your reply.

68000 - The CPU ahead of its time
https://www.youtube.com/watch?v=njGWWg69B4A
Modern Vintage Gamer
228K views 4 days ago #68000

1,119 Comments
pvc988 Quote:

I am writing my own hobby compiler. 68k is one of the easiest to generate code for. While x86 is the hardest. x86 was the main reason I failed in creating a proper compiler so many times before. Compared to 68k, x86 ISA seems like layers upon layers of decades of bad decisions slapped on top of each other till this day. ^ 14 replies spodule6000 Quote: I did a lot of assembly coding on the 68k back in the day. It's absolute luxury to code for compared to other chips. And I agree with you about x86. If IBM had chosen 68k for the PC then we'd be living in that future cities meme. JordanManfrey Quote: CISC feels like memorizing a book of magic spells compared to RISC peter0x444 Quote: The 68k was also gcc's first target. BGBTech Quote: @JordanManfrey If talking about M68K vs x86, both are in the CISC camp, just with different design choices. Major difference is one was more cleanly designed, whereas the other was/is an ever expanding mountain of hacks... scose Quote: It seems like that, because it is georgemartin1383 Quote: Terry.... AtomSymbol Quote: I am sorry, but it looks like someone who effectively admits to have made "bad decisions" while trying to develop a "proper compiler" is criticizing x86 for "bad decisions". Is it really "bad" that generating optimized code for x86 requires a constraint solver? F1nalspace Quote: @AtomSymbol I used word 'proper' not to say that is meant to be good or done in a right way. I used this word to differentiate it from things that aren't exactly compilers, like interpreters, transpilers, code generators, etc. As well as the fact that (at least for me) 'proper' compiler should be self hosting (which mine isn't really yet, but it's getting there). F1nalspace Quote: @pvc988 Fully agree, i few years ago i wrote a 8086 simulator - just to understand how a CPU of that era works and even the decoding of the instructions is really nasty. Normally i use jump tables to match a N-bytes to a defined register, so that i can execute and validate it very easily - but with X86, you have to fiddle around with bits to find out which register is the target, is the memory the target, is it wide etc. Type of EAC, etc. No idea how modern X86 CPU's, which still uses the same instruction decodes are implemented on the hardware level and be as efficient and allows pre-fetching. daishi5571 Quote: While the x86 was/is a compilation of disasters, I do have to say that at least Intel didn't abandoned their hardware like Motorola did with the 68060. LMB222 Quote: How's the ARM? pvc988 Quote: @LMB222 ARM is really nice. RISC architectures are fundametally different. In RISC architectures most operations are performed in CPU registers. There is mutitude of truly general purpose registers. And there are only few, well defined ways to interact with memory and devices. Instructions are mostly all the same size, execute in about the same time and their encoding is simple and well defined. Code generation methods are all very similar for all RISC architectures. If you have one of them done, you have all of them mostly done. F1nalspace Quote: @LMB222 ARM is much easier to decode, because the instructions are either 32/64/128 bit long. The length of X86 instructions are variable in length, it can be 1 byte or 15 bytes long. The instruction-set of ARM is more streamlined than X86, but ARM has a different memory model - which makes it a lot more difficult to emulate - especially on X86 hardware. Lord-Sméagol Quote: x86 is bodge upon bodge upon bodge ... ! :( It's a wonder that it manages to actually execute code; With instructions anything from 1 to 15 bytes long, it must take a decent amount of transistors to decode!

The CPU ISA is very important for compiler development. I wish to backup further and examine the importance of the hardware and ISA to early OS and compiler design. Employees of Bell Labs created BCPL successors B to C languages and Unix on the DEC PDP-7 mini computer. The PDP-7 was a simple accumulator architecture CPU that is in many ways more primitive than the 6502 but mini computers were much cheaper than workstations. An 18-bit PDP-7 was only $45k USD in 1964 which allowed many businesses access to a computer. The PDP-7 had a hardware feature that was important for Unix.

https://www.soemtron.org/downloads/decinfo/architecture18b08102006.pdf Quote:

After many unsuccessful years of searching, a copy of DECsys was found with the last functioning PDP-7 on the planet, Professor Harlan Lefevre’s system at the University of Oregon (soon to reside at Paul Allen’s PDP Planet in Seattle). But so far, no copies have been found of an even more historic system for the PDP-7, UNIX. The PDP-7’s multi-user protection, crude as it was, sufficed for implementation of the first version of UNIX, making the PDP-7 a significant system in the history of computing. Unfortunately, all copies of UNIX for the PDP-7 have been lost. Some details of the PDP-7 version can be found on Dennis Ritchie’s personal web site.

There were only 120 PDP-7s built which is low and shows the importance of the desired hardware feature. The later and much more popular 16-bit PDP-11 released in 1970 and with over 600,000 units sold was the next target and much less limited. The PDP-11 is a CISC architecture with orthogonal GP registers and powerful addressing modes including post-increment and pre-decrement. It was very influential to the C and OS friendly Bellmac32/WE32k, 68k and NS32k which are better upgrades to 32-bit than DECs own VAX and a cost reduction from MPU integration. Bell Labs was restricted from releasing their Bellmac32 by the US Justice Department and the 68000 beat the NS32k to market, had fewer bugs and has the best ISA. The upgrade to 32-bit pointers and a large flat address space was a major improvement over the PDP-11. PC-relative addressing, separate supervisor and user modes and stack pointers and vectored hardware interrupts are examples of features that were important for advanced OSs. An orthogonal ISA and GP registers were important for high level languages (HLL). These features are still important today as the foundation for advanced OSs and HLLs. As historically important as the PDP-7 and 6502 were, they are too primitive, limited and poorly designed for OSs and HLLs to modernize. The 68k ISA is better than the x86(-64) ISAs, a path to modernization is mostly obvious and good compatibility could likely be maintained with modernization. Anyone who can not see this huge difference should study CPU architectures and their history. Some low level assembly programming including OS friendly low level programming for educational purposes may improve understanding too. I am not talking about you bhabbott but "experts" who love architectures without knowledge or experience.

Edit: Another applicable "68000 - The CPU ahead of its time" video thread that goes right along with our discussion.


JanBruunAndersen Quote:

Anyone who loves the 68000 instruction set and flexible register use should take a look at the DEC PDP-11 CPU and its architecture. ^ 3 replies ferix.98 Quote: Well, the thing is that the 68000 was inspired by the PDP-11, so your appreciation makes sense. HenryKlausEsq. Quote: Thanks for that -- checking out the PDP-11 now. 8bitwiz_ Quote: Motorola did a better 32-bit version of the PDP-11 with the 68K than DEC did with the VAX. The 68K even has octal in its opcode mapping, but people only ever used hexadecimal with it.

Someone wrote nearly the same thing about the 68k being a "better 32-bit version of the PDP-11" than VAX. I found the comment after my post similar to the comment to the video that said practically the same thing as bhabbott. The video has attracted 68k programmers and engineers in mass, many forced to move on from the 68k. AmiWest will likely be dead for the 40th Amiga anniversary like last year when there were maybe 50 people in videos and half were on Trevor's payroll. PPC elitists have to sabotage the 68k Amiga like Motorola had to sabotage the 68k when moving to PPC. The sabotage is as bad for the Amiga as it was for Motorola. PPC is dead, step aside!

Last edited by matthey on 25-Apr-2025 at 07:52 PM.
Last edited by matthey on 25-Apr-2025 at 06:11 PM.
Last edited by matthey on 25-Apr-2025 at 06:04 PM.

I have nothing against 68k.
If real 68k will be faster and cheaper I may use it. Why not?
Especially graphics is too slow.
Last up to date Amiga chipset was ECS.
It was really good. In 1990 it was something.
But after that C= drop ball.
AGA was far behind from what C= should made in 1992.
Apollo/Natami/Vampire team promise to give us new chipset
but after so many years it is still not done.
Still no Amiga chipset on PS1 level.
So this i why I use PPC Amiga.
At least it reach cheap pc from win95 era level.

Oh lord.

What is going on?

_________________
Doing stupid things for fun...

@IntuitionAmiga

Quote:

IntuitionAmiga wrote: @cdimauro He’s hilarious. Social skills of a child who didn’t have a daddy to tell him how to be a man. Can’t code in any language worth using, but thinks the people who developed the toy languages he loves are idiots. He’s been doing this routine for 20+ years. I remember him from amiga.org back in the day. As you pointed out he just resorts to ad-hominem because he doesn’t understand the technology he mentions.

So he's behaving this way since long. Nice to know.

But there's no chance that he can do something else here: I'll use him like a sparring partner to make my days.
Quote:

You ever hire a programmer that doesn’t code “weird� pet projects outside of work? I know I haven’t and I never will because they are just trained monkeys with no creativity.

Exactly. When I've done interviews I've always asked candidates if they contributed to projects, or have personal projects that they work on, or even if they like tinkering with something. It's a good signal that shows passion and interest that goes beyond the usual: "I do the work". A distinctive point for the good ones.


@Karlos

Quote:

Karlos wrote: Oh lord. What is going on?

A lot of fun.

@ppcamiga1

Quote:

ppcamiga1 wrote: I have nothing against 68k. If real 68k will be faster and cheaper I may use it. Why not? Especially graphics is too slow. Last up to date Amiga chipset was ECS. It was really good. In 1990 it was something. But after that C= drop ball. AGA was far behind from what C= should made in 1992. Apollo/Natami/Vampire team promise to give us new chipset but after so many years it is still not done. Still no Amiga chipset on PS1 level. So this i why I use PPC Amiga. At least it reach cheap pc from win95 era level.

@matthey

Quote:

matthey wrote: bhabbott Quote: 'Fix your compiler'... without caring about assembly and the CPU's ISA? Good luck with that. There is a comment in the recent "68000 - The CPU ahead of its time" video that is applicable to your reply. [...]

Some comments are acknowledgeable, but some others show lack of capabilities or adeguate knowledge. Comments can be written by anyone...

But most report things which can be certainly shared. 68000 was the best processor ever, so a large mass positive feedbacks is obviously expected.

Quote:

Someone wrote nearly the same thing about the 68k being a "better 32-bit version of the PDP-11" than VAX. I found the comment after my post similar to the comment to the video that said practically the same thing as bhabbott. The video has attracted 68k programmers and engineers in mass, many forced to move on from the 68k. AmiWest will likely be dead for the 40th Amiga anniversary like last year when there were maybe 50 people in videos and half were on Trevor's payroll. PPC elitists have to sabotage the 68k Amiga like Motorola had to sabotage the 68k when moving to PPC. The sabotage is as bad for the Amiga as it was for Motorola. PPC is dead, step aside!

Of course: who's interested on PowerPCs in our community? Amiga was, and is, only 68k. PowerPC machines aren't Amigas, and they'll never be.