23 July 2020, 09:50 | #201 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Given this is literally the first time I've ever heard it being called embarrassing by anyone, never had any non-Amiga user even bring this up when talking to me and never personally felt it at all important for the overall experience, I respectfully disagree.
|
23 July 2020, 12:21 | #202 |
Registered User
Join Date: Apr 2017
Location: France
Posts: 567
|
Oh yes, I agree! From day one the quality of the display that can be connected, was not enough for a professional usage, especially graphical, which was where the A1000 could have won points.
Last edited by TEG; 25 July 2020 at 00:39. |
23 July 2020, 13:53 | #203 | |
Amiga user
Join Date: Nov 2008
Location: Sofia / Bulgaria
Posts: 455
|
Isn't multithreading something like AsyncWB, which according to this page - http://www.haage-partner.de/amiga/aos39/index-e.html only came with AmigaOS 3.9 BB1 in 2001? Although, I believe there were Aminet hacks that added similar to AsyncWB functionality long before this.
Also quote from this page: Quote:
|
|
23 July 2020, 13:59 | #204 | |
Amiga user
Join Date: Nov 2008
Location: Sofia / Bulgaria
Posts: 455
|
Quote:
Is this one of the reasons the Amiga 500 had Monochrome Composite output? Unlike the Amiga 1000 which had Color Composite display output? Or this is for cost reduction reasons? There are some Amiga demos and programs, which were done on monochrome displays. I remember in an old scene magazine a guy did some Amiga demo in a submarine on monochrome display and he coded the graphics assuming how they will look on color display, only to see his product later. |
|
23 July 2020, 14:02 | #205 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,861
|
For sure it was because of cost reduction. No need to add a chip for PAL or NTSC encoding.
|
24 July 2020, 02:07 | #206 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,332
|
At least on PAL, the composite output of the A1000 was abysmal.
The A1000 also had a built-in RF modulator, which was also removed on the A500. Without a modulator, you don't need the typical composite encoder chip either. |
24 July 2020, 23:49 | #207 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 839
|
Wasn't there a WB replacement called JazzBench or something like that?
|
25 July 2020, 01:01 | #208 | |
Registered User
Join Date: Apr 2017
Location: France
Posts: 567
|
Quote:
|
|
25 July 2020, 01:42 | #209 | |
Registered User
Join Date: Aug 2001
Location: Connecticut USA
Posts: 617
|
Quote:
|
|
25 July 2020, 04:30 | #210 | ||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,544
|
Quote:
But despite all that, compared to the single tasking systems we were used to the Amiga was pure magic. Even today I wish could I could drag my PC desktop screen down to see another program with different resolution etc. behind it. Those of us who wanted more added some FastRAM (I had 2MB plugged into the side of my A1000) and increased buffers to make things a bit smoother. I connected a 20MB MFM hard drive and controller to my A1000 via a home made 'bridgeboard' interface, and patched the kickstart to hide a RAD: disk in the upper 512k of FastRAM. This had the boot files copied into it so the hard drive would be mounted automatically on reset. The A1000 would run all day like that so long as I didn't turn the power off. Quote:
But I still don't do silly things like running two copying sessions at once, because the disk thrashing makes it slower than doing them sequentially (even on a 3GHz PC). |
||
25 July 2020, 05:03 | #211 | |||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,544
|
Quote:
In those days there was a big divide between business and 'home' users, and in New Zealand the markets were completely different. Unfortunately (or perhaps fortunately) Commodore was an American company, so they figured they had to cover both markets - even though the Amiga's chipset was not business oriented. Quote:
Monochrome output was cheap to add, and had somewhat higher resolution. But I don't think many people used it. PC monochrome screens used a funny resolution that was incompatible, and why would anybody buy an Amiga, with all those fantastic colors, just to run it in monochrome? Quote:
|
|||
25 July 2020, 08:45 | #212 | |||||
Registered User
Join Date: Sep 2006
Location: New Sandusky
Posts: 942
|
Quote:
Quote:
Quote:
But as I said they could have easily spared the resources to spin a new SID if they hadn't wasted time on stuff that would obviously fail like TED. TED was such a huge step backward for C=. Quote:
Quote:
|
|||||
25 July 2020, 14:53 | #213 | |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,861
|
Quote:
That's so that StartupII runs in a shell instead of a CLI and can use resident. The main Startup-Sequence has a wait command that stops it until StartupII is done, then in the end of StartupII a break is signaled back to CLI 1 (where wait is still running) and Startup-Sequence continues. So it isn't actually actively executing two scripts at the same time. |
|
25 July 2020, 23:05 | #214 | |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 839
|
Quote:
You could replace your standard (pseudocode) Code:
CWAIT position Code:
CMOVE Return,cop1pt ; tell the blitter stuff where it should go to after it is done Return: CWAIT (position|blitfree) ; this now triggers on either being true, not both CSKIP position ; if we are at the wanted position we don't do blitter stuff CMOVE blah,COPJMP2 ; go do some blitter stuff The blitter part would need to advance and update cop2pt after every blit is started so it is possible it would be derailed by the automatic strobe of cop1jmp and hence all blits should be repeatable without side effects (at least cookie-cuts are). (Oh, and when the the blitter part of cop2pt has run to the end you would preferably switch to a different version of the cop1pt list that doesn't run every available cycle.) |
|
25 July 2020, 23:43 | #215 |
Registered User
Join Date: Dec 2014
Location: germany
Posts: 439
|
IMHO a nice option would have been an independent COP3LC register for blitter queuing that would not have been reset at VBlank. So like having a list of CMOVEs that are executed when the copper isn't busy with the display copper list, with a CWAIT that just waits for the blitter to be finished, with some kind of end of the list mechanism. Plus making COP3LC readable, so the CPU could read the position in the blitter queue. Coupled with some fastram that would have been quite usefull, esp. for a lot of smaller blits: Just create a list of blitter commands, start it, do some work in fastmem and get an interrupt when finished.
I think in practice that would be more useful than the possibility to sync the blitter to the electron beam, which is a bit alike to Atari VCS game programming and was probably very seldomly used even in games. |
26 July 2020, 00:12 | #216 | |
Registered User
Join Date: Apr 2017
Location: France
Posts: 567
|
Quote:
|
|
26 July 2020, 08:44 | #217 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
Even Copper move could be made faster, at least the ones that have to set consecutive registers. Some sort of move next, so you could allmost double coppers' speed, and use less dma cycles.
|
05 July 2021, 01:58 | #218 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 839
|
There should have been some kind of setup/configuration that made interlace and non-interlace be programmed the exact same way. Perhaps you'd need twice as many registers or something - the ideas have not fully formed in my head yet.
The idea would then be to have both a 15KHz and a 31KHz connector and a little logic that could sense if 15KHz was not used. This to convert interlace modes to the equivalent non-interlace 31KHz with a single bit register/sensor. There might not always have been enough bandwidth to upscale everything, but that should eventually have come. |
06 July 2021, 10:45 | #219 |
Registered User
Join Date: Jul 2021
Location: Finland
Posts: 56
|
Good thread. Why I didnt even think about the limited joysticks? Its true that joysticks with more buttons and joypads/controllers would have made a difference.
A500 was ok without HD controller. You could get one anyway if you wanted. Besides if you actually needed it you could buy an A2000. Never had big problems with floppy disks. I still use some decades old floppies. |
08 July 2021, 16:19 | #220 |
cheeky scoundrel
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 42
Posts: 6,905
|
Theoretically yes, but you have to keep in mind that people shopping for an A500 did so probably because they were looking for something that fit within a budget.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Non-Amiga things that remind you of Amiga things? | Fingerlickin_B | Retrogaming General Discussion | 1048 | 19 March 2024 11:50 |
wanting to experiment, using Amiga (emulator) as my day to day machine, need advice | mmace | New to Emulation or Amiga scene | 14 | 19 March 2020 11:32 |
Why game companies didn't make better games for Amiga | ancalimon | Retrogaming General Discussion | 35 | 17 July 2017 12:27 |
New Year Day = throw CD32 in the dishwasher day | Paul_s | Hardware mods | 16 | 03 January 2009 19:45 |
Amazing things you've done with your Amiga | mr_a500 | Amiga scene | 67 | 05 July 2007 19:45 |
|
|