@cdimauro
cdimauro wrote:
Quote:

They were just I/O chips. I don't see the problems with them being so slow, for what they do.

Well, there might be some unnecessary performance penalty with interrupts, if you run e.g. a high-frequency CIA interrupt, you need to acknowledge the interrupt register in CIA every time, and that will be slow, in addition to accessing other cia registers.

cdimauro wrote:
Quote:

Because every vendor of USB devices can map the same components (digital axis, analog axis, buttons, scroll wheel, etc.) in a different way --> THEIR driver is needed. It sucks, but that's the sad (sadic) reality...

This is indeed bad, but needs to be thought about more. Do we need special hardware that works better with Amigas, which will be more expensive?

@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro It was stupid even in Commmodore times. I rememeber when I buy a1200. It was more than 30 yrs ago. games don't use hdd and still load from floppy. It was really annoying. On pc games loading super fast compared to Amiga. ootb.

For math power solution, A1200 was designed to be barebone when compared to Atari Falcon, since A300/A600-related debt debacle needs to be paid back.

For 400,000 A1200 units, each sold unit has $50 allocated to the A300/A600-related debt debacle.

From the Commodore - The Final Years book.

Without the A300/A600 debt debacle, Commodore had about $50 budget headroom for each A1200 unit.

Commodore was technically bankrupt in 1993!

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @coder76 CIAA/CIAB chips were first developed for the C64, these are 8bit chips, they are basic counters, that can be daisy chained. Where two of counters can cooperate. Some of the timers are already used by the OS, because its 8bit chip connected to 16bit bus, it skips a bit, this is why all registers are even addresses. (this why it’s a slow chip I guess)

No, CIA A has odd addresses and CIA B even ones:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012E.html#line9
Quote:

Now if you implement it in a FPGA, the FPGA can’t inheritance the slow level switching, the bus speed limits are removed. But it is the same old logic.

No, even implemented in FPGA they can and SHOULD work at the same speed of the original ones (e.g. 700Khz ca), otherwise the system will be incompatible with the original one.
Quote:

NutsAboutAmiga wrote: @cdimauro Quote: They were just I/O chips. I don't see the problems with them being so slow, for what they do. becouse of read / write speeds. (Better pression when busy looping, checking flags, but it can also cause some timing issues, if it does not behave as expected)

That's why they HAVE to work at the original speed.
Quote:

I agree that higher frequency times probably won’t make any sense. Considering requirements of the software.

Even nowadays, the speed is adeguate to what they are needed for.


@coder76

Quote:

coder76 wrote: @cdimauro cdimauro wrote: Quote: They were just I/O chips. I don't see the problems with them being so slow, for what they do. Well, there might be some unnecessary performance penalty with interrupts, if you run e.g. a high-frequency CIA interrupt, you need to acknowledge the interrupt register in CIA every time, and that will be slow, in addition to accessing other cia registers.

How much high in frequency? 100 thousand times? Yes, it will be a bit difficult to achieve it.

But do you really need interrupts happening so much frequently?

Ordinary OSes have around 100 times per second timers. Some have 1000 times per second, but it's already a lot (e.g.: context switching is eating part of the CPU time, which is multiplied by 10 with a so high frequency timer).
Quote:

cdimauro wrote: Quote: Because every vendor of USB devices can map the same components (digital axis, analog axis, buttons, scroll wheel, etc.) in a different way --> THEIR driver is needed. It sucks, but that's the sad (sadic) reality... This is indeed bad, but needs to be thought about more. Do we need special hardware that works better with Amigas, which will be more expensive?

As usual, the ones with boingball stickers on top...

@Hammer

Quote:

Hammer wrote: For math power solution, A1200 was designed to be barebone when compared to Atari Falcon, since A300/A600-related debt debacle needs to be paid back.

The A1200 would have been created even if the A600 didn't exist. Had the AGA chipset been ready in time the A600 might even have been the A1200.

Quote:

For 400,000 A1200 units, each sold unit has $50 allocated to the A300/A600-related debt debacle.

As I have pointed out before, Commodore sold all the A600s they made. They even made a second batch. If they didn't do that they would have made more A500(+)s for about the same cost, and would have about the same associated debt. The difference is they then wouldn't have the smd experience needed to produce the A1200, making it more expensive.

Quote:

Without the A300/A600 debt debacle, Commodore had about $50 budget headroom for each A1200 unit.

Wrong. Commodore had to produce something in order to get sales, and whatever it was would incur the debt. Some people argue that if they just kept making A500s they could have sold more and made more money, but I doubt that. PCs were taking over and the A500 was getting tired. I think sales would have dropped in 1992 anyway. That they needed $1 billion in sales to stay afloat shows how precarious Commodore's financial position was even before the A600.

Things might have been better if they had managed to get the A1200 out before or instead of the A600, but that wasn't going to happen due to lack of a finished AGA chipset - which had nothing to do the A600.

Quote:

Commodore was technically bankrupt in 1993!

True. And also in 1984, 1976, and 1965. From this we see that Commodore teetered on the edge of bankruptcy about every 10 years. Their lives finally ran out in 1994.

Quote:

coder76 wrote: cdimauro wrote: Quote: Because every vendor of USB devices can map the same components (digital axis, analog axis, buttons, scroll wheel, etc.) in a different way --> THEIR driver is needed. It sucks, but that's the sad (sadic) reality... This is indeed bad, but needs to be thought about more. Do we need special hardware that works better with Amigas, which will be more expensive?

No, just adapters to make them compatible, as is currently done. A small cheap MCU can easily do the job. It could be connected directly to the 68k bus for efficient use of USB memory sticks etc. The CH376 is an example that sells for ~$5 on a module with USB port and 8-bit parallel bus interface. It takes care of low-level USB operation so the host system doesn't have much work to do.

@bhabbott

Quote:

The A1200 would have been created even if the A600 didn't exist. Had the AGA chipset been ready in time the A600 might even have been the A1200.

From February 1992, Medhi Ali demanded an A500 class machine with AGA.

From Commodore - The Final Years

In February 1992, Ali told Sydnes he wanted a “full court press� to
produce an A500 class machine using the upcoming AA chipset by
September 1992. All this even before the AA chipset was done beta
testing and months before the A600 launch in May.

On February 26, Bill Sydnes asked his subordinate Jeff Frank how
he could meet the aggressive September schedule. To expedite the
project development time, Frank proposed building the new system
starting with the A600 design, with modifications to the custom gate
array chips to accommodate the AA chipset.


Jeff Frank injected A600 with Medhi Ali's demand for an A500-class machine with AGA.

Two months were consumed with glue logic design changes (e.g. Gayle to AA Gayle, replacing several PLL/Ramsey/Buster chips into Budgie) between A600 and AA600/A1200.

AA500 would be operational with Fat Gray, Ramsey, and Bridgette.

8 months wasted on ECS Amigas R&D from June 1991 to February 1992.

Quote:

As I have pointed out before, Commodore sold all the A600s they made.

As I pointed out, A600's production was in the red ink. A600 had a sales flop at 399 UKP, which needed a price reduction, which led to red ink.

Your "Commodore sold all the A600s" claim doesn't mean Commodore was profitable. UK labor cost is far higher than the Far East. Mehdi Ali departed from the A500 cost structure model.

Sony UK's RPi production is mostly automated. Case assembly is skipped with mostly bare RPi SBC shipments.

Fact: SCI UK's produced A600, and the resulting revenue generation wasn't able to pay itself!


With SNES's European 1992 release, the A600 didn't have the gaming specs to attract a higher asking price!


Quote:

They even made a second batch. If they didn't do that they would have made more A500(+)s for about the same cost, and would have about the same associated debt. The difference is they then wouldn't have the smd experience needed to produce the A1200, making it more expensive.

As I pointed out,
1. The 2nd AA3000+ prototype had an SMD revision before the June 1991 AGA R&D freeze.

2. Commodore - "The Final Years"

A300 Becomes A600
As George Robbins finished off the A300 design, it became clear the
cost reduction goal for the system could not be met, largely because
of the SMT form factor. “I think George probably did a pretty good
job and the surface mount screwed him,� says Joe Augenbraun.
Sydnes had set out to have two Amiga computers at two different
price points: the A500 Plus and the less expensive A300. Instead,
the opposite happened. “They took over what George [Robbins] was
working on and said, ‘We have to change this.’ They wanted new
features, but the A600 didn’t give anybody any new features that
anybody would consider useful,� says Dave Haynie. “It didn’t work
with the Amiga 500 peripherals. It took away the keypad. The result
cost $50 more than the A500. There was this whole list of things
that were wrong with it.�

Porter believes the project manager should have monitored the
development of the computer more closely and have been prepared
to abandon ideas. “Surface mount parts cost more. Four layer PCB
costs more,� he says. “No one was watching the costs.�

By all accounts, Robbins was apathetic during the A300
development, having to be pulled along by coworkers and even Jeff
Frank. It probably would have made more sense to allow Robbins to
concentrate on the A500 Plus while handing off the A300 to a more
motivated engineer who embraced cost reduction and wanted to
prove himself. “If I had been given the project to cost reduce the
A500, I think I probably could've gotten $100 off of it, maybe $150,�
says Joe Augenbraun. “It wasn't that cost reduced. The keyboard
was a pretty nice keyboard. There's money to take out there.
There's a lot of shielding. There was a lot of plastic. There were
extra components on the board. The board was bigger than it
needed to be.�


A reminder, the A600's case and keyboard are good quality, not a cheap/low-cost C64c case/keyboard.

A600 was designed like a laptop PC quality without an LCD screen!

A600 with AGA might attract a sustained higher asking price, but NOT obsolete ECS A600!

Would you prefer an A600 with AGA over an A600 with ECS?

Bill Sydnes can't design a profitable C64 with A500's guts!

Try again.

Last edited by Hammer on 14-May-2025 at 07:51 AM.
Last edited by Hammer on 12-May-2025 at 08:17 AM.
Last edited by Hammer on 12-May-2025 at 08:11 AM.
Last edited by Hammer on 12-May-2025 at 08:06 AM.
Last edited by Hammer on 12-May-2025 at 08:03 AM.
Last edited by Hammer on 12-May-2025 at 08:02 AM.
Last edited by Hammer on 12-May-2025 at 07:52 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@coder76

Quote:

coder76 wrote: Well, there might be some unnecessary performance penalty with interrupts, if you run e.g. a high-frequency CIA interrupt, you need to acknowledge the interrupt register in CIA every time, and that will be slow, in addition to accessing other cia registers.

It don't need to be faster than on the original Amiga.

Remember how much action the 68k has to do before starting an interrupt routine, accessing the CIA registers, that had a very reduced speed on an original Amiga wasn't so much time consuming.

@OneTimer1

I know hippo player is experience some odd behavior and crashes on faster hardware.. with some module formats. Timing is extremely critical.

Last edited by NutsAboutAmiga on 12-May-2025 at 05:00 PM.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @OneTimer1 I know hippo player is experience some odd behavior and crashes on faster hardware.. with some module formats. Timing is extremely critical.

A mod player usually needs to stick to 50 or 60 Hz, because such modules are "linked" to the video refresh rate / vertical frequency of the Amiga.

If Hippo player isn't able to work on faster hardware with such normal (and certainly not high) interrupt rates, then it's clearly evident that it's very badly written...

Quote:

NutsAboutAmiga wrote: I know hippo player is experience some odd behavior and crashes on faster hardware.. with some module formats. Timing is extremely critical.

Yes, even a faster CPU can crash some early programs, I knew some programmers who where extreme proud about their fast scrolling algorithm. They where literally counting every clock cycle, they found out how they don't use to ask the Blitter if it is ready with it's operation, because the Blitter was faster than the CPU, such a program will crash if the CPU gets faster.

Quote:

cdimauro wrote: A mod player usually needs to stick to 50 or 60 Hz, because such modules are "linked" to the video refresh rate / vertical frequency of the Amiga.

Yes, using the vertical blanking interrupt as a timer was common in games, it made sense for video operation but AFAIK most Mod players used it too, and the Mod format might even count note length in video refresh cycles.

Quote:

the minimum time frame was 0.02 seconds, or a "vertical blanking" (VSync) interval, because the original software used the VSync timing of the monitor running at 50 Hz (for PAL) or 60 Hz (for NTSC) for timing.

https://en.wikipedia.org/wiki/MOD_(file_format)#Timing

This might become a problem if you are developing an 'Amiga Compatible', the VSync for Mod players and the VSync for video (think about HDMI) might not be the same any more.

Last edited by OneTimer1 on 13-May-2025 at 10:49 AM.

@OneTimer1 you can use a timer for keeping the mod player in sync with the original Amiga vertical frequencies.

Which is required anyway, because we had mods developed for NTSC and mods developer for PAL system...

Quote:

cdimauro wrote: ... you can use a timer for keeping the mod player in sync ...

Yes, otherwise mod players wouldn't work on PCs, but people would call it 'incompatible' if programs on a FPGA systems or a software emulation won't work like they did on an A500.

@cdimauro
Quote:

Well, there might be some unnecessary performance penalty with interrupts, if you run e.g. a high-frequency CIA interrupt, you need to acknowledge the interrupt register in CIA every time, and that will be slow, in addition to accessing other cia registers. Quote: How much high in frequency? 100 thousand times? Yes, it will be a bit difficult to achieve it. But do you really need interrupts happening so much frequently? Ordinary OSes have around 100 times per second timers. Some have 1000 times per second, but it's already a lot (e.g.: context switching is eating part of the CPU time, which is multiplied by 10 with a so high frequency timer).

High-frequency reading of mouse more than 50/60 Hz comes to mind, USB mice have by default 128 times per second on the PCs, if I recall correctly, and PS2 mouse had below 100. Results in smoother operation of mouse. On the Amiga, we tend to just link mouse handling into VBI interrupt, giving typically 50/60 Hz update rate.

@bhabbott

Quote:

bhabbott wrote: No, just adapters to make them compatible, as is currently done. A small cheap MCU can easily do the job. It could be connected directly to the 68k bus for efficient use of USB memory sticks etc. The CH376 is an example that sells for ~$5 on a module with USB port and 8-bit parallel bus interface. It takes care of low-level USB operation so the host system doesn't have much work to do.

Ok, I remember some older example code for SAGA had some SPI code, so maybe they use a similar method in SAGA to integrate the hardware. I'm not a hardware expert though, but this is interesting. These kind of problems need to be solved for future Amiga FPGAs I believe.

@coder76

Quote:

High-frequency reading of mouse more than 50/60 Hz comes to mind, USB mice have by default 128 times per second on the PCs, if I recall correctly, and PS2 mouse had below 100. Results in smoother operation of mouse. On the Amiga, we tend to just link mouse handling into VBI interrupt, giving typically 50/60 Hz update rate.

USB gaming mice can range from 1000 hz to 8000 hz.

Examples:
1. Logitech G502 X has 1000 hz.
2. The SteelSeries Prime gaming mice can reach 1000 hz.
3. Corsair gaming mice have polling rates ranging from a minimum of 1,000 Hz (e.g. Corsair Harpoon RGB) to a maximum of 8,000 Hz (e.g. M65 RGB ULTRA). All Corsair gaming mice offer at least a 1,000 Hz polling rate.

Amiga's golden years were the gaming personal computers.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@OneTimer1

Quote:

OneTimer1 wrote: Quote: cdimauro wrote: ... you can use a timer for keeping the mod player in sync ... Yes, otherwise mod players wouldn't work on PCs, but people would call it 'incompatible' if programs on a FPGA systems or a software emulation won't work like they did on an A500.

If you want to (perfectly) replicate a system, then you're forced to implement how its works in all its details.


@coder76

Quote:

coder76 wrote: @cdimauro Quote: [quote] How much high in frequency? 100 thousand times? Yes, it will be a bit difficult to achieve it. But do you really need interrupts happening so much frequently? Ordinary OSes have around 100 times per second timers. Some have 1000 times per second, but it's already a lot (e.g.: context switching is eating part of the CPU time, which is multiplied by 10 with a so high frequency timer).

High-frequency reading of mouse more than 50/60 Hz comes to mind, USB mice have by default 128 times per second on the PCs, if I recall correctly, and PS2 mouse had below 100. Results in smoother operation of mouse.[/quote]
Yes, but USB mice rate is perfectly sustainable by CIA's timers.
Quote:

On the Amiga, we tend to just link mouse handling into VBI interrupt, giving typically 50/60 Hz update rate.

Indeed, but there's another technical reason: Paula has only 8-bit counters for the mouse coordinates updates. And it's 8-bit signed, of course.

This greatly limits the accuracy of the mouse movements.