Amstrad 1640DD Firmware

[parabyte]

so i decided over a 2 month period to write a reimplimentation of the bios for the amstrad thought i would share here.

I used elks to test its ide driver

xt Bios

and yes this could be modified to work on any xt machine.

[ghaerr]

Wow, @parabyte, you've really gone to town on this!! Very impressive!!

Does BIOS take up the entire 16KB ROM? Compressed?

What exactly does the Examiner decompression code do, is the ROM image decompressed into RAM, not sure what this is for?

It might be interesting to try this in various machines that otherwise use skiselev's 8088-bios. Do you have any of those systems for testing? I'm still reading through your source code which I find very interesting.

[parabyte]

urgh i may have put a typo in the source code im pretty sure thats the Exomizer decompressor you are referring to, classic vintage 8bit decompression technique exceptionally lightweight on resources.

whole idea of compressing the bios was to be able to fit in the floppy and the ide code at the same time. but unfortunately at the moment its 1 or the other, i need to optimize my code more.

The idea in my use case is the ide code is a nice fallback if someone does not have a bootable machine but have a isa card lying around, from testing i found most universal com printer combo cards with ide and floppy seem to mostly work.

the idea of shadow ram is self explanatory really, cant address compressed rom contents. so unfortunately left with 608kb of system ram.

but the whole point of my project is for someone like me who finds it easier playing with C the bios is a lovely toy to play around with.

I got the inspiration of the make system from elks.

As the code is using the gnu tools and not modifying them i think i am okay.

As for testing in a real machine. Soon as my eeprom's arrive from mouser i will cut some adaptor pcb's and test it, very eager to test it in my real machine!

My flavour of machine always been the Amstrad 1640 series

[ghaerr]

What exactly does the Examiner decompression code do

Oops - autocorrect at its finest - I was typing Exomizer and it was changed the Examiner. I'm pretty familiar with Exomizer, it is used to compress/decompress ELKS binaries on compressed images, and the decompressor is built into the kernel exec function.

the idea of shadow ram is self explanatory really, cant address compressed rom contents. so unfortunately left with 608kb of system ram.

How does that work - don't certain system programs expect addresses in the ROM range, rather than a displaced address in RAM?

Does this mean your BIOS runs in an additional 16K+ of real memory, starting at F8FFF, with the FCFFF-FFFFF locations unused? Wouldn't it need more than 16K since the original compressed version was 16K, thus requiring RAM base below F8FFF?

[parabyte]

my thinking was, it decompresses from the rom 16k area, the decrunched data is bigger then the 16k original bios.

The BIOS runs entirely from segment 9000h — physical addresses 0x90000-0x9FFFF. The boot sequence is:

1. CPU hits reset vector at FFFF:0000 → JMP FAR FC00:0000
2. ROM stub at FC00 copies compressed payload to 9000:xxxx, decompresses in-place
3. JMP FAR 9000:0000 — enters bios_reset_entry in RAM
4. SS, DS, ES all set to 9000h; stack at 9000:7C00
5. IVT vectors installed pointing to 9000h segment handlers

Is FC000-FFFFF unused at runtime?

No — the physical ROM is still there and still readable compressed data. The POST checksum routine (post.c:140-152) reads back the ROM at FC00h to verify integrity. And the compatibility trampoline at
FC00:3065 remains live for the video option ROM. But the BIOS executes from 9000h, not FC00h.

[parabyte]

the ROM chip is physically sitting at FC000-FFFFF. Writes to those addresses hit the ROM silicon and are silently ignored. There's no RAM behind that range to decompress into.

Shadow RAM on later machines (386+ chipsets) works because the chipset can electrically disconnect the ROM chip from those address lines and connect RAM instead. The PC1640 has no such
mechanism — it's an 8086 system that was my thinking anyway

[ghaerr]

I see, I get it now, and also understand the business of shadow RAM w/ROM, etc.

TBH, I think it may be a good idea to just try to reduce the amount of code generated so that everything fits in 16K and the system can run from ROM at FCFFF, thus making available 32K more RAM and less complexity. I haven't had time to study the source much yet, but even a just quick review of bios.h shows there's probably a good amount of space to be gained, at the expense of a bit less readability.

[parabyte]

the whole design choices was purely based on trying to fit floppy and ide into the bios. and any extra quality of life improvements, but you do have a very valid point. I may create a fork of my own bios that does not use any compression. and see if i can squeeze all the systems into it, minus ide. I want to make this particular bios very accessable to anyone, and very readable aka easy to understand. again this is all pointing to me making a fork of my own bios.

I am happy with a fork without ide.
or another choice is adapt this bios Specifically tailored to Elks might be able to free up space somehow without the restraint of having to be a standard bios? would help move away elks and its dependency on its current architecture! I am a huge x86 fan so likely not support anything outside of that, but different memory maps, homebrew x86 systems etc,

I am more happy, about the idea to opening up this bios fork with the same licence as elks to bring it in line with elks.

[ghaerr]

With regards to floppy and IDE, what about the idea of having the "standard" BIOS (16k at FC000) including most everything except IDE, and then having an add-on ROM (perhaps 8K at C0000 or CC000 etc) for IDE? This would fit with the idea used for the early IBM XT that had an add-on ROM on the HD controller card, right? In this way it's a more natural split and wouldn't have to use RAM to double the ROM contents after decompressing, etc.

Other ideas could include using your new config system to specify what is included in the upper 16K ROM, so that not everything is dragged in, without having to fork the repo - just keep the same repo and use the config utility(s) to specify what is wanted. It would be nice not having to fork the repo, especially this soon after development.

Along those lines, what could be really cool would be to be able to include an INT 67 LIM into the BIOS or separate option ROM that would handle the missing LIM stuff from your ELKS EMS implementation. Yet another idea would be to include a "loadable" INT 67 LIM implementation, either at boot into RAM or loadable (somehow) from ELKS, when EMS is configured. The source could possibly be shared (to a degree) between ROM and ELKS versions.

So I would think a fork would be unnecessary if more options could be enabled/disabled, in combination with looking for code that could be considerably trimmed down to fit. My quick look shows there's a fair amount that might be able to be reduced in size without losing any functionality.

another choice is adapt this bios Specifically tailored to Elks might be able to free up space somehow without the restraint of having to be a standard bios?

Yes, that could work, ELKS tries to use as little as possible in any BIOS though, so a fine-grained configuration capability should solve that problem. IMO one really wants to keep the "standard" BIOS within the upper 16K for maximum usability across a wide user base.

the idea to opening up this bios fork with the same licence as elks to bring it in line with elks.

Actually I think having a looser license than GPL, which most of ELKS is licensed under, would help others use your BIOS. I would suggest MIT or something more that direction, but that's totally up to you.

It is nice to have almost all the BIOS written in C for reference - this is similar to what was done with SeaBIOS, which is used in QEMU. In that environment, it's potentially less of an issue exactly how big the BIOS ROM is, since it's emulated. You might also look in to how easy it might be to replace QEMU's BIOS with your BIOS, for emulation and testing with ELKS etc.

[parabyte]

Okay having a major refactor I have implimented a driver that can speak to my elks lim code. i literally spent all day on that.
as for project cohesion and supporting more then just the amstrad. taken inspiration from linux itself with a machines folder
first target is 1640dd im stripping all specific code for that and making my drivers all more generic, then my next target is generic xt, final target be the Ibm pc jnr. but that will take time as i need to think about floppy pio. and lack of dma. I do not have any real ibm pc jnr hardware to test this one, but using x86box that i have patched. will push on with that target, but using a emulator for fidelity, less then ideal, but hopefully someone out there with a real machine, can patch out any problems with the various targets. my main verified target is the Amstrad 1640dd.

I have opened up discussion on my bios github page now