MacVICE

[jonnosan]

@jonno: the TFE/RR Net settings are in "Settings/Resource Inspector". There open "Peripherals/Cartridges/TFE"...
Unfortunately, I just found out that the code is in place but there is a regression opening the adapter... Will have a look

Did you get a chance to investigate?

I am currently using VICE Version 2.2.1-r22394_20100328_trunk - I can navigate to the TFE/RR-NET options in the Resource Inspector, and have the following options set:

Enable: ticked
Interface: en0 (wired ethernet which is plugged in to a switch and is UP according to ifconfig)
RRNet: ticked

To get this far, I also needed to run "sudo chmod 777 /dev/bpf?" otherwise the Vice console would report an error opening /dev/bpf0 and /dev/bpf1

So it looks like the RR-NET emulation is enabled (and the console log reports "TFE: CS8900a rev.D reset" , but when I try and run an RR-NET app, the app fails when looking for an RR-NET.

The code that is checking for the RR-NET is this:


   lda #0         ; check magic signature
   jsr cs_read_page
   cpx #$0e
   bne @notfound
   cpy #$63
   bne @notfound

i.e. it is expecting the first 2 bytes from page 0 in the cs8900a to be $0E $63, the values that are actually returned are $C8 $20

The above code worked fine on the following:
* winvice emulating an RR-NET
* real C64 & Retro Replay & RR-NET
* real C64 & 64NIC+


p.s. - I just tried it in 2.2.2-r22418_20100406_trunk and get same behaviour)

[MagerValp]

Hmmm... the long time hang sounds like an overflow problem to me...

Is there a correlation with the new sync draw?
Or does it happen with "normal" drawing, too?

I just had the display freeze after running for just half a minute. I opened a new tab in Firefox which caused VICE to drop a few frames, and then it froze. Going into the resource inspector and toggling Sync Draw Flicker Fix unstuck it.

[lallafa]

@jonno:

the current snapshot already contains the fix to set the correct mac adapter (en0 not eth0).

I did a quick check here with the current snapshot and Guruterm beta 1 on the C64.
I was able to get an IP address via DHCP... so it seems to work basically.
Can you confirm this?

The console log should show something like:

Code: [Select]

TFE: setup receiver: broadcast=off mac=off multicast=off correct=off promiscuous=off hashfilter=off
TFE: setup receiver: broadcast=on mac=on multicast=off correct=on promiscuous=off hashfilter=off
TFE: set MAC address: 00:0c:64:03:13:37

Which version of WinVICE did you compare with? Did you try the same version of MacVICE?
Which version on Mac do you use? i386 or x86_64 ...?

[jonnosan]

[a2retro]

DHCP is working for me but nothing after that.

[lallafa]

@a2retro: I had some trouble with name resolution, too. But by entering the IP the connect and BBSing works fine (e.g. 81.235.242.146)

@jonnosan: puh I am a bit clueless here... I have almost the same HW setup as you and here it works fine.
Did you try resetting to a default config and then only enabling RRNet?
The /dev/bpf? entries are still accessible (reboot resets them if its not set as a StartupItem)?

[a2retro]

@lallafa

DHCP (only) worked from me using the prebuilt 2.2 - vice-macosx-cocoa-i386+ppc-10.5-gcc40-2.2 but I have since got the latest code from svn and built using

1.1.1 - libpcap
1.1.2.1 - libnet

sh ../vice/build/macosx/build-pcaplibnet.sh ../extlib x86_64 10.6 gcc42

sh vice/build/macosx/build-vice-release.sh -d -u cocoa -a x86_64 -k 10.6 -c gcc42 -j cocoa-x86_64-10.6-gcc42 vice

and dhcp doesn't seem to be working for me now

I have turned on all debugging for TFE and thats as far as I get
TFE: tfe_arch_transmit() called with:                 length= 342 and buffer FF FF FF FF FF FF 00 0D-60 64 64 64 08 00 45 00*01 48 00 01 00 00 FF 11-BA A4 00 00 00 00 FF FF*FF FF 00 44 00 43 01 34-00 00 01 01 06 00 AD DE*12 23 00 00 00 00 00 00-00 00 00 00 00 00 00 00*00 00 00 00 00 00 00 0D-60 64 64 64 00 00 00 00*00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00*00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00*00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00*00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00*00 00 00 00 00 00
TFEARCH: tfe_arch_transmit() called, with: force = FALSE, onecoll = FALSE, inhibit_crc=FALSE, tx_pad_dis=FALSE, txlength=342
TFE: TX: sent  frame (length=0156)
TFE: TX: set status Rdy4TxNOW=0 TxBidErr=0
TFE: store [$0A] <= $24.
TFE: set PP Ptr to $3124.
TFE: store [$0B] <= $01.
TFE: set PP Ptr to $3124.
TFEARCH: tfe_arch_receive() called, with *plen=1518.
TFEARCH: tfe_arch_receive_frame() called, returns -1.
TFE: reading PP Ptr: $0124 => $0004.
TFE: read [$0D] => $00.
TFE: store [$0A] <= $24.
TFE: set PP Ptr to $3124.
TFE: store [$0B] <= $01.
TFE: set PP Ptr to $3124.
TFEARCH: tfe_arch_receive() called, with *plen=1518.
TFEARCH: tfe_arch_receive_frame() called, returns -1.

repeats

One other thing I an using TFE and not RR-NET - not sure if that should make any difference

[jonnosan]

The /dev/bpf? entries are still accessible (reboot resets them if its not set as a StartupItem)?

What do you mean by 'set as a StartupItem'? (this is my first mac so still learning the terminology)

btw I am using the following libraries (install from macports)

libnet                         @1.0.2a         net/libnet
libpcap                        @1.0.0          net/libpcap

[MagerValp]

The /dev/bpf? entries are still accessible (reboot resets them if its not set as a StartupItem)?

What do you mean by 'set as a StartupItem'? (this is my first mac so still learning the terminology)

The ownership and permissions of /dev/bpf0 gets reset every time you restart, so to make it readable by non-root users you have to add a script that sets the owner every time you log in. ChmodBPF comes with libpcap and wireshark, and check http://kleinsch.com/2009/10/03/wireshark-chmodbpf-errors-on-snow-leopard/ on how to make it work on Snow Leopard.

[a2retro]

@a2retro: I had some trouble with name resolution, too. But by entering the IP the connect and BBSing works fine (e.g. 81.235.242.146)

lallafa,

Since you have a working config, is there any chance you would consider updating your "TFE on Mac VICE Build Guide" web page with your latest info?

Thanks

[lallafa]

The text you refer to is a blog entry with a timestamp of 2006. So it describes the state at that time and it is quite ooold...

For an up to date description on how to build on Mac OS X have a look at the source tree:
doc/MacOSX-Build.txt is the one you are looking for.

There you find information on how to build the extlibs, the external libraries used in VICE.
This includes working versions of libnet and libpcap.

[a2retro]

The text you refer to is a blog entry with a timestamp of 2006. So it describes the state at that time and it is quite ooold...

For an up to date description on how to build on Mac OS X have a look at the source tree:
doc/MacOSX-Build.txt is the one you are looking for.

There you find information on how to build the extlibs, the external libraries used in VICE.
This includes working versions of libnet and libpcap.

I did originally follow that document with the one exception of using libpcap 1.1.1 vs 1.0.0. I switched back and now I can get an address via dhcp but I cannot get any of the apps to connect to internal or external destinations via name or ip. Any suggestions welcome.

Thanks

[franticHT]

I find it disturbing that the Control Window stays on top over other applications when MacVICE is not the focused application.

(Also, the login function on this forum does not work with the Camino browser on Mac, for some reason, but I guess that is some else's problem..)

[lallafa]

Actually, I have overwritten automatic hiding of the control window to allow the user a simplified drag & drop access to the image fields in the control window. In the current implementation you can simply drag a disk/tape file from finder to the still visible command window.

If this feature is not desired then I'll add a configure option to disable it.

[mrsid]

To me it wasn't even obvious that I can drag to the control window, because it doesn't give proper drag feedback (only the mouse cursor changes). When the window or a control can accept a drop, you should draw a border in the user's highlight color. Standard controls like NSImageView or NSTableView do that automatically for you.