@cdimauro

Just open my profile and check the links to my Amiga projects, then you see who is the developer and who is the incompetent opinionist.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

Quote:

Massi wrote: @cdimauro Just open my profile and check the links to my Amiga projects, then you see who is the developer and who is the incompetent opinionist.

No Amiga games. Thanks for confirming it: incompetent!

@cdimauro

A mediocre incompetent opinionist is what you are.

But actually I must admit that you have an ability: the ability of trolling and you are vey well known because of that.
The rest about you is vapor-ware.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

Quote:

Massi wrote: @cdimauro A mediocre incompetent opinionist is what you are.

Again? I've created games for Amiga but you did NOTHING.

Those are plain FACTs.
Quote:

But actually I must admit that you have an ability: the ability of trolling and you are vey well known because of that. The rest about you is vapor-ware.

Sure. When you're not able to rebut then you resort to personal attacks.

As usual, in your case.

@cdimauro

Quote:

cdimauro wrote: But this mechanism could have simply be removed with 68020+. So, basically only leaving the logic for the even CCs. This would have simplified the logic, requiring less transistors to be used for its implementation.

Sez you. Funny how the designers of the Amiga chipset didn't see it that way. Well I guess you're the genius and they were idiots.

Quote:

As you can see, it's exactly the opposite of what you said.

All I see see is a bare assertion. I bet there are a ton of gotchas your little thought experiment didn't consider.

Quote:

BTW, this should have already be fixed on the ECS (with the Amiga 3000): AGA was already too late.

So Dave Haynie wasn't as smart as you either!

Quote:

As I've said before, currently it requires to split the Chip-Mem accesses between the CPU and the Blitter to use as much as possible of them.

But in a typical AGA game about half the slots will be used up anyway, so they won't be available to the CPU, and any that are will be preferentially used by the blitter. At the end of the day it's all about maximizing bandwidth. We can argue about how best to fine tune the balance between CPU and custom chip access, but every game will be different and few would greatly benefit from your 'perfect' scheme.

Quote:

As you could imagine, this is a nightmare for the developers. And it's still inefficient, because you cannot use all available memory slots at their full potential.

A 'nightmare'? That's nonsense. All hardware has its limitations. Either it can do what you want or it can't, and if it can't you need to dial back your expectations. But the A1200 is much more powerful than the A500, so for experienced developers with realistic expectations it's a relief rather than a nightmare.

Quote:

Hardware flipping is the SMARTEST way to do this operation. Lazy can only applied to whom has NOT implemented it in hardware... And what's the problem? On THIS specific case proper graphic could be provided. Bu you cannot take SOME EXCEPTIONS and pretending to shut down the GENERAL case.

Sure I can. The existence of hardware flipping encourages laziness. Most fighting games look quite unnatural because of it.

Limited memory is just an excuse. The A1200 has 4 times more chip memory than a stock A500, yet sprites are still flipped instead of making them more realistic.

Quote:

It's exactly the opposite: RAM is much more expensive, whereas hardware flipping required a bunch of transistors.

Once you have some RAM, adding more is easy - just 1 extra address bit and you have doubled the memory space and eliminated the mirroring problem. Furthermore that extra RAM is useful for other purposes. Putting mirroring logic in the custom chips had much higher development costs than adding more RAM, for much less benefit. And RAM was getting cheaper all the time, while changing to a new process to squeeze more transistors into the custom chips was not cheaper (typical cost of a new fab was several million dollars - a serous investment).

Mirroring logic was put in arcade machines and consoles because ROM was expensive. This is not a problem for general purpose computers because they generally have lots of storage capacity and the medium is cheap.

Quote:

How many times people enjoyed such images and how many times they enjoyed videogames? Think about it and draw your conclusions...

If the Amiga was a video games console you would have a point. But it wasn't, it was a home computer - implying that people would enjoy using it in more varied applications. One of the main things that sold the Amiga was its amazing graphics. Perhaps the people who used it the most were kids playing games, but they didn't purchase it - their parents did. And they wanted more than a gaming console. That's why most A500 packages included a paint program and word processor. The most popular accessory that I sold with it was - a color printer.

Many times it has been said that the Amiga was ahead of its time. It predated digital cameras and the digital darkroom, but gave a taste of what the future would bring. As someone who was into photography in a big way, developing and my printing my own color photographs in sizes up to 18x22", HAM mode was of great interest. It's main flaw was lack of resolution, but this was fixed with AGA. Finally I could scan my photos and touch them up on-screen, then print them out on a dye-sub or color laser printer instead of mucking around with smelly chemicals in the dark!

Another area the Amiga became famous for early on was raytraced graphics. Eric Graham's 'the juggler' really put the Amiga on the map for this application, driving demand for faster CPUs with FPUs and 24 bit graphic cards. As you know, the juggler animation was rendered in HAM mode, providing the subtle shades and color range that showed the technique off to best effect. This was the Amiga's first 'killer app', which lead to the Video Toaster and Light Wave etc., and might not have happened without HAM mode.

Quote:

This would have required much more transistors, since it's a completely different hardware implementation.

Yes, and I can appreciate why Jay Miner didn't add those things. I previously had a ZX Spectrum and an Amstrad CPC664, both of which only had bitmap graphics. Text rendering was a bit slower than machines with true text mode, and you couldn't change a single 8x8 pattern and have it instantly duplicated all over the screen, but the simplicity of bitmap only appealed to me. Of course today all PCs do it that way, so clearly this was the future.

My first computer was bitmap only with a very low resolution (64x48) and I pined for a character mode. But adding it was complicated. Then I designed a computer using the MC6847 VDG which had all the circuitry for text and graphics modes built in. But text mode was also limiting (6847 can only do green text on a green background) so I created a split screen mode with bitmap graphics and 4 lines of text at the bottom. This was efficient, but not really necessary because I could have simply drawn the text onto the bitmap screen at any position, with the other advantage of being able to use whatever font I wanted.

The main reason for adding text mode to the Amiga was for business apps, making it more competitive with PCs of the day. But that wasn't going to happen anyway because even with a text mode it still wasn't IBM compatible. PCs suffered in text mode because you couldn't mix it with graphics, and before Windows there was no standard way of combining them. However the IBM character set was well suited to creating boxes and menus etc. using characters, so character based UIs soon became standard. Some apps using these were ported to the Amiga, but suffered from lack of colors or sluggish rendering in 16 colors.

Considering the enormous effort put into making the Amiga, suggesting it wasn't enough seems mean. Everybody wants their own special thing that has great importance to them, while others want something different. What we got was a general purpose bitmap based system with some useful hardware acceleration. It didn't have the scaling and flipping effects of dedicated arcade boards, or the text and tiling features of many 8 bit systems, all of which could make certain games easier to create. But like art, games tend to take on characteristics of the medium they are created in. Amiga games tended to be different from arcade game and 8 bit games because its hardware was different. This was not a bad thing.

Quote:

Why you have to wait for others to implement it?

Because you can't just add every feature you can think without there being a cost. The only real use for sprite flipping was ROM based gaming consoles, where the memory saved was worthwhile. But the Amiga was a RAM based machine, and it soon became apparent that memory wouldn't be the issue it once was. Moore's law was operating in full force on RAM chips, which were getting bigger at a dizzying pace. The Amiga (and also the ST) was originally intended to have only 128k RAM, but that quickly changed to 256k and then 512k before it got out the door. The Amiga had an 880k floppy drive as standard, but no cartridge slot - because disks were much cheaper than ROMs.

I remember when Clive Sinclair released the QL in 1984 he said said that soon 1MB would the standard home computer memory size. I scoffed (having just purchased the latest Amstrad 64k system), but it soon happened. In 1986 Atari touted the 1040ST as being the first ever computer to have 1MB for less than $1000. A year later the A500 had 1MB with the trapdoor RAM board installed. With that amount of memory the Amiga could really spread its wings.

Quote:

Hardware flipping can be used on very different games: car games, platform games, even adventures!

Sure, but most games don't have huge sprites with many varied parts that would otherwise need to be duplicated or flipped by the CPU in real time.

Quote:

You haven't developed games, so you don't know the challenges (and space constraints!). Hence, you don't know what's better needed for developers.

You presume I haven't developed any games because? But even if it were true it doesn't mean I don't appreciate the challenges. In the projects I have worked on I worked within the constraints of the platform and didn't complain about it, even when I only had 23k to play with (Sega SC3000 with Super Control Station). I started with systems that really were limited, like the HUG 1802 which only had 1k, my self-designed 6800 system with 6k, and the ZX81 (1k was not enough!).

@cdimauro

Quote:

I've created games for Amiga but you did NOTHING.

This is not really how you argue your point.
We have all written games and apps. Don't use this as a tard argument why youor argument should win.

TL;DR You are coming across as a fool. Calm down.

Last edited by V8 on 29-Oct-2022 at 11:01 AM.

@bhabbott

Quote:

Superhires 8 bitplanes saturates the bus during active display time no matter what mode is in use. HAM8 is no more taxing than 256 colors or 16 color dual playfield. Actually if you don't touch the base colors it's less taxing, because you only have to render to 6 bitplanes.

Super hires would. Most uses wouldn't even use it in hi res. Low res common. Here it uses it for a trick in the HAM render demo,

6 planes would be less taxing to process. But the hardware still needs to process 8.

Quote:

A better choice would be hires HAM8, giving effective horizontal resolution of ~213 pixels. On TV it would look pretty good, with close to the same resolution and much smoother color graduations than 256 colors. In hires there is no DMA contention so the blitter/CPU has full speed access, and there much less to do.

That would be similar to VHS. Might as well enable lace to complete the picture. Be interesting to see how lace would look.

So that would skip the pixel all colours converge on. If the original relies on it. Should still look better than copper chunky.

Quote:

But this isn't a problem with 'modern' CPUs. 32 bits is only one memory access (same as or faster than 8 bits into a chunky graphics card). You'll needs lots of Fast RAM too, but that's not a problem either these days.

Sure, but the frame resolution is still low res. So each pixel takes up a long. Which will need four times as much data than a usual 8 bit mode.

Quote:

No, not in the driver - in HDtoolbox. So it's not really a system design issue except that HDtoolbox was bundled with the OS. The reason for not limiting it to 64k by default was that other drives didn't have the problem, so it would be unnecessarily limiting their performance. However it might have been better to go with the safe option and let 'power' users change it as required.

HDToolbox wasn't the right place. And it was made more awkward needing to set global settings manually for each partition when the whole bus needed it. The mask and max transfer were hardware limits. What power users wanted to do is irrelevant if they misunderstood it because the control hardware cannot do more than it's limited too. Maxing out the max transfer and overloading it only results in corrupted data and/or crashes. The device driver should have been hard coded with the limits and in the least cut back transfers that would overflow max transfer limit.

I got caught on this on my A4000 since the card I was using, which IIRC was first a WarpEngine and then had other controllers, which had limits I wasn't aware of. This would be one of the reasons SCSI cards had their own custom partition software since it would know the limits and plug them in. However, I would have used HDToolbox and given OS3.9 was years old then, wanted the newest HDD software. By default the max transfer was close to 32 bits. I was getting crashes and didn't know why. Made sure I had the cabling and termination set correctly. Then after some research found my max transfer was too high. It was set to 0x7FFFFFFF or similar and was too high. Had to cut it down to 24 bit. Even though a transfer would hardly be over a 24 bit 16MB length I got crashes when it was set over 16MB.

Quote:

Oh, you meant performance, not electrical power consumption.

Yes, wanted to clarify that.

Quote:

The 68020 was less 'crippled' than you might think, due to its 256 byte instruction cache and 32 bit data bus (the CPU in a 386SX PC was more crippled because it had a 16 bit bus and no internal cache). Also it wasn't crippled when reading the system ROM, so OS operation was quite snappy. All in all it was a cheap way to get much better performance than an A500, with the added 'bonus' that 'Fast' RAM really was faster!

And then more speed ups like moving ROM to RAM. Which reduced RAM. Funny, a 1/4 K cache seems tiny now. At most it could store 128 instructions.

Quote:

Back then SCSI was still commonly used in high performance PC systems as well. It was particularly suitable for RAID because you could have up to 8 drives on one controller.

That's one thing SCSI had over IDE. More units per controller bus. But wasn't SCSI limited to 8 devices in total on the bus with the controller taking one slot leaving only 7 slots for devices?

Quote:

IDE became popular because it was cheap, then its performance got better and it pushed SCSI out of the marketplace. I remember buying a Quantum 120MB SCSI drive for my A3000 that 'only' cost NZ$1000 wholesale. A few years later Gigabyte size IDE drives were the same price. The Amiga doesn't generally need as much storage space as a PC though, so that drive lasted me a decade.

SCSI continued to be used for peripherals like flatbed scanners and other equipment like photo scanners. Things with a specific purpose. But in storage IDE took over obviously since IDE ports became build ins with UDMA taking over providing cheaper and fast storage.

I think the Amiga needing less space was because the programs were smaller. Even Amiga programs produced smaller files. Like, Wordworth will produce a 2KB RTF file that when imported into Word and saved out again, will suddenly bloat to 10 times the size and become 20KB!

But, with common media, like audio and image files, the Amiga didn't take up less space with. Now days, an Amiga needs heaps of storage for a WHDLoad collection that can take up gigabytes. It wasn't too long after OS4 came on the scene that it needed gigabytes of memory and almost terrabytes of storage.

Quote:

It's the nature of Amiga fans to get dejected about not having the ultimate best possible performance. But the biggest bottleneck in most systems was the drive itself. The A590 had DMA, but the XT-IDE drive in it maxed out at 150kB/s. The 120MB Seagate 2.5" drive supplied with some A1200s was much slower than the older 40MB model. Any drive that managed to get over 1MB/s was considered to be 'high end'. The 1GB 2.5" IDE drive in my A1200 in my A1200 gets ~2.5MB/s, which is plenty fast enough for me. With a CF Card in the PCMCIA slot it's even faster in typical operation due to the near instantaneous seek time.

Well, in the case I'm thinking it's Amiga fans that had good A3000 or even A2000 setups with SCSI cards and HDD. Then later buy an A1200 with a fast CPU card, use the internal IDE, but find it's slower than their older setup and hardware.

I think I know the feeling. I used to burn CDs and CDRW fine with my A1200. Then later I have an A4000/060 setup. There is a 74GB HDD connected to CyberSCSI. On IDE is a DVD burner. I was backing up some data on it but it just seemed too slow. Even taking into account I was using a DVDRW which should have been faster to write. But it seemed to take ages. IDE to SCSI adapter is what I needed.

Quote:

The PC's serial port couldn't do MIDI baud rate (not even close). The Amiga's serial port did, but of course nobody was comparing the ST to the Amiga, they were comparing it to the PC. PCs eventually solved this problem by putting a MIDI capable UART on the sound card. Since you probably wanted a sound card anyway if you were into making music this wasn't so much of a big deal.

That's interesting it had that limitation. It did seem strange as with MIDI in/outs it would need a card anyway with the jacks on the back. So I didn't know what the problem was since one card with all needed hardware on board should have been possible. The PC wasn't the sort of machine where boxes hung out the back like with an Amiga. So when I first head of this limitation I didn't think the PC serial ports would be used so didn't understand why a dedicated card couldn't do it.

Quote:

However the 'standard' on PC sound cards was to have TTL level MIDI signals on the 15 pin joystick port, and you had to buy a special cable with active components in it do MIDI (just like you did on the Amiga). I bought a bunch of these cables from my supplier who made all kinds of computer cables and adapters. Had to send them all back though, because the MIDI in part didn't work. I took one of the plugs apart and discovered the actual manufacturer (probably in Taiwan) hadn't connected it! MIDI in goes through an optocoupler which I am guessing they couldn't be bothered putting into the cable.

Yes I recall those cards. There's even one of those joystick ports on the back of the AmigaOne since it used standard audio in/outs. That's a useless lot of cables in a funny kind of way. Must have slipped through QC. Did they work with MIDI out?

Quote:

Yet nobody had an issue with the numerous parallel port samplers that disabled multitasking while recording.

I had one. Came with ProTracker and DirOpus. But that was a dedicated device. The screen needing blanking to reduce noise and system frozen to sample at a constant high speed.

MIDI needs to be interactive so can't exactly take over in the same way but does need the timing kept up.

Quote:

They didn't have to kick the OS out completely to get reliable MIDI in, they just had to prevent higher interrupts from interfering and perhaps have a more efficient driver. But that took knowledge of the machine that the developers didn't have (and apparently didn't think to get). Those of us who were into real-time systems knew what was needed, and we weren't fooled into thinking the 'massive power' of the Amiga's 68k CPU and custom chip hardware would make it unnecessary to consider interrupt latency.

It's one of those things where in house development should result in drivers that do the job and don't need third party alternates.

Quote:

Of course this wasn't an issue on the ST because it didn't have preemptive multitasking. So all software on the ST was 'like Protracker' in that it had the system to itself while running (we won't talk about the appallingly bad programming in the original Protracker, or all the 'improved' hacks based on a disassembly of it.).

Yes the ST had that. Less interference. From what I know ProTracker was a hack, hacked from a disassembly of NoiseTracker that was itself hacked from the disassembly of SoundTracker.

Quote:

No, you don't understand. The Amiga has many interrupt sources at different levels. The serial port is not the highest, so if you aren't careful a higher priority interrupt can override it and steal CPU time. Also the standard serial port driver was designed to 'play nice' with other interrupts by only doing one character at a time. This was fine when 1200 baud was fast, not so good at 31250 baud with a MIDI keyboard blasting out note sequences with no flow control. The answer is to suppress higher interrupts and deal with the received data efficiently. And don't run a hires 16 color screen!

The trendy OctaMED 4 look would need 16 colours.

So checked the register and INTENA has TBE for serial empty at level 1. But RBF for serial full at level 5. Suppose they thought sending was more important that receiving.

Another possibility, though strange but I have seen it done, it to use parallel to send serial signals. Usually with other signals. With hardware extension it could do bursts of 8 bits at once. It just needs to be sure those 8 bits are read and written in time.

Quote:

Main reason was so Commodore could upgrade the driver if necessary without having to make new ROMs, or for adding different serial port hardware without having to patch existing programs to use it. The Amiga has a standard device interface to make this easy, and it was fully expected that users might replace the 'stock' driver with one tuned to their needs

I haven't used much serial software. Mainly Term since it was around when I got a modem. So setting serial unit and device looked like a common convention. There were a few around like baud bandit device. But I saw the same with printer set ups.

Quote:

The first Supra 9600bd MODEM I got for the shop's bulletin board cost NZ$1000, half the price of a complete Amiga computer system. In 1992 Supra released their first 14400bd MODEM for US$399. The A1200 had no problem handling this baud rate either, but then came 33k6, and finally 56k which was too much for it. By this time the average PC was a fast 486 or Pentium, and anyone with a 386SX (A1200 equivalent in the PC world) had dumped it - or at least was not trying to use it on the Web!

I started with older 28.8K. Then 33.6K. When I bought a generic 56K new I needed better serial. I bought a Whippet to help. Plugged into the card slot. Would have replaced with Ethernet card but wasn't using A1200 by the time I had broadband with a router. But only adapter I used was CF card adapter file transfer.

Quote:

The last Amigas came out in 1992. All PCs back then had ISA slots, and few had PCI. I have an 800MHz Celeron PC with one ISA bus slot - and a parallel printer port, two RS232 serial ports and a 5.25" floppy drive too! All useful stuff you can't get today.

Unless you pay retro eBay prices.

Funny, when I was sent an Imation drive from a friend, which I always thought was code for imitation, I needed a PC with a parallel port. I found I had none. I had given a Dell away with XP, that was given to me, since I had my use out it for Windows. It was well built though. A friend had me given his older PC with better specs but it had no parallel port. The only machine I had with a PC parallel port was my AmigaOne XE! Because it's not x86 I didn't trust it. Even after compiling a Linux kernel with the PARIDE modules I still thought I needed pure x86.

Problem with being sent an incomplete drive. Previous owner didn't send proper cables and IIRC it was cheaper than the expensive ones online. A cable with a parallel port doesn't plug into a parallel port so there is no point trying to adapt it to a parallel port I found out.

Quote:

It's a pity that bridgeboard slot wasn't better utilized because the market was awash with cheap ISA bus cards back then. Later on they became available second hand for nicks, and would have been an excellent way for Amiga fans do more on the cheap.

Yeah, I picked up an ISA Ethernet card for a few bucks. Sat in a plastic case. Would have been good to use it.

Quote:

No, the Zip drive didn't use ECC/ECP, only 'EPP' (bidirectional) which the Amiga had. The issue was the PC printer port has 4 programmable output control lines, but the Amiga's strobe line is dedicated to producing strobe pulses only. I could have used the other 3 lines with a demux chip to create 8 states, but the joystick port was right there so...

Okay. I wondered what was going on there as the Amiga had the printer lines. Explanations about "the Amiga parallel port is inferior to the PC" didn't help to explain it. So, there's a few things here. The output lines lacking. And then the separate bidirectional lines on the PC. When the PC port had extra lines added for receive. The Amiga used the same data lines.

But if it was called Zip. Why didn't they use ECC/ECP? I expected it to use the best speed and expect it.

Quote:

Yes, that's what the MUX is for, to switch from one controller to the other. A lot of hassle just to get higher density though.

Well, I don't see how switching would help. It would need to transfer both PC and Amiga HD data at HD speeds. Given the point would be to transfer all HD data as HD speed. Thus why I thought a HD driver working with an embedded module that filtered out MFM to only block data would be needed. Since the MFM encoding roughly doubles the data bits, sending the block data as pure data bits, then having an embedded module encode MFM direct to the drive looked like one way about it while using same lines. The other point was to be able to connect a standard HD drive with an adapter board.

Quote:

I can assure you it was, at least in the US which was Commodore's home turf. It was a big deal here in NZ too in the 'serious' market. Home computers like the Amstrad CPC and Amiga were considered to be toys, not worth even thinking about. The very idea of a 'toy' being 'technically superior' to a PC was laughable. And yes, 3 years was all the time it took....

I can see 'toy' label being applied here. IIRC they even sold Amigas in Toys'R'Us. Wouldn't help the label.

Quote:

Yes, compared to other platforms like the C64 and Mac the Amiga was a lot more 'compatible'. At the launch of the A1000 they even demonstrated it running the PC's 'killer app' Lotus 123, from a copy-protected disk! But in the PC world that wasn't nearly enough. Many an early PC clone got dinged for not being 100% compatible, which meant it had to run everything you threw at it without the slightest glitch. That attitude never let up, except for the '100%' goalposts being moved to suit modern machines. Quote:

Ha. I thought the Mac would have been even more compatible. Since it appeared to be more professional aside from the 'toy' sized screen.

Quote:

Kindwords wasn't the best word processor, and like most sophisticated productivity apps it benefited greatly from a second disk drive. But it did work with one drive, cost nothing and was useful. To do the same thing on a PC you needed a hard drive, which in 1985 was not cheap!

It was the first actual word processor I used. Well, it was, compared to the only other one I used, WordWriter, which I wrote in BASIC on my C16. A basic text editor really. I had a C16, so I had to write my own software, but I could buy games.

And apparently it, KindWords, was the pre cursor to Wordworth. My favourite word processor despite it's quirks now days. Unfortunately I haven't found anything to convert WW format into something modern so documents can be loaded in a modern editor.

Quote:

I reckon I spent half my life shoving floppy disks into PCs. It took well over an hour to install Windows 95 from floppies.

That's why CDROM was good for it. I put Windows '95 DOS, MSDOS 7, on a floppy for use with PC-Task and that was enough disks for me.

Quote:

A lot of games used 'manual' protection (we even did that for one title I coded - forced the user to read the manual!). In general games produced in the US tended to be hard drive installable, while those from Europe didn't. This reflected the ownership trends, with many more US Amiga fans having hard drives. About half the people I knew with an Amiga had a hard drive, and many of them had 'big box' Amigas stuffed with cards.

The "manual" protection was common. I like to have the manuals. So I knew what I was doing. I grew tired of pirated games from school friends before too long. A plane game was complicated with lots of keys to press before starting off. Without a guide I didn't see how anyone could play it. I couldn't fly a plane blind as it sits there on the run way!

Quote:

Mostly true. For a while there was a trend towards 'slimline' machines with only one or even no 5.25" drive bays, then CDROM drives became popular and everybody wanted a 'tower' case.

I can still recall a conversation between two young guys about a desktop or tower. Which is best. Those young guys are old now in the modern market.

Quote:

It had a card that plugged into the trapdoor slot, and a cable coming out back on the right hand side. No good if you had an accelerator card. Like I said, we are lucky Commodore died when they did!

Yeah it just sounds messy. But the drive itself looked real neat. Should have just plugged neatly into card slot I think. I did plug audio cables into my CDROM tower externally after building a simple mixer. But expecting CD32 compatibility and making it so messed up the A1200 CDROM I think.

@OneTimer1

Quote:

There was not much software supporting HAM.

It was was rather a application specific hardware mode.

Quote:

It was good for displaying static pictures but hardly used in games or productivity software, even adventures avoided this mode.

Would have needed more effort for games. Most standard paint software supported it. Unfortunately, it wasn't suitable for what Jay would have liked to use it for, flight simulators.

Quote:

I wouldn't call it a failure but it wasn't that much of a benefit.

It did become an Amiga feature displaying real still images. Without that we would have needed a non-standard format. Using a custom copper list.

@Hammer

Quote:

HAM acts like lossy color compression i.e. "HAM can be considered a lossy compression technique, similar in operation and efficiency to JPEG minus the DCT stage".

Yes, that is why I would consider it revolutionary for its time. It wasn't until 16bpp that HAM6 was trumped. And not until 24bpp HAM8 was trumped. But HAM only used a 6 bpp bitmap or 8bpp bitmap for either so used less space. At the expense of colour blending which is where it reduced data. HAM6 could retain RGB4 but HAM8 reduced RGB8 palette to 6bpp.

Quote:

Delta Color Compression works on chunky pixel tiles and compression is applied. DCC adds logic complexity but it conserves bandwidth and cache.

I see compression going from colour to B&W so the example doesn't help.

Quote:

Amiga's HAM mode was a good idea and should have been refined and evolved. Amiga's HAM color compression idea was ahead of its time.

Well, they did, from HAM6 to HAM8. But, it was created to display realistic images, when bandwidth was limited. In the early 1990's display cards could do 16 and 24 bit colour. While images were larger and IFF24 especially they could show the full colour image.

@Karlos

Quote:

I was thinking even simpler. Just export a new RGB image at 4x the resolution to see how bad it is.

Yes, that would work, even simpler.

@pixie

Quote:

I never saw a game using HAM let alone a 3D FPS, and although it renders about half the speed of a normal aga screen mode I am actually quite impressed by it.

This quirky kangaroo game used HAM8 apparently. But don't know about in game as it uses some kind of dual playfield. But it is digitised.

https://crappygames.miraheze.org/wiki/Kang_Fu

Ahem.

@Hypex

Ham mode with dual play field! Imagine the potential, oh wait... xD

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: But this mechanism could have simply be removed with 68020+. So, basically only leaving the logic for the even CCs. This would have simplified the logic, requiring less transistors to be used for its implementation. Sez you. Funny how the designers of the Amiga chipset didn't see it that way.

It happens. Even Jay Miner didn't noticed how inefficient was planar graphics.
Quote:

Well I guess you're the genius and they were idiots.

That's YOUR idea: not mine. In fact, I don't think that they were idiots.
Quote:

Quote: As you can see, it's exactly the opposite of what you said. All I see see is a bare assertion. I bet there are a ton of gotchas your little thought experiment didn't consider.

Then I'm very curious to know them.
Quote:

Quote: BTW, this should have already be fixed on the ECS (with the Amiga 3000): AGA was already too late. So Dave Haynie wasn't as smart as you either!

I'm not an hardware engineer. However this doesn't stop me to analyze technical facts and share my opinion, IF I realize that I could do it (which was this case).

Plus, I've to remind you that the ECS came after 5 (FIVE) years from the original chipset and it brought so few changes that it's ridiculous.
Quote:

Quote: As I've said before, currently it requires to split the Chip-Mem accesses between the CPU and the Blitter to use as much as possible of them. But in a typical AGA game about half the slots will be used up anyway, so they won't be available to the CPU, and any that are will be preferentially used by the blitter. At the end of the day it's all about maximizing bandwidth. We can argue about how best to fine tune the balance between CPU and custom chip access, but every game will be different and few would greatly benefit from your 'perfect' scheme.

Yes, but whatever is the game you cannot maximize the bandwidth usage due to crippled Chip-Mem access for the CPU (when it's possible to use it instead of the Blitter, or in parallel with it).
Quote:

Quote: As you could imagine, this is a nightmare for the developers. And it's still inefficient, because you cannot use all available memory slots at their full potential. A 'nightmare'? That's nonsense.

Sure: it's nonsense for someone which has never developed a game and doesn't know its challenges.
Quote:

All hardware has its limitations. Either it can do what you want or it can't, and if it can't you need to dial back your expectations. But the A1200 is much more powerful than the A500, so for experienced developers with realistic expectations it's a relief rather than a nightmare.

It's self-evident that you have to use as best as possible what you have.

Nevertheless, the crippled Chip-Mem access creates headaches to the developers to utilize as much as possible of the available bandwidth.
Quote:

Quote: Hardware flipping is the SMARTEST way to do this operation. Lazy can only applied to whom has NOT implemented it in hardware... And what's the problem? On THIS specific case proper graphic could be provided. Bu you cannot take SOME EXCEPTIONS and pretending to shut down the GENERAL case. Sure I can. The existence of hardware flipping encourages laziness. Most fighting games look quite unnatural because of it.

Most fighting games look unnatural on Amiga because there's LIMITED space AND lack of hardware flipping.
Quote:

Limited memory is just an excuse. The A1200 has 4 times more chip memory than a stock A500, yet sprites are still flipped instead of making them more realistic.

That's another problem.
Quote:

Quote: It's exactly the opposite: RAM is much more expensive, whereas hardware flipping required a bunch of transistors. Once you have some RAM, adding more is easy - just 1 extra address bit and you have doubled the memory space and eliminated the mirroring problem. Furthermore that extra RAM is useful for other purposes.

Sure, but: how much it costed 512kB of expansion memory on 1985?
Quote:

Putting mirroring logic in the custom chips had much higher development costs than adding more RAM,

That's because you don't know how to implement it and you also don't know how much expensive was RAM at that time.
Quote:

for much less benefit.

Again, you talk of things that you don't know: ask other game developers what they think about the benefits coming from the hardware flipping, and you'll see!
Quote:

And RAM was getting cheaper all the time,

Well, GETTING cheaper... WHEN?
Quote:

while changing to a new process to squeeze more transistors into the custom chips was not cheaper (typical cost of a new fab was several million dollars - a serous investment).

Which wasn't required, since the implementation is simple. Trivial, at the hardware level.
Quote:

Mirroring logic was put in arcade machines and consoles because ROM was expensive.

And RAM was expensive as well at the time.
Quote:

This is not a problem for general purpose computers because they generally have lots of storage capacity and the medium is cheap.

The problem isn't about the storage, rather about the memory = RAM.

The storage problem on Amiga was "solved" by using more floppies, as we know.
Quote:

Quote: How many times people enjoyed such images and how many times they enjoyed videogames? Think about it and draw your conclusions... If the Amiga was a video games console you would have a point. But it wasn't, it was a home computer - implying that people would enjoy using it in more varied applications. One of the main things that sold the Amiga was its amazing graphics. Perhaps the people who used it the most were kids playing games, but they didn't purchase it - their parents did. And they wanted more than a gaming console. That's why most A500 packages included a paint program and word processor. The most popular accessory that I sold with it was - a color printer. Many times it has been said that the Amiga was ahead of its time. It predated digital cameras and the digital darkroom, but gave a taste of what the future would bring. As someone who was into photography in a big way, developing and my printing my own color photographs in sizes up to 18x22", HAM mode was of great interest. It's main flaw was lack of resolution, but this was fixed with AGA. Finally I could scan my photos and touch them up on-screen, then print them out on a dye-sub or color laser printer instead of mucking around with smelly chemicals in the dark! Another area the Amiga became famous for early on was raytraced graphics. Eric Graham's 'the juggler' really put the Amiga on the map for this application, driving demand for faster CPUs with FPUs and 24 bit graphic cards. As you know, the juggler animation was rendered in HAM mode, providing the subtle shades and color range that showed the technique off to best effect. This was the Amiga's first 'killer app', which lead to the Video Toaster and Light Wave etc., and might not have happened without HAM mode.

Fair point. In fact, the Amiga 1000 was quite expensive at the time and it was a personal computer: very distant from the low-cost home computers for the masses.
Quote:

Quote: Why you have to wait for others to implement it? Because you can't just add every feature you can think without there being a cost. The only real use for sprite flipping was ROM based gaming consoles, where the memory saved was worthwhile. But the Amiga was a RAM based machine, and it soon became apparent that memory wouldn't be the issue it once was. Moore's law was operating in full force on RAM chips, which were getting bigger at a dizzying pace. The Amiga (and also the ST) was originally intended to have only 128k RAM, but that quickly changed to 256k and then 512k before it got out the door. The Amiga had an 880k floppy drive as standard, but no cartridge slot - because disks were much cheaper than ROMs. I remember when Clive Sinclair released the QL in 1984 he said said that soon 1MB would the standard home computer memory size. I scoffed (having just purchased the latest Amstrad 64k system), but it soon happened. In 1986 Atari touted the 1040ST as being the first ever computer to have 1MB for less than $1000. A year later the A500 had 1MB with the trapdoor RAM board installed. With that amount of memory the Amiga could really spread its wings.

Already replied above: I don't agree.

BTW, on Amiga32 event in Germany I've talked about hardware flipping with Ron Nicholson and he agreed that it was useful and could have been implemented. But unfortunately no one of them thought about it.
Quote:

Quote: Hardware flipping can be used on very different games: car games, platform games, even adventures! Sure, but most games don't have huge sprites with many varied parts that would otherwise need to be duplicated or flipped by the CPU in real time.

It's the opposite: it's applicable on most games and hardware flipping would have helped a lot.
Quote:

Quote: You haven't developed games, so you don't know the challenges (and space constraints!). Hence, you don't know what's better needed for developers. You presume I haven't developed any games because?

Because you never written of any games when you talked about your developments.

So, have you developed games?
Quote:

But even if it were true it doesn't mean I don't appreciate the challenges. In the projects I have worked on I worked within the constraints of the platform and didn't complain about it, even when I only had 23k to play with (Sega SC3000 with Super Control Station). I started with systems that really were limited, like the HUG 1802 which only had 1k, my self-designed 6800 system with 6k, and the ZX81 (1k was not enough!).

OK, but this doesn't change the point: it's about what was better for developers. As I've already said above, you can talk with other game developers and ask their opinion about what we talked here.

@V8

Quote:

V8 wrote: @cdimauro Quote: I've created games for Amiga but you did NOTHING. This is not really how you argue your point. We have all written games and apps. Don't use this as a tard argument why youor argument should win. TL;DR You are coming across as a fool. Calm down.

Please, read all posts sequentially, because:
- I've replied to all things that Massi has written;
- I've written the above sentence only AFTER that he said that I'm an opinionist. Which is NOT the case, as I've explained.

Actually it's only Massi which derailed the our discussion because he wasn't able to sustain it.

@NutsAboutAmiga

https://www.youtube.com/watch?v=btoU_CQSg7A
Quake runs on Amiga 500's HAM mode at payable frame rates and its CPU is accelerated by PiStorm-Emu68-RPI 3a+.

The frame rates are around 19 fps from demo3 benchmarks.

Amiga 500's 1985 display technology can deliver playable Quake frame rates when there's a super 68K CPU.


---

For comparison
https://www.youtube.com/watch?v=octArwHpaiY
IBM VGA with AMD K7 Athlon XP 2200+ (1800 Mhz) delivered 8.6FPS at 320x200 resolution.

Soltek SL75-KAV (Via KT133A) motherboard supports an ISA slot.

https://thandor.net/benchmark/33
ET4000AX (with P100) delivered about 21 fps. For higher-performance SVGA PCI cards, Pentium 100 Mhz starts to be a bottleneck when it reached 27 fps.


Amiga 500's integrated graphics solution can handle Time Gal laser disc game ports. Commodore wasn't a Japanese games console company with 1st party game studios to produce good quality exclusive game titles.

There are many SVGA ISA cards that can display higher colors at higher resolution, but they are too slow when running action games like Quake at higher resolution modes. One of the best ISA SVGA cards such as ET4000AX is optimized for 320x200 resolution level for action games.

Last edited by Hammer on 30-Oct-2022 at 01:02 AM.
Last edited by Hammer on 30-Oct-2022 at 12:53 AM.
Last edited by Hammer on 30-Oct-2022 at 12:45 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: https://www.youtube.com/watch?v=btoU_CQSg7A Quake runs on Amiga 500's HAM mode at payable frame rates and its CPU is accelerated by PiStorm-Emu68-RPI 3a+. The frame rates are around 19 fps from demo3 benchmarks.

I'm impressed. My A3000 with Cyberstorm 060 overclocked to 66MHz and Picasso-II RTG card could barely manage 10fps. This looks so much smoother! I might have actually enjoyed playing the game at that frame rate.

Hoping the microchip shortage ends soon so I can get my hands on a PiStorm-RPI 3a+!

@cdimauro

Quote:

This contradicts your previous statement about your preference for Elfmania, which has even much less dynamism... Quote:

Fightin Spirit's game environment is dead and it was mocked by other SNES/Genesis gamers.

Fightin Spirit does NOT have SNES/Genesis-style parallax floor and parallax layers.

From https://youtu.be/4Oi--uDSYIw?t=264
This Team 17's Body Blows Galactic (AGA) stage has a single background parallax layer.

https://youtu.be/4Oi--uDSYIw?t=777
Body Blows Galactic (AGA)'s game environment effort with some floor movement and floor mirror effects.

Body Blows Galactic doesn't have dynamic game environment consistency when compared to Elfmania

Fightin Spirit doesn't have Elfmania's parallax floor and parallax layer effects.


Quote:

And Fightin' Spirit is a balance between it and more colored graphics.

I wouldn't use Fightin Spirit as a technical demo for the Amiga when debating against Sega Genesis SF2.

SNES SF2 has reduced player object size to budget for a dynamic game environment.

https://www.youtube.com/watch?v=31y_ScwUB6E
A500 with Fast RAM can run this SF2 tech demo with floor parallax and backwall parallax layer.

Stock A1200 can run the above SF2 tech demo with floor parallax and backwall parallax layer.
This SF2 tech demo runs very smooth on A500 with PiStorm.

SNES/Genesis SF2 is the benchmark to be compared against NOT some less known Neo Geo game title.

Last edited by Hammer on 30-Oct-2022 at 01:14 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Quote:

bhabbott wrote: @Hammer I'm impressed. My A3000 with Cyberstorm 060 overclocked to 66MHz and Picasso-II RTG card could barely manage 10fps. This looks so much smoother! I might have actually enjoyed playing the game at that frame rate. Hoping the microchip shortage ends soon so I can get my hands on a PiStorm-RPI 3a+!

I bought a pre-configured PiStorm Rev B Max II/Emu68/RPi 3a+/32 GB microSD card from Poland and the seller has apparently run out of stock.

From Quake, SoftSyn and MP3 use cases, PiStorm/Emu68 with RTG seems to perform like my old Intel Celeron 300A PC with an S3 Trio 64UV PCI card.

PiStorm/Emu68's brute force software OpenGL render with GLQuake results
https://www.youtube.com/watch?v=_SCyWap_Ocs

VS

https://youtu.be/qorUuh7JfYg?t=95
Official S3 Virge Quake Wrapper to Direct3D

PiStorm32/RPi CM4 is about 2X faster.

PiTray mini with RPi CM4 is known to work with A500's PiStorm/Emu68 but it needs a new RTG P96 driver due to CM4's Broadcom VideoCore VI IGP change.

Pentium II 266/300 (Emu68 with RPi 3a+) to estimated Pentium III 600 (Emu68 with RPi CM4) like CPU power for A1200's AGA would be interesting What IF that is beyond Vampire's AC68080 V4's "What IF".

PS; My MP3 collection is at a high bit rate in the 256 Kbps to 320 Kbps range.

Last edited by Hammer on 30-Oct-2022 at 01:12 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

cdimauro wrote: I'm not an hardware engineer... Which wasn't required, since the implementation is simple. Trivial, at the hardware level.

Not a hardware engineer, yet you conclude that the implementation would be 'trivial'?

Quote:

So, have you developed games?

One standard for you, another for me, eh?

I worked on several games, but none that were released. This was because I code for fun and producing a commercial game is a lot of work. I also hacked a lot of games and looked at how they did the graphics. Of course this was on machines that didn't have hardware flipping.

According to gaintbomb.com the first home computer to have hardware flipping was MSX2, introduced in 1985 (same year as the Amiga). However the V9938 technical reference manual doesn't say anything about this. The blitter may be able to reverse pixel order when copying in reverse. However it appears to only do rectangular block copies with no masking, so I guess this would have to be done by the CPU. The blitter is only 8 bit and often misses DMA slots so it is much slower than the Amiga's blitter, and the CPU to VDP interface is also only 8 bit with a bus speed of ~1MHz. In short, even if it does have true hardware flipping it was no competition to the Amiga.

So it seems that Commodore's engineers were not the only ones who weren't 'smart', since the others apparently weren't able to implement this 'trivial' feature in their designs either.

Quote:

OK, but this doesn't change the point: it's about what was better for developers. As I've already said above, you can talk with other game developers and ask their opinion about what we talked here.

Well sure, ask a developer if they would like this or that feature that might make their job a little easier and of course they will say yes. Might be a different story if they had to choose between that and something else though.

PADDING

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK