Do you know what the maximum size of CP/M floppy disks might be or how I can find out?
I think I read in the yaze-ag z80 emulator documentation that they could go to 8M bytes. Yaze is using CP/M 3 with banked memory, may be we have to go that way as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dr_A - your pcb was sent today and the last one to Melbourne arrived on the second day, so you should have a new toy Friday
I am loading the ram into the lower portion and the rom at $FF00 but the length is $0180 so something here is wrong?? Anyway, that is not my problem - I am resetting after about 20 instructions at $4414 = C9... What does a C9 do as it should cause execution to continue at $4335, not $0000 ? I have found a few errors where I was corrupting other data such as words (data_8 & $FF). Still have nothing to prove my pasm routine is writing correctly, but reading must be ok to get here. Spin is obviously writing and reading correctly(loading the 64KB)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Not sure about C9 - maybe the source would help as I can't see it in a quick scan of the instructions as a first byte of an instruction.
Re CP/M disk sizes - most floppies were 360k to 1.2Mb. Hard drives were a max 8Mb so no point trying to go higher than that - you need to then add them as seperate drives eg C, D, E etc.
I must admit a lot of those numbers have the instructions embedded in my memory as well. A result of hand coding, hand assembling, and entering the hex values into a 1702 eprom programmer to get my first CPM system to boot. Not sad at all though, haven't had that much fun building and coding until I started with the propeller.
heater hit it in one - I commented out 2 instructions so wasn't writing to SRAM.
I now get the A> prompt and a DIR does the usual display of rubbish without a disk.
Running 64KB ram/rom from SRAM. Now for a SRAM Disk - I can use one 512KB for one and still have 448KB available on the other SRAM (or can make one combined 960KB).
I have attached the code - remember, it runs on the TriBladeProp board on Blade #2 with SRAM and latch. It is not polished or simplified (sped up)as I just wanted to get it running first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This is fantastic. Now to get the 64K build of CP/M running. Here we are taking a step into the dark as you have the hardware and I cannot test what I'm about to say. Still we have a high degree of confidence now.
Attached are ccp.com, bdos, com and cbiosx.com all built for a 64K system. What needs to happen is:
1. Load the contents of CCP.COM into RAM at address $DC00
2. Load BDOS.COM into address $E400
3. Load CBIOSX.COM into address $F200
4. Load dskboot.com into address $FF00 as usual
Now the tricky part:
5. At RAM address $0000 there should be placed a jump to the bios at $F200 to get the thing started from reboot so we need the following bytes:
$C3, $00, $F2
6. At RAM address $0005 there should be placed a jump to the entry point of BDOS so we need the following bytes there:
$C3, $06, $E4
Note that the entry point is off set 6 bytes into BDOS.
And now it should work !!
If not there is always the single step fall back. I have included all the assembly listings of these files (*.PRN) so that it is possible to follow progress through them.
Good luck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I can't resist it. Here is a screen shot of ZiCog passing, for the first time, half a million test cases of arithmetic and logic operations using indexed with displacement addressing, then a bunch of other tests. Takes quite a while to run.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have been looking at the disk interface (for either SRAM or microSD). My microSD is a little more complex and I need to understand what is happening with the counters in the pasm code. I am sharing the interface pins, and they are not sequential although that part is easy.
Ale - yours will be in the mail tomorrow. So far only tubular has his.·Optomistically, they might start to arrive by the end of this week as some were airmailed last Friday (including heaters).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Great Cluso!
I never got a SD to work with the prop :-(, so now I'll have to try harder and get the appropriate socket . I wanted to pay via credit card... but seemed that the only way was wire transfer :-(. Thanks again!
Ale - I am using a microSD socket from Digikey. It is SMT but is easy to solder by hand with a fine tip. The pins are on the outer edge. Make sure the microSD is 2GB or less and supports SPI (I have heard that not all microSD support SPI).
As I said above, I am in the middle of either getting the microSD working or using SRAM for a disk emulation. I have to get both running, so it's just a matter of which first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks to heaters post above, here is the 64K CPM version running from·external SRAM·on the TriBladeProp Blade #2 up to the command prompt A> (without disk)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
ZiCog and the TriBladeProp now get their own customized CP/M 2.2 BIOS to support a 960KB RAM disk as drive A: on the TriBladeProp platform.
Attached screen shot shows my demo board running a 20K CP/M with the new BIOS and listing files from a 960K disk image.
I always intended to stick with the SIMH AltairZ80 emulators BIOS to save having to maintain it but needs must. Cluso has space in the TriBlades external RAM for a 960K RAM disk rather than the 1Mbyte SIMH disks.
Clusso: The attached CBIOSX is built for a 64K system and should be a drop in replacement for the one you are using now. The attached ram.dsk image replaces cpm2.dsk. Hope it is the right size. It still has all the original SIMH files on it. When we get around to booting from it it should work as it as I tested it in the SIMH emulator.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1. On the SD cards we have 512 byte blocks.
2. The disk images have a sector size of 137 bytes. Very odd I know but that it what old Altair drives used and what the SIMH emulator uses so we are stuck with it for now.
3. CP/M itself uses 128 byte sectors.
The BIOS reads 137 bytes from physical drive sectors and delivers 128 of them to CP/M. Skipping a few bytes at the beginning and dropping a few at the end of each sector.
Now to sort this out I have used the Propeller program cpm2SD.spin.
What that does is:
1. Download all the cpm2.dsk image file from the PC via PropTerminal.
2. Every sector of 137 bytes that is received is written to the beginning of a 512 byte buffer which is then written to an SD card block.
The result is that the SD card is filled with 512 byte blocks, each of which contains a 137 byte disk sector which in turn contains a 128 byte CP/M sector.
Easy haa !
So, for the RAM disk we should just copy the disk image file into RAM as it is. We now have RAM full of 137 byte sectors/blocks.
If replacing
disk : "sdspiqasm"
with
disk : "ramdisk"
in zicog_demo.spin
Then the block parameter given in for example:
err := \disk.writeblock(sd_block, @disk_buff)
will work if the block/sector size used by the RAM disk driver is 137 bytes.
Err.. Hope that all makes sense.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That odity with 128+9x$E5 Bytes sector come from very slow Disk controlers that wil have sync bytes in sector.
You can revrite BIOS to flat 128 else 256 Bytes sector.
It wil spare SD card space and 128 and (256-1,2MB) is standard on CPM with 8" drives with standart controler. 512 Bytes sector come with 3,5" Drives first
Ps "9x$E5" was Gap data on that disk
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Maybe someone could educate me on this thread... What is the purpose of emulating a processor that's over 30 years old on the prop? Is it for nostalgic purposes or are their practical reasons I'm missing? I'm not being flip, just curious....
bmb!, speaking for myself it is partly nostalgia and partly practical. I service a fair number of instruments that are based on 8080/z80 chips and am considering building and offering an update path based on the ZiCog emulator. There is also a lot of public domain software available for the 8080/z80 and CPM.
bmb!,
In addition to the nostalgia, there was a huge amount of software written for the 8080/Z80 including compilers, assemblers, linkers, utilities, database managers, text editors. Given that the Propeller is fast enough to emulate a Z80 at close to real speeds, complete with all of the common peripherals including the display terminal, it's a very reasonable way to have a useful system cheaply and simply with only a VGA display (or even a TV monitor) and PS/2 keyboard needed. You can even get an Ethernet interface and software stack to add in the mix.
There are a few reasons for me:
1. Nostalgia
2. Hobby - something to do
3. Get an SBC (Single Board Computer) running based on Props
4. Pretty cheap
5. Proof of concept - adding external SRAM (Static Ram)
6. Access to a lot of old software (as Mike Green said)
7. Learning and developing other concepts (overlay loader, vector decoding)
8. Interface to other hardware (microSD, Ethernet -> Internet)
9. Basis for other emulations (6502 - Apple, Commodore; 6809, 8088 - old PC)
10. Provide the motivation for the last missing link - a Prop Compiler for a Prop SBC
11. Possible commercial applications???
12. who knows...????
From my perspective, this is a hobby... but who knows. Some of what I have done in the past as a hobby turned commercial.
I hope this helps answer your curiosity
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I had always intended to use the SIMH Altair emulator's CP/M and BIOS unchanged for compatibility reasons. SIMH has a lot of disk images with a lot of software that we can just "drop in". Also it saves having to maintain an own version of the BIOS. Part of the challenge here was AltairZ80 compatibility. I also reasoned that those 9 wasted bytes in a sector (73152 per disk) were not not worth worrying about when using a 1GB SD card.
Now it looks like the the thing to do is to modify the BIOS to support a RAM disk or two but keep the Altair disk drivers also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In Bios it is tabeles to specify "Disk Type. 1.2" , 5.25 , 3.5 and HD
In my opinion it is no problem to ad one extra tabele for RAM type disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Comments
Do you know what the maximum size of CP/M floppy disks might be or how I can find out?
I think I read in the yaze-ag z80 emulator documentation that they could go to 8M bytes. Yaze is using CP/M 3 with banked memory, may be we have to go that way as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am loading the ram into the lower portion and the rom at $FF00 but the length is $0180 so something here is wrong?? Anyway, that is not my problem - I am resetting after about 20 instructions at $4414 = C9... What does a C9 do as it should cause execution to continue at $4335, not $0000 ? I have found a few errors where I was corrupting other data such as words (data_8 & $FF). Still have nothing to prove my pasm routine is writing correctly, but reading must be ok to get here. Spin is obviously writing and reading correctly(loading the 64KB)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 3/18/2009 12:21:48 PM GMT
Re CP/M disk sizes - most floppies were 360k to 1.2Mb. Hard drives were a max 8Mb so no point trying to go higher than that - you need to then add them as seperate drives eg C, D, E etc.
See here: nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater hit it in one - I commented out 2 instructions so wasn't writing to SRAM.
I now get the A> prompt and a DIR does the usual display of rubbish without a disk.
Running 64KB ram/rom from SRAM. Now for a SRAM Disk - I can use one 512KB for one and still have 448KB available on the other SRAM (or can make one combined 960KB).
I have attached the code - remember, it runs on the TriBladeProp board on Blade #2 with SRAM and latch. It is not polished or simplified (sped up)as I just wanted to get it running first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
This is fantastic. Now to get the 64K build of CP/M running. Here we are taking a step into the dark as you have the hardware and I cannot test what I'm about to say. Still we have a high degree of confidence now.
Attached are ccp.com, bdos, com and cbiosx.com all built for a 64K system. What needs to happen is:
1. Load the contents of CCP.COM into RAM at address $DC00
2. Load BDOS.COM into address $E400
3. Load CBIOSX.COM into address $F200
4. Load dskboot.com into address $FF00 as usual
Now the tricky part:
5. At RAM address $0000 there should be placed a jump to the bios at $F200 to get the thing started from reboot so we need the following bytes:
$C3, $00, $F2
6. At RAM address $0005 there should be placed a jump to the entry point of BDOS so we need the following bytes there:
$C3, $06, $E4
Note that the entry point is off set 6 bytes into BDOS.
And now it should work !!
If not there is always the single step fall back. I have included all the assembly listings of these files (*.PRN) so that it is possible to follow progress through them.
Good luck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 3/19/2009 5:52:32 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I have been looking at the disk interface (for either SRAM or microSD). My microSD is a little more complex and I need to understand what is happening with the counters in the pasm code. I am sharing the interface pins, and they are not sequential although that part is easy.
Ale - yours will be in the mail tomorrow. So far only tubular has his.·Optomistically, they might start to arrive by the end of this week as some were airmailed last Friday (including heaters).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I never got a SD to work with the prop :-(, so now I'll have to try harder and get the appropriate socket . I wanted to pay via credit card... but seemed that the only way was wire transfer :-(. Thanks again!
As I said above, I am in the middle of either getting the microSD working or using SRAM for a disk emulation. I have to get both running, so it's just a matter of which first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"They may have computers, and other weapons of mass destruction." - Janet Reno
Attached screen shot shows my demo board running a 20K CP/M with the new BIOS and listing files from a 960K disk image.
I always intended to stick with the SIMH AltairZ80 emulators BIOS to save having to maintain it but needs must. Cluso has space in the TriBlades external RAM for a 960K RAM disk rather than the 1Mbyte SIMH disks.
Clusso: The attached CBIOSX is built for a 64K system and should be a drop in replacement for the one you are using now. The attached ram.dsk image replaces cpm2.dsk. Hope it is the right size. It still has all the original SIMH files on it. When we get around to booting from it it should work as it as I tested it in the SIMH emulator.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is my code to implement the SRAM 960KB disk. I am now integrating it into ZiCog.
Forgot to ask - is the sector size 512 Bytes?
Added: here is a pic of the new ZiCog/TriBladeProp CPM screen from heaters code above
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer·using the TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 3/20/2009 2:34:36 PM GMT
1. On the SD cards we have 512 byte blocks.
2. The disk images have a sector size of 137 bytes. Very odd I know but that it what old Altair drives used and what the SIMH emulator uses so we are stuck with it for now.
3. CP/M itself uses 128 byte sectors.
The BIOS reads 137 bytes from physical drive sectors and delivers 128 of them to CP/M. Skipping a few bytes at the beginning and dropping a few at the end of each sector.
Now to sort this out I have used the Propeller program cpm2SD.spin.
What that does is:
1. Download all the cpm2.dsk image file from the PC via PropTerminal.
2. Every sector of 137 bytes that is received is written to the beginning of a 512 byte buffer which is then written to an SD card block.
The result is that the SD card is filled with 512 byte blocks, each of which contains a 137 byte disk sector which in turn contains a 128 byte CP/M sector.
Easy haa !
So, for the RAM disk we should just copy the disk image file into RAM as it is. We now have RAM full of 137 byte sectors/blocks.
If replacing
disk : "sdspiqasm"
with
disk : "ramdisk"
in zicog_demo.spin
Then the block parameter given in for example:
err := \disk.writeblock(sd_block, @disk_buff)
will work if the block/sector size used by the RAM disk driver is 137 bytes.
Err.. Hope that all makes sense.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That odity with 128+9x$E5 Bytes sector come from very slow Disk controlers that wil have sync bytes in sector.
You can revrite BIOS to flat 128 else 256 Bytes sector.
It wil spare SD card space and 128 and (256-1,2MB) is standard on CPM with 8" drives with standart controler. 512 Bytes sector come with 3,5" Drives first
Ps "9x$E5" was Gap data on that disk
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 3/20/2009 4:28:32 PM GMT
In addition to the nostalgia, there was a huge amount of software written for the 8080/Z80 including compilers, assemblers, linkers, utilities, database managers, text editors. Given that the Propeller is fast enough to emulate a Z80 at close to real speeds, complete with all of the common peripherals including the display terminal, it's a very reasonable way to have a useful system cheaply and simply with only a VGA display (or even a TV monitor) and PS/2 keyboard needed. You can even get an Ethernet interface and software stack to add in the mix.
1. Nostalgia
2. Hobby - something to do
3. Get an SBC (Single Board Computer) running based on Props
4. Pretty cheap
5. Proof of concept - adding external SRAM (Static Ram)
6. Access to a lot of old software (as Mike Green said)
7. Learning and developing other concepts (overlay loader, vector decoding)
8. Interface to other hardware (microSD, Ethernet -> Internet)
9. Basis for other emulations (6502 - Apple, Commodore; 6809, 8088 - old PC)
10. Provide the motivation for the last missing link - a Prop Compiler for a Prop SBC
11. Possible commercial applications???
12. who knows...????
From my perspective, this is a hobby... but who knows. Some of what I have done in the past as a hobby turned commercial.
I hope this helps answer your curiosity
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer·using the TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Loading CPM into SRAM Disk emulation (but not correctly·emulating the 137 byte sectors so the data is not valid yet)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer·using the TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I had always intended to use the SIMH Altair emulator's CP/M and BIOS unchanged for compatibility reasons. SIMH has a lot of disk images with a lot of software that we can just "drop in". Also it saves having to maintain an own version of the BIOS. Part of the challenge here was AltairZ80 compatibility. I also reasoned that those 9 wasted bytes in a sector (73152 per disk) were not not worth worrying about when using a 1GB SD card.
Now it looks like the the thing to do is to modify the BIOS to support a RAM disk or two but keep the Altair disk drivers also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am in the process of changing the SRAM driver to support this and other functions (i.e. a general purpose driver).
However, if we could identify the 9 bytes to remove from the 137 bytes to get 128 byte sectors, that would be much easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer·using the TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
In Bios it is tabeles to specify "Disk Type. 1.2" , 5.25 , 3.5 and HD
In my opinion it is no problem to ad one extra tabele for RAM type disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I have already added a table entry for a RAM disk type which only has a different size for now. Just looking at getting rid of those redundant bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.