Dr_Acula said...
And when Juergen gets the dracblade he can start adding overlays without having to worry about running out of hub ram.
Life is good!
But loading PASM code from external RAM is going to be (much) slower than from hub RAM. This somehow defeats the intent of a recompiling emulator
Right now my code generates 21288 longs (including the Debug_1pinTV driver) and there are still all EDxx opcodes and all DDCB/FDCB opcodes missing...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
seems quite reasonable at the moment, perhaps forever if you have no need of RAM disks or floppy sized images.
Hmmm... sending batch files via wireless for execution on the remote end....I think you are about to enable the possibility of the worlds first wirelessly transmitted CP/M virus/worm [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No he does not say that. He says of CP/M, "It relies on the physical security methodology.....No one can get to your data from the outside through a network because CP/M has no network."
Your CP/M does have a network and it's a network with free access over the airwaves. BATCH file worms here we come !
Nice comparisons he makes though[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks for that link. Interesting reading and it makes some valid points as well as cautioning us about taking comparisons and performance testing too literally.
As someone who ran a business on a dual floppy 64K CPM system for several years I must say that having computers with several orders of magnitude improvement in speed, memory, storage, and communications capability has not made anywhere near a similar improvement in running a business. With the exception of the improvements due to the internet and e-mail I could just as easily use a 2MHz Z80 and CPM to do what I now do on a 2.6GHz dual processor system with 2GB of memory.
Bahh! expletive, expletive, expletive. How long is it possible to stare at couple of dozen lines of code looking for a bug and not see what is in front of your nose?
That DAA in PASM uses variables "A" and "a". Well what's wrong with that? Nothing unless you forget that PASM is case insensitive and they are actually the same LONG. After having defined an "A" but forgotten to try and define an "a".
So I think we now have a working Z80 style DAA in ZiCog for the first time ever. Well it works in the SURVEY program. It still fails in the exerciser but that is, I hope, a failure of one of the other ops in that test batch.
Many thanks are due to PullMoll for this one.
Now the road is clear for all the other failing/missing ops.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Bahh! expletive, expletive, expletive. How long is it possible to stare at couple of dozen lines of code looking for a bug and not see what is in front of your nose?
That DAA in PASM uses variables "A" and "a". Well what's wrong with that? Nothing unless you forget that PASM is case insensitive and they are actually the same LONG. After having defined an "A" but forgotten to try and define an "a".
So I think we now have a working Z80 style DAA in ZiCog for the first time ever. Well it works in the SURVEY program. It still fails in the exerciser but that is, I hope, a failure of one of the other ops in that test batch.
Many thanks are due to PullMoll for this one.
Now the road is clear for all the other failing/missing ops.
LOL! Good one! I think I'm doing something similar silly with my code in the case of reading memory through HL (or even DE). It reads something, but not the RAM at the address... well, everyone has to carry his pack it seems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
You guys are going through tortuous loops trying to get everything in 1 prop when clearly 1 prop cannot do the job. Why don't you just go for the 2 prop solution and save yourself a virtually impossible and workable solution. There is no point if it is slower than a 4MHz Z80 is there ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
You *KNOW* I like multi-prop solutions [noparse]:)[/noparse]
I have to disagree with your statement that "clearly 1 prop cannot do the job". That is not yet proven, as a matter of fact, DracBlade, with a very latched design, and a single prop, runs at approx. 3.5MHz Z80 equivalent (if I remember right)
Actually even a 2MHz Z80 is useful for a lot of tasks...
Mind you, I can't wait to see how fast ZiCog will be on a Prop2 [noparse]:)[/noparse]
Cluso99 said...
You guys are going through tortuous loops trying to get everything in 1 prop when clearly 1 prop cannot do the job. Why don't you just go for the 2 prop solution and save yourself a virtually impossible and workable solution. There is no point if it is slower than a 4MHz Z80 is there ???
@Cluso re "Why don't you just go for the 2 prop solution"
Is this a windup? [noparse]:)[/noparse]
One prop is more than enough. I'm not sure how having two props helps with the zicog - do you split the zicog between two chips? Yikes.
I'm sure one prop is enough. It is a matter of smart solutions. eg - take a simple problem like all the data used for the font for the pocketerm vga object. How can you move this off into external ram? As far as I can tell, you can't use spin to move single bytes into a cog (right?). All you can do is move 2k of bytes into a cog all at once. So you can't load a bit of code and then poke in bytes for the font driver one at a time. But a cog can read bytes from hub one at a time. So it ought to be possible to put a tiny program into a cog that then loads in font bytes one at a time (a spin program is loading them one at a time off an sd card and you use a two byte system - data and flag) and then after the font bytes are loaded the program then goes and loads in the vga driver pasm code and fills up the cog, finally leaving just the little bit of code left that is doing the loading itself (which I don't think it can overwrite).
And there are other techniques too to free up hub ram - reading in cogs with data from an sd card that is fed through one 2k block in hub. Though much easier said than done as it involves rewriting each pasm object. How is that going BTW?
I see more cunning solutions as the answer to the memory problem. I did start coding this once - and I can guestimate about two weeks of coding to get the dracblade to use a lot less memory. One day I'll probably have to do this but not yet.
There are some simple changes too - eg any arrays in the code (eg the 128 byte dma buffer used in the dracblade) could recycle leftover cog space rather than taking up new space in hub ram.
Meanwhile, the issue is getting the rest of the Z80 opcodes done, and that is just a matter of tedious coding. My rate of coding is about an hour per opcode. I have no idea how heater wrote all those codes in the time he did.
I'm not sure speed is everything either. Wireless networking doesn't involve more speed - it involves new code. For raw speed, go for the SIMH on a PC with vb.net handling the I/O to the real world keyboard, display and serial ports.
The flugpost should hopefully deliver Juergen a board soon.
Guys, I'm pretty sure Cluso meant "COG" when he said "Prop". After all multiple Props is not going to speed things up. Personally I'm quite happy to farm out VT100 display and whatever to other Props. Although I like to see a one Prop CP/M machine.
Cluso is quite right to question the sanity of all this, after all he has contributed a great deal to the, err, insanity[noparse]:)[/noparse]
Here's my view of this:
1) It's for the challenge, we've come this far I'm not going to give up now. There is a set of tests in EXZ80DOC that are just crying out to PASS. It's like a crossword puzzle for me.
2) The base 8080 op codes work about as fast as they can, good enough for the intended purpose: to run CP/M, WordStar and the worlds first, and best C compiler for the Propeller, BDS C. [noparse][[/noparse]Note 1]
3) I don't much care if the Z80 extra ops are slower. I'm not aiming to create a Sinclair Spectrum or games machine.
4) It pains me to think of using a whole second 32 bit CPU just for those almost never used ops.
5) Prop II will run this quite fast enough when it comes.
Now if Cluso meant "Props", my apologies. That is a different debate on which I have no opinions much.
Dr_A "I have no idea how heater wrote all those codes in the time he did."
You are joking right?
The first 8080 for the Prop prototype was in Spin and took three or four days having never seen a Prop before.
BUT
Getting ZiCog to where it is today has take over two years! Through various versions of the old PropAltair. The four COG attempt. The ZiCog with Cluso's "smart dispatch table" idea and overlays. And now back to LMM. I can't count the number or rewrites.
Quite leisurely really. Look at the rate PullMoll has been churning out PASM !!
Note 1 - Based on the fact that it is currently the only C compiler that actually does the compiling on the Prop and produces the smallest code [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I mean 2 props. One for the Z80 emulation with SD and 512KB or sram. If only a single terminal is rquired then it all fits, no worries. BUT, if you require multiple I/O devices, then clearly a 2 prop solution clearly wins. It is easy to trap and send all Z80 I?O out to a second prop to handle.
IMHO, anything less than a 4mHz Z80 is inadequate.
I stand by my statement that the solution you guys are trying to implement is at least almost impossible and way beyond the design of the Prop I.
Don't bring the Prop II into it as it is still pie in the sky.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think it's neat to see a one Prop CP/M machine but really the issue of all those additional I/O devices and extra code is out of my scope. Application specific.
I think we are about up to the 4MHz Z80 speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes! We finally have that pesky Z80 DAA instruction well and truly beaten.
From the output of EXZ80DOC:
<daa,cpl,scf,ccf>.............( 65,536) cycles OK
Now who would have imagined that the complement carry instruction CCF (also tested here) would have copied the old value of the carry flag into the auxiliary (half) carry flag? Those Z80 designers were barking mad and it makes one appreciate the glorious regularity of the Propeller instruction set.
Thanks again Pullmoll.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes! We finally have that pesky Z80 DAA instruction well and truly beaten.
From the output of EXZ80DOC:
<daa,cpl,scf,ccf>.............( 65,536) cycles OK
Now who would have imagined that the complement carry instruction CCF (also tested here) would have copied the old value of the carry flag into the auxiliary (half) carry flag? Those Z80 designers were barking mad and it makes one appreciate the glorious regularity of the Propeller instruction set.
Thanks again Pullmoll.
I could have told you that - or the MAME source code z80.c for that matter
There are more flags oddities to come in the ED xx opcodes, beware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm not going to raid the MAME code for fear of weird licensing issues. From the MAME license:
"Redistributions may not be sold, nor may they be used in a commercial product or activity. "
and
"Using MAME as a "freebie" or including it at "no cost" with your product still constitutes commercial usage and is forbidden"
Given that a PASM version of whatever in C could be construed as a derived work, that is a restriction we don't want to be lumbered with.
However as you are the author and copyright holder of the MAME z80.c and you have posted the DAA code snippet from it here together with the PASM translation for use in ZiCog I take that as permission to do whatever with it[noparse]:)[/noparse]
Perhaps I worry too much about these things.
I had previously peeked at the DAA code in AltairZ80, blech, your version is much nicer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not going to raid the MAME code for fear of weird licensing issues. From the MAME license:
"Redistributions may not be sold, nor may they be used in a commercial product or activity. "
and
"Using MAME as a "freebie" or including it at "no cost" with your product still constitutes commercial usage and is forbidden"
Given that a PASM version of whatever in C could be construed as a derived work, that is a restriction we don't want to be lumbered with.
However as you are the author and copyright holder of the MAME z80.c and you have posted the DAA code snippet from it here together with the PASM translation for use in ZiCog I take that as permission to do whatever with it[noparse]:)[/noparse]
Perhaps I worry too much about these things.
I had previously peeked at the DAA code in AltairZ80, blech, your version is much nicer.
Well, the MAME license.. *sigh* It's intention was to prevent ripoffs of our joint efforts, while it does actually hinder widespread use of all our findings for no reason. And MAME code has been and is ripped in various ways by everyone and his dog. Since I wrote the Z80 core (most of it, that is.. it has been patched a lot) I opted for a dual license at the user's will. If you want, you can take the code for your GPLed project and continue under the GPL rules with it. You are just asked to be so kind to let improvements go back to us MAMEdev weirdos also
If you ask me, MAME as a whole should have been placed under the GPL, but this is a minority stance among the developers.
Anyway, you don't have to worry about taking Z80 code from the source. I have meanwhile written dozens of them, ranging from 8086 asm over 80386 asm, Java, plain C, microcode correct compiled language... I curious when I will write the final implementation of that beast.
BTW The EXZ80ALL.COM is too large by 651 longs to fit in hub RAM now :-(
It's about time to open the drawer with the used chips and search for some SRAM chip...
Hah! P5164SL-10 that should be a 64Kx8 SRAM, probably 100ns.
Darn, no. Some searching tells me its 64Kbit, so 8Kx8 and that doesn't help me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Odd, I was just reading that the early MAME was under the GPL and changed for some unknown reason.
There is no license on ZiCog as yet. Around here people like the MIT license as that is what is needed to get stuff into the OBEX. So I should really slap that on ZiCog also.
>> "I curious when I will write the final implementation of that beast."
What, there is no cure for this disease?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well done heater. I remember you have been going on about DAA for how long, a year now??
Dare I mention (in a very tiny voice) that I've never used this instruction in assembly?
*runs away and hides behind a big rock*
Ok, it probably does come up in compiled versions of higher level languages. Well done on cracking this one.
As an aside, I see lots of bytes to save in the Dracblade. Arrays of 512 bytes for instance for the disk I/O. If that can be placed in front of a DAT bit of cog code, that can save lots of memory. It isn't that simple though, because whatever object you choose has to somehow be 'merged' into the main code, and that involves going through and changing the names of any variables that happen to have the same name. Possible, but tedious.
However, that can save buff[noparse][[/noparse]256] and disk_buff[noparse][[/noparse]512] which would free up a lot of space for extra opcodes.
Re Cluso's comments, well for me the Dracblade is plenty fast enough. It 'feels' just fractionally slower than a 4Mhz N8VEM running a ramdisk, and indeed, on the N8VEM I ran most of my boards at 3.5Mhz because the xtals were cheaper, even though the Z80 chips were either 6 or 8Mhz. Propellers are expensive here in Australia ($25 for the prop plus eeprom plus xtal) so I'd rather have two seperate boards than one board with two chips. I think I can do more clever things with two boards than one board with two propellers. But - horses for courses, and the great thing about the zicog is that it can run on a wide variety of hardware. Choose the best board for the problem you want to solve!
Re Juergen "BTW The EXZ80ALL.COM is too large by 651 longs to fit in hub RAM now :-("
Wait till the board arrives! Then you will have plenty of room.
The main problem with the exz80all program is that on both the Dracblade and Cluso's ramblade, it takes all night to run the tests. So debugging is fairly slow using this tool.
As an aside, speaking of MAME copyright, all Dracblade code/board design/schematics are free to copy and nothing is copyright. I get all the thanks I need when people like Toby go and iron the design on to a homemade PCB!
Oh, and Juergen, you will need 55ns sram if you want decent speed. Was it "the great" Cluso that found the 512k chip from future electronics for $3? So my enormous pile of 8k ram chips remains obsolete and unused, as, I think, does heater's.
Re Juergen "I have meanwhile written dozens of them..." This is why I sent you a free board *grin*. I'm excited by what you will be able to do once you have CP/M running on a Zicog, with all the proper diagnostic programs like DDT and DDTZ.
Yep the DAA struggle has been long and hard. I take comfort in the fact every Z80 emulator I have come across has had bugs posted against DAA or it figures prominently in their change history.
The only program I know that uses it it SURVEY. I suspect compilers never use it. Compilers like simple stuff.
If you want to reuse the DAT space where some objects PASM lives before it is loaded to COG do not do any "merging into the main code" or "label changing".
All you need to do is this:
1) Add a small Spin method to object that has recyclable DAT space. This new method simply returns the address of the start of the DAT section.
2) Call that method from your main code and save the address returned.
3) Start the COG of whatever object it is.
4) Now you can use the memory from the address you have saved for disk buffers or whatever. Be sure not to use too much!
This is a crude hack for memory management but might get you by for a while.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dr_Acula said...
Oh, and Juergen, you will need 55ns sram if you want decent speed. Was it "the great" Cluso that found the 512k chip from future electronics for $3?
What's the name of that chip? I'd be interested to see the prices here in Germany - if it is at all available here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I've used DAA a bit on a real Z80, only really in RTC routines though. It's handy when you do have to deal with BCD arithmetic but seems like that's not very often. I've also seen it used in a fairly neat 8bit binary to BCD conversion loop. I noticed the other day looking at a PIC data sheet that the 18F series have a DAW instruction which does the same thing as the 8080 version I think so must still be useful to someone I guess.
3) I don't much care if the Z80 extra ops are slower. I'm not aiming to create a Sinclair Spectrum or games machine.
I want to try it. Do you think that it can be done·on TriBlade?
Beware, DAA instruction is used in many programs, like Turbo Pascal. Without it, many programs will have strange behaviour.
If you want to see some tests for correct Z80 implementation, and reference implementation of Z80 core that passes these tests go to sourceforge.net and look for project fuse-emulator. It's GPL and it emulates most of undocumented instructions and F reg behaviour.
The big problem with trying to emulate the Spectrum is the ULA. There was a massive amount of 'stuff' in there that affected how the screen worked and was involved in keyboard trapping etc. I've done some work with a real Spectrum and the odd bus behaviour can cause some headaches.
A possibility would be to re-write sections of the ROM to handle graphics and keyboard differently, I managed to re-write the tape routines to load/save to a USB key using an FTDI Vinculum chip and the ROM code is readily available and well documented. The problem you then get is when bits of custom assembly code in games directly interface with the hardware (e.g. to implement non-standard load/save routines for copy protection), because of the low power writing your own bits of assembly rather than calling ROM functions was not uncommon.
If you're interested in what was in the Spectrum there's no better place than www.worldofspectrum.org/.
Comments
But loading PASM code from external RAM is going to be (much) slower than from hub RAM. This somehow defeats the intent of a recompiling emulator
Right now my code generates 21288 longs (including the Debug_1pinTV driver) and there are still all EDxx opcodes and all DDCB/FDCB opcodes missing...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
He already did. It's called MAME mamedev.org/.
hdsk_dpb_ptr := @hdsk_dpb
seems quite reasonable at the moment, perhaps forever if you have no need of RAM disks or floppy sized images.
Hmmm... sending batch files via wireless for execution on the remote end....I think you are about to enable the possibility of the worlds first wirelessly transmitted CP/M virus/worm [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
yes, we worked that out I think. About 20x slower.
But on the other hand, you would only put the unusual commands in external ram. like LD SP,IX
The more common ones would live in hub ram.
Re "the worlds first wirelessly transmitted CP/M virus/worm"
but this guy says that can't happen!! www.oualline.com/practical.programmer/cpm.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/8/2010 12:39:05 PM GMT
Your CP/M does have a network and it's a network with free access over the airwaves. BATCH file worms here we come !
Nice comparisons he makes though[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks for that link. Interesting reading and it makes some valid points as well as cautioning us about taking comparisons and performance testing too literally.
As someone who ran a business on a dual floppy 64K CPM system for several years I must say that having computers with several orders of magnitude improvement in speed, memory, storage, and communications capability has not made anywhere near a similar improvement in running a business. With the exception of the improvements due to the internet and e-mail I could just as easily use a 2MHz Z80 and CPM to do what I now do on a 2.6GHz dual processor system with 2GB of memory.
That DAA in PASM uses variables "A" and "a". Well what's wrong with that? Nothing unless you forget that PASM is case insensitive and they are actually the same LONG. After having defined an "A" but forgotten to try and define an "a".
So I think we now have a working Z80 style DAA in ZiCog for the first time ever. Well it works in the SURVEY program. It still fails in the exerciser but that is, I hope, a failure of one of the other ops in that test batch.
Many thanks are due to PullMoll for this one.
Now the road is clear for all the other failing/missing ops.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
LOL! Good one! I think I'm doing something similar silly with my code in the case of reading memory through HL (or even DE). It reads something, but not the RAM at the address... well, everyone has to carry his pack it seems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
You *KNOW* I like multi-prop solutions [noparse]:)[/noparse]
I have to disagree with your statement that "clearly 1 prop cannot do the job". That is not yet proven, as a matter of fact, DracBlade, with a very latched design, and a single prop, runs at approx. 3.5MHz Z80 equivalent (if I remember right)
Actually even a 2MHz Z80 is useful for a lot of tasks...
Mind you, I can't wait to see how fast ZiCog will be on a Prop2 [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Is this a windup? [noparse]:)[/noparse]
One prop is more than enough. I'm not sure how having two props helps with the zicog - do you split the zicog between two chips? Yikes.
I'm sure one prop is enough. It is a matter of smart solutions. eg - take a simple problem like all the data used for the font for the pocketerm vga object. How can you move this off into external ram? As far as I can tell, you can't use spin to move single bytes into a cog (right?). All you can do is move 2k of bytes into a cog all at once. So you can't load a bit of code and then poke in bytes for the font driver one at a time. But a cog can read bytes from hub one at a time. So it ought to be possible to put a tiny program into a cog that then loads in font bytes one at a time (a spin program is loading them one at a time off an sd card and you use a two byte system - data and flag) and then after the font bytes are loaded the program then goes and loads in the vga driver pasm code and fills up the cog, finally leaving just the little bit of code left that is doing the loading itself (which I don't think it can overwrite).
And there are other techniques too to free up hub ram - reading in cogs with data from an sd card that is fed through one 2k block in hub. Though much easier said than done as it involves rewriting each pasm object. How is that going BTW?
I see more cunning solutions as the answer to the memory problem. I did start coding this once - and I can guestimate about two weeks of coding to get the dracblade to use a lot less memory. One day I'll probably have to do this but not yet.
There are some simple changes too - eg any arrays in the code (eg the 128 byte dma buffer used in the dracblade) could recycle leftover cog space rather than taking up new space in hub ram.
Meanwhile, the issue is getting the rest of the Z80 opcodes done, and that is just a matter of tedious coding. My rate of coding is about an hour per opcode. I have no idea how heater wrote all those codes in the time he did.
I'm not sure speed is everything either. Wireless networking doesn't involve more speed - it involves new code. For raw speed, go for the SIMH on a PC with vb.net handling the I/O to the real world keyboard, display and serial ports.
The flugpost should hopefully deliver Juergen a board soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Cluso is quite right to question the sanity of all this, after all he has contributed a great deal to the, err, insanity[noparse]:)[/noparse]
Here's my view of this:
1) It's for the challenge, we've come this far I'm not going to give up now. There is a set of tests in EXZ80DOC that are just crying out to PASS. It's like a crossword puzzle for me.
2) The base 8080 op codes work about as fast as they can, good enough for the intended purpose: to run CP/M, WordStar and the worlds first, and best C compiler for the Propeller, BDS C. [noparse][[/noparse]Note 1]
3) I don't much care if the Z80 extra ops are slower. I'm not aiming to create a Sinclair Spectrum or games machine.
4) It pains me to think of using a whole second 32 bit CPU just for those almost never used ops.
5) Prop II will run this quite fast enough when it comes.
Now if Cluso meant "Props", my apologies. That is a different debate on which I have no opinions much.
Dr_A "I have no idea how heater wrote all those codes in the time he did."
You are joking right?
The first 8080 for the Prop prototype was in Spin and took three or four days having never seen a Prop before.
BUT
Getting ZiCog to where it is today has take over two years! Through various versions of the old PropAltair. The four COG attempt. The ZiCog with Cluso's "smart dispatch table" idea and overlays. And now back to LMM. I can't count the number or rewrites.
Quite leisurely really. Look at the rate PullMoll has been churning out PASM !!
Note 1 - Based on the fact that it is currently the only C compiler that actually does the compiling on the Prop and produces the smallest code [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
IMHO, anything less than a 4mHz Z80 is inadequate.
I stand by my statement that the solution you guys are trying to implement is at least almost impossible and way beyond the design of the Prop I.
Don't bring the Prop II into it as it is still pie in the sky.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I think it's neat to see a one Prop CP/M machine but really the issue of all those additional I/O devices and extra code is out of my scope. Application specific.
I think we are about up to the 4MHz Z80 speed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes! We finally have that pesky Z80 DAA instruction well and truly beaten.
From the output of EXZ80DOC:
Now who would have imagined that the complement carry instruction CCF (also tested here) would have copied the old value of the carry flag into the auxiliary (half) carry flag? Those Z80 designers were barking mad and it makes one appreciate the glorious regularity of the Propeller instruction set.
Thanks again Pullmoll.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I could have told you that - or the MAME source code z80.c for that matter
There are more flags oddities to come in the ED xx opcodes, beware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm not going to raid the MAME code for fear of weird licensing issues. From the MAME license:
"Redistributions may not be sold, nor may they be used in a commercial product or activity. "
and
"Using MAME as a "freebie" or including it at "no cost" with your product still constitutes commercial usage and is forbidden"
Given that a PASM version of whatever in C could be construed as a derived work, that is a restriction we don't want to be lumbered with.
However as you are the author and copyright holder of the MAME z80.c and you have posted the DAA code snippet from it here together with the PASM translation for use in ZiCog I take that as permission to do whatever with it[noparse]:)[/noparse]
Perhaps I worry too much about these things.
I had previously peeked at the DAA code in AltairZ80, blech, your version is much nicer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, the MAME license.. *sigh* It's intention was to prevent ripoffs of our joint efforts, while it does actually hinder widespread use of all our findings for no reason. And MAME code has been and is ripped in various ways by everyone and his dog. Since I wrote the Z80 core (most of it, that is.. it has been patched a lot) I opted for a dual license at the user's will. If you want, you can take the code for your GPLed project and continue under the GPL rules with it. You are just asked to be so kind to let improvements go back to us MAMEdev weirdos also
If you ask me, MAME as a whole should have been placed under the GPL, but this is a minority stance among the developers.
Anyway, you don't have to worry about taking Z80 code from the source. I have meanwhile written dozens of them, ranging from 8086 asm over 80386 asm, Java, plain C, microcode correct compiled language... I curious when I will write the final implementation of that beast.
BTW The EXZ80ALL.COM is too large by 651 longs to fit in hub RAM now :-(
It's about time to open the drawer with the used chips and search for some SRAM chip...
Hah! P5164SL-10 that should be a 64Kx8 SRAM, probably 100ns.
Darn, no. Some searching tells me its 64Kbit, so 8Kx8 and that doesn't help me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/9/2010 11:31:15 AM GMT
There is no license on ZiCog as yet. Around here people like the MIT license as that is what is needed to get stuff into the OBEX. So I should really slap that on ZiCog also.
>> "I curious when I will write the final implementation of that beast."
What, there is no cure for this disease?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dare I mention (in a very tiny voice) that I've never used this instruction in assembly?
*runs away and hides behind a big rock*
Ok, it probably does come up in compiled versions of higher level languages. Well done on cracking this one.
As an aside, I see lots of bytes to save in the Dracblade. Arrays of 512 bytes for instance for the disk I/O. If that can be placed in front of a DAT bit of cog code, that can save lots of memory. It isn't that simple though, because whatever object you choose has to somehow be 'merged' into the main code, and that involves going through and changing the names of any variables that happen to have the same name. Possible, but tedious.
However, that can save buff[noparse][[/noparse]256] and disk_buff[noparse][[/noparse]512] which would free up a lot of space for extra opcodes.
Re Cluso's comments, well for me the Dracblade is plenty fast enough. It 'feels' just fractionally slower than a 4Mhz N8VEM running a ramdisk, and indeed, on the N8VEM I ran most of my boards at 3.5Mhz because the xtals were cheaper, even though the Z80 chips were either 6 or 8Mhz. Propellers are expensive here in Australia ($25 for the prop plus eeprom plus xtal) so I'd rather have two seperate boards than one board with two chips. I think I can do more clever things with two boards than one board with two propellers. But - horses for courses, and the great thing about the zicog is that it can run on a wide variety of hardware. Choose the best board for the problem you want to solve!
Re Juergen "BTW The EXZ80ALL.COM is too large by 651 longs to fit in hub RAM now :-("
Wait till the board arrives! Then you will have plenty of room.
The main problem with the exz80all program is that on both the Dracblade and Cluso's ramblade, it takes all night to run the tests. So debugging is fairly slow using this tool.
As an aside, speaking of MAME copyright, all Dracblade code/board design/schematics are free to copy and nothing is copyright. I get all the thanks I need when people like Toby go and iron the design on to a homemade PCB!
Oh, and Juergen, you will need 55ns sram if you want decent speed. Was it "the great" Cluso that found the 512k chip from future electronics for $3? So my enormous pile of 8k ram chips remains obsolete and unused, as, I think, does heater's.
Re Juergen "I have meanwhile written dozens of them..." This is why I sent you a free board *grin*. I'm excited by what you will be able to do once you have CP/M running on a Zicog, with all the proper diagnostic programs like DDT and DDTZ.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The only program I know that uses it it SURVEY. I suspect compilers never use it. Compilers like simple stuff.
If you want to reuse the DAT space where some objects PASM lives before it is loaded to COG do not do any "merging into the main code" or "label changing".
All you need to do is this:
1) Add a small Spin method to object that has recyclable DAT space. This new method simply returns the address of the start of the DAT section.
2) Call that method from your main code and save the address returned.
3) Start the COG of whatever object it is.
4) Now you can use the memory from the address you have saved for disk buffers or whatever. Be sure not to use too much!
This is a crude hack for memory management but might get you by for a while.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What's the name of that chip? I'd be interested to see the prices here in Germany - if it is at all available here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
It is the·AS6C4008-55
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Almost every Z80 debugger uses it to convert to hex. Here's a sample:
hex ld a,h call hex2 ld a,l hex2 push af rra rra rra rra call hex1 pop af hex1 or 0F0h daa add a,A0h adc a,40h ld (de),a inc de ret▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
That part is around 4,50 Euro here for 5 pieces. This is a little over US$6. Still okay for that amount of RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Beware, DAA instruction is used in many programs, like Turbo Pascal. Without it, many programs will have strange behaviour.
If you want to see some tests for correct Z80 implementation, and reference implementation of Z80 core that passes these tests go to sourceforge.net and look for project fuse-emulator. It's GPL and it emulates most of undocumented instructions and F reg behaviour.
·
I think we have DAA licked now.
Thanks for the fuse-emulator link.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have just notice that this tread is trundling up nicely, to 1000 posts. Just a page and a bit.
(do you think a Spectrum will be announced on that page ???? )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A possibility would be to re-write sections of the ROM to handle graphics and keyboard differently, I managed to re-write the tape routines to load/save to a USB key using an FTDI Vinculum chip and the ROM code is readily available and well documented. The problem you then get is when bits of custom assembly code in games directly interface with the hardware (e.g. to implement non-standard load/save routines for copy protection), because of the low power writing your own bits of assembly rather than calling ROM functions was not uncommon.
If you're interested in what was in the Spectrum there's no better place than www.worldofspectrum.org/.