Can you try booting up Wordstar? You will get lots of escape characters and most of it won't make sense, but at least you will be able to see if it restarts 20x before it gets to the prompt. (Or, use the Teraterm package I uploaded last week and run it as a VT100 terminal, and then Wordstar makes sense).
Unless you are in linux and don't have a VT100 terminal program?
In which case, try compiling a C program. Get the BDS C program and write a small program to print Hello. See post from me on 16th Sept at 9:19pm. If that works...
In reference to the issue discussed by Dr_Acula et al. on September 16th, the BDS C / WS crashes due to possible opcode issues:
If it helps, here's some info on how CC/CC2/CLINK use Z80-specific ops (and to be quite honest, I cannot even recall if CLINK uses any): There's only ONE Z80-specific opcode that's ever used by the compiler or the libraries, and that's an extended block move operation. There's a subroutine (or two) used to relocate data; it works by first performing an "INR A" (increment A, I believe that was the Intel-style 8080 instruction name but it's been so damn long, lol) and checking the parity bit afterwards; if it's running on an 8080 it's one way, Z80 the other. If it sees 8080, it uses 8080 ops to do the move. Else it uses the Z80 op.
That's IT. So problems with any other Z80 opcodes would not effect BDS C compiler/linker behavior.
BrainDamage, nice to see you are following along here.
ZiCog does not implement all the extra Z80 ops yet and perhaps never will. Especially when it comes to block I/O instructions.
However we do have the block loads in place (LDI, LDD, LDIR and LDDR) and we do set flags like the Z80 rather than 8080. So there should be no problem with BDSC.
Edit: The CBIOSX we use comes from the SIMH project and uses that exact same trick of checking the behaviour of the parity flag to determine CPU type and then using LDIR or not. So I'm doubly sure now that ZiCog should be OK with BDSC. Thanks BrainDamage.
I have not seen it myself as I did not have a system with enough RAM until recently but I believe BDSC has worked on ZiCog previously. We have broken something recently. I suspect it is in my recent hacks to the CBIOSX rather than the actual emulation which has not changed much for a while.
BREAKING NEWS: As I type this my TriBlade has just completed rebuilding CP/M and installing it on A:. This is with our latest "no Altair floppies" CBIOS. It is configured slightly differently to give it a little more memory. I'm not sure yet why this makes a difference as we should be reserving enough space for the 8 hard drives to work in anyway.
When I get a moment I will try BDSC, WS etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
We are all waiting eagerly to see how these experiments go. The programs that don't work now did work ok on the floppy emulation, so something changed in the last few weeks. I don't think the instruction interpreter has changed for a while. First step might be to replicate the problem, but if it can't be replicated, well that would be even better and we can go with that version that works.
There is something really cool about a computer that can recompile its own operating system.
Cluso is in town and we are looking at catching up Sunday to brainstorm the zicog/triblade. Heater, if you have a version that has multiple hard drives and doesn't have bugs, we would eagerly look forward to a posting of the code!
OK I have to run to work and there is no time to experiment here so attached is the boot disk image that at least can rebuild CP/M and appears to not have any problem with PIP B:=A:*.* etc.
I have been running it on my TriBlade using Cluso's release zicog_cpm_rc5.5b_rr123-bst-archive-090923-170907
Only changes I made to Cluso's package was to set up my 6.5536MHz clock and replace "BLANK_I0.DSK" with "ZIPM2Z80.D02".
Note that with this "no Altair floppy" boot disk the "FindDriveBase..." for floppies is not used and the disks I: and J: become A: and B:. If that's not to confusing.
The only change I made in the CP/M was to specify "bioslen equ 1000h" instead of "bioslen equ 0C00h" in CFGCCP.LIB.
Why this makes any difference I don't know yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
rr123 as I understand it was a re-release of an older version that didn't have the bug.
The more recent one that has 8 hard drives is the one with the bug. That is version 120. I'm going to move to v123 now.
But heater, I gather you have modified rr123 so it boots to a hard drive. I tried this below with drive A as your ZIPM2Z80.D02 and that does have the bug.
But you are booting to a hard drive and don't have the bug so is it possible to describe a bit more what version etc. Maybe we all need to go back and start from the same point again?
Just working through some other minor things. I've got xmodem on drive B so I can download things. Skip the 3 sec delay at startup. Wordstar working. Big file transfers working. Compile on the board working.
'#define FloppySupport 'Uncomment for Floppy support on TriBlade only
The above line commented out. No floppy drive needed.
Just purging out some old hard drives that had been corrupted with the old code and replacing with new blank ones.
Just to be clear, I am currently using "zicog_cpm_rc5.5b_rr123-bst-archive-090923-170907".
What I do is use ZIPM2Z80.D02 in place of BLANK_I0.DSK. Oh and I forgot to mention I replaced the ROM boot image file to use ZIBOOT instead. This is important. The old DSKBOOT cannot boot CP/M built for hard drives only as the boot sectors are now non-skewed.
This results in a system that boots from hard disk 0. The ZIPM2Z80.D02 which is then running knows nothing about floppy drives. So the disk I: is now seen as disk A:.
So far everything seems to work. What I want to do now is rebuild CP/M again with the "correct" size in CFGCCP.LIB and try to find out if/why that causes a problem.
By the way I have spotted a potential problem with TriBlade and 64K RAM. Basically there is nothing in zicog.spin that stops Z80 code form writing to the ROM area. There used to be a check against ram_size which is now commented out. I think the check was removed when we were implementing bank switched memory.
Anyway the way ram_size is set up is now wrong as it does not take into account the 256bytes of ROM.
I'm away from my Prop for the rest of the day so this is the best I can offer today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Attached zip of working directory with teraterm and bst as a package. I've purged out some old files. For the sd card, copy over the files in the attached screenshot.
To compile, run bst.bat.
I've been using the N8VEM terminal program to do bulk downloads of file packages, eg the mbasic package and the sbasic package. Requires .net but it may be easier for the moment if people want a package for me to make it and upload it.
Heater, is it worth renaming your .D02 file as a .DSK file like the others (and the corresponding change in the spin code)?
And here is MBASIC running as well as the BASCOM compiler. This is a huge step forward as SUBMIT was not working before, but now it works perfectly. On a previous version there was an autoexec, maybe that could go back in now it is all working?
A>MBASIC
BASIC-80 Rev. 5.21
[noparse][[/noparse]CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
31800 Bytes free
Ok
10 PRINT "Hello World"
list
10 PRINT "Hello World"
Ok
RUN
Hello World
Ok
SAVE "HELLO",A
Ok
SYSTEM
A>TYPE BAS.SUB
BASCOM =$1 /E
L80 $1,$1/N/E
A>SUPERSUB BAS HELLO
SuperSUB V1.1
A>BASCOM =HELLO /E
00000 Fatal Error(s)
24196 Bytes Free
A>L80 HELLO,HELLO/N/E
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Data 4000 4197 < 407>
40207 Bytes Free
[noparse][[/noparse]4011 4197 65]
A>hello
Hello World
A>
That disk image only picked up an odd name as I was juggling with many different versions here.
Autoexec will go back in. Hopefully later this evening.
We are not totally out of the woods yet. I would really like to know what causes the failure.
I am beginning to see something here, following this train of thought:
1) Things like PIP will do a warm boot when they finish their work. I believe SUBMIT and many others do to.
2) Warm boot is in the CBIOSX but it depends on a byte set in the ROM to tell it what the boot device should be.
3) We don't have any write protection on our ROM code just now.
So if something is a bit wrong somewhere and tramps over the boot ROM code it can corrupt the boot device byte which then causes any subsequent warm boot to crash. i.e. PIP and such fail.
Now in a 25K system if someone is writing off the end of the BIOS data areas it probably does not get into the boot ROM area so all is OK.
So what is it that is writing off the end of the BIOS data areas ?
Perhaps I can try to trap writes to that area and find out....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think we should include the option to build with floppy support for the TriBlade. It is fairly easy to distinguish and compile that version with the #define command. I thought I would add an option to select the B: drive file (in spin) so that it is not necessary for anyone to change the source other than the #define. In fact, I will provide a precompiled binary. My idea is that anyone wanting to copy floppy files to the hard drive files could do so easily this way. All files end in ".DSK"
I would also provide hard drive versions of the floppy files we know about, such as wordstar, supercalc, turbo pascal, etc. They do not take much room when compressed.
However, the main version we require (and support) is the one with 8 hard drives and no floppies. The·first 6 hard drives·being fixed 8MB drives, the 7th maybe a huge one, and the 8th being a small RamDrive. All drives are files (as per SIMH) packed 4x128 per 512 sector, and seperate contiguous files under FAT16.
Does this make sense??? Or would you prefer to strip the floppy support and I just maintain a binary version for this???
Note: I will add the ROM check with a message later today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes, thinking about this, I've found there is more than enough room on even just one hard drive. So making one of the drives a floppy drive would make it much easier to copy over from a floppy image. Ok, that one drive might be slow, but all the hard drives would still be fast, right?
So ok, drive B is a floppy image. And you could take the entire simh collection and put them all on a sd card, and then rename the one you want in the spin code?
Or.... is it possible to read completely unmodified simh floppy images? That would take more spin code, but if you had a drive that was read-only the code for that would be simpler. Then you would never need a vb6 program.
I'm not sure now which is quicker. We have so many options.
Also, cluso, if you are free Sun, send me an email? The BBQ will be fired up and ready to go. (home phone is 8370 3353)
This gets weirder and weirder. Last night I rebuilt and used a zipm2.dsk like so:
1) bioslen set to 0D00h in CFGCCP.LIB which is the original setting used in the failing version and what should be the correct setting.
3) AUTOEXEC back in again.
2) Using that same Cluso release with floppy support but with the "#define FloppySupport" commented out and a few changes to disk image file names.
Well so far the thing works for me!!!
PIP anywhere to anywhere has worked.
AUTOEXEC seems to work.
The BOOT command works.
Rebuilding CP/M (With DO SYSZIPM2) works.
In fact I have yet to see it crash anyway.
I have attached this disk image for someone to test as I am again short of time today.
Regarding some other comments:
1) I'm quite happy if Altair floppy support stays in as long as it is under a #define. The #define should be renamed AltairFloppyDriveSupport as its the driver model we are enabling here.
2) Reading completely unmodified Altair floppies could be done but would probably require the use of "seek" in FSRW and would be immensely slow.
3) I'd like to see the disk image names in the Spin code as ALTAIR_A.DSK, ALTAIR_B.DSK for any disks requiring the Altair floppy driver. Then HD8M_A.DSK, HD8M_B.DSK ... HD1M_G.DSK, HD440K_H.DSK for our regular drives. Or something like that i.e. the file name indicates the driver and geometry rather than the content. Users can just copy whatever images they have to those names and keep track.
4) We should create 8M hard drive images of all those floppies available form SIMH. And whatever other stuff we find.
I have just destroyed my home made made PropDemo board after 2 years of service [noparse]:([/noparse]
So DemoBoard support is not guaranteed until I can make my Blade #1 look like a Demo Board.
P.S. Has anyone noticed the number of files on a disk and bytes used reported by survey is different than that reported by ls? Survey seems to be wrong. Under SIMH as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) I am sorry I must have misled you. I intended a precompiled version be available (although the released code would be able to be recompiled with the floppy #define option) to use·2 floppies A: & B:·and 1 hard drive I:·purely for use in file transfers from SIMH floppies to hard disks using PIP.·Since we will require the A: floppy to be correct for booting, this can remain in our 1x128 per 512 format for speed. However, I suggest the B: floppy be the standard Altair 137 byte format. I will write the code to support this, so we will not require the VB program for any conversion. Therefore, PIP will be used to copy from B: floppy drive (must be called "ALTAIR_B.DSK")·to I: (must be called "HD8M_B.DSK" and then it can be the B: drive in the standard 8 Hard Drive version - does this make sense ????). This will make things much easier for everyone. The SIMH B: compatability may not be ready for V1.0 (do not want to hold a release for this).
2)see above - I will write code to suport B: in the SIMH format.
3)Sounds good to me. I can't remember why we had a 1MB drive, so make A:...G: all 8MB for now, and H: the RamDrive so this size will depend on the free RAM available for this. I intend to make this a write-through drive, so anything that writes (and modifies) a disk sector will be written back to the SD drive. This should speed up things nicely. Will probably not be ready for V1.0
4)Absolutely. I have already done Turbo Pascal, SuperCalc, and another. But I combined 2 floppies together, which I now realise was a mistake.
Thinking a little further, if someone (Drac?) can·write a simple·CPM program to reside on our·A: hard drive to write to a specific I/O port, we can trap that, and therefore we could reboot the prop with a binary from the SD card. So we could launch CPM2, CPM3, MPM, the floppy version, PropDos,·or anything else for that matter. Sound interesting???? It's certainly doable·and not that difficult.·
James: Looking forward to some interesting discussions Sunday
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
1) In a way it's nice to keep the Altair driver code in there, even if never used, permanently hiding under #define. I hate to throw things away! Especially if you have adapted it to handle raw SIMH disks with no preprocessing requirements.
2) Have fun with that [noparse]:)[/noparse]
3) The 1M hard drive (and 440K) were only put there to show we could configure drives as we like using the HD driver. I suggest that whatever is used as the RAM drive has a DPB adapted to the correct geometry otherwise things will get written off the end of it tripping up unsuspecting users.
4) Is a must.
As for trapping out of the emulation I have been thinking for a long while that we need to be able to do that.
SIMH uses Control-E to do this. Dumps you into a SIMH command mode. From there you can change configuration, attached drives, inspect/set memory etc. Then the GO command starts the emulation again.
So our Spin code rather than hanging in a loop waiting for the emulation to do I/O or break could actively be looking for Control-E from the keyboard. At which point I think the best we can do is stop the emulator COG completely, no chance to resume.
If I remember correctly there is a CP/M HALT.COM command in SIMH which exactly contains a single HALT instruction. This also stops the emulation and gets you to SIMH command line mode. We could trap HALT and do the same.
I'm very jealous of you guys meeting up this weekend. Have a great time, I want to hear all about it. Hmm how much is a flight from Helsinki to Australia now.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re "Thinking a little further, if someone (Drac?) can write a simple CPM program to reside on our A: hard drive to write to a specific I/O port, we can trap that, and therefore we could reboot the prop with a binary from the SD card. So we could launch CPM2, CPM3, MPM, the floppy version, PropDos, or anything else for that matter. Sound interesting???? It's certainly doable and not that difficult."
I'll do that when I get home. Frantic at work. 31 patients in 3 hours. Will post a more detailed response in 2 hour's time...
I saw your message after I did the coding. It was too easy! Let's do it all on the board itself...
Wrote this in Wordstar in N mode. Saved it.
A>type port255.mac
; Send an out to port 255
; must have a CR/LF after END
; use zasm.sub with supersub
; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the
; mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines
;M80 =$1 /Z/C/L/M
;L80 $1,$1/N/E
LD A,1 ; change value to change version of CP/M
OUT (255),A ; send an OUT to port 255, the Zicog control port
RET ; ret to CP/M though this might reset to a new version
END ; end the program
A>supersub zasm port255.mac
SuperSUB V1.1
A>M80 =PORT255 /Z/C/L/M
No Fatal error(s)
A>L80 PORT255,PORT255/N/E
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Data 0103 0108 < 5>
46133 Bytes Free
[noparse][[/noparse]0000 0108 1]
A>port255
Write to unimplemented I/O Port &HFF
A>
Ok, so that is being trapped in the spin code
n8vem_uart_out: '&H68
out_n8vem_byte
hdskport:
out_hdskport 'SIMH style hard disk port
other:
UART.str(string("Write to unimplemented I/O Port &H"))
UART.hex(io_port,2) 'print the port number for debugging
crlf
There are lots of I/O ports free, so there are two ways to pass things. Either just call different port numbers and trap them. Or call one port (eg 255) and pass a variable in A. Which in Spin becomes a variable io_data eg
UART.tx(io_data)
Now you can pass all sorts of things. There could be a series of little programs eg in CP/M2 you could have one that reboots to CP/M3. And in CP/M 3 one that goes to CP/M2.
The advantage of that is that you can have one version of the spin code, and change things from within CP/M rather than having to compile all sorts of spin variants. Eg, reboot to a version with 2 floppy drives and 2 hard drives. Reboot to a version with a different baud rate. These can be a list of little CP/M utility programs. Maybe take the program above and print something on the screen to explain what it does. Maybe give the user the option of quitting or continuing. That is easy in assembly.
Drac: This is great. We only need to trap one address so 255 sounds great. If we send the port a comand like "RUN BOOTCPM3.BIN +crlf" we could boot that binary from the SD card. I don't think this would be that hard in spin. Likewise we could then expand to "LIST *.* +crlf" and list the files on the SD card. In fact, probably MBASIC could probably even do this for us - is there an OUT type instruction to a specific port????·
Thinking a little further, we could add all the functions required for file type access on the SD card while we suspend ZiCog by just loading·a spin program in another cog·- we have spare cogs :-)
Next, we could switch hard drives on the fly, so to speak·
I see V2.0 possibilities coming where we can combine a PropDos and CPM intermixed.
Now, we have to see how Ross can get Catalina to compile with only 512KB and SD. Maybe I have to think about some form of memory paging for this. It does not matter if it is slow, just as long as we can do it. I have had it on my list to meet him when I am in Sydney, but somehow I just never get the chance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm not sure I understand why you want to be building all these magical commands into CP/M via an I/O trap. Not say it's a bad idea just maybe I'm not on the same page as you guys yet.
A few observations:
1) SIMH gets you out of the emulation into it's command line interface by Control-E.
2) From the command line interface "go" will resume the emulation from where it left off.
3) SIMH drops to it's command line interface whenever a HALT instruction is executed.
4) Typing "go" in this case just restarts the emulation at the HALT instruction so it halts and drops out again. So use "go 0005" to do a warm start, say.
5) The HALT.COM program is just that, a single HALT instruction.
6) From the command line interface you can attach different disks and configure all manner of things. Say if you want to go from CP/M 2 to CP/M 3 or change from Z80 to 8080.
7) SIMH has CP/M programs "r.com" and "w.com" to read and write files from the CP/M file system to the underlying host file system.
8) SIMH has CP/M command HDIR.COM to give a directory listing of the files in the host file system.
Probably there are many other SIMH features I'm not familiar with yet but I always though it would be cool to eventually provide similar features (same command names etc) under ZiCog.
As it happens SIMH defines a port through which these commands (W, R, HDIR etc) are implemented much like you are suggesting.
I'm thinking we should have the same commands even if they are implemented differently with different *.COM programs.
Now Cluso, you have a magical idea. We don't have a command line level to drop down into. So perhaps we just borrow one from PropDOS (or elsewhere). Perhaps adding new commands to it for the simulation, like "go" etc. Having a text editor around would be useful also.
Anyway, can we leave all this for a "version II" because at that point we really leave DemoBoard support behind. I'd really like to get to V1 at least knowing that CP/M 2 and 3 are in good shape (Or perhaps only CP/M 2).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: Wow, it's great that a lot of this is already in SIMH, so we can duplicate/use it.
Yes, we can do a lot once we drop into spin. We can do a lot there and then continue back in ZiCog from where we left off. We have cogs available, so we can drop into PropDos and then return to ZiCog. We could even 'hot switch' on the fly between them. Definately want to use the standard SIMH port.·
I agree - this is for V2.0
I will try to get the SIMH floppy B: running - I am not aiming for speed as it is just for PIP. If I make it for V1.0 well and good, but if not, then V1.5 will be fine.
I would like to tidy the code some more (before V1.0 release) with comments, etc·(the ZiCog CPM section, not your pasm) so let me know when it is an opportune time to do so. I do not expect to have time later next week (funeral with relos coming from oseas and interstate).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yep, SIMH has the functionality we want. We should duplicate the commands as much as possible if only for convenience of use. Not having to remember two different ways to do the same thing and being able to use the same BATCH files on SIMH and ZiCog. However we may not want to use exactly the same SIMH port and other implementation details. Lets see how easy it is on the Prop in Spin.
Is it OK if I try to squeeze a few more tests in tomorrow and if all is well put up my working version. After that if you have the new fsrw drivers working we may as well tidy up and put out V1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
In which case, try compiling a C program. Get the BDS C program and write a small program to print Hello. See post from me on 16th Sept at 9:19pm. If that works...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
If it helps, here's some info on how CC/CC2/CLINK use Z80-specific ops (and to be quite honest, I cannot even recall if CLINK uses any): There's only ONE Z80-specific opcode that's ever used by the compiler or the libraries, and that's an extended block move operation. There's a subroutine (or two) used to relocate data; it works by first performing an "INR A" (increment A, I believe that was the Intel-style 8080 instruction name but it's been so damn long, lol) and checking the parity bit afterwards; if it's running on an 8080 it's one way, Z80 the other. If it sees 8080, it uses 8080 ops to do the move. Else it uses the Z80 op.
That's IT. So problems with any other Z80 opcodes would not effect BDS C compiler/linker behavior.
Good luck!
ZiCog does not implement all the extra Z80 ops yet and perhaps never will. Especially when it comes to block I/O instructions.
However we do have the block loads in place (LDI, LDD, LDIR and LDDR) and we do set flags like the Z80 rather than 8080. So there should be no problem with BDSC.
Edit: The CBIOSX we use comes from the SIMH project and uses that exact same trick of checking the behaviour of the parity flag to determine CPU type and then using LDIR or not. So I'm doubly sure now that ZiCog should be OK with BDSC. Thanks BrainDamage.
I have not seen it myself as I did not have a system with enough RAM until recently but I believe BDSC has worked on ZiCog previously. We have broken something recently. I suspect it is in my recent hacks to the CBIOSX rather than the actual emulation which has not changed much for a while.
BREAKING NEWS: As I type this my TriBlade has just completed rebuilding CP/M and installing it on A:. This is with our latest "no Altair floppies" CBIOS. It is configured slightly differently to give it a little more memory. I'm not sure yet why this makes a difference as we should be reserving enough space for the 8 hard drives to work in anyway.
When I get a moment I will try BDSC, WS etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/30/2009 6:22:03 AM GMT
There is something really cool about a computer that can recompile its own operating system.
Cluso is in town and we are looking at catching up Sunday to brainstorm the zicog/triblade. Heater, if you have a version that has multiple hard drives and doesn't have bugs, we would eagerly look forward to a posting of the code!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/30/2009 7:27:21 AM GMT
I have been running it on my TriBlade using Cluso's release zicog_cpm_rc5.5b_rr123-bst-archive-090923-170907
Only changes I made to Cluso's package was to set up my 6.5536MHz clock and replace "BLANK_I0.DSK" with "ZIPM2Z80.D02".
Note that with this "no Altair floppy" boot disk the "FindDriveBase..." for floppies is not used and the disks I: and J: become A: and B:. If that's not to confusing.
The only change I made in the CP/M was to specify "bioslen equ 1000h" instead of "bioslen equ 0C00h" in CFGCCP.LIB.
Why this makes any difference I don't know yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The more recent one that has 8 hard drives is the one with the bug. That is version 120. I'm going to move to v123 now.
But heater, I gather you have modified rr123 so it boots to a hard drive. I tried this below with drive A as your ZIPM2Z80.D02 and that does have the bug.
But you are booting to a hard drive and don't have the bug so is it possible to describe a bit more what version etc. Maybe we all need to go back and start from the same point again?
#ifdef cpm2 ' FindDriveBase(0, string("ZIPM2 .DSK")) 'set the SD card drive base(s) 8MB CPM2.2 ' FindDriveBase(0, string("ZIPM2_64.DSK")) 'set the SD card drive base(s) 8MB CPM2.2 FindDriveBase(0, string("ZIPM2Z80.D02")) 'set the SD card drive base(s) 8MB CPM2.2 #else 'FindDriveBase(0, string("ZICOG_A3.DSK")) 'set the SD card drive base(s) 8MB CPM3 nonbanked #endif FindDriveBase(1, string("ZICOG_B0.DSK")) 'set the SD card drive base(s) 8MB FindDriveBase(2, string("ZICOG_C0.DSK")) 'set the SD card drive base(s) 8MB FindDriveBase(3, string("ZICOG_D0.DSK")) 'set the SD card drive base(s) 8MB FindDriveBase(4, string("ZICOG_E0.DSK")) 'set the SD card drive base(s) 8MB vedit & pascal FindDriveBase(5, string("ZICOG_F0.DSK")) 'set the SD card drive base(s) 8MB supercalc FindDriveBase(6, string("ZICOG_G0.DSK")) 'set the SD card drive base(s) 1MB equiv floppy FindDriveBase(7, string("ZICOG_H0.DSK")) 'set the SD card drive base(s) <1MB RamDisk 'other files Q:,R: FindDriveBase(17,string("ZIBOOT .COM")) 'set the SD card drive base(s) $FF00 for boot hdisk #endifAddit: no bug so far with heaters new code. Stay tuned...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/30/2009 10:01:17 AM GMT
So, if the bug is not present, then the fix is in the ZIPM2Z80.D01 disk file, which is where I thought the bug was. I will look in the morning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
#ifdef cpm2 ' FindDriveBase(0, string("ZIPM2 .DSK")) 'set the SD card drive base(s) 8MB CPM2.2 25KB ' FindDriveBase(0, string("ZIPM2_64.DSK")) 'set the SD card drive base(s) 8MB CPM2.2 FindDriveBase(0, string("zipm2z80.d02")) 'set the SD card drive base(s) 8MB CPM2.2 #else 'FindDriveBase(0, string("ZICOG_A3.DSK")) 'set the SD card drive base(s) 8MB CPM3 nonbanked #endif FindDriveBase(1, string("ZICOG_B0.DSK")) 'set the SD card drive base(s) 8MB FindDriveBase(2, string("ZICOG_C0.DSK")) 'set the SD card drive base(s) 8MB FindDriveBase(2, string("ZICOG_D0.DSK")) 'set the SD card drive base(s) 8MB Dr_A xmodem+ FindDriveBase(3, string("ZICOG_E0.DSK")) 'set the SD card drive base(s) 8MB FindDriveBase(5, string("ZICOG_F0.DSK")) 'set the SD card drive base(s) 8MB FindDriveBase(6, string("ZICOG_G0.DSK")) 'set the SD card drive base(s) 1MB equiv floppy FindDriveBase(7, string("ZICOG_H0.DSK")) 'set the SD card drive base(s) <1MB RamDisk 'other files Q:,R: FindDriveBase(17,string("ZIBOOT .COM")) 'set the SD card drive base(s) $FF00 for boot hdisk #endifZIPM2Z80.D02 is drive A (heater's new drive)
Just working through some other minor things. I've got xmodem on drive B so I can download things. Skip the 3 sec delay at startup. Wordstar working. Big file transfers working. Compile on the board working.
The above line commented out. No floppy drive needed.
Just purging out some old hard drives that had been corrupted with the old code and replacing with new blank ones.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/30/2009 10:45:49 AM GMT
What I do is use ZIPM2Z80.D02 in place of BLANK_I0.DSK. Oh and I forgot to mention I replaced the ROM boot image file to use ZIBOOT instead. This is important. The old DSKBOOT cannot boot CP/M built for hard drives only as the boot sectors are now non-skewed.
This results in a system that boots from hard disk 0. The ZIPM2Z80.D02 which is then running knows nothing about floppy drives. So the disk I: is now seen as disk A:.
So far everything seems to work. What I want to do now is rebuild CP/M again with the "correct" size in CFGCCP.LIB and try to find out if/why that causes a problem.
By the way I have spotted a potential problem with TriBlade and 64K RAM. Basically there is nothing in zicog.spin that stops Z80 code form writing to the ROM area. There used to be a check against ram_size which is now commented out. I think the check was removed when we were implementing bank switched memory.
Anyway the way ram_size is set up is now wrong as it does not take into account the 256bytes of ROM.
I'm away from my Prop for the rest of the day so this is the best I can offer today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Attached zip of working directory with teraterm and bst as a package. I've purged out some old files. For the sd card, copy over the files in the attached screenshot.
To compile, run bst.bat.
I've been using the N8VEM terminal program to do bulk downloads of file packages, eg the mbasic package and the sbasic package. Requires .net but it may be easier for the moment if people want a package for me to make it and upload it.
Heater, is it worth renaming your .D02 file as a .DSK file like the others (and the corresponding change in the spin code)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/30/2009 11:19:34 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
That disk image only picked up an odd name as I was juggling with many different versions here.
Autoexec will go back in. Hopefully later this evening.
We are not totally out of the woods yet. I would really like to know what causes the failure.
I am beginning to see something here, following this train of thought:
1) Things like PIP will do a warm boot when they finish their work. I believe SUBMIT and many others do to.
2) Warm boot is in the CBIOSX but it depends on a byte set in the ROM to tell it what the boot device should be.
3) We don't have any write protection on our ROM code just now.
So if something is a bit wrong somewhere and tramps over the boot ROM code it can corrupt the boot device byte which then causes any subsequent warm boot to crash. i.e. PIP and such fail.
Now in a 25K system if someone is writing off the end of the BIOS data areas it probably does not get into the boot ROM area so all is OK.
So what is it that is writing off the end of the BIOS data areas ?
Perhaps I can try to trap writes to that area and find out....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
But write protecting the ROM code is definitely a priority.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
(and waiting for your 1.0 release. [noparse];)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I think we should include the option to build with floppy support for the TriBlade. It is fairly easy to distinguish and compile that version with the #define command. I thought I would add an option to select the B: drive file (in spin) so that it is not necessary for anyone to change the source other than the #define. In fact, I will provide a precompiled binary. My idea is that anyone wanting to copy floppy files to the hard drive files could do so easily this way. All files end in ".DSK"
I would also provide hard drive versions of the floppy files we know about, such as wordstar, supercalc, turbo pascal, etc. They do not take much room when compressed.
However, the main version we require (and support) is the one with 8 hard drives and no floppies. The·first 6 hard drives·being fixed 8MB drives, the 7th maybe a huge one, and the 8th being a small RamDrive. All drives are files (as per SIMH) packed 4x128 per 512 sector, and seperate contiguous files under FAT16.
Does this make sense??? Or would you prefer to strip the floppy support and I just maintain a binary version for this???
Note: I will add the ROM check with a message later today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So ok, drive B is a floppy image. And you could take the entire simh collection and put them all on a sd card, and then rename the one you want in the spin code?
Or.... is it possible to read completely unmodified simh floppy images? That would take more spin code, but if you had a drive that was read-only the code for that would be simpler. Then you would never need a vb6 program.
I'm not sure now which is quicker. We have so many options.
Also, cluso, if you are free Sun, send me an email? The BBQ will be fired up and ready to go. (home phone is 8370 3353)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 10/1/2009 1:44:32 AM GMT
1) bioslen set to 0D00h in CFGCCP.LIB which is the original setting used in the failing version and what should be the correct setting.
3) AUTOEXEC back in again.
2) Using that same Cluso release with floppy support but with the "#define FloppySupport" commented out and a few changes to disk image file names.
Well so far the thing works for me!!!
PIP anywhere to anywhere has worked.
AUTOEXEC seems to work.
The BOOT command works.
Rebuilding CP/M (With DO SYSZIPM2) works.
In fact I have yet to see it crash anyway.
I have attached this disk image for someone to test as I am again short of time today.
Regarding some other comments:
1) I'm quite happy if Altair floppy support stays in as long as it is under a #define. The #define should be renamed AltairFloppyDriveSupport as its the driver model we are enabling here.
2) Reading completely unmodified Altair floppies could be done but would probably require the use of "seek" in FSRW and would be immensely slow.
3) I'd like to see the disk image names in the Spin code as ALTAIR_A.DSK, ALTAIR_B.DSK for any disks requiring the Altair floppy driver. Then HD8M_A.DSK, HD8M_B.DSK ... HD1M_G.DSK, HD440K_H.DSK for our regular drives. Or something like that i.e. the file name indicates the driver and geometry rather than the content. Users can just copy whatever images they have to those names and keep track.
4) We should create 8M hard drive images of all those floppies available form SIMH. And whatever other stuff we find.
I have just destroyed my home made made PropDemo board after 2 years of service [noparse]:([/noparse]
So DemoBoard support is not guaranteed until I can make my Blade #1 look like a Demo Board.
P.S. Has anyone noticed the number of files on a disk and bytes used reported by survey is different than that reported by ls? Survey seems to be wrong. Under SIMH as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) I am sorry I must have misled you. I intended a precompiled version be available (although the released code would be able to be recompiled with the floppy #define option) to use·2 floppies A: & B:·and 1 hard drive I:·purely for use in file transfers from SIMH floppies to hard disks using PIP.·Since we will require the A: floppy to be correct for booting, this can remain in our 1x128 per 512 format for speed. However, I suggest the B: floppy be the standard Altair 137 byte format. I will write the code to support this, so we will not require the VB program for any conversion. Therefore, PIP will be used to copy from B: floppy drive (must be called "ALTAIR_B.DSK")·to I: (must be called "HD8M_B.DSK" and then it can be the B: drive in the standard 8 Hard Drive version - does this make sense ????). This will make things much easier for everyone. The SIMH B: compatability may not be ready for V1.0 (do not want to hold a release for this).
2)see above - I will write code to suport B: in the SIMH format.
3)Sounds good to me. I can't remember why we had a 1MB drive, so make A:...G: all 8MB for now, and H: the RamDrive so this size will depend on the free RAM available for this. I intend to make this a write-through drive, so anything that writes (and modifies) a disk sector will be written back to the SD drive. This should speed up things nicely. Will probably not be ready for V1.0
4)Absolutely. I have already done Turbo Pascal, SuperCalc, and another. But I combined 2 floppies together, which I now realise was a mistake.
Thinking a little further, if someone (Drac?) can·write a simple·CPM program to reside on our·A: hard drive to write to a specific I/O port, we can trap that, and therefore we could reboot the prop with a binary from the SD card. So we could launch CPM2, CPM3, MPM, the floppy version, PropDos,·or anything else for that matter. Sound interesting???? It's certainly doable·and not that difficult.·
James: Looking forward to some interesting discussions Sunday
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Not much time to think for now but:
1) In a way it's nice to keep the Altair driver code in there, even if never used, permanently hiding under #define. I hate to throw things away! Especially if you have adapted it to handle raw SIMH disks with no preprocessing requirements.
2) Have fun with that [noparse]:)[/noparse]
3) The 1M hard drive (and 440K) were only put there to show we could configure drives as we like using the HD driver. I suggest that whatever is used as the RAM drive has a DPB adapted to the correct geometry otherwise things will get written off the end of it tripping up unsuspecting users.
4) Is a must.
As for trapping out of the emulation I have been thinking for a long while that we need to be able to do that.
SIMH uses Control-E to do this. Dumps you into a SIMH command mode. From there you can change configuration, attached drives, inspect/set memory etc. Then the GO command starts the emulation again.
So our Spin code rather than hanging in a loop waiting for the emulation to do I/O or break could actively be looking for Control-E from the keyboard. At which point I think the best we can do is stop the emulator COG completely, no chance to resume.
If I remember correctly there is a CP/M HALT.COM command in SIMH which exactly contains a single HALT instruction. This also stops the emulation and gets you to SIMH command line mode. We could trap HALT and do the same.
I'm very jealous of you guys meeting up this weekend. Have a great time, I want to hear all about it. Hmm how much is a flight from Helsinki to Australia now.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'll do that when I get home. Frantic at work. 31 patients in 3 hours. Will post a more detailed response in 2 hour's time...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I saw your message after I did the coding. It was too easy! Let's do it all on the board itself...
Wrote this in Wordstar in N mode. Saved it.
A>type port255.mac ; Send an out to port 255 ; must have a CR/LF after END ; use zasm.sub with supersub ; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the ; mac in the instruction - m80 knows it is implied) ; zasm.sub is the following two lines ;M80 =$1 /Z/C/L/M ;L80 $1,$1/N/E LD A,1 ; change value to change version of CP/M OUT (255),A ; send an OUT to port 255, the Zicog control port RET ; ret to CP/M though this might reset to a new version END ; end the program A>supersub zasm port255.mac SuperSUB V1.1 A>M80 =PORT255 /Z/C/L/M No Fatal error(s) A>L80 PORT255,PORT255/N/E Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft Data 0103 0108 < 5> 46133 Bytes Free [noparse][[/noparse]0000 0108 1] A>port255 Write to unimplemented I/O Port &HFF A>Ok, so that is being trapped in the spin code
n8vem_uart_out: '&H68 out_n8vem_byte hdskport: out_hdskport 'SIMH style hard disk port other: UART.str(string("Write to unimplemented I/O Port &H")) UART.hex(io_port,2) 'print the port number for debugging crlfThere are lots of I/O ports free, so there are two ways to pass things. Either just call different port numbers and trap them. Or call one port (eg 255) and pass a variable in A. Which in Spin becomes a variable io_data eg
UART.tx(io_data)
Now you can pass all sorts of things. There could be a series of little programs eg in CP/M2 you could have one that reboots to CP/M3. And in CP/M 3 one that goes to CP/M2.
The advantage of that is that you can have one version of the spin code, and change things from within CP/M rather than having to compile all sorts of spin variants. Eg, reboot to a version with 2 floppy drives and 2 hard drives. Reboot to a version with a different baud rate. These can be a list of little CP/M utility programs. Maybe take the program above and print something on the screen to explain what it does. Maybe give the user the option of quitting or continuing. That is easy in assembly.
Is this more flexible than a ^E and a Halt?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Thinking a little further, we could add all the functions required for file type access on the SD card while we suspend ZiCog by just loading·a spin program in another cog·- we have spare cogs :-)
Next, we could switch hard drives on the fly, so to speak·
I see V2.0 possibilities coming where we can combine a PropDos and CPM intermixed.
Now, we have to see how Ross can get Catalina to compile with only 512KB and SD. Maybe I have to think about some form of memory paging for this. It does not matter if it is slow, just as long as we can do it. I have had it on my list to meet him when I am in Sydney, but somehow I just never get the chance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
A few observations:
1) SIMH gets you out of the emulation into it's command line interface by Control-E.
2) From the command line interface "go" will resume the emulation from where it left off.
3) SIMH drops to it's command line interface whenever a HALT instruction is executed.
4) Typing "go" in this case just restarts the emulation at the HALT instruction so it halts and drops out again. So use "go 0005" to do a warm start, say.
5) The HALT.COM program is just that, a single HALT instruction.
6) From the command line interface you can attach different disks and configure all manner of things. Say if you want to go from CP/M 2 to CP/M 3 or change from Z80 to 8080.
7) SIMH has CP/M programs "r.com" and "w.com" to read and write files from the CP/M file system to the underlying host file system.
8) SIMH has CP/M command HDIR.COM to give a directory listing of the files in the host file system.
Probably there are many other SIMH features I'm not familiar with yet but I always though it would be cool to eventually provide similar features (same command names etc) under ZiCog.
As it happens SIMH defines a port through which these commands (W, R, HDIR etc) are implemented much like you are suggesting.
I'm thinking we should have the same commands even if they are implemented differently with different *.COM programs.
Now Cluso, you have a magical idea. We don't have a command line level to drop down into. So perhaps we just borrow one from PropDOS (or elsewhere). Perhaps adding new commands to it for the simulation, like "go" etc. Having a text editor around would be useful also.
Anyway, can we leave all this for a "version II" because at that point we really leave DemoBoard support behind. I'd really like to get to V1 at least knowing that CP/M 2 and 3 are in good shape (Or perhaps only CP/M 2).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, we can do a lot once we drop into spin. We can do a lot there and then continue back in ZiCog from where we left off. We have cogs available, so we can drop into PropDos and then return to ZiCog. We could even 'hot switch' on the fly between them. Definately want to use the standard SIMH port.·
I agree - this is for V2.0
I will try to get the SIMH floppy B: running - I am not aiming for speed as it is just for PIP. If I make it for V1.0 well and good, but if not, then V1.5 will be fine.
I would like to tidy the code some more (before V1.0 release) with comments, etc·(the ZiCog CPM section, not your pasm) so let me know when it is an opportune time to do so. I do not expect to have time later next week (funeral with relos coming from oseas and interstate).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Is it OK if I try to squeeze a few more tests in tomorrow and if all is well put up my working version. After that if you have the new fsrw drivers working we may as well tidy up and put out V1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.