It's been a while, and this is a small update, but it's a relatively important one since it was biting people, so I wanted to get it out.
-Removed SDGROM concept
It was a neat idea that I had, and it will probably resurrect in some form with the GROM chip I made, but the original plans I had for it suffered from several design flaws and I won't be pursuing it any further.
-Fixed Speech Synth reset code
This looks like a bug in the 5220 emulation - during reset it would write a 0 nibble to the address shift register, throwing the whole thing out of alignment unless you wrote enough nibbles to re-align it. Net effect was no speech for the first run on Mark's program. (I need to rip this out anyway and replace it with the new code from MESS so the synth has the right chip.
-Fix setting of carry bit on SRC instruction
Stuart Conner found this for me - SRC was setting carry to be equal to the value in the LSB after the shift, and not the value shifted out of the LSB. Should be fixed!
-Fix for post-increment on the CPU to handle instructions that reference the same register for source and destination (this affects about half the opcodes!)
I started this a few weeks ago upon discovering that the Corcomp Diagnostics memory test failed. The problem was in this instruction:
The test expected that the address of the memory location would be stored at each memory location, that is, >A000 = >A000, >A002 = >A002, etc. Unfortunately, my memory decode and opcode functionality didn't work with this - it would first get the address of the source and destination values, including handling post-increment, and THEN do the move itself (by which point the destination register had already been incremented, so the that DATA stored was off by 2).
I fixed that by separating the address aquisition and the post-increment operation, and that worked fine. But it introduced a new bug that caused even Extended BASIC to hang, so I couldn't release it. Tonight I worked that out, and it was this instruction in the GPL division code:
This code is used in a loop to copy a floating point value from one place in scratchpad to another place 10 bytes ahead. The problem here is that now my code was doing the post increment on the SOURCE register too late, calculating the destination address before the post increment, and thus again being off by 2.
The process needed to make all these edge cases work, which makes perfect sense to me now that I've had to work it out, is:
-Calculate source address
-Get source data
-Apply source register post-increment
-Calculate destination address
-Store operation result
-Apply destination register post-increment
Anyway, that was a trickier one, but I'm always happy to resolve CPU bugs -- and now two are resolved! Still some issues though.. ARC303 still can't write compressed files. I looked at that and I see the block of code where it decides not to write the file (it does write the directory, but declines to actually process the FILE), but I don't follow what that code is trying to do or why it made that choice. And TI Logo II can't seem to move the turtle at 270 degrees (it's off by 45 degrees only at that angle). Win994A seems to have the same bug, but MESS works. Again, though, it's a little hard to see why right now.
-Make "Step over" work on branches that include a data statement after them or that otherwise increment the return address by 2
This was just a quickie because I was dealing with DSRLNK calls, which include a data statement after them. Just made it also check the next address.
-fix debugger - register match value is entered in hex again
There was a bug where you had to enter register match values in decimal. Fixed that.
Edited by Tursi, Fri Dec 24, 2010 2:41 AM.