- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Has someone written a BIOSGEN
- Thread starter Ragnarock
- Start date
Chuck(G)
25k Member
Too much variation. I can show you a CP/M BIOS that's 4113 lines long. You could probably do this for simple console I/O, but when you get into mass storage, things get different and complicated.
Chuck(G)
25k Member
...if your system uses a 1771. That's probably not the majority of them. My BIOS also uses an Intel 8275 with DMA and interrupt for video.
Wouldnt you say the vast majority of CP/M systems use 177x, 179x disk controllers?
Some with DMA, some not, but there's a small number of DMA chips, at various addresses.
A collection of drivers for FDC and console I/O could also be offered in addition to parameterized I/O where the user specifies the type of chip, address, inversion of data bits, etc.
Just talking about getting a booting systems, not trying to resolve every possible parallel port or RTC board out there.
Some with DMA, some not, but there's a small number of DMA chips, at various addresses.
A collection of drivers for FDC and console I/O could also be offered in addition to parameterized I/O where the user specifies the type of chip, address, inversion of data bits, etc.
Just talking about getting a booting systems, not trying to resolve every possible parallel port or RTC board out there.
Chuck(G)
25k Member
Point is that if you have a manual for the system that details I/O ports, etc., why would you need a tool? You'd have to supply all the data anyway. I don't see it, but hey, have a go.
durgadas311
Veteran Member
The floppy controllers based on the 177x/179x would have needed additional circuitry (I/O port at least) to control drive select, DD, side (maybe), special interrupt modes (maybe) - in addition to how the FDC /INTRQ and /DRQ are routed to the CPU. There is no standardization for that, so you'd have to know who's controller you had. Some of those required special tricks in order to be able to keep up with the data transfer (on slower CPUs). In addition, the boot semantics are not likely the same across platforms, specifically when it comes to disabling the ROM and getting RAM at 0000H. There could be other hardware that's essential to run CP/M that is not standard for all platforms.
A less fancy solution would be to design a modular BIOS (link time, not runtime) where you can "plug in" modules needed for a particular platform. But even that is not simple to implement and requires a lot of code specific to each platform.
A less fancy solution would be to design a modular BIOS (link time, not runtime) where you can "plug in" modules needed for a particular platform. But even that is not simple to implement and requires a lot of code specific to each platform.
cj7hawk
Veteran Member
I had a bit of a think about this, and at first my thoughts were "Given you have to configure it with I/O and Chip specs and make it small. the effort of using such a BIOSGEN would be greater than writing it from scratch"
However on further consideration, the BIOS has a LOT of components that would benefit from automatic generation to an ASM file, such as the tables and automatic checking and allocation of the number of drives, etc.
So such an application would be useful in quickly establishing the known structure of the BIOS and writing up a shell ASM that you could then insert your own custom chip-interfacing code into. It would be more than just a standard template ( as is provided by DRI ) as it should simplify the process of setting up the DPB and DPH tables, and providing decisions around how large they should be would be useful, as well as providing high level information around how they should be set up.
When I consider the BIOS I wrote, that was the most complex aspect of writing the BIOS. The rest was pretty easy.
However on further consideration, the BIOS has a LOT of components that would benefit from automatic generation to an ASM file, such as the tables and automatic checking and allocation of the number of drives, etc.
So such an application would be useful in quickly establishing the known structure of the BIOS and writing up a shell ASM that you could then insert your own custom chip-interfacing code into. It would be more than just a standard template ( as is provided by DRI ) as it should simplify the process of setting up the DPB and DPH tables, and providing decisions around how large they should be would be useful, as well as providing high level information around how they should be set up.
When I consider the BIOS I wrote, that was the most complex aspect of writing the BIOS. The rest was pretty easy.
durgadas311
Veteran Member
Such a generated template probably does not differ much from one case to the next, so I would still wonder if it is worth creating a program to generate it when you could just use a static template (or start with the last BIOS you wrote). A reasonably designed modular BIOS also provides you that, and you don't have a monolithic ASM nightmare to maintain, you just add new modules for new hardware and link together into a BIOS.
durgadas311
Veteran Member
Even a decent macro assembler can make this an easy task. Digital Research provided a set of macros for building the DPH table, DPHs, and DPBs (along with ALV and CKS buffers) using MAC/RMAC. And modern macro assemblers are even more capable.
cj7hawk
Veteran Member
Although the BIOS doesn't actually use these - the BDOS sets these up and uses them - the BIOS just allocates them and leaves a vector to point to them.
And the learning curve when setting up the tables for the first time, especially when not familiar with CP/M, is quite daunting. The DRI examples I found were just tables, and figuring out what the tables actually do took a fair bit of effort.
Once you have they knowledge, they seem very simple in retrospect, but if there was builder of kind to write a skeletal BIOS ASM file for me, I probably would have used it, assuming it was powerful enough to fully populate the file with as many drives as I need tables for, and with the correct values.
Maybe others find those tables easier to understand than I did, but I read them and thought I understood them, and every so often I found what I understood was either corrected or expanded. Now I've written a BDOS and CCP, I'm pretty sure I understand them fully
- but it was still a lot of learning curve involved.WSM
Experienced Member
I've written a fair number of CP/M BIOS's and since I normally use M80 (Z80 & Z180) or ZDS for eZ80, I simply build the tables myself and don't use the DRI macros.
My $.02 is that if a programmer CAREFULLY reads Section 6.10 in the CP/M 2.2 Alteration Guide they should have a good handle on how to define these tables. The required disk information is basically the same for DRI macro use or straight DB/DW's and I find that building the tables myself allows for more flexibility and efficient use of memory.
As to the original question of a BIOSGEN: There is RomWBW if that's what you're looking for as a foundation. In my experience there's too many hardware differences between systems and I find it easier to reuse as much code as possible but every implementation is unique.
As to just a 1771 for disks ... while I built a BIOS with that controller and a genuine IBM 33FD in the 1970's, I've also used 179x's 765's, SD, CF, IDE, flash, MRAM, etc. as CP/M disks. As to DMA controllers ... I've used the Z80 DMA chip, Z180 internal DMA, custom CPLD controllers, etc.
My $.02 is that if a programmer CAREFULLY reads Section 6.10 in the CP/M 2.2 Alteration Guide they should have a good handle on how to define these tables. The required disk information is basically the same for DRI macro use or straight DB/DW's and I find that building the tables myself allows for more flexibility and efficient use of memory.
As to the original question of a BIOSGEN: There is RomWBW if that's what you're looking for as a foundation. In my experience there's too many hardware differences between systems and I find it easier to reuse as much code as possible but every implementation is unique.
As to just a 1771 for disks ... while I built a BIOS with that controller and a genuine IBM 33FD in the 1970's, I've also used 179x's 765's, SD, CF, IDE, flash, MRAM, etc. as CP/M disks. As to DMA controllers ... I've used the Z80 DMA chip, Z180 internal DMA, custom CPLD controllers, etc.
durgadas311
Veteran Member
RomWBW is a good example of just how big and complex of a project this would be. I'm not sure how many legacy systems it supports, but it supports a lot of different hardware. Wayne has done a great job of re-using common code, but it is no simple task to support a wide variety of hardware platforms.