Activity for Roberto Muscedere
-
Roberto Muscedere committed [r45333] on Code
Fix for RAMLINK: IO1 wouldn't bet setup properly after RAMLINK was turned back on
-
RAMLink and REU cannot be used together
-
Added c128 z80 timing suite to testbench
-
Added C128 Z80 timing suite
-
Added C128 Z80 timing suite
-
Added zex128 to C128 testbench
-
Added testlist to zex128
-
Fixed minor Z80 bug and added cycle limit for Z80 CPU
-
Can you verify on the real machine if access the MMU only returns valid values for $d500-d50b, or does it cover $d50c-$d5ff as well? Does it return $ff's from there or does it go through to the RAM?
-
With real C128 hardware Z80 cannot access Char ROM
-
Please add this to your suite of tests. Ideally they should have the debugcart functionality. At some point, we will combine them into a single test suite.
-
This bug tracker isn't the place for this request, but I will try to help you. The FD4000 mechanism is slightly modified from stock, so you may need to be careful. There is a good chance you are shorting out the main board while connecting the drive. There may be a connection that is assumed to be at 5V on the board and the drive is connecting it to GND or vise versa. I recall seeing images of the working mechanism out on the net before. I suggest you inspect them carefully to see if your drive matches...
-
My first thought is you aren't supposed to use LDs to access IO on the c128. So you should be using an IN variant. However, I'm not sure how a real machine works when you do issue LDs in IO. Given that the MMU is supposed to operate at 2MHz, the IO 1MHz limitation shouldn't be needed. So, yes, this should be investigated further. Perhaps on a variety of IO locations. VIC, color RAM, VDC, etc. What happens if you use a IN instead of the LD on d50b on the real machine?
-
MMU memory addressable at $d500
-
Okay. I updatede the Z80 code. See r45138. If should pass all your timing tests, and it now passes zexzall. Bit 3 and 5 support in the status register has been included. I will now try to deal with those particular timing issues.
-
More changes for bug #1979: Corrected more z80 timing issues, and added WZ reg for improved bit 3 and 5 status register results. x128 Z80 now passes ZEXALL.
-
ZEX128: A C128 native Z80 tester added
-
I know they SHOULD be the same, but I would prefer some kind of confirmation as I want to commit those changes to VICE soon. It seems like it would be more work to make these instructions a NOP than to make them do what they did without a prefix.
-
Oh, I see the problem; the file is not named correctly for EX DE,HL, you have it as E9, not EB. Regardless we should have complete coverage at least for single prefix (DD,FD). We can throw in a couple of weird cases later just to make sure the emulators handle the timing correctly. eg. DD,FD,DD,FD,DD,FD,00 Can you verify the DDE6 and E6 are the same on real hardware? The "undocumented z80 document" doesn't include these variants in its tables. I'm not sure if this was on purpose, or if it just was...
-
This is great. Everything passes on my current build. I've make a lot of changes to the z80 CPU code to make it more maintainable. However, there are still some missing opcodes. You seem to be missing EB "EX DE,HL". You should also include all the uncovered "DDxx", "FDxx", and "EDxx" codes. I know most of them are effectively probably nops, but they should be included. Emulators tend to fail on these issues. I'm also not certain about "DDxx" and "FDxx" beyond anything without HL in it. The DD and...
-
Okay. Corrected the z80 timing to meet both of these test disks. See r45106.
-
More changes for bug #1979: Corrected more z80 timing issues
-
Right, but the 8502 cycles don't matter when it comes to parity as they are running at 1MHz. So, right now, in your "even" code, you are running this on the z80: NOP ;4 JP z80code ;10 LD BC,DC0Eh ;10 LD A,08h ;7 NOP ;4 NOP ;4 NOP ;4 NOP ;4 OUT (C),a ;12 JP FFE0h ;10 Adding that all up gives you 69 cycles which is clearly odd. And you odd code: NOP ;4 JP z80code ;10 LD BC,DC0Eh ;10 XOR A;4 SCF ;4 RLA ;4 RLA ;4 RLA ;4 RLA ;4 OUT (C),a ;12 JP FFE0h ;10 Adding that all up gives you 70 cycles which is...
-
The ffe0 startup code is just a nop (4) and a jmp (10) which is 14 cycles. That is still even so it shouldn't effect anything.
-
I just reviewed your z80 code to make sure the instructions used have the proper cycle count and it seems the "odd" code actually has an even number of cycles: 10+4+4+4x4+12+10, where as the "even" code actually has an odd number of cycles: 10+7+4x4+12+10. Is this right?
-
I just checked the vice z80 code and there are over 1500 instructions handled. If you continue down the one tester per instruction path, you will need a lot of disk images. Yikes!
-
Or better yet, have the z80 code test all the scenarios separately, but save the results into a table along with the opcode and then have the 6502 code check the results (all the timing should be the same for all variants to make things simple) and if somethig is off, it would print out the opcode; so you would need to save those in a table as well.
-
I just had another thought. In the case of opcodes like: 01xxxxxx, if you proceed with the current method, you will need 64 files to test all those opcode variations. Would it be possible to put another nested loop inside your tester to generate all those 64 combinations? Given that the testing the "function" isn't the goal, but just the timing, this may save a lot of space and time. From what I recall, your code generates a starting, core, and ending code sequence, then it runs it. I think you may...
-
Can you create two separate PRG files for this test (one that runs EVEN and the other ODD)? As I said, you probably determined the z80 EVEN/ODD state from reset. So can you have each run properly after a full reset? I will use those to try get figure out what is happening.
-
x128 incorrectly reporting VDC ram
-
Fixed in r45100. vdcdump now works in 16KB mode too.
-
Fix for bug #1981: VDC memory is now properly accessed when memory configs differ; vdcdump runs in 16KB mode.
-
All memory/IO is 1MHz on the Z80 in the c128. This is my thought: EV OD 01 02 OUT (C),r 03 04 05 06 07 08 09 10 Write asserted, but not latched 11 12 Write to IO EV OD -- 01 OUT (C),r 02 03 04 05 06 07 08 09 10 11 Write to IO (write asserted and latched) 12 -- Write to IO? The OUT (c),r asserts the write line from the z80 from cycles 10 to 12 from what I can tell. So when IO happens on the EVEN cycle, the write should start at cycle 10 but the signal isn't latched by the 8502 bus until the beginning...
-
With real C128 hardware Z80 cannot access Char ROM
-
Fixed in r45099. Also, please incorporate this into your testing suite. I think we can do some automation with the c64 one by comparing screen captures.
-
Fix for bug #1987: Z80 can not see charrom in c128 mode, but it can in c64 mode
-
This is what I'm thinking: First, we have to always start from a reset as the number of z80 cycles is known until the 8502 switches; or I assume you've figured that number out. An OUT (C),r takes 12 cycles but the 128 does the 1MHz write near the end of the instruction based on the starting state. If you start the timer in an EVEN state, and then wait an EVEN amount of cycles and then do an IN (C),r (also 12 cycles; same issue as the OUT with respect to the read timing) to read the timer, will there...
-
Okay fixed this, but before I commit, can you do a test for c64 mode? The only difference is you can't go back to c128 mode, but you can write something to the screen ram to say if it passed or not. We won't be able to use the debug cart, but it will be something anyways.
-
I was going to ask you to write a test for this; how serendipitous that you did. I'm curious how do you know the ODD or EVEN state when you run your test? Is there a way to determine this by some z80 code and reading the timer? This should be possible as the timer reads will run at 1MHz, but you may be able to offset the z80 IN instruction enough to figure it out. Right now, I'm getting inconsistencies in the test results as it appears it is running from either a starting ODD or EVEN. You should...
-
Just following up on this. Did the attached ROM image solve your issue?
-
x128 incorrectly reporting VDC ram
-
C128 8502<>Z80 CPU switch timing test
-
With real C128 hardware Z80 cannot access Char ROM
-
Is this okay to close now?
-
RAMLink kernal doesn't override internal function ROM
-
It shouldn't be this bad, but maybe it is a WSL thing. I have never used WSL. I think the long term plan for c1541 is to make it separate in some way.
-
Just keep adding those packages until you get it to work. I know it isn't ideal, but that is just the way these distros work. On the plus side, at least it is telling you what you need. Sometimes you have to figure it out. If you want to build it from source, I found that I needed these packages: subversion autoconf flex bison dos2unix texinfo texlive libgtk-3-dev libglew-dev libpulse-dev libasound2-dev libsdl2-dev libsdl2-image-dev texlive-plain-generic libevdev-dev Along with gcc, but I think that...
-
I forgot about c1541. I think you can just install a debian release of vice.
-
Okay. Here is a beginning timing suite. You will need WSL and a debian install. Unzip this attached ZIP file into a new folder and make sure you have "xa" and "z80asm" installed as well. Use a terminal to execute "make" in the folder and it will assemble and build the d64 and d81 files for you too. (it only does this is the sources files change) The 6502 files are .ASM and the Z80 files are .Z80. The Makefile is setup to assemble the 6502 code and then add the Z80 code to the end of it. The Makefile...
-
I'm working on a build environment for you, but I'm having trouble finding a z80 assembler with working macro features.
-
z80asm is available in Debian, so assuming you are using WSL, you may want to try that.
-
Can you try with "-cartramlink ramlink2.bin" instead of "-ramlink -ramlinkbios ramlink201.bin" instead?
-
For this level of code generation, you may want to look into makefiles and perhaps using Linux. VICE is compiled under linux even for the windows build as the batching process is significantly simplified. You could probably setup an easy build environment using WSL.
-
Hi. Thanks for all these tests, but there are a lot of them. This is a very good basis for a test suite. I'm sure you have already started creating some kind of skeleton API that does most of the work and all you have to do is put in the instructions you are testing. I would ask that you also include the debugcart function where you write to IO at $d7ff with a return value, 0 for good and >0 for fail. This value is returned by the vice executable once it is written to so the tests can be scripted....
-
More changes for bug #1979: Corrected more z80 timing issues
-
Try r45055. I got it working for your demo and alternative tests, but not your original ones. Still one value of 4 is off by 1 for those tests.
-
More changes for bug #1979: Aligned IO read/write operations to 1MHz
-
Ugh. Trailing white space. Get r45045. I'm thinking the timing issues now are based on when the timer is read in the IN execution. VICE emulates CPUs one instruction at a time; the Z80 on the c128 is clocked at 2MHz, but the memory and IO are at 1MHz. So depending on when the instruction "runs" with respect to the read from the CIA may be the problem. To test this, if you can add an "odd" number of cycle delays before the IN on measurements that are currently correct, it should make the measurements...
-
Fixed white space in r45044
-
Okay. I committed another patch that fixed the LDIR test and gets better results in all of your tests. See r45044. It seems the Z80 doesn't do clock stretching as all of the memory and IO operations work at 1MHz.
-
More changes for bug #1979: Fixed Z80 timing issues
-
Back to back EIs results in interrupts being delayed until one instruction after the last EI. See: https://floooh.github.io/2021/12/06/z80-instruction-timing.html and http://www.visual6502.org/JSSim/expert-z80.html?a=0&d=ed56fbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfb0000000000000000&a=38&d=c9&int0=48&steps=200&graphics=false So this doesn't run like you think it does. But I'm close to your results; I get FF9F right now.
-
So far, everything looks right, but as I said, I'm 1 cycle off without stretching. There are a lot of moving parts in VICE so it helps to have testers that focus on one thing. By removing clock stretching from the measurements, I can determine if the cycle count is proper and then move on from there. The most reliable way is to use the CIA timer on the 8502 and avoid the VIC for anything as x128 is not cycle exact, so anything with the raster may be an issue elsewhere. I'm trying just to focus on...
-
I've been doing a deep dive on the current state of the code and how the z80 clock relates to the 1MHz clock. I've been able to get closer to the LDIR test as the cycles counts weren't correct for that instruction in VICE, but I can't seem to get a firm grasp on the clock stretching. As such, I would prefer if you could avoid using any OUT/IN instructions at this point. Try to just use registers, ie. a series of increments to see what the register value should be in the interrupt service routine....
-
To be honest, I'm not sure if I got the whole interrupt thing right. I'm reading data sheets and other materials and it is a little vague. There is no tester for this stuff. So given that I'm at best a novice with Z80 coding and you clearly have more skills, you should develop a good tester for this. I think you are on track but should avoid the VIC and blank the screen. Just use the CIAs and fire interrupts at a particulars time to measure when the IRQ code runs via inspection of the CIA timers;...
-
Okay. I committed an initial fix for this in r45031. The halt is handled, but the timing results seem to look the same as z64k. I'm not exactly sure what you are doing here to derive these numbers, but I don't think the VIC and CIA are the best ways to do this because of the badlines. If you are testing instruction timing, I suggest you look at: textprogs/general/Lorenz-2.15/src/cputiming.s It uses a very creating way to test instruction timing. As far as I know, we don't have a way of verifying...
-
Initial fix for bug #1979; halt works, timing isn't perfect, but same results as z64k
-
Can I close this bug?
-
CMD-RTC devices behave different to real hardware
-
Okay. I committed the fix in r45025. Give it a try. Should also work on CMD smartmouse.
-
Fix for bug #1992: RTC on CMD FD/HD and RAMLink
-
Allow CMD smartmouse time/date to be read and written even if the mouse is not grabbed
-
Never mind. I just found the utilities disk and it doesn't look straight forward. I will just use that.
-
I'm almost ready to commit this, but I see there is a RTC module here for the CMD smart mouse. Could you put together the same test for that so I can correct it as well?
-
Okay. So I fixed this problem by adding in a second offset for the day of the week only. Now I have to fix the whole RTC saving feature so it also saves this new offset.
-
This is actually a problem with the real-time clock (RTC) core. I fixed the AM/PM problem so far on the CMDHD (I'm getting to CMDFDs soon), but the request to set arbitrary "day of the week" is much harder to address as the RTC just keeps track of the offset from the "real time" and your "preferred time" in seconds. The day of the week is simply calculated from that as in most modern systems. I personally would prefer the system knows the day of the week automatically. But from a testing perspective,...
-
I'll be looking into this. I will take me a bit to catch up on the z80 cpu code. I did some work with it before, but from what I can see right now, it doesn't handle halt correctly. It seems it just waits 4 cycles and moves on. It should wait for an interrupt, but it clearly doesn't. I will also have to be careful with this as the same core code relates to other z80 add-ons, like the commodore cpm cart.
-
x128 gets stuck when opening borders with Z80
-
RAMLink tester fixed for bug #1963
-
RAMLink kernal doesn't override internal function ROM
-
Okay. Your original message didn't state you were using an internal function rom, just that you noticed a problem in emulation. Regardless, this actual made me find a problem in VICE when it comes to internal function roms; when off, it doesn't show an open-circuit, which I fixed. My tester, rlhw128, only works if you don't have an internal function rom as it looks for open-circuit conditions as most people with a RL will have. However, just out of curiosity, your internal function rom should work...
-
Fix for bug #1963, also exposes open-circuit when internal function roms are off in x128
-
Okay, test 227 checks if the internal function rom at $8000 is open-circuit, which it is on my RL. Can you enter the "monitor" and type in "m 48000" a couple of times to see if the values are inconsistent? Can you do the same with "m 88000" (which is for the external function rom)?
-
Which RAMLink? 1 or 2? I assume when you say "1" you mean the HW rev 1, as listed on the bottom of the unit.
-
Here is an updated tester that will check the internal ROM as well. I worked on my RL. It should go up to 4166. I will start making the changes to VICE.
-
I don't know if it is in the testbench, but it is available in "testprogs/RAMLink".
-
Okay. I had a look at my testing code and I can verify it doesn't check the internal function ROM situation at all. I will modify it to do so, compare with my RL, and then adjust the VICE code to have the same behavior.
-
Okay. I had a look at my testing code and I can verify it doesn't check the internal ROM situation at all. I will modify it to do so, compare with my RL, and then adjust the VICE code to have the same behavior.
-
Try these test programs. The won't alter your RAMLINK contents, but they will require a reboot after. If they fail, the screen will go red, but let me know where the counter stops.
-
RAMLink and REU cannot be used together
-
Which ramlink rom are you using? I did a pretty thorough test on a real RL with 2.01, but I don't remember the degree to which I tested in the internal ROM as I didn't have one.
-
RAMLink kernal doesn't override internal function ROM
-
I’ve attached my “2.02” file which will detect larger REUs (16M) and GEORAMS (4M), but I warn you that it will screw up if you go beyond 16MB. CMD's firmware limits ramlink to a total of 16MB so if you did have more, it would break it up and favor the ramcard over other things and then use what is left of everthing else. So, to be safe, configure your system appropriately.
-
Yes, this seems like it would be a problem. Please go ahead and commit the change. My current changes would break everything else.
-
RamLink emulation is broken?
-
Not likely. I only gave it to one other person. Again, it isn't official, it is just a patch I made to deal with the REU and GEORAM. I didn't do any serious testing on it.
-
RamLink emulation is broken?
-
Should be fixed in r44566.
-
Fix for bug 1949; C64 ramlink disabled on alternating resets
-
The RL 2.01 firmware doesn't support 16MB REUs. They weren't around at the time, so the detection algorithm goes into an infinite loop. I made a simple patch that will detect 16MB REUs and 4MB GEORAMs. It is attached here if you want to try it. I don't suggest trying to use more than 16MB at once (ie. REU+RL) as it will probably fail.
1 >