News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Was the firmware a "good thing"

Started by steve, 13:28, 23 December 10

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

steve

In my mind the Firmware was one of the features that made the CPC better than the spectrum, but I get the impression that most commercial software did not use it, so, except for "bedroom programmers", was it a "good thing" to have or a waste of time, money and resources on Amstrad's part.

arnoldemu

Quote from: steve on 13:28, 23 December 10
In my mind the Firmware was one of the features that made the CPC better than the spectrum, but I get the impression that most commercial software did not use it, so, except for "bedroom programmers", was it a "good thing" to have or a waste of time, money and resources on Amstrad's part.
good question.

I used to think that the firmware was bad, it should be avoided, it is slow.

But more recently, I have accepted that it's quite good, and can often save a lot of development time.

It is true that going direct to the hardware, and avoiding some of the firmware drawing functions will make your program faster, but if that is not so important, the firmware is actually good.

Knowing it well and knowing what it is doing, allows you to make a choice about which function to use, and possibly how to get more speed or what you want out of it.

I think the way it is structured, the jumpblock, the cleanness of it, it is actually a nice design.

In addition you can patch some functions, and so you can almost make it do as you want if you need to. (e.g. my 6 pixel wide font example)

In a new project I am working on, I do use the firmware for setting colours, mode and for loading.
The loading is done using the firmware so that the project could be hosted on different media (e.g. the sdcard hardware I wish for - not the one that emulates a floppy ;) ), and as long as the appropiate load functions are patched, it will run ok.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

AMSDOS

It's good that it exists and it's well documented and if applied properly can be an useful thing to apply in games and stuff.

But when I did a sweep though something like Tank Busters (circa 1984/5) from Design Design software, I couldn't find anything which would resemble firmware!  ???  This game runs at a blistering pace with it's Wire-Frame Graphics continous movement of Tanks, objects, mountains and even the Volcano in the backdrop can have it's rate of explosion changed through the menu!! It just makes we shiver!  :-[  Many AMSOFT games could be considered as being on the list for using Firmware and there's some which use Firmware to good effect - Blagger and Roland in Time could be examples of that, in the use of colour rotation.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

fano

I am not a fan of the CPC firmware as i overwrite it at start  :laugh:
But i must admit it is very good thing.You can do a lot of thing with it and it is stable , reliable and easily extensible.
Binded with Basic , it was very powerfull and made CPC a great machine to start learning computing.I think it has something to do with CPC succes (with some other things too)
I think other 8bits users should envy us for this :)
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

redbox

I think the firmware was a great idea.  It allowed people to quickly understand how the CPC worked and you could either use it verbatim (i.e. just make the calls) or disassemble it to see how specific functions were written.

I know the mantra is to avoid it as a programmer but that is because we have come so far.  It still works well for a quick routine that doesn't require speed, and if I want to do something that I have no idea about you can start there.

I remember reading it was a conscious decision to include it in the CPC because they realised that software was the key to a platforms success and they didn't want programmers to have many barriers to writing code.  Conversely it meant that most early titles were cr*p!

andycadley

It's certainly a much better design than the spectrum, where you're forced to jump into random addresses within the ROM and patching/modifying the ROM is difficult and leads to strange compatibility issues. It's also a lot faster than the Sinclair code, largely because it wasn't crammed to fit into 16K (and bits of the speccy ROM were originally made to fit into the 8K ROM of the ZX80/81).
Of course it's generally too slow for arcade games, but then that's true of pretty much any 8 bit machine. In those cases you're going to end up writing optimised routines regardless of what the system provides. For application software, however, the firmware design is superb.

cpcitor

Old thread here. :-)

To me, yes definitely, firmware was a good thing because it made the Amstrad CPC that friendly machine with a well-thought and fast Basic with well-integrated graphics, sound, real-time API (we didn't call that API at the time but it is).

Benefits of firmware have been made explicit here: available, robust, somehow flexible (with jumpblock and indirections overwriting, and also by being open to alternate ROMs that can provide alternative packs like PARADOS).

Slowness is not a factor for one-time setup.

Incidentally, exploiting the firmware -- as far as it comes handy and is good enough -- has been a focus in the early development of GitHub - cpcitor/cpc-dev-tool-chain: A development toolchain to compile your C or assembly projects on a modern OS and run your compiled projects on an Amstrad CPC or emulator..

Prods based on firmware, even if fully written in C for example without effort about style, get that firmware-style, like Color Flood shown in
https://youtu.be/2-Qg3beL8ZI?t=1661

cpc-dev-tool-chain was used by many projects in the early years of #CPCRetroDev. CPCTelera then forked from it, adding sprite and music routines, and those are killer features when making a platform game or 2D shoot-them-up.

To me, things have settled for now and won't change: devs use firmware mostly at load time, then either continue to use it if style and speed are okay, or switch to dedicated routines if styles and/or speed are a concern. Until all this becomes definitely outdated.

Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

GUNHED

The firmware was obviously made by 8080 coders. So they didn't use all of the Z80 features. A major drawback is that they occupied die 2nd register set for interrupts, which is not needed. No serious Z80 system does that (look at all the US CP/M machines for example). But aside of that the firmware is a great piece of coding, runs really stable and known bugs are very very few.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Bryce

They should have socketed the Firmware ROM to allow upgrades / bug fixes. Especially as the chip held both the Firmware and BASIC.

Bryce.

arnoldemu

Quote from: GUNHED on 12:15, 28 November 17
The firmware was obviously made by 8080 coders. So they didn't use all of the Z80 features. ...
Please can you point to the code in the OS that shows this?
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

#10
One thing they should have done was a way to patch the firmware jumpblock with a jump to a rom.

An example of where this is needed is the amsdos rom.

Here they allocate some ram. The firmware jumps to the ram, then jumps to the rom from there. In the rom they decide which function was called and then re-direct to the rom function.

This is messy. If they had provided an RST that did a rom jump this would have worked nicely.

The AMSDOS rom doesn't seem to follow their design, it's not as cleanly designed and put together compared to the the firmware. They got much closer with the +3 disc functions. The functionality here is much better than on the CPC and is what the CPC AMSDOS should have had.

EDIT: I think it could have been as simple as:

4 bits rom number, 12 bits offset into rom.

OR

8 bits rom number, 8 bits function number. (function number * 3 and jumped direct into the rom jumpblock).
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

khaz

Quote from: Bryce on 12:33, 28 November 17
They should have socketed the Firmware ROM to allow upgrades / bug fixes. Especially as the chip held both the Firmware and BASIC.

Has there been attempts to patch and upgrade the firmware?

Sykobee (Briggsy)

I have often wondered why the CPC has never seen improved Firmware or custom BASIC versions as replacement ROMs. Sure, back in 1984 48KB of ROM was being generous, and then Amstrad penny pinched ever after, but...


This seems to happen on other 8-bit machines.


It'd be neat to see a CPC with, e.g., a firmware that incorporated CPCTelera functions, and a BASIC that could hook into these. Or 8bp in ROM with native BASIC commands instead of RSXs.

Bryce

Quote from: khaz on 15:36, 28 November 17
Has there been attempts to patch and upgrade the firmware?

Yes, Firmware 3.1 which I use most of the time: http://www.cpcwiki.eu/index.php/Firmware_3.1

Bryce.

khaz

#14
Quote from: Bryce on 15:47, 28 November 17
Yes, Firmware 3.1 which I use most of the time: http://www.cpcwiki.eu/index.php/Firmware_3.1

Ah, yes, Toto's firmware. I have an X-MEM but I forgot about it haha.

I don't share Toto's idea of breaking backwards compatibility to allow for extra features. The removal of tape, boot in mode 1, and ù as an RSX character is just too big of a deal for me. He even breaks compatibility with his own hardware, removing the RAM drive feature in the latest (3.15?) version. I stick to the provided 3.14 in the rare case I need it, but otherwise I boot the original firmware.

Kris

Last version is 3.16 but unfortunately no more update for a while....

cpcitor

Quote from: Sykobee (Briggsy) on 15:43, 28 November 17
I have often wondered why the CPC has never seen improved Firmware or custom BASIC versions as replacement ROMs. Sure, back in 1984 48KB of ROM was being generous, and then Amstrad penny pinched ever after, but...

They did make an upgrade. They called it CPC+  ;)

Ironically, they did not improve the firmware with the CPC+ series, which is kind of confession that more work on firmware was not critical for success (+ models were late to the party anyway). And indeed, firmware was good enough for e.g. educational purpose. Working on an improved firmware supporting "+" features would have opened a lot of compatibility challenges, would have fragmented software set (because programs written with + firmware in mind wouldn't have worked on an older CPC) and such big effort wouldn't have resulted in better games or more sales.

Quote from: Sykobee (Briggsy) on 15:43, 28 November 17
This seems to happen on other 8-bit machines.

Can you provide examples?

Quote from: Sykobee (Briggsy) on 15:43, 28 November 17
It'd be neat to see a CPC with, e.g., a firmware that incorporated CPCTelera functions, and a BASIC that could hook into these. Or 8bp in ROM with native BASIC commands instead of RSXs.

It would be neat as a hack value. Practically, I don't see much of a benefit.
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

gerald

Quote from: GUNHED on 12:15, 28 November 17
The firmware was obviously made by 8080 coders. So they didn't use all of the Z80 features. A major drawback is that they occupied die 2nd register set for interrupts, which is not needed. No serious Z80 system does that (look at all the US CP/M machines for example).
Nice contradictions
On one side you complain they did not use Z80 feature.
On the other side you complain they use one of the best Z80 feature : the second register bank, mainly introduced to reduce interrupt latency.
;)

Bryce

Quote from: khaz on 16:00, 28 November 17
Ah, yes, Toto's firmware. I have an X-MEM but I forgot about it haha.

I don't share Toto's idea of breaking backwards compatibility to allow for extra features. The removal of tape, boot in mode 1, and ù as an RSX character is just too big of a deal for me. He even breaks compatibility with his own hardware, removing the RAM drive feature in the latest (3.15?) version. I stick to the provided 3.14 in the rare case I need it, but otherwise I boot the original firmware.
Back compatibility is irrelevant when you can easily switch back to the original firmware with the flick of a switch. Firmware 3.1 is a great piece of code.

Bryce.

Gesendet von meinem Motorola DynaTAC 8000x mit Tapatalk


khaz

Quote from: Bryce on 22:03, 28 November 17
Back compatibility is irrelevant when you can easily switch back to the original firmware with the flick of a switch. Firmware 3.1 is a great piece of code.

Bryce.

Gesendet von meinem Motorola DynaTAC 8000x mit Tapatalk

Oh I never said it wasn't. It does bring some interesting features.

I would disagree with the "easily" flick a switch. It's introducing another action prior to booting, with the user having to ask themselves what feature do they want to use every time they turn on the computer. And every time they want to use the other set, it's a "oh shit" moment where they have to stop what they are doing, flick the switch and restart the computer (potentially losing their work).

As a result, people tend to settle to one and try to use the other as rarely as possible. I stick to the original firmware and only use the new one when I really need it, and you boot the new firmware only unless you need those legacy functions. For both of us, this alternate boot is infrequent at best, and more likely extremely seldom, because we adapted our routines not to need the exclusive functions the other firmware bring.

AMSDOS

Quote from: Bryce on 22:03, 28 November 17
Back compatibility is irrelevant when you can easily switch back to the original firmware with the flick of a switch. Firmware 3.1 is a great piece of code.

Bryce.

Gesendet von meinem Motorola DynaTAC 8000x mit Tapatalk


I would agree with that only if the new Firmware was used in something current now, but instead it looks back to BASIC 1.1, so the Firmware 3.1 page is contradicting itself by saying "Looking the future, not the past".


My recent trails of various Sprite Drivers showed that positioning a Sprite using the firmware is compatible with using a firmware to Roll the Screen (Scroll), it's only setback is a slight reduction in speed as opposed to calculating a position (in assembly) to position the Sprite. Earlier when I tried adjusting a Sprite Driver to adjust the offset for the new screen position, I ended up with something unstable, which would work for a brief time and then crash.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Powered by SMFPacks Menu Editor Mod