B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 6:06 pm

hoglet wrote:I guess part of the reason for Sarah duplicating the 6502.c and 65tube.c was for efficiency, so the registers end up being global variables (known at link time) rather than members of a struct accessed via a pointer. It saves a level of indirection.


On that subject I note that some of the temporaries used during the execution of an emulated instruction are also globals. Compared to offsets from the stack pointer, as might be the case in unoptimised code, these would be faster but with local variables allocated to registers local variables would be faster.

One way to have the same code executing with a different set of global variables would be to use a common name in a body of code and the #define this to different actual variables in two further files each of which #includes the first file. I don't know if that particular boat has sailed, though, in that now 6502.c and 6502tube.c have their common ground and their differences.

I was suggesting the 65816 code for the tube 6502 because there can presumably be only one tube processor executing at a time, so if two of more logical tube processors, because they share code, share the registers that wouldn't be a practical problem and other things that are referenced in places through the code, like incrementing cycle counts, checking for interrupts, should be similar.

Bringing the main 6502 into the scheme would be harder because then we do need to have more than once instance of the same code running at the same time referring to different variables. That either means some macros and the #include trick or a struct to save state to when the processor is not executing (externalise, I assume, from your Z80 example) and then load these back into local variables (internalise), which we hope will be CPU registers, when this particular CPU runs again.

There is also the issue of polltime, i.e. checking if other modules need to be called because of the number of clock ticks that have passed.

One possibility would be a file that contains small, static, functions for all the instructions common to both one tube processor and one main processor, which is probably most of them. That could be #included in both 65816.c and in 6502.c each of which use #define to adjust for such differences as what globals are used for the registers, which cycle count to increase, polltime, and the memory access functions.

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 6:14 pm

OK, I understand your point about merging the 6502tube and 65816. I guess that would make sense if the 65816 is stable.

Not sure I see this as a high priority though.

Also, I haven't actually tried running any of the test suites against the 65816 yet. Have you?

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 6:25 pm

hoglet wrote:OK, I understand your point about merging the 6502tube and 65816. I guess that would make sense if the 65816 is stable.

Not sure I see this as a high priority though.

Also, I haven't actually tried running any of the test suites against the 65816 yet. Have you?

Dave


I haven't tried the test suite on it. We;d need to be sure exactly how the 6502 emulation mode is supposed to behave - presumably some kind of 65C02 but, from what I remember, not with the Rockwell extensions.

So, the job from the perspective of adding a "Rockwell 65C02" mode is to copy in the code for the extra instructions as functions, add another mode and associated jump table and then test as a 65C02.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 6:28 pm

I reckon push the fix for the ZP wrap around. As you say there is no urgency to refactor the tube 6502 implementation, I just mentioned it as it would be good to do before, rather than after, adding another copy/paste of the code for another slightly different 6502 tube variant.

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 6:59 pm

Coeus wrote:I reckon push the fix for the ZP wrap around. As you say there is no urgency to refactor the tube 6502 implementation, I just mentioned it as it would be good to do before, rather than after, adding another copy/paste of the code for another slightly different 6502 tube variant.

That's pushed now.

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 8:27 pm

hoglet wrote:The remaining issue we have to deal with is I whether to extend 6502tube.c with implementations of:
x7 - RMB/SMB zp
xF - BBR/BBS zp, rel

Both my original Cheese Wedges use the G65SC02, which don't have them.

But the Master Turbo internal Co Pro uses a R65C102, which does have them.

Dave


So this was what set me down the line of thinking "The 65816 code could be extended to emulate different varieties of processor", but if we didn't do that so we had to pick one, i.e. tube6502 had to be either the G65SC02 or a R65C102 which is more likely, that someone would write code expecting the Rockwell instructions to be implemented and rely on them working or would include one of those opcodes as a NOP despite the fact there is a proper, dedicate NOP code for that purpose. That means I am thinking maybe better to include the Rockwell instructions.

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 8:35 pm

Another option is to have both implementations of those instructions present, and switch between them an run time by testing a "rockwell mode" flag.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 8:36 pm

I tried the test suite (the ctr menu-driven one) on the 65816 - it is detected as a 65C02 but I choose the 65SC02 because the 65816 does not implement the Rockwell instructions - those opcodes are used for something else. It still doesn't pass:

Screenshot from 2017-04-02 21-33-59.png


I did think I was ok interpreting the output but this case seems to have no PCH value.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 8:37 pm

hoglet wrote:Another option is to have both implementations of those instructions present, and switch between them an run time by testing a "rockwell mode" flag.


There is a MASTER flag already. It might be better to #define what actually goes into the if () but that would be a good default to start with as it saves someone having to choose from a menu.

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 8:47 pm

Coeus wrote:I tried the test suite (the ctr menu-driven one) on the 65816 - it is detected as a 65C02 but I choose the 65SC02 because the 65816 does not implement the Rockwell instructions - those opcodes are used for something else. It still doesn't pass:

Screenshot from 2017-04-02 21-33-59.png

I did think I was ok interpreting the output but this case seems to have no PCH value.

This usually implies a crash of some some that messes up the stack.

The only clue as to it's whereabouts is &1900 (&0E) which I think means it's failing in test num 14. At a guess, that's here:
https://github.com/mungre/beeb6502test/ ... .lst#L2344

It's kind of hard to tell, as the output of macros (like next_test) is not shown in the listing.

Dave

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 8:57 pm

Actually, I'm wrong about the test case number.

I think this will need to be run with the debugger.

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 9:07 pm

Ok, I was just doing that.

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 9:10 pm

Coeus wrote:Ok, I was just doing that.

Good luck!

FYI, it seems a couple of gremlins have crept into the sf/debugger branch on Windows.

The Makefile.win needs darm adding to VPATH at the top.

And once running, you no longer get a choice of which core to attach the debugger too.

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 9:24 pm

hoglet wrote:And once running, you no longer get a choice of which core to attach the debugger too.


That was supposed to be a feature - there's now a -debugtube option which should debug whatever the current tube processor is. I am not sure how well that is coping with switching tube processor without a re-start.

It looks like the failure is in test 13 which tests TSX and TXS but also checks for stack wrap-around.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 10:19 pm

So the first error was that the test suite is testing for the stack pointer wrapping around in page 1. The 65816 emulation was using the 16 bit stack pointer with the upper byte pre-set to 01 which therefore didn't wrap. That was easy enough to fix, though I have not pushed it anywhere yet. The next issue is the same ZP wrap around but I'd have to check what the 65816 does there.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Tue Apr 04, 2017 11:56 am

Dave,

Getting the 65816 to pass the test suite is proving a little harder than I first thought. What do you reckon? Implement the Rockwell instructions on the tune 6502 and then merge and come back to the 65816 later?

User avatar
hoglet
Posts: 6352
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em

Postby hoglet » Tue Apr 04, 2017 12:09 pm

Coeus wrote:Getting the 65816 to pass the test suite is proving a little harder than I first thought. What do you reckon? Implement the Rockwell instructions on the tune 6502 and then merge and come back to the 65816 later?

Yes, I would be inclined just to add them to tube_6502.c. Ideally they would be enabled by a hardware configuration option somewhere, but I guess defaulting to always there isn't too bad. It's what PiTubeDirect does...

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Wed Apr 05, 2017 5:28 pm

I have merged the sf/bcdfix branch into master. This fixes the BCD mode of ADC/SBC, zero page wrap and adds the Rockwell RMB/SMB and BBR/BBS instructions to the tube 6502. It passes the test suite posted by ctr https://github.com/mungre/beeb6502test/ ... 02test.ssd on Linux and on Windows for a Model B with and without tube 6502 and for a Master and Master Turbo.

User avatar
oss003
Posts: 2515
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: B-Em

Postby oss003 » Sun Apr 09, 2017 10:06 am

In Atomulator, the display wasn't updated when a BREAK occured in debugging mode.
Also when stepping trough the code, the display wasn't updated.
This was very anoying when you were doing graphic stuff because you couldn't see the actual situation or changes.

Dave changed this in Atomulator and this is working great.
I think it's also a valuable addition to B-em's debugger.

Greetings
Kees

User avatar
tricky
Posts: 1811
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: B-Em

Postby tricky » Sun Apr 09, 2017 10:23 am

When you say updating the display while debugging, do you mean showing what would be on screen if the change to memory had been scanned out?

I often want the display to be updated while debugging, as per jsbeeb, but for games with palette changes, mode changes or vertical rupture, it is hard to know where that memory will be on screen, in which colours and in what mode it will be when displayed.

If a second "screen" were added, with a configurable mode, palette and start address, defaulting to match the main screen, that would probably cover it.

Or have I missed the point?

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 09, 2017 10:24 am

oss003 wrote:In Atomulator, the display wasn't updated when a BREAK occured in debugging mode.
Also when stepping trough the code, the display wasn't updated.


Ok, I know the reason it currently works the way it does. Synchronisation of the whole machine is effectively controlled by the emulated 6502 which counts clock cycles and calls other bits of the emulator after the appropriate number of clock cycles have completed. As the debugger has effectively stopped the 6502 awaiting your instruction that effectively stops everything in the emulator except the debugger itself until you issue a debugging command.

I will check out what Dave had done in Atomulator.

User avatar
oss003
Posts: 2515
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: B-Em

Postby oss003 » Sun Apr 09, 2017 10:41 am

tricky wrote:When you say updating the display while debugging, do you mean showing what would be on screen if the change to memory had been scanned out?

I mean that the emulated display shows the actual video memory state when the processor is stopped.
Normally the display is only updated 50 times/sec so if the processor is stopped between two display updates, you can not see the display changes if the processor is stopped. It's very usefull to see what's actually changed in the display while stepping sprite- or graphic routines.

I realize that this is a lot more complex than for the Atom but this is what Dave changed in Atomulator: https://github.com/hoglet67/Atomulator/ ... be68f37141

Greetings
Kees

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 09, 2017 10:53 am

So what Dave has done in Atomulator is to force an extra video scan each time the debugger is entered.

For the standard display modes, or even a non-standard mode that is the same for the whole screen, this would work fine.

For split modes, i.e. those where the 6845 is reprogrammed part way through the video scan this would display a mess. It would be easy enough to make it an option, though.

I will have a go later, when I am at the PC rather than on the phone.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sun Apr 09, 2017 12:52 pm

Ok, I have pushed a version that adds the extra screen refresh as an option, enabled by default. To turn it on/off use the vrefresh debugger command.

The source code is in GitHub: https://github.com/stardot/b-em/tree/sf/debugging. If you clone it remember to switch to the sf/debugging branch. I also attach a ready to run Windows version which you should be able to unzip and run in-place or extract the B-Em.exe file and use as part of an existing installation.

This is part of a debugging branch I am working on which, other than this feature, should work the same as master for debugging on the main 6502 but also adds a -debugtube command line option which enables debugging on the tube processor (all of them, 6502, 65816, Z80, 80186, 32016 and ARM).

Another new feature is the 'n' debugger command (styled after GDB). The standard single-step executes exactly one instruction. The 'n' command instead works out the length of the instruction about to be executed (the one displayed) and sets a temporary breakpoint at the next instruction. This behaves slightly differently in that provided you are about to execute a JSR instruction it will execute the whole subroutine and then return to the debugger at the instruction after the JSR. Also when about to execute a branch that continues a loop by branching backwards, 'n' will execute the loop until it finishes and then stop.
Attachments
b-em-debugging.zip
(8.69 MiB) Downloaded 16 times

User avatar
oss003
Posts: 2515
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: B-Em

Postby oss003 » Sun Apr 09, 2017 5:50 pm

Thanks for the upload, I had a try and these are my remarks:

- vrefresh is working fine with a BREAK pointer set and the Continue command
- vrefresh is not working in stepmode
- vrefresh is not working on a WRITEM to screen memory command in debug mode

General remarks:
- There are 2 spaces in front of the >-prompt in the debugger
- In the previous versions, the last command was repeated when you press RETURN
- Re-entering debug mode with the BREAK option in the pull-down menu doesn't work
- WLIST is a command to display the Watchpoints but isn't listed in the help (?) screen

Greetings
Kees

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Mon Apr 10, 2017 1:28 am

oss003 wrote:Thanks for the upload, I had a try and these are my remarks:

- vrefresh is working fine with a BREAK pointer set and the Continue command
- vrefresh is not working in stepmode


What I found was that whenever single-stepping it would immediately enter the interrupt service routine. That was because doing a complete screen refresh trigger the frame timer on the SYS VIA. I solved this by running the refresh without triggering the timer. The timer is still triggered by the refresh that happens in the normal course of events.

oss003 wrote:- vrefresh is not working on a WRITEM to screen memory command in debug mode


That should be working now.

oss003 wrote:General remarks:
- There are 2 spaces in front of the >-prompt in the debugger
- In the previous versions, the last command was repeated when you press RETURN
- Re-entering debug mode with the BREAK option in the pull-down menu doesn't work
- WLIST is a command to display the Watchpoints but isn't listed in the help (?) screen


These should also be fixed. Latest source at https://github.com/stardot/b-em/tree/sf/debugging

New windows build attached.
Attachments
b-em-debugging.zip
(8.69 MiB) Downloaded 18 times

User avatar
oss003
Posts: 2515
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: B-Em

Postby oss003 » Mon Apr 10, 2017 7:18 pm

Nice job Coeus =D> =D>
Everything is working fine now.

Greetings
Kees

User avatar
bakoulis
Posts: 229
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece

Re: B-Em

Postby bakoulis » Mon Apr 10, 2017 10:19 pm

If now working as it should, is time to move it from /sf/debugging at the main stardot/b-em.
:wink:
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em

Postby Coeus » Sat Apr 15, 2017 12:00 pm

Ok, so the sf/debugging branch is now merged to master. Thanks to Kees for the regression test.

Here is a revised Windows build - this is the same B-Em code but resolves an issue with some sideays ROMs loading twice because there were two copies of them in the ZIP distribution.
Attachments
b-em-master.zip
(8.59 MiB) Downloaded 23 times

User avatar
bakoulis
Posts: 229
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece

Re: B-Em

Postby bakoulis » Sat Apr 15, 2017 1:06 pm

Something must have been broke here:

Code: Select all

  CC       b_em-via.o
  CC       b_em-vidalleg.o
  CC       b_em-video.o
  CC       b_em-wd1770.o
  CC       b_em-x86.o
x86.c: In function ‘x86_dbg_disassemble’:
x86.c:196:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
    for (int i = 0; i < MAXOPLEN; i++) {
    ^
x86.c:196:4: note: use option -std=c99 or -std=gnu99 to compile your code
x86.c: In function ‘x86_init’:
x86.c:647:14: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
         fread(x86rom,0x4000,1,f);
              ^
make[1]: *** [b_em-x86.o] Error 1
make[1]: Leaving directory `/home/takis/b-em-master/src'
make: *** [all-recursive] Error 1


LINUX MINT 17.3 MATE 32ΒΙΤ
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 2 guests