TimexSinclair TS1000 - Is that like a ZX80, ZX81 or Sinclair Spectrum ?
At least one person here started down the road of a ZX80/81 using ZiCog as the CPU.
The Speccy might have to much Tricky hardware to deal with but on TriBlade board who knows what's possible.
Personally I have no desire to go down that road but I'd love to someone do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Currently ZiCog's hard drives are written to the SD card images as 1 sector (128 bytes) to one SD card block (512 bytes).
This was done as the SD driver deals only in 512 byte blocks so this makes for the simplest code in the emulator.
Cluso has a VB program to expand the SIMH images into this format. I have that Python script.
Of course this wastes space on SD and we end up with 32Mb images files for 8Mb disks!
What I have done now is to change the HD emulation to use 4 sectors in each HD block. So actually the image is just that from SIMH.
OK "packed" is not the right the description. They are just not expanded.
This is a bit more tricky to do and could be slower. One has to read every SD block prior to each sector write operation, up date the correct part of the block and then write it out again.
BUT what I have done is to record which SD block is currently in RAM so that it does not have to be read if a write operation refers to the same block. This keeps writes to sequential sectors up to speed. Luckily CP/M treats does a lot of sequential HD sector access because it deals in multiple sectors in "allocation blocks" on disk. There is no sector "skewing" on hard drives.
I have floppies working the same way. These really are "packed" as I we make 128 bytes sectors from the Altair 137 byte sectors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ah, that sounds interesting. Pure unaltered simh files. I like that. You describe how writes work. What about reads - do you read in 128 or 512 bytes when CP/M asks for 128 bytes? Just thinking of the probability that sectors are contiguous vs the overhead of reading in 4x the bytes vs the overhead of the start and stop routines on the sd card compared to the actual data reading. Also - dumb question but I can't work it out from the code - is the sd card working at 100khz or 400khz?
For reads it goes like this:
1) Calculate the SD card block that holds the sector you want
2) If that block is currently sitting in the disk buffer (from previous read) the just return the correct 128 byte chunk from the buffer.
3) If that block is not currently loaded the read it from SD and then return the sector from it.
So for 4 sequential reads within an SD block only one SD read is done.
CP/M does a lot of sequential reads due its allocation blocks. So we are onto a winner here speed wise.
No idea about the sd clock.
Code will come tomorrow after I have recovered it fro my office machine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hopefully heater can share some of that code by the time I get home from work [noparse]:)[/noparse]
Coz there is a little throwaway comment a few posts up by heater talking about 'allocation blocks' I think these are the smallest blocks for a file, and are the reason that you can save a file with 5 characters 'hello' and it ends up 2k in size. If the drive is not fragmented, the entire allocation block ought to be contiguous. I've got a crazy idea that maybe you could go up from 512 bytes up to 1 allocation block eg 2k or maybe more. Writing a few bytes would be slower (but writing a few bytes doesn't take long anyway). But a PIP or loading a program ought to be a lot faster again. Just a thought - and would need to test it first.
I guess that might bring up the thorny issue of a delayed write buffer. I guess there is a small chance of data corruption. In practice I found that happened anyway in the course of using CP/M intensively and I found I had to reformat floppies every few months. A failed xmodem download can also corrupt a disk, and occasionally the N8VEM needs a ram disk reformat. So nothing is 100% perfect and as with all systems it pays to have backups. (I use xmodem all the time to backup to the PC, and then back that up to the N8VEM website too) So given a system that may by 99% reliable, I'd be happy to accept the extra (theoretical) risk of a delayed write buffer.
Having said that, it is the reads where this ought to have the most impact.
Cluso99 said...
James: Would you like to post the latest code so that I can incorporate the latest changes. Thanks.
I haven't changed much over the last week. Heater has been the one doing all the cool stuff with packed drives. (I've done lots of experimenting but it was all dead-ends). I can post a few suggestions when I get home shortly. But my working program is essentially the same as your last uploaded files which I think was the 24th.
I've just merged my "packed" sector floppy driver version of zicog_demo with my packed sector hard drive version. They were in different towns for some days. I'll post it here this evening after I've given it a final test.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK here is zicog_demo.spin with the "packed" floppy and hard drive mods.
Testing took a long while because I found limiting the BIOS to just 1 hard disk I could get back to a 24K CP/M in HUB RAM (only 46 longs free now) so there was a lot of fiddling around rebuilding CP/M correctly for the demo board.
Good news is:
4 sectors per SD block floppies read/write OK
4 sectors per SD block hard disks read/write OK.
As there is now 24K CP/M RAM on the demo board PIP does not crash after finishing work (unlike me)
I found a neat way to add AUTOEXEC functionality with a simplle CBIOSX change. No CCP hacking. (not relevant to this attached file)
Bad news is:
I probably buggered up the TriBlade floppy/HD read/write routines as far as #ifdefs are concerned as I factored out some common code to new subroutines without much care to TriBlade. I thought you would need a good hard look at it whatever I did anyway.
You will notice in the file header this is v1.0_rc_1. (Version 1, Release Candidate 1). It really has to bump a major version now if we are changing the disk image formats.
So I hope Cluso and Dr_A can merge their latest changes with this and we have ZiCog V1.0.
(There are still some items outstanding for V1, like banked memory testing)
About the name, "demo" is not right because this runs on TriBlade also and perhaps Morpheus etc in the future not just a demo board. Also it is far from a simple demo of how to use the ZiCog emulator.
I leaning toward ZiCog_Altair as it is an Alatair emulation still. Or should it just be ZiCog V1?
But ZiCog is on
Dr_Acula, would you like to post your latest code. You marked up some changes on the thread (removing unwanted code, etc) so I would like to implement this.
Heater, likewise, I will add your changes.
Heater, I only load the BOOT code into $FF00-$FFFF for the TriBlade version of ZiCog. I was thinking there are two quicker ways to do this (than what I am doing for now which is slower - originally there was a reason as I loaded the whole 64KB of CPM).
1) Load this program from a file on the SD card (just the BOOT code, not from the 64KB I am using now)
2) Compile with it embedded in the spin program, as you currently do.
1) would be far more flexible. I am not sure how this works, but I gather it then reads the boot tracks from the boot drive - is this correct? This would solve the different hardware implementation issuse, wouldn't it? Your comments???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ok, warts and all this is my working version.
* Lots of debug messages commented out
* 38400 baud
* No 3 sec delay at startup waiting for the terminal to start
* 8 floppy drives and two hard drives as per the standard simh
* Works with hyperterminal and teraterm and pocketerm (I need these VT100 programs to run wordstar/games)
* Only loads first 64k of the drive_1m.dsk (which I am pondering renaming something else, eg ramimage.bin, as it is not a disk)
I'm not hugely fussed about the delay loading all the 64k of the ram, as there is a much longer delay once the zicog emulation starts.
I think the clean way to handle the boot code is your option 1)
a) Clear all the RAM to zero (up to FEFF anway).
b) Read DSKBOOT.COM from an SD file and put it at FF00
c) Start the emulation. The Z80 then runs up RAM executing NOPs until it hits the boot code at FF00. From there, yes, it reads the boot tracks from the boot drive and off we go.
This saves having to prepare a 64K RAM image file and is better than 2) because it saves 256 bytes of HUB space.
Then we can add a user selectable boot floppy by prompting for a drive 0-7 and "poking" that into the right byte somewhere after FF00.
Then when we want to boot from hard disk we only need to load HDSKBOOT.COM from an SD file into RAM somewhere (I think it is 5C00) in addition to DSKBOOT.COM, The user can the select boot drives 0 to 11 (currently) which gets poked to the same place in the DSKBOOT area and off we go.
This is basically what SIMH does.
As for solving the different hardware implementation issues, I have a cunning and devious plan...
Given that:
1) We would like to be able to just drop in SIMH AltairZ0 disk images after minimal sector mashing (but, importantly, not necessarily boot from them)
2) We would like to accommodate Joda and the N8VEM/PropIO guys. After all we can help them and they can help us with BIOS hacking [noparse]:)[/noparse] and cross-compatibility with many systems is always a good idea.
Then we all make a net gain by softening our stance on the "only use SIMH Altair BIOS".
Rather, we slowly start to diverge from that BIOS.
Let's face it, Altair floppy emulation is a disaster for us. Byte by byte I/O (no DMA) slows things horribly, having sector skew on the disk slows things horribly, the 137 byte sectors we already had to fix.
On top of that I already want to change the BIOS to get the AUTOEXEC function or run in 24K on the Demo Board. And we already need a small change to the CP/M 3 BIOS to get it to work on TriBlade.
The plan basically involves:
1) Changing the SIMH BIOS(s) to only support one Altair compatible floppy. So that we can drop in all those goodies that are available from SIMH (and out of respect for the Altair[noparse]:)[/noparse])
2) Changing the BIOS to support many disks via the hard disk driver (floppy or hard whatever size) giving us DMA and skew free speed.
3) Changing the BIOS to include AUTOEXEC.
4) Changing the BIOS to accomodate PropIO etc. (different port addresses etc)
5) Whatever else comes up.
Basically the changes are not huge. I believe any future SIMH Altair bug fixes/improvements could be easily back portable. Also as Yoda and Dr_A have said this new platform could end up being part of SIMH.
How cool is that ?
To that end I have already set up for myself a way of building ZiCog boot disks for DemoBoard, Triblade etc under SIMH on the PC.
OK this is getting long, more later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
ZiCog v0.10 on the Prop Demo Board
Starting disks (A:B:C:D:E:F:G:H:I:) ...
Passed, please wait...
RAM base = 00E8
ROM base = 5AE8
Starting Z80 emulation...
Passed, please wait...
24K CP/M Version 2.2 (ZiCog Prop Demo Board, BIOS V1.27, 1 HD, 29-Aug-2009)
Unknown console status write with byte &H03
Punch reset
SuperSUB V1.1
Submit file not found error on line number: 0
Unknown console status write with byte &H03
Punch reset
A>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Looking good. Now you can add files on bootup. I'm at work now and away from the triblade [noparse]:([/noparse] but I'll be following developments over the next 10 hours...
Dr_Acula: I have loading only the 256 bytes from the new file·DSKBOOT_.ROM and clearing the remainder of the 64KB ram (except I put a JMP to $FF00 at $0000 to speed things up).
Heater: I have implemented 1) and it saves 9 seconds in booting (because I was·loading the RamDrive as well, so whole 1MB).
I love your ideas. Do we need any floppies?? as we can just use them as a 1MB hard drive - saves on code space and of course we get the speed. Of course, we will need hdp's for floppy, the 8MB hard disks, the RamDisk and a supersized hard drive. If we cannote poke the drive to boot from, then we can have a special HDISKBOOT.COM which contains multiple boots concatenated. All we do is read from a different·offset for the drive number. This is·progressing nicely
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Dr_Acula: Thanks for your code - yes only minor changes. Do you have the hard disk working? Mine is not, so just wondering, as I do not see any code differences. Or is the I: drive blank???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes hard drive is working fine. Start with a blank 32mb filled with E5. I just tweaked the vb6 program to produce those. Then try a PIP to the hard drive.
Re heater's 5 point plan for success, I think it looks good. 1 floppy and lots of hard drives. one floppy is still useful even if it is really slow so you can go grab a .dsk image off the simh site and drop it onto a sd card unaltered. But for actually using it, the first thing I'd then do is a PIP *.* over to a hard drive and use the hard drive from then on.
Addit - re the hard drive working, it is working with that code I posted but I haven't had a chance to test heaters as it is work++ over this weekend.
Cluso: Sorry no msn today, after 10 hours work and 10 hours ZiCoging and pretty much the same the day before I just had to sleep. In fact I have to sleep some more...
"I am seeing the same invalid port access message and also cannot run SURVEY :-("
SURVEY does not work for me any more either. BLOODY HELL!.l I have been running that quite often during packed floppy and HD development and test. With progressively different ZiCog versions and various CBIOSX builds. 20K, 24K. Zero HDs, 1 HD. With AUTOEXEC and with out etc. Just not on that last version I presented.
Which is a shame as that was about the first version where PIP floppy to floppy, floppy to HD etc etc works without crashing on completion. ERA *.* on floppy and HD is fine and FORMAT works without error or crash.
SURVEY is hanging for me now just before the RAM display hits the 24K mark.
I can boot the same CP/M and BIOS as drive B: on SIMH and run SURVEY where of course it works fine.
The only invalid port accesses I get are to reset the console port I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
To fit this into 24K on the Demo Board I have built a smaller than normal BIOS with only one HD. It has a size of $0C00. That's exactly how big CBIOSX.COM is. I have set msize to 24K.
BUT in my CFGCCP.LIB I have defined "bioslen equ 0F00h" and in zicog_demo.spin I have "bioslen = $F00". A little bit bigger.
So when all this is loaded into Z80 space from the file statements the end of the CBIOSX area is a bit lower than it should be according to the build i.e. My Z80 RAM area is less than 24K !!
Basically I'm lying to CP/M and ZiCog_demo about how much RAM there is so SURVEY comes along and checks RAM happily marching off the end of my Z80 RAM and corrupting Spin/PASM stuff.
Now the strange thing is if I rebuild CP/M with bioslen = 0C00 and set zicog bioslen the same then BST complains I don't have enough HUB space !
I might have to go back to 20K CP/M but then I can't use/test any HDs
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
No it is not crazy talk. Cluso has had CP/M 3 running on TriBlade. we should be able to get the bank switching sorted for CP/M 3 with banks.
So MP/M is very close.
Second thoughts, it's 2009 and we are putting CP/M on a micro-controller, we are all crazy !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Since you can emulate a CP/M machine with your ZiCog, How about emulating a TimexSinclair TS1000?
Doug
At least one person here started down the road of a ZX80/81 using ZiCog as the CPU.
The Speccy might have to much Tricky hardware to deal with but on TriBlade board who knows what's possible.
Personally I have no desire to go down that road but I'd love to someone do it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I would post the code but I left the version with packed floppies on a USB stick back at my office. So tomorrow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This was done as the SD driver deals only in 512 byte blocks so this makes for the simplest code in the emulator.
Cluso has a VB program to expand the SIMH images into this format. I have that Python script.
Of course this wastes space on SD and we end up with 32Mb images files for 8Mb disks!
What I have done now is to change the HD emulation to use 4 sectors in each HD block. So actually the image is just that from SIMH.
OK "packed" is not the right the description. They are just not expanded.
This is a bit more tricky to do and could be slower. One has to read every SD block prior to each sector write operation, up date the correct part of the block and then write it out again.
BUT what I have done is to record which SD block is currently in RAM so that it does not have to be read if a write operation refers to the same block. This keeps writes to sequential sectors up to speed. Luckily CP/M treats does a lot of sequential HD sector access because it deals in multiple sectors in "allocation blocks" on disk. There is no sector "skewing" on hard drives.
I have floppies working the same way. These really are "packed" as I we make 128 bytes sectors from the Altair 137 byte sectors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Have you got some code to post yet?
1) Calculate the SD card block that holds the sector you want
2) If that block is currently sitting in the disk buffer (from previous read) the just return the correct 128 byte chunk from the buffer.
3) If that block is not currently loaded the read it from SD and then return the sector from it.
So for 4 sequential reads within an SD block only one SD read is done.
CP/M does a lot of sequential reads due its allocation blocks. So we are onto a winner here speed wise.
No idea about the sd clock.
Code will come tomorrow after I have recovered it fro my office machine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Hopefully heater can share some of that code by the time I get home from work [noparse]:)[/noparse]
Coz there is a little throwaway comment a few posts up by heater talking about 'allocation blocks' I think these are the smallest blocks for a file, and are the reason that you can save a file with 5 characters 'hello' and it ends up 2k in size. If the drive is not fragmented, the entire allocation block ought to be contiguous. I've got a crazy idea that maybe you could go up from 512 bytes up to 1 allocation block eg 2k or maybe more. Writing a few bytes would be slower (but writing a few bytes doesn't take long anyway). But a PIP or loading a program ought to be a lot faster again. Just a thought - and would need to test it first.
I guess that might bring up the thorny issue of a delayed write buffer. I guess there is a small chance of data corruption. In practice I found that happened anyway in the course of using CP/M intensively and I found I had to reformat floppies every few months. A failed xmodem download can also corrupt a disk, and occasionally the N8VEM needs a ram disk reformat. So nothing is 100% perfect and as with all systems it pays to have backups. (I use xmodem all the time to backup to the PC, and then back that up to the N8VEM website too) So given a system that may by 99% reliable, I'd be happy to accept the extra (theoretical) risk of a delayed write buffer.
Having said that, it is the reads where this ought to have the most impact.
Post Edited (Dr_Acula) : 8/27/2009 4:33:17 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 haven't changed much over the last week. Heater has been the one doing all the cool stuff with packed drives. (I've done lots of experimenting but it was all dead-ends). I can post a few suggestions when I get home shortly. But my working program is essentially the same as your last uploaded files which I think was the 24th.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Testing took a long while because I found limiting the BIOS to just 1 hard disk I could get back to a 24K CP/M in HUB RAM (only 46 longs free now) so there was a lot of fiddling around rebuilding CP/M correctly for the demo board.
Good news is:
4 sectors per SD block floppies read/write OK
4 sectors per SD block hard disks read/write OK.
As there is now 24K CP/M RAM on the demo board PIP does not crash after finishing work (unlike me)
I found a neat way to add AUTOEXEC functionality with a simplle CBIOSX change. No CCP hacking. (not relevant to this attached file)
Bad news is:
I probably buggered up the TriBlade floppy/HD read/write routines as far as #ifdefs are concerned as I factored out some common code to new subroutines without much care to TriBlade. I thought you would need a good hard look at it whatever I did anyway.
You will notice in the file header this is v1.0_rc_1. (Version 1, Release Candidate 1). It really has to bump a major version now if we are changing the disk image formats.
So I hope Cluso and Dr_A can merge their latest changes with this and we have ZiCog V1.0.
(There are still some items outstanding for V1, like banked memory testing)
About the name, "demo" is not right because this runs on TriBlade also and perhaps Morpheus etc in the future not just a demo board. Also it is far from a simple demo of how to use the ZiCog emulator.
I leaning toward ZiCog_Altair as it is an Alatair emulation still. Or should it just be ZiCog V1?
But ZiCog is on
Heater, likewise, I will add your changes.
Heater, I only load the BOOT code into $FF00-$FFFF for the TriBlade version of ZiCog. I was thinking there are two quicker ways to do this (than what I am doing for now which is slower - originally there was a reason as I loaded the whole 64KB of CPM).
1) Load this program from a file on the SD card (just the BOOT code, not from the 64KB I am using now)
2) Compile with it embedded in the spin program, as you currently do.
1) would be far more flexible. I am not sure how this works, but I gather it then reads the boot tracks from the boot drive - is this correct? This would solve the different hardware implementation issuse, wouldn't it? Your comments???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
* Lots of debug messages commented out
* 38400 baud
* No 3 sec delay at startup waiting for the terminal to start
* 8 floppy drives and two hard drives as per the standard simh
* Works with hyperterminal and teraterm and pocketerm (I need these VT100 programs to run wordstar/games)
* Only loads first 64k of the drive_1m.dsk (which I am pondering renaming something else, eg ramimage.bin, as it is not a disk)
I'm not hugely fussed about the delay loading all the 64k of the ram, as there is a much longer delay once the zicog emulation starts.
Cheers, James
Post Edited (Dr_Acula) : 8/29/2009 2:01:52 AM GMT
I think the clean way to handle the boot code is your option 1)
a) Clear all the RAM to zero (up to FEFF anway).
b) Read DSKBOOT.COM from an SD file and put it at FF00
c) Start the emulation. The Z80 then runs up RAM executing NOPs until it hits the boot code at FF00. From there, yes, it reads the boot tracks from the boot drive and off we go.
This saves having to prepare a 64K RAM image file and is better than 2) because it saves 256 bytes of HUB space.
Then we can add a user selectable boot floppy by prompting for a drive 0-7 and "poking" that into the right byte somewhere after FF00.
Then when we want to boot from hard disk we only need to load HDSKBOOT.COM from an SD file into RAM somewhere (I think it is 5C00) in addition to DSKBOOT.COM, The user can the select boot drives 0 to 11 (currently) which gets poked to the same place in the DSKBOOT area and off we go.
This is basically what SIMH does.
As for solving the different hardware implementation issues, I have a cunning and devious plan...
Given that:
1) We would like to be able to just drop in SIMH AltairZ0 disk images after minimal sector mashing (but, importantly, not necessarily boot from them)
2) We would like to accommodate Joda and the N8VEM/PropIO guys. After all we can help them and they can help us with BIOS hacking [noparse]:)[/noparse] and cross-compatibility with many systems is always a good idea.
Then we all make a net gain by softening our stance on the "only use SIMH Altair BIOS".
Rather, we slowly start to diverge from that BIOS.
Let's face it, Altair floppy emulation is a disaster for us. Byte by byte I/O (no DMA) slows things horribly, having sector skew on the disk slows things horribly, the 137 byte sectors we already had to fix.
On top of that I already want to change the BIOS to get the AUTOEXEC function or run in 24K on the Demo Board. And we already need a small change to the CP/M 3 BIOS to get it to work on TriBlade.
The plan basically involves:
1) Changing the SIMH BIOS(s) to only support one Altair compatible floppy. So that we can drop in all those goodies that are available from SIMH (and out of respect for the Altair[noparse]:)[/noparse])
2) Changing the BIOS to support many disks via the hard disk driver (floppy or hard whatever size) giving us DMA and skew free speed.
3) Changing the BIOS to include AUTOEXEC.
4) Changing the BIOS to accomodate PropIO etc. (different port addresses etc)
5) Whatever else comes up.
Basically the changes are not huge. I believe any future SIMH Altair bug fixes/improvements could be easily back portable. Also as Yoda and Dr_A have said this new platform could end up being part of SIMH.
How cool is that ?
To that end I have already set up for myself a way of building ZiCog boot disks for DemoBoard, Triblade etc under SIMH on the PC.
OK this is getting long, more later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
ZiCog v0.10 on the Prop Demo Board Starting disks (A:B:C:D:E:F:G:H:I:) ... Passed, please wait... RAM base = 00E8 ROM base = 5AE8 Starting Z80 emulation... Passed, please wait... 24K CP/M Version 2.2 (ZiCog Prop Demo Board, BIOS V1.27, 1 HD, 29-Aug-2009) Unknown console status write with byte &H03 Punch reset SuperSUB V1.1 Submit file not found error on line number: 0 Unknown console status write with byte &H03 Punch reset A>▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: I have implemented 1) and it saves 9 seconds in booting (because I was·loading the RamDrive as well, so whole 1MB).
I love your ideas. Do we need any floppies?? as we can just use them as a 1MB hard drive - saves on code space and of course we get the speed. Of course, we will need hdp's for floppy, the 8MB hard disks, the RamDisk and a supersized hard drive. If we cannote poke the drive to boot from, then we can have a special HDISKBOOT.COM which contains multiple boots concatenated. All we do is read from a different·offset for the drive number. This is·progressing nicely
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Here is my code and the DSKBOOT_.ROM file in case you are interested. I am seeing the same invalid port access message and also cannot run SURVEY :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Re heater's 5 point plan for success, I think it looks good. 1 floppy and lots of hard drives. one floppy is still useful even if it is really slow so you can go grab a .dsk image off the simh site and drop it onto a sd card unaltered. But for actually using it, the first thing I'd then do is a PIP *.* over to a hard drive and use the hard drive from then on.
Addit - re the hard drive working, it is working with that code I posted but I haven't had a chance to test heaters as it is work++ over this weekend.
Post Edited (Dr_Acula) : 8/29/2009 6:25:58 AM GMT
Attached is a zipped·32MB "E5" file which can be used for a blank hard drive.
SURVEY only shows the floppies. Is there a program that also shows the hard drives?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 am seeing the same invalid port access message and also cannot run SURVEY :-("
SURVEY does not work for me any more either. BLOODY HELL!.l I have been running that quite often during packed floppy and HD development and test. With progressively different ZiCog versions and various CBIOSX builds. 20K, 24K. Zero HDs, 1 HD. With AUTOEXEC and with out etc. Just not on that last version I presented.
Which is a shame as that was about the first version where PIP floppy to floppy, floppy to HD etc etc works without crashing on completion. ERA *.* on floppy and HD is fine and FORMAT works without error or crash.
SURVEY is hanging for me now just before the RAM display hits the 24K mark.
I can boot the same CP/M and BIOS as drive B: on SIMH and run SURVEY where of course it works fine.
The only invalid port accesses I get are to reset the console port I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have PIP working to copy all files to the hard drives I & J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
To fit this into 24K on the Demo Board I have built a smaller than normal BIOS with only one HD. It has a size of $0C00. That's exactly how big CBIOSX.COM is. I have set msize to 24K.
BUT in my CFGCCP.LIB I have defined "bioslen equ 0F00h" and in zicog_demo.spin I have "bioslen = $F00". A little bit bigger.
So when all this is loaded into Z80 space from the file statements the end of the CBIOSX area is a bit lower than it should be according to the build i.e. My Z80 RAM area is less than 24K !!
Basically I'm lying to CP/M and ZiCog_demo about how much RAM there is so SURVEY comes along and checks RAM happily marching off the end of my Z80 RAM and corrupting Spin/PASM stuff.
Now the strange thing is if I rebuild CP/M with bioslen = 0C00 and set zicog bioslen the same then BST complains I don't have enough HUB space !
I might have to go back to 20K CP/M but then I can't use/test any HDs
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.