The circuit changed on the 28th November. What I need to do is to somehow get a cc of the zip file as it was for the first board to Toby somehow. Events are conspiring against me on that front. I'm not sure what version is on my website as my kids used my monthly download limit playing @#$%^& world of warcraft and so I've been limited to dial up speeds till Christmas Day. So I can't check the zip of the Eagle files, though I did check the pdf capture of the Eagle schematic and that is v2. Toby might have got the original v1 off the raw Eagle files - I'm not sure but sorry about that.
Next thing- I can send Toby a snapshot of the files as they were late 28th November and that has the pin settings correct for the board he has made and should boot the zicog. BUT - I don't want to post it here as it is out of date and someone might download it thinking it was a new version. I tried sending a PM to Toby but it won't allow attachments to a PM for some reason. So maybe Toby can PM me with an email addresss. HOWEVER I'm pulling another 15 hour shift at work tomorrow so I won't get a chance to send the file for another 25 hours.
OR I can post the last board to Toby tomorrow from work if you can PM me a postal address.
V3 does not change any pins around. It simply adds a header for I2C and adds a real time clock and moves some chips around on the board so the traces are shorter. So - no software changes there.
Hey, don't worry about it !!!!!! I'll work around it. I'm knicking your work, so its MY problem. Thanks for the concern.
The differences I have seen so far are the SD and the 1 of 8 decoder. I have more of thos so I will snip it off the rear of the board and rework it in, somehow.
That will be work to be done if there is a Drac_Blade_2. I have already been deaming of a smaller one, I enjoy the design and building more anyway.
ADDIT
The cct I used was *******\Propeller_v2Oct09\Propeller_v2.sch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/9/2009 2:16:53 PM GMT
I have just been in touch with my solicitors. They were very keen to take on my case for punative damages for restitution of the intense dissapointment and trauma.
I was gladened by this but my high hopes were dashed, when I sited Dr_Acula as the guilty party. They said "Go away, and stay there", I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The dreams of getting it smaller will require true SM and a CPLD. No particular reasons for it, just more education.
The ram usage for CP/M is just 64KB at present (V2.2) but I notice drive R. Is that a ramdrive that uses the remains of the 512KB? If it isn't then thats one latch less, or as I am not using both Serial ports, there is a pin or two going begging, there should be a cog too if the LED is taken out. I havent got any 4 row ones.
Thanks for the design and the help over the few problems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Ah, you are thinking ahead already. Yes, it only uses 64k. I think Cluso has managed to use the rest of the memory for banking for another version of CP/M. Or it can be a ram drive but I'm not a huge fan of ram drives - if you turn off the power you lose the data and now the sd card is so fast may as well save to the sd card.
So... you could use a smaller ram chip and lose the latch. Only thing there is that the smaller ram chips tend to be 5V only. But you could fix that by running the latches from 5V instead of 3V and adding 8x 1k resistors in the data lines.
You have to tell us one important detail - What happened between the "press space bar" stage and the "YIPPEEEEEE" stage?
Or is this some version of ZiCog I have not seen that needs a space bar hit to start?
If you are happy with CP/M 2 with 64K then save the pins. We are planning to have banked switched CP/M 3 and MP/M running one day using 256K RAM. Cluso did have CP/M 3 running before we dropped the Altair style floppy support so we know it can be done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
CPM3 will run (it has been running) without enabling banking but requires Floppies. I am waiting in the wings for a HD only version, but I know there are more pressing things first. Then I will test the banking - you can see in the code there is some untested code already there.
I am also planning to run a write-through RamDisk for the remaining ram. Drac, it will not fail if the power is turned off, because if a change is done, it will automatically be written back to the SD card (that is what I call write-through). However, reads will come from ram and writes will check if the data has changed. Write-through will be able to be enabled/disabled. RamDisk will use the remaining SRAM. So, compiles with writethrough off should be especially fast
Off to collect my RamBlade parts from the PO · Maybe running tonight·
BTW I am almost certain now that I can get a 1-pin mono video and 1-pin PS2 Keyboard working, maybe with as few as 4 resistors. Remember, the Keyboard currently requires 4 resistors, but I think 3 will do and 1 for the video
"Blood? Blood? Did someone mention Blood?!" *faints on floor* (as bad as needles- phobia!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re heater to Toby What happened between the "press space bar" stage and the "YIPPEEEEEE" stage - I suspect there was the rapid progression to balding stage with accompanied dark mutterings related to voodoo dolls and effigies of myself and cluso and heater? Best not mentioned. And all forgotten anyway with the YIPPEEEEE!
Cluso - write through sounds very interesting. I can see the logic there, especially given most drive activity is Read rather than Write. Eg when you change drives there is a delay while it loads things from the disk. I'll bet it is the same data each time and if this were buffered it would make things a lot quicker. How would you do the software for this? Would you somehow keep track of the drive # and the sector/track # and have a list of all these with pointers to where they are in ram and then have a rotating list of 128 byte blocks of data? I'll think about this more but it sounds quite intriguing and quite possible with not very much code. And it would be a very useful thing to do with the spare ram capacity.
Lots of exciting news there on the ramblade. Looking forward to seeing one soldered up.
Parts are arriving for the dracblade. Just got 20 ram chips and 20 vga sockets from Future Electronics (yay, no more desoldering sub D15s). SD card sockets shipped out today from Sparkfun. Switchers and other chips are on their way from Futurlec. A pile of 1 gig SD cards coming from Hong Kong. I'm thinking of a kit of parts with pretty much everything except the Propeller (as the prop chip/eeprom/xtal package is $25 here in Australia but a lot cheaper in the US). The suggestion made earlier to distribute from someone in the US makes a lot of sense eg Gadget Gangster. Or Briel Computers or anyone else who would be kind enough to do this.
Heater my email to you must have gone astray - can you PM me with your address so I can send you a board?
And a thought re Toby's board - this shows it is possible to build this with boards made at home. Maybe a few design tweaks (Eagle makes a pretty good effort of single sided autorouting if you make the board a bit bigger so it has room to move). Homebrew boards would be an attractive alternative. Toby, when you redid the board did you go for the v2 schematic ie the change to the 138 pins and the sd pins - if so then the software will be much easier. There were some slight software advantages to grouping the sd card pins as a group of 4 and changing the 138 addresses. Of course, as Toby found, parts of the design can be done in other ways - eg off board/protoboard/otherboard 5V and 3V supplies. Maybe lose the max232 for a different chip or the transistor circuit that is on the parallax demo schematic or even cluso's musings a while back about 0V/3V being (just) within RS232 spec and use a single resistor. The sd card can be standard, mini or micro. The A16-A19 latch can be left out and those 3 lines pulled high or low on the ram chip. The LCD latch is not needed if you don't want a 20x4 LCD. You don't have to use D9 plugs etc etc.
The leap from "spacebar" to "yippee" was totaly my fault. The latch pin (11) on the lower addr mux used the chip pin as the feedthrough from btm to top layer, I hadn't soldered the top bit. It's amazing that a 0.5mm pin could sit in a 0.6mm hole and miss the sides!!!!
At work I have the wireless card from a HP printer, on it ther is the dinkies ram chip I have seen. I am sure that it is 64-128KB but has 0.4mm pitch. I will grab it later on, as I have to taxi a sound mixer around all day, TO LONDON - AAAAHHHHHGGGGGGGG!!!!!!!!!!
This chip will be much the same as the pitch scheduled for the PropII! Long live the D40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby: IIRC the smallest part I am using is 0.5mm pitch. The parts just arrived. Better I do not sneeze when putting them on as I can hardly see them now [noparse]:)[/noparse]
Drac: The RamDisk is just a small hard disk except it is initially read into ram. When a read is done, the driver delivers a block from ram. When a write is done, the block is checked to see if a change has taken place from ram. If so, it is copied to ram and a write to SD follows to write the new sector to SD. So, the SD is always in step with the ram.
However, there will be a switch to turn write-through off. This is because if you want to compile, you do not want to be writing to the sd card all the time, and it will be dramatically faster.
Drac: If you don't mind, what did your·1GB uSD cards·(and SD adapter?) inc shipping work out to be?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I had to pay £10 for a 2GB standard sized one the other day, at least it was a real Sandisk and I knew it would work.
The baby ram is a UT61L1024LS-12, 128KB 12nS. So not so big on mem but quick.
Dr_A····· I considered voodoo, but as you are one of the undead, it would be just a nusance phone call to you. Also, shouldn't your title be Chief Extraction Officer, not Managing Director ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The physical cct was bent to your new flavour, so hopefully it will be a bit more future proofed. It was quicker than ploughing back through all the software anyway. It only needed the sacrifice of the '138 and a scalpel (No 11) a few bits of new bridging wires and the reordered ram_wr was adjacent to the new pin already, one blob later I was at the "spacebar" bit. The KBD problem was me doing a mirror image of the CLK and DATA lines on the socket, yet I had the + and - the right way around (curse that apple juice!). Then there was the unfed feed through, that is where your board will alwasy be superior, definite conections from one side to the other and the copper pads are rivits, not just fragile islands. There is the great advantage of knowing the board design and the prat that made it, when it comes to the rebuild , on day two!
10000 loops of MBASIC was about 22 secs, so a bit slower than the Blade2, but that is to be expected with all the latchings. Still at 5MHz untill I get more used to where it could be pushed. I will have to play with the kbd layout to get it "English layout".
I tried WS, the first time it announced itself and then cleared the screen, now it just clears the screen. I dont know if this is the sign of more problems, or not, but I can live without it for now.
Addit- I tried 6, 6.55 and 7.3MHz rocks but only the 6MHz was stable. From distant memory, I recon the board is emulating about 3+ MHz. I tried the pullup on '138 pin 4 (gate) P9 but the board started to boot with occational "SpaceBars" etc, so it's now off and boots seem better. Hey-Ho.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/10/2009 11:30:08 PM GMT
Looks likeyou are pushing the limits already with the overclocking. There is a NOP in the memory read and memory write. I tried one NOP (and two) and it works but no NOP does not work. Cluso can use no NOP because there is no propogation delay through the 138. So as you overclock you could try extra NOPs but if you do you will have to go to 8080 as there is no space free in the Z80, even for two NOPs. Then one could argue the benefits of overclocking with extra NOPs, but it still might be worthwhile as the memory read and write are still only a small % of the instructions.
Toby - are you game to start looking at adding an extra Z80 instruction or two?
Yes, Drac is correct, there are delays being introduced via the decoder and latches that you need to be aware of. For my implementations, over 100MHz requires another look at the timing as I think it was just inside for 100MHz.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I agree that overclocking is a game of chance, I was just trying to feel for the edge and then back off a safe margin. That seems to be edge @ 96-100MHz and the safe margin 80MHz or so, at least I know that the edge isn't at 81MHz.
The adding of extra instructions is one of my wishes, and so I will sit down and try to figure out the problems. Heater could do it but that would leave me gratefully freeloading, and ingnorant. So finger out !! The brain is not that far behind the eyes though. If I can suss out the adding of the extra bits ( vital for Nascom stuff ) then the original Z80 interest will be revived.
Accidently left the DracBlade on last night, it was just sat there patiently waiting, this morning, bless.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby: My timing has all been done technically using chip specifications.
However, the overclocking (and some propeller timing) is not available. This section must be tried and then a safety margin added. Of course, this then comes with a caveat that it may not work as designed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
First step I figure is some sort of printout of the registers. I copied the format from DDTZ which takes two lines to print out the registers and looks like this:
A>bbcbasic
AF =0300 BC =440C DE =014F HL =E3EF SP =E39D PC =0122
AF'=0000 BC'=0000 DE'=0000 HL'=0000 IX =0000 IY =0000
Unimplemented instruction at location PC, spacebar to continue
It is easy to change the spincode to print that out:
PRI print_regs
'Print the Z80 registers to vga display and to terminal program on the serial port
RegString(string("AF ="))
HexOutput(af_reg)
RegString(string(" BC ="))
HexOutput(bc_reg)
RegString(string(" DE ="))
HexOutput(de_reg)
RegString(string(" HL ="))
HexOutput(hl_reg)
RegString(string(" SP ="))
HexOutput(sp_reg)
RegString(string(" PC ="))
HexOutput(pc_reg)
RegString(string(13,10)) ' new line for alternate register
RegString(string("AF'="))
HexOutput(af_reg_alt)
RegString(string(" BC'="))
HexOutput(bc_reg_alt)
RegString(string(" DE'="))
HexOutput(de_reg_alt)
RegString(string(" HL'="))
HexOutput(hl_reg_alt)
RegString(string(" IX ="))
HexOutput(ix_reg)
RegString(string(" IY ="))
HexOutput(iy_reg)
RegString(string(13,10))
And add these two pubs underneath so the debug code goes to both the terminal and to the vga display (having both is useful - the vga display if you can't be bothered waiting for windows to turn on and run a terminal program, but a terminal program is useful if you want to capture text and copy and paste it to the forum etc)
PUB HexOutput(HexValue)' send hex value to vga and to terminal
UART.hex(0,HexValue, 4)
vgatext.hex(HexValue,4)
PUB RegString(RString)
UART.str(0,Rstring) ' send to the serial port
vgatext.str(Rstring) ' send to vga display
In terms of priority opcodes, DDTZ lists a few at the beginning and these might even be in the right order:
; z80 opcodes used if Z80 cpu only
exaf macro
db 08h
endm
exx macro
db 0d9h
endm
pushix macro
db 0ddh,0e5h
endm
popix macro
db 0ddh,0e1h
endm
pushiy macro
db 0fdh,0e5h
endm
popiy macro
db 0fdh,0e1h
endm
I note EXX does have a jump location but no code at that location.
PM from heater saying he is very busy. So if we can share this out a bit it will make things quicker. First thing (oops) is to ask the incredibly busy heater a question:
In the main program is a list of words that store the registers:
register_file word
bc_reg word 0
de_reg word 0
hl_reg word 0
af_reg word 0
bc_reg_alt word 0
de_reg_alt word 0
hl_reg_alt word 0
af_reg_alt word 0
im_reg word 0
ix_reg word 0
iy_reg word 0
sp_reg word 0
pc_reg word 0
And in the zicog object is a list but it seems only partially complete:
I would presume these are in the same order and that the alternate registers sit somewhere between 8 and 18.
But the question is - where does the im_reg sit? In the first listing I'd be guessing that BC is at 0, DE at 2, HL at 4, AF at 6, BC' at 8, DE' at 10 HL' at 12, AF' at 14, IM at 16 and IX at 18. But in the second listing, im_reg sits at 8, not at 16?
I have just been poking around the decoder chip with my 'scope and noticed that without the 10K pullup on pin4 (gate) it sags down to about 50% over 150uS and then gets pushed back up to VDD with the next burst of activity ( screen just flashing cursor at A> promt). Obviously the 10K puts all tis right but I still get "Spacebar" occationaly on a slow rising PSU, ie pluging it in, it seems better on the 9V being plugged into the pcb having the SMPSU already on, and always ok with a reset from the switch I fitted. Nothing important, as yet, but there might be a clue to a future problem, for somebody.
With my cut down version I suppose I could get rid of the decoder, with the four pins used there and the two spare from not using the second '232 port I could run CP/M, using the lines to the latches and ram directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Dr_A: Lets comment the first list with byte offset values of the regs like so:
register_file word
bc_reg word 0 '1, 0
de_reg word 0 '2, 3
hl_reg word 0 '4, 5
af_reg word 0 '6, 7
bc_reg_alt word 0 '8, 9
de_reg_alt word 0 '10, 11
hl_reg_alt word 0 '12, 13
af_reg_alt word 0 '14, 15
im_reg word 0 '16, 17
ix_reg word 0 '18, 19
iy_reg word 0 '20, 21
sp_reg word 0 '22, 23
pc_reg word 0 '24, 25
Now we see that the im_reg sits at offset 16 and as you say the 8 is wrong, well spotted. Of course this does no harm yet as we don't ever use IM.
So change "im_reg := reg_base + 8" to "im_reg := reg_base + 16" and then you can access IM with "rd/wrword data_16, im_reg".
Not that I remember what is in IM reg at this moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
From distant memory it just returns the interupt mode 2 vector ( there were 3 modes), which will be of no interest to a generic CP/M, I hope. The R reg is just a cyclic 0-255 refresh counter, so as Clusso says the bottom byte of CNT is the same. EX and EXX get propenant usage in the Nascom stuff, usually just as a quick version of PUSH ..... and POP .... ( I guess that is what they were always there for). Stuff with index was great for tables etc but used a lot of clocks up, so sometimes in delays just as a waste of time.
Then there were the block moves with compares... So many of the "useful instructions" were just a consequence of the expansion to the 8080 set causing duplcated space fillings, and if used it was just the software writer showing off, as was the "undocumented instructions" party that happened in the early 80's. These were used, not because they did anything paticarly useful, but just to confuse the issue ( and dis-assemblers).
So as we have now it is probably enough to have a WTF catch bucket, scanning through the software as it is launched. As the vast majority of professional coders, for CP/M, would have been 8080 based then I bet the number of missing bits will drop very quickly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The 10k pullup on '138 pin 4 seems to leave the system with no "gate" dropping, no latching and obviously no ram_rd or ram_wr. So either there is an earlier polling of the ram to see if it exists, which is failing, or the lack of a pullup at boot, was by fluke allowing the ram system to boot up ok. No ram access = "Spacebar ..."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The pullups are there for when the pins are tristated, which is done quite often in a number of parts of the code. Putting a scope on a tristate pin may not tell you much either - ? a nice 50 or 60hz waveform. So the pullups are needed.
Is the problem that it won't boot sometimes? But will reset with the button ok? If so, the answer might be to put some delays in the code eg right at the very beginning put a 1sec delay. Cluso had delays in his code which I think were there to give the terminal program time to start. I took them out but maybe a shorter delay is needed to let the power supply rails stabilise.
Thanks heater re IM. Maybe cluso and yourself can change your code as well? I'll post something when I get home from work.
Yes, the electolytic values on the power supply could be a factor - bigger=smoother but longer to stabilise so it could explain why it works on some boards and not others.
I'm still at work (just been out for lunch, Cluso, and bought a paper from your friend who runs the Aldinga newsagency). Am looking forward to getting home as I think I have all the bits ready to write an instruction. All the registers print out. IM and other reg locations sorted. An IDE that can quickly compile tiny Z80 assembly programs to test each instruction.
Comments
Ps. I know that vampires and werewolves have heightened sences but spotting that off of the pic, Wow !!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Which is just as well as he tends to take unusually large blood samples[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Next thing- I can send Toby a snapshot of the files as they were late 28th November and that has the pin settings correct for the board he has made and should boot the zicog. BUT - I don't want to post it here as it is out of date and someone might download it thinking it was a new version. I tried sending a PM to Toby but it won't allow attachments to a PM for some reason. So maybe Toby can PM me with an email addresss. HOWEVER I'm pulling another 15 hour shift at work tomorrow so I won't get a chance to send the file for another 25 hours.
OR I can post the last board to Toby tomorrow from work if you can PM me a postal address.
V3 does not change any pins around. It simply adds a header for I2C and adds a real time clock and moves some chips around on the board so the traces are shorter. So - no software changes there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The differences I have seen so far are the SD and the 1 of 8 decoder. I have more of thos so I will snip it off the rear of the board and rework it in, somehow.
That will be work to be done if there is a Drac_Blade_2. I have already been deaming of a smaller one, I enjoy the design and building more anyway.
ADDIT
The cct I used was *******\Propeller_v2Oct09\Propeller_v2.sch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/9/2009 2:16:53 PM GMT
I was gladened by this but my high hopes were dashed, when I sited Dr_Acula as the guilty party. They said "Go away, and stay there", I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Log on runs trough the disk A-H + R
loading SRAM
Read boot code from SD card and store at $FF00
Starting Z80 emulation
Passed, loading Zicog
Then I get either one line of
"Write to unimplimented I/O Port"
(or load of those lines )
Better though !!!!
Kbd wired up wrong, now it asks for a spacebar, but does nothing.
So a "Y" could be ventured ( how many foulups before the final "E"?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/9/2009 4:09:17 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
re heater "That's damn neat ironing Toby.Did you clean the blood off already?"
Blood? Blood? Did someone mention Blood?!
Dr Vern Acula
Managing Director
Transylvanian Red Cross Transfusion Service
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/9/2009 10:11:14 PM GMT
The ram usage for CP/M is just 64KB at present (V2.2) but I notice drive R. Is that a ramdrive that uses the remains of the 512KB? If it isn't then thats one latch less, or as I am not using both Serial ports, there is a pin or two going begging, there should be a cog too if the LED is taken out. I havent got any 4 row ones.
Thanks for the design and the help over the few problems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
So... you could use a smaller ram chip and lose the latch. Only thing there is that the smaller ram chips tend to be 5V only. But you could fix that by running the latches from 5V instead of 3V and adding 8x 1k resistors in the data lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
You have to tell us one important detail - What happened between the "press space bar" stage and the "YIPPEEEEEE" stage?
Or is this some version of ZiCog I have not seen that needs a space bar hit to start?
If you are happy with CP/M 2 with 64K then save the pins. We are planning to have banked switched CP/M 3 and MP/M running one day using 256K RAM. Cluso did have CP/M 3 running before we dropped the Altair style floppy support so we know it can be done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
CPM3 will run (it has been running) without enabling banking but requires Floppies. I am waiting in the wings for a HD only version, but I know there are more pressing things first. Then I will test the banking - you can see in the code there is some untested code already there.
I am also planning to run a write-through RamDisk for the remaining ram. Drac, it will not fail if the power is turned off, because if a change is done, it will automatically be written back to the SD card (that is what I call write-through). However, reads will come from ram and writes will check if the data has changed. Write-through will be able to be enabled/disabled. RamDisk will use the remaining SRAM. So, compiles with writethrough off should be especially fast
Off to collect my RamBlade parts from the PO
BTW I am almost certain now that I can get a 1-pin mono video and 1-pin PS2 Keyboard working, maybe with as few as 4 resistors. Remember, the Keyboard currently requires 4 resistors, but I think 3 will do and 1 for the video
"Blood? Blood? Did someone mention Blood?!" *faints on floor* (as bad as needles- phobia!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Cluso - write through sounds very interesting. I can see the logic there, especially given most drive activity is Read rather than Write. Eg when you change drives there is a delay while it loads things from the disk. I'll bet it is the same data each time and if this were buffered it would make things a lot quicker. How would you do the software for this? Would you somehow keep track of the drive # and the sector/track # and have a list of all these with pointers to where they are in ram and then have a rotating list of 128 byte blocks of data? I'll think about this more but it sounds quite intriguing and quite possible with not very much code. And it would be a very useful thing to do with the spare ram capacity.
Lots of exciting news there on the ramblade. Looking forward to seeing one soldered up.
Parts are arriving for the dracblade. Just got 20 ram chips and 20 vga sockets from Future Electronics (yay, no more desoldering sub D15s). SD card sockets shipped out today from Sparkfun. Switchers and other chips are on their way from Futurlec. A pile of 1 gig SD cards coming from Hong Kong. I'm thinking of a kit of parts with pretty much everything except the Propeller (as the prop chip/eeprom/xtal package is $25 here in Australia but a lot cheaper in the US). The suggestion made earlier to distribute from someone in the US makes a lot of sense eg Gadget Gangster. Or Briel Computers or anyone else who would be kind enough to do this.
Heater my email to you must have gone astray - can you PM me with your address so I can send you a board?
And a thought re Toby's board - this shows it is possible to build this with boards made at home. Maybe a few design tweaks (Eagle makes a pretty good effort of single sided autorouting if you make the board a bit bigger so it has room to move). Homebrew boards would be an attractive alternative. Toby, when you redid the board did you go for the v2 schematic ie the change to the 138 pins and the sd pins - if so then the software will be much easier. There were some slight software advantages to grouping the sd card pins as a group of 4 and changing the 138 addresses. Of course, as Toby found, parts of the design can be done in other ways - eg off board/protoboard/otherboard 5V and 3V supplies. Maybe lose the max232 for a different chip or the transistor circuit that is on the parallax demo schematic or even cluso's musings a while back about 0V/3V being (just) within RS232 spec and use a single resistor. The sd card can be standard, mini or micro. The A16-A19 latch can be left out and those 3 lines pulled high or low on the ram chip. The LCD latch is not needed if you don't want a 20x4 LCD. You don't have to use D9 plugs etc etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/10/2009 4:07:09 AM GMT
At work I have the wireless card from a HP printer, on it ther is the dinkies ram chip I have seen. I am sure that it is 64-128KB but has 0.4mm pitch. I will grab it later on, as I have to taxi a sound mixer around all day, TO LONDON - AAAAHHHHHGGGGGGGG!!!!!!!!!!
This chip will be much the same as the pitch scheduled for the PropII! Long live the D40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Drac: The RamDisk is just a small hard disk except it is initially read into ram. When a read is done, the driver delivers a block from ram. When a write is done, the block is checked to see if a change has taken place from ram. If so, it is copied to ram and a write to SD follows to write the new sector to SD. So, the SD is always in step with the ram.
However, there will be a switch to turn write-through off. This is because if you want to compile, you do not want to be writing to the sd card all the time, and it will be dramatically faster.
Drac: If you don't mind, what did your·1GB uSD cards·(and SD adapter?) inc shipping work out to be?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
My Sandisk uSD cards with adaptors were 6 for $AU48 including shipping so $8ea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/10/2009 11:02:34 AM GMT
The baby ram is a UT61L1024LS-12, 128KB 12nS. So not so big on mem but quick.
Dr_A····· I considered voodoo, but as you are one of the undead, it would be just a nusance phone call to you. Also, shouldn't your title be Chief Extraction Officer, not Managing Director ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The physical cct was bent to your new flavour, so hopefully it will be a bit more future proofed. It was quicker than ploughing back through all the software anyway. It only needed the sacrifice of the '138 and a scalpel (No 11) a few bits of new bridging wires and the reordered ram_wr was adjacent to the new pin already, one blob later I was at the "spacebar" bit. The KBD problem was me doing a mirror image of the CLK and DATA lines on the socket, yet I had the + and - the right way around (curse that apple juice!). Then there was the unfed feed through, that is where your board will alwasy be superior, definite conections from one side to the other and the copper pads are rivits, not just fragile islands. There is the great advantage of knowing the board design and the prat that made it, when it comes to the rebuild , on day two!
10000 loops of MBASIC was about 22 secs, so a bit slower than the Blade2, but that is to be expected with all the latchings. Still at 5MHz untill I get more used to where it could be pushed. I will have to play with the kbd layout to get it "English layout".
I tried WS, the first time it announced itself and then cleared the screen, now it just clears the screen. I dont know if this is the sign of more problems, or not, but I can live without it for now.
Addit- I tried 6, 6.55 and 7.3MHz rocks but only the 6MHz was stable. From distant memory, I recon the board is emulating about 3+ MHz. I tried the pullup on '138 pin 4 (gate) P9 but the board started to boot with occational "SpaceBars" etc, so it's now off and boots seem better. Hey-Ho.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 12/10/2009 11:30:08 PM GMT
Toby - are you game to start looking at adding an extra Z80 instruction or two?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The adding of extra instructions is one of my wishes, and so I will sit down and try to figure out the problems. Heater could do it but that would leave me gratefully freeloading, and ingnorant. So finger out !! The brain is not that far behind the eyes though. If I can suss out the adding of the extra bits ( vital for Nascom stuff ) then the original Z80 interest will be revived.
Accidently left the DracBlade on last night, it was just sat there patiently waiting, this morning, bless.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
However, the overclocking (and some propeller timing) is not available. This section must be tried and then a safety margin added. Of course, this then comes with a caveat that it may not work as designed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
First step I figure is some sort of printout of the registers. I copied the format from DDTZ which takes two lines to print out the registers and looks like this:
It is easy to change the spincode to print that out:
PRI print_regs 'Print the Z80 registers to vga display and to terminal program on the serial port RegString(string("AF =")) HexOutput(af_reg) RegString(string(" BC =")) HexOutput(bc_reg) RegString(string(" DE =")) HexOutput(de_reg) RegString(string(" HL =")) HexOutput(hl_reg) RegString(string(" SP =")) HexOutput(sp_reg) RegString(string(" PC =")) HexOutput(pc_reg) RegString(string(13,10)) ' new line for alternate register RegString(string("AF'=")) HexOutput(af_reg_alt) RegString(string(" BC'=")) HexOutput(bc_reg_alt) RegString(string(" DE'=")) HexOutput(de_reg_alt) RegString(string(" HL'=")) HexOutput(hl_reg_alt) RegString(string(" IX =")) HexOutput(ix_reg) RegString(string(" IY =")) HexOutput(iy_reg) RegString(string(13,10))And add these two pubs underneath so the debug code goes to both the terminal and to the vga display (having both is useful - the vga display if you can't be bothered waiting for windows to turn on and run a terminal program, but a terminal program is useful if you want to capture text and copy and paste it to the forum etc)
PUB HexOutput(HexValue)' send hex value to vga and to terminal UART.hex(0,HexValue, 4) vgatext.hex(HexValue,4) PUB RegString(RString) UART.str(0,Rstring) ' send to the serial port vgatext.str(Rstring) ' send to vga displayIn terms of priority opcodes, DDTZ lists a few at the beginning and these might even be in the right order:
; z80 opcodes used if Z80 cpu only exaf macro db 08h endm exx macro db 0d9h endm pushix macro db 0ddh,0e5h endm popix macro db 0ddh,0e1h endm pushiy macro db 0fdh,0e5h endm popiy macro db 0fdh,0e1h endmI note EXX does have a jump location but no code at that location.
PM from heater saying he is very busy. So if we can share this out a bit it will make things quicker. First thing (oops) is to ask the incredibly busy heater a question:
In the main program is a list of words that store the registers:
And in the zicog object is a list but it seems only partially complete:
PUB start(cpu_params) : okay | reg_base, io_base '' Start CPU simulator - starts a cog '' returns false if no cog available '' '' cpu_par_params is a pointer to CPU parameter list stop reg_base := LONG[noparse][[/noparse]cpu_params] c_reg := reg_base + 0 b_reg := reg_base + 1 e_reg := reg_base + 2 d_reg := reg_base + 3 l_reg := reg_base + 4 h_reg := reg_base + 5 f_reg := reg_base + 6 a_reg := reg_base + 7 im_reg := reg_base + 8 ix_reg := reg_base + 18 iy_reg := reg_base + 20 sp_reg := reg_base + 22 pc_reg := reg_base + 24I would presume these are in the same order and that the alternate registers sit somewhere between 8 and 18.
But the question is - where does the im_reg sit? In the first listing I'd be guessing that BC is at 0, DE at 2, HL at 4, AF at 6, BC' at 8, DE' at 10 HL' at 12, AF' at 14, IM at 16 and IX at 18. But in the second listing, im_reg sits at 8, not at 16?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/11/2009 11:53:24 AM GMT
I have just been poking around the decoder chip with my 'scope and noticed that without the 10K pullup on pin4 (gate) it sags down to about 50% over 150uS and then gets pushed back up to VDD with the next burst of activity ( screen just flashing cursor at A> promt). Obviously the 10K puts all tis right but I still get "Spacebar" occationaly on a slow rising PSU, ie pluging it in, it seems better on the 9V being plugged into the pcb having the SMPSU already on, and always ok with a reset from the switch I fitted. Nothing important, as yet, but there might be a clue to a future problem, for somebody.
With my cut down version I suppose I could get rid of the decoder, with the four pins used there and the two spare from not using the second '232 port I could run CP/M, using the lines to the latches and ram directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Now we see that the im_reg sits at offset 16 and as you say the 8 is wrong, well spotted. Of course this does no harm yet as we don't ever use IM.
So change "im_reg := reg_base + 8" to "im_reg := reg_base + 16" and then you can access IM with "rd/wrword data_16, im_reg".
Not that I remember what is in IM reg at this moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Then there were the block moves with compares... So many of the "useful instructions" were just a consequence of the expansion to the 8080 set causing duplcated space fillings, and if used it was just the software writer showing off, as was the "undocumented instructions" party that happened in the early 80's. These were used, not because they did anything paticarly useful, but just to confuse the issue ( and dis-assemblers).
So as we have now it is probably enough to have a WTF catch bucket, scanning through the software as it is launched. As the vast majority of professional coders, for CP/M, would have been 8080 based then I bet the number of missing bits will drop very quickly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Is the problem that it won't boot sometimes? But will reset with the button ok? If so, the answer might be to put some delays in the code eg right at the very beginning put a 1sec delay. Cluso had delays in his code which I think were there to give the terminal program time to start. I took them out but maybe a shorter delay is needed to let the power supply rails stabilise.
Thanks heater re IM. Maybe cluso and yourself can change your code as well? I'll post something when I get home from work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Drac: I will just wait and take your fixed version. Busy testing RamBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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'm still at work (just been out for lunch, Cluso, and bought a paper from your friend who runs the Aldinga newsagency). Am looking forward to getting home as I think I have all the bits ready to write an instruction. All the registers print out. IM and other reg locations sorted. An IDE that can quickly compile tiny Z80 assembly programs to test each instruction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller