Question: I have a short on both the 5v rail and the 3.3v rail. I don't have any regulators installed, and I'm at a loss on how to find the short. Obviously I've checked for pins soldered together but I can't find anything. I asked an electronics guy and he suggested that I may have scratched the soldermask and hit the copper groundplane, then had a solder bridge to that. Is that feasible? I looked at all the connections and that doesn't appear to be the case, but I can't see if the solder flowed through a hole and made a connection under a socket. I tried using an ohmmeter to measure the resistance at various close power pins, but I don't think it can accuratly measure tenths of an ohm.
Edit: some more testing and looking still hasn't turned up the culprit. I tried passing 6A through the 5V input header near the RCA jack, but it didn't show up any shorts.
SLRM: I am not quite sure where you short is. Do you mean that the 5V and 3.3V rails are shorted together? Or do you mean both are shorted to ground? What component have you fitted (a photo may be easier than listing the parts)?
All pcbs were supposed to be electrically tested and I believe this to be the case as there were a number of reject pcbs.
If the short is between 5v and 3.3V then the 5V track is fairly short so it should be fairly easy to find.
I have included the copper sections attached. The red is the top, blue the bottom.·This is the strip you should be looking at for a short between the solder pads and the surrounding copper.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I get a short from 5v to ground, 3.3v to ground, and 5v to 3.3v. I tried passing 2A continuous through the board and measuring the voltage at different places, and I got the lowest voltage reading on blade three. It was in the range of tens of millivolts, but I'm not sure that it means anything. I've attached pictures of the board. At first I thought that the short was from the wrong type of regulator, so I removed both regulators. That wasn't it though... I don't have any chips onboard except the FTDI chip. Everything else is sockets. Thanks for the sections, I'll take a look at those.
The voltage out pins in the bottom right-hand corner (from front) look like there solder is jointed between the 3.3v and ground. That looks like that is it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
I see on the underside that the power connector pins at the bottom look like there may be a short. Unfortunately your pics are not that clear.
The easiest way may be to expand my picture (the red one) and follow the 5V copper and look for this short. Start at the 5V pad in the centre of the picture near the words "M"ouse. While the black outline is not al that clear I hope it will give you a clue to where the short is.
I would start at C1, C2, C3 and J3. Then check the mouse and VGA pins.
BTW Tantalums were recommended for C2 & C3. While it will probably be ok, I cannot guarantee this. Do not overclock the props unless you fit a tantalum under each prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The following is the answer to questions asked in a PM that I thought I would share with you.
The TriBlade is basically 5 seperate (self-contained) sections...
power supply (5V & 3V3 regulators)
PropPlug equivalent (USB to serial with reset capability)
Blade #1: Propeller chip with options for EEPROM, VGA, TV, Keyboard, Mouse, 512KByte SRAM using a latch, and 1-8MByte SPI Flash chip. Some options preclude others. It has a PropPlug input header.
Blade #2: Propeller chip with options for EEPROM, 2 x 512KByte (2 x 2MByte with very expensive chips) SRAM, latch for address decoding and resets to Blades #1 & #3, microSD socket, 1-8MByte SPI Flash chip. It has a PropPlug input header. The only external connection is via the 2 pin I/O which is also on the PropPlug header as all I/Os are used with the SRAM, etc.
Blade #3: Propeller chip with options for EEPROM and various header pins for connections to the unused I/Os. It has a PropPlug input header and another 2 wire (serial) connection to #2.
Now for the interconnection and programmability...
I have designed the pcb with the objective that #2 can reprogram #1 & #3 so an EEPROM is not required for #1 and/or #3.
It is not required to fit all options, nor all props, nor the internal PropPlug (external PropPlug OK).
So the pcb is EXTREMELY flexible although that is not apparent from the circuit.
I have a 2 wire bus that can be linked between #1 - #2 - #3 (P30 & P31) so that they can communicate via a 2 wire protocol. I envisage an ultra high speed serial (as Beau has proved) >1MBytes/s protocol between the 3 Blades (props). So far, I only have connected 2 blades together so have just used plainf FullDuplexSerial at 115200 baud.
#2 can boot a propeller binary from the uSD card with appropriate code in the EEPROM (working). The binary can be PropDos, ZiCog + CPM, or any other prop binary (working).
So, to answer your question, the props on the TriBlade are seperate AND able to interact, AND yes one prop can instruct/command/program the others (via #2).
You may also like to·see the RamBlade and TwinBlade threads, although progress has been slow due to other constraints.
Shameless plug: There are still a few pcbs available.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Answers for the TriBlade from questions on the ZiCog thread...
The best place to start is download the code and SD card files from the post at the top of Page 4 of this thread. There is a good explanation of the files. Near the bottom of·that page is a binary file which can be programmed into the eeprom to boot PropCmd and a binary file to place on the SD card to boot ZiCog.
Page 4 also contains a lot of information about the TriBlade and ZiCog and I suggest you read this.
As soon as I can get a new TriBlade built I will publish the latest code.
TriBlade "ZiCog_demoXXX_rrXXX.spin" code is for Blade #2 ONLY:
PC_Keyboard.spin and PC_Text.spin use the serial (program pins) to connect via a propplug (or equivalent) to the PC and the PC runs PropTerminal to emulate the Keyboard and Display. DO NOT substitute these with "Keyboard.spin, VGA.spin or TV_text". The TriBlade #2 does not support the keyboard or display (tv or vga) on this prop. It can communicate via the serial lines to another prop (Blade #1 or #3) which can act as a terminal, depending on the options wired.
1. Get ZiCog running on Blade #2 to the PC
2. Make sure you can do a SURVEY and run MSBasic
3. Now get Blade #1 running a Terminal Program (and the PC via propplug)
4. Now you can modify Blades #1 & #2 to talk to each other, replacing the PC.
I will post more details for this when I get my next TriBlade working.
Hope this helps for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
It is all very close now. On the link at the top of page 4 of this thread is a link to a zip file called TriBladeProp_Zicog_rr068.zip Unzip this as a package and it contains a file z.bat. This contains a line
homespun024 zicog_demo006_rr069 -b -d -i3 -w
a minor bug in that the file demo006_rr069 does not exist in the zip. It is actually rr068 so I changed it to 68
(I seem to have a file rr090 so this appears to be a fairly old version)
However, the zip package does compile as a unit which is great news! A few warning messages:
C:\Propeller\zicog68>homespun024 zicog_demo006_rr068 -b -d -i3 -w
Homespun Spin Compiler 0.24
parsing zicog_demo006_rr068.spin
parsing zicog005_rr021.spin
Warning: zicog005_rr021.spin (191, 33): JMP with non-immediate operand
vect_1 jmp vector 'Jump to the instruct
ion handler
^
Warning: zicog005_rr021.spin (195, 33): JMP with non-immediate operand
jmp vector
^
Warning: zicog005_rr021.spin (369, 33): JMP with non-immediate operand
if_nz jmp jump_rel_unconditional 'Jump if not zero
^
Warning: zicog005_rr021.spin (1446, 33): JMP with non-immediate operand
jmp OVERLAY_LOAD_RET 'return (indirect) to
calling routine
^
parsing PC_Keyboard.spin
parsing PC_Text.spin
parsing TriBladeProp_Blade2_201.spin
parsing FullDuplexSerialPlus.spin
parsing fsrwFemto.spin
parsing sdspiFemto.spin
compiling zicog_demo006_rr068.spin
compiling zicog005_rr021.spin
compiling PC_Keyboard.spin
compiling PC_Text.spin
compiling TriBladeProp_Blade2_201.spin
compiling FullDuplexSerialPlus.spin
compiling fsrwFemto.spin
compiling sdspiFemto.spin
writing zicog_demo006_rr068.binary
Writing listing to zicog_demo006_rr068.lst
Then had to drop the baud rate back to 38400 (that is just me and my 2 metre serial cable) and I've got it to the point of printing:
TriBladeProp: Load SRAM from microSD (Y/N)?
Ok, on to getting some files on the sd card...
Addit:
Getting an error saying the code is halting when reading the sd card.
I see this code:
FindDriveBase(0, string("DRIVE__A.DSK")) 'set the SD card drive base(s)
FindDriveBase(1, string("DRIVE__B.DSK")) 'set the SD card drive base(s)
FindDriveBase(2, string("DRIVE__C.DSK")) 'set the SD card drive base(s)
FindDriveBase(3, string("DRIVE__D.DSK")) 'set the SD card drive base(s)
FindDriveBase(4, string("DRIVE__E.DSK")) 'set the SD card drive base(s)
FindDriveBase(5, string("DRIVE__F.DSK")) 'set the SD card drive base(s)
FindDriveBase(6, string("DRVCPM_2.DSK")) 'set the SD card drive base(s)
FindDriveBase(7, string("DRVCPM_3.DSK")) 'set the SD card drive base(s)
r := sd.stopSDCard 'stop SD card, but do not stop cog
check_error(r)
But the package at the top of page 4 only contains 3 files. Could the missing files be the reason it is halting?
Post Edited (Dr_Acula (James Moxham)) : 8/4/2009 2:25:27 PM GMT
James: The warnings about jmps are just that - they are not errors and they can be turned off, but this is a common programming error, just in our case this is correct.
As for the files required on the uSD. They have to be contiguous, so reformat the card, then copy the files as you have described above.
DRIVE__A.DSK should be a copy of the DRVCPM_2.DSK. DRIVE__B.DSK to DRIVE__F.DSK should be copies of the blank disk (think I called it something like BLANK32M.DSK). These files were all compressed in the files on Page 4.
Just try the files at the top of page 4 for now. V090 jumped to synchronise with heaters v0.09 ZiCog code. I probably had other fixes in there also, so just ignore v090 for now.
Make sure you read the errata. You will need to follow this for the -OE mod to the sram on Blade #2. It is also on my website www.bluemagic.biz/cluso.htm
I hope to have my TriBlade running tomorrow when I can recompile the latest code and check it all works ok. Then I will post it. So please just hang in there till then.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re "DRIVE__A.DSK should be a copy of the DRVCPM_2.DSK. DRIVE__B.DSK to DRIVE__F.DSK should be copies of the blank disk (think I called it something like BLANK32M.DSK). These files were all compressed in the files on Page 4."
Great news. So, disk A is the disk with CP/M on it? If the others are just blank disks to start then that makes things a lot simpler. Looking forward to getting home and trying this out.
I have just posted updated code to the top of the thread. It consists of all source plus the homespun v024 compiler which·is used to compile the code. "z.bat" is a DOS batch file to compile the code. The code also contains the binary, so there is no requirement to compile.
This code loads into Blade #2 and runs ZiCog v009 (TriBlade v091). It uses the serial pins P30/P31 (via the PropPlug circuit) at 115,200 baud to communicate with the PC running PropTerminal. You CANNOT substitute the Keyboard and TV or VGA objects as these may not be connected to Blade #2. Blade #1 can be used for this and I will post this code later.
I have also posted two files which contain the files required to be on the microSD card to run CPM 2.2 & CPM 3 (Note CPM 3 is not working properly).
Posted here is a "Draft" version of the Assembly Instructions for the TriBladeProp board. Also included is a section to format the microSD card on the PC and files to copy to it.
In the following post is the Errata (modifications/fixes) for the pcb and photos.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The suggested modification for swapping the serial lines over between Blades #1 and #2 should be preferably done by using 150R resistors (to replace the green wires shown). Be careful not to allow the resistors to short.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Many thanks Cluso. Am downloading the disk images now. My sd card access is not so fast - maybe only USB1 as it is taking over an hour to send all the disk images. Anyway, 3/4 of the way there now. I tweaked a few lines of code eg
debug.str(string(13,13)) has been changed to debug.str(string(13,10))
There are a few 13s through the code and the terminal programs I'm using expect 13 (carriage return) and 10 (line feed).
13 by itself only puts the cursor back at the beginning of the line. It is a minor thing though, but is good to test the compile/download cycle. z.bat does the compile. For download, I'm doubleclicking on the .binary and that opens up the propeller IDE and does the download. Is there a quicker way to do the download eg another little batch program?
Propellent can do it but I have never used it - someone else may care to comment. However, once I get onto bst I think this can all be done within the same IDE.
What do you mean the sd card is slow? Are you using a USB to microSD adapter? One of my laptops has an SD slot
As you may have gathered, I have Blade #2 running on the newly built TriBlade, plus the power supply and propplug sections (see photos above). Ross - did you hear that :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Screen dump below. Have changed quite a number of lines. Baudrate in 3 places (text out, text in and the main program) to 38k. Multiple instances of 13 out changed to 13 then 10. And commented out the 10 catch here as I want to send out the 10.'
PRI out_condata
'Handle writes to the console data output port
'data := data & $7F 'Use this for 4KBASIC which spits out Smile
'if io_data <> 10
TV.out(io_data)
A>dir
A: ASM COM : BDOS MAC : BOOT COM : BOOT MAC
A: SYSCPM2 SUB : CBIOSX MAC : CCP MAC : CCPZ MAC
A: CCPZ TXT : CFGCCP LIB : CFGCCPZ LIB : COPY COM
A: CPU COM : CPU MAC : CREF80 COM : DDT COM
A: DDTZ COM : SYSCPM2Z SUB : DO COM : DSKBOOT MAC
A: DUMP COM : ED COM : ELIZA BAS : EX MAC
A: EX SUB : EX8080 COM : EXZ80ALL COM : EXZ80DOC COM
A: FORMAT COM : GO COM : HALT COM : PRELIM MAC
A: HDSKBOOT MAC : L80 COM : LADDER COM : LADDER DAT
A: LIB80 COM : LOAD COM : LS COM : LU COM
A: M80 COM : MBASIC COM : MC SUB : MCC SUB
A: MCCL SUB : MOVER MAC : OTHELLO COM : PIP COM
A: PRELIM COM : EC8080 LIB : RSETSIMH COM : RSETSIMH MAC
A: SID COM : ECZ80ALL LIB : STAT COM : SUBMIT COM
A: SURVEY COM : SURVEY MAC : ECZ80DOC LIB : BOOTGEN COM
A: DIF COM : TIMER COM : TIMER MAC : UNCR COM
A: UNERA COM : UNERA MAC : USQ COM : HDIR COM
A: WM COM : WM HLP : WORM COM : R COM
A: XSUB COM : ZAP COM : ZSID COM : ZTRAN4 COM
A: SHOWSEC COM : SPEED COM : SYSCOPY COM : W COM
A: XFORMAT COM
A>
......................
Some experiments:
Loading mbasic =14 seconds (is that correct)
N8VEM loading mbasic off the ramdisk = 0.5 seconds
mbasic speed test
10 for a=1 to 10000
20 next a
on triblade=14 seconds
on N8VEM running at 3.68Mhz=13 seconds
So it appears to run pretty much the same speed as the (slightly underclocked) N8VEM. Load times are longer though.
Hmm - makes one wonder about a battery backed ramdisk like the N8VEM. Just a DS1210 chip and a 3 V coin cell.
Heater, can we maybe brainstorm how much it would slow down the emulation to latch two address chips and then the data and get it onto one prop. Even if it slowed down by 20% I think that wouldn't matter much.
Also - anyone got xmodem working for file transfers?
Addit: musings re xmodem (unless anyone does have it working). xmodem means you can send a file from any terminal program, or transfer via radio modules etc. There are three simple I/O ports to trap.
MODCTLP:.EQU 06DH ; PUT YOUR MODEM STATUS PORT HERE (returns either 00000000 or 00000001)
MODDATP:.EQU 068H ; YOUR MODEM DATA IN PORT
MODDATO:.EQU 068H ; YOUR MODEM DATA OUT PORT
6DH and 68H happen to be the addresses for the N8VEM, and the input and output ports are the same 68H
For some simple code, could you trap these within the simulation? Testing a byte is ready would check the fullduplexserialplus cog code to see if a byte is available or not. An out to a designated port would send out a byte to TV.out and an input would receive it.
There are also some addresses to OUT to which change the baud rate for a true uart simulation.
Down the track if a few pins could be freed up on the prop, it could have a second port, so one could be serial for the terminal, and a second port is for transfers. Like on a real CP/M computer. This is something I'm pondering re the tradeoff of putting it all on one chip - it runs a bit slower, but if you can free up some pins you could have even 3 serial ports. Then you can run asynchronous serial routing with buffers - something that very few systems can do and which would truly show off the parallel processing power of the propeller.
Post Edited (Dr_Acula (James Moxham)) : 8/5/2009 11:00:44 AM GMT
Congratulations James I see the A> prompt and more.
Timings... Lonesock and Rokiki have a new fast SD access routine which I am yet to try. This should speed things up a lot.
Heater is trapping all IN & OUT instructions so we can do what we like with it. Heater has it running on one prop. It could run on Blade #1 as that has latching for the upper address bits. However, my minimal RamBlade is so simple (no latches and the eeprom/simulator is optional) there seems no reason not to use a second prop for all the I/O. The TwinBlade will do this. For a minimal system though, the RamBlade will be able to run with a keyboard and a monochrome composite TV out - not bad in about 1x1.8" pcb. Ram will only be 256KB if using TV out. Expecting to run at 120MHz overclocking, but will be testing higher.
As for 2 serial ports, RamBlade could do that but RAM would then be 128KB (will require a track cut and wire).
I see you are running v06x. I posted v091 today which incorporates heaters v009 ZiCog.
Have you done a DIR on all drives A..H then a SURVEY ??
Re CR+LF, it would be simpler to modify PC_Text.spin to add 10 after every 13.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
A few things are not quite right. You have some missing chars and/or garbled characters after "Starting Z80 emulation.." and the format of the DIR listing is a mess (missing TABs ?)
I'm amazed that a) the disk load is so slow and b) the emulation is so fast compared to N8VEM !!!
Adding new I/O ports as you describe should be easy. The hardware emulation spin code already traps for console port I/O as you describe , data out, data ready and data in. One only needs to add some extra cases to the code to check for the new port numbers. Have a look at what it does for the console ports.
How about hacking a new xmodem.asm that uses the existing console ports?
Yes we should think about a poor mans single Prop version. I have a stack of old 32K SRAMs waiting for it[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Garbled chars - yes working on that. Seems to be worse on one PC terminal vs another. Something is strangely wrong with my power supply - some data outputs from the board to the PC end up drawing lots of current and collapsing the power supply. Not sure why - there are resistors between that and the max232. Anyway - no matter, I just want to get this working and a 4700uF across the 3V rail is fixing it for the moment.
DIR listing is perfect - the misalignment is just a function of the copy and paste into the forum.
Disk load is very slow. But Cluso says he is going to fix that. Emulation is extraordinarily fast. More than enough for my purposes (and remember, you can't beat Pacman with a fast clock!)
Adding new ports. Help there would be great. I got to here:
A>mbasic
BASIC-80 Rev. 5.21
[noparse][[/noparse]CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
32824 Bytes free
Ok
out 255,1
Write to unimplemented I/O Port $FF,01
Ok
using this code
PRI on_output
...
other:
TV.str(string("Write to unimplemented I/O Port $"))
TV.hex(io_port,2) ' port number
TV.str(string(","))
TV.hex(io_data,2) ' write byte
TV.out(13)
TV.out(10)
So can trap Out and IN should be similar.
PRI on_input
...
other:
'TV.str(string("Read from unimplemented I/O Port $"))
'TV.hex(io_port,2)
'TV.out(13)
'io_data := 0
All I need to get xmodem working is to trap an In to a specific port number, and use that to ask the serialspin object "do you have a byte in your buffer?" Reading data between cogs is something I don't quite understand so help there would be appreciated.
I might even use the N8VEM uart port numbers as then all the code will be the same.
A stack of 32k srams eh? Well funny you should say that coz that is my motivation too!
James: The latest code fixes a conflict problem which required me to restart the cog in the older code for SD access. So please move to v091 code and try that.
You could modify PC_Text to insert 10 after 13 (CR+LF).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
ok, will do. What are the rules about multiple people writing code? Does one modify the code and also add the modification to the top in the comments section? And then where is it sent - is the moderator Heater or Cluso? Can mods be rejected? Is it going to be difficult if I go and add 10 after every 13 for instance?
As you can see, I'm bursting with ideas now. I'd love to get xmodem working. And it would be great to be able to change the baud rate from within CP/M by sending a few specific OUT bytes.
Congrats - you finally got here The CR problem is the one I alluded to earlier. You can actually fix in one place. In Cluso's driver he actually discards the the linefeeds because the PropTerm already inserts them. I think if you look for where he checks for the character 10 and drops it on the floor and comment that it out it will fix the CR/LF problem.
So for your information - I just downloaded the PockeTerm code into blade 1 and made sure the serial in/out were directed to p30/p31 and upped the baud rate to 115K so it corresponded to the Blade 2 setting and you will have your terminal on the TriBlade - no external connection to a PC or terminal - just hook up vga and keyboard to Blade 1.
Just to be clear in the Linefeed problem (10), go to zicog_demo009_rr091 or equiv and find function out_condata. If you look at the end of it, it says if io_data <> 10. Just remove that line and leave the TV.out(io_data) at the nest level of the statement above the if. The if is causing it to throw all the linefeeds (10) on the floor.
Hmm.. Good point about the various versions. So far Cluso and I have been collaborating on a single version that builds for Prop Demo board or TriBlade form a single set of source files. All two of them. Basically I was progressing with the opcode and hardware emulation and Cluso was making changes to get it running on the TriBlade. That has worked out so far mainly because there were only two of us but partly because the end functionality was always the same i.e. The hardware interfaces that the Z80 sees are exactly the same as provided by the SIMH Z80 emulator.
So there was a common target for console ports, disk driver ports, banked RAM ports etc. Also a common aim in CP/M and BIOS verisons to support.
If we get into the world of adding "non standard" or at least different peripheral hardware emulation life will get a lot more complicated. And even more so if custom CP/M code is introduced. In fact it becomes a different project as the requirement spec becomes different.
Still I'd like if all real hardware platforms Demo Board, Triblade, etc could be supported from a single source code base. It will get messy trying to support different emulated peripherals as well though, with a million combinations of #defines to think about. Might get easier if we split up the functionality into different files.
I have to think on this a bit.
In the mean time there is no reason you cant create your own version of the package and post it as long as it carries a different name and its clear what it does and what it runs on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think most of the changes will come in Cluso's code for hardware emulation. Cluso and I have been chatting in the N8VEM forums where I am doing a propeller I/O board for a SBC z80 system. I plan to ifdef into the code the I/O map for the N8VEM so that we can share microSDs between both projects.
I can forsee some forking of the CBIOS code as the disk I/O may be different between the 2. I will have to look at the SIMH disk routines and see if it makes sense to emulated the disk controller there or invent one for the N8VEM. Also the banking of memory may be different.
The N8VEM has a ROM that contains a monitor and CP/M in the ROM. I am going to try to just make the monitor be able to boot CP/M from the boot tracks of the emulated disk on the uSD. If that is successful maybe we can come to a common monitor that will be able to boot different variants of CP/M from one of the disk images on the uSD?
CR+LF probably should be in a #define crlf because this problem will exist in various terminal emulations, so I see this as common ground.
Other modifications, as Heater said, should be clearly identified at the top of·the code and the filename should reflect this, at least for now.
While my RamBlade uses different hardware mapping, this will be taken care of in another driver. This is because ram access is 75%+ faster. Remember, my objective is emulation speed first, simplicity second, then minimal cost, in that order.
FYI the v090 code had #define 8080 set (cannot recall exact name) instead of Z80. "baud" has been defined, but lower code objects also require changing. v090+ has faster SD access on the TriBlade because I had to do a reset/reload of the cog for each SD access to avoid a hardware conflict with the older v021 TriBlade driver. The fix in the sdspi driver to release the SD D0 pin just sends out a lot of clocks which is slow and happens at the end of each read/write of an SD sector. By using the new SD driver by lonesock/rokiki we should get much faster access, although the TriBlade and RamBlade hardware will preclude read ahead and write behind due to bus conflicts - otherwise latching has to be used which imposes r/w penalties with EVERY ram access. Oh for some more prop pins
I did not complicate the v091 release with PropDOS/PropCMD which allows the booting of any prop program. I have had this working. This will be great to also load Ross's Catalina C project and also Heaters' MoCog (Motorola 6809) emulation. It will be nice to load all these from a Prop command prompt.
Now, for the I/O emulation for various hardware. Since heater traps all the In/Out instructions in spin, it may be best if we move this to a ZiCog_IO.spin module (as heater suggested)·so that changes for various emulations can be done here, allowing for various forks to use different modules. Does this sound doable ?? I will be using a seperate prop for the I/O anyway, so the driver I use will be minimal as all the hard work will be done on the "other prop/blade". I will just be passing INs and OUTs to the other prop for interpretation via Ultra High Speed Serial (expect about 8MB/s), although initially 115,200 is fine because I can substitute the pc for this.
James, are you using RS232 for your link to the PC? If you have a USB on the PC, you will happily get 115,200 over 2m. Improves development imensely
Yoda, where are the boot tracks stored on the SD card? Are you meaning within the CPM A disk?? IIRC·I am loading 64KB into ram from a seperate file on the SD (DRIVE_1M.RAM) but in reality it is only·$0000 JMP $FF00 which contains the contents of the file BOOT.COM· I posted the VB6 code (and emailed a copy to James) where I make this and the other CPM files for the SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
More users = more confusion?! I guess if there are lots of options then it makes sense to try to bring it all to single ifdefs at the beginning of the program, so one change will alter many things automatically.
CRLF is more than just commenting out the single out_condata, as there are multiple instances of the debug object as well in the bootup. Thinking about that more, maybe there needs to be some sort of common text output as it starts off using debug., but changes to tv. half way through the bootup.
I've not used propterm, but rather I've been using a range of terminals (hyperterminal, teraterm etc) as these all have xmodem built in. I particularly like teraterm because it boots up the fastest. They all need the 10.
There is another option re settings, and that is to use Vince's solution with the Pocketerm where he has a line at the bottom with the function keys and what they do. Use a function key to set the baud rate for instance. Or to turn linefeed on or off. Settings are stored in the eeprom. It means you can have one set of code that everyone is using, but still customise it for users without having to do a recompile each time.
re the size of disks, I thought I was doing something wrong there as STAT was reporting them as only 1mb. But I was pretty sure the files I downloaded were 32mb each, and figuring 512 to 128byte sectors, that they were 8mb. Are there some blank 8mb 'hard disk' images that work? It would be pretty simple to move files from a 1mb disk image to an 8mb hard drive image using PIP. I have just tested PIP moving files from one drive to another and it works fine. PIP B:*.*=A:*.*
Baud is mentioned in three seperate places. Is it possible to link these so there is just one setting at the beginning?
Faster sd access sounds great. It ought to speed up the bootup as well. How close is that code?
Yes I'm using plain old RS232 for the download. 38k is more than fast enough for programming a propeller. It may be a little slow for xmodem transfers. I might get one of those USB to serial cables...
Changing baud rate from within software might be just me, but sometimes slow baud rates are useful. Radio goes twice as far at 1200 compared to 9600 baud.
More pins? Yes!! More serial ports? Yes please!
One nice thing about the N8VEM is the faster disk access. Bootup is under 1 second and loading programs about 30x faster. Going off on a tangent, if a ram chip were run from 5V instead of 3V and were linked via 1k resistors to the 3V system, then you could add a DS1210 and have a battery backed ram. You could then put in an SD card and move files over to the battery backed ram. If that ram also had a couple of boot tracks it could load CP/M. Then you could remove the sd card. The spincode could check for the sd card, and if not present, try booting from the ram drive instead. That would use less power too as you don't need to power an sd card.
A zicog I/O module? Yes, that could be an option. I was just going to write some PRI's to do things like trap an IO that changes the baud rate, and then change it etc.
I think tonight I might fire up Eagle and try some ideas with getting it onto one propeller. It may or may not work but it would be just cool to get this onto one chip. Even if it is a bit slower than a real CP/M computer. Though with a ramdrive and overclocking counteracting the need for a few more latch addresses, I think it could still come out at about the same as a 4Mhz machine.
Cluso: Yes I wanted to use the reserved sectors on the DISKA for the CP/M code and boot loader. That way you could use the standard CP/M tools like sysgen, etc to develop your CP/M code. So are you talking basically moving the I/O parts of your driver into a different object? That is OK with me. I think the ifdefs for N8VEM are going to be minimal to the current drivers. It is really just the address you trap for console and disk controller. I can probably make the disk controller look like the the SIMH one on the propIO board but the addresses are probably not going to be the same.
James: I would prefer to use the extra RAM with CP/M 3 to get psuedo caching of files - instead of battery backup. Having track buffers to the uSD I think is the way to go, kind of get the best of both worlds. On the CRLF - I thought you were only concerned about the ones in CP/M. The debug stuff is off the screen quickly and should be ifdef'd if not in the code so you would probably never see them.
Yes, thinking of the N8VEM and I/O, I think there might only be 3 or 4 ports. (I used the 8255 for keyboard etc, but the prop does this anyway). So ignore the 8255, the disk I/O already works fine, so the only ports needed are the ones to talk to the uart. Which are - send a byte, get a byte, check for a byte, change the baud rate. So that is pretty simple and maybe only a few lines of spin. It can sit there dormant for people not emulating the N8VEM as there are plenty of other free I/O ports.
Re the debug stuff on bootup, Yoda says this is off the screen quickly. How quickly, as my card takes about 15 secs to boot up. I'm wondering if my card is a bit slow??
I've just ordered two USB to serial devices - total cost for the two including shipping was only $7.50. I'd love to get xmodem working at 115k.
CP/M 3? Well that would be an amazing thing to see. I see there is a disk image around with CP/M3 in the name - is this working yet?
Post Edited (Dr_Acula (James Moxham)) : 8/6/2009 1:42:18 AM GMT
James: The changes from debug to TV were done for a reason but cannot remember why. I think the TV was changing intercepting characters and I was downloading code. I will have a new look at this later. It was a quick fix at the time.
I am using PropTerminal because I can switch between the IDE and it easily. As soon as I switch to bst I think I can move to this completely as there is a terminal window in the bst IDE as well. CRLF will require more thought to simplify and standardise it.
We could do a baud #define I suppose. Once again, more thought needed. I was not aware that the prop could be loaded at other than 115,200 even though it is quite tolerant (it is using internal clocking). Anyway, I don't expect to be reprogramming the eeprom. Perhaps baud could therefore be defined here and CRLF as well.
We will need some form of Terminal program for Blade #1 such as PockeTerm - not sure of Vince's license - but there are objects around for this.
Disks: The 32MB files are just copies of the 1MB disks into the first 8MB·with the remainder of the space unused. This is so the files can remain contiguous. Heater does not have the 2 x 8 MB hard disks working yet (??). However, it may be better to just jump in and change the floppy driver in CPM to use 8MB floppies and forget the hard disks altogether. Heater - any ideas/suggestions?? I have done a format of one of the disks a while ago and then used PIP to copy files. Drive G is a copy of Drive A, so if A gets modified too much, it can be fully restored.
SD speed: Have you tried v091 yet. The initialisation is much faster but I am not sure about CPM boot time and access. Perhaps you can time this for·me. Not sure when I will get time to use the new SD driver.
Ram Disk: I started out with a 960KB disk image plus 64KB of Z80 Ram before I got the SD working. As for 5V SRAM, I think the resistors could impact ram access times. After Windows, the load time is not a problem for me, but I like the idea of being able to run a ram disk. However, RamBlade will only have 512KB and may even be restricted to 128KB or 256KB if it is a single prop solution. Don't forget, we want 256KB for CPM3 bank switching.
Yoda: Yes sounds good to me
CPM3: Yes it runs but there is an I/O problem in that each character you enter requires it to be hit twice on the keyboard. Otherwise I did a dir. Just change the #define and recompile.
SPEED: Overclocking should give us a 6MHz equivalent Z80 · And we can probably still optimise ZiCog and the spin code. BTW Some of the spin code should be PASM = more speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
As you may have gathered, I have Blade #2 running on the newly built TriBlade, plus the power supply and propplug sections (see photos above).
Ross - did you hear that
Good news - I hope to soon have a TriBladeProp of my very own.
But really I should have two - after all, the REAL Catalina has two tribladeprops
Ross.
P.S. If you need your loaner board back for any reason, just let me know. I don't really need it for the stuff I'm working on at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Comments
Edit: some more testing and looking still hasn't turned up the culprit. I tried passing 6A through the 5V input header near the RCA jack, but it didn't show up any shorts.
Post Edited (SRLM) : 6/4/2009 10:23:12 PM GMT
All pcbs were supposed to be electrically tested and I believe this to be the case as there were a number of reject pcbs.
If the short is between 5v and 3.3V then the 5V track is fairly short so it should be fairly easy to find.
I have included the copper sections attached. The red is the top, blue the bottom.·This is the strip you should be looking at for a short between the solder pads and the surrounding copper.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontrolled.
The easiest way may be to expand my picture (the red one) and follow the 5V copper and look for this short. Start at the 5V pad in the centre of the picture near the words "M"ouse. While the black outline is not al that clear I hope it will give you a clue to where the short is.
I would start at C1, C2, C3 and J3. Then check the mouse and VGA pins.
BTW Tantalums were recommended for C2 & C3. While it will probably be ok, I cannot guarantee this. Do not overclock the props unless you fit a tantalum under each prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The TriBlade is basically 5 seperate (self-contained) sections...
Now for the interconnection and programmability...
So, to answer your question, the props on the TriBlade are seperate AND able to interact, AND yes one prop can instruct/command/program the others (via #2).
You may also like to·see the RamBlade and TwinBlade threads, although progress has been slow due to other constraints.
Shameless plug: There are still a few pcbs available.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 6/21/2009 3:03:53 AM GMT
The best place to start is download the code and SD card files from the post at the top of Page 4 of this thread. There is a good explanation of the files. Near the bottom of·that page is a binary file which can be programmed into the eeprom to boot PropCmd and a binary file to place on the SD card to boot ZiCog.
Page 4 also contains a lot of information about the TriBlade and ZiCog and I suggest you read this.
As soon as I can get a new TriBlade built I will publish the latest code.
TriBlade "ZiCog_demoXXX_rrXXX.spin" code is for Blade #2 ONLY:
PC_Keyboard.spin and PC_Text.spin use the serial (program pins) to connect via a propplug (or equivalent) to the PC and the PC runs PropTerminal to emulate the Keyboard and Display. DO NOT substitute these with "Keyboard.spin, VGA.spin or TV_text". The TriBlade #2 does not support the keyboard or display (tv or vga) on this prop. It can communicate via the serial lines to another prop (Blade #1 or #3) which can act as a terminal, depending on the options wired.
1. Get ZiCog running on Blade #2 to the PC
2. Make sure you can do a SURVEY and run MSBasic
3. Now get Blade #1 running a Terminal Program (and the PC via propplug)
4. Now you can modify Blades #1 & #2 to talk to each other, replacing the PC.
I will post more details for this when I get my next TriBlade working.
Hope this helps for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
It is all very close now. On the link at the top of page 4 of this thread is a link to a zip file called TriBladeProp_Zicog_rr068.zip Unzip this as a package and it contains a file z.bat. This contains a line
homespun024 zicog_demo006_rr069 -b -d -i3 -w
a minor bug in that the file demo006_rr069 does not exist in the zip. It is actually rr068 so I changed it to 68
(I seem to have a file rr090 so this appears to be a fairly old version)
However, the zip package does compile as a unit which is great news! A few warning messages:
C:\Propeller\zicog68>homespun024 zicog_demo006_rr068 -b -d -i3 -w
Homespun Spin Compiler 0.24
parsing zicog_demo006_rr068.spin
parsing zicog005_rr021.spin
Warning: zicog005_rr021.spin (191, 33): JMP with non-immediate operand
vect_1 jmp vector 'Jump to the instruct
ion handler
^
Warning: zicog005_rr021.spin (195, 33): JMP with non-immediate operand
jmp vector
^
Warning: zicog005_rr021.spin (369, 33): JMP with non-immediate operand
if_nz jmp jump_rel_unconditional 'Jump if not zero
^
Warning: zicog005_rr021.spin (1446, 33): JMP with non-immediate operand
jmp OVERLAY_LOAD_RET 'return (indirect) to
calling routine
^
parsing PC_Keyboard.spin
parsing PC_Text.spin
parsing TriBladeProp_Blade2_201.spin
parsing FullDuplexSerialPlus.spin
parsing fsrwFemto.spin
parsing sdspiFemto.spin
compiling zicog_demo006_rr068.spin
compiling zicog005_rr021.spin
compiling PC_Keyboard.spin
compiling PC_Text.spin
compiling TriBladeProp_Blade2_201.spin
compiling FullDuplexSerialPlus.spin
compiling fsrwFemto.spin
compiling sdspiFemto.spin
writing zicog_demo006_rr068.binary
Writing listing to zicog_demo006_rr068.lst
Then had to drop the baud rate back to 38400 (that is just me and my 2 metre serial cable) and I've got it to the point of printing:
TriBladeProp: Load SRAM from microSD (Y/N)?
Ok, on to getting some files on the sd card...
Addit:
Getting an error saying the code is halting when reading the sd card.
I see this code:
FindDriveBase(0, string("DRIVE__A.DSK")) 'set the SD card drive base(s)
FindDriveBase(1, string("DRIVE__B.DSK")) 'set the SD card drive base(s)
FindDriveBase(2, string("DRIVE__C.DSK")) 'set the SD card drive base(s)
FindDriveBase(3, string("DRIVE__D.DSK")) 'set the SD card drive base(s)
FindDriveBase(4, string("DRIVE__E.DSK")) 'set the SD card drive base(s)
FindDriveBase(5, string("DRIVE__F.DSK")) 'set the SD card drive base(s)
FindDriveBase(6, string("DRVCPM_2.DSK")) 'set the SD card drive base(s)
FindDriveBase(7, string("DRVCPM_3.DSK")) 'set the SD card drive base(s)
r := sd.stopSDCard 'stop SD card, but do not stop cog
check_error(r)
But the package at the top of page 4 only contains 3 files. Could the missing files be the reason it is halting?
Post Edited (Dr_Acula (James Moxham)) : 8/4/2009 2:25:27 PM GMT
As for the files required on the uSD. They have to be contiguous, so reformat the card, then copy the files as you have described above.
DRIVE__A.DSK should be a copy of the DRVCPM_2.DSK. DRIVE__B.DSK to DRIVE__F.DSK should be copies of the blank disk (think I called it something like BLANK32M.DSK). These files were all compressed in the files on Page 4.
Just try the files at the top of page 4 for now. V090 jumped to synchronise with heaters v0.09 ZiCog code. I probably had other fixes in there also, so just ignore v090 for now.
Make sure you read the errata. You will need to follow this for the -OE mod to the sram on Blade #2. It is also on my website www.bluemagic.biz/cluso.htm
I hope to have my TriBlade running tomorrow when I can recompile the latest code and check it all works ok. Then I will post it. So please just hang in there till then.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Great news. So, disk A is the disk with CP/M on it? If the others are just blank disks to start then that makes things a lot simpler. Looking forward to getting home and trying this out.
This code loads into Blade #2 and runs ZiCog v009 (TriBlade v091). It uses the serial pins P30/P31 (via the PropPlug circuit) at 115,200 baud to communicate with the PC running PropTerminal. You CANNOT substitute the Keyboard and TV or VGA objects as these may not be connected to Blade #2. Blade #1 can be used for this and I will post this code later.
I have also posted two files which contain the files required to be on the microSD card to run CPM 2.2 & CPM 3 (Note CPM 3 is not working properly).
Posted here is a "Draft" version of the Assembly Instructions for the TriBladeProp board. Also included is a section to format the microSD card on the PC and files to copy to it.
In the following post is the Errata (modifications/fixes) for the pcb and photos.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 8/5/2009 9:18:00 AM GMT
The suggested modification for swapping the serial lines over between Blades #1 and #2 should be preferably done by using 150R resistors (to replace the green wires shown). Be careful not to allow the resistors to short.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 8/5/2009 8:55:20 AM GMT
debug.str(string(13,13)) has been changed to debug.str(string(13,10))
There are a few 13s through the code and the terminal programs I'm using expect 13 (carriage return) and 10 (line feed).
13 by itself only puts the cursor back at the beginning of the line. It is a minor thing though, but is good to test the compile/download cycle. z.bat does the compile. For download, I'm doubleclicking on the .binary and that opens up the propeller IDE and does the download. Is there a quicker way to do the download eg another little batch program?
What do you mean the sd card is slow? Are you using a USB to microSD adapter? One of my laptops has an SD slot
As you may have gathered, I have Blade #2 running on the newly built TriBlade, plus the power supply and propplug sections (see photos above). Ross - did you hear that :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
PRI out_condata
'Handle writes to the console data output port
'data := data & $7F 'Use this for 4KBASIC which spits out Smile
'if io_data <> 10
TV.out(io_data)
Screen dump. It works!!
Triblade Prop
Starting disks...
A:B:C[noparse]:D[/noparse]:E:F:G:H:Loading SRAM...
0.1.2.3.4.5.6.7.................................................................
........................................................ Loaded
ZiCog v0.006 on the TriBladeProp v0.06x
Starting Z80 emulation...ver ... Passed
Passed
64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.25, 2 HD, 15-Jan-07)
A>dir
A: ASM COM : BDOS MAC : BOOT COM : BOOT MAC
A: SYSCPM2 SUB : CBIOSX MAC : CCP MAC : CCPZ MAC
A: CCPZ TXT : CFGCCP LIB : CFGCCPZ LIB : COPY COM
A: CPU COM : CPU MAC : CREF80 COM : DDT COM
A: DDTZ COM : SYSCPM2Z SUB : DO COM : DSKBOOT MAC
A: DUMP COM : ED COM : ELIZA BAS : EX MAC
A: EX SUB : EX8080 COM : EXZ80ALL COM : EXZ80DOC COM
A: FORMAT COM : GO COM : HALT COM : PRELIM MAC
A: HDSKBOOT MAC : L80 COM : LADDER COM : LADDER DAT
A: LIB80 COM : LOAD COM : LS COM : LU COM
A: M80 COM : MBASIC COM : MC SUB : MCC SUB
A: MCCL SUB : MOVER MAC : OTHELLO COM : PIP COM
A: PRELIM COM : EC8080 LIB : RSETSIMH COM : RSETSIMH MAC
A: SID COM : ECZ80ALL LIB : STAT COM : SUBMIT COM
A: SURVEY COM : SURVEY MAC : ECZ80DOC LIB : BOOTGEN COM
A: DIF COM : TIMER COM : TIMER MAC : UNCR COM
A: UNERA COM : UNERA MAC : USQ COM : HDIR COM
A: WM COM : WM HLP : WORM COM : R COM
A: XSUB COM : ZAP COM : ZSID COM : ZTRAN4 COM
A: SHOWSEC COM : SPEED COM : SYSCOPY COM : W COM
A: XFORMAT COM
A>
......................
Some experiments:
Loading mbasic =14 seconds (is that correct)
N8VEM loading mbasic off the ramdisk = 0.5 seconds
mbasic speed test
10 for a=1 to 10000
20 next a
on triblade=14 seconds
on N8VEM running at 3.68Mhz=13 seconds
So it appears to run pretty much the same speed as the (slightly underclocked) N8VEM. Load times are longer though.
Hmm - makes one wonder about a battery backed ramdisk like the N8VEM. Just a DS1210 chip and a 3 V coin cell.
Heater, can we maybe brainstorm how much it would slow down the emulation to latch two address chips and then the data and get it onto one prop. Even if it slowed down by 20% I think that wouldn't matter much.
Also - anyone got xmodem working for file transfers?
Addit: musings re xmodem (unless anyone does have it working). xmodem means you can send a file from any terminal program, or transfer via radio modules etc. There are three simple I/O ports to trap.
MODCTLP:.EQU 06DH ; PUT YOUR MODEM STATUS PORT HERE (returns either 00000000 or 00000001)
MODDATP:.EQU 068H ; YOUR MODEM DATA IN PORT
MODDATO:.EQU 068H ; YOUR MODEM DATA OUT PORT
6DH and 68H happen to be the addresses for the N8VEM, and the input and output ports are the same 68H
For some simple code, could you trap these within the simulation? Testing a byte is ready would check the fullduplexserialplus cog code to see if a byte is available or not. An out to a designated port would send out a byte to TV.out and an input would receive it.
There are also some addresses to OUT to which change the baud rate for a true uart simulation.
Down the track if a few pins could be freed up on the prop, it could have a second port, so one could be serial for the terminal, and a second port is for transfers. Like on a real CP/M computer. This is something I'm pondering re the tradeoff of putting it all on one chip - it runs a bit slower, but if you can free up some pins you could have even 3 serial ports. Then you can run asynchronous serial routing with buffers - something that very few systems can do and which would truly show off the parallel processing power of the propeller.
Post Edited (Dr_Acula (James Moxham)) : 8/5/2009 11:00:44 AM GMT
Timings... Lonesock and Rokiki have a new fast SD access routine which I am yet to try. This should speed things up a lot.
Heater is trapping all IN & OUT instructions so we can do what we like with it. Heater has it running on one prop. It could run on Blade #1 as that has latching for the upper address bits. However, my minimal RamBlade is so simple (no latches and the eeprom/simulator is optional) there seems no reason not to use a second prop for all the I/O. The TwinBlade will do this. For a minimal system though, the RamBlade will be able to run with a keyboard and a monochrome composite TV out - not bad in about 1x1.8" pcb. Ram will only be 256KB if using TV out. Expecting to run at 120MHz overclocking, but will be testing higher.
As for 2 serial ports, RamBlade could do that but RAM would then be 128KB (will require a track cut and wire).
I see you are running v06x. I posted v091 today which incorporates heaters v009 ZiCog.
Have you done a DIR on all drives A..H then a SURVEY ??
Re CR+LF, it would be simpler to modify PC_Text.spin to add 10 after every 13.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 8/5/2009 11:34:12 AM GMT
Sorry I don't have time to play along.
A few things are not quite right. You have some missing chars and/or garbled characters after "Starting Z80 emulation.." and the format of the DIR listing is a mess (missing TABs ?)
I'm amazed that a) the disk load is so slow and b) the emulation is so fast compared to N8VEM !!!
Adding new I/O ports as you describe should be easy. The hardware emulation spin code already traps for console port I/O as you describe , data out, data ready and data in. One only needs to add some extra cases to the code to check for the new port numbers. Have a look at what it does for the console ports.
How about hacking a new xmodem.asm that uses the existing console ports?
Yes we should think about a poor mans single Prop version. I have a stack of old 32K SRAMs waiting for it[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
DIR listing is perfect - the misalignment is just a function of the copy and paste into the forum.
Disk load is very slow. But Cluso says he is going to fix that. Emulation is extraordinarily fast. More than enough for my purposes (and remember, you can't beat Pacman with a fast clock!)
Adding new ports. Help there would be great. I got to here:
A>mbasic
BASIC-80 Rev. 5.21
[noparse][[/noparse]CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
32824 Bytes free
Ok
out 255,1
Write to unimplemented I/O Port $FF,01
Ok
using this code
PRI on_output
...
other:
TV.str(string("Write to unimplemented I/O Port $"))
TV.hex(io_port,2) ' port number
TV.str(string(","))
TV.hex(io_data,2) ' write byte
TV.out(13)
TV.out(10)
So can trap Out and IN should be similar.
PRI on_input
...
other:
'TV.str(string("Read from unimplemented I/O Port $"))
'TV.hex(io_port,2)
'TV.out(13)
'io_data := 0
All I need to get xmodem working is to trap an In to a specific port number, and use that to ask the serialspin object "do you have a byte in your buffer?" Reading data between cogs is something I don't quite understand so help there would be appreciated.
I might even use the N8VEM uart port numbers as then all the code will be the same.
A stack of 32k srams eh? Well funny you should say that coz that is my motivation too!
You could modify PC_Text to insert 10 after 13 (CR+LF).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
As you can see, I'm bursting with ideas now. I'd love to get xmodem working. And it would be great to be able to change the baud rate from within CP/M by sending a few specific OUT bytes.
Congrats - you finally got here
So for your information - I just downloaded the PockeTerm code into blade 1 and made sure the serial in/out were directed to p30/p31 and upped the baud rate to 115K so it corresponded to the Blade 2 setting and you will have your terminal on the TriBlade - no external connection to a PC or terminal - just hook up vga and keyboard to Blade 1.
Dave
Just to be clear in the Linefeed problem (10), go to zicog_demo009_rr091 or equiv and find function out_condata. If you look at the end of it, it says if io_data <> 10. Just remove that line and leave the TV.out(io_data) at the nest level of the statement above the if. The if is causing it to throw all the linefeeds (10) on the floor.
Dave
So there was a common target for console ports, disk driver ports, banked RAM ports etc. Also a common aim in CP/M and BIOS verisons to support.
If we get into the world of adding "non standard" or at least different peripheral hardware emulation life will get a lot more complicated. And even more so if custom CP/M code is introduced. In fact it becomes a different project as the requirement spec becomes different.
Still I'd like if all real hardware platforms Demo Board, Triblade, etc could be supported from a single source code base. It will get messy trying to support different emulated peripherals as well though, with a million combinations of #defines to think about. Might get easier if we split up the functionality into different files.
I have to think on this a bit.
In the mean time there is no reason you cant create your own version of the package and post it as long as it carries a different name and its clear what it does and what it runs on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think most of the changes will come in Cluso's code for hardware emulation. Cluso and I have been chatting in the N8VEM forums where I am doing a propeller I/O board for a SBC z80 system. I plan to ifdef into the code the I/O map for the N8VEM so that we can share microSDs between both projects.
I can forsee some forking of the CBIOS code as the disk I/O may be different between the 2. I will have to look at the SIMH disk routines and see if it makes sense to emulated the disk controller there or invent one for the N8VEM. Also the banking of memory may be different.
The N8VEM has a ROM that contains a monitor and CP/M in the ROM. I am going to try to just make the monitor be able to boot CP/M from the boot tracks of the emulated disk on the uSD. If that is successful maybe we can come to a common monitor that will be able to boot different variants of CP/M from one of the disk images on the uSD?
Dave
CR+LF probably should be in a #define crlf because this problem will exist in various terminal emulations, so I see this as common ground.
Other modifications, as Heater said, should be clearly identified at the top of·the code and the filename should reflect this, at least for now.
While my RamBlade uses different hardware mapping, this will be taken care of in another driver. This is because ram access is 75%+ faster. Remember, my objective is emulation speed first, simplicity second, then minimal cost, in that order.
FYI the v090 code had #define 8080 set (cannot recall exact name) instead of Z80. "baud" has been defined, but lower code objects also require changing. v090+ has faster SD access on the TriBlade because I had to do a reset/reload of the cog for each SD access to avoid a hardware conflict with the older v021 TriBlade driver. The fix in the sdspi driver to release the SD D0 pin just sends out a lot of clocks which is slow and happens at the end of each read/write of an SD sector. By using the new SD driver by lonesock/rokiki we should get much faster access, although the TriBlade and RamBlade hardware will preclude read ahead and write behind due to bus conflicts - otherwise latching has to be used which imposes r/w penalties with EVERY ram access. Oh for some more prop pins
I did not complicate the v091 release with PropDOS/PropCMD which allows the booting of any prop program. I have had this working. This will be great to also load Ross's Catalina C project and also Heaters' MoCog (Motorola 6809) emulation. It will be nice to load all these from a Prop command prompt.
Now, for the I/O emulation for various hardware. Since heater traps all the In/Out instructions in spin, it may be best if we move this to a ZiCog_IO.spin module (as heater suggested)·so that changes for various emulations can be done here, allowing for various forks to use different modules. Does this sound doable ?? I will be using a seperate prop for the I/O anyway, so the driver I use will be minimal as all the hard work will be done on the "other prop/blade". I will just be passing INs and OUTs to the other prop for interpretation via Ultra High Speed Serial (expect about 8MB/s), although initially 115,200 is fine because I can substitute the pc for this.
James, are you using RS232 for your link to the PC? If you have a USB on the PC, you will happily get 115,200 over 2m. Improves development imensely
Yoda, where are the boot tracks stored on the SD card? Are you meaning within the CPM A disk?? IIRC·I am loading 64KB into ram from a seperate file on the SD (DRIVE_1M.RAM) but in reality it is only·$0000 JMP $FF00 which contains the contents of the file BOOT.COM· I posted the VB6 code (and emailed a copy to James) where I make this and the other CPM files for the SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
CRLF is more than just commenting out the single out_condata, as there are multiple instances of the debug object as well in the bootup. Thinking about that more, maybe there needs to be some sort of common text output as it starts off using debug., but changes to tv. half way through the bootup.
I've not used propterm, but rather I've been using a range of terminals (hyperterminal, teraterm etc) as these all have xmodem built in. I particularly like teraterm because it boots up the fastest. They all need the 10.
There is another option re settings, and that is to use Vince's solution with the Pocketerm where he has a line at the bottom with the function keys and what they do. Use a function key to set the baud rate for instance. Or to turn linefeed on or off. Settings are stored in the eeprom. It means you can have one set of code that everyone is using, but still customise it for users without having to do a recompile each time.
re the size of disks, I thought I was doing something wrong there as STAT was reporting them as only 1mb. But I was pretty sure the files I downloaded were 32mb each, and figuring 512 to 128byte sectors, that they were 8mb. Are there some blank 8mb 'hard disk' images that work? It would be pretty simple to move files from a 1mb disk image to an 8mb hard drive image using PIP. I have just tested PIP moving files from one drive to another and it works fine. PIP B:*.*=A:*.*
Baud is mentioned in three seperate places. Is it possible to link these so there is just one setting at the beginning?
Faster sd access sounds great. It ought to speed up the bootup as well. How close is that code?
Yes I'm using plain old RS232 for the download. 38k is more than fast enough for programming a propeller. It may be a little slow for xmodem transfers. I might get one of those USB to serial cables...
Changing baud rate from within software might be just me, but sometimes slow baud rates are useful. Radio goes twice as far at 1200 compared to 9600 baud.
More pins? Yes!! More serial ports? Yes please!
One nice thing about the N8VEM is the faster disk access. Bootup is under 1 second and loading programs about 30x faster. Going off on a tangent, if a ram chip were run from 5V instead of 3V and were linked via 1k resistors to the 3V system, then you could add a DS1210 and have a battery backed ram. You could then put in an SD card and move files over to the battery backed ram. If that ram also had a couple of boot tracks it could load CP/M. Then you could remove the sd card. The spincode could check for the sd card, and if not present, try booting from the ram drive instead. That would use less power too as you don't need to power an sd card.
A zicog I/O module? Yes, that could be an option. I was just going to write some PRI's to do things like trap an IO that changes the baud rate, and then change it etc.
I think tonight I might fire up Eagle and try some ideas with getting it onto one propeller. It may or may not work but it would be just cool to get this onto one chip. Even if it is a bit slower than a real CP/M computer. Though with a ramdrive and overclocking counteracting the need for a few more latch addresses, I think it could still come out at about the same as a 4Mhz machine.
James: I would prefer to use the extra RAM with CP/M 3 to get psuedo caching of files - instead of battery backup. Having track buffers to the uSD I think is the way to go, kind of get the best of both worlds. On the CRLF - I thought you were only concerned about the ones in CP/M. The debug stuff is off the screen quickly and should be ifdef'd if not in the code so you would probably never see them.
Dave
Re the debug stuff on bootup, Yoda says this is off the screen quickly. How quickly, as my card takes about 15 secs to boot up. I'm wondering if my card is a bit slow??
I've just ordered two USB to serial devices - total cost for the two including shipping was only $7.50. I'd love to get xmodem working at 115k.
CP/M 3? Well that would be an amazing thing to see. I see there is a disk image around with CP/M3 in the name - is this working yet?
Post Edited (Dr_Acula (James Moxham)) : 8/6/2009 1:42:18 AM GMT
I am using PropTerminal because I can switch between the IDE and it easily. As soon as I switch to bst I think I can move to this completely as there is a terminal window in the bst IDE as well. CRLF will require more thought to simplify and standardise it.
We could do a baud #define I suppose. Once again, more thought needed. I was not aware that the prop could be loaded at other than 115,200 even though it is quite tolerant (it is using internal clocking). Anyway, I don't expect to be reprogramming the eeprom. Perhaps baud could therefore be defined here and CRLF as well.
We will need some form of Terminal program for Blade #1 such as PockeTerm - not sure of Vince's license - but there are objects around for this.
Disks: The 32MB files are just copies of the 1MB disks into the first 8MB·with the remainder of the space unused. This is so the files can remain contiguous. Heater does not have the 2 x 8 MB hard disks working yet (??). However, it may be better to just jump in and change the floppy driver in CPM to use 8MB floppies and forget the hard disks altogether. Heater - any ideas/suggestions?? I have done a format of one of the disks a while ago and then used PIP to copy files. Drive G is a copy of Drive A, so if A gets modified too much, it can be fully restored.
SD speed: Have you tried v091 yet. The initialisation is much faster but I am not sure about CPM boot time and access. Perhaps you can time this for·me. Not sure when I will get time to use the new SD driver.
Ram Disk: I started out with a 960KB disk image plus 64KB of Z80 Ram before I got the SD working. As for 5V SRAM, I think the resistors could impact ram access times. After Windows, the load time is not a problem for me, but I like the idea of being able to run a ram disk. However, RamBlade will only have 512KB and may even be restricted to 128KB or 256KB if it is a single prop solution. Don't forget, we want 256KB for CPM3 bank switching.
Yoda: Yes sounds good to me
CPM3: Yes it runs but there is an I/O problem in that each character you enter requires it to be hit twice on the keyboard. Otherwise I did a dir. Just change the #define and recompile.
SPEED: Overclocking should give us a 6MHz equivalent Z80
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 8/6/2009 2:42:43 AM GMT
Good news - I hope to soon have a TriBladeProp of my very own.
But really I should have two - after all, the REAL Catalina has two tribladeprops
Ross.
P.S. If you need your loaner board back for any reason, just let me know. I don't really need it for the stuff I'm working on at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 8/6/2009 5:46:26 AM GMT