CDIZORRAM

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

@cdimauro

Quote:

OK, I see thanks. So, it's an undocumented stuff. In fact, it doesn't work on AGA.

Yes, a slight hardware quirk. From the discussion it looks like it pulls an extra plane word from the register so it can act like a static 16 pixel plane for free, like a texture. But it must be only one way. Anyway about it works around the copper being able to only to work up to 1/8th the resolution of low res width on average as 1/4 low res was common on ECS. AGA has some extra tricks with fetch modes to simulate 1/2 low res.

This video shows copper chunky with code for ECS that works on AGA. I didn't watch it all. I looked for the code.
https://www.youtube.com/watch?v=ste_ejNVvDk

Quote:

That's something which I absolutely don't accept, since it's against Commodore's guidelines.

That's unusual for the average Amiga coder. A refreshing change. Good effort.

Quote:

Not really. Packed can handle pixels of any size. So, for depth = 1 bit it simply is the same as planar. :-8

What I mean is, if the pixels were 4 bit packed for example, a mask would still be 1 bit. So the size of each line would differ with mask compared to pixels. The mask and pixels could be "packed" together as well I suppose.

I'm still working on that magic logic algorithm to combine pixels without that annoying bitmask.

Quote:

Well, I'm a game developer: it was natural to me see some common problems during games development. And find practical solutions for them, like a CLUT loading DMA (which is way more practical and efficient compared to using the Copper).

Obviously the copper evolved from display lists. It has some cool features like being able to modify registers as the beam moves across. Needing to reset all pointers in list seems awkward but it was useful for screen dragging.

Quote:

The same for sprites: a direct pointer to the data instead of packing control words & plain graphic data would have been much much better.

Yeah, I always thought that was awkward. I expected coordinates in registers.

I had this idea for a fast fps counter in ADoom using sprites. After looking at the API I ended up using the ExtSprite functions. But it is still awkward changing sprite images and I couldn't see a way to simply change sprite image. It's limited in palette as well which makes it more work. But I did something wrong as it crashes when freeing sprites. I did so well FS-UAE core dumped!

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: OK, I see thanks. So, it's an undocumented stuff. In fact, it doesn't work on AGA. Yes, a slight hardware quirk. From the discussion it looks like it pulls an extra plane word from the register so it can act like a static 16 pixel plane for free, like a texture. But it must be only one way. Anyway about it works around the copper being able to only to work up to 1/8th the resolution of low res width on average as 1/4 low res was common on ECS. AGA has some extra tricks with fetch modes to simulate 1/2 low res. This video shows copper chunky with code for ECS that works on AGA. I didn't watch it all. I looked for the code. https://www.youtube.com/watch?v=ste_ejNVvDk

Unfortunately the graphic is too much blocky.
Quote:

Quote: That's something which I absolutely don't accept, since it's against Commodore's guidelines. That's unusual for the average Amiga coder. A refreshing change. Good effort.

I don't know if I'm unusual, but I certainly know that if this is the case then there were too many stupid idiots that were too fast moving from the zoe to the keyboard.

Rules aren't party favours to be just admired but are there to be respected and guarantee a future for your applications, when/if the system evolves.
Quote:

Quote: Not really. Packed can handle pixels of any size. So, for depth = 1 bit it simply is the same as planar. :-8 What I mean is, if the pixels were 4 bit packed for example, a mask would still be 1 bit. So the size of each line would differ with mask compared to pixels. The mask and pixels could be "packed" together as well I suppose.

Yes, I knew it. But a packed system system isn't/shouldn't bounded to exactly the same pixel size of the various elements involved.

So, sources and destinations could be made of different pixels sizes. And the same is for the mask, which could be kept as pixels of single bits = one bitplane.

Which, BTW, it was like with planar graphics: not all objects used the same pixel size, right? In fact, with Fightin' Spirit and USA Racing I've used different pixel sizes for different objects of the scene.
Quote:

I'm still working on that magic logic algorithm to combine pixels without that annoying bitmask.

Well, it should be very simple: the mask can be derived / calculated on-the-fly by the color/index zero.
Quote:

Quote: The same for sprites: a direct pointer to the data instead of packing control words & plain graphic data would have been much much better. Yeah, I always thought that was awkward. I expected coordinates in registers. I had this idea for a fast fps counter in ADoom using sprites. After looking at the API I ended up using the ExtSprite functions. But it is still awkward changing sprite images and I couldn't see a way to simply change sprite image. It's limited in palette as well which makes it more work. But I did something wrong as it crashes when freeing sprites. I did so well FS-UAE core dumped!

LOL Have you fixed it?

@cdimauro

Quote:

Unfortunately the graphic is too much blocky.

It is a bit. Looks like a super low res. Still, some demos used it, though I wonder if the output was worth the effort put into displaying it.

Quote:

I don't know if I'm unusual, but I certainly know that if this is the case then there were too many stupid idiots that were too fast moving from the zoe to the keyboard.

A few coders would have come from the C64 scene where you assume one hardware model and bang it how you like. The C128 shows that happening. So much time spent on supporting old C64 code that relied on hardware quirks and exact ROM data they might as well put two C64 boards in a case and called that a C128.

Quote:

Rules aren't party favours to be just admired but are there to be respected and guarantee a future for your applications, when/if the system evolves.

It became apparent what games followed guidelines when they would make or break on later systems. Psygnosis were good at future proofing I found, as they detected 68020 in early games, which meant they worked on my A1200. Others relied on A500 hardware with exact ROM code, so easily broke, but Commodore got the blame for breaking games.

Quote:

Which, BTW, it was like with planar graphics: not all objects used the same pixel size, right? In fact, with Fightin' Spirit and USA Racing I've used different pixel sizes for different objects of the scene.

Right, they don't need to use the same pixel size, they can be different.

Quote:

Well, it should be very simple: the mask can be derived / calculated on-the-fly by the color/index zero.

It can be calculated but I'd like to reduce it to a pure logic operation with non conditional code.

Quote:

LOL Have you fixed it?

No. I kinda gave up on it. The sprites still have to use a limited palette so it's not as easy as black and white. So the counters look funny. If I could pick palette indexes it would be better. But that OS sprite engine still makes changing sprite engine harder than should be. I restore pointers I change but something is messed up. An example of how to change image data with extended sprites would be good.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: I don't know if I'm unusual, but I certainly know that if this is the case then there were too many stupid idiots that were too fast moving from the zoe to the keyboard. A few coders would have come from the C64 scene where you assume one hardware model and bang it how you like. The C128 shows that happening. So much time spent on supporting old C64 code that relied on hardware quirks and exact ROM data they might as well put two C64 boards in a case and called that a C128.

So, they were already complete idiots working (!) with the C64 (and C128) and, since it wasn't enough, they wanted to prove it again with the Amigas...

Poking to unknown registers and/or setting reserved bits and doing the same to system structures was an idiotic thing whatever it was the given system.
Quote:

Quote: Rules aren't party favours to be just admired but are there to be respected and guarantee a future for your applications, when/if the system evolves. It became apparent what games followed guidelines when they would make or break on later systems. Psygnosis were good at future proofing I found, as they detected 68020 in early games, which meant they worked on my A1200. Others relied on A500 hardware with exact ROM code, so easily broke, but Commodore got the blame for breaking games.

Indeed. The list of idiots is very long, unfortunately.
Quote:

Quote: Well, it should be very simple: the mask can be derived / calculated on-the-fly by the color/index zero. It can be calculated but I'd like to reduce it to a pure logic operation with non conditional code.

You could do it. Think about it.
Quote:

Quote: LOL Have you fixed it? No. I kinda gave up on it. The sprites still have to use a limited palette so it's not as easy as black and white. So the counters look funny. If I could pick palette indexes it would be better. But that OS sprite engine still makes changing sprite engine harder than should be. I restore pointers I change but something is messed up. An example of how to change image data with extended sprites would be good.

Leave it as it if it's getting too much effort.

@cdimauro

Quote:

So, they were already complete idiots working (!) with the C64 (and C128) and, since it wasn't enough, they wanted to prove it again with the Amigas...

Old habits die hard. The hardware allowed it. It was common practice and always said to be the best way to get the most out of the hardware at the fastest speed.

Quote:

Poking to unknown registers and/or setting reserved bits and doing the same to system structures was an idiotic thing whatever it was the given system.

Doing that sure is going too far. I wouldn't trust software poking around in system structures. But even Commodore had guidelines on directly accessing registers, with how to check for particular chipsets, so they weren't against direct hardware access.

Quote:

Indeed. The list of idiots is very long, unfortunately.

And for once, Commodore wasn't one of them.

Quote:

You could do it. Think about it.

I'll think about it later then. Just need to draw up a logic table. And do some logic equations.

Quote:

Leave it as it if it's getting too much effort.

I think it is. I leave the counter off in real tests anyway. I tried disabling the routine to change sprites, so it just creates the sprites and displays them, but it still crashes on exit. Gave me an #80000008. I can't see any example for ExtSprites and the API gives no warnings about any data freed when releasing sprites. So nice idea but needs documentation.

Off topic but I found this video tonight. About how Street Fighter could have looked on AGA. Goes into little details of hardware comparisons and features, and I actually watched the whole thing, which rarely happens.

https://www.youtube.com/watch?v=33kH9DdNznA

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: So, they were already complete idiots working (!) with the C64 (and C128) and, since it wasn't enough, they wanted to prove it again with the Amigas... Old habits die hard. The hardware allowed it. It was common practice and always said to be the best way to get the most out of the hardware at the fastest speed. Quote: Poking to unknown registers and/or setting reserved bits and doing the same to system structures was an idiotic thing whatever it was the given system. Doing that sure is going too far. I wouldn't trust software poking around in system structures. But even Commodore had guidelines on directly accessing registers, with how to check for particular chipsets, so they weren't against direct hardware access. Quote: Indeed. The list of idiots is very long, unfortunately. And for once, Commodore wasn't one of them.

Indeed. Because it's important to underline that it wasn't the possibility to directly hit the hardware that was a bad practice. I did it A LOT with my video games (and internal tools).

The problem stays on NOT following the guidelines or even common sense, as I've reported above, when doing it.

Those aren't old habits rather IDIOTIC habits by stupid people which weren't able to write correct programs.
Quote:

Quote: Leave it as it if it's getting too much effort. I think it is. I leave the counter off in real tests anyway. I tried disabling the routine to change sprites, so it just creates the sprites and displays them, but it still crashes on exit. Gave me an #80000008. I can't see any example for ExtSprites and the API gives no warnings about any data freed when releasing sprites. So nice idea but needs documentation.

Strange. Usually the (post-)Amiga documentation was good.
Quote:

Off topic but I found this video tonight. About how Street Fighter could have looked on AGA. Goes into little details of hardware comparisons and features, and I actually watched the whole thing, which rarely happens. https://www.youtube.com/watch?v=33kH9DdNznA

Kudos for the effort, but being honest (as usual) it shows how limited was the Amiga platform for videogames, requiring A LOT of time and tricks to achieve some results which are barely comparable.

Better to have spent all that time to something else, IMO.

@cdimauro

Quote:

cdimauro wrote: Kudos for the effort, but being honest (as usual) it shows how limited was the Amiga platform for videogames, requiring A LOT of time and tricks to achieve some results which are barely comparable.

Well...

Street Fighter II
Quote:

Development of Street Fighter II took about two years and about 35 to 40 people, with Noritaka Funamizu as a producer, and Akira Nishitani and Akira Yasuda in charge of the game and character design, respectively. The budget was estimated at $2,450,000 (equivalent to $4,870,000 in 2021)

CP System
Quote:

Capcom developed the CPS hardware for about two-and-a-half years, during which time they developed two custom microchips that they called the CPS Super Chips, equivalent to the power of ten normal arcade printed circuit boards (PCBs) at the time. The two chips cost £5,500,000 or $9,800,000 (equivalent to $22,000,000 in 2021) to develop.

Not to put down their efforts, but in comparison to development of the original game I wouldn't say it was a LOT of time, and tricks are what the Amiga is all about (I particularly like the way they got all that colorful background animation without using the blitter or CPU). IMO the results are quite comparable, which is impressive considering the Amiga is punching way above its weight here.

Quote:

Better to have spent all that time to something else, IMO.

Like what? This demonstration isn't just about making a better Street Fighter II, it shows techniques that could be used in other games. But even if nobody uses them it was still worth it just to show what could have been done with a bit more time and bigger budget. For some of us just seeing what can be done is entertainment enough.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: Kudos for the effort, but being honest (as usual) it shows how limited was the Amiga platform for videogames, requiring A LOT of time and tricks to achieve some results which are barely comparable. Well... Street Fighter II Quote: Development of Street Fighter II took about two years and about 35 to 40 people, with Noritaka Funamizu as a producer, and Akira Nishitani and Akira Yasuda in charge of the game and character design, respectively. The budget was estimated at $2,450,000 (equivalent to $4,870,000 in 2021) CP System Quote: Capcom developed the CPS hardware for about two-and-a-half years, during which time they developed two custom microchips that they called the CPS Super Chips, equivalent to the power of ten normal arcade printed circuit boards (PCBs) at the time. The two chips cost £5,500,000 or $9,800,000 (equivalent to $22,000,000 in 2021) to develop.

Which is the development cost of the whole game. So, coding, graphics, sound, and hardware.
Quote:

Not to put down their efforts, but in comparison to development of the original game I wouldn't say it was a LOT of time, and tricks are what the Amiga is all about (I particularly like the way they got all that colorful background animation without using the blitter or CPU). IMO the results are quite comparable, which is impressive considering the Amiga is punching way above its weight here.

The results are impressive, yes, because the Amiga hardware was very limited.

But not comparable; for obvious reasons (if you make side-by-side comparisons).
Quote:

Quote: Better to have spent all that time to something else, IMO. Like what?

I'm not inclined to spend time developing for a retro platform, but if someone really want to do it then porting games that already exist on other, original, platforms is definitely NOT something which I would do.

If someone likes doing games, then a new, Amiga-only, game would be definitely better.

Or... tooling. For example, porting Python which is the most used language. BTW, there's a bounty that I've written for AROS. So, there's also a chance to gain some money

Or... making WHDLoad slaves for games which have issues due to the stupid idiots that haven't followed Commodore's guidelines when writing them.

Or... making such slaves to implement HD loading, support for joysticks/pads with additional buttons, saving score, etc..

That's if someone wants to still develop having as target the Amigas.

Talking about something related, there's the chance to improve the Amiga emulation. So, better / more compatible chipset emulation (albeit Toni did already an excellent job. There might be no room left here!).
Or a much better JIT.
Or embedding Python and start splitting the implementation between the pure 68k and chipset emulation to all other functionalities (for example, implementing the GUI, or the debugger, etc..) adding the possibility to support external plugins written in Python. So, adding the best of the two worlds: the speed of C for the pure emulation with the enormous flexibility / fast / easy development of Python. Think about Sublime Text, if you know it, and you've an idea of what I'm talking about.

Contributions to Emu68 could also be made for similar reasons.

Finally (but because I want to stop here), but not really least, AROS for 68k could be greatly improved. And this will help a lot the Vampire users. Which you should cool, right?
Quote:

This demonstration isn't just about making a better Street Fighter II, it shows techniques that could be used in other games. But even if nobody uses them it was still worth it just to show what could have been done with a bit more time and bigger budget.

Do you want to tell me that all of this effort / time spent is comparable to setting a few registers on the CPS hardware? Just "a bit more time"? Really?!?
Quote:

For some of us just seeing what can be done is entertainment enough.

Not arguing here.

@bhabbott

Quote:

For some of us just seeing what can be done is entertainment enough.

Definitely!

Rules are made to be broken. Hence the demo scene.

There’s a definite cultural aspect to obsessive obedience to rules that I’ve noticed.

@cdimauro

Quote:

Indeed. Because it's important to underline that it wasn't the possibility to directly hit the hardware that was a bad practice. I did it A LOT with my video games (and internal tools).

It was also easy enough for basic access without killing the system. I found I could easily experiment with hitting hardware by just wrapping my code in a Forbid(). And LoadView(0) was useful for setting up the display

Later I got into user copperlists. I found it quite convenient I could write copper code without needing to think about display offsets, window sizes or bitplane pointers. Good for testing ideas.

Quote:

The problem stays on NOT following the guidelines or even common sense, as I've reported above, when doing it. Those aren't old habits rather IDIOTIC habits by stupid people which weren't able to write correct programs.

I think some people didn't want to change either or were just stubborn. But, computers isn't a static profession. So, habitually doing the same methods without refining techniques, is going to break eventually.

I've noticed in OSS code it tends to look rough around the edges. I don't know what sort of training these people have, but sometimes it just looks like a mess. I suppose if you need to get something done you need to rush it. A slight gripe would be code assumed to be on x86 and nothing else. That is, C code that assumes words are backwards, so checks for backwards words looking for IDs. Well, that's just poor C, and goes beyond being portable. It's also unnecessary since an ID can be defined and looked for which works on everything and lets the C compiler figure out byte orders. It's also cleaner looking.

Quote:

Strange. Usually the (post-)Amiga documentation was good.

The description looks fine. But what it lacks is how to piece it all together. All I found was old sprite examples. I could have easily used old sprite routines but the newer ones made it easier. I just pass in a bitmap and it creates a full sprite for me. So, I can text each number into a bitmap, then pass that for each number to create a sprite. But, it still needs 30 sprites, since there are 3 digits of 10 possible numbers so it gets out of hand.

Quote:

Kudos for the effort, but being honest (as usual) it shows how limited was the Amiga platform for videogames, requiring A LOT of time and tricks to achieve some results which are barely comparable.

The Amiga was said to be arcade quality in the early days. It was fine for the time but would be limited a few years later. It at least had unlimited height for sprites. And VSprites could be used to multiplex them, but that complicated it, and they had limitations. At this point having 8 sprites like the C64 wasn't enough. A problem I see is only supporting basic bitmaps in the hardware design and lacking tilemaps. The dual playfield mode also cut the colours down so it was useful but had it's own limitations. And soon enough four layers were desired.

Quote:

Better to have spent all that time to something else, IMO.

I've read that in the A500 era they spent considerable time getting the most out of the hardware with all sorts of tricks. For 50 FPS shooters with hundreds of objects racing around the screen. Just reading about it does my head in.

@Bosanac

Quote:

Bosanac wrote: @bhabbott Quote: For some of us just seeing what can be done is entertainment enough. Definitely! Rules are made to be broken.

Do it in our society and let's see the consequences. Or avoid following the rules on a nuclear plant for controlling the kernel...
Quote:

Hence the demo scene.

So all demo scene is founded on breaking the rules? Is there not a single demo which followed the guidelines?
Quote:

There’s a definite cultural aspect to obsessive obedience to rules that I’ve noticed.

Obsessive? Rules are there not because someone badly woke-up in the morning and decided to set them.

The same happens when code is written: you follow some rules to be sure that your application/game works when something changed on the system.

Many games stopped worked or had problems when I've switched from my Amiga 2000 to 1200: guess why. Same for some applications when the Kickstart changed.

And who is the guilty for that? The dumb idiots that didn't followed the guidelines.

Anyway, you replied about the SF2: are you sure that the developer isn't following the Commodore's guidelines to achieve those results? From the video I haven't seen anything that makes me think so.


@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Indeed. Because it's important to underline that it wasn't the possibility to directly hit the hardware that was a bad practice. I did it A LOT with my video games (and internal tools). It was also easy enough for basic access without killing the system. I found I could easily experiment with hitting hardware by just wrapping my code in a Forbid(). And LoadView(0) was useful for setting up the display Later I got into user copperlists. I found it quite convenient I could write copper code without needing to think about display offsets, window sizes or bitplane pointers. Good for testing ideas.

Indeed. But just Forbid (but I've used Disable) and LoadView weren't enough to kill the o.s. (and bringing it back when I was developing my games or tools). I haven't checked now (because I'm on vacation and I cannot access my PC), but I recall that several things / steps were needed (e.g. I had a longer subroutine).
Quote:

Quote: The problem stays on NOT following the guidelines or even common sense, as I've reported above, when doing it. Those aren't old habits rather IDIOTIC habits by stupid people which weren't able to write correct programs. I think some people didn't want to change either or were just stubborn.

Stubborn, I think, but it's a compliment for certain people.
Quote:

But, computers isn't a static profession. So, habitually doing the same methods without refining techniques, is going to break eventually.

Well, what I learned from the beginning is that computer science requires constant updates and continuous learning.
Quote:

I've noticed in OSS code it tends to look rough around the edges. I don't know what sort of training these people have, but sometimes it just looks like a mess. I suppose if you need to get something done you need to rush it.

Not all OSS code is like that, fortunately, (the CPython code base is quite good) but I share a similar opinion.
Quote:

A slight gripe would be code assumed to be on x86 and nothing else. That is, C code that assumes words are backwards, so checks for backwards words looking for IDs. Well, that's just poor C, and goes beyond being portable. It's also unnecessary since an ID can be defined and looked for which works on everything and lets the C compiler figure out byte orders. It's also cleaner looking.

I agree, but that's a general problem, not strictly related to a language: you can make dirty things even with Python (example: "if x is 7:", without quotes, is a big mistake, despite it USUALLY works).
Quote:

Quote: Strange. Usually the (post-)Amiga documentation was good. The description looks fine. But what it lacks is how to piece it all together. All I found was old sprite examples. I could have easily used old sprite routines but the newer ones made it easier. I just pass in a bitmap and it creates a full sprite for me. So, I can text each number into a bitmap, then pass that for each number to create a sprite. But, it still needs 30 sprites, since there are 3 digits of 10 possible numbers so it gets out of hand.

OK, so there were changes on ExtSprite which aren't immediate from the documentation.
Quote:

Quote: Kudos for the effort, but being honest (as usual) it shows how limited was the Amiga platform for videogames, requiring A LOT of time and tricks to achieve some results which are barely comparable. The Amiga was said to be arcade quality in the early days. It was fine for the time but would be limited a few years later. It at least had unlimited height for sprites. And VSprites could be used to multiplex them, but that complicated it, and they had limitations. At this point having 8 sprites like the C64 wasn't enough. A problem I see is only supporting basic bitmaps in the hardware design and lacking tilemaps. The dual playfield mode also cut the colours down so it was useful but had it's own limitations. And soon enough four layers were desired.

Indeed. The Amiga hardware wasn't much "game-oriented". Rather more workstation-like. So, it was good at the beginning for writing games because the hardware was a quantum step compared to the existing platforms, but its limits soon emerged.
Quote:

Quote: Better to have spent all that time to something else, IMO. I've read that in the A500 era they spent considerable time getting the most out of the hardware with all sorts of tricks. For 50 FPS shooters with hundreds of objects racing around the screen. Just reading about it does my head in.

I know. Keeping Fightin' Spirit working at 25FPS (most of the time) moving all that graphic was a big challenge. And USA Racing wasn't that different for running at 50FPS with all that stuff.

I would have been trivial with some console, since they had proper hardware...

@cdimauro

Quote:

Indeed. But just Forbid (but I've used Disable) and LoadView weren't enough to kill the o.s. (and bringing it back when I was developing my games or tools). I haven't checked now (because I'm on vacation and I cannot access my PC), but I recall that several things / steps were needed (e.g. I had a longer subroutine).

No it wouldn't kill the OS. But I wanted to bring it back when I was finished. Also Disable is said to be unsafe for a long time. I found LoadView was useful as it could reset the display hardware to a default state. When I upgraded to an A1200 ProTracker broke as the screen was all garbled. So I wrote a simple command called LoadECS that simply called LoadView(NIL). I ran this before running PT and all was well again. I meant to upload all the little stuff I've written over the years.

What I am impressed with is tools like WHDLoad being able to exit a game and bring back the OS. Of course they do patch the game to an extent. But the game still needs to take over. What I don't understand is why WHDLoad needs Kickstarts for games. It already hacks the game code so don't know get that why it's made to be more complicated.

Quote:

Stubborn, I think, but it's a compliment for certain people.

Ha.

Quote:

Well, what I learned from the beginning is that computer science requires constant updates and continuous learning.

Any user running Windows is familiar with software updates without a degree in computer science!

Quote:

Not all OSS code is like that, fortunately, (the CPython code base is quite good) but I share a similar opinion.

I think it's just that I am picky. I like things to be clean looking, be that code, or anything else in life. Now, I don't have a degree in computer science, so I'm not looking from a professional perspective and may be expecting too much.

I've been accused of having OCD. I can understand but it's certainly not true. This room is a mess! I think OCD is a good way to be. Keeping the world a neater place.

Quote:

I agree, but that's a general problem, not strictly related to a language: you can make dirty things even with Python (example: "if x is 7:", without quotes, is a big mistake, despite it USUALLY works).

Different, but somewhat reminds me of floating point comparisons, where a value can be rounded to a whole value for comparison to an integer but fail in some cases.

In the ID case, it was only that I recalled Amiga code from 20 years back or so, that used the MAKE_ID macro. This was in big endian code that didn't need to be portable, so perhaps it wasn't so commonly used. But, I tested the macro and found the opposite worked well, that in little endian specific code it had the effect of making it compatible to big endian and thus portable. It also looks cleaner and easier to understand.

Quote:

OK, so there were changes on ExtSprite which aren't immediate from the documentation.

Yes. What's also missing is how to display any sprite. So, you allocate sprite data and get a free sprite from the pick. Now what? So it's rather vague on that. And then how to remove it from screen? Just free it or what? Change sprite to a NULL pointer? So it's lacking in this basic information. This goes for all sprite functions.

Quote:

Indeed. The Amiga hardware wasn't much "game-oriented". Rather more workstation-like. So, it was good at the beginning for writing games because the hardware was a quantum step compared to the existing platforms, but its limits soon emerged.

Sometimes I wonder how they made it simple in some places but complicated in others. For example using PCM sound simplified it somewhat as it didn't need a fancy FM synth, but some FM sound chips had 32 channels, and the rarely used AM and FM Paula did support used two channels. Then there is just using bitmaps with no support for text modes popular in the day. But the sprites stored X/Y across sprite data, had limited colours and shared palette.

Quote:

I know. Keeping Fightin' Spirit working at 25FPS (most of the time) moving all that graphic was a big challenge. And USA Racing wasn't that different for running at 50FPS with all that stuff.

A friend likes to play Fightin' Spirit on his CD32. I think he introduced me to it. USA Racing I imagine would be more of a challenge as a racing game needs to update the screen quickly.

Quote:

I would have been trivial with some console, since they had proper hardware...

With lots of sprites and direct X/Y positions no doubt.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Indeed. But just Forbid (but I've used Disable) and LoadView weren't enough to kill the o.s. (and bringing it back when I was developing my games or tools). I haven't checked now (because I'm on vacation and I cannot access my PC), but I recall that several things / steps were needed (e.g. I had a longer subroutine). No it wouldn't kill the OS. But I wanted to bring it back when I was finished.

That's what I did when I've developed my games and tools. I can't always reset the system each time that I had to try if the latest changes worked on, for obvious reasons.
Quote:

Also Disable is said to be unsafe for a long time.

AFAIR only if you change / use a specific timer on one of the CIAs. Which I haven't done.
Quote:

What I am impressed with is tools like WHDLoad being able to exit a game and bring back the OS. Of course they do patch the game to an extent. But the game still needs to take over.

Sure but, as you said, games are properly patched for this.
Quote:

What I don't understand is why WHDLoad needs Kickstarts for games. It already hacks the game code so don't know get that why it's made to be more complicated.

I think that it's needed to don't make the slave more complex by patching too much those games.

Unfortunately those are games created by the biggest idiots on the Amiga game development scene: depending on the Kickstart version... which is OBVIOUSLY very well known TO CHANGE over the time (learned nothing from the Kickstart loading from disk and its new releases on the Amiga 1000, eh? Dumb idiots!).

And, of course, jumping to specific ROM locations. How much stupid could be a game developer like this?!? Bah...
Quote:

Quote: Not all OSS code is like that, fortunately, (the CPython code base is quite good) but I share a similar opinion. I think it's just that I am picky. I like things to be clean looking, be that code, or anything else in life.

Same for me. I'm so picky that I'm able to put tenths of comments on code reviews for patches where some colleague put a +1 for approval, or even +2...
Quote:

Now, I don't have a degree in computer science, so I'm not looking from a professional perspective and may be expecting too much.

Take one and believe me: a degree would give you a better insight about the fundamental nature of the software, algorithms, and good design patterns, etc.

Yes, you could learn them alone, but the challenges that a degree gives to you will make a better job for acquiring the right mindset.
Quote:

I've been accused of having OCD. I can understand but it's certainly not true. This room is a mess! I think OCD is a good way to be. Keeping the world a neater place.

Who cares: OCD could be useful.
Quote:

Quote: OK, so there were changes on ExtSprite which aren't immediate from the documentation. Yes. What's also missing is how to display any sprite. So, you allocate sprite data and get a free sprite from the pick. Now what? So it's rather vague on that. And then how to remove it from screen? Just free it or what? Change sprite to a NULL pointer? So it's lacking in this basic information. This goes for all sprite functions.

Understood. Maybe you can search for some open source game or tool which is using it, and then take a look. Or ask to Thomas Richter or Olaf Barthel, which could take a look at the sources and give you some insights.
Quote:

Quote: Indeed. The Amiga hardware wasn't much "game-oriented". Rather more workstation-like. So, it was good at the beginning for writing games because the hardware was a quantum step compared to the existing platforms, but its limits soon emerged. Sometimes I wonder how they made it simple in some places but complicated in others. For example using PCM sound simplified it somewhat as it didn't need a fancy FM synth, but some FM sound chips had 32 channels, and the rarely used AM and FM Paula did support used two channels. Then there is just using bitmaps with no support for text modes popular in the day. But the sprites stored X/Y across sprite data, had limited colours and shared palette.

I agree.

Bad design decisions. Which unfortunately cannot be changed anymore...
Quote:

Quote: I know. Keeping Fightin' Spirit working at 25FPS (most of the time) moving all that graphic was a big challenge. And USA Racing wasn't that different for running at 50FPS with all that stuff. A friend likes to play Fightin' Spirit on his CD32. I think he introduced me to it. USA Racing I imagine would be more of a challenge as a racing game needs to update the screen quickly.

Indeed, because it had to run to 50 FPS. While still moving (very quickly) a lot of stuff on the screen.

@cdimauro

Quote:

That's what I did when I've developed my games and tools. I can't always reset the system each time that I had to try if the latest changes worked on, for obvious reasons.

The Amiga was generally fast at rebooting. But resetting the system each time would be annoying and unproductive.

Quote:

AFAIR only if you change / use a specific timer on one of the CIAs. Which I haven't done.

So that was it. I didn't see that noted in the auto docs. Thanks.

Quote:

I think that it's needed to don't make the slave more complex by patching too much those games.

Well, WHDLoad is an integrated system, so I would have expected common routines to be patched so it calls an internal WHDLoad function to do the work.

Quote:

Unfortunately those are games created by the biggest idiots on the Amiga game development scene: depending on the Kickstart version... which is OBVIOUSLY very well known TO CHANGE over the time (learned nothing from the Kickstart loading from disk and its new releases on the Amiga 1000, eh? Dumb idiots!). And, of course, jumping to specific ROM locations. How much stupid could be a game developer like this?!? Bah...

LOL. If it's in Exec then a jump table is right there. But, I don't get why they would do it, if they are going to kill the system anyway. Doesn't make sense to me.

But, what I don't really understand, is not using the free lunch given at boot. What I mean by free lunch, is, that Exec leaves an IO request in A1 that can be used to read in more disk blocks. Likely the rest of the track in standard format then the code can take over and go custom.

Quote:

Same for me. I'm so picky that I'm able to put tenths of comments on code reviews for patches where some colleague put a +1 for approval, or even +2...

Ha. My own code doesn't have too many comments, that is, not to the point that every line had a comment. But I do tend to comment above functions. Unless they are trivial and self explanatory by the function name. But, I don't share stuff, unless it's open source, so I can look back five years later and wonder what on earth some function is doing.

Quote:

Take one and believe me: a degree would give you a better insight about the fundamental nature of the software, algorithms, and good design patterns, etc.

I imagine it would. I always wanted to get into computers but ended up following in the footsteps of my father and becoming a house painter. We had a good relationship and we were still painting together when dad wanted to come along. Now dad's gone, suddenly passing away late last year, I feel kinda lost despite getting back to it. But early on, dad could see something in me, when he found me printing off reams of machine code from my C16 and knew I understood it. My mum, however, wanted to know why I couldn't just play games like all the normal kids. She bought me a C16, not a C64, didn't she know?

Quote:

Who cares: OCD could be useful.

Yes I think it can.

Quote:

Yes, you could learn them alone, but the challenges that a degree gives to you will make a better job for acquiring the right mindset.

I can't escape the tag of amateur developer. Since I only do it as a hobby and am self taught like a lot of 80's kids. But I have noticed, especially in later years, that I am lacking in certain disciplines and speed which can hold my work back. It could even be getting stuck on a simple problem, or a simple typo throwing the compiler way off, that I get stuck for too long. Something that coders would see with coder muscle memory, and I would have as well when I was younger, but now I'm getting older my brain isn't as sharp as it used to be.

Quote:

Understood. Maybe you can search for some open source game or tool which is using it, and then take a look. Or ask to Thomas Richter or Olaf Barthel, which could take a look at the sources and give you some insights.

Yes that would help. I'm on EAB as well. I've spent so much time on OS4 stuff I forget where the OS3 coders hang out. I got it to the point of sprites displaying, But I've done something wrong when freeing the sprite data. It could even be order though thought I had freed sprites before screen is closed. See, years ago I would have found this already, but for now I've just left it.

Quote:

I agree. Bad design decisions. Which unfortunately cannot be changed anymore...

Thanks. The Vampire is trying to change that. But that's in its own private Idaho.

Quote:

Indeed, because it had to run to 50 FPS. While still moving (very quickly) a lot of stuff on the screen.

I'll find a video of it.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: I think that it's needed to don't make the slave more complex by patching too much those games. Well, WHDLoad is an integrated system, so I would have expected common routines to be patched so it calls an internal WHDLoad function to do the work.

I think that the problem is that you should rewrite & integrate the Kickstart code which is called by those lame games. Rewrite, because you cannot just copy & adapt them on WHDLoad, for copyright reasons.

That could be too much effort, hence the idea of directly loading the proper Kickstart.
Quote:

Quote: Unfortunately those are games created by the biggest idiots on the Amiga game development scene: depending on the Kickstart version... which is OBVIOUSLY very well known TO CHANGE over the time (learned nothing from the Kickstart loading from disk and its new releases on the Amiga 1000, eh? Dumb idiots!). And, of course, jumping to specific ROM locations. How much stupid could be a game developer like this?!? Bah... LOL. If it's in Exec then a jump table is right there. But, I don't get why they would do it, if they are going to kill the system anyway. Doesn't make sense to me.

Same for me: a complete non sense. That's why they were stupid idiots.
Quote:

But, what I don't really understand, is not using the free lunch given at boot. What I mean by free lunch, is, that Exec leaves an IO request in A1 that can be used to read in more disk blocks. Likely the rest of the track in standard format then the code can take over and go custom.

I know. I don't recall now if I've used it, or my custom trackloader was short-enough to be contained in the 1kB boot loader.

Anyway, that was the way to safely and (o.s.) friendly load additional sectors if it was needed by the game (or demo).
Quote:

Quote: Same for me. I'm so picky that I'm able to put tenths of comments on code reviews for patches where some colleague put a +1 for approval, or even +2... Ha. My own code doesn't have too many comments, that is, not to the point that every line had a comment. But I do tend to comment above functions. Unless they are trivial and self explanatory by the function name.

Hum. I add the right / needed comments to my code.

In theory we should put NO comments at all in the code, because it should always be self-explanatory and fully (unit; at least) tested. But that's a bit extreme in the real world.
Quote:

But, I don't share stuff, unless it's open source, so I can look back five years later and wonder what on earth some function is doing.

I don't have to wait that long to recognize that I don't like my code: I'm always not satisfied.

Fortunately I don't write much code anymore, since I've switched to a manager role. Problem "solved"...
Quote:

Quote: Take one and believe me: a degree would give you a better insight about the fundamental nature of the software, algorithms, and good design patterns, etc. I imagine it would. I always wanted to get into computers but ended up following in the footsteps of my father and becoming a house painter. We had a good relationship and we were still painting together when dad wanted to come along. Now dad's gone, suddenly passing away late last year, I feel kinda lost despite getting back to it. But early on, dad could see something in me, when he found me printing off reams of machine code from my C16 and knew I understood it. My mum, however, wanted to know why I couldn't just play games like all the normal kids. She bought me a C16, not a C64, didn't she know?

Hey, more or less similar situation with me. I lost some years because I decided to start working to be come more independent and I got my degree only years late, when I "needed the paper" to find a better job.

And my first computer was Plus4: the C16 bigger brother...
Quote:

Quote: Yes, you could learn them alone, but the challenges that a degree gives to you will make a better job for acquiring the right mindset. I can't escape the tag of amateur developer. Since I only do it as a hobby and am self taught like a lot of 80's kids. But I have noticed, especially in later years, that I am lacking in certain disciplines and speed which can hold my work back. It could even be getting stuck on a simple problem, or a simple typo throwing the compiler way off, that I get stuck for too long. Something that coders would see with coder muscle memory, and I would have as well when I was younger, but now I'm getting older my brain isn't as sharp as it used to be.

It's also difficult for me, because I'm getting older. But some people got a degree well above 80 years old, so there's hope.
Quote:

Quote: I agree. Bad design decisions. Which unfortunately cannot be changed anymore... Thanks. The Vampire is trying to change that. But that's in its own private Idaho.

No, unfortunately the Vampire made the things even worse, by just patching the chipset (and processor) based on the contingent needs. So, there was/is no good vision about the design.

Anyway, I don't want to open another door. I already has several discussions in the past, and that's enough for me: it's my personal opinion as computer architectures passionate.
Quote:

Quote: Indeed, because it had to run to 50 FPS. While still moving (very quickly) a lot of stuff on the screen. I'll find a video of it.

There's no video. Only some screenshots on some reviews of a few old videogame magazines.

And some information on a more recent ARS Technica article: https://arstechnica.com/gaming/2010/06/shadow-of-the-16-bit-beast-an-amiga-gaming-retrospective/

LET'S END THIS BANTER ONCE AND FOR ALL WITH THE WORD OF OUR LORD AND SAVIOR

DAVID DOYLE

WHOM ORIGINALLY FOUNDED AMIGAWORLD.NET


DAVID DOYLE SAYS...






/MEGA!

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

@Hypex

Quote:

Hypex wrote: What's also missing is how to display any sprite. So, you allocate sprite data and get a free sprite from the pick. Now what? So it's rather vague on that. And then how to remove it from screen? Just free it or what? Change sprite to a NULL pointer? So it's lacking in this basic information. This goes for all sprite functions.

Just take a course in computer science and it will all become clear. ;)

Quote:

Indeed. The Amiga hardware wasn't much "game-oriented". Rather more workstation-like. So, it was good at the beginning for writing games because the hardware was a quantum step compared to the existing platforms, but its limits soon emerged.

The Amiga was designed to be a games machine, but with computing capabilities too - just like all the other home computers of the day. But they decided to put a 68000 in it (an excellent decision as it really was a 'quantum leap' over 8 bit CPUs), and then got carried away with an efficient multitasking kernel and GUI OS. It was still a toy though, not a workstation.

Quote:

Sometimes I wonder how they made it simple in some places but complicated in others. For example using PCM sound simplified it somewhat as it didn't need a fancy FM synth, but some FM sound chips had 32 channels,

When you say 'fancy FM synth' you pretty much mean Yamaha, which patented the technology in the 1970s. They developed it for synthesizer keyboards or 'electronic pianos', which needed a lot of channels to emulate a real piano.

In 1983 (when the Amiga was being designed) the only computer sound chips Yamaha made were the YM2149 (a clone of the General Instruments AY-3-8910, which had 3 channels of square waves, not FM), and the YM2151 which had 8 channels of basic FM synthesis. FM sound chips with 32 channels were not considered for inclusion in the Amiga because they didn't exist, and creating one from scratch would be problematic legally.

Other home computers of the day had a variety of sound systems ranging from a single bit-banged I/O pin (ZX Spectrum) or programmable timer output (PC 'speaker'), a proprietary sound generator (Atari Pokey, Commodore SID), or one of the few off-the-shelf square wave sound chips available (GI AY-3-18910, Ti SN76489), all of which were very limiting. In comparison the Amiga's 4 channels of PCM sound were a quantum leap forward because they could reproduce any sound with excellent fidelity and minimal system loading.

Would 8 or 32 channels have been better? Sure (apart from the cost), but 4 channels was already more than other machines had, with vastly more realistic sound. It was the ability to play multiple sampled sounds at once that gave the Amiga the edge over sound systems that were limited to cheesy synthesized music. That can easily be extended to 8 channels with small CPU loading if you can be bothered. Other systems could maybe play one channel of PCM sound at very low fidelity with 100% CPU loading.

Quote:

Then there is just using bitmaps with no support for text modes popular in the day.

Perhaps you are forgetting the other popular home computers that didn't have a text mode, such as the Sinclair ZX Spectrum, Acorn Electron and Amstrad CPC series. Of course if you wanted a GUI then bitmap graphics was essential. Machines with text mode as their primary display generally had poor bitmap graphics which was not well supported in the OS, if at all. This lack of proper bitmap graphics was keenly felt by users who wanted more than plain text. It was pretty much the only reason that PC users ran Windows.

Quote:

But the sprites stored X/Y across sprite data, had limited colours and shared palette.

Hardware limitations are a bummer, but such is life when you are producing something to a price. The Amiga only had a 32 color CLUT, so sprites had to share it. The upper 16 colors were used to make this less onerous. Limited colors per sprite etc. is simply a result of limited silicon. Most other popular home computers of the day either had no sprites at all or a single color per sprite. The Amiga had a blitter to render objects so it didn't suffer from the extreme CPU load of other bitmap based systems, and didn't need to rely on sprites for efficient animation.

Hindsight is 20/20 of course, but this constant denigration of the Amiga's design without consideration of when and why it was developed and the constraints it was limited by really annoys me. It wasn't perfect, but what was? You say 'its limits soon emerged'. The Amiga's hardware limits were spelled out from day one, published in the hardware reference manual. What did 'emerge' is relatively poor OS support for games. But it was always intended to be programmed 'bare metal' for games, just like other home computers and gaming consoles etc. OS support in most home computers was limited to setting the screen mode and perhaps some BASIC commands, after that you were on your own.

It was a bit more problematic on the Amiga due to the multitasking OS and complex hardware it controlled, which requires some care to maintain. That is why coders often kicked out the OS as soon as possible and did everything themselves, then all they had to understand was how the hardware worked. Of course this soon lead to compatibility issues when new hardware was released and people wanted hard drives etc. that required a working OS.

The Amiga was not alone in this. Even PC users suffered from it, which why the phrase '100% IBM compatible' quickly became so important to them. My first experience of this was when I bought a 'Genius' serial mouse for my IBM JX. The driver wouldn't work because instead of letting the OS set the baud rate it poked the hardware registers directly. But the JX (like the PC Jr) has a different baud rate generator clock frequency from the PC. The PC didn't get proper OS support for games until 1995 with Direct X. Most home computers never had it.

Perversely, the Amiga's multitasking OS with graphics support makes it more difficult for programmers who just skim the reference manuals and expect 'bare metal' performance via OS functions. This is possible, but still requires a good understanding of the hardware and the OS. If Commodore had given us a lesser single-tasking OS like TOS or MSDOS, nobody would be complaining!

Last edited by bhabbott on 09-Sep-2022 at 07:07 PM.
Last edited by bhabbott on 09-Sep-2022 at 07:05 PM.
Last edited by bhabbott on 09-Sep-2022 at 07:04 PM.

@bhabbott

Quote:

bhabbott wrote: @Hypex Hypex wrote:

Please properly use quotes, because you reported and replied also to my writings instead of (only) Hypex.
Quote:

Quote: Indeed. The Amiga hardware wasn't much "game-oriented". Rather more workstation-like. So, it was good at the beginning for writing games because the hardware was a quantum step compared to the existing platforms, but its limits soon emerged. The Amiga was designed to be a games machine,

Only because 8 sprites where added?
Quote:

but with computing capabilities too - just like all the other home computers of the day.

It was a personal computer. In fact, it was also very expensive. Whereas home computers of the time were much cheaper and usually standalone (e.g. the computer was integrated with the keyboard).
Quote:

But they decided to put a 68000 in it (an excellent decision as it really was a 'quantum leap' over 8 bit CPUs),

Commodore should have used the 68010, instead. At least some issues could have been solved.
Quote:

and then got carried away with an efficient multitasking kernel and GUI OS. It was still a toy though, not a workstation.

In fact I was talking about and only the hardware and said that it was "workstation-like".
Quote:

Quote: Sometimes I wonder how they made it simple in some places but complicated in others. For example using PCM sound simplified it somewhat as it didn't need a fancy FM synth, but some FM sound chips had 32 channels, When you say 'fancy FM synth' you pretty much mean Yamaha, which patented the technology in the 1970s. They developed it for synthesizer keyboards or 'electronic pianos', which needed a lot of channels to emulate a real piano. In 1983 (when the Amiga was being designed) the only computer sound chips Yamaha made were the YM2149 (a clone of the General Instruments AY-3-8910, which had 3 channels of square waves, not FM), and the YM2151 which had 8 channels of basic FM synthesis. FM sound chips with 32 channels were not considered for inclusion in the Amiga because they didn't exist, and creating one from scratch would be problematic legally. Other home computers of the day had a variety of sound systems ranging from a single bit-banged I/O pin (ZX Spectrum) or programmable timer output (PC 'speaker'), a proprietary sound generator (Atari Pokey, Commodore SID), or one of the few off-the-shelf square wave sound chips available (GI AY-3-18910, Ti SN76489), all of which were very limiting. In comparison the Amiga's 4 channels of PCM sound were a quantum leap forward because they could reproduce any sound with excellent fidelity and minimal system loading. Would 8 or 32 channels have been better? Sure (apart from the cost), but 4 channels was already more than other machines had, with vastly more realistic sound.

Yes, it would have been much better to have 8 channels instead of 8 sprites. 8 audio channels and 4 sprites would have been way more useful.
Quote:

It was the ability to play multiple sampled sounds at once that gave the Amiga the edge over sound systems that were limited to cheesy synthesized music.

Unfortunately PCM sound required memory: MUCH MORE memory compared to synthesized music.

On a system where chip ram wasn't that much and the chipset was able to access to ONLY this kind of memory.
Quote:

That can easily be extended to 8 channels with small CPU loading if you can be bothered.

Absolutely not true on a 7Mhz 68000 system. Otherwise many game would have used it, since 4 channels aren't certainly enough for both music and sfx.
Quote:

Other systems could maybe play one channel of PCM sound at very low fidelity with 100% CPU loading.

So, let me recap: audio mixing was very cheap on a 7Mhz 68000 but super mega (not RJ) expensive on other systems. Are you talking about a Commodore 64, ZX Spectrum, etc. as such systems?
Quote:

Quote: But the sprites stored X/Y across sprite data, had limited colours and shared palette. Hardware limitations are a bummer, but such is life when you are producing something to a price. The Amiga only had a 32 color CLUT, so sprites had to share it. The upper 16 colors were used to make this less onerous. Limited colors per sprite etc. is simply a result of limited silicon. Most other popular home computers of the day either had no sprites at all or a single color per sprite. The Amiga had a blitter to render objects so it didn't suffer from the extreme CPU load of other bitmap based systems, and didn't need to rely on sprites for efficient animation.

Unfortunately using BOBs means that you had to use the planar graphic which is wasting a lot of space and bandwidth compared to packed graphic, for complex operations like cookie-cut.
Quote:

[quote]Hindsight is 20/20 of course, but this constant denigration of the Amiga's design without consideration of when and why it was developed and the constraints it was limited by really annoys me. It wasn't perfect, but what was? You say 'its limits soon emerged'. The Amiga's hardware limits were spelled out from day one, published in the hardware reference manual. What did 'emerge' is relatively poor OS support for games. But it was always intended to be programmed 'bare metal' for games, just like other home computers and gaming consoles etc. OS support in most home computers was limited to setting the screen mode and perhaps some BASIC commands, after that you were on your own. It was a bit more problematic on the Amiga due to the multitasking OS and complex hardware it controlled, which requires some care to maintain. That is why coders often kicked out the OS as soon as possible and did everything themselves, then all they had to understand was how the hardware worked. Of course this soon lead to compatibility issues when new hardware was released and people wanted hard drives etc. that required a working OS.

That's simply because those developers were a bunch of stupid idiots that never opened or understood the Amiga Hardware Reference Manual and followed its guidelines.
Quote:

The Amiga was not alone in this. Even PC users suffered from it, which why the phrase '100% IBM compatible' quickly became so important to them. My first experience of this was when I bought a 'Genius' serial mouse for my IBM JX. The driver wouldn't work because instead of letting the OS set the baud rate it poked the hardware registers directly. But the JX (like the PC Jr) has a different baud rate generator clock frequency from the PC.

That's the reason why the JX and PC JR were NOT PCs. So, not PC-compatible.
Quote:

The PC didn't get proper OS support for games until 1995 with Direct X. Most home computers never had it.

You "forgot" the VESA standard (stan...dard. Do you know?) which came before the '90s. And Windows GDI.
Quote:

Perversely, the Amiga's multitasking OS with graphics support makes it more difficult for programmers who just skim the reference manuals and expect 'bare metal' performance via OS functions. This is possible, but still requires a good understanding of the hardware and the OS. If Commodore had given us a lesser single-tasking OS like TOS or MSDOS, nobody would be complaining!

Well, the thing is that you cannot use the o.s. because you'll lose a lot of performances and memory. So, to squeeze the most of the system you had to kill the o.s. and DIY everything (reinventing the wheel).

On PCs the o.s. was ultralightweight for obvious reasons and it wasn't needed to kill it. However, developing games was more or less bare metal, while still keeping the basic o.s. functions which were very useful.

@cdimauro

Quote:

I think that the problem is that you should rewrite & integrate the Kickstart code which is called by those lame games. Rewrite, because you cannot just copy & adapt them on WHDLoad, for copyright reasons.

I considerer this somewhat redundant since every Amiga running WHDLoad has a Kickstart. Like Snipes said in Blade 3, about 3 times; use it, use it, use it. But they don't. They won't They shon't.

It makes it harder to install. I must have spent one or two hours installing the damn thing on my A4000. Tracking down every Kickstart I needed and then the extra Kickstart files. Downloading all this crap and copy it over until the errors stop. Sheesh! I just wanted to play a simple game! I almost went back to floppy. It would have loaded faster!

Quote:

That could be too much effort, hence the idea of directly loading the proper Kickstart.

Too much effort for the programmers so force the user to locate a bunch of pirated ROM files and then some.

Quote:

Anyway, that was the way to safely and (o.s.) friendly load additional sectors if it was needed by the game (or demo).

Related. I also simulated it. Tired of needing to reboot when ever I wanted to run a game or bootblock I wrote my own loader. RunBB. For Run BootBlock. Was easy to do. Reduced game reboots to one reboot after.

Quote:

In theory we should put NO comments at all in the code, because it should always be self-explanatory and fully (unit; at least) tested. But that's a bit extreme in the real world.

Interesting. Bare bones commenting. Must try this one.

I have a couple of friends in my code project. Their names are MarkTempo() and MarkSplit(), I know what they mean to me.

Quote:

I don't have to wait that long to recognize that I don't like my code: I'm always not satisfied.

Richard Marx could have a theme song for your code.

Quote:

Fortunately I don't write much code anymore, since I've switched to a manager role. Problem "solved"...

Ha.

Sometimes I find all the projects I've created exhausting. Because I need to keep them updated and I know what more they need and what my roadmap is for them. But no one else is going to code all my ideas for me or if even they did they wouldn't do it right.

So I have an old memory. I have some computer book from years ago, looked past it when I was in my 20's. It spoke about System Analysts which would be an old term now but Google still knows it. I recall it explained it something like being above a developer, a managerial position, where other people coded. But at the time I thought, no, I'd never want to give up the coding. However, now I imagine I would also feel fortunate, if I had ended up working in the field.

Quote:

And my first computer was Plus4: the C16 bigger brother...

I'll avoid another story. So I first wanted a C64 as all my friends had one. But I ended up with a C16 and was converted. Somehow after the C16 the Plus/4 became my dream computer. I recall one local holiday we went to a bulk store and they had stacked boxes of Plus/4 computers. Price must have been good. I said we have to get one now. My mum said to leave it and we'll get one on the way back. Bad idea. Come back and they were all gone. Typical. Mum stiffed me again!

Also, I think of the C16, and more so for the Plus/4, as a programmers computer. It had the built in monitor and simple assembler. For what it lacked in the games department it made up for in coding. Sure, you can buy a monitor and assembler for a C64, but you needed to buy a floppy drive first to load it off and wait for it to load, unless there was a cartridge. The C16 had it built in, ready to go, seconds after power on. We know what happened to the music industry when Atari put midi ports on the ST and Commodore didn't put them on the Amiga. Having built in makes all the difference.

Quote:

It's also difficult for me, because I'm getting older. But some people got a degree well above 80 years old, so there's hope.

Yes there is. A friend tells me I should study as uni is full of women. Most practical advice I've ever had I think. A degree and dating. Two birds with the one stone!

Quote:

No, unfortunately the Vampire made the things even worse, by just patching the chipset (and processor) based on the contingent needs. So, there was/is no good vision about the design.

The Vampire gives people what they want. A computer that is compatible with those Amiga games. This is why the AmigaOne series failed, because they dropped any Amiga hardware chipsets and replaced it with a more practical and up to date solution. So when Amiga people find out, they don't understand what the point of it is, because it can't load all their old A500 floppy games. A Vampire SA can't load floppy games either but some how it's still better because the AGA compatibility.

Quote:

There's no video. Only some screenshots on some reviews of a few old videogame magazines.

I didn't realise I typed too soon. I soon found out about the lack of videos.

Quote:

And some information on a more recent ARS Technica article:

Good. Thanks. I particularity liked this in the opening:
Even the younger and smaller computer game industry had moved far beyond Roberta Williams putting floppy disks into ziplock bags and answering phone calls from players in her kitchen.

Was she running a dating business!?

So the 320 x 240 screen was a stand out. Thought I was reading about a PC game after that. But it had to be single buffered. And used display lists. They didn't include pictures.