@cdimauro

Quote:

A company has to make profits...

First you gain foothold and erase competition, then you may start collect profits...

@pavlor: it's illegal. Not have Jack Tramiel did something like that...

@Hypex
Quote:

Quote: Hypex wrote: @babsimov [quote]Yes i know, but ECS came in 1990 It didn't seem it like then that I got my A500 for Christmas. I had an A500 Starter Kit. And before then my first computer was a C16.

I got my Amiga 500 in 1988. It was my first computer, but i have followed the Amiga since 1985, in newspapers. So you can understand why i was disapointed with the ECS (and i'm not the only one).

Quote:

Quote: But my main goal with a 640x512 2 color mode at 31 khz is to have a very cheap monitor for office work Have you heard of MagicTV? It was a software deinterlacer for running on a TV. I ran it on my A1200. It did something to the palette colours. Okay not exactly the same.

No i don't have heard about it, sorry. But i find this :

https://www.youtube.com/watch?v=HVc3_Wgqu_c

It seems really cool. Thank you for letting me discover.

Quote:

Quote: Remember the Atari ST sold more or less 6 to 7 millions units. Mr parents gave me a choice in the shop of Atari or Amiga. And I must say, the Atari looked better! It looked cooler on the box. Trendy geey color. And around 20 colourful games were included. OTOH, by comparsion the Amiga was in the dated looking beige case and only had about four games. I was tempted to get the Atari but I thought the Amiga was the right choice. Brand recognition really, a logo on the box. I liked the Commodore brand. Damn machine has cursed me ever since! We must also remember that Jay designed chipsets for Atari and the Amiga was destined to be the next Atari. Good subject for a thread.

Nice personnal history. I agree about the Atari ST case, it was a cool casing design.

Yes, i know about Jay Miner and Atari, it is a long story :)

Quote:

Quote: I can't follow you here, it became too technical, sorry. And here I thought I made it simple. The A500, for example, as standard could display 32 colours on screen in low-res. The C16 could display 121 colours on screen in low res. Quote: To me, in reality, release the C16 as not compatible with the successfull C64 is a waste of money and a bad idea for Commodore. I don't see a need for it to be compatible. It's not meant to be a C64. It was for a different market. For one thing, it only has 16KB RAM, so it couldn't be compatible anyway. But, looking at the PET, VIC-20 and C64; the VIC-20 wasn't fully compatible with the PET. And the C64 certainly wasn't fully compatible with the VIC-20. So I didn't see the problem here. A logo doesn't have to mean one thing and nothing else.

I understand your point of view, and i think i have to agree, compatibility is not essential if you target another market segment.

But, my main goal is Amiga. But, if it don't cost lot of money to keep a 8 bit range like C16 and others, why not. Otherwise, I would rather keep the C64 as it is and sacrifice the others 8 bits in favor of the Amiga.

Quote:

Quote: So i choose the ACS way, 256 color in 1987, way better than ECS at 1990 or AGA (256 color at 1992).... Remember at 1987 VGA exist on PC and MAC (but with no blitter/copper). I always want the Amiga to be better than PC/MAC for the office market. If anything ECS was a slight update. That broke my A500 from playing some games and software. I do agree that AGA was hack. Keeping the RGB 4-bit nibbles and using bank switching to support 256 entries with 24+1 bit colour. Sorry got technical.

Yes ECS was a very slight update (a joke update). At minimum ECS might be included on Amiga 500 and Amiga 2000 in 1987 as standard. At this time it would be a nice update. But, my dream ACS is a better option i think. Maybe ECS in 1987 for low end (68000 based Amiga) and ACS for high end (the 3000 ACS i have described in my original post). I think it's a nice idea and i make an edit to my original post.

About the RGB thing, too technical for me, very sorry to not be able to follow you in this area.

Quote:

It would have been better if had AGA earlier. And even better if AGA was skipped and AAA shipped in its place. Don't get me wrong, compared to OCS/ECS the 24-bit AGA pallette is super crisp along with all those full size hi res modes. But it should have been better with a simpler hardware design rather than trying to fit it into the rigid design of ECS.

I agree, AGA would have been a nice upgrade for the 3000 in 1990 instead of ECS.

Of course if AAA have been shipped with the 3000, it is way better. But, i read that AAA can't allow a low end Amiga due to is high manufacturing cost. It was why i choose to add ACS in 1987. At this time the ACS production cost could have been high. But as it was intended for high-end it was not serious issue. In 1990 it is amortized and can be produced at a reasonable price allow usage in entry level Amiga. The AAA chipset is rumored to be high expensive to produce even in 1992/94.

The thing Commodore might have released in 1990 is the AA+ chipset :
https://en.wikipedia.org/wiki/Commodore_AA%2B_Chipset

So why i don't use it in my dream timeline ?
I don't really know. Maybe because it was AGA based, maybe because i like to have my own new chipset (ACS). I don't know if AA+ would be cost effective at 1987 ? I see the AAA better for high end in 1990. But AA+ in 1987 for high end and at 1990 for low end is fine for me :)
Maybe my ACS chipset idea is not as good as i have thinked :)

Quote:

Quote: I can't follow on the blitter bit and bit-mask. Well, the blitter works on 16 pixels at a time, on a per bitplane basis. So, it works with 16-bit words in memory. Like so: 0000111111110000 Say we want to blit that to a bitmap but only the 8 pixels in the middle. The mask wil protect the bits of the destination bitmap we want to leave as is. So as the blitter reads in the bitmap data to proces it, it read the destination word, mask it then OR the source with it and write it back to the desination. So the pixels are only combined where they are wanted. A mask like so: 1111000000001111 The other thing was blitting to any X/Y coordinate. For this the blitter had to shift or rather rotate the data to write it in between the 16 pixel aligment it worked with. So a mask would hide the left edge and right edge and a simple rotate took care of the middle. To cut it short, planar data is real bitmap data, as it is all split into seperate bits per pixel. And the blitter was optimsed to work with this arrangement.

Sorry, too technical for me to follow, even more in english.

@Hypex

Quote:

Quote: I'd let them develop the OCS chipset with just a few tweaks, 2 channels of 16-bit audio instead of 4 channels of 8-bit for example, Instead of? As well of sure but not instead of. Those extra channels allowed music to play and games to play sound efects. Sure only two per stereo channel but it made a difference. One 16-bit stereo channel would have been okay for professional use like multi-tracking where the CPU renders the output. But not for general use. The Amiga was about hardware acceleration. This would have gone against that and forced the programmer to try and mix it together. Mixing by hand isn't easy; you have to read in different channnel samples....

I get what you mean. How about, in addition to the 2-channel 16-bit mode, an additional 8 channel 4-bit ADPCM mode (4 channels left and 4 right).

The first time I dealt with ADPCM compressed audio, I was quite impressed, the sound quality was similar to 8-bit audio, and the overhead of decompressing the audio was very low, and it could also have been done very easily in hardware I reckon.


Quote:

and adding a 6-bit chunky graphics mode. Quote: That sounds awkward. Sure you can just put the LSB on bit 0 so you plonk in a normal byte value up to 63. But it takes more RAM than 6 bitplanes. Chunky is really only suitable for multiples of two. Planar is good for odd depths. Memory wise.

Yea, it's hard to make the odd bit-number screen modes work. The only reason for considering them is because of the Amigas limited chip-memory bandwidth. Perhaps the best thing would be just to go with chunky from the beginning. Say, limit the original Amiga to palleted 16-colour (4-bit chunky) modes, but throw in a low-resolution 256 colour low-res chunky mode as well. With that there wouldn't be much need for HAM either. Then in further iterations of the Amiga (say with dual-ported VRAM) bring the 256 colour modes to medium resolutions and add in a 15/16 bit low-res palette-less mode

Quote:

Quote: At the same time, I'd set up a small CPU development team and begin developing a new cpu. Commodore did have MOS. But that was stuck in the 80's. In any case, why? The 68000 was fine piece of CPU.

I never said the 68000 wasn't a fine CPU! But a good 16/32-bit RISC CPU would have been much faster while using a lot less transistors. Also, I'm projecting forward a few years here, but by the early 90's some RISC designs were hitting some very high Mhz rates just by moving to deeper pipelines which was a much cheaper way of getting more processing power than very complicated superscalar dual pipelined approach of the 68060.

Quote:

Also, would you have made it big or little endian?

How about a big-endian CPU but with some little-endian support, say, some instruction for easy conversion, or a little-endian addressing mode?

Quote:

Quote: Quote: all machines would come with a IDE interface Blah! As an optional cheap interface sure but without the DMA mode of SCSI there is no point. Also, only two devices per bus compared to 7 on SCSI.

I have to disagree there, SCSI was better but more expensive, IDE was cheaper in terms of interface and drives, why force people to buy something they probably wont need?

@pavlor

Quote:

As someone who used both A1200/C1085S monitor with MagicTV and Atari ST with SM124 monitor I can assure you, difference is enormous.

I tested it out but in the least the hardware should have softened the blow. The only thing that looked good on a TV in interlace mode on the Amiga was a real picture. Which would look rock solid at high res.

Normal computer text on screen just fickered it like mad. That said I had a chance to buy a Microvitec M1438 multisync once at an Amiga meeting for a good price. But I declined. Fact was the screen was shrunk on DblPAL modes and the owner didn't know how to widen it. I knew it was better for my eyes but I just couldn't see the point of buying a "proper" monitor and only being able to use half the screen in high res modes. In the end it was probably a knob or something. I had a fiddle but just couldn't get it right. So I went back to my TV which probably ended up ruining my eyes for now.

Quote:

Nothing beats good monitor - like SM124 or 19" TFT

Well for that you'd need a scan doubler unless your TFT accepts TV over VGA.

Quote:

So I´m not alone? I also like Atari ST case design far more than "boring" A500.

Looks like you're not. I think this is the first time I've said anything about it. It might have been competing with the Amiga back in the day but now I think we are like brothers in arms and I always liked Atari's anyway. (Jay Miner, 68K, custom chips, lost to Apple, ...)

Quote:

It sounds hard from me, but I think concept of AAA was dead end.

I think the Amiga could have survived longer if they just gave it a 24-bit mode. See, people always talk about sound, games and chunky mode. But that wasn't where the Amiga was really at. Fact is it was used in TV and 24-bit with genlocking ability could have kept it going longer. I read talk about AAA not being much better than a PC but so what? I never saw a PC able to connect to a TV and genlock out of the box. Comparing AAA to a PC, like it seems the designers were doing in retrospect, is ignorant of the fact it was widely used in TV studios. Apart from the Toaster. And AAA would left the Amiga better off that the AGA that became the last chipset legacy.

For example, I came across a company who still used Amiga A1200's for video displays years after the PC had 24-bit graphics. I was slighty shocked. Okay that's just one example. But I also did some programming work for them when they needed to program Scala to display a race timer sent over serial for a racecourse. I managed to write a program that could read the serial timer string and program Scala to display it over the ARexx port. But I was unhappy as the whole process took one second from reading the timer to it displaying on screen. They was okay with a one second delay. I don't know how my program was used after that if at all but my contact gave me an A1200 for my work. (Worth $50AUD at the time.)

Last edited by Hypex on 28-Sep-2015 at 03:51 PM.
Last edited by Hypex on 28-Sep-2015 at 03:46 PM.

@cdimauro

Quote:

Last but not really least, an 80386 allowed to address 4GB of memory (only for the data: code was still limited to the first MB of RAM) using the so called "unreal mode". The 4GB were fully linearly addressable.

Okay so what x86 got fully linear access that still exists today? And is it as easy as a on 68K?

Quote:

The argument was more general and much more complex.

Okay will check it out.

What's interesting I think is that one bit depth on just one bitplane is considered chunky. Or at least one bit chunky. As demonstrated by ShapeShifter which ran Mac really fast on my A1200. After one bit depth the format changes, bit planes going into the Z dimension and chunky expressing the pixels across.

Another comparison is that the Amiga supported chunky in a way, with sound samples, which were byte values so direct like chunky data. Not so useful on screen.

Quote:

HAM is a different thing, and it's also more compact, albeit handling it was a nightmare.

HAM is different and the closest to a true colour mode. A chunky HAM would have been easier to manage I think. Even a hybrid with control, R, G and B on different planes I would have been easier think.

Quote:

Because they simply took the 16 colors palette used by the Commodore VIC 20 and 64, and added an 8 levels (3 bits) brightness control. It was cheaper to implement, and very effective.

It also sound lazy. With brightness controls colours like Lt Blue and Dk Blue makes less sense if they could be generated them from one colour base. And 8 blacks reducing the colours to 121 just looks stupid. Making the machines more infamous.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Last but not really least, an 80386 allowed to address 4GB of memory (only for the data: code was still limited to the first MB of RAM) using the so called "unreal mode". The 4GB were fully linearly addressable. Okay so what x86 got fully linear access that still exists today?

All x86s still have segmentation enabled and working. The thing is that normally an o.s. does NOT use segments (which are called selectors in the new protected mode), except for implementing something like syscalls (switching between user and kernel mode, using the so called "Call gates"; but from several years there are ad hoc, much faster, instructions to enter and exit kernel mode in a controlled/secure way), interrupts, etc., or to implement a very fast "kernel memory pool" access (using segment GS).

Applications can use them to implement a very fast "thread memory pool" access (using segment FS).

But essentially both kernel and applications don't use segments in normal, common, operations. So, the memory is accessed linearly, because every segment (code, data, stack) was already setup as a linear, and common (to all segments) 4GB space.

On AMD64/x64/Intel64 Long Mode (64-bit), segmentation is mostly disabled, except for the above mentioned memory pools and some kernel object (interrupts).
Quote:

And is it as easy as a on 68K?

Since all segments are set has linear, 4GB, common address space... yes, it's like on a 68K.
Quote:

Quote: The argument was more general and much more complex. Okay will check it out. What's interesting I think is that one bit depth on just one bitplane is considered chunky.

Yes, it's the only "point of contact".
Quote:

Or at least one bit chunky. As demonstrated by ShapeShifter which ran Mac really fast on my A1200.

That was because the emulator patched the Mac ROM to enable the usage of the Blitter for MacOS's graphic APIs.
Quote:

Another comparison is that the Amiga supported chunky in a way, with sound samples, which were byte values so direct like chunky data. Not so useful on screen.

Interesting point: Amiga loved packed (sound) data too!
Quote:

Quote: HAM is a different thing, and it's also more compact, albeit handling it was a nightmare. HAM is different and the closest to a true colour mode. A chunky HAM would have been easier to manage I think.

It's exactly like non-HAM modes: same benefits for reading & writing pixels.
Quote:

Even a hybrid with control, R, G and B on different planes I would have been easier think.

Easier than (plain) planar graphic, yes, but the complication to handle the 3 channels separately.
Quote:

Quote: Because they simply took the 16 colors palette used by the Commodore VIC 20 and 64, and added an 8 levels (3 bits) brightness control. It was cheaper to implement, and very effective. It also sound lazy. With brightness controls colours like Lt Blue and Dk Blue makes less sense if they could be generated them from one colour base. And 8 blacks reducing the colours to 121 just looks stupid. Making the machines more infamous.

It might sound stupid, but this mechanism is very simple and cheap to implement in hardware, and makes absolutely sense at that time.

Amiga's Extra Half-Brite mode had also two blacks, for the same, exact, reason. But I defy anyone which have seen EHB games in actions to still sustain that it was stupid to waste on color as another black.