Heater, Cluso, thanks for your responses and interest. I have been following the ZiCog and 3 blade prop threads with the idea of building a simple replacement for this board that can use the code already in eprom. The TwinBladeProp looks to be an even better fit for this.
The first problem is that I have a very old very crowded set of blueprint schematics for an earlier rev of this board, and they are in poor shape. I used Paint to copy what was legible, inspected a board to find some more, and guess at what was left. While some details may be wrong I have enough to know the memory and I/O layout and write some basic diagnostics.
Now to describe the memory and I/O layout a bit better.
The regular memory consists of 56KB of 2732 eprom from 0000-DFFF. The 8KB above that consists of 8KB (16 2114 chips 1Kx4 each) addressed as two 2K blocks at address E800-EFFF and one 4K block at address F000-FFFF. The two 2KB blocks at E800-EFFF are selected by writing a 0 or 1 to a flip flop at I/O address 7C-7F. No idea why the entire block of 8KB is not addressed as a single block from E000-FFFF.
The I/O ram is 14KB addressed as 56 blocks of 256 bytes using the block I/O instructions and 56 I/O port adresses to read and write the data. As heater pointed out the port address comes out on the lower (A0-A7) 8 bits of the address bus, and the byte count comes out on the high 8 bits. This has the effect of scattering the data throughout the entire 64K address space unless address bit wiring or decoding is done to compensate. Easy to do on the prop, not quite so easy to do with the Z80, eeproms, and ram chips if you want to keep the chip count and complexity down.
Since this board only uses 2 serial port connections to the outside world what I would like to do is use the TwinBladeProp and ZiCog to run the existing code.
Heater, Cluso, if you want any more information I can PM the schematics and eprom code to you
The only reason commertial kit doesn't have wires is because you didn't see the first ten variasions. Also they have the luxury of just diving into another layer, the opinion we all make of the final product is based on the outer 1/10000" that the light bounces off
Wow Toby... I have never done 10 variations of anything and have sold 100,000's of some products. Nothing like checking your design parameters first. As I said above, most of my products sold use the first version of the pcb and I almost always call it Rev A. I have not always laid out the pcbs, but I always check the layout.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
kwinn: That is one weird old board you have there.
Perhaps that 8K can just be addressed in a regular fashion and the flip-flop ignored. Unless there is something weird going on in the code that will overwrite something if the flip-flop is not set correctly.
It should not matter that bytes are splattered all over that 64K RAM in I/O space in a strange order. They will be written and read from the same "wrong" physical location but so what.
Mapping that I/O RAM will eat some execution time and I hope there is space to fit the code to do it. ZiCog is very tight now. Perhaps some Z80 instructions are unused and can be dumped to make room.
Does this thing have any performance requirements? Will ZiCog be fast enough?.
Better not to send any schematics just now I'm kind of busy. Perhaps later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sems You have old CPM PCB.
One of 4 KBytes blok after You switch with Flip Flop Remaps to address 0000H and that 14KBytes should ware maped to addresses after them KBytes addressed from 0000H.
You could replaced al 2732 eproms with same capacity SRAMs (only ading /WR to them) only Eprom at addressed as 0000H You cant replace.
In 0000H eprom You wil have start upp program that loads SRAM that remaps to 0000H and last SRAM with startup BIOS and then swith Eprom to SRAM and You have Fine CPM system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I suppose you are right, the vast mijority of modern stuff out there is V1 or v2 as you say, they cannot risk delaying an idea for fear of the fad passing or the idea being hijacked.
People have been very patient with the early, rough versions of a widly used product, and then seem willing to pay for the "Corrections"
I like the idea of the lazer cut boxes. So much neater than a shotgun(which does cut down on the drilling)
Heater, you are right, it is a weird old board, but they have been very reliable over the last 25 years or so. The only reason I want to do this is that some of the chips are getting very difficult to source reliably. It is a 15” x 10” board with 44 ram chips, up to 16 eproms, 2 UARTS, A Z80, and 55 glue chips. And I hope to replace it with Cluso’s TwinBladeProp and maybe a couple of additional chips. Do I sound like an optimist?
Like you I am hoping the 8K of ram can be addressed in regular fashion and the flip flop ignored, but I have a feeling the software may not permit that. That’s the beauty of the prop, I can add the flip flop function to the software if it is needed.
As you said, the fact that the block I/O ram addressing scatters the data all over the 64K address space does not make any difference as long as that 64K block is used exclusively for the I/O ram.
What I am thinking now is that one 64K block is used for the 56K of firmware that is now in eprom and the 8K left over is used as the 8K of ram that is addressed as normal memory at E000-EFFF. If the bank switching FF is needed the address translation can be done by the prop.
The block I/O read/writes can be done to a second 64K block of ram with no additional address translation except the high order address bits to select the block.
The instrument uses two of these boards, and they are identical except for the firmware. One board ( board 1 ) controls the instrument (front panel display, key pad, thresholds, scaler chips, etc) and sends the data to the second board ( board 2, the one I am trying to replace ) for processing via a serial connection. The processed data is sent back to board 1 where it is then sent out of a second serial connection to a printer or PC. The serial connections are full duplex RS232 at 1200 baud. As far as I can determine the I/O ram is used to buffer this data exchange if board 2 or the printer can’t keep up.
I think ZiCog will be fast enough. Most of the time will be spent executing regular code with only occasional address translation required. The I/O ram access may even be faster on the prop since the address setup is done once and then 256 bytes can be transferred sequentially. For a block I/O instruction we could reverse the order of the address in the B and C register and put the resulting address in a word so that the loop would be only read, increment source, write, increment destination. That would also “unsplatter” the data in memory.
Sapieha, it is not an old CPM board although I am pretty sure it was based on the design of the old S100 CPM systems, and the software was probably written and compiled on a CPM system. I am familiar with the S100/CPM trick of having a flip flop place the eprom at 0000 on power up and then placing it as the top block of memory as soon as bit 15 goes high, and this is not what happens on this board. The memory at this location is 8K of ram, but it is addressed as one block of 4K at F000-FFFF and 2 blocks of 2K at E800-EFFF. The flip flop determines which of the 2 blocks appears at E800-EFFF, and the other block is 'invisible'. I have no idea why this 4K block is split up, why it does not occupy the entire block from E000-EFFF, or if that area of E000-E7FF is used for something. It may be a result of the board having jumpers to allow the use of 2716 eproms.
PS If you are curious I can pm the schematics of the address decoding and memory to you.
Kwinn: I have to read you descriptions carefully again. I think Sapieha is on to something. Perhaps it does not have CP/M on board but it may use similar techniques.
Thing is CP/M, for example, requires that there is RAM starting at 0000. It keeps some housekeeping variables from 0000 to 00FF. Programs get loaded at 0100. CP/M itself lives in the high end of RAM.
BUT The Z80 requires there to be ROM at 0000 because that's where it starts execution after reset.
So it looks like that flip flop is crucial. After reset ROM is mapped at 0000 upwards. The Z80 starts at 0000 and runs some boot code from ROM. Perhaps it is using those I/O ports to copy code from the ROMS into the RAMS. When everything is in place it can toggle the flip-flop after which those ROMS are out of the MAP replaced by the RAMS. From then on the code runs from the RAM which is now mapped into normal memory space.
For all this to work it probably uses the fixed block of RAM at the high end from where it can do the "bank switch". This is what CP/M does when using banked memory.
If this is the case then actually the writes to RAM using I/O instructions cannot splatter data around because that data is actually code that must be in the right place after that flip flop is toggled!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater, looks like they did cross in the ether. I double checked my schematics anyway and I am almost 100% sure that the flip flop only enables one or the other 2K blocks of ram at E800. Always possible I missed something between the poor condition and crowding of the old schematics, but I am 99.99% sure. Have to log off for a while and go earn a living. Drat!
There will be a TwinBladeProp Blade #2 section only pcb which will be 25mmx50mm (1 said...
1.96") due at the same time."
If this is still true, let me change my order for two (2) of those boards.
I have many Prototype boards already, and two of the MonoBlades are all I need.
Thanks again...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (James Michael Huselton) : 5/11/2009 6:35:52 PM GMT
32 bit? This is because I was remembering the experiments at Parallax obtaining unholy speeds. I recall these were measured in Baud, so I assume you are measuring 1 long = 4 baud.
I suspect he meant 1 MegaByte per second since he used an upper case B. Bits per second is usually indicated with a lower case b. The term baud is now used interchangeably with bits per second, but here is what Wikipedia has to say.
Relationship to gross bitrate
The term baud rate has sometimes incorrectly been used to mean bit rate, since these rates are the same in old modems as well as in the simplest digital communication links using only one bit per symbol, such that binary "0" is represented by one symbol, and binary "1" by another symbol. In more advanced modems and data transmission techniques, a symbol may have more than two states, so it may represent more than one binary bit (a binary bit always represents exactly two states). For this reason, the baud rate value will often be lower than the gross bit rate.
Example of use and misuse of "baud rate": It is correct to write "the baud rate of my COM port is 9,600" if we mean that the bit rate is 9,600 bit/s, since there is one bit per symbol in this case. It is not correct to write "the baud rate of Ethernet is 100 Mbaud" or "the baud rate of my modem is 56,000" if we mean bit rate. See below for more details on these techniques. The difference between baud (or signalling rate) and the data rate (or bit rate) is like a man using a single semaphore flag who can move his arm to a new position once each second, so his signalling rate (baud) is one symbol per second. The flag can be held in one of eight distinct positions: Straight up, 45° left, 90° left, 135° left, straight down (which is the rest state, where he is sending no signal), 135° right, 90° right, and 45° right. Each signal carries three bits of information. It takes three binary digits to encode eight states. The data rate is three bits per second. In the Navy, more than one flag pattern and arm can be used at once, so the combinations of these produce many symbols, each conveying several bits, a higher data rate.
If N bits are conveyed per symbol, and the gross bit rate is R, inclusive of channel coding overhead, the symbol rate can be calculated as:
kwinn: I believe that we can emulate your board in software. I don't have time at present for obvious reasons, but can have a look at the schematic later if you like. Send to cluso@bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The serial transfers are synchronous because of the shared Propeller crystal and do not require start/stop bits for every byte. If I remember correctly, the raw uninterpreted data transfer rate was up to 14 million bits per second. 1MB/s is just a nice and friendly round number.
Cluso99 said...
[*]Obviously this project has been inspired by the brilliant work done by heater in getting ZiCog to run on the prop. There are·many others also. [*]It has been and remains my ambition to get the prop running it's own proper operating system which includes all the development tools. We are now very close to that being a reality. We now have
PropDos/PropCmd
FAT16 SD cards (up to 2GB)
PrEditor (well underway??)
FemtoBasic
Forth??
Thanks for the nudge...PrEditor is definitely "well underway" and is almost done. I took two steps back implementing mouse functionality before completion. I consider it a great·complement to be listed among the other titles that would allow a·"Prop Only" environment. · I was very close to ordering a Tri-Blade...but I think that’s too easy for this crew. I think the twinblade is more of a fair challenge.
From the block diagram i t looks like there is 4 bits of data bus that are connected between prop1 and prop2 and the memory chip. Is that so Cluso99?
If that is the case and the memory was read in from the memory chip to prop2, prop 1 could "see" the upper 4 bits. The only thing left to transfer would be the lower 4 bits, so through the high speed serial, you could just go back and fill in the holes, effectively doubling your throughput.
Also, if that is the case, and those 4 lines connect to p28, p29, p30, and p31, there is no reason that prop2 couldn't boot from prop1.
Sorry guys - real life things have caught up that need to be done. That's why I have not been around much. I am not sure when I can get back to it (days/weeks). The RamBlade is almost complete, but the TwinBlade has block sections complete, but the extras need to be squeezed in. They will be on the one panel to reduce costs.
If there was enough interest then I could probably get the RamBlade out to manufacture but the tooling costs push the pcb price up considerably.
This design is for speed. The RamBlade (#2) can, and is intended to be (if connected) loaded from Blade #1 (or Prop Proto Board or whatever), to perform initial booting to the SD card.
Connection between Blades is 2 wire because otherwise the memory speed is compomised.
re Paul's design (BTW I hadn't seen it) - I address 512KB contiguously, have a microSD card, and is much faster in memory access.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I like your use of pins(some of which I am assuming) to make for less shifts & such, but I think the two approaches are essential the same.
It looks like you have the performance pretty good on the RamBlade, but what is the full cycle time going to be from Blade #1 to RamBlade and back?.
Another question, who uses the "aural subcarrier" of the video output? If it is not used, it could be freed up for more bandwidth between blades. Since it is by itself, it would make a good reset control line..
@hinv: From your comments I think you may have missunderstood the concept. The RamBlade is a self-contained processor (with 512KB SRAM and microSD) that uses another processor (prop Blade #1, Prop Proto Board, or somthing else) as a terminal to the RamBlade. So, the RamBlade would run PropDos, ZiCog or something else and use the "other" processor as an intelligent set of peripherals, such as keyboard, vga, TV, etc.
All comms is over 2 wire ultra high speed serial to another prop or terminal. If it is a Blade #1, or Prop Proto Board, etc, then this comms can be 1+MBps. There are no other pins spare on the RamBlade and the interface to the RAM has been speed/instruction optimised.
I expect that only a few cogs will be utilised on the RamBlade. Although heater 'proved' that more cogs did not improve performance on ZiCog, their may still be ways to improve the performance in some ways.
On Blade #2 of the TriBlade board (equivalent to the RamBlade), 1 cog does the ZiCog emulator, one does the high level ZiCog interface in spin, one does the high level spin and one does the low level pasm access to the microSD, one does the FullDuplexSerial interface spin and one the pasm. But this is currently inefficient and the high level spin code could be combined, and some could be done in pasm to improve performance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
You are right, I thought that ZiCog would be running on blade1, but your concept is to run the memory heavy stuff on RamBlade, and that is why you wanted the microSD attached to it as well.
Clusso: "heater 'proved' that more cogs did not improve performance on ZiCog"
You are right to put 'proved' in quotes there.
My conclusions were that
1) I could not get significant Z80 performance gains from multiple COGs. In fact the whole thing was slower than the current single COG effort. But, as I said at the time, perhaps my implementation was not optimal.
2) It did not look like any performance gains were worth sacrificing so many COGs and HUB RAM (For the dispatch tables).
However now with the Blade #2 we have a bunch of COGs free which are not so easy to use for anything as all the pins are used up. And a lot of free HUB space. So perhaps the multi-COG approach could be revisited.
What I'm thinking is that using multiple COGS for emulation combined with the current "micro-op" emulation architecture may yet show some speed ups. That is, we now have a lot of ops emulated through the use of overlays, especially the string move instructions and block I/O instructions. These could well be moved from overlays into another COG/COGS. The overheads of transferring control to another COG are offset by the fact that these instruction contain loops.
Personally I'm not up for doing this. Most of those instructions are not used very much. If anyone wants to take the reigns on that feel free. I'd like to use what little free time I have to get on with the Motoroal 6809 emulation[noparse]:)[/noparse]
Or perhaps the free COGS will find use speeding up some of the peripheral emulation that is currently written in SPIN on one COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater:
Yes, I am sure we can squeeze some more speed out of ZiCog. BUT, it works now and that is the main purpose. Anything else is cream
I agree it is better to get another emulator up and running. Next 6502 and Apple ][noparse][[/noparse] ??? Was the Commodore 64 based on 6502??
Moving the spin peripheral code to pasm could help the most. I intended the TriBlade driver to be able to do block moves. A few of the overlays may be good to place in a couple of cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Potatohead and co. are working on a 6502 emulator over on the Hydra forum. http://forums.parallax.com/showthread.php?p=767703
Seems they have switched from the multiple COG to to the Cluso micro-op method as well. They have been a bit quite about it for some time now.
I have most of the code in place for a 6809 emulator but it's nowhere near running yet. Plan is to get Dave Dunfield's CUBIX OS running www.dunfield.com/dave/d6809.htm after that perhaps FLEX, SK*DOS, OMU (One Man Unix).
Interesting thing about CUBIX is that Dave has a 8085 emulator for it. So the challenge is to get 8080 code running under emulation in the 6809 emulator on the COG...Call me crazy again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The first problem is that I have a very old very crowded set of blueprint schematics for an earlier rev of this board, and they are in poor shape. I used Paint to copy what was legible, inspected a board to find some more, and guess at what was left. While some details may be wrong I have enough to know the memory and I/O layout and write some basic diagnostics.
Now to describe the memory and I/O layout a bit better.
The regular memory consists of 56KB of 2732 eprom from 0000-DFFF. The 8KB above that consists of 8KB (16 2114 chips 1Kx4 each) addressed as two 2K blocks at address E800-EFFF and one 4K block at address F000-FFFF. The two 2KB blocks at E800-EFFF are selected by writing a 0 or 1 to a flip flop at I/O address 7C-7F. No idea why the entire block of 8KB is not addressed as a single block from E000-FFFF.
The I/O ram is 14KB addressed as 56 blocks of 256 bytes using the block I/O instructions and 56 I/O port adresses to read and write the data. As heater pointed out the port address comes out on the lower (A0-A7) 8 bits of the address bus, and the byte count comes out on the high 8 bits. This has the effect of scattering the data throughout the entire 64K address space unless address bit wiring or decoding is done to compensate. Easy to do on the prop, not quite so easy to do with the Z80, eeproms, and ram chips if you want to keep the chip count and complexity down.
Since this board only uses 2 serial port connections to the outside world what I would like to do is use the TwinBladeProp and ZiCog to run the existing code.
Heater, Cluso, if you want any more information I can PM the schematics and eprom code to you
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Perhaps that 8K can just be addressed in a regular fashion and the flip-flop ignored. Unless there is something weird going on in the code that will overwrite something if the flip-flop is not set correctly.
It should not matter that bytes are splattered all over that 64K RAM in I/O space in a strange order. They will be written and read from the same "wrong" physical location but so what.
Mapping that I/O RAM will eat some execution time and I hope there is space to fit the code to do it. ZiCog is very tight now. Perhaps some Z80 instructions are unused and can be dumped to make room.
Does this thing have any performance requirements? Will ZiCog be fast enough?.
Better not to send any schematics just now I'm kind of busy. Perhaps later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There will be a TwinBladeProp "Blade·#2 section only" pcb which will be 25mmx50mm (1"x1.96") due at the same time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 5/11/2009 8:27:08 AM GMT
Sems You have old CPM PCB.
One of 4 KBytes blok after You switch with Flip Flop Remaps to address 0000H and that 14KBytes should ware maped to addresses after them KBytes addressed from 0000H.
You could replaced al 2732 eproms with same capacity SRAMs (only ading /WR to them) only Eprom at addressed as 0000H You cant replace.
In 0000H eprom You wil have start upp program that loads SRAM that remaps to 0000H and last SRAM with startup BIOS and then swith Eprom to SRAM and You have Fine CPM system.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I suppose you are right, the vast mijority of modern stuff out there is V1 or v2 as you say, they cannot risk delaying an idea for fear of the fad passing or the idea being hijacked.
People have been very patient with the early, rough versions of a widly used product, and then seem willing to pay for the "Corrections"
I like the idea of the lazer cut boxes. So much neater than a shotgun(which does cut down on the drilling)
Like you I am hoping the 8K of ram can be addressed in regular fashion and the flip flop ignored, but I have a feeling the software may not permit that. That’s the beauty of the prop, I can add the flip flop function to the software if it is needed.
As you said, the fact that the block I/O ram addressing scatters the data all over the 64K address space does not make any difference as long as that 64K block is used exclusively for the I/O ram.
What I am thinking now is that one 64K block is used for the 56K of firmware that is now in eprom and the 8K left over is used as the 8K of ram that is addressed as normal memory at E000-EFFF. If the bank switching FF is needed the address translation can be done by the prop.
The block I/O read/writes can be done to a second 64K block of ram with no additional address translation except the high order address bits to select the block.
The instrument uses two of these boards, and they are identical except for the firmware. One board ( board 1 ) controls the instrument (front panel display, key pad, thresholds, scaler chips, etc) and sends the data to the second board ( board 2, the one I am trying to replace ) for processing via a serial connection. The processed data is sent back to board 1 where it is then sent out of a second serial connection to a printer or PC. The serial connections are full duplex RS232 at 1200 baud. As far as I can determine the I/O ram is used to buffer this data exchange if board 2 or the printer can’t keep up.
I think ZiCog will be fast enough. Most of the time will be spent executing regular code with only occasional address translation required. The I/O ram access may even be faster on the prop since the address setup is done once and then 256 bytes can be transferred sequentially. For a block I/O instruction we could reverse the order of the address in the B and C register and put the resulting address in a word so that the loop would be only read, increment source, write, increment destination. That would also “unsplatter” the data in memory.
PS If you are curious I can pm the schematics of the address decoding and memory to you.
Thing is CP/M, for example, requires that there is RAM starting at 0000. It keeps some housekeeping variables from 0000 to 00FF. Programs get loaded at 0100. CP/M itself lives in the high end of RAM.
BUT The Z80 requires there to be ROM at 0000 because that's where it starts execution after reset.
So it looks like that flip flop is crucial. After reset ROM is mapped at 0000 upwards. The Z80 starts at 0000 and runs some boot code from ROM. Perhaps it is using those I/O ports to copy code from the ROMS into the RAMS. When everything is in place it can toggle the flip-flop after which those ROMS are out of the MAP replaced by the RAMS. From then on the code runs from the RAM which is now mapped into normal memory space.
For all this to work it probably uses the fixed block of RAM at the high end from where it can do the "bank switch". This is what CP/M does when using banked memory.
If this is the case then actually the writes to RAM using I/O instructions cannot splatter data around because that data is actually code that must be in the right place after that flip flop is toggled!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Relationship to gross bitrate
The term baud rate has sometimes incorrectly been used to mean bit rate, since these rates are the same in old modems as well as in the simplest digital communication links using only one bit per symbol, such that binary "0" is represented by one symbol, and binary "1" by another symbol. In more advanced modems and data transmission techniques, a symbol may have more than two states, so it may represent more than one binary bit (a binary bit always represents exactly two states). For this reason, the baud rate value will often be lower than the gross bit rate.
Example of use and misuse of "baud rate": It is correct to write "the baud rate of my COM port is 9,600" if we mean that the bit rate is 9,600 bit/s, since there is one bit per symbol in this case. It is not correct to write "the baud rate of Ethernet is 100 Mbaud" or "the baud rate of my modem is 56,000" if we mean bit rate. See below for more details on these techniques. The difference between baud (or signalling rate) and the data rate (or bit rate) is like a man using a single semaphore flag who can move his arm to a new position once each second, so his signalling rate (baud) is one symbol per second. The flag can be held in one of eight distinct positions: Straight up, 45° left, 90° left, 135° left, straight down (which is the rest state, where he is sending no signal), 135° right, 90° right, and 45° right. Each signal carries three bits of information. It takes three binary digits to encode eight states. The data rate is three bits per second. In the Navy, more than one flag pattern and arm can be used at once, so the combinations of these produce many symbols, each conveying several bits, a higher data rate.
If N bits are conveyed per symbol, and the gross bit rate is R, inclusive of channel coding overhead, the symbol rate can be calculated as:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
·
I was very close to ordering a Tri-Blade...but I think that’s too easy for this crew. I think the twinblade is more of a fair challenge.
Thanks for upping the ante
Rick
·
If that is the case and the memory was read in from the memory chip to prop2, prop 1 could "see" the upper 4 bits. The only thing left to transfer would be the lower 4 bits, so through the high speed serial, you could just go back and fill in the holes, effectively doubling your throughput.
Also, if that is the case, and those 4 lines connect to p28, p29, p30, and p31, there is no reason that prop2 couldn't boot from prop1.
Am I missing something here?
What is the status of your board?
http://forums.parallax.com/forums/attach.aspx?a=10636
Thanks,
Doug
If there was enough interest then I could probably get the RamBlade out to manufacture but the tooling costs push the pcb price up considerably.
This design is for speed. The RamBlade (#2) can, and is intended to be (if connected) loaded from Blade #1 (or Prop Proto Board or whatever), to perform initial booting to the SD card.
Connection between Blades is 2 wire because otherwise the memory speed is compomised.
re Paul's design (BTW I hadn't seen it) - I address 512KB contiguously, have a microSD card, and is much faster in memory access.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
http://forums.parallax.com/forums/default.aspx?f=25&m=158040
I like your use of pins(some of which I am assuming) to make for less shifts & such, but I think the two approaches are essential the same.
It looks like you have the performance pretty good on the RamBlade, but what is the full cycle time going to be from Blade #1 to RamBlade and back?.
Another question, who uses the "aural subcarrier" of the video output? If it is not used, it could be freed up for more bandwidth between blades. Since it is by itself, it would make a good reset control line..
All comms is over 2 wire ultra high speed serial to another prop or terminal. If it is a Blade #1, or Prop Proto Board, etc, then this comms can be 1+MBps. There are no other pins spare on the RamBlade and the interface to the RAM has been speed/instruction optimised.
I expect that only a few cogs will be utilised on the RamBlade. Although heater 'proved' that more cogs did not improve performance on ZiCog, their may still be ways to improve the performance in some ways.
On Blade #2 of the TriBlade board (equivalent to the RamBlade), 1 cog does the ZiCog emulator, one does the high level ZiCog interface in spin, one does the high level spin and one does the low level pasm access to the microSD, one does the FullDuplexSerial interface spin and one the pasm. But this is currently inefficient and the high level spin code could be combined, and some could be done in pasm to improve performance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I think I get it now.
Thanks,
Doug
You are right to put 'proved' in quotes there.
My conclusions were that
1) I could not get significant Z80 performance gains from multiple COGs. In fact the whole thing was slower than the current single COG effort. But, as I said at the time, perhaps my implementation was not optimal.
2) It did not look like any performance gains were worth sacrificing so many COGs and HUB RAM (For the dispatch tables).
However now with the Blade #2 we have a bunch of COGs free which are not so easy to use for anything as all the pins are used up. And a lot of free HUB space. So perhaps the multi-COG approach could be revisited.
What I'm thinking is that using multiple COGS for emulation combined with the current "micro-op" emulation architecture may yet show some speed ups. That is, we now have a lot of ops emulated through the use of overlays, especially the string move instructions and block I/O instructions. These could well be moved from overlays into another COG/COGS. The overheads of transferring control to another COG are offset by the fact that these instruction contain loops.
Personally I'm not up for doing this. Most of those instructions are not used very much. If anyone wants to take the reigns on that feel free. I'd like to use what little free time I have to get on with the Motoroal 6809 emulation[noparse]:)[/noparse]
Or perhaps the free COGS will find use speeding up some of the peripheral emulation that is currently written in SPIN on one COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I am sure we can squeeze some more speed out of ZiCog. BUT, it works now and that is the main purpose. Anything else is cream
I agree it is better to get another emulator up and running. Next 6502 and Apple ][noparse][[/noparse] ??? Was the Commodore 64 based on 6502??
Moving the spin peripheral code to pasm could help the most. I intended the TriBlade driver to be able to do block moves. A few of the overlays may be good to place in a couple of cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Seems they have switched from the multiple COG to to the Cluso micro-op method as well. They have been a bit quite about it for some time now.
I have most of the code in place for a 6809 emulator but it's nowhere near running yet. Plan is to get Dave Dunfield's CUBIX OS running www.dunfield.com/dave/d6809.htm after that perhaps FLEX, SK*DOS, OMU (One Man Unix).
Interesting thing about CUBIX is that Dave has a 8085 emulator for it. So the challenge is to get 8080 code running under emulation in the 6809 emulator on the COG...Call me crazy again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.