B-Em

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
fordp
Posts: 877
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em

Postby fordp » Sun Mar 19, 2017 9:25 pm

hoglet wrote:Ford,

Are you aware of the way that MMFS (and the earlier MMBEEB) is supported in BeebEm?

It's not commonly used, but it does in fact work.

How are you thinking of doing it here?

Dave


I have not used BeebEm so no. But yes my ideas are basically to support MMB files in B-Em and how best to do that,
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby Coeus » Sun Mar 19, 2017 9:40 pm

fordp wrote:
Coeus wrote:I have been reading ssd.c I think I can see what I would like to do. I dare not say here as the pixies will have it written overnight :(


Bear in mind the wd1770 enhancement I mentioned replaces ssd.c (including both SSD and DSD media) and adf.c with a new file, sdf.c, nmemonic Simple Disk Formats (as opposed to FDI). That was because I found the ADF module didn't handle double-density media that were not ADFS and I then noted that all three of these are just sectors in a file - essentially the same code but with different numbers for tracks/sectors/sides hard-coded into it, so wearing my rationalisation hat I thought why not have one copy of the code and simply parameterise the geometry for the particular media loaded? That then paves the way to load such as the Watford DDFS media etc. That module is at https://github.com/SteveFosdick/b-em/bl ... /src/sdf.c

But anyway, were you waiting for me to implement command passthough? Of for us to agree it is a good idea as I know Dave has reservations?

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

Re: B-Em

Postby Coeus » Sun Mar 19, 2017 9:54 pm

hoglet wrote:For reference, here is the MMBEEB.DLL source code:


So to summarise this emulates an SD card interface so that the real MMFS ROM can be run within the emulator. That doesn't require *command passthrough.

User avatar
fordp
Posts: 877
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em

Postby fordp » Sun Mar 19, 2017 9:55 pm

My ideas are dependant on the pass through feature.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby Coeus » Sun Mar 19, 2017 10:17 pm

fordp wrote:My ideas are dependant on the pass through feature.


So, from our previous discussion I think we were agreed that the way forward was for the existing VDFS ROM (vdfs.s in B-Em github) to pass the unrecognised command call from the OS through the existing trap mechanism used by VDFS. That means it ends up in a case statement towards the end of the vdfs.c file which can dispatch it to a routine of your writing.

But you didn't say if you wanted me to implement that bit, leaving you to fill in the code for the routine being called with an unrecognised command, whether you'd do it yourself, or if you were waiting for greater consensus as to whether this pass-though idea is a good one.

I know Dave mentioned the hazard of discs which rely on B-Em-only features. I am not sure how different that is from discs that rely on having a particular ROM installed. Perhaps this is something that falls more into the domain of the curator of an archive to set a policy on whether submissions are welcome for discs that don't work on a "standard" machine, and if such things are allowed, how they are marked as such so people don't waste their time downloading them to find they don't work. Certainly BITD I created discs with a selection of stuff and a menu that used the particular ROMs I had in my machine but that was before the days of sharing such things on the Internet.

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

Re: B-Em

Postby hoglet » Sun Mar 19, 2017 10:23 pm

Coeus wrote:So to summarise this emulates an SD card interface so that the real MMFS ROM can be run within the emulator. That doesn't require *command passthrough.

Almost...

You are right that it doesn't require passthrough.

But it does assume the use of a Memory Mapped SPI interface (essentially just a 1 byte at R/W port &FE18).

Now, such a piece of hardware I think did actually once exist, but it's not the way most people connect SD Cards to their Beeb (i.e. via a 6522 based user port).

MMFS supports three low level interfaces:
- a 6522 connected SD Card
- a memory mapped SPI connected SD Card
- a Elk Plus One printer port connected SD Card

Each of these is a different MMFS rom (and there are actually variants with the class):
https://github.com/hoglet67/MMFS/wiki/Release-structure

95% of MMFS is the same, just the bottom 5% varies.

Dave

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

Re: B-Em

Postby Coeus » Sun Mar 19, 2017 10:37 pm

hoglet wrote:Each of these is a different MMFS rom (and there are actually variants with the class):
https://github.com/hoglet67/MMFS/wiki/Release-structure


On the question of the different versions I notice there is a sideways RAM version which, I gather, expects to use RAM at the end of its own ROM slot, i.e. it expects to run from sideways RAM itself. How would it get into sideways RAM in the first place? I don't have the issue, at the moment, as I don't have sideways RAM, at the moment, but for me the attraction of the SD card interface is that it works reliably whereas my real floppy drives really need cleaning.

User avatar
fordp
Posts: 877
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em

Postby fordp » Sun Mar 19, 2017 11:13 pm

Coeus wrote:
hoglet wrote:Each of these is a different MMFS rom (and there are actually variants with the class):
https://github.com/hoglet67/MMFS/wiki/Release-structure


On the question of the different versions I notice there is a sideways RAM version which, I gather, expects to use RAM at the end of its own ROM slot, i.e. it expects to run from sideways RAM itself. How would it get into sideways RAM in the first place? I don't have the issue, at the moment, as I don't have sideways RAM, at the moment, but for me the attraction of the SD card interface is that it works reliably whereas my real floppy drives really need cleaning.


I am guessing it runs from Battery Backed RAM.

Anyway my idea was to implement the MMB file without using the MMFS ROM but just the regular DFS. The disc changing is then handled by B-Em using the passed through star commands. I like the fact that you get the good bits of MMFS without a different ROM and can mix disc images in SSD DSD and encapsulated within MMB files.

Again like most of my ideas they are just things that interest me. They are are maybe not the best way, and they are certainly not the only way. This is a hobby so I just like to tinker. If other people like it then it can get pushed in to the B-Em main line. I am happy to work on my branch.

I am also interested to try VS Code on Ubuntu Linux as an IDE for this project.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: B-Em

Postby hoglet » Mon Mar 20, 2017 7:17 am

Coeus wrote:On the question of the different versions I notice there is a sideways RAM version which, I gather, expects to use RAM at the end of its own ROM slot, i.e. it expects to run from sideways RAM itself. How would it get into sideways RAM in the first place?

As Ford says, the main way is battery backed RAM.

The IFEL RAM ROM board has this:
http://sweh.spuddy.org/Beeb/Ram_Rom/

I also use it in ElectronFPGA, where a small (hardware) bootstrap loader loads it into a sideways RAM slots. It was this use case that led me to get involved with MMFS in the first place, as I had ElectronFPGA working (ish) but no way to actually load programs.

Dave

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

Re: B-Em

Postby Coeus » Mon Mar 20, 2017 1:13 pm

Ok, I've e-mailed the seller of that board. That does seem to be the best featured one I have seen.

The other option I have been looking at is the one viewtopic.php?f=3&t=12465#p163748 though they don't appear to feature battery backup. If I can't get one with battery backup, the other idea that occurs to me, based on your mentioning a bootstrap, would be to put the RAM version into a ROM with a small boot loader first, i.e. the bit that actually responds to the OS service calls. I gather there is about 4K spare - that has to be enough for a boot loader and I wonder if it is even enough to put back the missing ROMs command.

A more flexible option, I guess, would be to have a boot loader that loads the full ROM image from the SD card, for example by looking for MMFS.ROM as a FAT file, as that allows updating to a new version just by copying to the SD card. That would presumably be more complicated but it looks like the source code for MMFS is already structured so pieces of it can be put together in different ways.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: B-Em

Postby SteveF » Sat Apr 01, 2017 9:46 pm

I tried the 6502test.ssd from ctr's latest post in the thread at viewtopic.php?f=4&t=12351 on a copy of b-em built from the https://github.com/stardot/b-em master branch (commit 3c84479aa2f25bd6c8ab7db5b0ffd24c6fe5b84b) and it fails almost immediately:

Screenshot from 2017-04-01 22-45-11.png

I haven't investigated this yet, if no one else does I will perhaps have a look at it tomorrow.

(An old-ish build of b-em 2.2 I have lying around also fails in the same way, so it doesn't look like this is a new bug introduced by any recent changes.)

Cheers.

Steve

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 6:50 am

Regarding the BCD issues, I fixed some of these in Atomulator a while back:
https://github.com/hoglet67/Atomulator/ ... 4ed6d3?w=1

It looks like the same fix could possibly be applied to B-Em, as the ADC and SBC macros look similar.

FYI, the test suite I was using is here:
viewtopic.php?p=97168#p97168

(The test source is here)

Dave

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

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 9:11 am

When I last looked at this the failure was in executing in D mode when one or both of the inputs was not valid BCD. I did have a go at fixing it but the few things I tried broke the behavior for valid inputs so I left as-is as the lesser evil. It would be good to fix this though.

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

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 10:26 am

Ok, I have got this to the point where the main 6502 and the tube 6502 run the test program Dave linked - see https://github.com/stardot/b-em/tree/sf/bcdfix. Thanks, Dave, for the link to you fix for Atomulator - that did the trick.

It does not pass the test program Dave linked, at least for ADC which is as far as I got, for the 65C02 in the master. I am wondering if the test program is valid for a 65C02?

I am not running ctr's tests.

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

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 10:55 am

And already that's a fail. I am not sure how to interpret the result, though. How do I work out what's failing. This is on the main 6502:

Screenshot from 2017-04-02 11-54-00.png


This is on the master:

Screenshot from 2017-04-02 11-56-41.png


And this is on the tube 6502:

Screenshot from 2017-04-02 11-58-33.png


but the test program says it intends to test the tube processor as a 65C02 whereas I think B-Em emulates a normal (NMOS) 6502. Was there more than one 6502 co-processor? Was, for example, the original cheese wedge a 6502 and the internal master 6502 co-processor another 65C02?
Last edited by Coeus on Sun Apr 02, 2017 11:02 am, edited 1 time in total.

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 10:56 am

Coeus wrote:Thanks, Dave, for the link to you fix for Atomulator - that did the trick. It does not work, at least for ADC which is as far as I got, for the 65C02 version of the ADC macro. I am wondering now if that test suite is valid for the 65C02.

I just tested this version of the test suite:
https://github.com/hoglet67/AtomSoftwar ... CDTEST.ssd
on my real Master 128, and it auto-detected the 65C02 and the suite passes.

With your sf/bcdfix I get:
BCD1.png

BCD2.png

So the NMOS 6502 is now passing, but SBC in the CMOS 65C02 is failing.

If you look at the code in B-Em, it seems there are two sets of macros:
- ADC/SBC - for the NMOS 6502, and
- ADCc/SBCc - for the CMOS 65C02

Am I right in thinking you have just patched the first of these?

I've just tried patching the second ones, and the SBC test is getting a bit further, but still fails:
BCD3.png

I'll work though this specific case to try to see what's going wrong.

Dave

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 11:00 am

Steve,

Coeus wrote:It does not pass the test program Dave linked, at least for ADC which is as far as I got, for the 65C02 in the master. I am wondering if the test program is valid for a 65C02?

Sorry, I may have linked to an old version of the BCD test suite. Please use this version instead:
https://github.com/hoglet67/AtomSoftwar ... CDTEST.ssd

Dave

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

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 11:04 am

Thanks, Dave. Yes, I did see that the 65C02 macros were different hence the assumption that what was valid for one may not be for the other. I tried the first line of your fix from Atomulator on the 65C02 and it still failed but from your earlier post that may be due to the version of the test program. I am going to have to leave this until later today. I'll check back then. In the meantime feel free to commit to sf/bcdfix and I can always pull any changes.

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 11:10 am

This is the reference I have always used:
http://6502.org/tutorials/decimal_mode.html#A

For the C02, the following is needed:

Code: Select all

4a. AL = (A & $0F) - (B & $0F) + C-1
4b. A = A - B + C-1
4c. If A < 0, then A = A - $60
4d. If AL < 0, then A = A - $06
4e. The accumulator result is the lower 8 bits of A

Let me compare that with the current SBCc() macro.

Dave

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 1:06 pm

Coeus wrote:Thanks, Dave. Yes, I did see that the 65C02 macros were different hence the assumption that what was valid for one may not be for the other. I tried the first line of your fix from Atomulator on the 65C02 and it still failed but from your earlier post that may be due to the version of the test program. I am going to have to leave this until later today. I'll check back then. In the meantime feel free to commit to sf/bcdfix and I can always pull any changes.

BCDgood1.png

BCDgood2.png

I've pushed a fix to your branch:
https://github.com/stardot/b-em/commits/sf/bcdfix

I've also tried running the DORMANN 65C02 tests and there are failures.
DORMANN1.png


It seems one of the 65C02 opcodes is missing:
34 - BIT zp, X

In addition, the Rockwell specific 65C02 instructions are missing.
x7 - RMB/SMB zp
xF - BBR/BBS zp, rel

That's probably OK for the Master's G65SC12 but I think some real 6502 Co Pro's did use Rockwell R65C02s. If we choose not to implement these, then they should behave as NOPs.

Dave

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 2:12 pm

A few more 65C02 fixes..

For the main 65C02:
https://github.com/stardot/b-em/commit/ ... 4cddccabcf
D65C00N_main.png

For the tube 65C02:
https://github.com/stardot/b-em/commit/ ... 8dd771361d
D65C00N_tube.png


FYI, this is the test suite I an running:
dormann.zip
(408.71 KiB) Downloaded 9 times

Dave

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 2:32 pm

Steve,

FYI, I'm just looking at the failures in the NOP tests on the C02...

Dave

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 3:51 pm

Steve,

The NOP fixes are now pushed to your branch.

My port of the DORMANN 65C02 tests is now passing.
Coeus wrote:I am not sure how to interpret the result, though. How do I work out what's failing.

You need to consult the corresponding assembler listings:
https://github.com/mungre/beeb6502test/ ... l_test.lst
https://github.com/mungre/beeb6502test/ ... /65C02.lst
https://github.com/mungre/beeb6502test/ ... 65SC02.lst

I'm currently seeing a failure with Ctr's extended tests:
newtest1.png

It's actually the same failure that you saw earlier.

The failure is happening at 33EF, and if you look at the listing that's a new test for wrap around:
https://github.com/mungre/beeb6502test/ ... .lst#L4135

This is the instruction that's not wrapping correctly in B-Em:

Code: Select all

lda ($ff),y

What's your feeling Steve about whether to fix this?
Coeus wrote:but the test program says it intends to test the tube processor as a 65C02 whereas I think B-Em emulates a normal (NMOS) 6502. Was there more than one 6502 co-processor? Was, for example, the original cheese wedge a 6502 and the internal master 6502 co-processor another 65C02?

The 6502 Second Processor was never an NMOS 6502.

B-Em does emulate a 65C02 without the Rockwell extensions.

Dave

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

Re: B-Em

Postby bakoulis » Sun Apr 02, 2017 4:12 pm

Why the fixes pushed only to Steve's branch?
Why don't pushed to your branch?
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 4:16 pm

bakoulis wrote:Why the fixes pushed only to Steve's branch?
Why don't pushed to your branch?

Because I'm building on work that Steve has done on his sf/bcdfixes branch. Continuing on that branch seemed the simplest way.

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

Re: B-Em

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

hoglet wrote:This is the instruction that's not wrapping correctly in B-Em:

Code: Select all

lda ($ff),y

What's your feeling Steve about whether to fix this?

I do have a fix for this. It's simple, but quite a lot of changed lines. I'll pause on pushing this and let you catch up.

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

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

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 5:11 pm

hoglet wrote:What's your feeling Steve about whether to fix this?


If I have got this right, wrapping around within zero page so address from which the value is then fetched has the 8 low bits from 0xff and the high eight bits from 0x00 is what the real processor does but B-Em uses 0xff and 0x100. I had heard this described as a hardware bug, i.e. the processor was doing something odd but is is really just treating was expected to be an eight bit value as exactly that. It seems to me something that would likely be "undefined" behaviour in official documentation. If we're trying to emulate the actual processor exactly, though, probably we should adopt the fix.

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 5:20 pm

Coeus wrote:
hoglet wrote:What's your feeling Steve about whether to fix this?


If I have got this right, wrapping around within zero page so address from which the value is then fetched has the 8 low bits from 0xff and the high eight bits from 0x00 is what the real processor does but B-Em uses 0xff and 0x100. I had heard this described as a hardware bug, i.e. the processor was doing something odd but is is really just treating was expected to be an eight bit value as exactly that. It seems to me something that would likely be "undefined" behaviour in official documentation. If we're trying to emulate the actual processor exactly, though, probably we should adopt the fix.

Yes, your understanding of this is correct.

But I believe this is documented behaviour, and there was no attempt to fix it in the 65C02 (unlike the other page wrapping bug).

I can push the fix to your branch if you want to take a look.

Dave

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

Re: B-Em

Postby Coeus » Sun Apr 02, 2017 5:26 pm

hoglet wrote:I do have a fix for this. It's simple, but quite a lot of changed lines. I'll pause on pushing this and let you catch up.

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


One idea I had was to abandon 6502tube.c and use the 65816 emulation instead.

This takes a different approach in that instead of having the code for the various instructions inside a big switch/case statement (which the compiler will presumably implement with a jump table) the code has small C functions for each instruction and constructs what amounts to a jump table (an array of function pointers) which is then used to dispatch the emulation of opcodes. By having an array of (pointers to) these arrays it can dynamically switch behaviour, used to switch between 6502 emulation and various other modes of the 65816, i.e. whether particular registers work in 16bit of 8bit mode.

This could be extended to emulate other 6502 variants with the advantage that each new variant added just means another table of 256 function pointers and, most importantly, where the instructions between any two variants behave identically, they share the pointer to the function that implements the instruction that way rather than copy/paste the code such that when bugs are found we have to chase down each and every copy. I think, if we cached the array lookup for for which mode the processor is in by maintaining a pointer to the array of functions for the current mode, this should deliver similar performance to the existing 6502tube but be much more flexible.

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

Re: B-Em

Postby hoglet » Sun Apr 02, 2017 5:34 pm

The function pointer table seems a good idea, avoiding the current three copies of each instruction to maintain.

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.

But there are otherways to achieve this. Lib6502, for example, uses macros internalize() and externalize to copy the struct into local variables that hopefully end up in registers. The Z80 core we use in PiTubeDirect does the same.

Dave


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 4 guests