Code: Select all
DIM code% 256, data% 512
FOR opt%=0 TO 3 STEP 3
P%=code%
[OPT opt%
LDY #&FF
LDA (&70),Y
STA (&72),Y
RTS
]
NEXT
?&70=&75:?&71=&FF
?&72=data% MOD 256:?&73=data% DIV 256
FOR I%=0 TO 255
?&74=I%
?(data%+&FF)=0
CALL code%
IF I%<>?(data%+&FF) THEN PRINT "Failed (";I%;")":END
NEXT
I'm going to be away from my Windows development system for the next few days. As a birthday present from myself I've done the last bit of coding I had outstanding over Christmas after getting distracted by some bugs in the IDE implementation. It can be merged into the main trunk by somebody who knows how to do that.tricky wrote:There is a github stardot beebem repository, but I'm not sure all the changes have been merged there.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_I'm currently preparing a BeebEm 4.15 release at https://github.com/stardot/beebem-windows. It would be nice to include a fix for this if you'd like to prepare a patch or send a pull request.SteveF wrote:While playing around with PLASMA (http://www.stardot.org.uk/forums/viewto ... 181279cfa5) I encountered a mysterious bug where code worked fine on b-em but consistently failed in BeebEm (Windows, 4.14, February 2012). It looks as though "LDA (zp),Y" doesn't wrap around to zero page if the two bytes at zp contain an address of the form &FFxx and &FFxx+Y>&FFFF.
[...]
Is anyone maintaining BeebEm at the moment? I'd be happy to try to come up with a patch if someone will take it...
If you'd like to include your changes in 4.15, could you send a pull request please? I tried building your source, but I think it may be missing the changes to the resource file BeebEm.rc.jgharston wrote:As a birthday present from myself I've done the last bit of coding I had outstanding over Christmas after getting distracted by some bugs in the IDE implementation. It can be merged into the main trunk by somebody who knows how to do that.
BeebEm414jgh.zip
The main updates are:
* Added &x3 and &03 emulator filing system traps so a VDFS-type filing system can access the host file system
* Fixed some bugs in IDE support returning incorrect status and selecting invalid drives
See CHANGES-jgh.txt for more details
I've made a start on it, with help from ctr: https://github.com/stardot/beebem-windows/pull/9, please take a look and add your patch there.SteveF wrote:I've only just seen this, sorry! I will see if I can knock up a patch this weekend (main stumbling block is likely to be getting a Windows compiler installed...)
I don't think there's anything left for me to patch, is there? It looks like the commit https://github.com/stardot/beebem-windo ... 6674e41d88 should fix this. I haven't tested it but it certainly looks right. Thanks for doing this!chrisn wrote:I've made a start on it, with help from ctr: https://github.com/stardot/beebem-windows/pull/9, please take a look and add your patch there.SteveF wrote:I've only just seen this, sorry! I will see if I can knock up a patch this weekend (main stumbling block is likely to be getting a Windows compiler installed...)
There may be more changes needed, from the comment from ctr / mungre:SteveF wrote:I don't think there's anything left for me to patch, is there? It looks like the commit https://github.com/stardot/beebem-windo ... 6674e41d88 should fix this. I haven't tested it but it certainly looks right. Thanks for doing this!
If you think there's something I still need to do (you say "add your patch there"), please let me know...
Cheers.
Steve
I'm hoping that using a 6502 test suite will highlight if this is indeed another bug.mungre wrote:I think there's another bug in the original code!
The high byte of the address comes from WholeRam[ZPAddr+1] . If ZPAddr is 0xFF then the high byte will come from 0x100, which doesn't seem like the kind of thing the 6502 would do.
I've made an ssd that detects what kind of beeb it's running on and runs Klaus Dormann's and Bruce Clark's tests. Unfortunately, they don't cover these two edge cases so I just need to add tests for them.chrisn wrote:I'm hoping that using a 6502 test suite will highlight if this is indeed another bug.
Nice work! FWIW I've tried this on jsbeeb and it passes there.ctr wrote:The code tests that lda(&ff),y loads the base address from &ff and &00. beebem currently fails this test. I expect a real 6502 to pass it, but I don't have a beeb to confirm it.
Excellent, thanks!ctr wrote:I've added tests for wrapping at the top of the address space and wrapping at lda(&ff),y. There is a new SSD here.
The code tests that lda(&ff),y loads the base address from &ff and &00. beebem currently fails this test. I expect a real 6502 to pass it, but I don't have a beeb to confirm it.
It's worth noting that this behaviour isn't documented and differs between the 6502 and 65C02, so software tends not to rely on it. Anyway, it would be near the bottom of my list for fixing!chrisn wrote:It looks like we have a separate issue with BCD in BeebEm though...
You can get the error address from PCL and PCH in the error output. I've added the assembler listing files to github for the 6502 and 65C02 tests. Look up the address in the listing to see what's failing.SteveF wrote:b-em (both my old-ish local build of 2.2 and the master branch at https://github.com/stardot/b-em) fail this almost immediately. I'll post something about this in the b-em thread...
Code: Select all
static void ADC_CMOS(M6502 *s) {
if(s->p.bits.d) {
unsigned tmp=(s->a&0xfu)+(s->data&0xfu)+s->p.bits.c;
if(tmp>9) {
tmp+=6;
}
if(tmp<=0xf) {
tmp=(tmp&0xf)+(s->a&0xf0)+(s->data&0xf0);
} else {
tmp=(tmp&0xf)+(s->a&0xf0)+(s->data&0xf0)+0x10;
}
s->p.bits.v=((s->a^tmp)&(~s->a^s->data)&0x80)!=0;
s->p.bits.c=0;
if((tmp&0x1f0)>0x90) {
tmp+=0x60;
s->p.bits.c=1;
}
s->a=(uint8_t)tmp;
SetNZ(s,s->a);
} else {
M6502Word result;
result.w=s->a+s->data+s->p.bits.c;
SetNZ(s,result.b.l);
s->p.bits.c=result.b.h>0;
s->p.bits.v=(~(s->a^s->data)&(s->a^result.b.l)&0x80)!=0;
s->a=result.b.l;
}
}
static void SBC(M6502 *s) {
M6502Word result;
result.w=s->a+(uint8_t)~s->data+s->p.bits.c;
if(s->p.bits.d) {
unsigned tmp=(s->a&0xfu)-(s->data&0xfu)-(!s->p.bits.c);
if(tmp&0x10) {
tmp=((tmp-6u)&0xfu)|((s->a&0xf0u)-(s->data&0xf0u)-0x10u);
} else {
tmp=(tmp&0xfu)|((s->a&0xf0u)-(s->data&0xf0u));
}
if(tmp&0x100) {
tmp-=0x60;
}
SetNZ(s,result.b.l);
s->p.bits.c=result.b.h>0;
s->p.bits.v=(((s->a^result.b.l)&0x80)&&((s->a^s->data)&0x80))!=0;
s->a=(uint8_t)tmp;
} else {
SetNZ(s,result.b.l);
s->p.bits.c=result.b.h>0;
s->p.bits.v=((s->a^s->data)&(s->a^result.b.l)&0x80)!=0;
s->a=result.b.l;
}
}
- my recollection being that I started with the 64doc code and the results from my Master, and that it was mostly obvious what was going on, but there were still a few cases that I couldn't seem to figure out on my own.
Code: Select all
regs Y X A PS PCLPCH
01FA 42 01 FF 7D 10 2D
000A 00 00 00 00 00 00 00
1900 00 00 06 00 00 00 00 00 00 00
It's failing on opcode 7, which is a NOP on the 65SC02 and RMB0 on the 65C02. 6502test.ssd uses the same test for the master and the second processor and it targets the Master's 65SC02. But I guess that's not right for the second processor.tom_seddon wrote:I tried 6502test.ssd on my Master 128 and in my emulator (both in B and M128 modes) and it passed in all 3 cases.
My real B is currently dead so no results from that I'm afraid
I also tried it with a cheese wedge 6502 2nd processor, and ReCo6502Mini, and it failed in both cases in the 65C02 opcode test:
Code: Select all
regs Y X A PS PCLPCH 01FA 42 01 FF 7D 10 2D 000A 00 00 00 00 00 00 00 1900 00 00 06 00 00 00 00 00 00 00
Sure - passes on both ReCo6502Mini and cheese wedge.ctr wrote:Can you try this older one on the cheese wedge? It targets the 65C02. If it works I'll update the ssd to include different tests for the master and second processor.
Thank you, that's really helpful. There's room on the disk for tests for both the cheese wedge and the ReCo6502Mini so I might as well add them both. But maybe not tonight.tom_seddon wrote:Sure - passes on both ReCo6502Mini and cheese wedge.ctr wrote:Can you try this older one on the cheese wedge? It targets the 65C02. If it works I'll update the ssd to include different tests for the master and second processor.
Your mention of RMB reminded me of something, so I looked back through my notebook and found some notes on this from when I was trying to get the Klaus Dormann test suite working: (I didn't try to get the full set of tests working on the real BBC - I just did some quick tests with a few key opcodes, going by the equs in the source code, to see whether they were NOPs or something else)
- M128 (G65SC12?): no Rockwell instructions, no WDC instructions
- cheese wedge (R65C02?): Rockwell instructions, no WDC instructions
- ReCo6502Mini (W65C02?): Rockwell instructions, WDC instructions (I didn't do any particular tests on the WDC instructions, but they didn't seem to be simple NOPs)
The proper Master Turbo had a R65C102, so I assume it's the same as the cheese wedge.
Code: Select all
x7 - RMB/SMB zp
xF - BBR/BBS zp, rel
Blame this on my UI. If a second-processor is present then the test runs there. It tests the CPU you pick in the menu.hoglet wrote:Ctr,
Thanks for the updated DORMANN tests - B-Em is afflicted with this bug as well.
One other thing I'm finding is that when testing a real cheese wedge with a G65SC02 there is no way from the menu to force the 65SC02 test suite to run. So it's failing due to the lack of the Rockwell/WDC extensions:It's probably worth having this be selectable.Code: Select all
x7 - RMB/SMB zp xF - BBR/BBS zp, rel
FYI, My cheese wedge is like this one:
http://chrisacorns.computinghistory.org ... rocFL.html
Dave
I tried this, but it doesn't seen to have the desired effect. It always runs the 65C02 test. Can you try this as well?ctr wrote: So if a second-processor is connected and you select the Master (press "2") then it will run the 65SC02 test on the second-processor.
Sorry, you're right, I broke the menu in my last update. I've pushed a new version to github. Without the menu rewording yet.hoglet wrote:I tried this, but it doesn't seen to have the desired effect. It always runs the 65C02 test. Can you try this as well?ctr wrote: So if a second-processor is connected and you select the Master (press "2") then it will run the 65SC02 test on the second-processor.
Dave
Oops, didn't realise they used different chips! - presumably they just bought whatever they could get hold of. I had a quick skim through the manual and indeed, it doesn't even mention that you might have a CMOS one in the first place ;)hoglet wrote:FYI, My cheese wedge is like this one:
http://chrisacorns.computinghistory.org ... rocFL.html