heater said...
Hmmm... I was overjoyed just to get an LED to flash with my first couple of lines of PASM.
I always start with something like implementing Conway's life. Fun to look at for hours once it runs. I remember doing this on my first Z80. Must've been in 1980... *blafasel*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The board you are waiting for shows P13-15 used for the Composite vid out the resistors will have to be left off for DracBlade, this is where the SD card goes. Or were you going to do Heaters 24KB CP/M on DemoBoard mode.
As Heater says, WOW so much code with no test bed !!!. I am waiting for the printer police to go to lunch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The board you are waiting for shows P13-15 used for the Composite vid out the resistors will have to be left off for DracBlade, this is where the SD card goes. Or were you going to do Heaters 24KB CP/M on DemoBoard mode.
Yes, I first wanted to practice some low memory space things before I get overwhelmed by mega bytes of RAM [noparse]:)[/noparse]
Toby Seckshund said...
As Heater says, WOW so much code with no test bed !!!. I am waiting for the printer police to go to lunch.
It may seem like WOW. You know, I've been dealing with dozens of CPU and uC types, that's why it didn't take more than a few days to grok the Prop. And that's the reason why I was very impressed by its design quickly after reading the first few details. The Propeller is for uCs what the ARM is for CPUs in my opinion, and the Propeller 2 is certainly going to break all kinds of records.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
My copy is wearing out! See photo. Book, nice stable blue screen and 4 Dracblades as part of the crazy wireless network setup.
Mine will wear out when I die, because it's in my head No, I actually have the book laying around somewhere.
For the details that Zak doesn't cover, there has been a site www.z80.org which had all kinds of undocumented behaviour of the Z80s (yes, there are differences between various manufacturer's chips!) described. Unfortunately it seems this site is gone :-/ I think archive.org should have collected most of the info that has been there.
This makes me think: what happens should the parallax.com forum crash/disappear? All projects gone? There ought to be a backup repository or even a CVS or SVN server for projects. No, not sourceforge, a server dedicated to the Propeller.
Attached is a photo of my place. The only propeller I have here is on the fan on the ceiling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm not sure what you mean by "...get anywhere near a correct Z80 flags handling"
We can easily check if that ADD/SUB flag is set correctly for the opcodes you have listed.
As it stands we have 95% of Z80 ops in place. There are only a few tests of the many in our exerciser that fail. It checks flags against those observed for millions of test cases on a real Z80.
Admittedly ZiCog does not pay attention to flags or instructions that were undocumented by Zilog.
Specifically the half index register ops but I think we can deal with them in LMM easily.
I'm not inclined to worry about any undocumented flags if it means adding code that slows down core 8080 functionality.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater, I've tried a couple of times to delete ddcb code but this bit depends on that bit depends on something else, and it is not nearly as simple as deleting a few lines. At one stage I had every bit of code that dealt with IX and IY commented out. Have had to put them all back in again - there are too many dependencies so for the moment I'll live with code that fits exactly. In any case I think this could be heading in an entirely new direction with Juergen's code.
heater said...
I'm not sure what you mean by "...get anywhere near a correct Z80 flags handling"
We can easily check if that ADD/SUB flag is set correctly for the opcodes you have listed.
I meant including the undocumented flags X and Y and the oddities of the EDxx opcodes, specificially the I and R registers access effects on the flags, the counting of R as such etc. pp.
heater said...
As it stands we have 95% of Z80 ops in place. There are only a few tests of the many in our exerciser that fail. It checks flags against those observed for millions of test cases on a real Z80.
Yeah, I see you are aiming at compliance to the documented Z80.
heater said...
Admittedly ZiCog does not pay attention to flags or instructions that were undocumented by Zilog.
Specifically the half index register ops but I think we can deal with them in LMM easily.
I agree.
heater said...
I'm not inclined to worry about any undocumented flags if it means adding code that slows down core 8080 functionality.
But the Prop2 is on its way
Ok, I understand that the main goal for ZiCog is to be compatible enough to run all kinds of CP/M programs without a flaw. And that's probably sufficient for 99% of the people that will be using it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
In any case I think this could be heading in an entirely new direction with Juergen's code.
Don't be more optimistic than I am. I'm seeing the cog RAM shrinking away too fast, or alternatively the hub RAM for code that is repeated over and over again. It may well be that a recompiling Z80 core is impossible to fit in 32K in its entirety, unless I find a clever way to not repeat code like the alu ops over and over and also not waste kernel space with it. Regardless if my attempt succeeds or fails I'll be helping out with heater's ZiCog where I can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Even if it won't fit in 32k, we still have external ram. 512k ram chips are $3 and because CP/M only uses 64k, most of the boards using Zicog have a lot of free ram. Of course, this is slow, as it takes many pasm instructions to get bytes in and out. But on the other hand, if you only have infrequently used instructions in external ram, and/or you only bring instructions into hub/cog ram once but you use that code many times, then the time delay is less of a problem. Plus the code to move bytes in and out of external memory already reside in the Zicog (in various forms depending on the hardware).
Having said that, the zicog is already highly optimised with common Z80 instructions only taking a few pasm instructions to emulate, and less common ones in overlays.
I just made a new copy of ziCog and zicog_cpm with a view to hacking out all the overlays stuff and turning them into LMM code. In future the demo board is not supported for CP/M (There will be a non-CP/M Z80 demo there) so I hacked out all PropDemoBoard codes.
Just now it's running through the EX test on a TriBlade just to make sure I did not break anything along the way. It's fine, now I can start converting to LMM.
But what's this? I have 61 LONGS free in the zicog COG !!!
How come you guys are scabbling about for LONGs so hard ?
Anyway this is good news as I can add an LMM Virtual Machine and start experimenting with LMM versions of overlaid code without breaking the whole thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
But what's this? I have 61 LONGS free in the zicog COG !!!
ALS - anxious longs syndrome. Some longs hide from the coder because they fear to get $DEADBEEF
heater said...
How come you guys are scabbling about for LONGs so hard ?
Hey, YOU said that memory was tight...
heater said...
Anyway this is good news as I can add an LMM Virtual Machine and start experimenting with LMM versions of overlaid code without breaking the whole thing.
Great news! I'm sure using LMM will make things a lot easier in the end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Well you are the author, you have the history of what was going on as all those words were layed down.
Anyway, yippeee, 60+ longs will be so useful. I never went into the memory driver bits until recently, with DracBlade and so hadn't realized just how tight it all was ( leave alone the 9 bit literal thing )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Sorry. It's a confusion on my part regarding #defines.
If you hit F8 in the to level zicog_cpm.spin all the defines there are in effect but if you hit F8 in zicog.spin then CPU_Z80 is not defined there and the 8080 only code is much smaller. Duhhh.
The correct answer in my TriBlade case is 13 free LONGs.
However that is still enough to proceed with LMM experiments without breaking everything at once [noparse]:)[/noparse]
Note: Must remember to put the defines back in the project configuration in BST.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just a hint while I'm writing down my list of opcodes: There is no such thing as an invalid DDxx or FDxx instruction. The Z80 actually executes the invalid opcode as if it was not prefixed for the opcodes that do not have H, L, or HL in them. Also, multiple DD or FD prefixes are possible and it's the latest that counts for the instruction.
HTH,
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Pulloll: We have to speak on this DD, FD prefix topic some more.
It has always occurred to me that we should be able to dispense with the DD and FD dispatch tables and combine them into the main dispatch table. Well actually there there is only a combined DDFD table now. I've always assumed that the Z80 just had flags somewhere that select HL, IX or IY when a prefix is encountered and then runs through much the same 8080 logic but using the IX or IY regs instead. Are they the mysterious undocumented bits in the flags byte?
Combing those tables would save 256 LONGs in HUB which would make Dr_A happy.
However I'm loath to put extra code in the 8080 "critical path" that does this index reg selection. Perhaps there is a fast way to do it. I have not looked so hard. Let's remember to discuss this later when I have my LMM in place.
We could fill in the ddfd table with valid 8080 ops where there are currently "undocumented"
Multiple prefixes should be handled easily as well.
Reminds me of the time way back when I discovered you could put a "32 bit" prefix byte in front of 80386 instructions, even when it is operating in 16 bit real mode. Having 32 bit arithmetic under MSDOS was a hoot.
By the way, I have just put in an LMM loop and replaced the overlay for the OUT instruction with LMM. Works a treat!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well it doesn't take much to get me excited about more memory so the comment about DD FD table means I've gone and commented this out for the moment. It is saving me a whole lot of hub longs, and with those I've been able to transfer some of the networking code from discrete CP/M programs into Spin. I can see the beginnings of a CP/M network. I've got three boards all with wireless tranceivers. The PC is off and not part of this network (though it can be if you want). Any board can find out who is nearby (#WHO command) and any board can link with any other board and do file transfers, or even run Mbasic or Wordstar remotely. This is the amazing thing about the propeller - you just can't do this with standard CP/M machines as you need buffers and two asynchronous serial ports. I used the spare memory to add things like random time delays when a WHO command is received so all boards don't reply at once.
So I run this little sbasic program
A>net
Welcome to CP/M networking for the Propeller
My name is GAMMA
1 - Send file to peer
2 - Receive file from peer
3 - Talk to peer
4 - Talk to server
5 - Send a test packet
6 - WHO - search for peers
7 - WHO - search for servers
9 - Logoff
Enter your choice: 6
Listening for peers - please wait 10 seconds for all peers to reply
#WHO
BETA DELTA
Finish listening
#OFF
A>
And then I know that BETA and DELTA are within range, so then I can use option 3 and choose the board and talk to it. Or send or receive a file. Links are disconnected when you hit ESC or if there is no activity for 3 minutes.
Max range is 3km.
So.... I do hope all these new zicog experiments don't take up too much hub ram!!
heater said...
Pulloll: We have to speak on this DD, FD prefix topic some more.
It has always occurred to me that we should be able to dispense with the DD and FD dispatch tables and combine them into the main dispatch table. Well actually there there is only a combined DDFD table now. I've always assumed that the Z80 just had flags somewhere that select HL, IX or IY when a prefix is encountered and then runs through much the same 8080 logic but using the IX or IY regs instead. Are they the mysterious undocumented bits in the flags byte?
No, definitely not. But you are probably right that the Z80 uses a way to index either HL (normal opcodes) or IX or IY and then executes the normal opcode's microcode. This is most probably also the reason why the undocumented half IX/IY registers exist. It's a side effect of remapping HL to IX or IY. OTOH there are opcodes where H or L is used in combination with IX or IY. Think of ld l,(ix+offs), so the remapping of the registers is somewhat more complex... It seems to depend on opcode bits 2..0 being = 6, i.e. the memory slot of the 8 registers with 8 bits.
heater said...
Combing those tables would save 256 LONGs in HUB which would make Dr_A happy.
However I'm loath to put extra code in the 8080 "critical path" that does this index reg selection. Perhaps there is a fast way to do it. I have not looked so hard. Let's remember to discuss this later when I have my LMM in place.
Yes, this should be possible somehow, but it's not easy to accomplish for abovementioned reason.
heater said...
We could fill in the ddfd table with valid 8080 ops where there are currently "undocumented"
Multiple prefixes should be handled easily as well.
That's what I meant. Just execute the same things as in the 00 table for undocumented entries.
heater said...
Reminds me of the time way back when I discovered you could put a "32 bit" prefix byte in front of 80386 instructions, even when it is operating in 16 bit real mode. Having 32 bit arithmetic under MSDOS was a hoot.
By the way, I have just put in an LMM loop and replaced the overlay for the OUT instruction with LMM. Works a treat!
Great! Even though I can't follow your development without a Prop, I'm eager to see the LMM stuff as a workaround for the space problems.
My PropRPM still isn't here, and it's probably not going to arrive today anymore :-( It looks like I have to run one of the Prop emulators. Do you know if they work well enough to play with?
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_A: You should not need to comment out any tables. They are surrounded #ifdef CPU_Z80.
So if you use #define CPU_8080 instead it should have the same effect.
Unless you are using some Z80 opcodes in an otherwise broken Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re "Unless you are using some Z80 opcodes in an otherwise broken Z80."
Yes, that is what I'm doing. I've got a few of my favourites in some assembly programs eg DJNZ. But almost everything is 8080 - eg all the compiled higher level languages. So I am following this discussion closely especially the tradeoff between slightly slower 8080 vs smaller Z80.
Pullmoll: Actually it was when I discovered the half index register instructions that first realized the similarity of these tables and how they just use different 16 bit regs.
Looks like the ddfd table might be staying, unless someone comes up with a fast way of handling things.
I have played with Gear and what was it, PropEmu?, but I had no luck using them on complicated multi COG code and gave up the idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That'd be great! If you think you can do, just PM me for my postal mail address.
TIA,
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The N flag is actually documented. It's described in Rodnay Zak's Z80 book, i.e. the bible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The board you are waiting for shows P13-15 used for the Composite vid out the resistors will have to be left off for DracBlade, this is where the SD card goes. Or were you going to do Heaters 24KB CP/M on DemoBoard mode.
As Heater says, WOW so much code with no test bed !!!. I am waiting for the printer police to go to lunch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
When I say documented I'm mean as in the original Z80 manuals and data sheets from Zilog.
Which raises the point that for DAA to work correctly that flag has to be set correctly every place else.
Conway's life - Me to, on a TRS-80 clone.
The DracBlade is a wonderful thing. It's big. All DIP chips so you can see what you are doing !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I first wanted to practice some low memory space things before I get overwhelmed by mega bytes of RAM [noparse]:)[/noparse]
It may seem like WOW. You know, I've been dealing with dozens of CPU and uC types, that's why it didn't take more than a few days to grok the Prop. And that's the reason why I was very impressed by its design quickly after reading the first few details. The Propeller is for uCs what the ARM is for CPUs in my opinion, and the Propeller 2 is certainly going to break all kinds of records.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
My copy is wearing out! See photo. Book, nice stable blue screen and 4 Dracblades as part of the crazy wireless network setup.
Juergen - please send me a personal message with your address and I'll send you one of those boards for free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
ADD, ADC, INC and all of the alu logic opcodes (AND, OR ...)
The opcodes setting it are:
SUB, SBC, DEC, CMP
It looks you will have to go with LMM anyway to get anywhere near a correct Z80 flags handling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Mine will wear out when I die, because it's in my head
For the details that Zak doesn't cover, there has been a site www.z80.org which had all kinds of undocumented behaviour of the Z80s (yes, there are differences between various manufacturer's chips!) described. Unfortunately it seems this site is gone :-/ I think archive.org should have collected most of the info that has been there.
This makes me think: what happens should the parallax.com forum crash/disappear? All projects gone? There ought to be a backup repository or even a CVS or SVN server for projects. No, not sourceforge, a server dedicated to the Propeller.
Attached is a photo of my place. The only propeller I have here is on the fan on the ceiling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/5/2010 12:09:13 PM GMT
We can easily check if that ADD/SUB flag is set correctly for the opcodes you have listed.
As it stands we have 95% of Z80 ops in place. There are only a few tests of the many in our exerciser that fail. It checks flags against those observed for millions of test cases on a real Z80.
Admittedly ZiCog does not pay attention to flags or instructions that were undocumented by Zilog.
Specifically the half index register ops but I think we can deal with them in LMM easily.
I'm not inclined to worry about any undocumented flags if it means adding code that slows down core 8080 functionality.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I meant including the undocumented flags X and Y and the oddities of the EDxx opcodes, specificially the I and R registers access effects on the flags, the counting of R as such etc. pp.
Yeah, I see you are aiming at compliance to the documented Z80.
I agree.
But the Prop2 is on its way
Ok, I understand that the main goal for ZiCog is to be compatible enough to run all kinds of CP/M programs without a flaw. And that's probably sufficient for 99% of the people that will be using it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Don't be more optimistic than I am. I'm seeing the cog RAM shrinking away too fast, or alternatively the hub RAM for code that is repeated over and over again. It may well be that a recompiling Z80 core is impossible to fit in 32K in its entirety, unless I find a clever way to not repeat code like the alu ops over and over and also not waste kernel space with it. Regardless if my attempt succeeds or fails I'll be helping out with heater's ZiCog where I can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/5/2010 12:52:13 PM GMT
Having said that, the zicog is already highly optimised with common Z80 instructions only taking a few pasm instructions to emulate, and less common ones in overlays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/5/2010 11:07:50 PM GMT
I just made a new copy of ziCog and zicog_cpm with a view to hacking out all the overlays stuff and turning them into LMM code. In future the demo board is not supported for CP/M (There will be a non-CP/M Z80 demo there) so I hacked out all PropDemoBoard codes.
Just now it's running through the EX test on a TriBlade just to make sure I did not break anything along the way. It's fine, now I can start converting to LMM.
But what's this? I have 61 LONGS free in the zicog COG !!!
How come you guys are scabbling about for LONGs so hard ?
Anyway this is good news as I can add an LMM Virtual Machine and start experimenting with LMM versions of overlaid code without breaking the whole thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hey, YOU said that memory was tight...
Great news! I'm sure using LMM will make things a lot easier in the end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Anyway, yippeee, 60+ longs will be so useful. I never went into the memory driver bits until recently, with DracBlade and so hadn't realized just how tight it all was ( leave alone the 9 bit literal thing )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Sorry. It's a confusion on my part regarding #defines.
If you hit F8 in the to level zicog_cpm.spin all the defines there are in effect but if you hit F8 in zicog.spin then CPU_Z80 is not defined there and the 8080 only code is much smaller. Duhhh.
The correct answer in my TriBlade case is 13 free LONGs.
However that is still enough to proceed with LMM experiments without breaking everything at once [noparse]:)[/noparse]
Note: Must remember to put the defines back in the project configuration in BST.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
HTH,
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
It has always occurred to me that we should be able to dispense with the DD and FD dispatch tables and combine them into the main dispatch table. Well actually there there is only a combined DDFD table now. I've always assumed that the Z80 just had flags somewhere that select HL, IX or IY when a prefix is encountered and then runs through much the same 8080 logic but using the IX or IY regs instead. Are they the mysterious undocumented bits in the flags byte?
Combing those tables would save 256 LONGs in HUB which would make Dr_A happy.
However I'm loath to put extra code in the 8080 "critical path" that does this index reg selection. Perhaps there is a fast way to do it. I have not looked so hard. Let's remember to discuss this later when I have my LMM in place.
We could fill in the ddfd table with valid 8080 ops where there are currently "undocumented"
Multiple prefixes should be handled easily as well.
Reminds me of the time way back when I discovered you could put a "32 bit" prefix byte in front of 80386 instructions, even when it is operating in 16 bit real mode. Having 32 bit arithmetic under MSDOS was a hoot.
By the way, I have just put in an LMM loop and replaced the overlay for the OUT instruction with LMM. Works a treat!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well it doesn't take much to get me excited about more memory so the comment about DD FD table means I've gone and commented this out for the moment. It is saving me a whole lot of hub longs, and with those I've been able to transfer some of the networking code from discrete CP/M programs into Spin. I can see the beginnings of a CP/M network. I've got three boards all with wireless tranceivers. The PC is off and not part of this network (though it can be if you want). Any board can find out who is nearby (#WHO command) and any board can link with any other board and do file transfers, or even run Mbasic or Wordstar remotely. This is the amazing thing about the propeller - you just can't do this with standard CP/M machines as you need buffers and two asynchronous serial ports. I used the spare memory to add things like random time delays when a WHO command is received so all boards don't reply at once.
So I run this little sbasic program
And then I know that BETA and DELTA are within range, so then I can use option 3 and choose the board and talk to it. Or send or receive a file. Links are disconnected when you hit ESC or if there is no activity for 3 minutes.
Max range is 3km.
So.... I do hope all these new zicog experiments don't take up too much hub ram!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/6/2010 12:55:56 PM GMT
No, definitely not. But you are probably right that the Z80 uses a way to index either HL (normal opcodes) or IX or IY and then executes the normal opcode's microcode. This is most probably also the reason why the undocumented half IX/IY registers exist. It's a side effect of remapping HL to IX or IY. OTOH there are opcodes where H or L is used in combination with IX or IY. Think of ld l,(ix+offs), so the remapping of the registers is somewhat more complex... It seems to depend on opcode bits 2..0 being = 6, i.e. the memory slot of the 8 registers with 8 bits.
Yes, this should be possible somehow, but it's not easy to accomplish for abovementioned reason.
That's what I meant. Just execute the same things as in the 00 table for undocumented entries.
Great! Even though I can't follow your development without a Prop, I'm eager to see the LMM stuff as a workaround for the space problems.
My PropRPM still isn't here, and it's probably not going to arrive today anymore :-( It looks like I have to run one of the Prop emulators. Do you know if they work well enough to play with?
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/6/2010 12:59:09 PM GMT
So if you use #define CPU_8080 instead it should have the same effect.
Unless you are using some Z80 opcodes in an otherwise broken Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, that is what I'm doing. I've got a few of my favourites in some assembly programs eg DJNZ. But almost everything is 8080 - eg all the compiled higher level languages. So I am following this discussion closely especially the tradeoff between slightly slower 8080 vs smaller Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Looks like the ddfd table might be staying, unless someone comes up with a fast way of handling things.
I have played with Gear and what was it, PropEmu?, but I had no luck using them on complicated multi COG code and gave up the idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point