Add an entry to the configuration file "diskdefs" to specify zicog HD image layout;
diskdef zicog
seclen 128
tracks 2048
sectrk 32
blocksize 4096
maxdir 1024
skew 0
boottrk 6
os 2.2
end
Then you can play with files inside a ZiCog HD image like so:
List the contents
cpmls -l -f zicog ../altairz80/zipm2.dsk
0:
-rwxrwxrwx 8192 Jan 01 1970 asm.com
-rw-rw-rw- 128 Jan 01 1970 autoexec.sub
-rwxrwxrwx 3584 Jan 01 1970 bdos.com
-rw-rw-rw- 67584 Jan 01 1970 bdos.mac
-rw-rw-rw- 172032 Jan 01 1970 bdos.prn
-rwxrwxrwx 128 Jan 01 1970 boot.com
-rw-rw-rw- 128 Jan 01 1970 boot.mac
.
.
.
Copy file out of image:
cpmcp -f zicog zipm2.dsk 0:ZIBOOT.COM .
Copy file into disk image:
cpmcp -f zicog zipm2.dsk data.txt 0:
Remove a file:
cpmrm -f zicog zipm2.dsk 0:data.txt
Format a disk:
mkfs.cpm -f zicog new.img
Not sure how to set zicog as the default format yet.
Yoda: We have been using packed sectors for many months now[noparse]:)[/noparse]
It's a useful speed up what with caching four CP/M sectors in our SD buffer space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This will be *very* useful. Now we have another way of moving files in and out of disk images. And I don't need to worry about coding anything!
@Yoda, the hard drive images ended up so much more convenient than the floppy ones that we have abandoned the floppy ones. The hard drive images are directly compatible with the SIMH. I've got a little batch file for the simh that has Drives A-H as floppy images and drives I, J as hard images. If I want (say) the drive with the C compiler, I grab it from the simh site, copy my BLANK.DSK to I.DSK, fire up my simh, do a PIP *.* to drive I, then put that drive I on the SD card (renamed as - say - C.DSK) and it is good to go.
It would be really handy to be able to transfer these hard drive images to and from the N8VEM. I see that Andrew Lynch is starting on a board for the N8VEM using the prop. It ought to be possible for the N8VEM to get access to these 8mb drive images via the SD card.
I am planning on using the same format on the propIO so that there is interchangeability. Also within reason I am trying to make them compatible at the CBIOS level as well so that they will be bootable on either platform in the future.
Sounds good Yoda. I see you have a post on the N8VEM forum looking for an Eagle or Kicad part for the uSD socket. I never managed to find this. Maybe Cluso can help there, or anyone else?
I suspect many of us are guilty of the "announcing my new xyz board, it was really easy" which really means "here is my new board and best not mention the pile of broken boards and chips sitting in the dustbin!"
I'm very impressed with how small you have made this. And I do like the philosophy of treating this board like a fine red wine or a tasty cheese - let it mature for a while before testing!
I have responded to an email from Andrew (sorry missed the post). The microSD socket is Digikey WM17115-ND CONN MINI-USB-B RECEPTACLE 5POS RT ANG (it is posted in the TriBlade BOM). It is easy to solder as the pins are open and at the card end.
Toby, that is a great photo of a small module. I have not been following closely - what is the hardware???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
It's a even more cut back Drac_Blade. It only has two latches for 64K mem, but there are spare pins that Dr_A uses for his second '232 so the 64K could be 256 paged ( but withiout the common area).
I thought CP/M stood for Cigarette Packet / Micro, doesn't it ??
I'll be back on Weds, so perhaps then, another YIPPEE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Thanks Sam. I've been a bit quiet as I'm busy writing the code to build a wireless communications protocol for these boards. It isn't as simple as it sounds but I'm ending up with a system that takes data packets and wraps them up with headers and footers to say where they came from and where they are meant to go. Spin code sitting underneath CP/M is perfect for this. I'm heading towards using some of the 4dSystems video to RS232 devices to capture pictures and chop them up into pieces and send them wirelessly via a very simplified bittorrent type of protocol. The ultimate application is for multiple robots etc sharing pictures of their local environment.
Plus there might be some non Z80, non CP/M applications on the way...
And it's another YIPPEEEE. First time, which shows that the design is near to bomb proof. This is a second time I chose to lop lumps off it and it still lives !!
Thanks guys
Now Clusso has started a size war, I'll cling to the notion that MY attempt has connectors ! Two pics- one in it's spead eagle mode and a boot screen.
PS I don't know if this is Cigarette packet sized or not. I do not know one person that smokes. Whwn I asked, at the local shop, if I could just jet the dimensions of one they looked at me as if I were the most blatent shoplifter they had in this week ( beleive me, I,m no runner)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
So the theory of letting a board "mature" works?!!
Good to see homebrew versions working. Which bits are you lopping off - can you post a schematic?
Cluso has won the size war comprehensively, so I'm also going to go with the "my board includes plugs" argument. Mind you, Cluso will probably put the thing in a plug next...
Note to self - I must get motivated to do the 'hard' problem of getting the Z80 opcoces working. I keep putting it off, partly because it is quite hard to actually isolate the instructions as the EX program has them in groups and just tells you the group failed.
Hey guys in anticipation of getting my Dr_Acula board I went kind of crazy and bought some lots of Sram on Ebay here is what I have,, 40Pin MK380IN-6 I think they might be Z80 chips I also have PMC Flash PM29Foo2T-12PC 32 pin 1Meg Sram I believe.
MCM60256AP10 256K Sram, the old style 27256 Eprom and the giant 27C010A-10 32 Pin Eprom I bought 100 of each and will be happy to share if we can use them I just ask that you guys would share any code with me.. I have this awesome programmer this thing will burn any Eprom, Ram, Pic, Arm, Atmel, EEprom you name it it will burn it it also tests the chips it will do over 10K devices I even got all the adapters for it, I tested the parts and it identified them so I know they are good I can even stick code on them if you guys want to pre-program them
Let me know if we can use them
Mike.Div
Oh and happy holidays to everyone,, one more thing I drew up a board design well the schematic in Eagle Pro it was a real Bich for me can anyone help me figure out how I can get my boards made now I do not know how to do anything but draw the schematic is that good enough for having boards made?? thanks
mikediv, two boards are on their way so surely one will be able to slip through customs and border security and any postal strikes and soon a board will lob in your letterbox.
Meanwhile, what are you doing buying all those bits?! Actually, if you want, they could come in handy for a N8VEM board if you wanted to build a real Z80 board. Certainly it has been very handy for a few of us when debugging to have a real board as well for comparison. I used my eprom programmer a lot until heater and Cluso came along and rendered it obsolete!
One of the problems with ram chips is most run on 5V. However... there is a way to use any generic sram chip. Run the latches at 5V instead of 3V (one of the latches doing the LCD display already is at 5V). Data going into the latch from the prop will be 3V to 5V so needs no interfacing. And data coming out of the ram chip into the prop just needs 8x1k resistors in series (to prop pins P0-P7. So for the cost of 8 resistors you can use any chip you like (even 2x32k 62256s if you decode the A15 line).
30 boards arrived today. There is no one supplier that sells everything so I'm pulling together some bits so I could send out a board plus the hard-to-get parts (eg the ram chip, the sd card holder, the coils and switchers, and the vga socket plus maybe a few more things) and then the extra parts like generic sockets and logic chips and leds and resistors could be sourced locally.
Re Eagle, there is a huge learning curve, very steep, but well worth persevering with. Do the schematic first. Check for unconnected tracks by grabbing each component and moving it a bit. Ask for questions about the hard bits. Then move to the board. Then do the autorouter. Then do many ripups/moves/redraws on the autorouter, moving parts around slightly each time. Then optimise a few things like making power traces thicker and moving vias away from pads. Then turn it into a gerber (takes about 30 seconds but it has some obscure menus to negotiate). Then send to a PCB maker. And then they send you back the boards with a nice Christmas card as well (Thanks, OurPCB!).
I went through all the above learning process about two years ago and I wrote some of it up in an Instructable.
OR - make your own PCB like Toby. The design is simple enough for home PCBs.
OR - hopefully those boards will arrive soon but if not by next week, heck, I'll send a third...
This latest rendition of Dr_A's is the same cct but now with the fourth and third latches missing, along with all of the '232 stuff. This meens the memory is just 64KB and my '232 to TTL interface is the only way in/out ( if that bit becomes importnt there is some space on the second layer )
I could use P24 + P25 for memory paging up to 256KB, but then I thought I would have enough spare pins to get rid of the decoder as well.
The op codes, I looked at your words and think I may have got the gist of the way it's done, but work has gone manic ( before Xmas ) and so all thinking would be muddled. I have 2 weeks off soon and if SHE (and HER spawn) allow me a moment's peace....
The EX and EXX are important for the Nascom EMU_DB64.
As for "Does size matter?" I have some SM bits and I could have another ironing fest
PS just thought, I havent put the pullup onto the latch, again, Will try that tonight and see if this one suffers the PSU startup probs too. 5V and 3.3V separate on this one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/23/2009 8:09:30 AM GMT
EX and EXX are coded now, but only on the dracblade, not on the official zicog. I am not sure who is the holder of the official zicog code - heater or cluso99? It was in the last drac code though I can post it again see below (though you need to add a few pointers too). Heater may well be able to see a way to code these faster. I think heater was going to have some time soon to look at these.
I'm working on ways of getting spin and CP/M to talk to each other. Eg, let's say a board needs a unique identifier, for use in a network for instance. We can save a tiny text file on the sd card either by copying it from a PC (created in notepad) or with a few lines of spin:
PUB WriteName ' test writing a name to the sd card from CP/M - call after the sd card initialised eg just before zicog
sd.popen(string("MYNAME.TXT",0),"w") ' open file Myname.txt - terminate with 0
sd.pwrite(string("Alpha "),8) ' write 8 bytes to file, pad alpha beta gamma to 8 chars
sd.pclose ' close the file
CP/M can send something to an out port and put up to 128 bytes at memory location 80H and can write files onto the sd card this way. But for this example, we are interested in reading files off the sd card. So, MYNAME.TXT may or may not exist. At bootup, we run this tiny code which gives a prompt if it does not exist and if it does, then prints out the name of the board.
PUB ReadMyName | r
' MYNAME.TXT is a tiny text file max 8 bytes created with notepad and copied to the SD card
' names are ALPHA BETA GAMMA EPSILON etc through the Greek alphabet
' pad unneeded bytes with spaces
r:=sd.popen(string("MYNAME.TXT",0),"r")
r:=sd.pread(@myname,8) 'get 8 bytes Alpha... Beta.... etc
if r<0
printstringcr(string("MYNAME.TXT not found"))
else
vgatext.str(String("Board name = "))
vgatext.str(@myname) ' terminates with 0 and the array is 9 bytes and only copied 8 to the array so the last byte is 0 which is the terminator
sd.pclose
Next, we need a little routine to return the filename (and, just as importantly, not crash if the board has not been named yet).
First, define an arbitrary port number in the VAR section:
myname_port = $70 ' hopefully not used by anything else
and then capture any outputs to this port in the PRI on_output
PRI on_output
case io_port
...
myname_port:
GetMyname ' returns board name in DMA 80H
and then process this request:
PUB GetMyname | r
' reads 8 bytes from MYNAME.TXT and puts them in the DMA starting at address 80
' could pass io_data here if wanted to pass a value (0-255)
' small program is myname.mac OUT (70H),A where A doesn't really matter but is passed in io_data
r:=sd.popen(string("MYNAME.TXT",0),"r")
r:=sd.pread(@myname,8) 'get 8 bytes Alpha... Beta.... etc
if r>=0
'vgatext.str(@myname)
RamLatches.DoCmd("W", @myname, 128, 8) ' move 8 bytes from myname array to address 80H
sd.pclose
and finally, some code to test this. While machine code and C are the pukka way to do this, nothing is quicker for debugging than the MBASIC interpreter:
10 REM an out to port &H70, with any value to get back the name of the board
20 OUT &H70,0
30 FOR I=&H80 TO &H87 ' read 8 bytes
40 J=PEEK(I) ' store in J
50 IF J>=65 AND J<127 THEN A$=A$+CHR$(J) ' ignore spaces at the end
60 NEXT I
70 PRINT A$ ' print out the name
80 PRINT LEN(A$) ' and just a quick test print out the length, which is 5 for ALPHA
While it is more complicated to create big text files on the FAT part of the SD card, this shows how it is quite easy to read and write tiny files as long as they are 128 bytes or less. This could be useful for changing bootup parameters from within CP/M by writing to various setup files. (Somthing that Cluso is working on as well).
Next step is using these named boards to create links between boards via wireless, with a timeout and with the ability to tell other boards not to talk for a while when two boards are communicating.
For reference, EXX and EX pasm code
'---------------------------------------------------------------------------------------------------------
'---------------------------------------------------------------------------------------------------------
'ex af,af' overlay. rdbyte and wrbyte are value,address for both
org OVERLAY_START
ex_af_af_ovl wrbyte flags, f_reg ' local flags to hub register
rdbyte data_8,f_reg ' get it back into data_8
mov data_16,f_reg ' temp store
add data_16,#8 ' alt flags location in data_16 (temp variable)
rdbyte temp1,data_16 ' get the alt flag data into temp1
wrbyte data_8,data_16 ' F to F'
wrbyte temp1,f_reg ' F' to F
mov flags,temp1 ' put the F' to local flags
wrbyte flags,f_reg ' and put into hub too for break display
' now do the A register
add data_16,#1 ' data_16 to A' register
rdbyte data_8,a_reg ' A to data_8
rdbyte temp1,data_16 ' alt A to temp1
wrbyte data_8,data_16 ' A to A'
wrbyte temp1,a_reg ' A' to A
jmp #fetch
long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED)
ex_af_af_ovl_end
fit $1F0
'---------------------------------------------------------------------------------------------------------
'exx overlay.
org OVERLAY_START
exx_ovl mov data_16,c_reg ' happens to be 0 ie regbase
add data_16,#8 ' data_16 now points to the alt BC reg
rdword data_8,c_reg ' get BC into data_8 (messy as storing 2 bytes in data_8)
rdword temp1,data_16 ' BC' to temp1
wrword data_8,data_16 ' BC to BC'
wrword temp1,c_reg ' BC' to BC
add data_16,#2 ' point to DE'
rdword data_8,e_reg ' get DE into data_8
rdword temp1,data_16 ' DE' to temp1
wrword data_8,data_16 ' DE to DE'
wrword temp1,e_reg ' DE' to DE
add data_16,#2 ' point to HL'
rdword data_8,l_reg ' get HL into data_8
rdword temp1,data_16 ' HL' to temp1
wrword data_8,data_16 ' HL to HL'
wrword temp1,l_reg ' HL' to HL
jmp #fetch
long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED)
exx_ovl_end
fit $1F0
Thank you very much Dr_A I can't wait to build your board.. I know about the chips I just got carried away and thought 1Meg Ram Wow not really thinking it through ,, But the offer does stand if anyone wants or needs any of these chips just email and I will mail some out to you
Dr_A if you would like a bunch for your Z80 or anything at all let me know I have 50 pieces of most and 100 of some I can not possibly use all these so guys please don't be shy even if your a neewbie and would like some chips please just ask
I was thinking just for the heck of it we could use the 2764 eproms and make some kind of boot image or firmware I know it would eat a lot of prop pins but thinking out load could we load the BIOS from the eprom(2764) then have it disconnect through software
the 2764 and then free the I/O lines????
Mike.
P.S Heater I am not positive it was you but I thought someone was looking for the older style eproms if you want any of the chips or even the Z80 please just ask I know same deal the 1Meg ram will eat pins but I have 256K Sram as well.
Dr-Acula I have been designing schematics for ever I can do that I want to have real boards made from my designs if you don't mind me asking in Eagle Pro I have been trying to learn but I am confused do I have to when building a board set each and ever individual PAD??
I can take parts and place them on the boards and I figured out how to run wires but it does not look right I am not sure what to do about the PADS????
Can I show you a quick example of what I did ?
Thank you
I have put the 10K pullup onto the '138 gate and the waveform goes from the sagging signal (expected) to a crisp held up one. This time the systen boots ok with, or without the pullup but with the added capacitance of the 'scope probe, without the 10K, booting was a random affair. This time I have ran the 5 Volt and 3.3 Volt regs off of the incoming 9 Volts, rather than cascading them, the beasty runs barely warm anyway.
Speaking of stacks of old chips, I still have a load of 27c1001s but I need to run WIN98 to to get the KISS programmer to go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Hi mikediv. Parallelling up eproms and ram chips would be quite possible as all the address and data lines could be shared, and you could do the chip select off a spare 138 output. The biggest problem is the 5V issue so would need those 8x1k resistors.
Re Eagle, can you describe the problem a bit more? Just for a very simple example, start a new schematic and drop a couple of TTL chips on it, and join with one wire. Then go to the board view and you will see the two chips off the board. Move them into the middle of the board and you should see the airwires joining the pads. Then run the autorouter and it will put in the traces. So you never really need to worry about joining to the pads (yes, you can do manual tracing but I've never needed to).
Can you a quick screen capture of what you have done and post it here as an attachment?
My new boards arrived (version 3) and I soldered up three of them.
Silly me though, I was short one 10k pullup so I decided to leave one out, and now it doesn't work. The line I left it out of is DO of the SD card (to P12 on the prop) and I figured this could be left out because it was data from the sd card to the prop. The current schematic has 10k pullups on CS, DI, CLK and IRQ.
Bad move! Putting in an extra resistor fixes it so this is the problem. I think this might be related to some of the problems Toby is having and I'm starting to think all the pullups are needed. But I don't understand why...
Ok, deep inside the code, in the sdspiFemto.spin is some code to stop the DO pin. I'm not 100% sure how much of this 'stop' code is there because it is needed to drive an SD card, or because of Cluso99s specific requirements.
(Intriguingly, Cluso comes up in the very latest fsrw code safe_spi
{=== these PASM functions get me in and out of multiblock mode ===}
release_DO
' we're already out of multiblock mode, so
' deselect the card and send out some clocks
or outa,maskCS
call #in8
call #in8
' if you are using pull-up resistors, and need all
' lines tristated, then uncomment the following line.
' for Cluso99
'mov dira,#0
release_DO_ret
ret
But that isn't code I'm using. This is the code I'm using:
'' Stop SPI communications. Any previously used I/O pins are set to input
'' mode and the masks for the I/O pins are zeroed.
spiDoStop
andn dira,spiMaskCS ' This is used for the situation
mov spiMaskCS,#0 ' where the pins used for the SD
andn dira,spiMaskDI ' card may be used for some other
mov spiMaskDI,#0 ' purpose when the card is removed
andn dira,spiMaskClk
mov spiMaskClk,#0
andn dira,spiMaskDO
mov spiMaskDO,#0
jmp #i2cGoUpdate
{{
' Cluso code commented out at present
' Modification by Cluso99 to force the SD card to tristate the D0 pin (allows other chips on the bus)
spiDoStop or outa,spiMaskCS ' CS=1
andn dira,spiMaskDO ' disable D0 as output (s/be input anyway)
call #spiRecvByte ' Output a stream of clocks
andn dira,spiMaskCS ' CS input
mov spiMaskCS,#0 '
mov spiMaskDO,#0 ' D0 already input (above)
andn dira,spiMaskDI ' DI input
mov spiMaskDI,#0 '
andn dira,spiMaskClk ' CLK input
mov spiMaskClk,#0
jmp #i2cGoUpdate
}}
The thing is that I don't understand what is supposed to be going on here. My understanding is that DO only ever is an input to the propeller, so I can't see why you would want to disable it. Indeed, in Cluso's code there is the comment "s/be input anyway". Except that Cluso also then goes and explicitly makes it tristate just after that line.
I'm trying to work out what the code does when it boots up the SD card. I'm presuming it sends out some bytes and then expects something to come back. I'm not sure why the pullup on DO should make any difference to what comes back - it should be high or low regardless of the pullup. The only explanation here that I can think of is that somewhere in the code it reads back a high which registers as success in some way, but the high is there because of the pullup, not because of the SD card status. And that has never really been obvious that is happening because everyone specifies the pullup.
The *simple* answer is to put the pullup on DO. But then I have to get more boards made OR send out boards with an errata.
There seems to be a lot of different opinions out there on the 'net about pullups. Eg "In the Appendix on page A-1, the PDF briefly mentions that MMC cards power up in open-drain mode and can not handle a clock faster than 400KHz. After initializing the card, it switches over to push-pull mode where the pull up resistor would no longer be needed."
Implying you do need pullups. fsrw mentions 6 resistors for 4 lines. Are the other two DAT1 and DAT2? (pins 8 and 9 on the sd card)
Oh, and just to muddy the waters even further, this is a standard sized sd card, but it actually is a micro sd card sitting in an adapter that goes to a standard sized one. So it really is a micro sd card (I have not had much luck with certain brands of standard size sd cards, so I'm sticking with sandisk 1gig uSD in a standard holder, because it works (and because they are only $7 on ebay))
The circuit that works is www.ucontroller.com/documentation/SDCardDoc.html which has *five* pullups. I'm not sure I'm game to leave any of them out now without really understanding more about how this works.
Anyone who can shed some light on this (fsrw experts) would be most appreciated!
On my SD card I/F I only put a pullup on CSn, and don't have any problems. Rayman doesn't have any problems with no pullups!
I use a MiniSD card which is actually an adapter with a microSD card in it. It's supplied by Kingston Micro. I'd be a bit wary buying stuff like SD cards off Ebay, especially if they are very cheap. Their are lots of counterfeiters around.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
I found that I didn't need any of the pullups on Propcomm ccts and so I didn't put any on the Blade2 Bd, on the VDU bit, Clusso has some already on his bit but as that is using each pin for half a dozen different things I left them in. I have used 10Ks on all 4 lines on both of the DB bds as you had said that you had early problems without them. The pullup I keep forgetting is the 74HC138 pin4 one, this leads to ram access problems and the sysyen drops out with a "Spacebar" error, which I do not see fully because I do not build the two '232 bits.
The small 64K version seems to be better on bootups, with or without the gate pullup, which is on now. Perhaps it is better layout, different feeding of the two regs or the on/off switch I remembered this time, which should give a better defined power rising edge.
The addition of pullups didn't seem to help, or hinder, with the operation of more SD cards, only the two (of 5) fired up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I'll get to the fsrw code soon, but in the meantime I've written the code to latch the A16-A19 of the high latch. So now the raw code for banking is ready to go, plus this gives easy access to all 512k of the ram chip.
There is a new command H to set the high byte latch. So the command set is now:
''Dracblade driver for talking to a ram chip via three latches
'' Modified code from Cluso's triblade
' DoCmd(command_, hub_address, ram_address, block_length)
' R - read bytes at address n up (n to n+block_length) where n =0 to 65535 (ie lower 64k of the sram chip)
' W - write bytes at address n up
' I - initialise
' N - Led on (pass "N" and other values are zero)
' F - Led off
' H - set high latch to value in ramaddress A16 to A23 (will include the led)
Given the address is already passing a long, this is passed with the address
HighLatchByte :=%00000000_00000000_00000000_00000000 ' xxxxxxxx_nnnnnnnn_xxxxxxxx_xxxxxxxx where n is A16 to A23
RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' set high latch byte A16-A19, plus led plus the 4 spare outputs
So for bank 0 pass zero, for bank 1 pass
HighLatchByte :=%00000000_00000001_00000000_00000000
etc.
HighLatchByte is added to the VAR list in the main program
If you set it up to run in bank 111, ie in the top 64k of the sram, instead of the bottom 64k ram, it will happily load zicog and run CP/M fine. This leads to the concept of running a number of virtual CP/M machines all at once, which I think is what MP/M does.
In the dracblade.spin program there are some extensive changes to add the new H command. There also ended up some common code with turning the led on and off, so it ended up simpler to combine these all together. As a result, the syntax for turning on and off the led has changed in the spin code in the Main program
Instead of
RamLatches.LedOn
the command is now
RamLatches.DoCmd("N",0,0,0)
Which is more in keeping with passing a command as a single letter, and then 0 to 3 variables.
I've attached the entire code as a zip.
And I should add there is a bit of code at the beginning that reads the name of the board as a tiny text file off the sd card. If you don't want this then comment it out - the command to do this is just before the zicog is started
ReadMyName ' comment this out if not needed
service_io
I'm naming boards so that they can find each other in a network. Also it demonstrates a way of CP/M talking to FAT16 files on the sd card.
Also I've been working on a new board layout - making chips closer and have managed to create enough space to add an octal buffer for another 8 inputs. This won't affect any of the existing code, but it does give the board 8 inputs (and the existing 4+2+1=7 outputs)
Comments
Get cpmtools from here: www.moria.de/~michael/cpmtools/ or as a package in Debian etc.
Add an entry to the configuration file "diskdefs" to specify zicog HD image layout;
Then you can play with files inside a ZiCog HD image like so:
Not sure how to set zicog as the default format yet.
Yoda: We have been using packed sectors for many months now[noparse]:)[/noparse]
It's a useful speed up what with caching four CP/M sectors in our SD buffer space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@Yoda, the hard drive images ended up so much more convenient than the floppy ones that we have abandoned the floppy ones. The hard drive images are directly compatible with the SIMH. I've got a little batch file for the simh that has Drives A-H as floppy images and drives I, J as hard images. If I want (say) the drive with the C compiler, I grab it from the simh site, copy my BLANK.DSK to I.DSK, fire up my simh, do a PIP *.* to drive I, then put that drive I on the SD card (renamed as - say - C.DSK) and it is good to go.
It would be really handy to be able to transfer these hard drive images to and from the N8VEM. I see that Andrew Lynch is starting on a board for the N8VEM using the prop. It ought to be possible for the N8VEM to get access to these 8mb drive images via the SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I am planning on using the same format on the propIO so that there is interchangeability. Also within reason I am trying to make them compatible at the CBIOS level as well so that they will be bootable on either platform in the future.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Ladies and gentlemen, what are you forcasts of this one working ?
I have to go to far flung provinces of this land, and so will be denigned the switching on until Wednesday.
Bets ( to finance the new PC PSU and garage freezer ) gratefully received
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I'm very impressed with how small you have made this. And I do like the philosophy of treating this board like a fine red wine or a tasty cheese - let it mature for a while before testing!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/21/2009 12:12:41 AM GMT
Toby, that is a great photo of a small module. I have not been following closely - what is the hardware???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (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 thought CP/M stood for Cigarette Packet / Micro, doesn't it ??
I'll be back on Weds, so perhaps then, another YIPPEE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (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
They will never find that on the bus.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Is this the first official view of a soldered up ramblade?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
heater: No, but if they sit on it they will feel the pain
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
A belated one, but I have not been on the forum much recently.... too much life..
I am SOOOOOOO impressed
VERY IMPRESSIVE...... congratulations.
I must also say that I like the new avatar a LOT more than the previous one.
I hope you have a wonderful success with this, you deserve it.
Samuel
Plus there might be some non Z80, non CP/M applications on the way...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
And it's another YIPPEEEE. First time, which shows that the design is near to bomb proof. This is a second time I chose to lop lumps off it and it still lives !!
Thanks guys
Now Clusso has started a size war, I'll cling to the notion that MY attempt has connectors ! Two pics- one in it's spead eagle mode and a boot screen.
PS I don't know if this is Cigarette packet sized or not. I do not know one person that smokes. Whwn I asked, at the local shop, if I could just jet the dimensions of one they looked at me as if I were the most blatent shoplifter they had in this week ( beleive me, I,m no runner)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Good to see homebrew versions working. Which bits are you lopping off - can you post a schematic?
Cluso has won the size war comprehensively, so I'm also going to go with the "my board includes plugs" argument. Mind you, Cluso will probably put the thing in a plug next...
Note to self - I must get motivated to do the 'hard' problem of getting the Z80 opcoces working. I keep putting it off, partly because it is quite hard to actually isolate the instructions as the EX program has them in groups and just tells you the group failed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I see on the N8VEM group someone is proudly showing off their CP/M box. It's very nice and all but it is the size of a house by comparison!
Dr_A: I have been looking at the missing/incorrect op codes, problem is Christmas is now going to get in the way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
MCM60256AP10 256K Sram, the old style 27256 Eprom and the giant 27C010A-10 32 Pin Eprom I bought 100 of each and will be happy to share if we can use them I just ask that you guys would share any code with me.. I have this awesome programmer this thing will burn any Eprom, Ram, Pic, Arm, Atmel, EEprom you name it it will burn it it also tests the chips it will do over 10K devices I even got all the adapters for it, I tested the parts and it identified them so I know they are good I can even stick code on them if you guys want to pre-program them
Let me know if we can use them
Mike.Div
Oh and happy holidays to everyone,, one more thing I drew up a board design well the schematic in Eagle Pro it was a real Bich for me can anyone help me figure out how I can get my boards made now I do not know how to do anything but draw the schematic is that good enough for having boards made?? thanks
Meanwhile, what are you doing buying all those bits?! Actually, if you want, they could come in handy for a N8VEM board if you wanted to build a real Z80 board. Certainly it has been very handy for a few of us when debugging to have a real board as well for comparison. I used my eprom programmer a lot until heater and Cluso came along and rendered it obsolete!
One of the problems with ram chips is most run on 5V. However... there is a way to use any generic sram chip. Run the latches at 5V instead of 3V (one of the latches doing the LCD display already is at 5V). Data going into the latch from the prop will be 3V to 5V so needs no interfacing. And data coming out of the ram chip into the prop just needs 8x1k resistors in series (to prop pins P0-P7. So for the cost of 8 resistors you can use any chip you like (even 2x32k 62256s if you decode the A15 line).
30 boards arrived today. There is no one supplier that sells everything so I'm pulling together some bits so I could send out a board plus the hard-to-get parts (eg the ram chip, the sd card holder, the coils and switchers, and the vga socket plus maybe a few more things) and then the extra parts like generic sockets and logic chips and leds and resistors could be sourced locally.
Re Eagle, there is a huge learning curve, very steep, but well worth persevering with. Do the schematic first. Check for unconnected tracks by grabbing each component and moving it a bit. Ask for questions about the hard bits. Then move to the board. Then do the autorouter. Then do many ripups/moves/redraws on the autorouter, moving parts around slightly each time. Then optimise a few things like making power traces thicker and moving vias away from pads. Then turn it into a gerber (takes about 30 seconds but it has some obscure menus to negotiate). Then send to a PCB maker. And then they send you back the boards with a nice Christmas card as well (Thanks, OurPCB!).
I went through all the above learning process about two years ago and I wrote some of it up in an Instructable.
OR - make your own PCB like Toby. The design is simple enough for home PCBs.
OR - hopefully those boards will arrive soon but if not by next week, heck, I'll send a third...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I could use P24 + P25 for memory paging up to 256KB, but then I thought I would have enough spare pins to get rid of the decoder as well.
The op codes, I looked at your words and think I may have got the gist of the way it's done, but work has gone manic ( before Xmas ) and so all thinking would be muddled. I have 2 weeks off soon and if SHE (and HER spawn) allow me a moment's peace....
The EX and EXX are important for the Nascom EMU_DB64.
As for "Does size matter?" I have some SM bits and I could have another ironing fest
PS just thought, I havent put the pullup onto the latch, again, Will try that tonight and see if this one suffers the PSU startup probs too. 5V and 3.3V separate on this one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/23/2009 8:09:30 AM GMT
EX and EXX are coded now, but only on the dracblade, not on the official zicog. I am not sure who is the holder of the official zicog code - heater or cluso99? It was in the last drac code though I can post it again see below (though you need to add a few pointers too). Heater may well be able to see a way to code these faster. I think heater was going to have some time soon to look at these.
I'm working on ways of getting spin and CP/M to talk to each other. Eg, let's say a board needs a unique identifier, for use in a network for instance. We can save a tiny text file on the sd card either by copying it from a PC (created in notepad) or with a few lines of spin:
PUB WriteName ' test writing a name to the sd card from CP/M - call after the sd card initialised eg just before zicog sd.popen(string("MYNAME.TXT",0),"w") ' open file Myname.txt - terminate with 0 sd.pwrite(string("Alpha "),8) ' write 8 bytes to file, pad alpha beta gamma to 8 chars sd.pclose ' close the fileCP/M can send something to an out port and put up to 128 bytes at memory location 80H and can write files onto the sd card this way. But for this example, we are interested in reading files off the sd card. So, MYNAME.TXT may or may not exist. At bootup, we run this tiny code which gives a prompt if it does not exist and if it does, then prints out the name of the board.
PUB ReadMyName | r ' MYNAME.TXT is a tiny text file max 8 bytes created with notepad and copied to the SD card ' names are ALPHA BETA GAMMA EPSILON etc through the Greek alphabet ' pad unneeded bytes with spaces r:=sd.popen(string("MYNAME.TXT",0),"r") r:=sd.pread(@myname,8) 'get 8 bytes Alpha... Beta.... etc if r<0 printstringcr(string("MYNAME.TXT not found")) else vgatext.str(String("Board name = ")) vgatext.str(@myname) ' terminates with 0 and the array is 9 bytes and only copied 8 to the array so the last byte is 0 which is the terminator sd.pcloseNext, we need a little routine to return the filename (and, just as importantly, not crash if the board has not been named yet).
First, define an arbitrary port number in the VAR section:
and then capture any outputs to this port in the PRI on_output
PRI on_output case io_port ... myname_port: GetMyname ' returns board name in DMA 80Hand then process this request:
PUB GetMyname | r ' reads 8 bytes from MYNAME.TXT and puts them in the DMA starting at address 80 ' could pass io_data here if wanted to pass a value (0-255) ' small program is myname.mac OUT (70H),A where A doesn't really matter but is passed in io_data r:=sd.popen(string("MYNAME.TXT",0),"r") r:=sd.pread(@myname,8) 'get 8 bytes Alpha... Beta.... etc if r>=0 'vgatext.str(@myname) RamLatches.DoCmd("W", @myname, 128, 8) ' move 8 bytes from myname array to address 80H sd.pcloseand finally, some code to test this. While machine code and C are the pukka way to do this, nothing is quicker for debugging than the MBASIC interpreter:
While it is more complicated to create big text files on the FAT part of the SD card, this shows how it is quite easy to read and write tiny files as long as they are 128 bytes or less. This could be useful for changing bootup parameters from within CP/M by writing to various setup files. (Somthing that Cluso is working on as well).
Next step is using these named boards to create links between boards via wireless, with a timeout and with the ability to tell other boards not to talk for a while when two boards are communicating.
For reference, EXX and EX pasm code
'--------------------------------------------------------------------------------------------------------- '--------------------------------------------------------------------------------------------------------- 'ex af,af' overlay. rdbyte and wrbyte are value,address for both org OVERLAY_START ex_af_af_ovl wrbyte flags, f_reg ' local flags to hub register rdbyte data_8,f_reg ' get it back into data_8 mov data_16,f_reg ' temp store add data_16,#8 ' alt flags location in data_16 (temp variable) rdbyte temp1,data_16 ' get the alt flag data into temp1 wrbyte data_8,data_16 ' F to F' wrbyte temp1,f_reg ' F' to F mov flags,temp1 ' put the F' to local flags wrbyte flags,f_reg ' and put into hub too for break display ' now do the A register add data_16,#1 ' data_16 to A' register rdbyte data_8,a_reg ' A to data_8 rdbyte temp1,data_16 ' alt A to temp1 wrbyte data_8,data_16 ' A to A' wrbyte temp1,a_reg ' A' to A jmp #fetch long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED) ex_af_af_ovl_end fit $1F0 '--------------------------------------------------------------------------------------------------------- 'exx overlay. org OVERLAY_START exx_ovl mov data_16,c_reg ' happens to be 0 ie regbase add data_16,#8 ' data_16 now points to the alt BC reg rdword data_8,c_reg ' get BC into data_8 (messy as storing 2 bytes in data_8) rdword temp1,data_16 ' BC' to temp1 wrword data_8,data_16 ' BC to BC' wrword temp1,c_reg ' BC' to BC add data_16,#2 ' point to DE' rdword data_8,e_reg ' get DE into data_8 rdword temp1,data_16 ' DE' to temp1 wrword data_8,data_16 ' DE to DE' wrword temp1,e_reg ' DE' to DE add data_16,#2 ' point to HL' rdword data_8,l_reg ' get HL into data_8 rdword temp1,data_16 ' HL' to temp1 wrword data_8,data_16 ' HL to HL' wrword temp1,l_reg ' HL' to HL jmp #fetch long $0[noparse][[/noparse]($ - OVERLAY_START) // 2] 'fill to even number of longs (REQUIRED) exx_ovl_end fit $1F0▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Dr_A if you would like a bunch for your Z80 or anything at all let me know I have 50 pieces of most and 100 of some I can not possibly use all these so guys please don't be shy even if your a neewbie and would like some chips please just ask
I was thinking just for the heck of it we could use the 2764 eproms and make some kind of boot image or firmware I know it would eat a lot of prop pins but thinking out load could we load the BIOS from the eprom(2764) then have it disconnect through software
the 2764 and then free the I/O lines????
Mike.
P.S Heater I am not positive it was you but I thought someone was looking for the older style eproms if you want any of the chips or even the Z80 please just ask I know same deal the 1Meg ram will eat pins but I have 256K Sram as well.
Dr-Acula I have been designing schematics for ever I can do that I want to have real boards made from my designs if you don't mind me asking in Eagle Pro I have been trying to learn but I am confused do I have to when building a board set each and ever individual PAD??
I can take parts and place them on the boards and I figured out how to run wires but it does not look right I am not sure what to do about the PADS????
Can I show you a quick example of what I did ?
Thank you
I have put the 10K pullup onto the '138 gate and the waveform goes from the sagging signal (expected) to a crisp held up one. This time the systen boots ok with, or without the pullup but with the added capacitance of the 'scope probe, without the 10K, booting was a random affair. This time I have ran the 5 Volt and 3.3 Volt regs off of the incoming 9 Volts, rather than cascading them, the beasty runs barely warm anyway.
Speaking of stacks of old chips, I still have a load of 27c1001s but I need to run WIN98 to to get the KISS programmer to go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Re Eagle, can you describe the problem a bit more? Just for a very simple example, start a new schematic and drop a couple of TTL chips on it, and join with one wire. Then go to the board view and you will see the two chips off the board. Move them into the middle of the board and you should see the airwires joining the pads. Then run the autorouter and it will put in the traces. So you never really need to worry about joining to the pads (yes, you can do manual tracing but I've never needed to).
Can you a quick screen capture of what you have done and post it here as an attachment?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Silly me though, I was short one 10k pullup so I decided to leave one out, and now it doesn't work. The line I left it out of is DO of the SD card (to P12 on the prop) and I figured this could be left out because it was data from the sd card to the prop. The current schematic has 10k pullups on CS, DI, CLK and IRQ.
Bad move! Putting in an extra resistor fixes it so this is the problem. I think this might be related to some of the problems Toby is having and I'm starting to think all the pullups are needed. But I don't understand why...
Ok, deep inside the code, in the sdspiFemto.spin is some code to stop the DO pin. I'm not 100% sure how much of this 'stop' code is there because it is needed to drive an SD card, or because of Cluso99s specific requirements.
(Intriguingly, Cluso comes up in the very latest fsrw code safe_spi
{=== these PASM functions get me in and out of multiblock mode ===} release_DO ' we're already out of multiblock mode, so ' deselect the card and send out some clocks or outa,maskCS call #in8 call #in8 ' if you are using pull-up resistors, and need all ' lines tristated, then uncomment the following line. ' for Cluso99 'mov dira,#0 release_DO_ret retBut that isn't code I'm using. This is the code I'm using:
'' Stop SPI communications. Any previously used I/O pins are set to input '' mode and the masks for the I/O pins are zeroed. spiDoStop andn dira,spiMaskCS ' This is used for the situation mov spiMaskCS,#0 ' where the pins used for the SD andn dira,spiMaskDI ' card may be used for some other mov spiMaskDI,#0 ' purpose when the card is removed andn dira,spiMaskClk mov spiMaskClk,#0 andn dira,spiMaskDO mov spiMaskDO,#0 jmp #i2cGoUpdate {{ ' Cluso code commented out at present ' Modification by Cluso99 to force the SD card to tristate the D0 pin (allows other chips on the bus) spiDoStop or outa,spiMaskCS ' CS=1 andn dira,spiMaskDO ' disable D0 as output (s/be input anyway) call #spiRecvByte ' Output a stream of clocks andn dira,spiMaskCS ' CS input mov spiMaskCS,#0 ' mov spiMaskDO,#0 ' D0 already input (above) andn dira,spiMaskDI ' DI input mov spiMaskDI,#0 ' andn dira,spiMaskClk ' CLK input mov spiMaskClk,#0 jmp #i2cGoUpdate }}The thing is that I don't understand what is supposed to be going on here. My understanding is that DO only ever is an input to the propeller, so I can't see why you would want to disable it. Indeed, in Cluso's code there is the comment "s/be input anyway". Except that Cluso also then goes and explicitly makes it tristate just after that line.
I'm trying to work out what the code does when it boots up the SD card. I'm presuming it sends out some bytes and then expects something to come back. I'm not sure why the pullup on DO should make any difference to what comes back - it should be high or low regardless of the pullup. The only explanation here that I can think of is that somewhere in the code it reads back a high which registers as success in some way, but the high is there because of the pullup, not because of the SD card status. And that has never really been obvious that is happening because everyone specifies the pullup.
The *simple* answer is to put the pullup on DO. But then I have to get more boards made OR send out boards with an errata.
There seems to be a lot of different opinions out there on the 'net about pullups. Eg "In the Appendix on page A-1, the PDF briefly mentions that MMC cards power up in open-drain mode and can not handle a clock faster than 400KHz. After initializing the card, it switches over to push-pull mode where the pull up resistor would no longer be needed."
Implying you do need pullups. fsrw mentions 6 resistors for 4 lines. Are the other two DAT1 and DAT2? (pins 8 and 9 on the sd card)
Oh, and just to muddy the waters even further, this is a standard sized sd card, but it actually is a micro sd card sitting in an adapter that goes to a standard sized one. So it really is a micro sd card (I have not had much luck with certain brands of standard size sd cards, so I'm sticking with sandisk 1gig uSD in a standard holder, because it works (and because they are only $7 on ebay))
The circuit that works is www.ucontroller.com/documentation/SDCardDoc.html which has *five* pullups. I'm not sure I'm game to leave any of them out now without really understanding more about how this works.
Anyone who can shed some light on this (fsrw experts) would be most appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/24/2009 12:17:51 PM GMT
I use a MiniSD card which is actually an adapter with a microSD card in it. It's supplied by Kingston Micro. I'd be a bit wary buying stuff like SD cards off Ebay, especially if they are very cheap. Their are lots of counterfeiters around.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
The small 64K version seems to be better on bootups, with or without the gate pullup, which is on now. Perhaps it is better layout, different feeding of the two regs or the on/off switch I remembered this time, which should give a better defined power rising edge.
The addition of pullups didn't seem to help, or hinder, with the operation of more SD cards, only the two (of 5) fired up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I have just lifted the DO pullup and baby still fires up, and loads MBASIC, etc, ok.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
There is a new command H to set the high byte latch. So the command set is now:
Given the address is already passing a long, this is passed with the address
HighLatchByte :=%00000000_00000000_00000000_00000000 ' xxxxxxxx_nnnnnnnn_xxxxxxxx_xxxxxxxx where n is A16 to A23 RamLatches.DoCmd("H", 0, HighLatchByte, 0) ' set high latch byte A16-A19, plus led plus the 4 spare outputsSo for bank 0 pass zero, for bank 1 pass
HighLatchByte :=%00000000_00000001_00000000_00000000
etc.
HighLatchByte is added to the VAR list in the main program
If you set it up to run in bank 111, ie in the top 64k of the sram, instead of the bottom 64k ram, it will happily load zicog and run CP/M fine. This leads to the concept of running a number of virtual CP/M machines all at once, which I think is what MP/M does.
In the dracblade.spin program there are some extensive changes to add the new H command. There also ended up some common code with turning the led on and off, so it ended up simpler to combine these all together. As a result, the syntax for turning on and off the led has changed in the spin code in the Main program
Instead of
RamLatches.LedOn
the command is now
RamLatches.DoCmd("N",0,0,0)
Which is more in keeping with passing a command as a single letter, and then 0 to 3 variables.
I've attached the entire code as a zip.
And I should add there is a bit of code at the beginning that reads the name of the board as a tiny text file off the sd card. If you don't want this then comment it out - the command to do this is just before the zicog is started
I'm naming boards so that they can find each other in a network. Also it demonstrates a way of CP/M talking to FAT16 files on the sd card.
Also I've been working on a new board layout - making chips closer and have managed to create enough space to add an octal buffer for another 8 inputs. This won't affect any of the existing code, but it does give the board 8 inputs (and the existing 4+2+1=7 outputs)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/26/2009 2:00:20 AM GMT