You won't regret ordering and waiting. Besides Z80 emulation you will be able to use the Catalina C compiler to produce huge programs for external RAM. Or use GCC and the Zog system. Or whatever else comes up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've got drawers full of 5V memory chips. I think heater has as well. Those occasional errors do not sound good. I think it might be similar to an issue discussed recently on another thread where someone very cleverly noticed that 74HC parts do not fall within specification when translating 3.3V to a logic high. Yet many of us have used these chips. Indeed it could explain mysterious bugs, because the voltages are very close but not quite. 74HCT is within specification. I don't know what the specs are for particular ram chips - whether they are like HC or HCT or even more like LS logic levels.
For the addressing, if you are using latches you will put in HCT anyway. The data lines are more complicated as they are bidirectional. Whether you use 100 ohm or 1k or something else, the problem may still be there. Perhaps there is a two resistor divider circuit that biases the high up by 20% but still keeps the low within spec as well? I don't know and it would depend on the data specs for high and low for the particular memory chip.
There also could be a solution with a HCT245 but then you need to provide a direction signal. Possibly using the rd or wr line. But that adds another chip.
I think it was cluso that found the 512k memory chip. It still is not a perfect solution - future electronics charge $30 shipping for a $4 chip. I justified it by buying ten and also buying ten vga sockets (which are also a bit hard to find).
I'm selling about three dracblade boards a fortnight. Maybe I should think about a kit? Maybe someone else could sell a kit? I will ponder that some more.
Alternatively, Cluso sells his boards already soldered up and I must say they are very neat and tiny.
Dr_A. You are selling 6 DracBlades a month. Excellent. That makes almost makes it a "standard platform" to work to like the DemoBoard. I wonder how many TriBlades/RamBlades are out there.
A kit would be an excellent idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The 3-vector emulator idea is total genius. I modified the original z80_emu code posted here to make a working pure 8080 CPU and used it in a Space Invaders emulator. I am attaching my project archive. You can see the emulator in action here.
I saw a YouTube clip of the original Space Invaders arcade game, and I realized that it should be possible to improve the sound in your emulator.
I know that you are using SIDcog, that's why I am offering to help you out.
any chance to get the space invaders demo to work on a demo board with the sd @p3 and vid @12,13,14 ?)
Alexis64, this one was quickly hacked for the DemoBoard without SD card, the ROM (not included) must be embedded in the binary.
Controls can be wired in the same fashion as the original, but moved to the P0..P7 range (DISABLE OUTPUT DRIVE BY THE PAD OBJECT FIRST!), or using a Wii Classic Controller connected to the mouse port (SDA=P24, SCL=P25).
P.S.: I forgot to comment out "dbg.start(...)" at in boot.spin, line 124 before packing...
Help is most welcome! I wish I knew more about how to play samples on the propeller. The files are available on the web to play from MAME. It might be possible to import them.
After reading some, I'm convinced that SIDcog was the right choice, just need some tuning with the parameters. :thumb:
I've done some more "monkey job" on the controllers, using MIGS system (by OBC et al).
Now keyboard, NES pads, N64 pads and WiiClassic are supported in this mod.
Every DemoBoard owner should be able to defend the earth, no excuses!
NOTE: keyboard mapping in MIGS has been changed to a more MAME-ish layout: the arrow keys, left-CTRL/left-ALT, 5 for coin and 1 to start.
@heater et al, I was wondering if I can ask a few things about the 8080 version of the Zicog. I see post #1086 ChrisCantrell did a modified 8080 version. I'm thinking of the fastest 8080 version out there and presumably this would be an all-in-one-cog solution, no LMM and with the 8080 registers stored in the cog rather than in hub?
If so, how fast did this run with that small version of CP/M where you used hub ram only and no external ram?
The reason I ask is that I'm wondering if you could take that version and run it with 64k of memory using caching?
Drac: Some of the older versions can still be compiled with those options. IIRC you can still compile the latest RamBlade ZiCog code with 8080 and without sram.
Possibly this question is best answered by Drac or maybe heater...
I have just been getting the RamBlade3 and ZiCog & CPM2.2 together for a full release. While testing I remembered that I wanted to be able to reboot back to the prop os. It's running a modified PropCmd although maybe I should be running KyeDos???
Anyway, do you have a method to get back to the prop os? IIRC heater suggested using the HALT program in CPM. Has anyone tried it - I presume I need to trap the Z80 Halt instruction?
Gosh, how did I miss your question from 10-24-2011? Sorry.
I thought you had gone over to PullMolls Z80 emulator.
I'm thinking of the fastest 8080 version out there and presumably this would
be an all-in-one-cog solution, no LMM and with the 8080 registers stored in the
cog rather than in hub?
[/quoute]
Somewhere back in mists of time there was an 8080 only emulation that passed
100% the 8080 instruction set tests we find in SimH Altair and lived in a single
COG with no LMM or overlays etc. Might even have been in the PropAltair days.
Anyway as far as I remember ZiCog passes all the 8080 instruction tests in the
Z80 version of that test. BUT there are some difference between the way a Z80
and a 8080 set flags so ZiCog (being a Z80) fails the 8080 version of the
tests. If you see what I mean. None of this matters for running CP/M and most
CP/M programs.
Also as far as I remember, and I have no time to check just now, ZiCog had
#ifdefs to get rid of all the Z80 ops when compiling.
I have a feeling that keeping the registers in COG did not gain anything much
speed wise. I reckon if you are using external RAM the difference is going to
be negligible.
If so, how fast did this run with that small version of CP/M where you used hub
ram only and no external ram?
I did some timing tests back in the day, again perhaps on the PropAltair
version, and posted the results which I no longer remember:) 600K instructions
per second comes to mind though.
The reason I ask is that I'm wondering if you could take that version and run it
with 64k of memory using caching?
Interesting idea, and it did cross my mind once or twice. It works for Zog so
why not 8080 codes? I think it's doable.
Be aware that it is not possible to rebuild CP/M under CP/M running on an 8080
using the tools provided in SimH Altair. Some of the programs used in the
submit files make use of Z80 instructions. I think its only the string ops.
Also there is some difference in flag setting between Z80 and 8080 used by the
BIOS to detect which processor is in use.
So the best thing to do, and which I did initially, is have the 8080 instruction
set plus those few required Z80 instructions. A kind of hybrid.
Now, there has not been any ZiCog action here for a long time due to work and
life and a million other projects that need doing. I was kind of thinking to
leave it dormant until the Prop II comes out and we can put the whole CP/M
computer in there. Plus I want to bin all the Spin and replace it with C.
Again I have no time to check but seem to remember that he HLT instruction is trapped in ZiCog and gets you back out to Spin. So the HALT program would do that.
How you get out of that Spin back to whatever Prop OS you have I have no idea.
By the way guys, I 'm glad to see ZiCog has a life out there without me. I have not given up on it. One day I will have time again and for sure the will need to be a PII version.
I noticed the display, Sounds like there is a CP/M Tab on the horizon:)
C might speed things up but the LMM code it generates is bigger and there is no way we are going to get the FAT file system and all into the Prop I with it.
I will check the halt trap section. It stops the emulation and outputs the reg set atm.
I am wanting to get back to prop os whateverbthat may be.
ZiCog is definately not dead - just that I have been busy elsewhere. I have some new hw coming and want to get it running so i can also use catalina c programs and some basic too, all under the os.
I recently got a DuinoMite Mini with its inbuilt BASIC, as standard. They do a Z80 emu but I havent tried it but it did show me what a chip with 512Kb of flash and 128Kb of RAM can do on its own, and with just one core!
If the Prop2 could just boot from a SD as well as the EEPROM then ....
I noticed the display, Sounds like there is a CP/M Tab on the horizon
Yes there will be. Just need to get a font for this touchscreen. I think this program is going to be the answer http://www.angelcode.com/products/bmfont/ Should be able to get a 40x12 display. Possibly more.
Playing music ought to be easy too (if you are happy to only have a few songs with one icon per song).
I think this can be possible in C and Spin. Probably do Spin first then port it over to C. I'm doing all the coding for the ILI9325 inside a single object to make it easy to use.
But this is going to need text and some scrolling text windows and a popup keyboard. So I have some work to do!
I have a little dream of running CP/M on a device you can fit in your pocket
cpm to fat works. fat to cpmfile copy of the data works but i am not writing out the directory entries yet. i also have the pc to and from fat basics coded.
See the ILI9325 discussion thread - if this display can do Wordstar at 80x40 characters, it would be absolutely fantastic to have the real emulator working as well.
re
So the best thing to do, and which I did initially, is have the 8080 instruction
set plus those few required Z80 instructions. A kind of hybrid.
Yes that sounds like the secret.
In terms of resources, if you look at that program running the touchscreen, it is using two cogs (three if you count the TV but that is just for debugging and I'm almost at the point of not needing that now that a rudimentary VT100 display is working), and as well as the two cogs, it uses about half the hub ram. Most of that hub ram is for Kye's SD driver code.
So - with 16k of hub and 6 cogs, is it possible to get the 8080 + a few Z80 driver working?
(No need for a display buffer - that is in external ram)
There may come a time where I might get some boards made and send them out to all those involved.
But just to get the vibe of the thing, is it possible to fit an 8080 + a few Z80 opcodes into a cog *without* using LMM?
Also as a heads-up, I'm working on a few hardware concepts. The ILI9325 display works best at 16 bits, so that sort of leans to a design where you have the ILI9325 and the ram interfaced as closely as possible. 16 data lines. One write line driven by a propeller pin. Address lines driven by 19 propeller pins so you can increment the ram address quickly. The slower bit is writing data to the ram. I'm still scribbling designs on the back of envelopes at the moment, but the general idea is that it will be possible to move data to and from two parallel sram chips 16 bits at a time. So the data throughput to the ram is twice as fast potentially as cluso's fastest design.
As a result it may almost be quicker to pull data directly off the ram chips rather than read from hub (reading 1 word at a time), and maybe this leads to consideration of a different cog design for the zicog?
I'll think about this more and maybe post a schematic of what I am thinking about.
The *slowest* bit right now is the display so I have to work on that. Back to coding...
So - with 16k of hub and 6 cogs, is it possible to get the 8080 + a few Z80 driver working?
Back in the day we had an 8080 emulation running with 20 odd K of memory space for 8080 programs in HUB so I guess what you want is possible. Assuming the CP/M memory space is in ext RAM.
...is it possible to fit an 8080 + a few Z80 opcodes into a cog *without* using LMM?
Hmmm...As far a remember it did not quite fit and the DAA and block move instructions had to go out to overlay and then LMM. But it's not much.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For the addressing, if you are using latches you will put in HCT anyway. The data lines are more complicated as they are bidirectional. Whether you use 100 ohm or 1k or something else, the problem may still be there. Perhaps there is a two resistor divider circuit that biases the high up by 20% but still keeps the low within spec as well? I don't know and it would depend on the data specs for high and low for the particular memory chip.
There also could be a solution with a HCT245 but then you need to provide a direction signal. Possibly using the rd or wr line. But that adds another chip.
I think it was cluso that found the 512k memory chip. It still is not a perfect solution - future electronics charge $30 shipping for a $4 chip. I justified it by buying ten and also buying ten vga sockets (which are also a bit hard to find).
I'm selling about three dracblade boards a fortnight. Maybe I should think about a kit? Maybe someone else could sell a kit? I will ponder that some more.
Alternatively, Cluso sells his boards already soldered up and I must say they are very neat and tiny.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/24/2010 12:58:43 AM GMT
A kit would be an excellent idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
http://www.youtube.com/watch?v=n8_lrEy30JE
I saw a YouTube clip of the original Space Invaders arcade game, and I realized that it should be possible to improve the sound in your emulator.
I know that you are using SIDcog, that's why I am offering to help you out.
/Ahle2
well done!
Alexis64, this one was quickly hacked for the DemoBoard without SD card, the ROM (not included) must be embedded in the binary.
Controls can be wired in the same fashion as the original, but moved to the P0..P7 range (DISABLE OUTPUT DRIVE BY THE PAD OBJECT FIRST!), or using a Wii Classic Controller connected to the mouse port (SDA=P24, SCL=P25).
P.S.: I forgot to comment out "dbg.start(...)" at in boot.spin, line 124 before packing...
That's great. Good to see the old ZiCog code getting some use. I have to have a play with that but I'm away from home for this week.
Indeed it is. Full credit for that must go to Cluso who suggested the idea to me.
I guess you already know this one: http://www.ascotti.org/programming/side/soundboard.htm
If not, it's definitely worth a look!
After reading some, I'm convinced that SIDcog was the right choice, just need some tuning with the parameters. :thumb:
I've done some more "monkey job" on the controllers, using MIGS system (by OBC et al).
Now keyboard, NES pads, N64 pads and WiiClassic are supported in this mod.
Every DemoBoard owner should be able to defend the earth, no excuses!
NOTE: keyboard mapping in MIGS has been changed to a more MAME-ish layout: the arrow keys, left-CTRL/left-ALT, 5 for coin and 1 to start.
Thank you very much -- works great! I just wanted to see the speed and how it emulates it all ... very neat...
If so, how fast did this run with that small version of CP/M where you used hub ram only and no external ram?
The reason I ask is that I'm wondering if you could take that version and run it with 64k of memory using caching?
I have just been getting the RamBlade3 and ZiCog & CPM2.2 together for a full release. While testing I remembered that I wanted to be able to reboot back to the prop os. It's running a modified PropCmd although maybe I should be running KyeDos???
Anyway, do you have a method to get back to the prop os? IIRC heater suggested using the HALT program in CPM. Has anyone tried it - I presume I need to trap the Z80 Halt instruction?
Gosh, how did I miss your question from 10-24-2011? Sorry.
I thought you had gone over to PullMolls Z80 emulator.
Again I have no time to check but seem to remember that he HLT instruction is trapped in ZiCog and gets you back out to Spin. So the HALT program would do that.
How you get out of that Spin back to whatever Prop OS you have I have no idea.
Well, yes I went over to Pullmoll's code but he has disappeared, and much of what he wrote is in pure pasm.
So - time marches on and we have another display solution http://forums.parallax.com/showthread.php?137266-Propeller-GUI-touchscreen-and-full-color-display and I am thinking of a way to write CP/M using a text driver for that new display.
And we now have caching and C which will speed things up a lot. So Zicog could well have another life! And I don't think it needs to wait for the PII
At the very least, it could be a neat demonstration of what is possible using C.
I noticed the display, Sounds like there is a CP/M Tab on the horizon:)
C might speed things up but the LMM code it generates is bigger and there is no way we are going to get the FAT file system and all into the Prop I with it.
I am wanting to get back to prop os whateverbthat may be.
ZiCog is definately not dead - just that I have been busy elsewhere. I have some new hw coming and want to get it running so i can also use catalina c programs and some basic too, all under the os.
If the Prop2 could just boot from a SD as well as the EEPROM then ....
Yes there will be. Just need to get a font for this touchscreen. I think this program is going to be the answer http://www.angelcode.com/products/bmfont/ Should be able to get a 40x12 display. Possibly more.
I got a movie going on the touchscreen http://www.youtube.com/watch?v=2mGsOHryeFw&feature=youtu.be
Playing music ought to be easy too (if you are happy to only have a few songs with one icon per song).
I think this can be possible in C and Spin. Probably do Spin first then port it over to C. I'm doing all the coding for the ILI9325 inside a single object to make it easy to use.
But this is going to need text and some scrolling text windows and a popup keyboard. So I have some work to do!
I have a little dream of running CP/M on a device you can fit in your pocket
Attached is the RamBlade3 build using the PC as a terminal at 115,200.
zicog_cpm_2012_rr173_RB3_fdx-bst-archive-120121-195806.zip
FYI: I rename the binary Z3_173FX.BIN
Z3 = ZiCog for RamBlade3
173 = version number
FX = FullDuplexSerial (PC comms on P31/P30)
(same spec as previous post v173 for RamBlade3)
zicog_cpm_2012_rr174_RB1_fdx-bst-archive-120207-205853.zip
See the ILI9325 discussion thread - if this display can do Wordstar at 80x40 characters, it would be absolutely fantastic to have the real emulator working as well.
re
Yes that sounds like the secret.
In terms of resources, if you look at that program running the touchscreen, it is using two cogs (three if you count the TV but that is just for debugging and I'm almost at the point of not needing that now that a rudimentary VT100 display is working), and as well as the two cogs, it uses about half the hub ram. Most of that hub ram is for Kye's SD driver code.
So - with 16k of hub and 6 cogs, is it possible to get the 8080 + a few Z80 driver working?
(No need for a display buffer - that is in external ram)
There may come a time where I might get some boards made and send them out to all those involved.
But just to get the vibe of the thing, is it possible to fit an 8080 + a few Z80 opcodes into a cog *without* using LMM?
Also as a heads-up, I'm working on a few hardware concepts. The ILI9325 display works best at 16 bits, so that sort of leans to a design where you have the ILI9325 and the ram interfaced as closely as possible. 16 data lines. One write line driven by a propeller pin. Address lines driven by 19 propeller pins so you can increment the ram address quickly. The slower bit is writing data to the ram. I'm still scribbling designs on the back of envelopes at the moment, but the general idea is that it will be possible to move data to and from two parallel sram chips 16 bits at a time. So the data throughput to the ram is twice as fast potentially as cluso's fastest design.
As a result it may almost be quicker to pull data directly off the ram chips rather than read from hub (reading 1 word at a time), and maybe this leads to consideration of a different cog design for the zicog?
I'll think about this more and maybe post a schematic of what I am thinking about.
The *slowest* bit right now is the display so I have to work on that. Back to coding...
Back in the day we had an 8080 emulation running with 20 odd K of memory space for 8080 programs in HUB so I guess what you want is possible. Assuming the CP/M memory space is in ext RAM.
Hmmm...As far a remember it did not quite fit and the DAA and block move instructions had to go out to overlay and then LMM. But it's not much.