heater said "I was thinking about a zicog disk compilation." Zip of the first hard drive attached.
Ok, first disk is the Basic disk.
1) go to simh site http://www.schorn.ch/cpm/intro.php and download the zip
2) unzip to a working simh directory with the files from that simh package I posted a few posts back
3) edit the file ALL (no extension) and add the name of the file as an attachment eg basic.dsk as disk 1
d tracks[noparse][[/noparse]0-7] 254
attach dsk cpm2.dsk
attach dsk1 basic.dsk
attach hdsk0 i.dsk
set cpu 64k
set cpu noitrap
set cpu z80
set cpu altairrom
set cpu nonbanked
reset cpu
set sio ansi
set sio nosleep
boot dsk
bye
4) Save ALL
5) make a copy of the blank drive i.dsk (I called it Blank_Hard.dsk) for future use.
6) Run AltairAll.bat
7) PIP I:=B:*.* copy files to the hard drive image. Shut down the emulation (^E)
8) rename i.dsk as the new zicog disk eg ZICOG_B0.DSK
9) copy the blank drive i from step 5 to i.dsk
10) put the new disk image on the sd card.
Ok, I bags drive B for Basic and Drive c for C. I'll do C in a bit and post it as well.
I guess I should flag at this stage that wordstar is crashing the zicog rather badly. It works in the simh so possibly a Z80 opcode isn't emulating right, as it eventually crashes to a dump of the registers.
And I did get PACMAN working but it needs a special Wyse monitor emulation (on the Pocketerm and in a custom vb.net program I wrote) But curse your super efficient emulation, heater, because it is running too fast for me to even get close to escaping the monsters!
Look at all the lovely space free for programs!
B>dirx
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
BASCOM COM 32K ! CB80 OV3 20K ! HAMURS BAS 4K ! RANTEST COM 4K
BASCOM HLP 16K ! CB80 SUB 4K ! HORSE BAS 8K ! READ ME 40K
BASCOM SUB 4K ! CBASE2 COM 24K ! KING4K BAS 8K ! ROCKET BAS 4K
BASCOM2 HLP 32K ! CBASIC COM 24K ! LANDER4KBAS 8K ! SAMPLE BAS 4K
BASLIB REL 28K ! CBASIC SUB 4K ! LIB COM 8K ! SAMPLE COM 4K
BCLOAD 4K ! CBASXREFCOM 8K ! LINK COM 16K ! SAMPLE INT 4K
BLACKJAKBAS 8K ! CHASE BAS 4K ! LK80 COM 8K ! SAMPLE REL 4K
BLACKJAKCOM 8K ! CRUN COM 20K ! MBASIC45COM 20K ! SIEVE BAS 4K
BLACKJAKINT 4K ! CRUN2 COM 20K ! MBASIC51COM 24K ! STARTREKBAS 28K
BRUN COM 16K ! DEMOGRAFBAS 12K ! MBASIC52COM 24K ! TAXMAN BAS 8K
CB80 COM 8K ! ELIZA BAS 12K ! MSTMND BAS 4K ! TRADE BAS 16K
CB80 IRL 36K ! GRAPHCOMBAS 4K ! OBSLIB REL 48K ! TSTCIR BAS 4K
CB80 OV1 16K ! GRAPHR BAS 12K ! RANTEST ASC 4K ! WUMPUS4KBAS 12K
CB80 OV2 16K ! GSXPREP BAS 4K ! RANTEST BAS 4K ! XBASIC COM 20K
56 File(s), occupying 744K of 8136K total capacity
964 directory entries and 7392K bytes remain on B:
B>
C:\N8VEM\BDSC>altairz80 all
Altair 8800 (Z80) simulator V3.7-3 build 1016 (scp created Apr 20 2008 at 13:01:
09 with gcc 4.2.3)
64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.25, 2 HD, 15-Jan-07)
A>C:
C>TYPE HELLO.C
#include <stdio.h>
main()
{
printf("Hello World\n");
}
C>CC HELLO
BD Software C Compiler v1.60 (part I)
36K elbowroom
BD Software C Compiler v1.60 (part II)
33K to spare
C>CLINK HELLO -SW
BD Software C Linker v1.60
0D56 ISDIGIT 087F MAIN 089B PRINTF 0E12 PUTCHAR
0DDD STRLEN 0D82 _GV2 08BB _SPR 0CB7 _USPR
Last code address: 0E47
Externals start at 0E48, occupy 0006 bytes, last byte at 0E4D
Top of memory: E405
Stack space: D5B8
Writing output...
45K link space remaining
C>HELLO
Hello World
C>
Downloaded HELLO.C with XMODEMP R HELLO.C as it is quicker than pulling out the sd card. (Note that xmodem by default puts all downloads on drive A, so you need to do a PIP C:=A:HELLO.C to copy it to drive C)
On the triblade, CC.COM works but CLINK crashes after printing the first line - it then prints about 20 copies of the Z80 registers and then hangs. I'm not sure how to debug that sort of thing. But it is a similar crash to the Wordstar crash. Addit - BDS C is apparantly written in 8080 rather than Z80, as (probably) is Wordstar. Not sure if that helps narrowing down the bug. Even more strange is that BDS C and Wordstar were both working fine back in the mid August version of the zicog.
Do you have "#defiine CPU_Z80" uncommented when building ZiCog, if not things will go wonky for Z80 code. If stuff is still failing then run EXZ80DOC.COM and let's see if some tests are failing now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sorry about the delay, running the exerciser is an overnight job. It fell over at this point. There is a small chance due to CRLF issues that it may be the instruction after this one.
Not sure how to test this quicker.
Also - maybe there is a file access issue as well - both CLINK and Wordstar start off by reading files off the disk.
Re "In both files ?" - which other file?
A>exz80doc
Z80 instruction exerciser
Undefined status bits NOT taken into account
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles ERROR **** crc expected:f39089a
0 found:70201f28
add hl,<bc,de,hl,sp>..........( 35,840) cycles OK
add ix,<bc,de,ix,sp>..........( 35,840) cycles OK
add iy,<bc,de,iy,sp>..........( 35,840) cycles OK
aluop a,nn....................( 45,056) cycles OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles OK
aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles PC=253D AF=38C5 BC=C035 DE=22DD
HL=2847 IX=ACCF IY=C76E SP=234B
I have a question on the SD file structure for zicog_cpm_rc5.5b_rr118 .
Would either you Cluso99 or Dr. A or heater create a batch file script to do the formating and writing of the files on the SD card for the releases?
I realize it is early (pre V1.0 release) but it would help all those of us who are "silently" trying to follow along without waiting to V1.0 .
I believe this sort of script would be helpful if it were part of the package of files in each release to somewhat automate or to give a template for how to automate this process.
For sure a batch file or otherwise automating this process is a good idea.
I'm a little bit stuck for that:
1) Currently I only have a Prop Demo Board so the process is by necessity somewhat manual.
2) I'm using Linux, do you want a Bash script?
For now some simple step by step instructions is probably the best bet. It's not so complicated.
We'll see what we can do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
TrapperBob: Great to hear you are following
I am unsure what you are asking?
To create the files on an SD card (those provided in the various zip packages above) all that is required is for you to unzip them into a folder on your pc.
To reformat the microSD card you will require some form of adapter (either uSD to SD and an SD reader or a uSD to USB adapter).
In Windows Vista, right click on the SD card drive (I have to enable the SD driver in the device manager first) and do a format using 32KB clusters.
Then copy (copy & paste) the files expanded above to the uSD and you are done.
You may continue to add files to this SD card without reformatting, provided you do not overwrite any files or delete any files. We have to ensure they use contiguous sectors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The test "aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles" is testing instructions like "ld a, xh", "ld a, xl" etc. Where "xl" is the low byte of the X register etc.
Just so happens that ZiCog does not implement those instruction !!!
Why not you might ask?
Well those instructions do not exist in my MOSTEK Z80 Technical Manual or my Zilog Z80 Family Users Manual. I'm not sure why EXZ80DOC is testing them.
But this gets more serious and weird. There is a bunch of instructions that use an index register plus an offset e.g. "LD r,(IX + d)" which we also do not implement.
Turns out these are in my Z80 documents but in this case EXZ80DOC doe not test them.
This will take a little research to sort out. Seems my original op-code list was a bit off.
Mean while, actually why not set CPU_8080 when building ZiCog. WordStar and BDSC should detect a 8080 and behave correctly. N.B. EX8080 will fail in this case as we still set some flags like a Z80 when in 8080 mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I've not heard of those instructions. And it may be a red herring anyway.
Or it could be that the real problem is an instruction after this one and we are not getting to that because it crashes.
Or, something Cluso just said about contiguous files, I've been copying the new disk image over and overwriting the old one. Maybe overwriting does not result in contiguous code? Maybe need to delete first?
I don't think copying over existing CP/M images files will not work reliably. I'm pretty sure the new data is written to new sectors, not over the existing file sectors, and then the directory entries are pointed to the new stuff. The new sectors may be contiguous or not depending on the state of the FAT.
Mind you I have written over my images in FAT using Linux "dd" command. As we know the sector offset of the file we can exactly hit the spot with dd.
For sure those Z80 ops using HIGH and LOW index register halves are not implemented in ZiCog.
Surveying various Z80 op-code documents around the net I find many of them include those ops and perhaps they have always worked on Z80.
What seems to happen in the Z80 is that any 8080 ops that used HL get switched to using X or Y regs when the DD or FD prefix is used. Many of those combinations were not included in original Z80 documents but may have just worked anyway.
I wonder when people started to assume they were always there.
Try #define CPU_8080.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That instructions is on some Z80 compatible CPU's that have bunch of extra IO components and registers.
But was used of some people to run CPM. some have in build memory bank switch components and that instructions was useful with switch betwen bank's
some of that instructions was for on board IO components.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
heater : I understand your situation with resources. I would like a copy of a bash script though. I am looking to move back to a Linux based environment from the PC. Step-by-step instructions would be helpful to many.
Cluso99: I know the process itself is very simple. The details do get confusing at times. I have always managed to work my way through getting the right files on the SD card. The issue has been with the exact file names on the SD card versus the filenames in the zip archive throughout the history of the project. These have been in a state of flux. Also exactly which files need to go on the SD card and in what order. Having said this the most important reason for me is that I find scripts much easier to deal with over time than having to repetitively do things like copy & paste in a gui.
I (we) appreciate all your efforts on this project. I am sharing this project and its ongoing development with a number of junior high and high school children in our robotics group. They are eager to learn and enjoy learning about the "old days" meaning pre Windows XP for most. CPM and what can be accomplished with this "little board" (TriBladeProp) and the Propeller in general has very much caught their interest. I am sure you would agree.
TrapperBob: On the Prop Demo Board life is not so easy. One has to:
1) Format an SD card to FAT on a PC
2) Copy all required CP/M images there.
3) Move the card to the Prop
4) Run zicogSDptr on the Prop to find those image file sector offsets.
5) Record results
6) Paste those results into zicog_cpm.spin
7) Now you can run zicog_cpm and hopefully it finds everything on SD.
I don't see how I can automate this much but I will try to prepare detailed and accurate instructions using The new images files Dr_A and Cluso have come up with.
In a way the old system of just blasting sectors onto SD, with no FAT, was easier for Linux users and could be scripted easily. But you know what these Windows guys are like, always want to go around the houses to do anything (Just joking honest [noparse]:)[/noparse])
If I had time and knew enough about FAT I would arrange for a script that, formatted the SD and found all the files, and wrote out a Spin file containing the required offsets ready to drop into zicog. Then it would use BSTC to rebuild ZiCog and program the Prop. Bang, all in one go!
Hmm.. might not be so hard. Let me get Cluso's last modifications running here and see what can be done.
But you have a TriBlade so life should be much easier. Over to Cluso again...
You efforts with the high school children are most heartwarming. I hope they get the same buzz I did when I was fist introduced to TTL all those decades ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Bob: On the TriBlade the code automatically locates the files on the SD card so their order is unimportant. In fact I have many files on my SD card from various versions. And I run various versions all the time from the same SD card.
I am sorry, I cannot create scripts to do this (don't know how). I am not a unix person and I love my gui.
The zipped files retain the filenames. We do keep changing them - sorry about this. Hopefully ths will settle down shortly.
Keep up the good work with the school children !!!
FWIW: I am in the middle of getting the new fsrw running. It is locating the files and their block numbers successfully. However, it seems to not recover from a release (make the SD pins tristate).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
TrapperBob - do you have a triblade soldered up and ready to go? And do you have a micro sd card with some sort of reader device? If so, you are only a few minutes away from getting it working. First step is to reformat the sd card on your reader device with a right click on the drive then "reformat" with fat16. Then copy the .dsk files onto the sd card. Have you got that far?
To Cluso/Heater - something is seriously wrong with this version. It can't run a number of programs that work fine on the Aug30 version.
I have been running off just drive A, and downloading programs via xmodem so they cleanly go onto the drive. Also tried copying to a sd card image and moving that over. Same error either way. Wordstar seems to restart about 10x before it gets to the prompt.
Wordstar package attached.
I tried mbasic reading and writing a file to disk and that works. As do simple mbasic programs.
I wonder if it is the autoexec thing? I remember with the N8VEM it took me about a week to get the autoexec working. It was extremely complicated, yet seemed a simple thing to do. The errors were similar - endless restarts under certain circumstances. I'm trying to find where the autoexec bit is so I can try temporarily disabling it. Not in spin. It is coming up though in the ZIPM2_64.DSK image. How was this built, and is it possible to get a version without any autoexec?
capture of the text coming back from a wordstar startup. Eventually it progresses
[code]
A>ws
[noparse][[/noparse]H[noparse][[/noparse]J[noparse][[/noparse]0m
WordStar, CP/M Edition, Release 4.00 #21
Copyright (C) 1979, 1987 MicroPro International Corporation
All rights reserved.
Dr_A: This looks familiar. When I first implemented AUTOEXEC all hell broke loose in a similar looking way.
I had been editing the AUTOEXEC.SUB using vim under Linux. Thinking the was some problem with line endings in Unix vs CP/M I tried converting the AUTOEXEC.SUB to DOS format with the unix2dos tool. That did not work either.
The final AUTOEXEC.SUB is a cut down and modified version of MCCL.SUB. Which is still not right. You notice "; AUTOEXEC.SUB; PLACE INITIAL BOOT COMMANDS HERE" is all on one line, it should not be.
As far as I can tell CP/M text files should have 0d 0a line endings. Another thing that occurs to me now is that CP/M text files should have an "end of file" character at the end, 1a. Otherwise CP/M has no way to tell where the end is.
Are you running WS from AUTOEXEC ?
The AUTOEXEC function is enabled in the CBIOSX, as is done in SIMH. The BIOS pokes the command into CCP. This is all predicated on the original idea of CP/M that one does not have the CCP sorce to hack but is expected to customize a BIOS.
Attached is a zipm2.dsk with no autoexec enabled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have had a triblade up an operational for several months. I have been following the thread development without updating from earlier release. I believe the release was around rr80 ? So I know how to format and SD card and the hardware necessary to do so.
I have just found throughout the life of this development that the filenames in the published zip archives have routinely changed names. That seems to have been somewhat rectified. As I stated earlier having processes scripted lends to their documentation and the ability for new folks to catch on faster in my opinion.
Cluso99:
I appreciate your info on non-relevance of order( I was not sure!) and I will create an example script (.bat file) to automate this process in the future once I am sure I fully understand. I do believe as you (we) get closer to a V1.0 release many of these vagarities will disappear.
In one of the latest SD file zip files there was a .PTR file. Does this or should this be written to the SD card?
I also saw a ZICOG_A2.dsk and ZIPM2_64.DSK. What is the use for ZICOG_A2.dsk? These are the types of things some of the newer folks may struggle with understanding.
BoB:
The .PTR file is not used. I made this for heater so he could possibly use it in his 25K prop demo board.
re the filenames...
If you look at the ZiCog_cpm... (previously called ZiCog_demo...) spin file there is a routine called FindSDblock. This section list all the SD files that will be used in this version, including what drives they will be mapped to.
It is necessary to keep changing filenames when they become incompatible with the older versions of code. This is so I can run older versions of the code, together with the latest.
As you can see, there is a problem heater and drac are working on which will mean a new A: drive disk file when they fix the bug.
ZICOG_A2.DSK was to be the default name of the A: disk file with 2=CMP2.2 However, that file was only a version for 25K of user space (ram). Heater produced a new version with 64K of user space called ZIPM2_64.DSK so this is currently mapped as the A: drive - it has a bug so it's name will change when fixed.
Drac: Can we keep filenames "ZICOG_dv.DSK" where d=normal drive no (A:...H[noparse]:)[/noparse], v=CPM/MPM version (0=not specific, 2=CPM2.2, 3=CPM3, M=MPM) ? This way we can change the A: drive boot disk to vary from CPM2.2, CPM3 (banked, etc), MPM, etc
For drives with wordstar, vedit, etc, we could use "WORDSTAR.DSK", "VEDIT .DSK", "C .DSK", "BASIC .DSK", etc
Does this make sense???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Working ++ today so no time to check heaters code. Will do late tonight?
Re the names of drives, sure, call them a name that makes sense like Wordstar.dsk. Change to the drive name when you want to use that drive image. That is easy to do in Windows - indeed you could have the entire SIMH collection on a single sd card and just rename the ones you want to use.
Then I guess it is a matter of going through all those SIMH floppy images and turning them into hard drive images. PIP can do it. Maybe there is another way that is more automated?
Re TrapperBob, the simplest way to keep track of code is to start from now and work back through the threads looking for Cluso posts that have attachments. Cluso is the keeper of the 'working' latest version. Doing this myself, there is one about 2 pages back. Download that and put it in a new drive. Cluso also posted a package with the disk images. Get that and put it in the same directory, and also copy those files to the sd card. Then, you might need a couple of extra bits - I posted about 1 page back on all the extra files eg the BST exe, the BST batch file to compile with one click and then run a terminal. And a quick and simple terminal that can handle VT100 codes (otherwise Wordstar and games won't display properly). I'll post a proper step-by-step but can't until it is actually working, and right now it isn't and I'm stuck at work away from a triblade [noparse]:([/noparse]
I made some progress narrowing down the bug though.
If you try
PIP B:=CBIOSX.MAC
It will crash about half way through. Same with copying to and from any drive.
Type LS at the A> to get the file sizes. More experiments reveal that PIP crashes whenever the file size is >32k and it gets to 32k. This might help narrow down the bug (I hope there is only one!), as I think you can run PIP in your non triblade 20k version. Try a smaller file first.
So, something changes at 32k. I'm thinking of ways to try to track this down. But it would be very helpful if you can replicate the fault.
More ponderings. I think it is all the same bug. CLINK is loading up a library file >32k. Wordstar is loading up WS.OVR which is 52k. So I think the problem is *reading* files >32k.
Hmm - in CP/M in the file control block at position 15 is the record count. That clocks up every 16k if you use 128 byte records. It doesn't quite explain why things change at 32k but it might be a clue.
With the rc1_5.5b release on the Demo Board I have been able to PIP any file from anywhere to anywhere without problem.
I just now tried PIP B:=A:*.*. It does not crash. After that LS B: shows all files in place. TYPE B:BDOS.PRN scrolls what looks like all of the 168K of BDOS listing without mishap.
Release 5.5 was a big deal to me because for a long time ZiCog would crash after a PIP or any program performing a warm boot on completion. Including AUTOEXEC. The ZIBOOT and a little extra available RAM made this work again on the demo board.
Additionally the BOOT command started to work.
So this problem looks like a TriBlade issue. Or a bigger than 25K memory issue. Does it still crash when running from HUB RAM on the TriBlade ?
I will start building up my TriBlade today. At last. Might have to wait a couple of hours until "her indoors" has gone to work for some tranquil soldering time.
Cluso: Check your hotmail mail.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
After a late night email brainstorming session with Cluso last night, I've realised that I haven't removed pin 24 of the ram chip and installed a wire link. So when I get home I'll need to do this. It is surprising it works, as this is the /RD (or /OE) pin. I think it does work because there is a feature of the ram chips with a low on /RD and /WR at the same time does a write, even though this isn't a valid condition using the old-school Z80 type bus.
I'm pondering adding one more latch for another 8 output pins and even another latch for 8 inputs. Maybe poll these which you could do every few instructions and that would be quick enough to do some more (slower?) serial ports and poll a keyboard. Eg set all the inputs such that they default to high using pullups and then read in a byte and if any bit is low, ie the byte is <>255, go off and process it, but otherwise the regular checking doesn't add much overhead.
Crazy idea here - but add one 573 and use 6 pins to drive a LCD display, and 2 to drive two serial ports. On the input chip, use two pins to poll serial ports and two to poll a keyboard. 4 spare. Put the input latch into the data lines, and put the second output latch on A8 to A15. Then with two extra chips (and maybe a max232) but no mods to the existing circuit, it could do an LCD display, keyboard and two serial ports. That would be a nifty self contained computer with just one propeller.
Meanwhile, the world has run out of DIP propellers and so if one has to look at surface mount, this got me looking at ram chips and I found this interesting one from futurlec http://www.futurlec.com/Memory/628512LLFP-70.shtml which is low voltage, surface mount and it would be great if this worked as it is $8.40 and futurlec's standard shipping for small orders is $4 worldwide.
Tonight I will do that wire link and then maybe do a quick schematic with two more latches. Maybe surface mount for all??
Dr_A, I'm not sure I would go with adding more hardware to Blade 2.
At some point in the future Cluso will come up with the super high speed serial bus between blades. My presumption is that this will be able to carry multiple streams of data in a multiplexed fashion.
So the idea would be add more serial or parallel I/O using the I/O pins free on Blade 3. Hang your LCD off of that. Use the high speed serial bus to drive it all.
We should add some more serial ports to the CBIOSX which would then be interfaced via the emulator and high speed bus to the Blade 3 I/O ports.
At some point this has to be done for MP/M anyway. The SIMH MP/M already has 4 more console ports in its BIOS.
I'm toying with the idea of implementing an interrupt in ZiCog (as an option), it may well slow it down a wee bit but would help with your multitasking, serial port driving, wireless distributed CP/M.
We make up for the speed hit by over clocking the TriBlade [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sorry James, but you will not be able to do serial at any speed via latches because ZiCog cannot be interrupted sufficiently to do the test required. You see, as I keep explaining, the bus is SHARED. Reading or writing to latches can be done, but not with any timing precision. You have to shift out of that Z80 concept
I will have a small sbc smt pcb out rsn which can support 2 serial or 1 keyboard and 1 TV plus run ZiCog. Other options too, but not ready for release yet... and it's tiny and faster ram access than the TriBlade. Also able to plug into a Prop DemoBoard or other boards.
re the -OE problem. The read will work fine, but there is a bus conflict which occurs without this mod which permits the ram and the prop to drive the pins at the same time (short duration). This could result in chip failure.
Heater has the TriBlade partially running, but just needs to get a few bits tomorrow to complete :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm partly posting this because I still don't quite understand the modifications, and partly to help others who still haven't got a triblade working. I hope this is ok.
Ok, from the description in your email, you said "SO THE MODIFICATION REQUIRED TO REMOVE /OE FROM GND AND TIE TO P28 (SCL) WAS REQUIRED"
This is the modification I see on the two ram solution. But not mentioned on the one ram solution.
Let's look at a one ram board for the moment: Is the following correct?
1) Disconnect ram pin 24 from ground (lift the pin out of the socket) and connect it to physical pin 37 of the propeller (a line variously called CLK, SCL or P28 depending on the chip. I've called it CLK on my schematic)
2) Join ram pin 22 of the ram chip to pin 11 of the 573 (which is the wire link from pin 11 to pin 17 of the 573). Leaving aside the brief potential data conflict on the latch, this means that pin 22 of the ram chip (/CE or /CS) is now driven by physical pin 36 of the propeller.
I *think* the source of the confusion is not mod #1, but that mod #2 applies to 1 ram chip boards as well as 2 ram chip boards.
If the above is all correct, could I then ask whether, instead of putting the mod #1 with an output of a latch potentially feeding back into its own latch input, whether you could lift pin 24 of the ram chip and put a wire link to pin 11 of the latch (or to pin 37 of the prop).
Dracula: Thanks, I see the source of the confusion. There are two ways to wire the srams. I have not done any driver for the latchless single ram solution, so do not use this.
Therefore, the·modification described in the errata· item 5 (on thread page 6),·MUST be done no matter if 1 or two SRAMs are fitted and the LATCH 74HC573 MUST also be fitted.
The wire from pin 11 to 17 on the '573 must NOT be fitted when the latch is fitted. Therefore, ignore the photograph tribladeprop_a1d.jpg which is for a simpler pcb. There is no software support for this version of hardware at this time.
So, to recap, always build with the errata as follows
ignore the latchless single SRAM option (item 4)
for 1 or 2 SRAM(s) with the latch, wire(s) are·required from the Propeller pin 37 to SRAM(s) pin 24 and pin 24 of the SRAM(s) must be isolated from the pcb (see item 5). This has software driver support for ZiCog·etc.·
transistor overlay incorrect - see picture for correct mounting.
Comments
Ok, first disk is the Basic disk.
1) go to simh site http://www.schorn.ch/cpm/intro.php and download the zip
2) unzip to a working simh directory with the files from that simh package I posted a few posts back
3) edit the file ALL (no extension) and add the name of the file as an attachment eg basic.dsk as disk 1
4) Save ALL
5) make a copy of the blank drive i.dsk (I called it Blank_Hard.dsk) for future use.
6) Run AltairAll.bat
7) PIP I:=B:*.* copy files to the hard drive image. Shut down the emulation (^E)
8) rename i.dsk as the new zicog disk eg ZICOG_B0.DSK
9) copy the blank drive i from step 5 to i.dsk
10) put the new disk image on the sd card.
Ok, I bags drive B for Basic and Drive c for C. I'll do C in a bit and post it as well.
I guess I should flag at this stage that wordstar is crashing the zicog rather badly. It works in the simh so possibly a Z80 opcode isn't emulating right, as it eventually crashes to a dump of the registers.
And I did get PACMAN working but it needs a special Wyse monitor emulation (on the Pocketerm and in a custom vb.net program I wrote) But curse your super efficient emulation, heater, because it is running too fast for me to even get close to escaping the monsters!
Look at all the lovely space free for programs!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/16/2009 10:59:14 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Finding some bugs though. Like Wordstar, CLINK is also crashing the zicog, but is working fine on the Altair SIMH.
I wrote a tiny program in Notepad called HELLO.C (see attached)
#include <stdio.h> main() { printf("Hello World\n"); }Copied it into the SIMH with R HELLO.C
and ran the compiler
C:\N8VEM\BDSC>altairz80 all Altair 8800 (Z80) simulator V3.7-3 build 1016 (scp created Apr 20 2008 at 13:01: 09 with gcc 4.2.3) 64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.25, 2 HD, 15-Jan-07) A>C: C>TYPE HELLO.C #include <stdio.h> main() { printf("Hello World\n"); } C>CC HELLO BD Software C Compiler v1.60 (part I) 36K elbowroom BD Software C Compiler v1.60 (part II) 33K to spare C>CLINK HELLO -SW BD Software C Linker v1.60 0D56 ISDIGIT 087F MAIN 089B PRINTF 0E12 PUTCHAR 0DDD STRLEN 0D82 _GV2 08BB _SPR 0CB7 _USPR Last code address: 0E47 Externals start at 0E48, occupy 0006 bytes, last byte at 0E4D Top of memory: E405 Stack space: D5B8 Writing output... 45K link space remaining C>HELLO Hello World C>Downloaded HELLO.C with XMODEMP R HELLO.C as it is quicker than pulling out the sd card. (Note that xmodem by default puts all downloads on drive A, so you need to do a PIP C:=A:HELLO.C to copy it to drive C)
On the triblade, CC.COM works but CLINK crashes after printing the first line - it then prints about 20 copies of the Z80 registers and then hangs. I'm not sure how to debug that sort of thing. But it is a similar crash to the Wordstar crash. Addit - BDS C is apparantly written in 8080 rather than Z80, as (probably) is Wordstar. Not sure if that helps narrowing down the bug. Even more strange is that BDS C and Wordstar were both working fine back in the mid August version of the zicog.
Now that heater has a ram chip...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/16/2009 11:47:34 AM GMT
Do you have "#defiine CPU_Z80" uncommented when building ZiCog, if not things will go wonky for Z80 code. If stuff is still failing then run EXZ80DOC.COM and let's see if some tests are failing now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
'Uncomment one of the following CPU emulation types.
#define CPU_Z80
'#define CPU_8080
Running the exerciser now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Not sure how to test this quicker.
Also - maybe there is a file access issue as well - both CLINK and Wordstar start off by reading files off the disk.
Re "In both files ?" - which other file?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
I have a question on the SD file structure for zicog_cpm_rc5.5b_rr118 .
Would either you Cluso99 or Dr. A or heater create a batch file script to do the formating and writing of the files on the SD card for the releases?
I realize it is early (pre V1.0 release) but it would help all those of us who are "silently" trying to follow along without waiting to V1.0 .
I believe this sort of script would be helpful if it were part of the package of files in each release to somewhat automate or to give a template for how to automate this process.
Thanks
TrapperBob
For sure a batch file or otherwise automating this process is a good idea.
I'm a little bit stuck for that:
1) Currently I only have a Prop Demo Board so the process is by necessity somewhat manual.
2) I'm using Linux, do you want a Bash script?
For now some simple step by step instructions is probably the best bet. It's not so complicated.
We'll see what we can do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am unsure what you are asking?
To create the files on an SD card (those provided in the various zip packages above) all that is required is for you to unzip them into a folder on your pc.
To reformat the microSD card you will require some form of adapter (either uSD to SD and an SD reader or a uSD to USB adapter).
In Windows Vista, right click on the SD card drive (I have to enable the SD driver in the device manager first) and do a format using 32KB clusters.
Then copy (copy & paste) the files expanded above to the uSD and you are done.
You may continue to add files to this SD card without reformatting, provided you do not overwrite any files or delete any files. We have to ensure they use contiguous sectors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 test "aluop a,<ixh,ixl,iyh,iyl>.....(376,832) cycles" is testing instructions like "ld a, xh", "ld a, xl" etc. Where "xl" is the low byte of the X register etc.
Just so happens that ZiCog does not implement those instruction !!!
Why not you might ask?
Well those instructions do not exist in my MOSTEK Z80 Technical Manual or my Zilog Z80 Family Users Manual. I'm not sure why EXZ80DOC is testing them.
But this gets more serious and weird. There is a bunch of instructions that use an index register plus an offset e.g. "LD r,(IX + d)" which we also do not implement.
Turns out these are in my Z80 documents but in this case EXZ80DOC doe not test them.
This will take a little research to sort out. Seems my original op-code list was a bit off.
Mean while, actually why not set CPU_8080 when building ZiCog. WordStar and BDSC should detect a 8080 and behave correctly. N.B. EX8080 will fail in this case as we still set some flags like a Z80 when in 8080 mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Or it could be that the real problem is an instruction after this one and we are not getting to that because it crashes.
Or, something Cluso just said about contiguous files, I've been copying the new disk image over and overwriting the old one. Maybe overwriting does not result in contiguous code? Maybe need to delete first?
So I need to do some more experiments too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Mind you I have written over my images in FAT using Linux "dd" command. As we know the sector offset of the file we can exactly hit the spot with dd.
For sure those Z80 ops using HIGH and LOW index register halves are not implemented in ZiCog.
Surveying various Z80 op-code documents around the net I find many of them include those ops and perhaps they have always worked on Z80.
What seems to happen in the Z80 is that any 8080 ops that used HL get switched to using X or Y regs when the DD or FD prefix is used. Many of those combinations were not included in original Z80 documents but may have just worked anyway.
I wonder when people started to assume they were always there.
Try #define CPU_8080.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/17/2009 7:51:15 AM GMT
That instructions is on some Z80 compatible CPU's that have bunch of extra IO components and registers.
But was used of some people to run CPM. some have in build memory bank switch components and that instructions was useful with switch betwen bank's
some of that instructions was for on board IO components.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Cluso99: I know the process itself is very simple. The details do get confusing at times. I have always managed to work my way through getting the right files on the SD card. The issue has been with the exact file names on the SD card versus the filenames in the zip archive throughout the history of the project. These have been in a state of flux. Also exactly which files need to go on the SD card and in what order. Having said this the most important reason for me is that I find scripts much easier to deal with over time than having to repetitively do things like copy & paste in a gui.
I (we) appreciate all your efforts on this project. I am sharing this project and its ongoing development with a number of junior high and high school children in our robotics group. They are eager to learn and enjoy learning about the "old days" meaning pre Windows XP for most. CPM and what can be accomplished with this "little board" (TriBladeProp) and the Propeller in general has very much caught their interest. I am sure you would agree.
Thanks
TrapperBob
1) Format an SD card to FAT on a PC
2) Copy all required CP/M images there.
3) Move the card to the Prop
4) Run zicogSDptr on the Prop to find those image file sector offsets.
5) Record results
6) Paste those results into zicog_cpm.spin
7) Now you can run zicog_cpm and hopefully it finds everything on SD.
I don't see how I can automate this much but I will try to prepare detailed and accurate instructions using The new images files Dr_A and Cluso have come up with.
In a way the old system of just blasting sectors onto SD, with no FAT, was easier for Linux users and could be scripted easily. But you know what these Windows guys are like, always want to go around the houses to do anything (Just joking honest [noparse]:)[/noparse])
If I had time and knew enough about FAT I would arrange for a script that, formatted the SD and found all the files, and wrote out a Spin file containing the required offsets ready to drop into zicog. Then it would use BSTC to rebuild ZiCog and program the Prop. Bang, all in one go!
Hmm.. might not be so hard. Let me get Cluso's last modifications running here and see what can be done.
But you have a TriBlade so life should be much easier. Over to Cluso again...
You efforts with the high school children are most heartwarming. I hope they get the same buzz I did when I was fist introduced to TTL all those decades ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I am sorry, I cannot create scripts to do this (don't know how). I am not a unix person and I love my gui.
The zipped files retain the filenames. We do keep changing them - sorry about this. Hopefully ths will settle down shortly.
Keep up the good work with the school children !!!
FWIW: I am in the middle of getting the new fsrw running. It is locating the files and their block numbers successfully. However, it seems to not recover from a release (make the SD pins tristate).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 Cluso/Heater - something is seriously wrong with this version. It can't run a number of programs that work fine on the Aug30 version.
I have been running off just drive A, and downloading programs via xmodem so they cleanly go onto the drive. Also tried copying to a sd card image and moving that over. Same error either way. Wordstar seems to restart about 10x before it gets to the prompt.
Wordstar package attached.
I tried mbasic reading and writing a file to disk and that works. As do simple mbasic programs.
I wonder if it is the autoexec thing? I remember with the N8VEM it took me about a week to get the autoexec working. It was extremely complicated, yet seemed a simple thing to do. The errors were similar - endless restarts under certain circumstances. I'm trying to find where the autoexec bit is so I can try temporarily disabling it. Not in spin. It is coming up though in the ZIPM2_64.DSK image. How was this built, and is it possible to get a version without any autoexec?
capture of the text coming back from a wordstar startup. Eventually it progresses
[code]
A>ws
[noparse][[/noparse]H[noparse][[/noparse]J[noparse][[/noparse]0m
WordStar, CP/M Edition, Release 4.00 #21
Copyright (C) 1979, 1987 MicroPro International Corporation
All rights reserved.
i
I had been editing the AUTOEXEC.SUB using vim under Linux. Thinking the was some problem with line endings in Unix vs CP/M I tried converting the AUTOEXEC.SUB to DOS format with the unix2dos tool. That did not work either.
The final AUTOEXEC.SUB is a cut down and modified version of MCCL.SUB. Which is still not right. You notice "; AUTOEXEC.SUB; PLACE INITIAL BOOT COMMANDS HERE" is all on one line, it should not be.
As far as I can tell CP/M text files should have 0d 0a line endings. Another thing that occurs to me now is that CP/M text files should have an "end of file" character at the end, 1a. Otherwise CP/M has no way to tell where the end is.
Are you running WS from AUTOEXEC ?
The AUTOEXEC function is enabled in the CBIOSX, as is done in SIMH. The BIOS pokes the command into CCP. This is all predicated on the original idea of CP/M that one does not have the CCP sorce to hack but is expected to customize a BIOS.
Attached is a zipm2.dsk with no autoexec enabled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have had a triblade up an operational for several months. I have been following the thread development without updating from earlier release. I believe the release was around rr80 ? So I know how to format and SD card and the hardware necessary to do so.
I have just found throughout the life of this development that the filenames in the published zip archives have routinely changed names. That seems to have been somewhat rectified. As I stated earlier having processes scripted lends to their documentation and the ability for new folks to catch on faster in my opinion.
Cluso99:
I appreciate your info on non-relevance of order( I was not sure!) and I will create an example script (.bat file) to automate this process in the future once I am sure I fully understand. I do believe as you (we) get closer to a V1.0 release many of these vagarities will disappear.
In one of the latest SD file zip files there was a .PTR file. Does this or should this be written to the SD card?
I also saw a ZICOG_A2.dsk and ZIPM2_64.DSK. What is the use for ZICOG_A2.dsk? These are the types of things some of the newer folks may struggle with understanding.
The .PTR file is not used. I made this for heater so he could possibly use it in his 25K prop demo board.
re the filenames...
If you look at the ZiCog_cpm... (previously called ZiCog_demo...) spin file there is a routine called FindSDblock. This section list all the SD files that will be used in this version, including what drives they will be mapped to.
It is necessary to keep changing filenames when they become incompatible with the older versions of code. This is so I can run older versions of the code, together with the latest.
As you can see, there is a problem heater and drac are working on which will mean a new A: drive disk file when they fix the bug.
ZICOG_A2.DSK was to be the default name of the A: disk file with 2=CMP2.2 However, that file was only a version for 25K of user space (ram). Heater produced a new version with 64K of user space called ZIPM2_64.DSK so this is currently mapped as the A: drive - it has a bug so it's name will change when fixed.
Drac: Can we keep filenames "ZICOG_dv.DSK" where d=normal drive no (A:...H[noparse]:)[/noparse], v=CPM/MPM version (0=not specific, 2=CPM2.2, 3=CPM3, M=MPM) ? This way we can change the A: drive boot disk to vary from CPM2.2, CPM3 (banked, etc), MPM, etc
For drives with wordstar, vedit, etc, we could use "WORDSTAR.DSK", "VEDIT .DSK", "C .DSK", "BASIC .DSK", etc
Does this make sense???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Re the names of drives, sure, call them a name that makes sense like Wordstar.dsk. Change to the drive name when you want to use that drive image. That is easy to do in Windows - indeed you could have the entire SIMH collection on a single sd card and just rename the ones you want to use.
Then I guess it is a matter of going through all those SIMH floppy images and turning them into hard drive images. PIP can do it. Maybe there is another way that is more automated?
Re TrapperBob, the simplest way to keep track of code is to start from now and work back through the threads looking for Cluso posts that have attachments. Cluso is the keeper of the 'working' latest version. Doing this myself, there is one about 2 pages back. Download that and put it in a new drive. Cluso also posted a package with the disk images. Get that and put it in the same directory, and also copy those files to the sd card. Then, you might need a couple of extra bits - I posted about 1 page back on all the extra files eg the BST exe, the BST batch file to compile with one click and then run a terminal. And a quick and simple terminal that can handle VT100 codes (otherwise Wordstar and games won't display properly). I'll post a proper step-by-step but can't until it is actually working, and right now it isn't and I'm stuck at work away from a triblade [noparse]:([/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
#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 #elseComment out one or the other.
I made some progress narrowing down the bug though.
If you try
PIP B:=CBIOSX.MAC
It will crash about half way through. Same with copying to and from any drive.
Type LS at the A> to get the file sizes. More experiments reveal that PIP crashes whenever the file size is >32k and it gets to 32k. This might help narrow down the bug (I hope there is only one!), as I think you can run PIP in your non triblade 20k version. Try a smaller file first.
So, something changes at 32k. I'm thinking of ways to try to track this down. But it would be very helpful if you can replicate the fault.
More ponderings. I think it is all the same bug. CLINK is loading up a library file >32k. Wordstar is loading up WS.OVR which is 52k. So I think the problem is *reading* files >32k.
Hmm - in CP/M in the file control block at position 15 is the record count. That clocks up every 16k if you use 128 byte records. It doesn't quite explain why things change at 32k but it might be a clue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/19/2009 1:48:33 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 just now tried PIP B:=A:*.*. It does not crash. After that LS B: shows all files in place. TYPE B:BDOS.PRN scrolls what looks like all of the 168K of BDOS listing without mishap.
Release 5.5 was a big deal to me because for a long time ZiCog would crash after a PIP or any program performing a warm boot on completion. Including AUTOEXEC. The ZIBOOT and a little extra available RAM made this work again on the demo board.
Additionally the BOOT command started to work.
So this problem looks like a TriBlade issue. Or a bigger than 25K memory issue. Does it still crash when running from HUB RAM on the TriBlade ?
I will start building up my TriBlade today. At last. Might have to wait a couple of hours until "her indoors" has gone to work for some tranquil soldering time.
Cluso: Check your hotmail mail.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm pondering adding one more latch for another 8 output pins and even another latch for 8 inputs. Maybe poll these which you could do every few instructions and that would be quick enough to do some more (slower?) serial ports and poll a keyboard. Eg set all the inputs such that they default to high using pullups and then read in a byte and if any bit is low, ie the byte is <>255, go off and process it, but otherwise the regular checking doesn't add much overhead.
Crazy idea here - but add one 573 and use 6 pins to drive a LCD display, and 2 to drive two serial ports. On the input chip, use two pins to poll serial ports and two to poll a keyboard. 4 spare. Put the input latch into the data lines, and put the second output latch on A8 to A15. Then with two extra chips (and maybe a max232) but no mods to the existing circuit, it could do an LCD display, keyboard and two serial ports. That would be a nifty self contained computer with just one propeller.
Meanwhile, the world has run out of DIP propellers and so if one has to look at surface mount, this got me looking at ram chips and I found this interesting one from futurlec http://www.futurlec.com/Memory/628512LLFP-70.shtml which is low voltage, surface mount and it would be great if this worked as it is $8.40 and futurlec's standard shipping for small orders is $4 worldwide.
Tonight I will do that wire link and then maybe do a quick schematic with two more latches. Maybe surface mount for all??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/20/2009 8:02:40 AM GMT
At some point in the future Cluso will come up with the super high speed serial bus between blades. My presumption is that this will be able to carry multiple streams of data in a multiplexed fashion.
So the idea would be add more serial or parallel I/O using the I/O pins free on Blade 3. Hang your LCD off of that. Use the high speed serial bus to drive it all.
We should add some more serial ports to the CBIOSX which would then be interfaced via the emulator and high speed bus to the Blade 3 I/O ports.
At some point this has to be done for MP/M anyway. The SIMH MP/M already has 4 more console ports in its BIOS.
I'm toying with the idea of implementing an interrupt in ZiCog (as an option), it may well slow it down a wee bit but would help with your multitasking, serial port driving, wireless distributed CP/M.
We make up for the speed hit by over clocking the TriBlade [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I will have a small sbc smt pcb out rsn which can support 2 serial or 1 keyboard and 1 TV plus run ZiCog. Other options too, but not ready for release yet... and it's tiny and faster ram access than the TriBlade. Also able to plug into a Prop DemoBoard or other boards.
re the -OE problem. The read will work fine, but there is a bus conflict which occurs without this mod which permits the ram and the prop to drive the pins at the same time (short duration). This could result in chip failure.
Heater has the TriBlade partially running, but just needs to get a few bits tomorrow to complete :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 9/20/2009 8:23:55 AM GMT
I'm partly posting this because I still don't quite understand the modifications, and partly to help others who still haven't got a triblade working. I hope this is ok.
This photo shows your board with one ram installed www.bluemagic.biz/clusodocs/tribladeprop_a1d.jpg
This photos shows the modification with description www.bluemagic.biz/clusodocs/tribladeprop_a1b.jpg
This photo shows your schematic before any mods www.bluemagic.biz/clusodocs/tribladeprop_sch_375p2.bmp
This photo shows a modification to a two ram chip triblade http://www.bluemagic.biz/clusodocs/tribladeprop_a1c.jpg
Attached is my attempt in Eagle to redraw the schematic.
Ok, from the description in your email, you said "SO THE MODIFICATION REQUIRED TO REMOVE /OE FROM GND AND TIE TO P28 (SCL) WAS REQUIRED"
This is the modification I see on the two ram solution. But not mentioned on the one ram solution.
Let's look at a one ram board for the moment: Is the following correct?
1) Disconnect ram pin 24 from ground (lift the pin out of the socket) and connect it to physical pin 37 of the propeller (a line variously called CLK, SCL or P28 depending on the chip. I've called it CLK on my schematic)
2) Join ram pin 22 of the ram chip to pin 11 of the 573 (which is the wire link from pin 11 to pin 17 of the 573). Leaving aside the brief potential data conflict on the latch, this means that pin 22 of the ram chip (/CE or /CS) is now driven by physical pin 36 of the propeller.
I *think* the source of the confusion is not mod #1, but that mod #2 applies to 1 ram chip boards as well as 2 ram chip boards.
If the above is all correct, could I then ask whether, instead of putting the mod #1 with an output of a latch potentially feeding back into its own latch input, whether you could lift pin 24 of the ram chip and put a wire link to pin 11 of the latch (or to pin 37 of the prop).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/20/2009 11:11:43 AM GMT
Therefore, the·modification described in the errata· item 5 (on thread page 6),·MUST be done no matter if 1 or two SRAMs are fitted and the LATCH 74HC573 MUST also be fitted.
The wire from pin 11 to 17 on the '573 must NOT be fitted when the latch is fitted. Therefore, ignore the photograph tribladeprop_a1d.jpg which is for a simpler pcb. There is no software support for this version of hardware at this time.
So, to recap, always build with the errata as follows
Rev A1.3 schematic page 2 attached. Errata Rev A1.3 attached.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 9/20/2009 11:33:15 AM GMT