▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!
My apologies for the code tidyup. I thought you were busy with other things when I did it, so thought you would take my additions. Anyway, it was easy for me to insert your mods.
I like your idea of plugging the base address(es) of the SD card into eeprom. There could be another way by using one of the reserved boot sectors to store the offsets. That way, we can change SD cards. It is easy to check for "FAT16". This can happen in the background for now anyway.
Why do I want to get the PropDemo version running on the TriBlade?
Currently I haven't added the code to do the blocking, so at least I thought I could get the latest code running again so I can test out your latest mods.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Gosh Hanno, coming from you I take that as a very great compliment. Probably more than is deserved.
Cluso, no apologies needed, it was just unlucky that it coincided with the huge code turmoil going on at this end.
The boot sector idea sounds solid. I just thought it would be nice to to have to introduce any more sneaky and "transient" code into zicog.spin. It's long, rambling and complicated enough already. Didn't much like to put the z80_ram in there either but at least it is tightly bound to the CPU workings and enable me simplify the parameter list passed into it most of which is not needed for TriBlade anyway.
Good point about having a working version using HUB RAM to build from.
I was thinking though. Presumably it's simple enough for you to get the thing compiled for TriBlade, as I have done, and up to the point where external RAM access is at least working.
Then if you have ZIBOOT loaded into external RAM at the right place you can single step through it. Very soon comes a disk sector read. So there we have built in blocking disk access test, just need to print out the first few sectors read in and compare to the hexdump of the disk.
And so....I should release a boot from disk version package ASAP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yep, but it will take some six hours or so, I'm having to get on with some real work at the moment and away from my Propeller dev machine.
I don't really know how to get any kind of Windows to write a raw binary image to the blocks of an SD card (or any other disk). But there are two ways I would try:
1) Install cygwin www.cygwin.com/. This gives a nice Unix command line interface on Windows and a million useful tools including the "dd" command.
Now under Linux I use the "dd" command like so:
# dd if=a_zboot.dsk of=/dev/sdf
Where /dev/sdf happens to be my SD card reader device.
OK. Well this is what I am going to do, since it is easy for me...
Use my FAT16 SD and copy the file onto it (it will use contiguous sectors since nothing has been deleted since formatting).
Write a spin program to find the file (already done for TriBlade) and then copy the contents from it's location on SD to sector 0, etc. This will overwrite FAT16 but who cares because this is what we want, and no chance of a problem on my Windoze pc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
James - I am here - have been studying code and am ready to implement disk on propIO.
To all: Here are some observations. It took me a while to figure out exactly how the hdsk controller in simulator and zicog work and I not quite happy with the way it works now. The reading of the DPB is kind of useless today and actually makes it slower. The data is hard coded on the spin side - it might as well just be hard coded in BIOS. I am thinking at making it really usable. If on open of the Disk file in FAT we can get the size then we truly can make this dynamic as intended. So if the size is 1MB you pass back DPB for 1Meg drive, if size of file is 8MB then you pass back the 8Meg DPB and you can mix and match to your heart's content. Or the first 16 bytes of sector 0 could contain this information. I have to look on how that might impact booting from the disk. The second thing is that the DMA is really nasty and will not work on a real Z80 as written. Basically what is happening (and was confusing to me initially) is that you are holding off the I/O operation until you have read the sector and transferred it to the Z80 address space. I guess this could be done by holding the /WAIT on the Z80 but is not very aesthetically pleasing. What really should be done is DMA is initiated and you poll the controller or use an interrupt to look for completion of the DMA. In the case of propIO I will be doing indir or outdir to read or write the data but will have to check when the operation to disk is complete on the read before reading or after writing. I can make this all work on the propIO but there will be slight differences in the code for the hdsk controller but they will be very minimal. As for the second generation that I am thinking of for an SBC with Z80 and 1 or 2 propellers on a single board or stacked board that will support DMA and possibly interrupts the hdsk port will have to be changed as well to look more like a real DMA device instead of holding off the I/O until the pseudo DMA is complete.
I think I have all the logic together now and a good understanding of the BIOS and the spin code that I will start implementing the propIO disk I/O. I expect it to be a little different for now but will sync up with commonality in V2. I think I don't want to disrupt the V1 ZiCog too much at this point as it is so close. The comments above are more for planning of changes in V2.
I probably have to mull over your ideas for a while but here are some initial thoughts:
The DPBs:
I don't think the slow down here is so bad as that DPB fetching does not happen so often. For sure we could hard code the geometries into the CBIOS if there was any useful speed gain.
If you look at the HDSK driver in SIMH you will see that it actually does what you say. At least if the attached disk image file is of a known size it will report a DPB for that disk format. There is a table of "known" disk formats in the SIMH hdsk driver code. If you attach an Altair 1Mb floppy as an HDSK it will show up in the correct format. Also the sector skewing is taken care of.
So whilst we currently have DPBs "hard coded" in Spin they could be made more dynamic based on image file size or other meta data. In fact I'm already making a start on this by providing DPBs for 1Mb and 440Kb disks. Just to prove to myself that it works more than anything else.
To make a regular SIMH 1M floppy image readable under ZiCog we only need handle the sector skewing when that format is detected.
The DMA:
Well the SIMH style "DMA" is a bit dumb and does not work in a way that makes sense on real hardware. However for our purposes it is just fine. The mechanism could easily be tweaked so that the BIOS polls a "done" bit somewhere or waits for an interrupt. However that would gain us nothing as CP/M is not a multi-threaded multi-tasking OS. It just has to wait somehow. Even CP/M 3 and MP/M as far as I can tell could not make use of "real" DMA. Their only idea of multi-tasking is support for background printer spooling (as far as I am aware). We don't want to get into interrupts as it would slow the emulation.
I was wondering how disk transfers would work for Prop I/O. The use of INDIR/OUTDIR sounds cool. To make it go at a reasonable rate the Prop code to handle that will need to be PASM.
I like the idea of a Z80 SBC with 2 Props on it.
Ha ! ZiCog V1 seems to have taken a big step further away since there are so many changes going on[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yeah the speed is negligible, but would like to get rid of the hard coding along the way, doesn't have to be in V1.
DMA:
The way it is now is OK - just wanted to point it won't work on a real Z80 and we will have to address that eventually. V2 for this is fine.
Yes I am using INDIR/OUTDIR and all the I/O port logic is in PASM and I have control of the /WAIT line to throttle if necessary. I don't really want to have to do that and should not have to.
Yeah - after I get propIO basically working, I will throw together some schematics. I plan to use one prop just to control the z80 and the other to do I/O. I will probably package like a morpheus in that you can stack boards so you could do a basic z80 with one board and then plug in another board for vga/keyboard/rs232 etc.
A tad off route, but I am thinking of forcing myself to go Linux, like yourself. The windozeless guy, at work, says that there are no viruses for Linux and so no guards need to be put up, and get more speed etc. True ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I have never had to use Windows to do any development work, I started professionally in 1980. I have never had a Windows computer at home. I really don't know anything about it. For 10 years or more I've been living in a Linux world. (OK apart from that short time between discovering the Propeller and the arrival of BST and HomeSpun)
So the idea of "forcing" has never occurred to me.
I do worry about the idea of the whole worlds computing capability being owned and controlled by a single company. Especially a foreign company.
I would not buy into hype about the performance of Linux over Windows or visa-versa. For general day to day work I don't think there is much to choose. For anything else, well, you have to test it for yourself, application by application.
I would also not buy into any hype about the security of any system. Security in computing, like life, is an ongoing process of awareness of the dangers facing you and the measures you can take to combat them.
So, if only out of curiosity, check out Linux/Unix. It's a long road and a different culture but could be well worth it. For many reasons besides speed or security.
Of course if you are into gaming you will probably need to hang onto Bill's apron strings for a long time to come. But that is not why we are here is it ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I was just stirring. Or maybe you were not near a computer for a while but the Force told you to check the forum?!
Re As for the second generation that I am thinking of for an SBC with Z80 and 1 or 2 propellers on a single board or stacked board that will support DMA and possibly interrupts the hdsk port will have to be changed as well to look more like a real DMA device instead of holding off the I/O until the pseudo DMA is complete.
I was looking at the schematic of the N8VEM again last night. There are so many hybrids one could think of. The problem for me is the cost of the propeller. It is $25 here in Australia so they are precious and that leads to a design where you have the minimum number of prop chips, ie 1. Ideally one would do the zicog in the prop and also have spare pins for vga/keyboard/a couple of serial ports. But that is not possible (roll on the prop II, which hopefully will have >64k of ram as well as lots of pins).
Another option is to buy a whole lot of props at once. I'm still a bit stung by the shipping costs from the US. Ram chips listed at $3 but you buy 10 and the cost is $80. They did arrive 2 days later but I'd be happy to pay less for shipping and have them arrive 10 days later. Futurlec seem to have the balance right - $4 worldwide shipping and arrive in 10 days. Anyway the point is a bit moot as I want DIP40 chips and they are out of stock now anyway. But maybe I'll do an order of multiple props down the track.
So I have a design in the back of my head that has all the same hard drive parameters as the zicog, uses an sd card but has a real Z80 and a ram chip with battery backup. It is a N8VEM design but with no eprom and no uart. It has some latch chips (possibly up to 4) so the propeller can completely take control of the Z80 bus and program up the ram chip and then set it running. And I guess that design has the dma to think about and the need to trap I/O signals etc. Have you got a cog able to trap a I/O signal and act on it quickly enough? If yes, that is fantastic. If no, I suppose there is always the busrq and waits etc. Or even an idea where you save a clock module and produce the clock signal from the propeller and then the clock can run slow when needed.
All of these are complicated designs and can't really be built while there are no DIP40 chips around, and the zicog is still in development and maybe in the meantime the prop II might come out and make it all so much easier to design with lots less chips. So for the moment I'm just musing about these things and watching in amazement as heater and cluso continue to optimise the zicog and make it faster and faster.
We will have to swap designs. I too want to control all the z80 signals with the propeller hence the reason for 2. I am thinking probably one latch and the design will support DMA at least to the lower page of memory which I think is the only place the CP/M supports anyways. I am leaning more towards SMT props as I am convinced now from my research they are no harder to solder than conventional chips. Maybe we work out something where I can put a couple of chips in the mail to get around the 25 dollars per prop if we can come up with a common design so we can work on it together. If we can get the SD speeds up I don't see a real reason for battery backed up RAM if we can boot in under a couple of seconds. A sub file can automatically repopulate the ramdisk.
I agree no eprom and if we go with a style like morpheus we can have small custom boards that plug in or stack to do the custom things we want.
I think the prop II is probably quite a ways off and initially will not be cheap so exploiting prop I is probably the way to go.
I am thinking probably 1 latch 2 props a Z80, ram, eeprom, prop Xtal and a bunch of resistors and capacitors is we all need to be a very neat z80 SBC. I guess we will probably have to throw in some bus transceivers so we can drive the bus for stacking. I guess the base board would have only 1 prop and move 1 prop to a custom board to support vga, keyboard and SD. You could replace with a custom board with latches, and max 232s, and SD for the config you want. I am counting control signals we need to control with the prop and it is going to be tight. Also with the prop supplying the clock we can play games over clocking the z80 as well. In terms of I/O trapping it is a little tight so I also control the /WAIT line as well to be safe.
Yes, maybe we could look at smt. Maybe even smt everything??
(I guess one reason I've gone with DIP and sockets is that with the 8 iterations to get the N8VEM board right I ended up recycling a lot of components from board to board)
The N8VEM has the 96 way plug and that makes prototyping new addon boards much easier. But the four 245s can be left off if the backplane is not needed.
Agree re no need for battery backup if the sd is running fast. The last working version I have of the zicog package was Aug29 and that was fast loading the disk images but it was still very slow from starting zicog to the A> prompt. Not sure if the major revision heater did is on cluso's board yet. But if it is only a few seconds then this opens up a lot of possibilities.
I guess we might need to write some specs for such a board. The reason I haven't is that the specs keep changing! But I'm firming up with 2 RS232, micro sd card, keyboard, vga, 6 pins to drive a 20x4LCD and/or maybe ?8 pins to drive a 128x64graphics LCD with text drivers for 21x8 text. Not 100% sure about the N8VEM backplane. Not even 100% sure about the ram chip - if the sd card access truly is going to get to a second to load a program like mbasic, maybe even go back to old-school 64k ram and have all the drives on the sd card? And some generic I/O pins, eg latches for output and buffers (?241) for input. Maybe a D25 with the same pins as the old parallel port that was at the back of a PC so can drive a printer and all the myriad of add-on boards that worked off parallel ports. And I'd like a couple of analog outputs and a couple of analog inputs.
I was thinking of reducing the board size more like the size of the pockeTerm size, and using female dual inline headers for the connectors. Take a look at http://www.mikronauts.com/products/morpheus These type of connectors are much cheaper than ECB connectors. Bill claims you can stack 8 high (I am thinking at most 3).
I think the board is pretty simple and will breadboard one after I finish the propIO. Maybe I will be lucky and get it right of first PCB like Cluso does
I think the difference in price of 64K vs 512K is pretty minimal. The reason to stay with 512K is we can move to MPM with a multi serial card and then you will want the RAM.
I need to get in gear and finish the propIO so I can start playing on this new design
Now to see if I can comment on all the above posts in the last 24 hours
Yoda,·I like your idea of getting the drive length from the SD FAT16 file length However, heater's version without ram will have some code space issues. I have been looking at the FAT16 structure to see a way to embed some parameters without being too complex.
DMA - As heater says, it is not truly DMA within CPM anyway. However, my designs will never allow for DMA anyway as the pins are shared between SD and Ram. And to introduce an instruction to check for interrupts would significantly slow the code down.
re 128KB vs 512KB $2 vs $3. No point to save $1. Shipping is the killer, but over here we should all get together to share shipping costs.
re Battery backed ram - I intend to modify my RamDisk to be write-through which means if (and I will check in code) a write is required then it will also be copied out to SD. So, the RamDisk will be mirrorred on SD. So the complexity of battery backed ram is not required.
I am all for the smt prop (plcc). Just use longer pads on the outside to make it easier to solder.
Since I have a few designs near completion (been saying that for a while now ), I will be getting an order from Future Electronics (memory) and Digikey (rest of the parts including smt props) shortly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso: As requested the complete zicog_cpm V1 release candidate 5.5b.
Sorry for the delay but I could not resist making a couple of changes [noparse]:)[/noparse]
1) Shrunk the CBIOSX by 512 bytes by removing redundant Altair floppy driver code.
2) Enabled autoexec functionality in CBIOSX
3) Fixed that Z80 RAM allocation bug in zicog.spin
WARNING: I may have made a few teeny tweaks to zicog and zicog_cpm I've forgotten about along the way, did not bump the version or add change notes.
As supplied this runs on PropDemo board.
Requires the folowing #defines
PropDemoBoard
CPU_8080
BOOT_FROM_SD
If BOOT_FROM_SD_SPIN is used instead then a Spin function will load the boot sectors from SD instead of ZIBOOT.
zipm2.dsk is now the bootable A: drive for ZiCog.
All modified CP/M 2 files, ZIBOOT, BOOTGEN, SYSCPM2, etc etc are now all included in zipm2.dsk
To rebuild CP/M 2 for ZiCog just:
1) Attach zipm2.dsk as drive I: under SIMH
2) Change to the I: drive
3) Write out MOVER.MAC, CCP.MAC, BDOS.MAC, CBIOSX.MAC, CFGCCP.LIB to the host directory
4) Issue the command "do syscpm2", must be in I: drive.
Step 3 is because syscpm2 reads the files in from the host directory, where they can be easily edited.
This will rebuild CP/M and BOOTGEN the I: drive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just for fun I put the zipm2.dsk CP/M disk image file onto a newly formatted 2GB SD card and managed to get it to work on my PropDemoBoard ZiCog. With just a one line change to Spin code.
How?
1) Format the card (FAT32) under Windows and copy the zipm2.dsk file to it.
2) Read the card (or at least the first couple of hundred megabytes of it) using "dd" under linux into temporary file.
3) Use hexdump under Linux to find zipm2.dsk in the temp file.
4) Calculate the SD block number form the offset shown in hexdump.
5) Set hdsk_base_block to that number in zicog_cpm.spin.
6) Boot the prop with it and there we are.
I'm thinking zicog_cpm.spin could search for some magic to find the file itself, say "Digital Research". Might be a bit slow though.
Anyway, if I now rewrite zipm2.dsk using "dd" to exactly overwrite the existing one (dd has a seek option) then my zicog will keep working even if I use the card for other DOS files [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The wiki explains the FAT12/16/32 structure so you will know where the first file is always placed for a format of say FAT16 and 32KB clusters.
Suggest we stick to FAT16 and 2GB max cards for now.
A prop spin program can find the file base sector easily (my TriBlade ZiCog does that now for all the drives used). So I will cut down a version to find and report the base sector using the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Heater, just thinking further. You are now so close to using what I have been doing for some time, that being locating the seperate drive files under FAT16. Then I just use that start sector address as the base for each drive..
long drive_base[noparse][[/noparse]10] 'use 8+2 (8 = drives A-H, 9 = Ziboot file, 10 = sector containing the offsets)
sector_number := drive_base[noparse][[/noparse]hdsk_drive] 'base sector for drive
·For now, I am going to suggest that I write some code (maybe today) that will read the files on the FAT16 SD card and update a file called "ZICOG.PTR" which contains the data to later·be loaded into drive_base[noparse][[/noparse]10] above, and display the start address of this file for "plugging" into your code.
Later I will write a program in PASM to do this so it can be resident in your Z80 ram space, but for now this will work with your code and be extensible later.
Your comments???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This standalone file base finding program sounds great.
Lets say it searches for files with a fixed naming convention "zicog_a.dsk", "zicog_b.dsk" etc. Whatever you like.
Now it's output should be a small Spin file "zicog_disks.spin" or whatever. This would have the drive bases definitions written into it as constant definitions. It could then just be copied into the zicog_cpm project build.
Now if this program were also to check the size of files it finds it could also generate the DPB's for them ......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Last night I discovered that the BIOS supplied with SIMH for CP/M 3 does NOT support booting from SIMH style hard drives !!!
Worse: There are two BIOSs to consider for CP/M 3. It has a simple BIOS in it's initial loader which then reads CP/M 3 from a file which in turn contains a full BIOS.
Looks like I have some work to do.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: I was meaning I would do the program in spin to update the SD card. I have created the file shell on my SD now called "ZICOGDRV.PTR" Hopefully I will have this running tonight and will post the code.
re CPM3 & MPM: I will let you think about this. We will still require the above anyway. Maybe we just have to support 1 floppy to boot??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Correction, the actual full scale CP/M 3 BIOS supports hard drives. We can make pretty much the same changes to it as CBIOSX.
It's just that the cut down loader BIOS has no hard drive support. We could:
a) Add hard drive support to it (preferred)
b) Put all that floppy drive support back into Spin (Ouch)
c) Skip it and put stuff into Z80 RAM as we have done for CP/M 2 before (messy)
Not sure about MP/M yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I seem to have got lost in the last few days. My last working package that could boot to an A> was on the 30th August. Any chance you could take that last zip and add the files to make it a complete package? eg spin files and a drive image (zipped should be small) and the ..demo_rr10x version?
Here is the content of my SD as shown by the fsrw demo followed by the output of zicog_SDPtr:
> dir
> mount
mount returned 0
> dir
ZIPM2.DSK 8388608 bytes
ZICOGDRV.PTR 458752 bytes
DRIVE__B.DSK 8388608 bytes
DRIVE__C.DSK 8388608 bytes
DRIVE__D.DSK 8388608 bytes
DRIVE__E.DSK 8388608 bytes
DRIVE__F.DSK 8388608 bytes
DRVCPM_2.DSK 8388608 bytes
DRVCPM_3.DSK 8388608 bytes
> ZiCog set ZICOGDRV.PTR on SD using PropDemoBoard v0.001
It just stops there[noparse]:([/noparse]
The SD was formatted as FAT32 under XP and then ZIPM2.DSK and ZICOGDRV.PTR dropped on to it. The other files were copies of ZIPM2[noparse]:D[/noparse]SK done on the Prop with the fsrw demo.
There is an other option for CP/M 3 loading. Modify the loader so that it is a CP/M 2 program then use it to start CP/M 3 from CP/M 2 !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is the latest version 003 of the pointer program.
I do not think that FAT32 is supported. I have fixed some things and display the actual sectors where the data is stored on the disk.
Also included are the files that can be copied to a newly formatted sd. Use FAT16 and 32KB clusters. I am not certain that drive A is actually CPM2.2 (I think it is from you heater and is the i drive with 4 x 128 per sector i.e.blocked). The other drives are all $E5 ready for formatting. They are all 8MB.
James: I will have to test first - I have nothing working at present as I have moved forward and need to get heaters code running again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
OK that zicog_SDptr works fine now I have a nice new FAT16 formatted SD.
Manually patched the SD block offset shown for drive A: into zicog_cpm and it booted fine.
I'm not going to make any changes here until Cluso has a TriBlade version up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I will have a look tomorrow at adding in any changes I have done and get it running on TriBlade
I have been having a bit of a look at how FAT16 is arranged and the file length so we can set the hdpb up per drive. Not v. difficult, but it can wait. Also later, can make this into a pasm routine so we can hide the code in the z80 ram space within hub.
The code I posted above will make the basis of a good SD FAT16 tool - it can display each sector, so just needs a front end to ask for the sector number.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
Truly inspiring.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!
My apologies for the code tidyup. I thought you were busy with other things when I did it, so thought you would take my additions. Anyway, it was easy for me to insert your mods.
I like your idea of plugging the base address(es) of the SD card into eeprom. There could be another way by using one of the reserved boot sectors to store the offsets. That way, we can change SD cards. It is easy to check for "FAT16". This can happen in the background for now anyway.
Why do I want to get the PropDemo version running on the TriBlade?
Currently I haven't added the code to do the blocking, so at least I thought I could get the latest code running again so I can test out your latest mods.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
Cluso, no apologies needed, it was just unlucky that it coincided with the huge code turmoil going on at this end.
The boot sector idea sounds solid. I just thought it would be nice to to have to introduce any more sneaky and "transient" code into zicog.spin. It's long, rambling and complicated enough already. Didn't much like to put the z80_ram in there either but at least it is tightly bound to the CPU workings and enable me simplify the parameter list passed into it most of which is not needed for TriBlade anyway.
Good point about having a working version using HUB RAM to build from.
I was thinking though. Presumably it's simple enough for you to get the thing compiled for TriBlade, as I have done, and up to the point where external RAM access is at least working.
Then if you have ZIBOOT loaded into external RAM at the right place you can single step through it. Very soon comes a disk sector read. So there we have built in blocking disk access test, just need to print out the first few sectors read in and compare to the hexdump of the disk.
And so....I should release a boot from disk version package ASAP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
And the instructions please (windows vista) to create the SD disk with just the a_ziboot.dsk on it (not FAT16) so I can run your code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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 don't really know how to get any kind of Windows to write a raw binary image to the blocks of an SD card (or any other disk). But there are two ways I would try:
1) Install cygwin www.cygwin.com/. This gives a nice Unix command line interface on Windows and a million useful tools including the "dd" command.
Now under Linux I use the "dd" command like so:
# dd if=a_zboot.dsk of=/dev/sdf
Where /dev/sdf happens to be my SD card reader device.
What we need is the name of that device under Windows. It can be found using Windows disk manager diskmgmt.msc. There is some good hints on doing all this here www.packetninjas.net/index.php/commentary-on-using-dd-in-cygwin-forensics/
2) Download WinHex www.x-ways.net/winhex/ which looks like it does what we want.
I have never tried either of these techniques, just thought I may get around it one day.
BE CAREFUL !! Either of these could wreck your hard drive partitions if you select the wrong thing to write to !!!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Use my FAT16 SD and copy the file onto it (it will use contiguous sectors since nothing has been deleted since formatting).
Write a spin program to find the file (already done for TriBlade) and then copy the contents from it's location on SD to sector 0, etc. This will overwrite FAT16 but who cares because this is what we want, and no chance of a problem on my Windoze pc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
To all: Here are some observations. It took me a while to figure out exactly how the hdsk controller in simulator and zicog work and I not quite happy with the way it works now. The reading of the DPB is kind of useless today and actually makes it slower. The data is hard coded on the spin side - it might as well just be hard coded in BIOS. I am thinking at making it really usable. If on open of the Disk file in FAT we can get the size then we truly can make this dynamic as intended. So if the size is 1MB you pass back DPB for 1Meg drive, if size of file is 8MB then you pass back the 8Meg DPB and you can mix and match to your heart's content. Or the first 16 bytes of sector 0 could contain this information. I have to look on how that might impact booting from the disk. The second thing is that the DMA is really nasty and will not work on a real Z80 as written. Basically what is happening (and was confusing to me initially) is that you are holding off the I/O operation until you have read the sector and transferred it to the Z80 address space. I guess this could be done by holding the /WAIT on the Z80 but is not very aesthetically pleasing. What really should be done is DMA is initiated and you poll the controller or use an interrupt to look for completion of the DMA. In the case of propIO I will be doing indir or outdir to read or write the data but will have to check when the operation to disk is complete on the read before reading or after writing. I can make this all work on the propIO but there will be slight differences in the code for the hdsk controller but they will be very minimal. As for the second generation that I am thinking of for an SBC with Z80 and 1 or 2 propellers on a single board or stacked board that will support DMA and possibly interrupts the hdsk port will have to be changed as well to look more like a real DMA device instead of holding off the I/O until the pseudo DMA is complete.
I think I have all the logic together now and a good understanding of the BIOS and the spin code that I will start implementing the propIO disk I/O. I expect it to be a little different for now but will sync up with commonality in V2. I think I don't want to disrupt the V1 ZiCog too much at this point as it is so close. The comments above are more for planning of changes in V2.
Dave
I probably have to mull over your ideas for a while but here are some initial thoughts:
The DPBs:
I don't think the slow down here is so bad as that DPB fetching does not happen so often. For sure we could hard code the geometries into the CBIOS if there was any useful speed gain.
If you look at the HDSK driver in SIMH you will see that it actually does what you say. At least if the attached disk image file is of a known size it will report a DPB for that disk format. There is a table of "known" disk formats in the SIMH hdsk driver code. If you attach an Altair 1Mb floppy as an HDSK it will show up in the correct format. Also the sector skewing is taken care of.
So whilst we currently have DPBs "hard coded" in Spin they could be made more dynamic based on image file size or other meta data. In fact I'm already making a start on this by providing DPBs for 1Mb and 440Kb disks. Just to prove to myself that it works more than anything else.
To make a regular SIMH 1M floppy image readable under ZiCog we only need handle the sector skewing when that format is detected.
The DMA:
Well the SIMH style "DMA" is a bit dumb and does not work in a way that makes sense on real hardware. However for our purposes it is just fine. The mechanism could easily be tweaked so that the BIOS polls a "done" bit somewhere or waits for an interrupt. However that would gain us nothing as CP/M is not a multi-threaded multi-tasking OS. It just has to wait somehow. Even CP/M 3 and MP/M as far as I can tell could not make use of "real" DMA. Their only idea of multi-tasking is support for background printer spooling (as far as I am aware). We don't want to get into interrupts as it would slow the emulation.
I was wondering how disk transfers would work for Prop I/O. The use of INDIR/OUTDIR sounds cool. To make it go at a reasonable rate the Prop code to handle that will need to be PASM.
I like the idea of a Z80 SBC with 2 Props on it.
Ha ! ZiCog V1 seems to have taken a big step further away since there are so many changes going on[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
DPB:
Yeah the speed is negligible, but would like to get rid of the hard coding along the way, doesn't have to be in V1.
DMA:
The way it is now is OK - just wanted to point it won't work on a real Z80 and we will have to address that eventually. V2 for this is fine.
Yes I am using INDIR/OUTDIR and all the I/O port logic is in PASM and I have control of the /WAIT line to throttle if necessary. I don't really want to have to do that and should not have to.
Yeah - after I get propIO basically working, I will throw together some schematics. I plan to use one prop just to control the z80 and the other to do I/O. I will probably package like a morpheus in that you can stack boards so you could do a basic z80 with one board and then plug in another board for vga/keyboard/rs232 etc.
Dave
A tad off route, but I am thinking of forcing myself to go Linux, like yourself. The windozeless guy, at work, says that there are no viruses for Linux and so no guards need to be put up, and get more speed etc. True ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I have never had to use Windows to do any development work, I started professionally in 1980. I have never had a Windows computer at home. I really don't know anything about it. For 10 years or more I've been living in a Linux world. (OK apart from that short time between discovering the Propeller and the arrival of BST and HomeSpun)
So the idea of "forcing" has never occurred to me.
I do worry about the idea of the whole worlds computing capability being owned and controlled by a single company. Especially a foreign company.
I would not buy into hype about the performance of Linux over Windows or visa-versa. For general day to day work I don't think there is much to choose. For anything else, well, you have to test it for yourself, application by application.
I would also not buy into any hype about the security of any system. Security in computing, like life, is an ongoing process of awareness of the dangers facing you and the measures you can take to combat them.
So, if only out of curiosity, check out Linux/Unix. It's a long road and a different culture but could be well worth it. For many reasons besides speed or security.
Of course if you are into gaming you will probably need to hang onto Bill's apron strings for a long time to come. But that is not why we are here is it ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/9/2009 10:30:31 PM GMT
Yes, I was just stirring. Or maybe you were not near a computer for a while but the Force told you to check the forum?!
Re As for the second generation that I am thinking of for an SBC with Z80 and 1 or 2 propellers on a single board or stacked board that will support DMA and possibly interrupts the hdsk port will have to be changed as well to look more like a real DMA device instead of holding off the I/O until the pseudo DMA is complete.
I was looking at the schematic of the N8VEM again last night. There are so many hybrids one could think of. The problem for me is the cost of the propeller. It is $25 here in Australia so they are precious and that leads to a design where you have the minimum number of prop chips, ie 1. Ideally one would do the zicog in the prop and also have spare pins for vga/keyboard/a couple of serial ports. But that is not possible (roll on the prop II, which hopefully will have >64k of ram as well as lots of pins).
Another option is to buy a whole lot of props at once. I'm still a bit stung by the shipping costs from the US. Ram chips listed at $3 but you buy 10 and the cost is $80. They did arrive 2 days later but I'd be happy to pay less for shipping and have them arrive 10 days later. Futurlec seem to have the balance right - $4 worldwide shipping and arrive in 10 days. Anyway the point is a bit moot as I want DIP40 chips and they are out of stock now anyway. But maybe I'll do an order of multiple props down the track.
So I have a design in the back of my head that has all the same hard drive parameters as the zicog, uses an sd card but has a real Z80 and a ram chip with battery backup. It is a N8VEM design but with no eprom and no uart. It has some latch chips (possibly up to 4) so the propeller can completely take control of the Z80 bus and program up the ram chip and then set it running. And I guess that design has the dma to think about and the need to trap I/O signals etc. Have you got a cog able to trap a I/O signal and act on it quickly enough? If yes, that is fantastic. If no, I suppose there is always the busrq and waits etc. Or even an idea where you save a clock module and produce the clock signal from the propeller and then the clock can run slow when needed.
All of these are complicated designs and can't really be built while there are no DIP40 chips around, and the zicog is still in development and maybe in the meantime the prop II might come out and make it all so much easier to design with lots less chips. So for the moment I'm just musing about these things and watching in amazement as heater and cluso continue to optimise the zicog and make it faster and faster.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
We will have to swap designs. I too want to control all the z80 signals with the propeller hence the reason for 2. I am thinking probably one latch and the design will support DMA at least to the lower page of memory which I think is the only place the CP/M supports anyways. I am leaning more towards SMT props as I am convinced now from my research they are no harder to solder than conventional chips. Maybe we work out something where I can put a couple of chips in the mail to get around the 25 dollars per prop if we can come up with a common design so we can work on it together. If we can get the SD speeds up I don't see a real reason for battery backed up RAM if we can boot in under a couple of seconds. A sub file can automatically repopulate the ramdisk.
I agree no eprom and if we go with a style like morpheus we can have small custom boards that plug in or stack to do the custom things we want.
I think the prop II is probably quite a ways off and initially will not be cheap so exploiting prop I is probably the way to go.
I am thinking probably 1 latch 2 props a Z80, ram, eeprom, prop Xtal and a bunch of resistors and capacitors is we all need to be a very neat z80 SBC. I guess we will probably have to throw in some bus transceivers so we can drive the bus for stacking. I guess the base board would have only 1 prop and move 1 prop to a custom board to support vga, keyboard and SD. You could replace with a custom board with latches, and max 232s, and SD for the config you want. I am counting control signals we need to control with the prop and it is going to be tight. Also with the prop supplying the clock we can play games over clocking the z80 as well. In terms of I/O trapping it is a little tight so I also control the /WAIT line as well to be safe.
Yes, maybe we could look at smt. Maybe even smt everything??
(I guess one reason I've gone with DIP and sockets is that with the 8 iterations to get the N8VEM board right I ended up recycling a lot of components from board to board)
The N8VEM has the 96 way plug and that makes prototyping new addon boards much easier. But the four 245s can be left off if the backplane is not needed.
Agree re no need for battery backup if the sd is running fast. The last working version I have of the zicog package was Aug29 and that was fast loading the disk images but it was still very slow from starting zicog to the A> prompt. Not sure if the major revision heater did is on cluso's board yet. But if it is only a few seconds then this opens up a lot of possibilities.
I guess we might need to write some specs for such a board. The reason I haven't is that the specs keep changing! But I'm firming up with 2 RS232, micro sd card, keyboard, vga, 6 pins to drive a 20x4LCD and/or maybe ?8 pins to drive a 128x64graphics LCD with text drivers for 21x8 text. Not 100% sure about the N8VEM backplane. Not even 100% sure about the ram chip - if the sd card access truly is going to get to a second to load a program like mbasic, maybe even go back to old-school 64k ram and have all the drives on the sd card? And some generic I/O pins, eg latches for output and buffers (?241) for input. Maybe a D25 with the same pins as the old parallel port that was at the back of a PC so can drive a printer and all the myriad of add-on boards that worked off parallel ports. And I'd like a couple of analog outputs and a couple of analog inputs.
But that might all change next week!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
I think the board is pretty simple and will breadboard one after I finish the propIO. Maybe I will be lucky and get it right of first PCB like Cluso does
I think the difference in price of 64K vs 512K is pretty minimal. The reason to stay with 512K is we can move to MPM with a multi serial card and then you will want the RAM.
I need to get in gear and finish the propIO so I can start playing on this new design
Now to see if I can comment on all the above posts in the last 24 hours
Yoda,·I like your idea of getting the drive length from the SD FAT16 file length
DMA - As heater says, it is not truly DMA within CPM anyway. However, my designs will never allow for DMA anyway as the pins are shared between SD and Ram. And to introduce an instruction to check for interrupts would significantly slow the code down.
re 128KB vs 512KB $2 vs $3. No point to save $1. Shipping is the killer, but over here we should all get together to share shipping costs.
re Battery backed ram - I intend to modify my RamDisk to be write-through which means if (and I will check in code) a write is required then it will also be copied out to SD. So, the RamDisk will be mirrorred on SD. So the complexity of battery backed ram is not required.
I am all for the smt prop (plcc). Just use longer pads on the outside to make it easier to solder.
Since I have a few designs near completion (been saying that for a while now
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
Sorry for the delay but I could not resist making a couple of changes [noparse]:)[/noparse]
1) Shrunk the CBIOSX by 512 bytes by removing redundant Altair floppy driver code.
2) Enabled autoexec functionality in CBIOSX
3) Fixed that Z80 RAM allocation bug in zicog.spin
WARNING: I may have made a few teeny tweaks to zicog and zicog_cpm I've forgotten about along the way, did not bump the version or add change notes.
As supplied this runs on PropDemo board.
Requires the folowing #defines
PropDemoBoard
CPU_8080
BOOT_FROM_SD
If BOOT_FROM_SD_SPIN is used instead then a Spin function will load the boot sectors from SD instead of ZIBOOT.
zipm2.dsk is now the bootable A: drive for ZiCog.
All modified CP/M 2 files, ZIBOOT, BOOTGEN, SYSCPM2, etc etc are now all included in zipm2.dsk
To rebuild CP/M 2 for ZiCog just:
1) Attach zipm2.dsk as drive I: under SIMH
2) Change to the I: drive
3) Write out MOVER.MAC, CCP.MAC, BDOS.MAC, CBIOSX.MAC, CFGCCP.LIB to the host directory
4) Issue the command "do syscpm2", must be in I: drive.
Step 3 is because syscpm2 reads the files in from the host directory, where they can be easily edited.
This will rebuild CP/M and BOOTGEN the I: drive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How?
1) Format the card (FAT32) under Windows and copy the zipm2.dsk file to it.
2) Read the card (or at least the first couple of hundred megabytes of it) using "dd" under linux into temporary file.
3) Use hexdump under Linux to find zipm2.dsk in the temp file.
4) Calculate the SD block number form the offset shown in hexdump.
5) Set hdsk_base_block to that number in zicog_cpm.spin.
6) Boot the prop with it and there we are.
I'm thinking zicog_cpm.spin could search for some magic to find the file itself, say "Digital Research". Might be a bit slow though.
Anyway, if I now rewrite zipm2.dsk using "dd" to exactly overwrite the existing one (dd has a seek option) then my zicog will keep working even if I use the card for other DOS files [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Suggest we stick to FAT16 and 2GB max cards for now.
A prop spin program can find the file base sector easily (my TriBlade ZiCog does that now for all the drives used). So I will cut down a version to find and report the base sector using the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
·For now, I am going to suggest that I write some code (maybe today) that will read the files on the FAT16 SD card and update a file called "ZICOG.PTR" which contains the data to later·be loaded into drive_base[noparse][[/noparse]10] above, and display the start address of this file for "plugging" into your code.
Later I will write a program in PASM to do this so it can be resident in your Z80 ram space, but for now this will work with your code and be extensible later.
Your comments???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
Lets say it searches for files with a fixed naming convention "zicog_a.dsk", "zicog_b.dsk" etc. Whatever you like.
Now it's output should be a small Spin file "zicog_disks.spin" or whatever. This would have the drive bases definitions written into it as constant definitions. It could then just be copied into the zicog_cpm project build.
Now if this program were also to check the size of files it finds it could also generate the DPB's for them ......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You guys are not going to be happy.
Last night I discovered that the BIOS supplied with SIMH for CP/M 3 does NOT support booting from SIMH style hard drives !!!
Worse: There are two BIOSs to consider for CP/M 3. It has a simple BIOS in it's initial loader which then reads CP/M 3 from a file which in turn contains a full BIOS.
Looks like I have some work to do.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
re CPM3 & MPM: I will let you think about this. We will still require the above anyway. Maybe we just have to support 1 floppy to boot??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
It's just that the cut down loader BIOS has no hard drive support. We could:
a) Add hard drive support to it (preferred)
b) Put all that floppy drive support back into Spin (Ouch)
c) Skip it and put stuff into Z80 RAM as we have done for CP/M 2 before (messy)
Not sure about MP/M yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is code to update an SD·file "ZICOGDRV.PTR" with the pointers.
We need to change the naming, so yes lets go with
ZICOG_An.DSK, etc
where A is A=A:, B=B: .... H=H:
where n is 2=CPM2.2, 3=CPM3, M=MPM, 0=General
This way we can change on boot easier. The pointer file (can have more than one for different drive mapping)
ZICOG__n.PTR
where n is as above
We may also need a boot file or whatever. I will just wait until I see what we need first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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 seem to have got lost in the last few days. My last working package that could boot to an A> was on the 30th August. Any chance you could take that last zip and add the files to make it a complete package? eg spin files and a drive image (zipped should be small) and the ..demo_rr10x version?
Many thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Here is the content of my SD as shown by the fsrw demo followed by the output of zicog_SDPtr:
It just stops there[noparse]:([/noparse]
The SD was formatted as FAT32 under XP and then ZIPM2.DSK and ZICOGDRV.PTR dropped on to it. The other files were copies of ZIPM2[noparse]:D[/noparse]SK done on the Prop with the fsrw demo.
There is an other option for CP/M 3 loading. Modify the loader so that it is a CP/M 2 program then use it to start CP/M 3 from CP/M 2 !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I do not think that FAT32 is supported. I have fixed some things and display the actual sectors where the data is stored on the disk.
Also included are the files that can be copied to a newly formatted sd. Use FAT16 and 32KB clusters. I am not certain that drive A is actually CPM2.2 (I think it is from you heater and is the i drive with 4 x 128 per sector i.e.blocked). The other drives are all $E5 ready for formatting. They are all 8MB.
James: I will have to test first - I have nothing working at present as I have moved forward and need to get heaters code running again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
Manually patched the SD block offset shown for drive A: into zicog_cpm and it booted fine.
I'm not going to make any changes here until Cluso has a TriBlade version up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I will have a look tomorrow at adding in any changes I have done and get it running on TriBlade
I have been having a bit of a look at how FAT16 is arranged and the file length so we can set the hdpb up per drive. Not v. difficult, but it can wait. Also later, can make this into a pasm routine so we can hide the code in the z80 ram space within hub.
The code I posted above will make the basis of a good SD FAT16 tool - it can display each sector, so just needs a front end to ask for the sector number.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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