Hello Andrew,
Would you please explain more details about addressing the sectors and tracks? How are the information stored on these tracks/sectors: as linked lists, some kind of an allocation
table...etc?
Thank you
ziloo
Hi!
OK, well really the real tracks and sector information is contained in the CBIOS design. It views the data contained in the ROM as a 32K block device "disk". The CBIOS has an algorithm which when you tell it load track 00, sector 00, it knows to go get the first 128 bytes of the ROM. Depending on what track/sector combination you request, it returns different 128 ROM memory regions as a sector. It really is a kind of neat trick.
The ROM itself does not contain any disk metadata like sector/track information like you'd find if you used a Catweasel to do a raw read of a soft sector floppy disk. It is more like a data-only disk image where the disk imaging program knows which data goes with which track/sector based on the data's relative position within the image file.
The ROM is formatted in such a way that the CBIOS can parse it out using its track/sector block device read (and write in the case of the RAM drive). You can literally see the 32K disk structure in the layout of the ROM. It follows the CP/M DPB values in the CBIOS. I think goes something like this...
each track is 4K long and is composed of 32 sectors each 128 bytes in length. Within the 32K ROM there are 8 tracks. Track 0 and 1 are reserved as "system" tracks to contain the loader, dbgmon, & CPM boot image. Starting on track 2 is the directory structure which is like four sectors long or something. Actual disk data starts someplace after the end of the directory and goes to the end of the 32K ROM.
There is a similar concept for the RAM disk but with a different set of DPB values. Eventually I will convert the 1M ROM into a format similar to the RAM drive and include an entire CP/M set of utilities and some development tools, applications and the like. Of course this is user customizable so anything can go in there but right now you have to format the ROM image by hand which is a real PITA.
One of the things I put on the "help needed" section of the N8VEM website is for some programming whiz to make a DOS program which given a set of files and a DPB, will create a formatted ROM image. The program would not be that hard to write (I think) but would require some fairly detailed knowledge of how CP/M disk layout and formatting. I am doing that by hand now but it would be highly useful for others to have a utility which could do this automatically. All the necessary technical information is available online in the CP/M documentation and I can help point out where if anyone is interested.
Thanks and have a nice day!
Andrew Lynch
PS, OK, here is a long note and it is going to ramble about as I have lots of random thoughts I'd like to write down. These aren't aimed at you specifically Ziloo, but just some general thoughts I have been mulling over.
First, last night I worked more on the RTC. It apparently works as is and without any software modifications. I seem to remember something changing during the design or maybe my original notes were unclear. In any event, when I compared the RTC software to the schematic it seemed to be accessing it correctly and when I tried it the software "just worked". The battery back up worked fine too. I misremembered misremembering?
I think tonight I am going to clean up the software directory, make a ZIP file and post the whole mess on the N8VEM website. Yeah, the software is an awful stinky pile of something smelly but it seems to work at least somewhat and rather than wait until it is "perfect" (which will never happen) I'll just post it so people can review it and get a better idea of what this SBC is doing and why. Of course, a few bug reports and improvements would be nice...
The PCB respin is going along OK too. It is rather slow on the computer in the basement (2.6MHz Northwood celeron 400MHz FSB) and it hasn't finished its first pass of optimizing yet. The new layout took a major complexity hit in my attempts to improve the minimum clearance. It is just going to be a while before the optimizer can sort out the mess. I anticipate the via count will be somewhat higher than before, probably 150 or so is acceptable, due to the increased clearance margins. Really, the number of vias is hardly noticeable anyway but the improved clearance is *VERY* important to any future builders.
Regarding making the PCB available to other hobbyists; my plan is that when this PCB comes out of the optimizer is to order a batch of boards and sell them for $20 a piece + shipping to recover the costs. I may offer a 27C1001 EPROM option if its needed. Since there is no practical way for people to order these themselves directly (my preferred method... no middle man and you are on your own) direct ordering appears impractical based on the PCB manufacturers I have spoken with.
All the PCB information is all publically available so there is nothing stopping someone from just taking the Gerber files and ordering a PCB for themselves. Due to the low volume the unit cost will be rather expensive. However, you can do it and I did it for the initial two prototypes. It costs me $80 with shipping for the two initial proofing units.
There is nothing special about the $20 per unit figure, it is just what seems like a reasonable price to me and gives me some flexibility to find a good source of manufacturing. Besides, $20 is a nice round number everyone can identify with. Keeping the price fixed dramatically reduces the overhead of managing a group buy which ties the unit cost to the number of boards sold. My goal is only to cover my costs for the order and if by some miracle there are any funds left over at the end, I will put those towards either another SBC PCB order or for a PCB order of the ECB backplane, bus debug board, or disk IO board.
Using a fixed price method, I can just order a batch of PCBs and dole them out as people's orders come in and avoid the charging people in advance for an undetermined unit cost. I just don't see a practical method of organizing a "unit cost tied to group volume buy" scheme that doesn't rely on some complicated goat rope procedure I don't have time or patience to manage. In addition, complex ordering schemes are notorious for collapsing under the weight of their own excessive details. I have found adding money to any situation makes people wierd in my experience so I'd like to keep it all as simple as possible.
Please remember this is all in the open discussion/planning/thinking out loud phase right now. I am *NOT* ready to take any orders yet. The PCB has to survive the optimizer and final check out still before I place any my order. Even then, it will be at least a couple of weeks turn around so I would expect it will be another 3 weeks (optimistically) before I am ready to accept any orders.
One final note and it is a doozy. Although I have done everything I can think of to reduce the risk of this project for other hobbyists, the initial group who purchase PCBs will be taking on some inherent risk. It is inevitable. Since my initial PCB order, I have had to change the design to account for errors and anomalies. These new boards will be much improved but essentially untried new boards. While I am confident the design is essentially intact, until the first hobbyist other than me builds their first board, no one knows for certain what will happen. Caveat Emptor and all that jazz. There is inherent risk in any project like this and there are *NO* guarrantees or assurances this will work. Please keep that in mind *before* ordering a PCB.
Thoughts? Thanks and have a nice day!
Andrew Lynch
