|
Post by willymanilly on Mar 11, 2021 21:26:47 GMT
Please note when loading PRG files, the C128 emulator doesn't properly set the BASIC pointers after loading yet so some programs might fail.
Thanks for the tip. This is something I know I still need to resolve with loading PRG files. I plan on including options to inject file into memory (that's what it does now), create a virtual device, or dump file into a blank disk image and auto load from that but I always seem to get distracted with other aspects of the emulation with an ever growing list of improvements I want to do. Currently I've been focused on the Z80 emulation and I'm glad to report it is very close to being cycle accurate and should have correct undocumented flag behaviour for all instructions now. ZEXALL pass all tests as OK!
|
|
|
Post by willymanilly on Feb 19, 2021 12:43:48 GMT
The Z80 implementation on Z64K has had the least attention and I guess it's starting to show. Largely that was due to lack of documentation I could find on how the memory mapping Z80 mode works and having access to decent test programs. I guess I'll need to revisit having a look at the C128 schematics and PLA and maybe write a few test programs. I always welcome any test programs I can compare real hardware to emulation. Beside running CP/M and a few other simple programs, the only suite of Z80 test programs I've been able to find are on the VICE test repository
|
|
|
Post by willymanilly on Feb 15, 2021 21:18:33 GMT
The (famous?) "ibmfont.com" still drops into the monitor because of using "jp (ix)".
I generally try to fix issues as soon as they a brought to my attention. In saying that jp (ix) and jp (iy) are now implemented and I have confirmed ibmfont.com works now without triggering the monitor. There's a few other missing Z80 instructions I'm aware of which I'm happy to prioritise in implementing if requested. All these reports have been very welcome because when I get home from QLD (assuming I don't get stuck up here with short notice new COVID restrictions) I plan on giving the Z80 emulation a long overdue major update to implement missing instructions and improve timing.
|
|
|
Post by willymanilly on Feb 13, 2021 16:56:25 GMT
Seems this forum has "exceeded its attachment space limit" so easiest way would be to send to my personal email. Will pm you the details.
|
|
|
Post by willymanilly on Feb 7, 2021 11:35:28 GMT
Thanks for the update! The C128 CPM development now runs without the ramdisk workaround. I find the cycle exact nature of Z64k a great help in improving the 80column output.
I hope you will consider an option for (some) Z80 instructions if they will jump to the monitor (in itself a good idea)
I'm reviewing some of Z64K's missing Z80 instructions and I remember now I deliberately made all missing instructions currently trigger the monitor as a reminder to myself to implement them whenever they pop up. There's not many that aren't implemented so it totally slipped my mind to review them until you highlighted some of those instructions. I have just implemented HALT but haven't tested it's behaviour compared to real hardware yet. Do you have any programs you are willing to share that I can test with? I will implement the other missing instructions in the coming weeks.
|
|
|
Post by willymanilly on Feb 2, 2021 21:43:39 GMT
Thanks for the share. I watch part of the video and what I saw of how the RESET vector was shown to work is mostly incorrect. As we all know instructions don't start executing at $FFFC, instead $FFFC/$FFFD contains the location in memory where the first instruction is fetched. As far as I'm aware from research I've done to date is the RESET routine exactly the same cycles as a BRK statement except RW is not set to write during the stack cycles so nothing should be written to the stack during reset. The stack pointer is reset to 0 so it should have a value of $FD by the end of the RESET cycles. This has also been discussed at atariage.com/forums/topic/261488-reset-sp/ which includes a bin file (cartridge for Atari 2600) that does similar to what you suggested to test with the C64. For anyone interested Z64K uses the same code to handle BRK, Interrupts and RESET. Attached is the code (slightly modified) that Z64K uses. I've exclude code (...) not directly related to the BRK/Interrrupt/RESET cycles. The function updateBus() handles the actual reading/writing to memory. public void clockCycle(){ switch(cpuState){ .... case FETCH:fetchInstruction();break; case INTERRUPT:cpuState =INTERRUPT_1;P&=~0x10;break; case BRK:PC++; case INTERRUPT_1:RW=false; case RESET:DL=(PC>>8)&0xff;pushStack();cpuState =BRK_1;break; case BRK_1:DL=PC&0xff;pushStack();cpuState =BRK_2;break; case BRK_2:DL=P;pushStack();if(NMI.trigger){NMI.trigger=false;irqVector &=0xfffa;}cpuState =BRK_3;P|=0x10;break; case BRK_3:AB=irqVector;irqVector |=0x6;cpuState =BRK_4;fetchType=FETCH;RW=true;break; case BRK_4:P|=0x04;IRQ.trigger=IRQ.allowTrigger=false;SB=DL;AB=(AB&0xff00)|((AB+1)&0xff);cpuState=PC_FETCH;break; case PC_FETCH:PC=(DL<<8)|SB;AB=PC;cpuState=fetchType;break; .... } updateBus(); ... }
private void pushStack(){AB=0x100|SP--;SP&=0xff;}
public void reset(){ SP=0; irqVector=0xfffc; cpuState =RESET; IRQ.reset(); NMI.reset(); stopMask=0; RW=RDY=true; }
|
|
|
Post by willymanilly on Feb 1, 2021 21:28:46 GMT
I had a look and applied a quick fix to Version 2 of Z64K to use bits 7 and 6 of D506 for the DMA-target. I've uploaded it to the website. I haven't tested with Volley for 2 yet but it hasn't broken any of the REU tests available in Testbench. I will test Volley for 2* when I get home from work and look more in depth to the other requests then as well. *Update I've confirmed replays in Volley For Two work now.
|
|
|
Post by willymanilly on Feb 1, 2021 20:30:45 GMT
Thanks for the bug report, especially for the information on the REU issue for Volley For Two. I was wondering where I needed to start looking to get replays working. I will apply a fix sometime this week.
|
|
|
Post by willymanilly on Nov 30, 2020 13:11:45 GMT
The game and demo looks great! I had a few games of Hose it and really enjoyed trying out a few of the levels. Looking forward to playing some of the later levels. Well done on creating these using the VDC.
|
|
|
Reg 22
Nov 29, 2020 10:22:59 GMT
Post by willymanilly on Nov 29, 2020 10:22:59 GMT
|
|