[Coco] Cloud-9 Driver Platform WAS NitrOS9 build errors

Mark Marlette mmarlette at frontiernet.net
Tue Jan 21 10:13:05 EST 2014


All,

As Robert has suggested. Previous Cloud-9 products at their final revisions, all used the SuperDriver.by Boisy, which he released to the public.

This driver allowed the hardware to be queried and all of the drive geometry controlled by the OS, if so selected. Bit in the descriptor field.

The standard configuration from Cloud-9 was not to allow this query to occur as it didn't do partitions when selected. Since we had a 256 drive HDB-DOS partition and a ~127MB NOS partition that we didn't want to step on.


Current platforms that I am developing are basically driverless, for the most part. They all talk via the DW protocal and the heavy lifting is done in the device's firmware. This allows the CoCo interface to be the same, always DriveWire.


The new SuperSD is FAT based and currently complies to the .dsk format. It can also detects RAW NOS/DECB file structures and mount that as well but who would want to do that??? It acts much like a drivewire file server been working on the Ethernet side but this device will not have an Ethernet port even though it could..Heck, might add as an option, not sure ATM. Haven't looked at wireless yet. Most wireless solutions are serial based, slow, unless you can get them in the 2-4megabaud region. Then I can use a DMA on the Xmega to do the transfers in the background.


No it is not completed yet, firmware still in development. The .dsk portion all works. Runs on the Atmel Xmega platform. Current megaread times on the dev system are under 1.8seconds. Preliminary megaread optimum review that was done indicates that it should be under 9seconds, if we did our homework right. ?????? :)


This device will also have SRAM rather than FLASH. The bootable ROM paks are all configured via the SD card and loaded before the coco boots. Still need to do the hardware SRAM sharing logic but from what I remember it can load a 8K ROM in 13mS , 16K in 24mS.

DS1307 RTC as well......

Upgradeable firmware via the SD, just place the file on the SD and turn it on. The firmware's bootloader reads a file off the SD via the Xmega's AES encryption engine. I wrote a special bootloader for this, had to make the library read only because SD write functions made the routine larger than the bootstrap memory would allow....uffda. :) 


The final goal is to have this all on the SB....Yes a lot of firmware development and learning......

Sorry for the verbose reply. Just been awhile on a status update, stuck in firmware and yes, need to get the FLASHpak done, mind in firmware, hard to drop to route the board, simple I know but close on a baseline firmware release ATM.

Regards,

Mark
http://www.cloud9tech.com



________________________________
 From: Robert Gault <robert.gault at att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com> 
Sent: Tuesday, January 21, 2014 7:59 AM
Subject: Re: [Coco] NitrOS9 build errors
 

Tormod Volden wrote:

> Let me ask again, all of you floppy disk fans. What is the useful
> information you need when you look at that disk image listing? How do
> you normally classify those floppies and drives? TPI? Or tracks?
> Capacity?
> 
> See the refreshed http://nitros9.sourceforge.net/latest/ where I have
> calculated a number of tracks from the "os9 id" output. Would it be an
> idea to replace or complement the TPI with this?
> 
> Tormod
> 

You can follow the example of MESS when handling Coco floppies. Any floppy labeled .dsk is assumed to be single sided, have 18 sector tracks, 256 byte sectors, and a multiple of 35 tracks per disk; basically the JVC format.
Any disk labeled .os9, means that the format must be taken from LSN0; permitting double sided disks of any size. Regards tpi and other info, that is a function of OS-9 and the drive in use and should be
 transparent to the user.

At the moment, NitrOS-9 does not handle adequately issues related to tpi and in some cases hard drives. Mark Marlette (because Cloud-9 is selling drive hardware) and Gene Heskett (because he seems to find bugs more than anyone else do to his extensive drive collection) should be queried to see what is needed for their hardware.

Robert


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


More information about the Coco mailing list