Post Edited (heater) : 9/30/2009 6:22:03 AM GMT

Post Edited (Dr_Acula) : 9/30/2009 7:27:21 AM GMT

Post Edited (Dr_Acula) : 9/30/2009 10:01:17 AM GMT

Post Edited (Dr_Acula) : 9/30/2009 10:45:49 AM GMT

Post Edited (Dr_Acula) : 9/30/2009 11:19:34 AM GMT

Image Attachment : image2.jpg   105KB (image/jpeg) This image has been viewed 18 time(s).

Image Attachment : SD_Card_Files.jpg   44KB (image/jpeg) This image has been viewed 16 time(s).

A quick comment for thoughts....

I think we should include the option to build with floppy support for the TriBlade. It is fairly easy to distinguish and compile that version with the #define command. I thought I would add an option to select the B: drive file (in spin) so that it is not necessary for anyone to change the source other than the #define. In fact, I will provide a precompiled binary. My idea is that anyone wanting to copy floppy files to the hard drive files could do so easily this way. All files end in ".DSK"

I would also provide hard drive versions of the floppy files we know about, such as wordstar, supercalc, turbo pascal, etc. They do not take much room when compressed.

However, the main version we require (and support) is the one with 8 hard drives and no floppies. The first 6 hard drives being fixed 8MB drives, the 7th maybe a huge one, and the 8th being a small RamDrive. All drives are files (as per SIMH) packed 4x128 per 512 sector, and seperate contiguous files under FAT16.

Post Edited (Dr_Acula) : 10/1/2009 1:44:32 AM GMT

re Heater's discussion...

1) I am sorry I must have misled you. I intended a precompiled version be available (although the released code would be able to be recompiled with the floppy #define option) to use 2 floppies A: & B: and 1 hard drive I: purely for use in file transfers from SIMH floppies to hard disks using PIP. Since we will require the A: floppy to be correct for booting, this can remain in our 1x128 per 512 format for speed. However, I suggest the B: floppy be the standard Altair 137 byte format. I will write the code to support this, so we will not require the VB program for any conversion. Therefore, PIP will be used to copy from B: floppy drive (must be called "ALTAIR_B.DSK") to I: (must be called "HD8M_B.DSK" and then it can be the B: drive in the standard 8 Hard Drive version - does this make sense ????). This will make things much easier for everyone. The SIMH B: compatability may not be ready for V1.0 (do not want to hold a release for this).

2)see above - I will write code to suport B: in the SIMH format.

3)Sounds good to me. I can't remember why we had a 1MB drive, so make A:...G: all 8MB for now, and H: the RamDrive so this size will depend on the free RAM available for this. I intend to make this a write-through drive, so anything that writes (and modifies) a disk sector will be written back to the SD drive. This should speed up things nicely. Will probably not be ready for V1.0

4)Absolutely. I have already done Turbo Pascal, SuperCalc, and another. But I combined 2 floppies together, which I now realise was a mistake.

Thinking a little further, if someone (Drac?) can write a simple CPM program to reside on our A: hard drive to write to a specific I/O port, we can trap that, and therefore we could reboot the prop with a binary from the SD card. So we could launch CPM2, CPM3, MPM, the floppy version, PropDos, or anything else for that matter. Sound interesting???? It's certainly doable and not that difficult. 

James: Looking forward to some interesting discussions Sunday

Drac: This is great. We only need to trap one address so 255 sounds great. If we send the port a comand like "RUN BOOTCPM3.BIN +crlf" we could boot that binary from the SD card. I don't think this would be that hard in spin. Likewise we could then expand to "LIST *.* +crlf" and list the files on the SD card. In fact, probably MBASIC could probably even do this for us - is there an OUT type instruction to a specific port???? 

Thinking a little further, we could add all the functions required for file type access on the SD card while we suspend ZiCog by just loading a spin program in another cog - we have spare cogs :-)

Next, we could switch hard drives on the fly, so to speak 

I see V2.0 possibilities coming where we can combine a PropDos and CPM intermixed.

Now, we have to see how Ross can get Catalina to compile with only 512KB and SD. Maybe I have to think about some form of memory paging for this. It does not matter if it is slow, just as long as we can do it. I have had it on my list to meet him when I am in Sydney, but somehow I just never get the chance.

Heater: Wow, it's great that a lot of this is already in SIMH, so we can duplicate/use it.

Yes, we can do a lot once we drop into spin. We can do a lot there and then continue back in ZiCog from where we left off. We have cogs available, so we can drop into PropDos and then return to ZiCog. We could even 'hot switch' on the fly between them. Definately want to use the standard SIMH port. 

I agree - this is for V2.0

I will try to get the SIMH floppy B: running - I am not aiming for speed as it is just for PIP. If I make it for V1.0 well and good, but if not, then V1.5 will be fine.

I would like to tidy the code some more (before V1.0 release) with comments, etc (the ZiCog CPM section, not your pasm) so let me know when it is an opportune time to do so. I do not expect to have time later next week (funeral with relos coming from oseas and interstate).