Hey Toby I was looking for you sorry I have been awhile busy with other Smile.. PM me ,you are more than welcome to take a shot at my dead Dr_A board Its still complete and will work for a limited time, Toby where did you get the YAZ80 files??? is this more complete than the copy of CPM we are laready using??
I have just put YAZ80 into a Dracblade, with the images on a freshly formatted (Fat16) 2GB SD and it fires up and runs a 10000 For-Next loop test OK.
I the tried it on a 512KB Blade2 but it only gets as far as sd and Triblade inits, followed by : sector 0. It then stops.
I was just trying to see the speed differences.
Any clues as to what stupidity I have done, this time ?
There may be bugs in the TriBladeProp read/write handlers and/or in the tri-stating and re-enabling of the RAM. All that code is untested. I'll look over it and compare with ZiCog to see if I can find a bug on my side. It may as well be in me using the TriBlade xmm functions. They should be equivalent to the RamBlade and DracBlade ones. Can you cut+paste the output on the TriBlade?
Ah, it looks like the TriBlade needs extra calls to the active and idle methods to enable and disable the SD card on the bus. I'll put that in and make an update.
Edit: You can try ver 0.2.3 or 0.2.4 from the front page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Baggers said...
Thanks pullmoll, don't need to worry too much about cycle accuracy, because I'd make the ZX81 emulation point to a screen buffer, which would then drawn by the screen display driver, not the actual ZX81.
Spectrum version is a bitmap anyway, and we already have drivers for that [noparse]:D[/noparse]
Do you know if you need all interrupt modes, or just interrupt mode 1 (RST 38h)?
The Z80 interrupt modes are:
0: execute opcode written to the data bus by the interrupt device
1: execute a RST 38h
2: jump to the address at memory[noparse][[/noparse]I*256+databus]
For now I'll implement an interrupt request long with the following semantics:
NMI = bit31 is non zero, e.g. write -1 to the irq long.
IRQ = write $ff or any other RST opcode to the irq long to execute that interrupt.
yaz80 has a PUB get_irq that gives you the address of the long to modify.
If modes 0 and 2 are required, I'll have to do some more work here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Thanks for the reply. I am Propless untill the weekend, so I will try it then.
MikeDiv
I think that YAZ80 is only unfinished on set and res bits, but Pullmoll is still working on these. We are so lucky to have his effort on this. Heater, Clusso and Dr_A had done so much hard work and Pullmoll's input over the last month, or so, has pushed it on so much.
As for the DracBlade send it up and I will willingly look at it for you. Preferably soon, as the new job is bound to complicate life.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby Seckshund said...
I think that YAZ80 is only unfinished on set and res bits, but Pullmoll is still working on these.
No, the SET/RES (IX/IY+disp8) opcodes are working, it's just the undocumented part that I had to strip out to make EXZ80DOC happy.
In reality (on a Zilog Z80) using DD CB 01 00, which is an "invalid opcode", would do the same as DD CB 01 06 - which is RLC (IX+1) - but it would put the result in the B register also! Similar DD CB 01 01 would put the result in the C register and so on.
When I implemented that, the exerciser would fail. I can only assume it was not run on a Zilog Z80 to get the original CRCs, but perhaps on a NEC µPD780 or some other Z80 derivate. That would also explain why Dr_Acula's try on to run it on a Zilog Z80 resulted in 3 CRC mismatches.
Ideally we would use a Zilog Z80, let EXZ80DOC and EXZ80ALL run there and update the correct CRCs in the source file, but that's going to quit some work to do...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Re "Ideally we would use a Zilog Z80, let EXZ80DOC and EXZ80ALL run there and update the correct CRCs in the source file, but that's going to quit some work to do..."
I can run a test on a real Z80 if you wish. Which program do you want run (maybe post it here as an attachment).
Re "The TRS80 clock interrupt and FDC interrupt, sharing the same one IRQ (RST 38 vector). The clock was 40Hz if I'm not totally wrong"
I see you are thinking of an #ifdef that adds one or two lines of code to each instruction to test if an interrupt has occured. That interrupt could be another cog?? On the dracblade, maybe the memory access cog, or the keyboard cog could update a long somewhere. Just a thought - does MP/M require an interrupt clock to switch between users?
Dr_Acula said...
Re "Ideally we would use a Zilog Z80, let EXZ80DOC and EXZ80ALL run there and update the correct CRCs in the source file, but that's going to quit some work to do..."
I can run a test on a real Z80 if you wish. Which program do you want run (maybe post it here as an attachment).
The EXZ80DOC.COM as you have it would be sufficient. Actually we could take the output from the test you already ran - I assume on that same Z80?
If it runs again and prints the same tests failing, then we have to assume the CRCs in the source are wrong ... unless your Z80 isn't one [noparse]:)[/noparse]
Dr_Acula said...
Re "The TRS80 clock interrupt and FDC interrupt, sharing the same one IRQ (RST 38 vector). The clock was 40Hz if I'm not totally wrong"
I see you are thinking of an #ifdef that adds one or two lines of code to each instruction to test if an interrupt has occured. That interrupt could be another cog?? On the dracblade, maybe the memory access cog, or the keyboard cog could update a long somewhere. Just a thought - does MP/M require an interrupt clock to switch between users?
#define INTERRUPTS adds two instructions to the fetch opcode entry, which is executed once per instruction, yes. The interrupt is signaled by some cog/Spin modifying a long irg, i.e. the interrupt request. The keyboard cog could generate e.g. an RST 38h by writing $ff to irq, but you would have to setup the vector in the Z80 RAM to do something useful then. You could e.g. implement a type ahead buffer in the Z80 bios that reads the constat port and saves condata to somewhere. The constat BIOS function would then check the buffer, not the current status on the port. A periodic interrupt would also be possible. Any cog that runs at a constant rate could be turned into a clock generator by periodically writing to this long irq.
I have no clue when it comes to MP/M. I used Phillips TurboDOS for a couple of weeks, which is some kind of MP/M clone, but I don't even remember if it was Z80 or 8086 (I think it was the latter).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 11:10:05 AM GMT
D'OH! Actually reading the Propeller's manual sometimes helps.
I coded up the Z80 rotate and shift opcodes under the assumption the a >1 shift/rotate would leave the carry with the most recent bit in either position 31 or 0. The Propeller however uses the state of the initial bit 31 or 0 to set the carry. I've been looking at the 8 shift/rotate instruction emulations for literally hours without seeing the problem. Now this was, hopefully, the last fat bug in the code.
I'll clean it all up a little, run some test and then post an update on the first page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll, IM2 was used in most spectrum machine coded games, you don't need IM1 because that code was bugged, and basically did software reset when a location had 0 in it. so won't be necessary to execute the interrupt
Baggers said...
pullmoll, IM2 was used in most spectrum machine coded games, you don't need IM1 because that code was bugged, and basically did software reset when a location had 0 in it. so won't be necessary to execute the interrupt
Well, I _need_ IM 1, because it's the default without ever executing the IM opcode. The question is: do _you_ need IM 2 vectored jumps? That isn't clear to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm looking at using the Yaz80 instead of the ZicogLMM (which recently replaced the old Zicog). I've got the latest code from the TRS80 thread and changed a couple of variables. Changed the startup below (yaz80=cpu)
err := \cpu.start(@reg_base)
' err :=\cpu.start(0,@reg_base,0,0)
Only one error now. "Binary exceeds memory by 1033 longs"
Dr_Acula said...
I'm looking at using the Yaz80 instead of the ZicogLMM (which recently replaced the old Zicog). I've got the latest code from the TRS80 thread and changed a couple of variables. Changed the startup below (yaz80=cpu)
err := \cpu.start(@reg_base)
' err :=\cpu.start(0,@reg_base,0,0)
Only one error now. "Binary exceeds memory by 1033 longs"
Any suggestions?
This is wrong. You don't have to supply reg_base, since the registers belong to yaz80 and are defined there.
You will have to specify the address of the io_command long that is used to communicate Z80 i/o port activity to your main.
This long must be followed by io_port and io_data as it is now.
For the memory size: throw out what you don't need. Since yaz80 is doing all Z80 opcodes, it's of course bigger than ZiCog. yaz80 alone does not have anything you could tweak to reduce its size. Only exception: undefine COUNT_R to save a few longs (not much). You could reuse its hub RAM starting at @entry, but be careful to not overwrite the Z80 registers following it, so don't use more than $1f0 bytes there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
and noted that io_base is cpu_params +4, so the value being passed is not for the registers, it is for the io_base. I was going to simply add 4 onto cpu_params if I got it to compile.
But this brings up a more fundamental question - is the code you are writing going to work for a single prop CP/M computer?
Currently the ZicogLMM is emulating an 8080 and this works fine because CP/M is 8080. The earlier version heater wrote had almost all the Z80 opcodes working and I stripped those out because a number were not working and a half working Z80 wasn't very useful. There are quite a few bytes free now. Then I saved some more bytes reusing some of the cog space for an array, and by commenting out code for disk drive formats that was not needed and even getting rid of the code that can read any byte in the 512k memory. There isn't much else that can be deleted. ? strip the sd card routines back to something smaller
But Yaz80 seems to have used up all that space and more. Aaargh!
I'm not quite sure why it is using so much more memory. A large part of yaz80 is not compiled as it has the ifdefs for all the different hardware.
Already so much of the dracblade is a compromise. Propbasic for instance runs on the same board and can do all sorts of fancy graphics on a vga monitor. But that requires a lot of hub memory. So if you want a keyboard and sd access and serial ports you have to give up graphics.
I see you are porting I/O routines into pasm, is that right? If so, that will save some space. I/O in spin is slow and uses a lot of precious hub ram for what it does. Also, the dracblade cog
''Dracblade driver for talking to a ram chip via three latches
'' Modified code from Cluso's triblade
' DoCmd(command_, hub_address, ram_address, block_length)
' R - read bytes at address n up (n to n+block_length) where n =0 to 65535 (ie lower 64k of the sram chip)
' W - write bytes at address n up
' I - initialise
' N - Led on
' F - Led off
' H - set high latch to value in ramaddress A16 to A23 (will include the led)
has a lot of spare space that could do io. Or are you incorporating that cog into the yaz80 cog??
Dr_Acula said...
But this brings up a more fundamental question - is the code you are writing going to work for a single prop CP/M computer?
Of course. It runs on your DracBlade, which - after all - is a single Prop board!?
Dr_Acula said...
Currently the ZicogLMM is emulating an 8080 and this works fine because CP/M is 8080. The earlier version heater wrote had almost all the Z80 opcodes working and I stripped those out because a number were not working and a half working Z80 wasn't very useful.
I can see that this is smaller. I can come up with a ya8085 sooner or later, but the Z80 has... hmm.. let me count: 256+256+96+256+256+256+256 = 1632 different opcodes. By joining IX/IY I could save 512 of them, but that leaves 1120 opcodes, each consisting of at least 2 longs in hubRAM, most of them of some more longs.
Dr_Acula said...
But Yaz80 seems to have used up all that space and more. Aaargh!
With my io.spin I'm at ~6000 longs now, so I have some space for important things. What will not work is to have it all at once. LCD+VGA+Serial or the like. You certainly will have to choose what hardware to support.
Dr_Acula said...
I'm not quite sure why it is using so much more memory. A large part of yaz80 is not compiled as it has the ifdefs for all the different hardware.
See above. It is because of 1120 opcodes compared to 256 8080 opcodes.
Dr_Acula said...
Already so much of the dracblade is a compromise. Propbasic for instance runs on the same board and can do all sorts of fancy graphics on a vga monitor. But that requires a lot of hub memory. So if you want a keyboard and sd access and serial ports you have to give up graphics.
Hmm.. I havent looked at Propbasic. We all suffer from tight memory and all do our best to use as few longs as possible.
Dr_Acula said...
I see you are porting I/O routines into pasm, is that right?
Yes. Mostly for speed. If I want to have e.g. sound in TRS80, then I/O port handling in Spin would be way too slow.
Dr_Acula said...
Or are you incorporating that cog into the yaz80 cog??
The yaz80 cog is almost full, as is the io cog. I'll have to very carefully select what I can put in either of them. Keyboard is a must and either VGA or TV will be there some day. For now I rely on the serial communications as a terminal interface.
Dr_Acula said...
Are you using VGA or only TV at the moment?
Neither. Just serial.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Re "What will not work is to have it all at once. LCD+VGA+Serial or the like. You certainly will have to choose what hardware to support."
Yes lots of compromises. For me I'd rather have LCD and VGA and serial. Is ya8080 a possibility?
I wonder, there must be Z80 opcodes that are hardly ever used. Could those be stored somehow on the sd card and then moved into external ram (the rest of the 512k) and only loaded if they are encountered? Very slow. But hardly ever happens. Do you save much memory that way?
I was thinking about some sort of statistical measure of which opcodes are used the most. Not which come up in a program the most (that is easy to see just looking at the source code) but which ones are run the most. I suspect the code that polls a port waiting for input and output use 99% of the opcodes as mostly CP/M is waiting for input from the keyboard or the serial port etc. So putting io into pasm makes a lot of sense and may well give a very big speed increase.
As an example, a FOR loop in basic indicates somewhere between 3 and 4Mhz. But the timing delay in xmodem has had to be decreased to about 1/10th to get the right delay, and that bit of code is the bit polling the io ports. Which is calling spin a lot.
I wonder, there must be Z80 opcodes that are hardly ever used. Could those be stored somehow on the sd card and then moved into external ram (the rest of the 512k) and only loaded if they are encountered? Very slow. But hardly ever happens. Do you save much memory that way?
I fear that the code fetching them might almost eat up the saved space [noparse]:)[/noparse] yaz80 is entirely stored in $cea = 3306 longs. To externalize e.g. the DD/FD CB opcodes, I would still need an index table to fetch the correct entry. The table is squeezed in 16 longs now. The code for them is 0xac2 to 0xb1a = $58 = 88 longs, ergo: these alone are not worth the hassle. Externalizing the entire IX/IY group would save +128 longs for the tables and ($99c to $ac2 = $126) +294 longs, so 526 long was the absolute maximum that could be saved by this. You are short of 1033 longs...
Dr_Acula said...
I was thinking about some sort of statistical measure of which opcodes are used the most. Not which come up in a program the most (that is easy to see just looking at the source code) but which ones are run the most. I suspect the code that polls a port waiting for input and output use 99% of the opcodes as mostly CP/M is waiting for input from the keyboard or the serial port etc. So putting io into pasm makes a lot of sense and may well give a very big speed increase.
I am already doing I/O in PASM only. Did I say that the EXZ80DOC test of ini,ind,outi,outd took more than 3 hours before I stopped it? I don't know if it was maybe stuck...
Dr_Acula said...
As an example, a FOR loop in basic indicates somewhere between 3 and 4Mhz. But the timing delay in xmodem has had to be decreased to about 1/10th to get the right delay, and that bit of code is the bit polling the io ports. Which is calling spin a lot.
You won't get good numbers from only executing a specific loop, because this is going to use a specific subset of opcodes only. Running a program that actually does something, like starting up Wordstar with a large file, and then measuring the cycles Z80 vs. Propeller should give a good measure. I think yaz80 runs at abt. 1.6MHz (without the cycle counting).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll, yes, basicall what we used to do, was using IM2, point I to FD, and fill FD00 to FDFF with FF's then put $18 ( JR disp ) at $ffff, and use the rom's first byte at $0000 of $f3 as the disp, which jumps back to $fff4 for our VBlank interrupt [noparse]:D[/noparse] is that helpful?
btw, not all games using IM2 used this addressing system, but most filled the I referenced 257 bytes of memory with the same number, so that whatever the vector offset was, would be catered for, so you could save instructions, by getting the first byte, and jumping to that address.
Baggers said...
pullmoll, yes, basicall what we used to do, was using IM2, point I to FD, and fill FD00 to FDFF with FF's then put $18 ( JR disp ) at $ffff, and use the rom's first byte at $0000 of $f3 as the disp, which jumps back to $fff4 for our VBlank interrupt [noparse]:D[/noparse] is that helpful?
btw, not all games using IM2 used this addressing system, but most filled the I referenced 257 bytes of memory with the same number, so that whatever the vector offset was, would be catered for, so you could save instructions, by getting the first byte, and jumping to that address.
hope this helps.
Well, sort of.. you did indirectly answer my question _if_ you need vectored jumps. It looks like you do. Then _what_ you do with them is your job [noparse]:)[/noparse] I will implement the modes and for mode 2 will use the lower 8 bits of the interrupt long as the data bus byte and change the PC to word[noparse][[/noparse]I<<8+data]. Wait for the next release please.
Would executing FF not exceed the table $fd00 to $fdff? I think the word read from the table doesn't wrap the address for the MSB. It would read $fdff and $fe00 and jump to ... nirwana?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Okay, 0.3.1 is there. It includes code for the 3 interrupt modes - of course untested [noparse]:)[/noparse]
I also changed the communication between the Z80 and the I/O cog to a single long containing command, port and data. That saves several hub accesses with potentially time consuming congestion. Since I had to remove the LDIR/LDDR core loops to be able to optionally measure the Z80 speed, I have now 73 longs free in the cog. If anyone has good arguments for what to put in there, I'm all ears.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Get 0.3.2 and just define CPU_8080 instead of CPU_Z80 and you will get a bastard 8080 that still knows the DJNZ and JR <cond> opcodes, but no prefixed opcodes. It runs CP/M here. The size is down to $53d = 1341 longs.
Oh, forgot to say: you'll have to change your I/O handling function at the entry. The port and the data are encoded in the same long as the command byte.
Just do
cmd := command>>24
port := (command>>8)&$ff
data := command&$ff
and you should be set.
The io_cmd_break ($3) delivers the address of the register file in hub RAM in the port value. You can do:
addr := (command>>8)&$ffff
to get the base address. Look at yaz80.spin after the "fit" to see the order of registers if you want to print them on HALT.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I am sure that most of my attemps at Z80 were really 8080 code, in Z80 mnemonics. If I had of used the 8080 ones then the 8051 series would had been easier for me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Wow Pullmoll. Well done on getting yaz80 through all the EX tests. A great piece of work. I'll certainly be trying it out when I have a moment.
Looks like you are going to win over all the ZiCog users. I'm kind of sad about that but hey, the world moves on, and you get to field all the support questions in the future[noparse]:)[/noparse]
That EX test we have been using states that the CRC's it checks against were generated on a Z80 by MOSTEK. If anyone has a real Z80 to run EX on we should really get ourselves a new version of EX that tests against that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Wow Pullmoll. Well done on getting yaz80 through all the EX tests. A great piece of work. I'll certainly be trying it out when I have a moment.
Looks like you are going to win over all the ZiCog users. I'm kind of sad about that but hey, the world moves on, and you get to field all the support questions in the future[noparse]:)[/noparse]
That EX test we have been using states that the CRC's it checks against were generated on a Z80 by MOSTEK. If anyone has a real Z80 to run EX on we should really get ourselves a new version of EX that tests against that.
I actually should run the EX tests in full length once again to see if I really have them all. Over the hassle with the new SD SPI object I forgot where I actually was.
Hey, ZiCog is essential in that it gave me a good start to peek at and to see how you did things. Otherwise it would have taken a lot more time to find out e.g. that the parity flag of the Prop is inverted compared with the Z80's.
Yes, we should really get the numbers of a Zilog Z80 to verify against. Let's see what Dr_A has in his box [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_A kindly sent me a mini-N8VEM board some time ago. What with all the other things going on I'm sad to say it has been neglected recently. I'll dig it out this evening and try EX on it. Not sure but I have a feeling it does have a real Z80 on it.
Is there any quick way to run EX against your MAME Z80 emulator code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Dr_A kindly sent me a mini-N8VEM board some time ago. What with all the other things going on I'm sad to say it has been neglected recently. I'll dig it out this evening and try EX on it. Not sure but I have a feeling it does have a real Z80 on it.
Is there any quick way to run EX against your MAME Z80 emulator code?
Hmm.. not too easy. There's also MESS, a computer + console emulation based on MAME, but I haven't used that for years and don't know how stable it is. I wrote a Kaypro CP/M emulation for MESS many years ago, and - of course - also TRS80 and my beloved Colour Genie + some more I don't recall. All Z80 - and I believe most of them broken today after other devs didn't care about my drivers anymore.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
Re "Let's see what Dr_A has in his box [noparse]:)[/noparse]"
Dr_A is stuck at work plastering up kids with broken arms etc. They will let me out eventually...
Oh yes, real life exists I heard someone say recently [noparse]:)[/noparse]
Since I have no wife and no kids, I wrote a TV 80x24 video driver and am in the process of writing the accompanying VT100 emulation. It's just too bad that attributes are very hard to squeeze in the tight timing of an 80 columns video driver. If any at all. But even without attributes I wanted a rather complete VT100 and looked through my old x86 assembler source where I had a linux console compatible VT100/ANSI... Well, anyway, I'm talking too much [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Comments
I have just put YAZ80 into a Dracblade, with the images on a freshly formatted (Fat16) 2GB SD and it fires up and runs a 10000 For-Next loop test OK.
I the tried it on a 512KB Blade2 but it only gets as far as sd and Triblade inits, followed by : sector 0. It then stops.
I was just trying to see the speed differences.
Any clues as to what stupidity I have done, this time ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
There may be bugs in the TriBladeProp read/write handlers and/or in the tri-stating and re-enabling of the RAM. All that code is untested. I'll look over it and compare with ZiCog to see if I can find a bug on my side. It may as well be in me using the TriBlade xmm functions. They should be equivalent to the RamBlade and DracBlade ones. Can you cut+paste the output on the TriBlade?
Ah, it looks like the TriBlade needs extra calls to the active and idle methods to enable and disable the SD card on the bus. I'll put that in and make an update.
Edit: You can try ver 0.2.3 or 0.2.4 from the front page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 8:33:06 AM GMT
Do you know if you need all interrupt modes, or just interrupt mode 1 (RST 38h)?
The Z80 interrupt modes are:
0: execute opcode written to the data bus by the interrupt device
1: execute a RST 38h
2: jump to the address at memory[noparse][[/noparse]I*256+databus]
For now I'll implement an interrupt request long with the following semantics:
NMI = bit31 is non zero, e.g. write -1 to the irq long.
IRQ = write $ff or any other RST opcode to the irq long to execute that interrupt.
yaz80 has a PUB get_irq that gives you the address of the long to modify.
If modes 0 and 2 are required, I'll have to do some more work here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 6:03:18 AM GMT
Thanks for the reply. I am Propless untill the weekend, so I will try it then.
MikeDiv
I think that YAZ80 is only unfinished on set and res bits, but Pullmoll is still working on these. We are so lucky to have his effort on this. Heater, Clusso and Dr_A had done so much hard work and Pullmoll's input over the last month, or so, has pushed it on so much.
As for the DracBlade send it up and I will willingly look at it for you. Preferably soon, as the new job is bound to complicate life.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
No, the SET/RES (IX/IY+disp8) opcodes are working, it's just the undocumented part that I had to strip out to make EXZ80DOC happy.
In reality (on a Zilog Z80) using DD CB 01 00, which is an "invalid opcode", would do the same as DD CB 01 06 - which is RLC (IX+1) - but it would put the result in the B register also! Similar DD CB 01 01 would put the result in the C register and so on.
When I implemented that, the exerciser would fail. I can only assume it was not run on a Zilog Z80 to get the original CRCs, but perhaps on a NEC µPD780 or some other Z80 derivate. That would also explain why Dr_Acula's try on to run it on a Zilog Z80 resulted in 3 CRC mismatches.
Ideally we would use a Zilog Z80, let EXZ80DOC and EXZ80ALL run there and update the correct CRCs in the source file, but that's going to quit some work to do...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 9:27:32 AM GMT
I can run a test on a real Z80 if you wish. Which program do you want run (maybe post it here as an attachment).
Re "The TRS80 clock interrupt and FDC interrupt, sharing the same one IRQ (RST 38 vector). The clock was 40Hz if I'm not totally wrong"
I see you are thinking of an #ifdef that adds one or two lines of code to each instruction to test if an interrupt has occured. That interrupt could be another cog?? On the dracblade, maybe the memory access cog, or the keyboard cog could update a long somewhere. Just a thought - does MP/M require an interrupt clock to switch between users?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/25/2010 9:39:45 AM GMT
The EXZ80DOC.COM as you have it would be sufficient. Actually we could take the output from the test you already ran - I assume on that same Z80?
If it runs again and prints the same tests failing, then we have to assume the CRCs in the source are wrong ... unless your Z80 isn't one [noparse]:)[/noparse]
#define INTERRUPTS adds two instructions to the fetch opcode entry, which is executed once per instruction, yes. The interrupt is signaled by some cog/Spin modifying a long irg, i.e. the interrupt request. The keyboard cog could generate e.g. an RST 38h by writing $ff to irq, but you would have to setup the vector in the Z80 RAM to do something useful then. You could e.g. implement a type ahead buffer in the Z80 bios that reads the constat port and saves condata to somewhere. The constat BIOS function would then check the buffer, not the current status on the port. A periodic interrupt would also be possible. Any cog that runs at a constant rate could be turned into a clock generator by periodically writing to this long irq.
I have no clue when it comes to MP/M. I used Phillips TurboDOS for a couple of weeks, which is some kind of MP/M clone, but I don't even remember if it was Z80 or 8086 (I think it was the latter).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 11:10:05 AM GMT
I coded up the Z80 rotate and shift opcodes under the assumption the a >1 shift/rotate would leave the carry with the most recent bit in either position 31 or 0. The Propeller however uses the state of the initial bit 31 or 0 to set the carry. I've been looking at the 8 shift/rotate instruction emulations for literally hours without seeing the problem. Now this was, hopefully, the last fat bug in the code.
I'll clean it all up a little, run some test and then post an update on the first page.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Well, I _need_ IM 1, because it's the default without ever executing the IM opcode. The question is: do _you_ need IM 2 vectored jumps? That isn't clear to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
err := \cpu.start(@reg_base)
' err :=\cpu.start(0,@reg_base,0,0)
Only one error now. "Binary exceeds memory by 1033 longs"
Any suggestions?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
This is wrong. You don't have to supply reg_base, since the registers belong to yaz80 and are defined there.
You will have to specify the address of the io_command long that is used to communicate Z80 i/o port activity to your main.
This long must be followed by io_port and io_data as it is now.
For the memory size: throw out what you don't need. Since yaz80 is doing all Z80 opcodes, it's of course bigger than ZiCog. yaz80 alone does not have anything you could tweak to reduce its size. Only exception: undefine COUNT_R to save a few longs (not much). You could reuse its hub RAM starting at @entry, but be careful to not overwrite the Z80 registers following it, so don't use more than $1f0 bytes there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/27/2010 4:34:56 AM GMT
PUB start(cpu_params) : okay | reg_base, io_base '' Start CPU simulator - starts a cog '' returns false if no cog available '' '' cpu_par_params is a pointer to CPU parameter list stop reg_base := LONG[noparse][[/noparse]cpu_params] c_reg := reg_base + 0 b_reg := reg_base + 1 e_reg := reg_base + 2 d_reg := reg_base + 3 l_reg := reg_base + 4 h_reg := reg_base + 5 f_reg := reg_base + 6 a_reg := reg_base + 7 im_reg := reg_base + 16 ix_reg := reg_base + 18 iy_reg := reg_base + 20 sp_reg := reg_base + 22 pc_reg := reg_base + 24 #ifdef TriBladeProp or DracbladeProp ram_size := $FB00 '(1024 * msize) - $100 #else #warn RAM size not defined #endif io_base := LONG[noparse][[/noparse]cpu_params + 4] io_command := io_base io_port := io_base + 4 io_data := io_base + 8and noted that io_base is cpu_params +4, so the value being passed is not for the registers, it is for the io_base. I was going to simply add 4 onto cpu_params if I got it to compile.
But this brings up a more fundamental question - is the code you are writing going to work for a single prop CP/M computer?
Currently the ZicogLMM is emulating an 8080 and this works fine because CP/M is 8080. The earlier version heater wrote had almost all the Z80 opcodes working and I stripped those out because a number were not working and a half working Z80 wasn't very useful. There are quite a few bytes free now. Then I saved some more bytes reusing some of the cog space for an array, and by commenting out code for disk drive formats that was not needed and even getting rid of the code that can read any byte in the 512k memory. There isn't much else that can be deleted. ? strip the sd card routines back to something smaller
But Yaz80 seems to have used up all that space and more. Aaargh!
I'm not quite sure why it is using so much more memory. A large part of yaz80 is not compiled as it has the ifdefs for all the different hardware.
Already so much of the dracblade is a compromise. Propbasic for instance runs on the same board and can do all sorts of fancy graphics on a vga monitor. But that requires a lot of hub memory. So if you want a keyboard and sd access and serial ports you have to give up graphics.
I see you are porting I/O routines into pasm, is that right? If so, that will save some space. I/O in spin is slow and uses a lot of precious hub ram for what it does. Also, the dracblade cog
has a lot of spare space that could do io. Or are you incorporating that cog into the yaz80 cog??
Are you using VGA or only TV at the moment?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Of course. It runs on your DracBlade, which - after all - is a single Prop board!?
I can see that this is smaller. I can come up with a ya8085 sooner or later, but the Z80 has... hmm.. let me count: 256+256+96+256+256+256+256 = 1632 different opcodes. By joining IX/IY I could save 512 of them, but that leaves 1120 opcodes, each consisting of at least 2 longs in hubRAM, most of them of some more longs.
With my io.spin I'm at ~6000 longs now, so I have some space for important things. What will not work is to have it all at once. LCD+VGA+Serial or the like. You certainly will have to choose what hardware to support.
See above. It is because of 1120 opcodes compared to 256 8080 opcodes.
Hmm.. I havent looked at Propbasic. We all suffer from tight memory and all do our best to use as few longs as possible.
Yes. Mostly for speed. If I want to have e.g. sound in TRS80, then I/O port handling in Spin would be way too slow.
The yaz80 cog is almost full, as is the io cog. I'll have to very carefully select what I can put in either of them. Keyboard is a must and either VGA or TV will be there some day. For now I rely on the serial communications as a terminal interface.
Neither. Just serial.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Yes lots of compromises. For me I'd rather have LCD and VGA and serial. Is ya8080 a possibility?
I wonder, there must be Z80 opcodes that are hardly ever used. Could those be stored somehow on the sd card and then moved into external ram (the rest of the 512k) and only loaded if they are encountered? Very slow. But hardly ever happens. Do you save much memory that way?
I was thinking about some sort of statistical measure of which opcodes are used the most. Not which come up in a program the most (that is easy to see just looking at the source code) but which ones are run the most. I suspect the code that polls a port waiting for input and output use 99% of the opcodes as mostly CP/M is waiting for input from the keyboard or the serial port etc. So putting io into pasm makes a lot of sense and may well give a very big speed increase.
As an example, a FOR loop in basic indicates somewhere between 3 and 4Mhz. But the timing delay in xmodem has had to be decreased to about 1/10th to get the right delay, and that bit of code is the bit polling the io ports. Which is calling spin a lot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I fear that the code fetching them might almost eat up the saved space [noparse]:)[/noparse] yaz80 is entirely stored in $cea = 3306 longs. To externalize e.g. the DD/FD CB opcodes, I would still need an index table to fetch the correct entry. The table is squeezed in 16 longs now. The code for them is 0xac2 to 0xb1a = $58 = 88 longs, ergo: these alone are not worth the hassle. Externalizing the entire IX/IY group would save +128 longs for the tables and ($99c to $ac2 = $126) +294 longs, so 526 long was the absolute maximum that could be saved by this. You are short of 1033 longs...
I am already doing I/O in PASM only. Did I say that the EXZ80DOC test of ini,ind,outi,outd took more than 3 hours before I stopped it? I don't know if it was maybe stuck...
You won't get good numbers from only executing a specific loop, because this is going to use a specific subset of opcodes only. Running a program that actually does something, like starting up Wordstar with a large file, and then measuring the cycles Z80 vs. Propeller should give a good measure. I think yaz80 runs at abt. 1.6MHz (without the cycle counting).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
btw, not all games using IM2 used this addressing system, but most filled the I referenced 257 bytes of memory with the same number, so that whatever the vector offset was, would be catered for, so you could save instructions, by getting the first byte, and jumping to that address.
hope this helps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Well, sort of.. you did indirectly answer my question _if_ you need vectored jumps. It looks like you do. Then _what_ you do with them is your job [noparse]:)[/noparse] I will implement the modes and for mode 2 will use the lower 8 bits of the interrupt long as the data bus byte and change the PC to word[noparse][[/noparse]I<<8+data]. Wait for the next release please.
Would executing FF not exceed the table $fd00 to $fdff? I think the word read from the table doesn't wrap the address for the MSB. It would read $fdff and $fe00 and jump to ... nirwana?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/27/2010 9:14:38 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I also changed the communication between the Z80 and the I/O cog to a single long containing command, port and data. That saves several hub accesses with potentially time consuming congestion. Since I had to remove the LDIR/LDDR core loops to be able to optionally measure the Z80 speed, I have now 73 longs free in the cog. If anyone has good arguments for what to put in there, I'm all ears.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Get 0.3.2 and just define CPU_8080 instead of CPU_Z80 and you will get a bastard 8080 that still knows the DJNZ and JR <cond> opcodes, but no prefixed opcodes. It runs CP/M here. The size is down to $53d = 1341 longs.
Oh, forgot to say: you'll have to change your I/O handling function at the entry. The port and the data are encoded in the same long as the command byte.
Just do
cmd := command>>24
port := (command>>8)&$ff
data := command&$ff
and you should be set.
The io_cmd_break ($3) delivers the address of the register file in hub RAM in the port value. You can do:
addr := (command>>8)&$ffff
to get the base address. Look at yaz80.spin after the "fit" to see the order of registers if you want to print them on HALT.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/29/2010 9:17:21 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Looks like you are going to win over all the ZiCog users. I'm kind of sad about that but hey, the world moves on, and you get to field all the support questions in the future[noparse]:)[/noparse]
That EX test we have been using states that the CRC's it checks against were generated on a Z80 by MOSTEK. If anyone has a real Z80 to run EX on we should really get ourselves a new version of EX that tests against that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I actually should run the EX tests in full length once again to see if I really have them all. Over the hassle with the new SD SPI object I forgot where I actually was.
Hey, ZiCog is essential in that it gave me a good start to peek at and to see how you did things. Otherwise it would have taken a lot more time to find out e.g. that the parity flag of the Prop is inverted compared with the Z80's.
Yes, we should really get the numbers of a Zilog Z80 to verify against. Let's see what Dr_A has in his box [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_A is stuck at work plastering up kids with broken arms etc. They will let me out eventually...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Is there any quick way to run EX against your MAME Z80 emulator code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hmm.. not too easy. There's also MESS, a computer + console emulation based on MAME, but I haven't used that for years and don't know how stable it is. I wrote a Kaypro CP/M emulation for MESS many years ago, and - of course - also TRS80 and my beloved Colour Genie + some more I don't recall. All Z80 - and I believe most of them broken today after other devs didn't care about my drivers anymore.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Oh yes, real life exists I heard someone say recently [noparse]:)[/noparse]
Since I have no wife and no kids, I wrote a TV 80x24 video driver and am in the process of writing the accompanying VT100 emulation. It's just too bad that attributes are very hard to squeeze in the tight timing of an 80 columns video driver. If any at all. But even without attributes I wanted a rather complete VT100 and looked through my old x86 assembler source where I had a linux console compatible VT100/ANSI... Well, anyway, I'm talking too much [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.