Remove this ad

DOS internals - techniques for interfacing with new hardware

Rss     Subscribe     Share     Tweet    

0 Points


Jun 17 13 4:56 AM

Tags : :

Imagine a new piece of hardware which can be used to store files. It is desirable for programs to have transparent access to this hardware. - meaning that any program can run without modification using this device as its storage medium. I accept that any kind of software protection which uses the disk drive hardware directly won't work.

It is also desirable that the user has an easy time using the new hardware - meaning that no drivers need to be loaded or obscure commands need to be learned. Ideally the new device will 'just work'. It's a pain in the butt to have to load a program each time the machine is booted or reset.

This means either a utility ROM or a modified DOS I guess.

With a modified DOS I expect that programs requiring the DOS functions would work but if there are some which don't use DOS at all - games perhaps? - then these would require patching.

Having used TeeBee's silicon disk I know that it's possible to interact at the MOS level using an extension ROM to add hardware support, so maybe this should be the gold standard to aim for.

What is the best document to consult to learn about DOS/MOS internals? I have a copy of 'Albert Revealed' on order, is there anywhere else to look? Can anyone offer up any further suggestions about how einSDein can be supported at the OS level??


Quote    Reply   
Remove this ad
Remove this ad

#1 [url]

Jun 17 13 10:43 AM

Hi Charlie,
There will no doubt be some varied opinions about this but I'm the only one who is right. LOL!
If you think about it once a file that was written to work on the Einstein is loaded into Einstein memory it will work. So providing it worked either using DOS calls e.g. a vanilla CP/M program or just MOS calls or other programming tricks such as direct hardware access such as in a game it will still work once it is loaded and executed. 

What really concerns us regarding EinsDein is the how and where those files are stored. File handling is a function of BDOS. BDOS processes DOS calls for creating,opening,reading,writing and deleting files. It is also responsible for processing the records of these files i.e pulling them from the storage device and writing them back to it. BDOS DOES NOT CARE WHAT THESE STORAGE DEVICES ARE because BDOS uses "Duck" processing - as long as the storage device behaves like a duck BDOS considers it to be a duck. However built within this highly democratic file system are some inherent limitations. CP/M can only address disks of 8Mb in size but it can address up to 16 of these as discrete drives e.g. A:-P: so in theory the file system can address 16 * 8 Mb = 128Mb and that's it. A paltry amount by todays standards but it was a colossal amount of memory back in the early 80's when a single 10Gb Hdd cost £500-1000. With a bit of tweaking and if we abandoned USER codes (primitive directories) then the number of drives could be increased to 32. However this in itself has ramifications. Each drive installed has a a drive descriptor of 16 bytes and a bit map allocation table. This maps the free blocks on a storage device that are allocated or not and the numbers of the allocated blocks are stored in the file directory entry which tells the OS which blocks belong to that file. Currently the Einstein OS uses 2kb allocation blocks for its files and each block is represented by one bit. A byte thus maps 16kb So each 8mb drive would require 8*1024kb / 16 = 512 bytes and 16 drives would thus require 8kb of allocation tables. These are stored in RAM not on the disk so you can see that we could quickly run out of space to run programs in and for each drive we added we would have to reduce the TPA (transient program area) by 512 bytes. We can increase allocation size up to 32kb per block but then a 1byte file would occupy 32kb of disk space and we are still not going to get a disk that's significantly larger, In reality we will want to address a single drive of around 32Gb in size without jumping through hoops - so it isn't hard to see that the Einstein OS's file system is hopelessly outdated for a modern size disk. This is why I am rewriting the OS to make it small enough and robust enough to handle modern sized disks. This is very tricky because it needs to be 32bit to address a big disk and because it has to be small and compact enough - ideally the same size that it already is and be backward compatible with all of the existing software. It's a tall order and it is going to take a long time .But there is one thing you need to know IT DOESN'T MATTER FOR NOW. Even if the the file system uses your interface in the traditional way and addressed say a couple of 8mb drives this would still be good enough and a vast improvement on anything that exists at the moment and has existed since Einstein hard drives disappeared 30 years ago. 

What I recommend is this. The EinsDein hardware device should be programmed into a second ROM and 2 new MOS calls created to read/write a single 512 byte sector which mirror the existing ones for the FDD. The existing OS can then be very simply modified by selecting the device in BIOS via its drive number - reads/writes to EinsDein will be simply redirected transparently and to all intents and purposes it will be a large Duck.

This will then give us all the time in the world to develop a modernised OS.

There is a second approach. This is to use the native API which talks to the SD interface to simply save and load files - so it's a big storage depot. This means that the vanilla Einstein DOS doesn't know anything about EinsDein and can't write and read records directly through it but they can be modified once in memory and saved back.This could be easily achieved by transient programs or just added to the OS as additional commands with the code embedded.

Perhaps for now both methods could be used by partitioning part of the SD card as a drive the Einstein OS can use directly and using the remainder as a file storage depot.

Regarding literature it depends what you really want to know - Albert revealed is VG for hardware but CP/M calls are just like MSDOS calls and in fact MSDOS was cloned from CP/M. The DOS/MOS manual is very useful and is available from the Einstein reborn website free as a pdf. My list of MOS calls and their functions is in the files section of the Einstein  User Group.
To truly understand the issues I'm talking about then you need to know how CP/M works under the hood and I can recommend CP/M revealed by Jack D. Denton and Soul of CP/M by Mitchell Waite and Robert Lafore. Remember that these are old texts and use old tools and 8080 assembler syntax not Z80. The main difference between CP/M and Einstein Xtal DOS is that Xtal is optimised for the Z80. Having disassembled it and compared it with CP/M 2.2 it seems to me that Xtal probably originally licenced the code from Digital Research and added their own improvements but perhaps Trevor Brownen of Xtal Research who is a forum member can comment on that.

Certainly learning about CP/M will stand you in good stead but it takes along time to become a proficient Z80 coder which is a constant balancing act between size, speed and efficiency and a lot longer to understand the issues surrounding an OS and backward compatibility I question if you really need to become an expert in this area or if your existing talents in electronics are better employed in a collaborative effort with myself and others.

Quote    Reply   

#2 [url]

Jun 18 13 6:31 AM

Thanks for the input! I want nothing more than to be able to involve the rest of the community. Expertise from everywhere is welcome. I'll be sharing the sources to all my work as I go along. When I developed ZXpand one of the most time consuming activities was modifying the ZX81 ROM to give seamless access to all the new facilities. If I can provide people with the tools they need in order for them to bring new goodness to the system then all the better :D

As it is I think the 2nd ROM is the way to go. I'm not interested in a hard-drive replacement/new DOS for the moment - making this work with what exists already is my number one concern. If I can mount an existing disk image on einSDein and have the einy think there's a floppy there then I will be satisfied. I'll have a look at Tony's silicon disk ROM and see if there are any clues there.

A transient program or 2 for creating and managing the images would be the missing pieces. Is it possible to add new DOS commands when using a second ROM? Something like SDDIR / SDMOUNT / SDLOAD / SDSAVE etc. This would eliminate the need to have a boot disk. Something I'm keen on.

If we can create & mount 8mb disks then I will be more than satisfied  :D  I will be 100% cock-a-hoop if some way could be found to make transparent access to the SD card's file system possible - though I know this may only be through some significant development.

So - game on?

Quote    Reply   

#3 [url]

Jun 20 13 4:03 PM


Totally cool about your agreement about 2nd ROM

About embedding commands in ROM - a bit too complicated and probably not possible as DOS is not Rom'd itself and remember that ROM memory is paged out during normal transient program operation.
You still need BDOS and CBIOS loaded as a minimum to support DOS calls and the hardware and you will need some sort of CLI so loading CCP anyway seems sensible so effectively  its best to boot DOS from the interface.

I think the way forward for now is to finish the SDDIR etc. transients for test access.
I am confident I can modify DOS for at least one 8Mb drive and if we assign it to say drive Z: that I can seamlessly get DOS to treat that like a large FDD as long as those 2 new MOS calls exist for reading/writing a sector on EinsDein.Thinking about it - it should be possible to use multiple 8mb partitions on EinsDein but only allow DOS the one large allocation table so that a drive switch simply reinitialises the partition table - however this would make inter-partition file copying within DOS difficult so 2 allocation tables for 2 drives would be required - well that's only 1k less TPA and a small price to pay for all that extra ooomf!
So my suggestion is to modify DOS for 2 floppies and 2 EinsDein drives - with the additional possibility of adding some software paging trickery to have multiples of the 8mb partitions. This could be achieved by simply treating these partitions as fixed offsets from track zero. 
You could boot from the Z: drive and have DOS boot from that. All you have to do is get the second ROM to select the EinsDein as the boot drive and transfer to the first ROM  loader program and that will boot whatever is on track 0.

My modular version of DOS should give 3 advantages - it uses less RAM than the current 2.05 version so we might not lose much of the TPA . As the Z: & Y: drives will behave like floppies all normal DOS commands will work. Transients that access the remainder of the SD card as a file repository could also be integrated if you like. Because this DOS is modular it only loads active modules so it doesn't matter how big DOS is it won't occupy any more RAM in operation. 

:-)  A

Quote    Reply   
Add Reply

Quick Reply

bbcode help