BrainDamage!!! Is that Leor "BrainDamage" Zolman. If so I am honoured that you should turn up here on this thread.
I always assumed BDS C restricted itself to 8080 instructions. Those simple tests I have done with it on the Prop emulation work just fine. But they do not use such things as memcmp or strcpy. For sure I want to get all the flags right in ZiCog so that this works as you say.
I'm just itching to get BDS C hosted on the Propeller itself. We are just days away now, what with Clusos TriBlade board coming soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater:
No, I don't want, nor expect locks. The word access is not going to happen because then you have to cater for both byte and word and code that. Also, you have to have 16bit wide memory and the extra 8 pins or else you resort to a latch which defeats the speed. But I will code for word access - once OUTA has the address in the correct bits, then after the read we just increment the OUTA address and read the next byte (and increment the register holding the original address if required) - easy. And yes, the DIRA will always be left in the same state (which is for read). With the word reads, you can see how easy it will be to do string reads/writes (be it for Disk emulation or string moves) - I am talking RAM emulation here, not microSD or Flash as that will be seperate.
Rokicki:
What we are proposing to do for access will also work on any emulation, including the 6809. I have a real soft spot for Motorola cpus - used 100,000's of 68705's. Never did anything on the 6809 though. I suggest you continue the 6809 work. Maybe another thread as those not interested in the Z80 may not read this thread and you might find others willing to help there as well. Sorry, I just cannot afford to get distracted yet.
Don't worry about code size at this point. Just get each instruction working using the vector table concept and overlay when you need to (even if this means every instruction loads an overlay, that doesn't matter yet). Once running this can all be sorted, and you will realise where common code can be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
No, no I'm not expecting 16bit access physically just something to replace the [noparse][[/noparse]read,write]_memory_word routines that does the fastest thing possible without making calls on [noparse][[/noparse]read,write]_memory_byte as they do now. I think what you are describing is just the ticket.
Don't care what DIRA is doing. Thing is one COG should not be driving addresses/controls high when a another COG may need access after all the COG outputs are ORed together on their way to the actual pins. Perhaps DIRA will need setting to input to achieve this, I don't know.
Just thinking about IO. We should make it possible for Z80 code to get direct access to Propeller hardware: pins, counters etc. Just need to map some Z80 IO space into COG special purpose registers. Although I'd be surprised if we can generate video from 8080 code[noparse]:)[/noparse]
Really crazy to would be to enable the 8080 code to start COGs with code read from the SD card file system!
A 6809 thread is a great idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Great, word access will be fine then and you are right, this will be faster.
DIRA from multiple cogs: Not a problem. There are different ways this can be done, but in this case it will be best for the cog to make the DIRA all inputs before it releases control. That way we don't have to set OUTA before we release control, and no handshaking or locks will be needed if multiple cogs wont be accessing the ram simulataneously. We can use a different cog to do the ram disk access which means it can be resident code in the cog. Then just pass the disk sector address to the cog via hub and the cog can read the data - or maybe it may be just as quick to use the one cog, just like you found in splitting up the instructions - will have to see, but that can come later.
IO: We do not have any i/o pins available - only 2 serial pins for comms to another prop - so keep that in mind. So, the video and any i/o will be on a seperate prop(s). This will use a Terminal emulator like VT100 on another prop - there was one posted on another thread (I think by OBC).
Likewise, the SDcard file system has been posted on another thread I think - it may require modifying but I am sure it's there when required.
A cog could be started with code from the sd card but its a little more complex than that. However, the same applies as the i/o system - likely to be on another prop.
I have taken all this into account for the TriBladeProp. We can start out with 2 Blades and progress to 3 if we need more i/o or the vga system needs ram. A lot of the design options are still in my head. The schematic shows all the options but doesnt really explain how I intend to use them, and how to expand their use from a minimal system to a more complex one. Most of the links are already on the pcb. We can use pin headers with links(shunts) or hardwire the links with wire. It will be easier to explain with photos (or videos) of the pcb, in conjunction with the schematic I published. I'll create a thread to ask how people do videos easily - isn't this forum just great
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have just been looking at your v0.1 code. Since we will have·a full 64KB ram/rom space, the read_memory_byte·routine will no longer have to check the ram_size. This will improve performance quite a bit, particularly the rom access,·as well as saving some code space.
The read_memory_word routine will now be easy to place inline, also improving performance.
Not that the above will have a great impact on overall performance as it is only a small part of the code executed for each emulated instruction, but is common to every instruction. Every bit will help. The call #read_memory_byte can then be inline coded which will improve again, but uses a couple of extra longs.
There are probably places to improve performance where the 2nd & 3rd vectors could be inline coded for an extra long which will improve a bit more.
As I said, every bit will help. :-)
Your use of the PC_Keyboard and PC_Text will be great to make it easy to have the "Terminal" on another prop (Blade) :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yep, that's exactly what I had in mind re: the memory access routines. I'm sure we will get a little more oomph out of this.
I have already been through the vectors pruning out some redundant steps, perhaps there are more possibilities there but it can wait a bit.
Just now I was wondering how to make a CP/M package out of this. Given that you are going to be the one with TriBlades and RAM up and running first I though I'd try and make something that you can just drop in and modify the access functions.
I'm thinking to replace the PropAltair cpu with ZiCog and get it running as a 16K CP/M system in HUB RAM as usual. There is not enough room for the old 24K system with ZiCog. You would then have to: 1) Modify the RAM access functions. 2) Add some code to copy the CP/M and BIOS files from HUB out to ext RAM on start up. This is quick and dirty to see it run but we really want a 64K system.
So, second step, replace the CP/M files with ones built for 64K, change the copy code to put them in the right place in ext RAM. That's it, should run.
Note that this does not rely on the EPROM bootloader code or files on SD card to get us up to the CP/M prompt which makes life much easier for testing.
A more grandiose plan is to use FAT on the SD card and keep CP/M disks in files there. Ariba has already shown how to do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is the modified sections with some questions for the read memory sections :-)
The write is a little more complex so I am still looking at this.
I agree, the simplest will be to copy the rom code to the sram and run from the·64KB SRAM. Initially I will use the PC_Keyboard and PC_Text via the PropPlug (external one first). I will have to get PropTerminal working - currently use PST, but no problems there anyway.
And yes the SD can come later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
ClusoRead looks like like it's going to be quite snappy.
At first glance I would suggest not storing the PC shifted by 8. There are a lot of places that use pc which would then have to be fixed up. At least in a first version it would be better not to have so many changes to make.
Unless I have done something wrong "address" is a throw away parameter for [noparse][[/noparse]read,write]_memory_[noparse][[/noparse]byte,word] except that [noparse][[/noparse]read,write]_memory_word expects it to be incremented by [noparse][[/noparse]read,write]_memory_byte. If you see what I mean.So I don't expect any problem there.
What is going on with read_memory_word? "data_8" gets shifted by 24 but is otherwise unused. "data_8" is not a required output of read_memory_word.
Not sure now but it's probably better if data_8 is not corrupted here either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Don't we have a problem here with sharing RAM between COGs.
The RAM is selected when CE is low and more dangerous write is enabled when WE is low.
So when changing from COG to COG aren't we in a dangerous state during the time both COGs "release" the bus if these signals float low.
Do we need pull up resistors on these ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There are pullups on these
However, we still have to be careful when changing cogs. -CE should be returned high when changing cogs. -WE cannot ever be left low, it must be returned high at the end of the write phase.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
It's very possible that you will have your blades up and running before I get a CP/M version together. I'm supposed to be dedicating my time to real work for a new start up[noparse]:)[/noparse]
Also I thought it would probably make sense to take baby steps and get the 8080 CPU diagnostic running first so that we know that everything is still OK with the emulation when using external RAM.
To that end I have attached two variants or ZiCog version 0.3. A "single step" version that is configured to execute one instruction when any key is hit and display the registers. A "speed" version that runs at full speed and displays the T8080 test result and KIPS.
They both run the same T8080.COM CPU diagnostic the source and listing of which are included and they both use PropTerminal.
I guess the speed version may be a problem unless you can find a spare pin for the heartbeat output. Would be nice to see if we can beat the current 456KIPS with the external RAM.
Hope the handful of COG LONGs remaining is sufficient.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What for speed have You on Yours system in "zicog_v0_3_speed".
On my system with 14.318.180 Hz Crystal and VGA driver from N8VME/PockeTermV.83 It have 1755 to 1806
Ps. with VGA·setings 640x480 it is 2660 to 2720
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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: Forgot to mention, as released it is set up to run with a 10MHz crystal and 8x PPL. With that I get approx. 456 thousand instructions per second.
Your numbers look very odd.
Changing to VGA or TV driver instead of the PropTerminal's serial drivers should not make any difference. I have used TV_Text and VGA_text many times. Assuming there is enough RAM left in the HUB I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I now it is orginaly 10MHz but only one of my Propelers run 5MHz and 16x PLL
Rest have 14.318.180 Hz and on that Prop I run Yours test
Will look on standart VGA_txt
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Heater: Thanks. I will test as soon as I get my pcbs and assemble. Hopefully they will be completed today but I have to wait for the postman. (I note 96% completion after inspection which may indicate a problem on the pcb manufacturer website)
Sapieha: Is the heartbeat on one of your used pins for the VGA???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes it was and in "Frequency Counter" was bad value to 1 second wait.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Here is ZiCog V 0.3 running a 20K CP/M system from HUB.
Although this is still V0.3 I did make a weeny change in the break function break_ovl in zicog.spin. Of course the zicog_demo.spin is now totally different containing all the Altair hardware emulation.
Cluso, I love it when you say you will get your boards fixed today that means they will be ready when I a wake up in the morning here in Finland[noparse]:)[/noparse]
Sapieha: Sorry, yes, I forgot to fix that delay in frequency counter, I just today fixed the one in the single step function.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have been watching the i8080 and Z80 work with great interest. I have been wanting to reproduce my first computer, which was a Nascom 1 (later 2). I made a great mistake in chucking it out 10 years ago. I am only about 2 months into the Prop path and so would use 99% of your brilliant work and bend it a bit, I hope.
The Nascom 1 was awonderfully simple build if you loved hundreds of ttl gates and strange screen layouts. I did once use the dreaded Mode 2 interupts, just to get a joystick-sort-of -mouse curser control
I have edited one line in Yours "zicog_demo" to have posiblites to dynamic Reconfig ON "msize" CONstant
It is that line.
"free BYTE 0[noparse][[/noparse]ram_size - $2400 - $08] ' 0[noparse][[/noparse]$2C00 - $08]"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Going off on a slight tangent, I'm deep inside the world of wireless mesh protocols. This involves individual CP/M boards (I'm using 3 and am going to go to 5 very soon), all testing links to each other and building up a database over 24 hours or so with the % reliability of those links. These end up in text files, so one needs the ability to read and write text files. Then from time to time the boards exchange these text files using xmodem. Eventually all these files end up propogating through the mesh with each board knowing the nearby nodes list for every other board, so each board has all the data it needs to work out the optimum route for a message. There are some cunning little programs in there, like one called DIRLST which does a DIR and saves it to a text file. Sometimes, instead of writing code, it is easier to shell out to an existing CP/M program. There is a vast library of useful little bits of code out there, especially on the Walnut Creek CD archive.
The reason for mentioning all this is that the code needed to run a mesh ends up growing. It is now up to 31k and may end up bigger again. So it won't quite fit in 20k that the prop simulation is using. Then again, many CP/M programs won't fit in 20k. Most, like wordstar and games, grew to the available space, which was ?about 50k.
Cluso99 - please let us know when your boards come in - I can do a direct deposit payment or paypal etc.
heater - on your screenshot it looks like you are using the altair simh version. That can emulate quite a few drives. Are these drives 'real' in your simulation? ie, if you went to drive B>, are there files there too? Can you PIP those files? And where are these files residing, on a SD card? I'm just wondering if you have mass storage code working, because if so, that is a huge achievement. Can you run the <20k programs, eg does DDT run?
I'm eagerly looking forward to putting this on a triblade with some ram...
Yes all those drives listed in the start up messages are real. Yes you can log in to them, DIR them, PIP to them, format them etc. They are 8 floppy drives of 1Mb each and exist on a SD card. See attached screen shot. I keep meaning to add two 8Mb hard drives, should be quite simple, just haven't got around to it yet.
The PropAltair CP/M on a Prop has supported these floppy drives since almost the beginning, ZiCog now has a tidied up version of that code.
Just realized that I have forgotten to include the object required to get the CP/M disk images onto the SD card.
I should try to document this properly. All this info is buried now in the long PropAltair thread. That might have to wait until the TriBlades are ready and we have a "stable" system.
Yes we can run code that fits in 20K, see survey.com running in another screen shot.
Yes DDT works, see last screen shot.
This ZiCog really is CP/M on a single Propeller. PropAltair is a complete standalone 20K CP/M computer including video display in one of it's versions. ZiCog has grown a bit large to do that though unless we go down to 16K or so.
I'm itching to get a TriBlade as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Amazing. I've no idea how you got the disk bit working because that is the hard part.
I've just disassembled this sbasic program
rem ************ MAIN **************
print "Hello World"
end
You may not be able to compile this on the board because sbasic needs more than 20k to run the compiler, but a disassembly shows a few Z80 codes - I see ex af,af' and djnz for example. So attached is a compiled version.
Attached HELLO.XYZ (change it to .COM as the forum doesn't like .COM extensions)
I'd be interested to see if this runs...
Post Edited (Dr_Acula (James Moxham)) : 3/11/2009 12:28:45 PM GMT
Turns out the floppy disk implementation was very easy:
1) Halt the CPU emulation on I/O operations and see what it wants to do.
2) Collect the disk select, sector and track commands it is outputting.
3) Translate those into block numbers on the SD card.
4) read/writes then go to that SD block.
Have a look in zicog_demo.spin there is not much to it.
You have quite a challenge there for me, many of the Z80 ops are not tested in any way yet and things like EX don't exist yet.
Still I'll see what I can do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My immediate problem is that the CP/M distributed with the SIMH AltairZ80 emulator project uses some tools to rebuild CP/M that do use a handful of Z80 ops. So I have to get those ops working for starters. I'd like to continue to use the SIMH stuff as it is a known good working system as a reference and a very fine simulator environment.
Anyway I have advertised ZiCog as a full up Z80 simulator so I'm kind of committed now to doing an accurate job.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have looked at your ZiCog code for v0.3 and run it using PST (on a ProtoBoard)·- no problems after I placed a delay loop in the demo· to slow the start till PST was running after the PropTool loading (and changed the xtal). Are there any commands I can input from PST?
I looked at your ZCog v0.3 CP/M. I will need to replace sdspiqasm.spin so that I can use the RAM for this initially. That wil be easy, but how do I get the sdcard code in a binary block so I can load it into RAM in the first place? I see it is·currently in files. I guess I am asking how to format and copy the RAM as a Floppy/Hard drive.
My pcbs were not shipped by the mfr today, hopefully they will be shipped tomorrow :-(
Nascom:
I have a friend in NZ that has a couple of working Nascoms with all sots of rom code including assemblers. He also has a couple of·Motorola D2·and has bought a PropProtoBoard to do a Terminal for this. Then maybe I'll get him on to emulations on the TriBladeProp :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
zicog_v0_3_single_step only has one command "step" when any key is pressed. zicog_v0_3_single_speed has none.
If you have zicog_v0_3_cpm and a CP/M prompt on your demo board and no SD card file system there is very little you can do. There are a couple of commands "built in" to CP/M but I don't remember what they are. All most all, DIR, etc etc are on disk. I guess if you type "DIR" you get a BDOS ERROR or it crashes[noparse]:)[/noparse]
I seriously recommend that we forget CP/M and SD cards for a moment and get the CPU test code running first. So I think the thing to do is:
1) Down load the zicog_v0_3_single_step.zip version from a few posts back.
2) Check you can run this on the your demo board so you can see how it goes. Basically every time you hit a key it will execute one instruction of the T8080 CPU diagnostic program and then display the registers. The current op code is also displayed unlabelled. For fun the a listing of the T8080 program is included so you can follow the program steps in the listing. If you hold down a key long enough, a minute or so, the PC will get up to 1EAC at which point it will indicate that a 1 has been output to port 0. That is the "pass" result. If you get 2 that is not good.
3) You'll want to do the same check on the Blade when it arrives.
4) Now modify the zicogs memory access routines for external RAM
5) Now to put the T8080 program into your external RAM. Somewhere in zicog_demo.spin before the cpu start you will have to add some code that reads all the bytes of T8080.COM (as included by a "file" statement) from where it sits in HUB and writes them out to address $0100 upward in the external RAM.
Bytes $0000 to $00FF can be zero as that is a NOP. The CPU will start at zero and run through the NOPs into the test program at $0100. Might be as well to zero the rest of RAM.
6) Now you can test RAM execution by single stepping.
7) If that is working you can do a speed trial by changing "single_step := 1" to "single_step := 0" in zicog_demo.spin and commenting out the call to break_ovl in the dispatch loop in zicog.spin. You now have the "speed" version.
8) I will think about how to do all this for the CPM version[noparse]:)[/noparse]
Hope all that makes sense.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I always assumed BDS C restricted itself to 8080 instructions. Those simple tests I have done with it on the Prop emulation work just fine. But they do not use such things as memcmp or strcpy. For sure I want to get all the flags right in ZiCog so that this works as you say.
I'm just itching to get BDS C hosted on the Propeller itself. We are just days away now, what with Clusos TriBlade board coming soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No, I don't want, nor expect locks. The word access is not going to happen because then you have to cater for both byte and word and code that. Also, you have to have 16bit wide memory and the extra 8 pins or else you resort to a latch which defeats the speed. But I will code for word access - once OUTA has the address in the correct bits, then after the read we just increment the OUTA address and read the next byte (and increment the register holding the original address if required) - easy. And yes, the DIRA will always be left in the same state (which is for read). With the word reads, you can see how easy it will be to do string reads/writes (be it for Disk emulation or string moves) - I am talking RAM emulation here, not microSD or Flash as that will be seperate.
Rokicki:
What we are proposing to do for access will also work on any emulation, including the 6809. I have a real soft spot for Motorola cpus - used 100,000's of 68705's. Never did anything on the 6809 though. I suggest you continue the 6809 work. Maybe another thread as those not interested in the Z80 may not read this thread and you might find others willing to help there as well. Sorry, I just cannot afford to get distracted yet.
Don't worry about code size at this point. Just get each instruction working using the vector table concept and overlay when you need to (even if this means every instruction loads an overlay, that doesn't matter yet). Once running this can all be sorted, and you will realise where common code can be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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
Don't care what DIRA is doing. Thing is one COG should not be driving addresses/controls high when a another COG may need access after all the COG outputs are ORed together on their way to the actual pins. Perhaps DIRA will need setting to input to achieve this, I don't know.
Just thinking about IO. We should make it possible for Z80 code to get direct access to Propeller hardware: pins, counters etc. Just need to map some Z80 IO space into COG special purpose registers. Although I'd be surprised if we can generate video from 8080 code[noparse]:)[/noparse]
Really crazy to would be to enable the 8080 code to start COGs with code read from the SD card file system!
A 6809 thread is a great idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
DIRA from multiple cogs: Not a problem. There are different ways this can be done, but in this case it will be best for the cog to make the DIRA all inputs before it releases control. That way we don't have to set OUTA before we release control, and no handshaking or locks will be needed if multiple cogs wont be accessing the ram simulataneously. We can use a different cog to do the ram disk access which means it can be resident code in the cog. Then just pass the disk sector address to the cog via hub and the cog can read the data - or maybe it may be just as quick to use the one cog, just like you found in splitting up the instructions - will have to see, but that can come later.
IO: We do not have any i/o pins available - only 2 serial pins for comms to another prop - so keep that in mind. So, the video and any i/o will be on a seperate prop(s). This will use a Terminal emulator like VT100 on another prop - there was one posted on another thread (I think by OBC).
Likewise, the SDcard file system has been posted on another thread I think - it may require modifying but I am sure it's there when required.
A cog could be started with code from the sd card but its a little more complex than that. However, the same applies as the i/o system - likely to be on another prop.
I have taken all this into account for the TriBladeProp. We can start out with 2 Blades and progress to 3 if we need more i/o or the vga system needs ram. A lot of the design options are still in my head. The schematic shows all the options but doesnt really explain how I intend to use them, and how to expand their use from a minimal system to a more complex one. Most of the links are already on the pcb. We can use pin headers with links(shunts) or hardwire the links with wire. It will be easier to explain with photos (or videos) of the pcb, in conjunction with the schematic I published. I'll create a thread to ask how people do videos easily - isn't this forum just great
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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 have just been looking at your v0.1 code. Since we will have·a full 64KB ram/rom space, the read_memory_byte·routine will no longer have to check the ram_size. This will improve performance quite a bit, particularly the rom access,·as well as saving some code space.
The read_memory_word routine will now be easy to place inline, also improving performance.
Not that the above will have a great impact on overall performance as it is only a small part of the code executed for each emulated instruction, but is common to every instruction. Every bit will help. The call #read_memory_byte can then be inline coded which will improve again, but uses a couple of extra longs.
There are probably places to improve performance where the 2nd & 3rd vectors could be inline coded for an extra long which will improve a bit more.
As I said, every bit will help. :-)
Your use of the PC_Keyboard and PC_Text will be great to make it easy to have the "Terminal" on another prop (Blade) :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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 have already been through the vectors pruning out some redundant steps, perhaps there are more possibilities there but it can wait a bit.
Just now I was wondering how to make a CP/M package out of this. Given that you are going to be the one with TriBlades and RAM up and running first I though I'd try and make something that you can just drop in and modify the access functions.
I'm thinking to replace the PropAltair cpu with ZiCog and get it running as a 16K CP/M system in HUB RAM as usual. There is not enough room for the old 24K system with ZiCog. You would then have to: 1) Modify the RAM access functions. 2) Add some code to copy the CP/M and BIOS files from HUB out to ext RAM on start up. This is quick and dirty to see it run but we really want a 64K system.
So, second step, replace the CP/M files with ones built for 64K, change the copy code to put them in the right place in ext RAM. That's it, should run.
Note that this does not rely on the EPROM bootloader code or files on SD card to get us up to the CP/M prompt which makes life much easier for testing.
A more grandiose plan is to use FAT on the SD card and keep CP/M disks in files there. Ariba has already shown how to do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The write is a little more complex so I am still looking at this.
I agree, the simplest will be to copy the rom code to the sram and run from the·64KB SRAM. Initially I will use the PC_Keyboard and PC_Text via the PropPlug (external one first). I will have to get PropTerminal working - currently use PST, but no problems there anyway.
And yes the SD can come later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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
At first glance I would suggest not storing the PC shifted by 8. There are a lot of places that use pc which would then have to be fixed up. At least in a first version it would be better not to have so many changes to make.
Unless I have done something wrong "address" is a throw away parameter for [noparse][[/noparse]read,write]_memory_[noparse][[/noparse]byte,word] except that [noparse][[/noparse]read,write]_memory_word expects it to be incremented by [noparse][[/noparse]read,write]_memory_byte. If you see what I mean.So I don't expect any problem there.
What is going on with read_memory_word? "data_8" gets shifted by 24 but is otherwise unused. "data_8" is not a required output of read_memory_word.
Not sure now but it's probably better if data_8 is not corrupted here either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, address has to be incremented - probably best at first to copy elsewhere for use.
Sorry, the data_8 should be data_16 (data_8 never used) as...
shl data_16, #24 ' extract 8 bits (+ sram access time)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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 RAM is selected when CE is low and more dangerous write is enabled when WE is low.
So when changing from COG to COG aren't we in a dangerous state during the time both COGs "release" the bus if these signals float low.
Do we need pull up resistors on these ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
However, we still have to be careful when changing cogs. -CE should be returned high when changing cogs. -WE cannot ever be left low, it must be returned high at the end of the write phase.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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
It's very possible that you will have your blades up and running before I get a CP/M version together. I'm supposed to be dedicating my time to real work for a new start up[noparse]:)[/noparse]
Also I thought it would probably make sense to take baby steps and get the 8080 CPU diagnostic running first so that we know that everything is still OK with the emulation when using external RAM.
To that end I have attached two variants or ZiCog version 0.3. A "single step" version that is configured to execute one instruction when any key is hit and display the registers. A "speed" version that runs at full speed and displays the T8080 test result and KIPS.
They both run the same T8080.COM CPU diagnostic the source and listing of which are included and they both use PropTerminal.
I guess the speed version may be a problem unless you can find a spare pin for the heartbeat output. Would be nice to see if we can beat the current 456KIPS with the external RAM.
Hope the handful of COG LONGs remaining is sufficient.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What for speed have You on Yours system in "zicog_v0_3_speed".
On my system with 14.318.180 Hz Crystal and VGA driver from N8VME/PockeTermV.83 It have 1755 to 1806
Ps. with VGA·setings 640x480 it is 2660 to 2720
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Sapieha) : 3/10/2009 5:09:57 PM GMT
Your numbers look very odd.
Changing to VGA or TV driver instead of the PropTerminal's serial drivers should not make any difference. I have used TV_Text and VGA_text many times. Assuming there is enough RAM left in the HUB I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I now it is orginaly 10MHz but only one of my Propelers run 5MHz and 16x PLL
Rest have 14.318.180 Hz and on that Prop I run Yours test
Will look on standart VGA_txt
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Sapieha) : 3/10/2009 6:00:50 PM GMT
Sapieha: Is the heartbeat on one of your used pins for the VGA???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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
Yes it was and in "Frequency Counter" was bad value to 1 second wait.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Although this is still V0.3 I did make a weeny change in the break function break_ovl in zicog.spin. Of course the zicog_demo.spin is now totally different containing all the Altair hardware emulation.
Cluso, I love it when you say you will get your boards fixed today that means they will be ready when I a wake up in the morning here in Finland[noparse]:)[/noparse]
Sapieha: Sorry, yes, I forgot to fix that delay in frequency counter, I just today fixed the one in the single step function.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have been watching the i8080 and Z80 work with great interest. I have been wanting to reproduce my first computer, which was a Nascom 1 (later 2). I made a great mistake in chucking it out 10 years ago. I am only about 2 months into the Prop path and so would use 99% of your brilliant work and bend it a bit, I hope.
The Nascom 1 was awonderfully simple build if you loved hundreds of ttl gates and strange screen layouts. I did once use the dreaded Mode 2 interupts, just to get a joystick-sort-of -mouse curser control
Seems everything one needs to know is here www.nascomhomepage.com/
Should be possible to get a NASCOM 1 into a single Prop including video. Or use Cluso's TriBlade propeller board for more RAM.
How I drooled over the NASCOM adds. Never had the cash to get one at the time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have edited one line in Yours "zicog_demo" to have posiblites to dynamic Reconfig ON "msize" CONstant
It is that line.
"free BYTE 0[noparse][[/noparse]ram_size - $2400 - $08] ' 0[noparse][[/noparse]$2C00 - $08]"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Going off on a slight tangent, I'm deep inside the world of wireless mesh protocols. This involves individual CP/M boards (I'm using 3 and am going to go to 5 very soon), all testing links to each other and building up a database over 24 hours or so with the % reliability of those links. These end up in text files, so one needs the ability to read and write text files. Then from time to time the boards exchange these text files using xmodem. Eventually all these files end up propogating through the mesh with each board knowing the nearby nodes list for every other board, so each board has all the data it needs to work out the optimum route for a message. There are some cunning little programs in there, like one called DIRLST which does a DIR and saves it to a text file. Sometimes, instead of writing code, it is easier to shell out to an existing CP/M program. There is a vast library of useful little bits of code out there, especially on the Walnut Creek CD archive.
The reason for mentioning all this is that the code needed to run a mesh ends up growing. It is now up to 31k and may end up bigger again. So it won't quite fit in 20k that the prop simulation is using. Then again, many CP/M programs won't fit in 20k. Most, like wordstar and games, grew to the available space, which was ?about 50k.
Cluso99 - please let us know when your boards come in - I can do a direct deposit payment or paypal etc.
heater - on your screenshot it looks like you are using the altair simh version. That can emulate quite a few drives. Are these drives 'real' in your simulation? ie, if you went to drive B>, are there files there too? Can you PIP those files? And where are these files residing, on a SD card? I'm just wondering if you have mass storage code working, because if so, that is a huge achievement. Can you run the <20k programs, eg does DDT run?
I'm eagerly looking forward to putting this on a triblade with some ram...
Yes all those drives listed in the start up messages are real. Yes you can log in to them, DIR them, PIP to them, format them etc. They are 8 floppy drives of 1Mb each and exist on a SD card. See attached screen shot. I keep meaning to add two 8Mb hard drives, should be quite simple, just haven't got around to it yet.
The PropAltair CP/M on a Prop has supported these floppy drives since almost the beginning, ZiCog now has a tidied up version of that code.
Just realized that I have forgotten to include the object required to get the CP/M disk images onto the SD card.
I should try to document this properly. All this info is buried now in the long PropAltair thread. That might have to wait until the TriBlades are ready and we have a "stable" system.
Yes we can run code that fits in 20K, see survey.com running in another screen shot.
Yes DDT works, see last screen shot.
This ZiCog really is CP/M on a single Propeller. PropAltair is a complete standalone 20K CP/M computer including video display in one of it's versions. ZiCog has grown a bit large to do that though unless we go down to 16K or so.
I'm itching to get a TriBlade as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 3/11/2009 6:09:31 AM GMT
I've just disassembled this sbasic program
rem ************ MAIN **************
print "Hello World"
end
You may not be able to compile this on the board because sbasic needs more than 20k to run the compiler, but a disassembly shows a few Z80 codes - I see ex af,af' and djnz for example. So attached is a compiled version.
Attached HELLO.XYZ (change it to .COM as the forum doesn't like .COM extensions)
I'd be interested to see if this runs...
Post Edited (Dr_Acula (James Moxham)) : 3/11/2009 12:28:45 PM GMT
1) Halt the CPU emulation on I/O operations and see what it wants to do.
2) Collect the disk select, sector and track commands it is outputting.
3) Translate those into block numbers on the SD card.
4) read/writes then go to that SD block.
Have a look in zicog_demo.spin there is not much to it.
You have quite a challenge there for me, many of the Z80 ops are not tested in any way yet and things like EX don't exist yet.
Still I'll see what I can do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Do you have any more complex sbasic progs?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Programs that have been compiled to run on one specific machine may use them, IF the tools they used was built to take advantage of the Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
My immediate problem is that the CP/M distributed with the SIMH AltairZ80 emulator project uses some tools to rebuild CP/M that do use a handful of Z80 ops. So I have to get those ops working for starters. I'd like to continue to use the SIMH stuff as it is a known good working system as a reference and a very fine simulator environment.
Anyway I have advertised ZiCog as a full up Z80 simulator so I'm kind of committed now to doing an accurate job.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have looked at your ZiCog code for v0.3 and run it using PST (on a ProtoBoard)·- no problems after I placed a delay loop in the demo· to slow the start till PST was running after the PropTool loading (and changed the xtal). Are there any commands I can input from PST?
I looked at your ZCog v0.3 CP/M. I will need to replace sdspiqasm.spin so that I can use the RAM for this initially. That wil be easy, but how do I get the sdcard code in a binary block so I can load it into RAM in the first place? I see it is·currently in files. I guess I am asking how to format and copy the RAM as a Floppy/Hard drive.
My pcbs were not shipped by the mfr today, hopefully they will be shipped tomorrow :-(
Nascom:
I have a friend in NZ that has a couple of working Nascoms with all sots of rom code including assemblers. He also has a couple of·Motorola D2·and has bought a PropProtoBoard to do a Terminal for this. Then maybe I'll get him on to emulations on the TriBladeProp :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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
If you have zicog_v0_3_cpm and a CP/M prompt on your demo board and no SD card file system there is very little you can do. There are a couple of commands "built in" to CP/M but I don't remember what they are. All most all, DIR, etc etc are on disk. I guess if you type "DIR" you get a BDOS ERROR or it crashes[noparse]:)[/noparse]
I seriously recommend that we forget CP/M and SD cards for a moment and get the CPU test code running first. So I think the thing to do is:
1) Down load the zicog_v0_3_single_step.zip version from a few posts back.
2) Check you can run this on the your demo board so you can see how it goes. Basically every time you hit a key it will execute one instruction of the T8080 CPU diagnostic program and then display the registers. The current op code is also displayed unlabelled. For fun the a listing of the T8080 program is included so you can follow the program steps in the listing. If you hold down a key long enough, a minute or so, the PC will get up to 1EAC at which point it will indicate that a 1 has been output to port 0. That is the "pass" result. If you get 2 that is not good.
3) You'll want to do the same check on the Blade when it arrives.
4) Now modify the zicogs memory access routines for external RAM
5) Now to put the T8080 program into your external RAM. Somewhere in zicog_demo.spin before the cpu start you will have to add some code that reads all the bytes of T8080.COM (as included by a "file" statement) from where it sits in HUB and writes them out to address $0100 upward in the external RAM.
Bytes $0000 to $00FF can be zero as that is a NOP. The CPU will start at zero and run through the NOPs into the test program at $0100. Might be as well to zero the rest of RAM.
6) Now you can test RAM execution by single stepping.
7) If that is working you can do a speed trial by changing "single_step := 1" to "single_step := 0" in zicog_demo.spin and commenting out the call to break_ovl in the dispatch loop in zicog.spin. You now have the "speed" version.
8) I will think about how to do all this for the CPM version[noparse]:)[/noparse]
Hope all that makes sense.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.