6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Oct 04, 2024 11:25 am

All times are UTC




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: 65816 Emulator
PostPosted: Fri Sep 08, 2006 4:46 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
I've e-mailed the author of XGS, to see if I can get some tips on ripping the 65816 emulator out of it and being able to compile it as a shared library under Linux. I looked at XGS 0.5.0 (which is probably ancient, since the website hadn't been updated since 2002), and it looks like it would compile cleanly in isolation, provided a few external symbols are provided. However, I would need to get rid of all the Apple IIgs relavent symbol references, which unfortunately, are scattered everywhere, but apparently not in any of the sources I've looked at. For example:

Code:
$ ./configure
$ gcc -shared -o blah.test -Iinclude/ opcodes?.c cpu.c rw.c
$ objdump -x blah.test | grep "*UND*"


will produce a large listing of undefined symbols, nearly all of which are references to the Apple IIgs hardware emulation code. However, 'grep'-ing for any of these symbols in the cpu.c, rw.c, or the include/opcodes.h file (which the opcodes?.c files reference as their main body) produces no results. I'm very confused about where these symbols are being defined.

Hopefully, if I can succeed in making the 65816 emulator a self-standing component, then perhaps more interesting emulator projects can be made with it. For example, I'd like to "grow" a Kestrel emulator with this, designing the hardware via Verilog at the same time as writing the emulator for said hardware.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 12, 2006 11:47 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
The 65816 emulator core works!!!!!

I even wrote a trivially simple "FooBox" emulator. You don't know what a FooBox is? Oh, it's simple -- it's the latest and greatest 65816-based computer in the world. I can wrap it up in the following:

Code:
$000000-$0FFFFF: RAM
$100000-$1FFFFF: Console Output Ports
$200000-$2FFFFF: Console Input Ports (blocking)
$300000-$3FFFFF: Console Input ports (non-blocking)
$400000-$FFFFFF: unused/unspecified


ROM file is stored in a file called ROM.PRG, and the file is standard Commodore PRG format. It's not a true ROM of course, since the first MB is all RAM. It should really be called IPL.PRG, I suppose, but I digress.

Why 1MB for keyboard input and console output? SImple -- MVN and MVP instructions can then double as simple INPUT or PRINT instructions. For example:

Code:
PrintError:
    LDX #Msg12 & $FFFF
    LDY #0
    LDA #Msg12Length-1
    MVP $00,$10  ; Print the message!
    RTS


Of course, this is just an emulator convenience. :) Real hardware might be a bit more difficult to deal with, but fortunately, rarely much more difficult.

Anyway, the code still isn't in a distributable state just yet -- much "packaging" work needs to be done before it's readily available for download. (e.g., I need to write a Makefile for it, write documentation,etc.)

It's based on the XGS 65816 processor core (in fact, I changed it only minimally). Over time, I'll add more features, but for now, my first goal is to get it into a "reusable" state so that others can use it in their own projects.


I'll post the sources of the FooBox and the ROM.PRG that I'm testing with in the next two messages.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 12, 2006 11:50 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
This just goes to show you how simple it is to create your own *minimal* virtual 65816-based machine. Some functions aren't implemented yet.

Code:
#include <stdio.h>
#include "cpu.h"

byte addressSpace[1048576];

byte BlockingRead( void )
{
    return (byte)( getchar() );
}   

byte NonBlockingRead( void )
{
    return 0x00;
}   

void Emit( byte b )
{
    putchar( (int)b );
}   

void EMUL_handleWDM( void )
{
}

void EMUL_hardwareUpdate( void )
{
}

byte MEM_readMem( word32 address )
{
    if( address > 0x3FFFFF )    return 0x00;
    if( address > 0x2FFFFF )    return NonBlockingRead();
    if( address > 0x1FFFFF )    return BlockingRead();
    if( address > 0x0FFFFF )    return 0x00; /* unused at the moment */

    return addressSpace[address];
}

void MEM_writeMem( word32 address, byte b )
{
    if( address > 0x1FFFFF )    return; /* unused at the moment */
    if( address > 0x0FFFFF ) {  Emit(b); return; }

    addressSpace[address] = b;
}

void LoadROMs( void )
{
    union { int I; struct { char B0, B1, B2, B3; } B; } loadAddress;
    FILE *fh;

    fprintf( stderr, "Reading ROM.PRG\n" );
    fh = fopen( "ROM.PRG", "rb" );
    if( fh != NULL )
    {
        fread( &(loadAddress.B.B0), 1, 1, fh );
        fread( &(loadAddress.B.B1), 1, 1, fh );
        loadAddress.I &= 0xFFFF;

        while( !feof( fh ) )
        {   
            fread( &addressSpace[ loadAddress.I ], 1, 1, fh );
            printf( ".M %04lX %02lX\n", loadAddress.I, addressSpace[ loadAddress.I ] );
            loadAddress.I = (loadAddress.I+1) & 0xFFFF;
        }   

        fclose( fh );
    }
}

int main( void )
{
    LoadROMs();

    fprintf( stderr, "WARP FACTOR 5\n" );
    CPU_reset();
    CPU_run();

    return 0;
}



Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Sep 12, 2006 11:50 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
This is the 8-bit test code that I used to verify the emulator was first working:

Code:
    !cpu    65816
    !to     "ROM.PRG"

    *=$F000

cold:
    lda     #<msg
    sta     0
    lda     #>msg
    sta     1
    ldy     #0
next:
    lda     (0),y
    beq     cold
    sta     $100000 ; store in "output byte" port
    iny
    jmp     next

msg:
    !text    "Hello world!"
    !byte   10,0

    *=$FFF0     ; ROM vectors -- don't remember which ones are
                ; which, so I'm shot-gunning it.

    !wo     cold, cold, cold, cold
    !wo     cold, cold, cold, cold


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Sep 13, 2006 6:37 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
Almost done writing a Kestrel "1p4" emulator. The Kestrel 1p4 differs from the 1p3 in several important ways:

* The VIA chip is relocated from $0000-$000F to $4000-$400F
* There is now a USB FIFO interface (emulated FT245M to be specific). Its data port appears at addresses $2000-$3FFF, while its handshake lines appear on the top two bits of VIA port A ($4001).
* Ideally, TBE# and RBF# would be tied to a CAx pin to generate an interrupt too.

The VIA is not even skeletal -- I implemented *just* enough code to emulate PA7 and PA6 -- that's it.

The FT245M emulation is 90% complete. The only thing it lacks is cycle accuracy (it can transmit a 384 byte payload in a single CPU clock cycle. Now if only the real world worked that simply!). Handshaking is implemented. Transmit handshaking, although "implemented," cannot really be tested without support for cycle accuracy.

Otherwise, the software seems to work well. Launch the "k1" emulator (it's a daemon), then telnet to 127.0.0.1 port 4096. Assuming the IPL.PRG file contains code designed for a telnet session, it should work fine. The emulator "turns off" when you disconnect the telnet session.

If graphics is your bag, you can implement an RFB protocol inside the Kestrel, then connect to 127.0.0.1:4096 with your VNC client. :) Although I've not tested this yet, since I've never written an RFB server before. Even so, I don't see why it wouldn't work. Might be pretty neat for games.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Sep 27, 2006 7:03 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
Well, I started working on the Kestrel 2 "baseline" emulator, and have 640x480 monochrome graphics and PS/2 keyboard (read-only) interface working. I am planning on releasing some documentation on the environment on my website in the coming days.

Basically, on-board I/O space exists at $FF0000-$FFFFFF, each I/O device receiving its own page of addressing space. The MGIA (Monochrome Graphics Interface Adapter) sits at $FF0000-$FF001F, IRQC (IRQ "Controller") at $FF0100-$FF0103, and the KIMO (Keyboard Input and MOuse, although the mouse interface isn't finished yet) exists at $FF0200-$FF0207.

RAM exists from $000000-$FEFFFF, with the exception of a ROM image at $008000-$00FFFF.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Mar 21, 2009 5:49 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10943
Location: England
Just a note for future adventurers: with the latest lib65816, I needed an extra line to make the minimal demonstration work:

Code:
int main( void )
{
    CPUEvent_initialize(); // now needed
    LoadROMs();

    fprintf( stderr, "WARP FACTOR 5\n" );
    CPU_reset();
    CPU_run();

    return 0;
}


I also had to update some of the interfaces:
Code:
21c21
< void EMUL_handleWDM( void )
---
> void EMUL_handleWDM( byte opcode, word32 timestamp )
25c25
< void EMUL_hardwareUpdate( void )
---
> void EMUL_hardwareUpdate( word32 timestamp )
29c29,30
< byte MEM_readMem( word32 address )
---
>
> byte MEM_readMem( word32 address, word32 timestamp )
39c40
< void MEM_writeMem( word32 address, byte b )
---
> void MEM_writeMem( word32 address, byte b, word32 timestamp )


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Mar 21, 2009 11:54 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
That ought not be the case; I am positive I replaced the binaries at the last upload. I'll need to look into it when I get more time.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jun 18, 2009 8:05 pm 
Offline

Joined: Thu Jun 18, 2009 7:24 pm
Posts: 3
Is there a possibility of making this library compatible with VICE?

It would be nice to finally have 65802/65816 emulation with a CBM based host.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jun 18, 2009 8:36 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
Dinjiin wrote:
Is there a possibility of making this library compatible with VICE?

It would be nice to finally have 65802/65816 emulation with a CBM based host.


I would like this very much as well. However, I don't know a thing about VICE, and the developer community around VICE seem exhorbitantly and quite bizarrely hostile to the idea of implementing a 65816 CPU emulation.

I think it'd be neat to finally implement SuperCPU emulation for the C64 and C128 platforms.

I don't know if lib65816, as architected, would be the most efficient approach though.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 4:12 am 
Offline

Joined: Thu Jun 18, 2009 7:24 pm
Posts: 3
kc5tja wrote:
the developer community around VICE seem exorbitantly and quite bizarrely hostile to the idea of implementing a 65816 CPU emulation.

I think it'd be neat to finally implement SuperCPU emulation for the C64 and C128 platforms.


Hrm, that's too bad.

Another option that comes to mind would be to modify one of the CBM modules in the open source MESS emulation project. MESS already includes support for 6502, 65C02, 65816 and 4510/65CE02 cores, so it would just be some glue logic to tie it all together.

The only concern that I have is the philosophy of the MESS project. Their stated goal is to have emulation be as accurate as possible, even at the expense of speed. I am unsure if they would frown upon somebody making a c64-816 module, or better, a c65-816 module. Worst case, you'd need to fork the code tree.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 7:52 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10943
Location: England
Please allow me to chip in... I'm afraid I'm going in two directions at once here:

Dinjiin wrote:
the philosophy of the MESS project. Their stated goal is to have emulation be as accurate as possible, even at the expense of speed.


Thanks for the pointer to MESS. I'd overlooked that. (The licensing is a bit murky. No problem for personal use, but for redistribution or merging into other projects it could be a barrier. VICE is GPL and might be unable to accept lib65816 for these reasons - even if they were willing.)

Is speed of emulation a problem? I know it can be, but with a recent computer emulating something running at a few MHz I thought there was no problem keeping up.

kc5tja wrote:
I think it'd be neat to finally implement SuperCPU emulation for the C64 and C128 platforms.


It would! A 65816 transplant into a 6502 system is very much my area of interest.

I found a couple of pointers: SuperCPU Programming Information and SuperCPU Steps Up To Version 2

Jammon is for superCPU, and I still hope to bring that up in lib65816 and then perhaps port it to our project. (I have a rudimentary command-line wrapper for lib65816 called run65816, which is where I'd hope to do the bring-up and porting - graphics isn't part of the story at present.)

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 19, 2009 5:16 pm 
Offline

Joined: Thu Jun 18, 2009 7:24 pm
Posts: 3
BigEd wrote:
Is speed of emulation a problem? I know it can be, but with a recent computer emulating something running at a few MHz I thought there was no problem keeping up.


It isn't really a problem these days. When testing with my Athlon 4850e (2.5GHz x2) with CPU power save disabled, the Apple IIgs module in MESS utilized about 30-40% of core0 while core1 was idle.

As a comparison, the C64 module in mess utilized about 18-20%, VICE x64 utilized about 0-2%, CCS64 utilized about 10-16% and KEGS32 utilized 6-8% (with 65816 running at 8.1MHz)


Top
 Profile  
Reply with quote  
 Post subject: more superCPU info
PostPosted: Sun Jun 21, 2009 9:53 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10943
Location: England
Digging out some more info on the SuperCPU, I see it is impressively complex. For example, it has a 1-byte write buffer to allow backgrounded writes to slower memory, the RAM expansion does a prefetch of next byte and it deals with page mode in dynamic RAMs. That's great for the quality and performance of the product, but makes a cycle-accurate emulation a nightmare.

So I'm thinking no-one with a goal of cycle-accuracy would want to tackle the emulation of a SuperCPU.

But an approximate emulation should be much less of a problem.

Some more SuperCPU links:


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Jun 27, 2009 10:56 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
OK, I know it's been awhile since I updated this thread.

BUT...

Would anyone, besides myself, be interested in contributing towards retrofitting lib65816, or its functional equivalent, into the VICE C64 emulator?

I'm thinking that we don't need it to be SuperCPU compatible. I wager a simple fork of x64 with the following attributes would be sufficient:

Code:
  FROM  | Description                                       |   TO   
--------+---------------------------------------------------+--------
 000000 | As currently understood for a stock Commodore 64. | 00FFFF
 010000 | Available RAM                                     | FEFFFF
 F00000 | Reads return $00, writes ignored                  | FEFFFF
 FF0000 | Expanded I/O space                                | FFFFFF
--------+---------------------------------------------------+--------

  FROM  | Description                                       |   TO   
--------+---------------------------------------------------+--------
 FF0000 | Mirror of C64's $D000-$DFFF I/O space.            | FF0FFF
 FF1000 | Mirror of C64's $D000-$DFFF color RAM space.      | FF1FFF
 FF2000 | Emulator-defined I/O devices, as we'd like        | FFFFFF
--------+---------------------------------------------------+--------


The I/O space from $F00000-$FFFFFF remains visible to the CPU at all times, as do the I/O ports sitting at $000000 and $000001. This allows you to, for example, bank out $D000-$DFFF to reveal its underlying RAM, while retaining the ability to access I/O devices in native mode (or, at least, using the [dp],Y addressing mode). $FF2000-$FFFFFF would give us, as coders, room to add any I/O devices we want (maybe even making a software plug-in system for it). The only drawback is that it leaves "only" 15MB of RAM available for you to use. Shucky darn. ;)

Who knows? Maybe this will attract developers to actually work on a real SuperCPU emulation.

I'm not interested in working on this alone, particularly since I haven't clue one about how Vice works. But if others would like to assist, I'm game.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: