"Can I just clarify, when you read a sector, does the sd card code send heaps of pulses first to somehow reset the card?"
I believe so. The pulses after the read(s)/write(s) have been done have been added by me. That many is not required. As I have said, all will be resolved when I manage to move to the new SD driver.
@heater: DMA via another cog is NOT possible on the TriBlade as the RAM and SD bus is shared. So, ZiCog stalls (as it currently does) waiting for SD completion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ah, ok. And I know we have covered this before and I know it is on the (ever growing) list of things to do. I guess the reason it is relevant is that there may not be much point packing the drives down from 32 to 8mb for a small speed gain if there is going to be a much bigger gain down the track from different sd card code.
The code to expand the drives is pretty simple to use (either the vb6 code or some simple python). I might integrate it into the N8VEM vb.net ide as well. Indeed, one of the things the vb.net ide can do is to batch downloading of many files via xmodem. eg the wordstar package. So I've got drive A as the cp/m drive and then I'm just dropping in lots of blank drives at the moment and then set the ide going sending over wordstar via xmodem. For just a few files it is quicker than firing up the simh, reading in files, then expanding out the drive image and removing the sd card and copying it across and then putting the card back in again and then doing a reboot.
I'm now trying to get my head around the simultaneous discussion on the N8VEM forum about trying to create common file images. Hard or floppy drive images? 8 or 32mb? Boot from drive or boot from eprom? Boot from floppy drive or hard drive? I'm not sure of any answers yet. Just trying to understand the questions first!
The boot from floppy is REAL SIMPLE now. Heater is convinced it is as easy to boot from a hard drive, but we need to get the hdp working. And as you can see from the spin demo code, it is easy to boot from different drives to run CPM2, CPM3 or indeed MPM.
The first objective is to use common file formats for N8VEM (and PropIO) and the Prop versions of ZiCog. I would say this is done from our side - 1x128 per 512 SD sector for now, maybe 4x128 per 512 SD sector at a later date.
Ultimately, I am sure we will boot the whole project from SD card because we can then boot PropDos, MoCog, etc. I have actually done this some months ago. However, the boot code can simply be a file on the SD card under FAT16 and just this file could be different for N8VEM booting meaning a standard EPROM bootloader and no more EPROM burning for the N8VEM group
Anyway, just working on getting the new SD driver running. There are interdependencies between the pasm driver and the spin above it that I need to work through because I have to add a function to tristate the SD pins and reenable them as they are shared between the SD card and the SRAM bus, and it will remain that way for speed on my cards anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I plan to do the packing / unpacking on the propeller side. I don't understand the wear issue, you actually do less I/O at least on the read side and come close to even on the write side. There is no delayed write in the way I am implementing. In some cases I may have to do a read modify write but if doing sequential write I would only have to do that on every fourth right. On the read side there in general will be a quarter of the reads with packed versus upacked.
I am still in favor of packed drives. Sorry my real job got in the way this week and have not done much but am hoping to get a lot done this week I hope. Next weekend in holiday weekend in the US so maybe I can get a lot more done.
Yoda: The delayed write imposes some issues, at least for the TriBlade style hardware. If you wait until the next write which is not in the same block, then you risk having up to 3x128 unwritten cpm sectors in the block. If you place a time on it then my hardware will not work, as it will have to interrupt ZiCog which means every instruction will have to do a check (=slower) in case the SD driver requires the bus to write. I have designed the hardware for speed and simplicity, so I do not have latches as such so the data bus is shared between the SD and SRAM. If you always write out, then you may have 4 writes to the same SD sector. I just don't think the complexity is worth the problem and SD space saving. I am unsure of the impact on the N8VEM hardware/software if the real Z80 tries to access 512byte sectors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The need for speed -- Yes we need more. I love the N8VEM for its instant start up. We may never get to that but:
1) Booting from hard disks will be much faster. I want to dump all support for those slow Altair floppies in the emulator and in the CBIOSX. Boot from RAM disk probably does not help initial boot as it has to be loaded from SD anyway (unless we get battery backed RAM) BUT warm boots would then be much faster !
Lets not worry about the HUB RAM only "demo" version, we have pushed it as far as is reasonable.
CP/M 3 has already been working on TriBlade. If we dump Altair disks it will need the same BIOS mods as proposed for CP/M 2 CBISOX, and the same again for MP/M.
Cluso:
Enough said about DMA already[noparse]:)[/noparse] We both know how it works in reality, as far as I'm concerned the Z80 sees DMA, the spin code sees a block move. Who cares what we call it we know what we mean. Except - I have never said anything about a another COG doing DMA. It's impossible as you say and I'm quite happy with what we have done there.
Looking forward to the faster SD driver.
Yoda:
Yes, packing/unpacking (blocking/unblocking) should happen in the Prop side. If the Z80 does it we have a slow down especially for the emulation.
I have implemented 4 * 128 byte sectors in 512 byte SD blocks for floppy and HD emulation. It works fine. Given that CP/M uses alocation blocks on disk of 1K, 2K or whatever then there is a lot of sequential access going on. So there should be a 4 fold increase in read speed. There is no wear issue with reads.
Currently I don't do delayed writes, the SD block buffer is updated and written for each CP/M sector. This is the safest way to do it but, as Cluso points out, means that each SD block gets 4 times more writes than if we just used one CP/M sector per SD block.
Cluso:
Don't worry about the real Z80 wanting 512 bye sectors. If it does that is a bug that should be fixed as everyone agrees that packing/unpackingshould happen in the Prop side.
Implementing delayed writes for "packed" sectors/blocks would be a risky proposition as you say. I agree that having an "interrupt" to the Z80 or a time check in the opcode cycle is not a good idea. The only way I could think to time out the delayed writes is during the time the CBIOS is polling the console port. This would not slow or complicate the actual Z80 emulation. But seems a very risky idea regarding possible data loss/disk corruption. What happens if the program does not want to read fronm the console? I think delayed writes are a no-no.
So packed sectors gives:
1) Smaller images
2) Faster reads, boot times
3) A little bit slower writes, due to prefetching SD blocks. Remember most access are sequential to 1K or 2K so only one block needs fetching for every 4 sector writes.
Down side is:
1) 4 times more wear on a sector.
The wear issue will not concern me until I see it[noparse]:)[/noparse] Are we really going to hammer the SD so much? Is the wear leveling in the SD card itself not good enough? I don't know.
Have at look at that last zicog_demo.spin I put up. The code for packed sectors is not at all complex.
I'd be quite happy to adopt packed sectors but am prepared to sit on it for now.
Instead, I will get on with CBIOS mods, Altair floppy disk removal, booting from HD, getting floppy format disks into the HD driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: I presume getting the floppy format disks into the HD driver is as simple as PIP J:=A:*.* It takes a while but does indeed work.
Since you are commenting, I can only assume it is not so easy to convert in VB or Python. Maybe we can just use SIMH on the PC to convert using PIP ? Am I missing something. BTW I haven't run SIMH on the PC.
I am keen to get Banking working on CPM3 if you can point me in the right direction (while I have time).
The SD driver is still a priority. I cut a lot of rubbish out of the code last night before posting it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
When I said "get the floppy format into the HD driver" I was not meaning just copy files from floppy to hard.
Those SIMH Altair floppies have 137 byte sectors that we can easily fix in a pre-process step in VB or Python, as we have done.
BUT those floppies also have sector skewing where as the HDs do not. So trying to read a processed SIMH Altair floppy with the HD driver will not work.
So the CBIOS needs to be told that when using one or more designated drives (A: and B: say) as 1Mb floppy disks it should de-skew them.
Also it is required to put the floppy disk parameters into those HD tables in zicog_demo.
However, now that I think about it why not do the de-skewing in our VB/Python pre-processor?
Or even more radical, why bother with 1M floppies at all ?
Consider this: We could configure the thing to support up to sixteen 8Mb hard disks and no floppies!
For CP/M 3 add some bigger disks if desired.
Why not? Transfering stuff from SIMH is a matter of PIP to hard drive, as you say, and then put that HD image on the SD card.
If we used packed sectors no pre-processing step is required. Just copy the image to SD. It's only 8M which takes no time at all.
What do you think? Why do we want floppies at all ?
I say dump 'em.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Of course when I suggest ditching 1M floppy support I assume we can but from HD. We are almost there.
We have had, or at least Cluso has had, booting from floppy working via the DSKBOOT.COM code placed at FF00.
There is HDSKBOOT.COM for hard disk boot. Works on SIMH. Looking at the code I see no reason it should not work for ZiCog/TriBlade.
It's a little different from DSKBOOT in that it runs from 5C00 and it relies on DSKBOOT to supply the byte indicating which drive to boot from. So I'd make a few little changes there.
I'm working on it....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Why the big discussion about floppies or HDs? If they all "exist" on SD in some form or other is it just a legasty thing from SIMH. Bucket 1, Bucket 2 ... its all storage (just don't call them cassettes, unless the screen sides change colour). Directory linitations would favour lots of small "drives" but 2Gb would soon run out of alphabet. There doesn't seem to be any coherent data on the write cycles possible and how effective the self wear leveling is on top of that. One destructive experiment required, but I bet there is one huge difference between big brand names and the "Ebay" sort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
OK I now have a CBIOSX with no Altair floppy driver support.
Drives A: B: and C: are all 8Mb
As I have packed sectors enabled the image on SD card is exactly that of a SIMH I.DSK with no pre-processing !!!
Does it start up faster?
Oh yes it does and it would be quicker still if these were floppy geometry disks with 256 directory entries to scan instead of 1024.
Any way, just proves the point that we don't need the Altair driver.
ZiCog v0.10 on the Prop Demo Board
Starting disks (A:B:C:) ...
Passed, please wait...
RAM base = 00E8
ROM base = 58E8
Starting Z80 emulation...
Passed, please wait...
24K CP/M Version 2.2 (ZiCog, BIOS V1.27_Z01, 3 HD, 31-Aug-2009)
A>ls a:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
ASM COM 8K ! CPMBOOT COM 12K ! FORMAT COM 4K ! MOVER PRN 4K
BDOS COM 4K ! CREF80 COM 4K ! GO COM 0K ! PIP COM 8K
BDOS MAC 68K ! DDT COM 8K ! HALT COM 4K ! SHOWSEC COM 4K
BDOS PRN 168K ! DIF COM 4K ! HDSKBOOTMAC 8K ! STAT COM 8K
BOOT COM 4K ! DO COM 4K ! L80 COM 12K ! SUBMIT COM 4K
BOOT MAC 4K ! DSKBOOT COM 4K ! LIB80 COM 8K ! SURVEY COM 4K
BOOTGEN COM 4K ! DSKBOOT MAC 8K ! LOAD COM 4K ! SURVEY MAC 16K
CBIOSX COM 4K ! DUMP COM 4K ! LS COM 4K ! SYSCOPY COM 4K
CBIOSX MAC 52K ! EC8080 LIB 4K ! LU COM 20K ! SYSCPM2 SUB 4K
CBIOSX PRN 104K ! ECZ80ALLLIB 4K ! M80 COM 20K ! UNCR COM 8K
CCP COM 4K ! ECZ80DOCLIB 4K ! MC SUB 4K ! UNERA COM 4K
CCP MAC 28K ! ED COM 8K ! MCC SUB 4K ! UNERA MAC 16K
CCP PRN 76K ! EX MAC 56K ! MCCL SUB 4K ! XFORMAT COM 4K
CFGCCP LIB 4K ! EX8080 COM 12K ! MOVER COM 4K ! XSUB COM 4K
COPY COM 4K ! EXZ80DOCCOM 12K ! MOVER MAC 4K
59 File(s), occupying 880K of 8136K total capacity
951 directory entries and 7256K bytes remain on A:
A>ls b:
0 File(s), occupying 0K of 8136K total capacity
1024 directory entries and 8136K bytes remain on B:hdsk param
A>ls c:
0 File(s), occupying 0K of 8136K total capacity
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sounds very exciting. I have been studying the code. I'm not sure what the 256 byte code is that boots it up - is there some assembly source code for that?
Attached is a photo of it running on its own vga monitor (pocketerm). Apologies for the flash in the centre, but for some reason it comes out much clearer with the flash than without.
I'm pondering different drive formats. I wonder, how about 1 floppy drive that is the unpacked 32mb format as created by cluso's vb6 program (for backwards compatability), one floppy drive that is an exact copy of a simh drive (137 bytes??. Can that be done??), and the rest hard drives? Then again (crossed posts), if you say the hard drives are faster...
Then you could drop in some blank drives, drop in a simh drive and do a pip *.* You would never need a conversion program. But if you did have one it would make things quicker.
Also, cluso, do you want a simh package?
Post Edited (Dr_Acula) : 8/31/2009 12:51:24 PM GMT
In the SIMH cpm2.dsk you will find the source for floppy and hard disk boot. DSKBOOT.MAC and HDSKBOOT.MAC
I just compile it with mccl.
Your photo is very encouraging.
We should not get confused between floppy disk or hard disk formats and the use of the floppy or hard disk drivers in CBIOSX/Zicog.
What I am doing now is using the hard disk driver to access hard disk format disks. BUT as you know the actual disk geometries used by the hard disk driver can be changed by tweaking those tables in zicog_demo.spin, dpb_0 etc.
Next up I will put the params for 1M floppy format drives in those tables for disks A: and B: so can work with what looks like floppies.
We should also not get confused between the formats that CP/M/CBIOSX sees and how they actually look on SD cards as our emulation can play games with that. Packed or un-packed, with 137 bytes floppy sectors or not etc.
Just now I want to prove that we can do any/many of these options.
Boot up times in this configuration: Less than 1 second. Feels closer to 0.5s.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Boot up times in this configuration: Less than 1 second. Feels closer to 0.5s.
What, from switch on to the A>?? No way!
Just now I want to prove that we can do any/many of these options.
Yes maybe that is the way forward. Do as many as possible and let the 'marketplace' decide.
I suspect the fastest large drive will be the most popular. But I still see a place for the simplicity of copying a straight simh disk.
I still don't understand the bootloader. It loads the sram with this code
'read the DSKBOOT_.ROM file (256 bytes)
r := sd.initSDCard(spiDO,spiClk,spiDI,spiCS) 'init SD card, but do not restart cog
CheckError(r)
r := sd.readSDCard(drive_base[noparse][[/noparse]16], @buff, 256) 'get 256 bytes
CheckError(r)
r := sd.stopSDCard 'stop SD card, but do not stop cog
CheckError(r)
'copy the 256 bytes to $FF00-$FFFF in sram
r := tbp2.active 'activate the bus
CheckError(r)
r := tbp2.DoCmd("W", @buff, $FF00, 256) 'write to sram
CheckError(r)
'now set the buffer to "$E5" and fill the remainder of sram for use as empty RamDisk
repeat i from 0 to count - 1 'set 8KB block = $E5
buff[noparse][[/noparse] i ] := $E5
repeat i from b1 to b2 - 1 '8 to 63/127: write 56/120 x 8KB blocks of sram above first 64KB
r := tbp2.DoCmd("W", @buff, i * count, count) 'write to sram
CheckError(r)
and then jumps straight into the zicog. Does it then got and read off the boot tracks off of drive A?
Addit - checking out those .mac files
; The sectors of a track are read in the following order:
; first even sectors, then odd sectors in ascending order
; 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,
; 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31
All credit to you heater for decoding this as I tried looking at the boot sectors of a hard disk image with a binary file viewer and the data didn't seem to bear any resemblence to the order above. If you have cracked the code =>kudos.
Aren't you just drooling? Don't you REALLY want those packed disks with DMA (sorry block transfers) and no sector skewing?
All we have to do now is convince Cluso about the sector packing.....
Ideally the emulation would some how just zero RAM and boot the DSKBOOT code at FF00. Then start emulation.
It could put a JUMP FF00 at 0000.
Cluso has done this but I think at the moment we are loading all of CP/M to RAM from a disk file and jumping to the BIOS to start it. This means at least CP/M will start even if your disk images are messed up.
As you see the boot loaders read from disk every other sector. Again an attempt to speed up loading from real floppy drives. This is NOT the same sector skew as used by the BIOS when reading normal data tracks.
So boot times would be doubled again if we laid down the boot sectors as 1, 2, 3, 4....and changed the boot loaders to read like wise.
I'm not up for that yet...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
By the way. The advantage of fewer and smaller drives is that the BIOS gets smaller leaving more room for apps in the TPA. Some of them need it.
The advantage of many small drives over a few large ones is in organizing your files. Boot stuff in A:, Compiler stuff in B: your projects in C: etc. Makes things easier as we have no directories.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso, et al. : I was never proposing to do delayed writes. I think Heater is doing the way I proposed, you write on every write but sometimes you may need to do a read before the write. If it is sequential write you will do one read every 4 writes. Cluso, I understand that there will be 4 times as many writes to a sector but I don't think think this will kill the SD as compared to like a camera or cell phone usage of an SD, unless you are doing some serious data writing from a program.
James, I would not carried away with the number and size of disks. Heater is correct on both counts. 1) you really eat lots of memory that some programs require and 2) large disks become very unmanageable with no directories. I think we should also as Toby suggested get out of the notion of floppies and hard drives as they are all on uSD and are just block devices with different sizes. I really think 4 block devices are plenty and challenging enough to manage. When we are on CPM3 one of those could be a 512MB drive so that should satisfy you thirst for space - good luck managing it - you will find it challenging.
Toby: Are you using the latest bst.exe? I have compiled _rr107 successfully. I just checked the package and it compiles correctly. I also note James has compiled it (can see his photo). Are you compiling for the TriBlade??
The big discussion about floppies v hard drives is because CPM treats floppies as character devices and is therefore very slow. Hard drives are treated as block drives and much faster. Also, Floppies have sector skewing meaning it does not read each successive sector. We want to just use hard drives within CPM even if it is really a floppy image (converted or not) because we want the speed. Hope this answers you questions.
Heater: I am happy to go with the packed sectors. We can always revert if there are issues. The hdp_0 does not appear to be working.
James & Heater: My code no longer loads all 64KB of SRAM from SD. Version rr107 code·now clears the RAM $0000-FFFF, places a JMP $FF00 at $0000, loads the file DSKBOOT_.ROM (its the DSKBOOT.COM file which is 256 bytes long i.e. 1x512 byte SD sector) into $FF00-$FFFF and starts ZiCog which of course executes $0000 which immediately jumps to $FF00. Quite fast now, even with my slow SD driver. BTW, if a RamDisk is used, then the SRAM $10000-$7FFFF for 512KB SRAM or $10000-$FFFFF for 1MB SRAM is preloaded with $E5 to simulate an empty formatted drive. James, that is what the code you posted above is doing. I use tbp2 as a block driver because it is in pasm so it is very fast for block moves. I have not yet added a "clear/fill sram" function·which will be even faster.
[i][color=red]The following just enables the SD driver (it is already resident)[/color][/i]
'read the DSKBOOT_.ROM file (256 bytes)
r := sd.initSDCard(spiDO,spiClk,spiDI,spiCS) 'init SD card, but do not restart cog
CheckError(r)
[i][color=red]The following reads the contents (256 bytes) from drive[noparse][[/noparse]16] which has been preloaded with the base sector address on the card for the file DSKBOOT_.ROM (DSKBOOT.COM)[/color][/i]
r := sd.readSDCard(drive_base[noparse][[/noparse]16], @buff, 256) 'get 256 bytes
CheckError(r)
[i][color=red]The following tristates the SD card bus, but keeps the SD pasm driver active, so we do not have to reload the cog[/color][/i]
r := sd.stopSDCard 'stop SD card, but do not stop cog
CheckError(r)
[i][color=red]The following re-activates the SRAM bus in the TriBlade driver[/color][/i]
'copy the 256 bytes to $FF00-$FFFF in sram
r := tbp2.active 'activate the bus
CheckError(r)
[i][color=red]The following copies 256 bytes from the buffer to SRAM $FF00 (these are the 256 bytes read from the DSKBOOT file above)[/color][/i]
r := tbp2.DoCmd("W", @buff, $FF00, 256) 'write to sram
CheckError(r)
[i][color=red]The following clears an 8KB hub buffer to $E5[/color][/i]
'now set the buffer to "$E5" and fill the remainder of sram for use as empty RamDisk
repeat i from 0 to count - 1 'set 8KB block = $E5
buff[noparse][[/noparse] i ] := $E5
[i][color=red]The following copies the 8KB hub buffer ($E5) to SRAM in 8KB blocks from 64KB to 512KB or 1MB, depending of the size of SRAM.[/color][/i]
[i][color=#ff0000]This is used for the RamDisk and is a blank formatted drive.[/color][/i]
repeat i from b1 to b2 - 1 '8 to 63/127: write 56/120 x 8KB blocks of sram above first 64KB
r := tbp2.DoCmd("W", @buff, i * count, count) 'write to sram
CheckError(r)
Hope this explains the above code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes, that is, NO delayed writes the rest as you say. I put my faith in the wear leveling algorithms builtinto SD cards. Especially has we can have lots of free space on the cards for it to jugle blocks in.
I'm aiming to implement 2 * 1Mb and 1 * 8Mb disks, that would have been "high end" in 1980, if anyone wants to expand/change that they are welcome.
Should be easy now we have the disk geometry params in Spin.
Having only a few disks is not such a bad limitation IF they can be selected by the user before starting Z80 emulation. One may have a hundred different "floppies" on the SD and just load up the ones required. You remember, we used to have to change floppies[noparse]:)[/noparse]
Which means that...We should be able to escape from a running emulation into an emulator command mode so as to change disk selections etc. Contol-E for example like SIMH.
Cluso:
Packed sectors hurrah ! We are in turbo mode.
P.S. I may have fibbed about the boot time from power up. I am loading RAM from BST and watching boot time from end of load to A> prompt.
I am not counting the time it takes a Prop to load from EEPROM. Would you believe I still don't have one !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Toby: Great news that it compiles. bst should also work.
Postedit from Heater: Do check the "Non-Parallax compatible extensions" and "Override global compiler optimizations" in the Project options dialogue.
For the SD card: Get a converter for your PC. There are two ways for this, one is an SD to microSD converter but you will require a PC that has an SD reader. Otherwise, you can get a microSD to USB converter. Both are cheap at camera and computer stores or eBay (or·Officeworks in Australia) I have posted photos. You will require a microSD "uSD" with 2GB or less. Format it with windows with 32KB clusters and FAT16 (I think my assembly instructions at the top of this thread has this in them). Now copy the following files to the uSD... (needs to be done to a reformatted uSD as the files must be contiguous to work correctly!)
DSKBOOT_.ROM·········· (small boot program)
DRIVE__A.DSK············ (a copy of either DRVCPM_2.DSK or DRVCPM_3.DSK - use DRVCPM_2.DSK for now)
DRIVE__B.DSK
DRIVE__C.DSK
DRIVE__D.DSK
DRIVE__E.DSK
DRIVE__F.DSK
DRVCPM_2.DSK··········· (CPM 2.2 floppy)
DRVCPM_3.DSK··········· (CPM 3··· floppy)
HDRIVE_I.DSK
HDRIVE_J.DSK
The first and last 2 are in a recent post (page or 2 back). The rest are in 2 files at the top of this thread with instructions. This should get the A> prompt. Then read this and the ZiCog thread - look for screen shots and·in the posts above you should see instructions for MBASIC. A better way maybe to search the wiki for CPM commands.
Enjoy
Heater: I think we need at least 4 Hard Disks, maybe 6-8 (as we want CPM2, CPM3, MPM) although I guess we don't need all these online at once. So: 1 x 1MB, 1 x 448KB/960KB/???KB RamDrive, 1 x 8MB, 1 x 8MB(or larger). Your thoughts??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm at work now so can't check the code at home, but I noticed last night that two of the parameters in the hdp_0 were commented out. They are the same two that won't display properly on this forum and I'm wondering if they have been copied onto a forum post then copied back into the code and got corrupted and then commented out? Maybe I'm going off on a tangent here but hdp_0 was different to the other 3.
There is a lot to be said for creating 'directories' by keeping files in floppy/hard drive package sizes. eg a wordstar disk, mbasic, sbasic, c, fortran like the way the simh packages are organised. Fascinating comment earlier about putting lots of disk images from the simh on the sd card (even all of them?) and then just using the ones you want.
I wonder, could you change disks on the fly with a special command? eg an 'out' to a port that gets trapped by the spin code and then changes the disk. Then write a small program in cp/m (bdsc, sbasic, bascom) that you can run and it maybe gives you a list of the disks and you can select which one you now want to be 'disk B' or whatever. It could print out a 'directory' of all the available disk images. That would give cp/m a directory structure without having to hack cp/m! I can think about how such a program would work if it is:
a) possible to remount a disk after the zicog has been started and
b) it is possible to talk to the spin operating system from within cp/m using some in and out statements (thinking 4 ports - two in and two out, 'do you have a byte' and 'byte' for each) and for the spin code to return, 1 byte at a time, a list of all the disk images, and receive, 1 byte at a time, the name of a disk image.
No James. It was me trying to limit the size of the drive, but STAT did not report any difference, so I just left what I had done commented out for heater to see if he could get it to work. I had tried hdp_1 also.
re changing SD on the fly... Lots of risks here. Changing a disk (i.e. file) on the fly maybe. But let's walk first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re "re changing SD on the fly... Lots of risks here. Changing a disk (i.e. file) on the fly maybe. But let's walk first."
I was thinking of changing a file on the fly. Not changing the physical sd card.
At the simplest level changing a file might involve sending some commands back to the spin code that changes the array that holds the .dsk names of the disk files. Then just do a cold boot by jumping right back to the beginning of the spin code. Crude I know, and probably there is a more elegant method (? a warm boot). But yes, walking first, and agreeing on how many floppy drives and how many hard drives and what format etc would need to come first.
CP/M has the capability, or at least some CBIOSs did have, of detecting disk changes and rescanning the directories. I don't see any support for this in our CBIOSX and I don't see how it can be made to work without interrupts to the Z80, which we are almost certainly never going to implement. Checking for interrupts in the emulation loop would be yet another slow down.
BUT I can imagine that add some user interface to the emulation such that Control-E kills the emulation, allows the user to map a different disk image to a drive and then restart the emulation. Rather like you would do in SIMH.
Now whether we can be more sophisticated and not kill the emulation but just pause it and then change the disk I don't know yet. Again when you allow the emulation to continue from where it left off how would it know a disk has changed ?
News:
I just managed to get the Mits Altair 1M floppy disk parameters into one of our dpb blocks.
It now shows up as a 1M drive C:
There is a little problem here as I cannot create a 1M floppy to use as a boot disk.
Problem is if you create a 1M boot floppy under SIMH as normal then it has Altair floppy sector skewing on it. The hard disk driver in CBIOS does not use sector skewing so it would be unreadable by ZiCog.
Anyone got any idea how to get SIMH to deal with an Altair geometry floppy but without skew ?
So for now I'm stuck with the backward situation of having an 8M boot disk as drive A: and the rest can be 1M or 8M.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I believe so. The pulses after the read(s)/write(s) have been done have been added by me. That many is not required. As I have said, all will be resolved when I manage to move to the new SD driver.
@heater: DMA via another cog is NOT possible on the TriBlade as the RAM and SD bus is shared. So, ZiCog stalls (as it currently does) waiting for SD completion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The code to expand the drives is pretty simple to use (either the vb6 code or some simple python). I might integrate it into the N8VEM vb.net ide as well. Indeed, one of the things the vb.net ide can do is to batch downloading of many files via xmodem. eg the wordstar package. So I've got drive A as the cp/m drive and then I'm just dropping in lots of blank drives at the moment and then set the ide going sending over wordstar via xmodem. For just a few files it is quicker than firing up the simh, reading in files, then expanding out the drive image and removing the sd card and copying it across and then putting the card back in again and then doing a reboot.
I'm now trying to get my head around the simultaneous discussion on the N8VEM forum about trying to create common file images. Hard or floppy drive images? 8 or 32mb? Boot from drive or boot from eprom? Boot from floppy drive or hard drive? I'm not sure of any answers yet. Just trying to understand the questions first!
The first objective is to use common file formats for N8VEM (and PropIO) and the Prop versions of ZiCog. I would say this is done from our side - 1x128 per 512 SD sector for now, maybe 4x128 per 512 SD sector at a later date.
Ultimately, I am sure we will boot the whole project from SD card because we can then boot PropDos, MoCog, etc. I have actually done this some months ago. However, the boot code can simply be a file on the SD card under FAT16 and just this file could be different for N8VEM booting meaning a standard EPROM bootloader and no more EPROM burning for the N8VEM group
Anyway, just working on getting the new SD driver running. There are interdependencies between the pasm driver and the spin above it that I need to work through because I have to add a function to tristate the SD pins and reenable them as they are shared between the SD card and the SRAM bus, and it will remain that way for speed on my cards anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I plan to do the packing / unpacking on the propeller side. I don't understand the wear issue, you actually do less I/O at least on the read side and come close to even on the write side. There is no delayed write in the way I am implementing. In some cases I may have to do a read modify write but if doing sequential write I would only have to do that on every fourth right. On the read side there in general will be a quarter of the reads with packed versus upacked.
I am still in favor of packed drives. Sorry my real job got in the way this week and have not done much but am hoping to get a lot done this week I hope. Next weekend in holiday weekend in the US so maybe I can get a lot more done.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The need for speed -- Yes we need more. I love the N8VEM for its instant start up. We may never get to that but:
1) Booting from hard disks will be much faster. I want to dump all support for those slow Altair floppies in the emulator and in the CBIOSX. Boot from RAM disk probably does not help initial boot as it has to be loaded from SD anyway (unless we get battery backed RAM) BUT warm boots would then be much faster !
Lets not worry about the HUB RAM only "demo" version, we have pushed it as far as is reasonable.
CP/M 3 has already been working on TriBlade. If we dump Altair disks it will need the same BIOS mods as proposed for CP/M 2 CBISOX, and the same again for MP/M.
Cluso:
Enough said about DMA already[noparse]:)[/noparse] We both know how it works in reality, as far as I'm concerned the Z80 sees DMA, the spin code sees a block move. Who cares what we call it we know what we mean. Except - I have never said anything about a another COG doing DMA. It's impossible as you say and I'm quite happy with what we have done there.
Looking forward to the faster SD driver.
Yoda:
Yes, packing/unpacking (blocking/unblocking) should happen in the Prop side. If the Z80 does it we have a slow down especially for the emulation.
I have implemented 4 * 128 byte sectors in 512 byte SD blocks for floppy and HD emulation. It works fine. Given that CP/M uses alocation blocks on disk of 1K, 2K or whatever then there is a lot of sequential access going on. So there should be a 4 fold increase in read speed. There is no wear issue with reads.
Currently I don't do delayed writes, the SD block buffer is updated and written for each CP/M sector. This is the safest way to do it but, as Cluso points out, means that each SD block gets 4 times more writes than if we just used one CP/M sector per SD block.
Cluso:
Don't worry about the real Z80 wanting 512 bye sectors. If it does that is a bug that should be fixed as everyone agrees that packing/unpackingshould happen in the Prop side.
Implementing delayed writes for "packed" sectors/blocks would be a risky proposition as you say. I agree that having an "interrupt" to the Z80 or a time check in the opcode cycle is not a good idea. The only way I could think to time out the delayed writes is during the time the CBIOS is polling the console port. This would not slow or complicate the actual Z80 emulation. But seems a very risky idea regarding possible data loss/disk corruption. What happens if the program does not want to read fronm the console? I think delayed writes are a no-no.
So packed sectors gives:
1) Smaller images
2) Faster reads, boot times
3) A little bit slower writes, due to prefetching SD blocks. Remember most access are sequential to 1K or 2K so only one block needs fetching for every 4 sector writes.
Down side is:
1) 4 times more wear on a sector.
The wear issue will not concern me until I see it[noparse]:)[/noparse] Are we really going to hammer the SD so much? Is the wear leveling in the SD card itself not good enough? I don't know.
Have at look at that last zicog_demo.spin I put up. The code for packed sectors is not at all complex.
I'd be quite happy to adopt packed sectors but am prepared to sit on it for now.
Instead, I will get on with CBIOS mods, Altair floppy disk removal, booting from HD, getting floppy format disks into the HD driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Since you are commenting, I can only assume it is not so easy to convert in VB or Python. Maybe we can just use SIMH on the PC to convert using PIP ? Am I missing something. BTW I haven't run SIMH on the PC.
I am keen to get Banking working on CPM3 if you can point me in the right direction (while I have time).
The SD driver is still a priority. I cut a lot of rubbish out of the code last night before posting it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Packed sectors means being able to transfer SIMH hard disk images directly into ZiCog/Triblade with no format conversion.
With a bit of work SIMH could save it's floppies in the same format.
How cool is that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, PIP does it.
Ah, but now I see I was not so clear.
When I said "get the floppy format into the HD driver" I was not meaning just copy files from floppy to hard.
Those SIMH Altair floppies have 137 byte sectors that we can easily fix in a pre-process step in VB or Python, as we have done.
BUT those floppies also have sector skewing where as the HDs do not. So trying to read a processed SIMH Altair floppy with the HD driver will not work.
So the CBIOS needs to be told that when using one or more designated drives (A: and B: say) as 1Mb floppy disks it should de-skew them.
Also it is required to put the floppy disk parameters into those HD tables in zicog_demo.
However, now that I think about it why not do the de-skewing in our VB/Python pre-processor?
Or even more radical, why bother with 1M floppies at all ?
Consider this: We could configure the thing to support up to sixteen 8Mb hard disks and no floppies!
For CP/M 3 add some bigger disks if desired.
Why not? Transfering stuff from SIMH is a matter of PIP to hard drive, as you say, and then put that HD image on the SD card.
If we used packed sectors no pre-processing step is required. Just copy the image to SD. It's only 8M which takes no time at all.
What do you think? Why do we want floppies at all ?
I say dump 'em.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, the problem here and now on my zicog is that it can't boot to a hard drive image. So if you can't boot off a drive, you can't run anything.
UNLESS.... you have got it to boot off a hard drive image???
And if that is possible, then yes, why have floppy images.
Of course when I suggest ditching 1M floppy support I assume we can but from HD. We are almost there.
We have had, or at least Cluso has had, booting from floppy working via the DSKBOOT.COM code placed at FF00.
There is HDSKBOOT.COM for hard disk boot. Works on SIMH. Looking at the code I see no reason it should not work for ZiCog/TriBlade.
It's a little different from DSKBOOT in that it runs from 5C00 and it relies on DSKBOOT to supply the byte indicating which drive to boot from. So I'd make a few little changes there.
I'm working on it....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Why the big discussion about floppies or HDs? If they all "exist" on SD in some form or other is it just a legasty thing from SIMH. Bucket 1, Bucket 2 ... its all storage (just don't call them cassettes, unless the screen sides change colour). Directory linitations would favour lots of small "drives" but 2Gb would soon run out of alphabet. There doesn't seem to be any coherent data on the write cycles possible and how effective the self wear leveling is on top of that. One destructive experiment required, but I bet there is one huge difference between big brand names and the "Ebay" sort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Drives A: B: and C: are all 8Mb
As I have packed sectors enabled the image on SD card is exactly that of a SIMH I.DSK with no pre-processing !!!
Does it start up faster?
Oh yes it does and it would be quicker still if these were floppy geometry disks with 256 directory entries to scan instead of 1024.
Any way, just proves the point that we don't need the Altair driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Attached is a photo of it running on its own vga monitor (pocketerm). Apologies for the flash in the centre, but for some reason it comes out much clearer with the flash than without.
I'm pondering different drive formats. I wonder, how about 1 floppy drive that is the unpacked 32mb format as created by cluso's vb6 program (for backwards compatability), one floppy drive that is an exact copy of a simh drive (137 bytes??. Can that be done??), and the rest hard drives? Then again (crossed posts), if you say the hard drives are faster...
Then you could drop in some blank drives, drop in a simh drive and do a pip *.* You would never need a conversion program. But if you did have one it would make things quicker.
Also, cluso, do you want a simh package?
Post Edited (Dr_Acula) : 8/31/2009 12:51:24 PM GMT
I just compile it with mccl.
Your photo is very encouraging.
We should not get confused between floppy disk or hard disk formats and the use of the floppy or hard disk drivers in CBIOSX/Zicog.
What I am doing now is using the hard disk driver to access hard disk format disks. BUT as you know the actual disk geometries used by the hard disk driver can be changed by tweaking those tables in zicog_demo.spin, dpb_0 etc.
Next up I will put the params for 1M floppy format drives in those tables for disks A: and B: so can work with what looks like floppies.
We should also not get confused between the formats that CP/M/CBIOSX sees and how they actually look on SD cards as our emulation can play games with that. Packed or un-packed, with 137 bytes floppy sectors or not etc.
Just now I want to prove that we can do any/many of these options.
Boot up times in this configuration: Less than 1 second. Feels closer to 0.5s.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What, from switch on to the A>?? No way!
Just now I want to prove that we can do any/many of these options.
Yes maybe that is the way forward. Do as many as possible and let the 'marketplace' decide.
I suspect the fastest large drive will be the most popular. But I still see a place for the simplicity of copying a straight simh disk.
I still don't understand the bootloader. It loads the sram with this code
'read the DSKBOOT_.ROM file (256 bytes) r := sd.initSDCard(spiDO,spiClk,spiDI,spiCS) 'init SD card, but do not restart cog CheckError(r) r := sd.readSDCard(drive_base[noparse][[/noparse]16], @buff, 256) 'get 256 bytes CheckError(r) r := sd.stopSDCard 'stop SD card, but do not stop cog CheckError(r) 'copy the 256 bytes to $FF00-$FFFF in sram r := tbp2.active 'activate the bus CheckError(r) r := tbp2.DoCmd("W", @buff, $FF00, 256) 'write to sram CheckError(r) 'now set the buffer to "$E5" and fill the remainder of sram for use as empty RamDisk repeat i from 0 to count - 1 'set 8KB block = $E5 buff[noparse][[/noparse] i ] := $E5 repeat i from b1 to b2 - 1 '8 to 63/127: write 56/120 x 8KB blocks of sram above first 64KB r := tbp2.DoCmd("W", @buff, i * count, count) 'write to sram CheckError(r)and then jumps straight into the zicog. Does it then got and read off the boot tracks off of drive A?
Addit - checking out those .mac files
All credit to you heater for decoding this as I tried looking at the boot sectors of a hard disk image with a binary file viewer and the data didn't seem to bear any resemblence to the order above. If you have cracked the code =>kudos.
Post Edited (Dr_Acula) : 8/31/2009 1:26:28 PM GMT
Aren't you just drooling? Don't you REALLY want those packed disks with DMA (sorry block transfers) and no sector skewing?
All we have to do now is convince Cluso about the sector packing.....
Ideally the emulation would some how just zero RAM and boot the DSKBOOT code at FF00. Then start emulation.
It could put a JUMP FF00 at 0000.
Cluso has done this but I think at the moment we are loading all of CP/M to RAM from a disk file and jumping to the BIOS to start it. This means at least CP/M will start even if your disk images are messed up.
As you see the boot loaders read from disk every other sector. Again an attempt to speed up loading from real floppy drives. This is NOT the same sector skew as used by the BIOS when reading normal data tracks.
So boot times would be doubled again if we laid down the boot sectors as 1, 2, 3, 4....and changed the boot loaders to read like wise.
I'm not up for that yet...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The advantage of many small drives over a few large ones is in organizing your files. Boot stuff in A:, Compiler stuff in B: your projects in C:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There I was, finally getting a chance to try out your code on BST, bright eyed, with bushy tail.
The first conditional else at the end of the con block (rr107) and there it is "Expected Unique Nane..." error
Eyes dulled by welling tears, tail flattened.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
James, I would not carried away with the number and size of disks. Heater is correct on both counts. 1) you really eat lots of memory that some programs require and 2) large disks become very unmanageable with no directories. I think we should also as Toby suggested get out of the notion of floppies and hard drives as they are all on uSD and are just block devices with different sizes. I really think 4 block devices are plenty and challenging enough to manage. When we are on CPM3 one of those could be a 512MB drive so that should satisfy you thirst for space - good luck managing it - you will find it challenging.
Dave
Toby: Are you using the latest bst.exe? I have compiled _rr107 successfully. I just checked the package and it compiles correctly. I also note James has compiled it (can see his photo). Are you compiling for the TriBlade??
The big discussion about floppies v hard drives is because CPM treats floppies as character devices and is therefore very slow. Hard drives are treated as block drives and much faster. Also, Floppies have sector skewing meaning it does not read each successive sector. We want to just use hard drives within CPM even if it is really a floppy image (converted or not) because we want the speed. Hope this answers you questions.
Heater: I am happy to go with the packed sectors. We can always revert if there are issues. The hdp_0 does not appear to be working.
James & Heater: My code no longer loads all 64KB of SRAM from SD. Version rr107 code·now clears the RAM $0000-FFFF, places a JMP $FF00 at $0000, loads the file DSKBOOT_.ROM (its the DSKBOOT.COM file which is 256 bytes long i.e. 1x512 byte SD sector) into $FF00-$FFFF and starts ZiCog which of course executes $0000 which immediately jumps to $FF00. Quite fast now, even with my slow SD driver. BTW, if a RamDisk is used, then the SRAM $10000-$7FFFF for 512KB SRAM or $10000-$FFFFF for 1MB SRAM is preloaded with $E5 to simulate an empty formatted drive. James, that is what the code you posted above is doing. I use tbp2 as a block driver because it is in pasm so it is very fast for block moves. I have not yet added a "clear/fill sram" function·which will be even faster.
[i][color=red]The following just enables the SD driver (it is already resident)[/color][/i] 'read the DSKBOOT_.ROM file (256 bytes) r := sd.initSDCard(spiDO,spiClk,spiDI,spiCS) 'init SD card, but do not restart cog CheckError(r) [i][color=red]The following reads the contents (256 bytes) from drive[noparse][[/noparse]16] which has been preloaded with the base sector address on the card for the file DSKBOOT_.ROM (DSKBOOT.COM)[/color][/i] r := sd.readSDCard(drive_base[noparse][[/noparse]16], @buff, 256) 'get 256 bytes CheckError(r) [i][color=red]The following tristates the SD card bus, but keeps the SD pasm driver active, so we do not have to reload the cog[/color][/i] r := sd.stopSDCard 'stop SD card, but do not stop cog CheckError(r) [i][color=red]The following re-activates the SRAM bus in the TriBlade driver[/color][/i] 'copy the 256 bytes to $FF00-$FFFF in sram r := tbp2.active 'activate the bus CheckError(r) [i][color=red]The following copies 256 bytes from the buffer to SRAM $FF00 (these are the 256 bytes read from the DSKBOOT file above)[/color][/i] r := tbp2.DoCmd("W", @buff, $FF00, 256) 'write to sram CheckError(r) [i][color=red]The following clears an 8KB hub buffer to $E5[/color][/i] 'now set the buffer to "$E5" and fill the remainder of sram for use as empty RamDisk repeat i from 0 to count - 1 'set 8KB block = $E5 buff[noparse][[/noparse] i ] := $E5 [i][color=red]The following copies the 8KB hub buffer ($E5) to SRAM in 8KB blocks from 64KB to 512KB or 1MB, depending of the size of SRAM.[/color][/i] [i][color=#ff0000]This is used for the RamDisk and is a blank formatted drive.[/color][/i] repeat i from b1 to b2 - 1 '8 to 63/127: write 56/120 x 8KB blocks of sram above first 64KB r := tbp2.DoCmd("W", @buff, i * count, count) 'write to sram CheckError(r)Hope this explains the above code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Yes, that is, NO delayed writes the rest as you say. I put my faith in the wear leveling algorithms builtinto SD cards. Especially has we can have lots of free space on the cards for it to jugle blocks in.
I'm aiming to implement 2 * 1Mb and 1 * 8Mb disks, that would have been "high end" in 1980, if anyone wants to expand/change that they are welcome.
Should be easy now we have the disk geometry params in Spin.
Having only a few disks is not such a bad limitation IF they can be selected by the user before starting Z80 emulation. One may have a hundred different "floppies" on the SD and just load up the ones required. You remember, we used to have to change floppies[noparse]:)[/noparse]
Which means that...We should be able to escape from a running emulation into an emulator command mode so as to change disk selections etc. Contol-E for example like SIMH.
Cluso:
Packed sectors hurrah ! We are in turbo mode.
P.S. I may have fibbed about the boot time from power up. I am loading RAM from BST and watching boot time from end of load to A> prompt.
I am not counting the time it takes a Prop to load from EEPROM. Would you believe I still don't have one !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just tried James's version via BSTc and it ran through ok. I'll catch on to this computer stuff, one day.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I "ticked" the extensons and generic opt boxes and it runs though.
now, what needs to be on the SD card, and how do I get it in the right places??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Postedit from Heater: Do check the "Non-Parallax compatible extensions" and "Override global compiler optimizations" in the Project options dialogue.
For the SD card: Get a converter for your PC. There are two ways for this, one is an SD to microSD converter but you will require a PC that has an SD reader. Otherwise, you can get a microSD to USB converter. Both are cheap at camera and computer stores or eBay (or·Officeworks in Australia) I have posted photos. You will require a microSD "uSD" with 2GB or less. Format it with windows with 32KB clusters and FAT16 (I think my assembly instructions at the top of this thread has this in them). Now copy the following files to the uSD... (needs to be done to a reformatted uSD as the files must be contiguous to work correctly!)
The first and last 2 are in a recent post (page or 2 back). The rest are in 2 files at the top of this thread with instructions. This should get the A> prompt. Then read this and the ZiCog thread - look for screen shots and·in the posts above you should see instructions for MBASIC. A better way maybe to search the wiki for CPM commands.
Enjoy
Heater: I think we need at least 4 Hard Disks, maybe 6-8 (as we want CPM2, CPM3, MPM) although I guess we don't need all these online at once. So: 1 x 1MB, 1 x 448KB/960KB/???KB RamDrive, 1 x 8MB, 1 x 8MB(or larger). Your thoughts??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 8/31/2009 10:17:36 PM GMT
I'm at work now so can't check the code at home, but I noticed last night that two of the parameters in the hdp_0 were commented out. They are the same two that won't display properly on this forum and I'm wondering if they have been copied onto a forum post then copied back into the code and got corrupted and then commented out? Maybe I'm going off on a tangent here but hdp_0 was different to the other 3.
There is a lot to be said for creating 'directories' by keeping files in floppy/hard drive package sizes. eg a wordstar disk, mbasic, sbasic, c, fortran like the way the simh packages are organised. Fascinating comment earlier about putting lots of disk images from the simh on the sd card (even all of them?) and then just using the ones you want.
I wonder, could you change disks on the fly with a special command? eg an 'out' to a port that gets trapped by the spin code and then changes the disk. Then write a small program in cp/m (bdsc, sbasic, bascom) that you can run and it maybe gives you a list of the disks and you can select which one you now want to be 'disk B' or whatever. It could print out a 'directory' of all the available disk images. That would give cp/m a directory structure without having to hack cp/m! I can think about how such a program would work if it is:
a) possible to remount a disk after the zicog has been started and
b) it is possible to talk to the spin operating system from within cp/m using some in and out statements (thinking 4 ports - two in and two out, 'do you have a byte' and 'byte' for each) and for the spin code to return, 1 byte at a time, a list of all the disk images, and receive, 1 byte at a time, the name of a disk image.
re changing SD on the fly... Lots of risks here. Changing a disk (i.e. file) on the fly maybe. But let's walk first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I was thinking of changing a file on the fly. Not changing the physical sd card.
At the simplest level changing a file might involve sending some commands back to the spin code that changes the array that holds the .dsk names of the disk files. Then just do a cold boot by jumping right back to the beginning of the spin code. Crude I know, and probably there is a more elegant method (? a warm boot). But yes, walking first, and agreeing on how many floppy drives and how many hard drives and what format etc would need to come first.
Toby, have you got an A> yet?
BUT I can imagine that add some user interface to the emulation such that Control-E kills the emulation, allows the user to map a different disk image to a drive and then restart the emulation. Rather like you would do in SIMH.
Now whether we can be more sophisticated and not kill the emulation but just pause it and then change the disk I don't know yet. Again when you allow the emulation to continue from where it left off how would it know a disk has changed ?
News:
I just managed to get the Mits Altair 1M floppy disk parameters into one of our dpb blocks.
It now shows up as a 1M drive C:
There is a little problem here as I cannot create a 1M floppy to use as a boot disk.
Problem is if you create a 1M boot floppy under SIMH as normal then it has Altair floppy sector skewing on it. The hard disk driver in CBIOS does not use sector skewing so it would be unreadable by ZiCog.
Anyone got any idea how to get SIMH to deal with an Altair geometry floppy but without skew ?
So for now I'm stuck with the backward situation of having an 8M boot disk as drive A: and the rest can be 1M or 8M.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.