Menu
▾
▴
basilisk-devel — Basilisk II development-related discussion
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(42) |
Oct
(17) |
Nov
(7) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(14) |
Feb
(8) |
Mar
(13) |
Apr
(10) |
May
(28) |
Jun
(28) |
Jul
(23) |
Aug
(7) |
Sep
(2) |
Oct
(24) |
Nov
(9) |
Dec
(2) |
| 2002 |
Jan
(58) |
Feb
(15) |
Mar
(57) |
Apr
(26) |
May
(7) |
Jun
|
Jul
(10) |
Aug
|
Sep
(19) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
| 2003 |
Jan
(4) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(14) |
Jun
(3) |
Jul
(7) |
Aug
(4) |
Sep
(7) |
Oct
(4) |
Nov
(11) |
Dec
(3) |
| 2004 |
Jan
(32) |
Feb
(21) |
Mar
(3) |
Apr
(11) |
May
(33) |
Jun
(42) |
Jul
(46) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(42) |
Dec
(23) |
| 2005 |
Jan
(5) |
Feb
(2) |
Mar
(12) |
Apr
(26) |
May
(8) |
Jun
(18) |
Jul
(21) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(10) |
Dec
(1) |
| 2006 |
Jan
(17) |
Feb
(17) |
Mar
(3) |
Apr
(2) |
May
(2) |
Jun
(7) |
Jul
(6) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(7) |
Dec
(4) |
| 2007 |
Jan
(6) |
Feb
(4) |
Mar
|
Apr
(3) |
May
(7) |
Jun
(17) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
| 2008 |
Jan
(14) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
(22) |
Mar
(3) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
(15) |
Sep
|
Oct
(32) |
Nov
(9) |
Dec
|
| 2010 |
Jan
(18) |
Feb
(2) |
Mar
(14) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(7) |
Sep
(6) |
Oct
(35) |
Nov
(4) |
Dec
|
| 2011 |
Jan
(4) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
(4) |
| 2012 |
Jan
(4) |
Feb
|
Mar
(8) |
Apr
(9) |
May
|
Jun
(176) |
Jul
(86) |
Aug
(20) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(13) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: Andrew T. <rak...@gm...> - 2020-11-16 23:54:19
|
Hi all, Does anyone know how I can test DGA virtual screen mode? It is mentioned as something to consider in the VOSF full screen update code, and I wonder if the code there which seems broken for SDL is actually intended to be a special case for DGA. https://github.com/cebix/macemu/blob/29bb3d5a5a99db494049f64c678f38301ef63432/BasiliskII/src/CrossPlatform/video_vosf.h#L547 >From the change where dst_bytes_per_row and scr_bytes_per_row were first separated ( https://github.com/cebix/macemu/commit/31f80e338b78d8823305d2d6a55fe3511767ecfe ), which seems to only have the effect of skipping over the last partial chunk of source data in the row, I wonder if DGA virtual screen mode changes the semantics of the framebuffer in a way that makes that make sense? Anything you can tell me, like a vague recollection of some linux distro this would have been tested on at the time, would be helpful. Cheers, -AT |
|
From: Andrew T. <rak...@gm...> - 2020-10-05 23:04:18
|
I put this question to the issue tracker, but for anyone who isn't paying attention there: tl;dr: On a real mac with OF, how does OF tell the Mac ROM code what disk to boot from? https://github.com/cebix/macemu/issues/224 I've got a hack which just reorders the drive queue after the drives have been added, which works fine for the limited purpose of booting from CD when the user puts in the pref for that, but it seems really silly to have to do this for a NewWorld ROM that on a real machine obviously obeys the Startup Disk setting somehow. -AT |
|
From: <bjj...@ya...> - 2018-10-07 21:19:26
|
Congratulations! Glad you've had some success. Brian Johnson Sent from my android device. -----Original Message----- From: Brent Busby <br...@ke...> To: Discussions related to the development of Basilisk II <bas...@li...> Sent: Sun, 07 Oct 2018 5:40 AM Subject: Re: [B2-devel] Midi support in Basilisk (by hook or by crook) Just thought I'd let you know, my holy grail search for a way to run Sound Process Visual Editor (and classic Mac MIDI applications in general) in emulation has continued...and found some success, finally. Installing OS9 in QEMU's PowerPC emulation and directing the virtual serial port to a MIDI device node in Linux actually does give applications bidirectional MIDI with real hardware on the host. I was able to run SPVE and edit patches on an Ensoniq Mirage running Sound Process. Running a sequencer, predictably, proved glitchy timing-wise, but SPVE is a patch editor, so for that application the timing doesn't matter. The next thing I'd like to try is PCE, since it would be much lighter (faster?), and it's supposed to have a very good serial port emulation. Also, I think it only can run OS7, but that's fine too. Just in case anyone wants to know if Mac MIDI emulation is hopeless... -- - Brent Busby + =============================================== + "The introduction of a new kind of music must -- Studio -- + be shunned as imperiling the whole state, for -- Amadeus/ -- + styles of music are never disturbed without -- Keycorner -- + without affecting the most important political -- Recording -- + institutions." --Plato, "Republic" ----------------+ =============================================== |
|
From: Brent B. <br...@ke...> - 2018-10-07 10:40:11
|
Just thought I'd let you know, my holy grail search for a way to run Sound Process Visual Editor (and classic Mac MIDI applications in general) in emulation has continued...and found some success, finally. Installing OS9 in QEMU's PowerPC emulation and directing the virtual serial port to a MIDI device node in Linux actually does give applications bidirectional MIDI with real hardware on the host. I was able to run SPVE and edit patches on an Ensoniq Mirage running Sound Process. Running a sequencer, predictably, proved glitchy timing-wise, but SPVE is a patch editor, so for that application the timing doesn't matter. The next thing I'd like to try is PCE, since it would be much lighter (faster?), and it's supposed to have a very good serial port emulation. Also, I think it only can run OS7, but that's fine too. Just in case anyone wants to know if Mac MIDI emulation is hopeless... -- - Brent Busby + =============================================== + "The introduction of a new kind of music must -- Studio -- + be shunned as imperiling the whole state, for -- Amadeus/ -- + styles of music are never disturbed without -- Keycorner -- + without affecting the most important political -- Recording -- + institutions." --Plato, "Republic" ----------------+ =============================================== |
|
From: Eric K. <er...@kn...> - 2018-09-26 23:56:29
|
Using one of the Macintosh Repository tar balls, I have a running system from master head on GitHub. My Win32 debug image runs, but my Release build quits apparently before getting to the OS initialization. I had to run the gen*.exe files by hand. VS doesn't want to build those custom targets. I'm hooked and fascinated :). I started coding for GUIs on 68k Macs. I want to hack on this. |
|
From: Eric K. <er...@kn...> - 2018-09-26 08:51:37
|
Next step, SDL.dll is now in the BasiliskII output directory. I've tried to set up a Quadra700 rom in the prefs file and as just "ROM" as in the README, but I still get a dialog box that it can't open the ROM file. |
|
From: Eric K. <er...@kn...> - 2018-09-26 07:56:51
|
Backed up to attempting a Win32 build, but now when I try to register the 32 bit debug SDL DLL it tells me it can't find the DllRegisterServer() function. |
|
From: Eric K. <er...@kn...> - 2018-09-26 04:24:52
|
I had to remove the <TargetPlatform> parameter from the project files. Now I'm having trouble with the final build: 1>------ Build started: Project: gencpu, Configuration: Debug x64 ------ 1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(391,5): warning MSB8028: The intermediate directory (x64\Debug\) contains files shared from another project (build68k.vcxproj). This can lead to incorrect clean and rebuild behavior. 1>Generating cpudefs.cpp... 1>cpudefs.cpp 1>gencpu.vcxproj -> D:\macemu-master\BasiliskII\src\Windows\x64\Debug\gencpu.exe 1>Done building project "gencpu.vcxproj". 2>------ Build started: Project: BasiliskII, Configuration: Debug JIT x64 ------ 2>Generating CPU emulation sources... 2>The system cannot find the path specified. 2>The system cannot find the path specified. 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: The command "cd ..\uae_cpu 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: "D:\macemu-master\BasiliskII\src\Windows\Debug\gencpu" 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: "D:\macemu-master\BasiliskII\src\Windows\Debug\gencomp" 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: :VCEnd" exited with code 3. 2>Done building project "BasiliskII.vcxproj" -- FAILED. ========== Build: 1 succeeded, 1 failed, 1 up-to-date, 0 skipped ========== |
|
From: Eric K. <er...@kn...> - 2018-09-26 04:06:26
|
Not very familiar with the Windows development environment. I'm an embedded systems programmer. It was trying to find the 2015 development tools environment, but I was able to retarget that. I really don't want to have to go hunt down my old CD of VC++, so I'm using the 2017 community version. I'm having a problem that the three subprojects won't let me retarget to the new Windows library. It just resets to 8.1: 1>------ Build started: Project: build68k, Configuration: Debug x64 ------ 1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". 1>Done building project "build68k.vcxproj" -- FAILED. 2>------ Build started: Project: gencpu, Configuration: Debug x64 ------ 3>------ Build started: Project: gencomp, Configuration: Debug x64 ------ 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". 2>Done building project "gencpu.vcxproj" -- FAILED. 3>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". 3>Done building project "gencomp.vcxproj" -- FAILED. 4>------ Build started: Project: BasiliskII, Configuration: Debug JIT x64 ------ 4>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1879,5): warning : The referenced project '..\..\..\..\thirdparty\src\SDL-1.2.15\VisualC\SDLmain\SDLmain.vcxproj' does not exist. 4>Generating CPU emulation sources... 4>The system cannot find the path specified. 4>The system cannot find the path specified. 4>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: The command "cd ..\uae_cpu 4>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: "D:\macemu-master\BasiliskII\src\Windows\Debug\gencpu" 4>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: "D:\macemu-master\BasiliskII\src\Windows\Debug\gencomp" 4>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: 4>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(255,5): error MSB3073: :VCEnd" exited with code 3. 4>Done building project "BasiliskII.vcxproj" -- FAILED. ========== Build: 0 succeeded, 4 failed, 2 up-to-date, 0 skipped ========== |
|
From: Brent B. <br...@ke...> - 2018-07-06 05:00:11
|
Michael Schmitt via basilisk-devel
<bas...@li...> writes:
> Does it print the unimplemented control code value? What is it?
>
> Is it 15 (kSERDClockMidi, as defined in serial_defs.h)?
Been busy with fireworks and food (US Independence Day)...
I tried the experiment again. Yes, it is 15.
> I wonder what would happen if you just changed the switch/case block to return noErr for that code.
Well, I tried it. I added a new case:
case kSERDClockMIDI:
printf("DEBUG: I think I saw a serial port trying to do Midi\n", code);
return noErr; // Midi? We never saw no Midi.
I does print the message, especially when you try to setup OpCode
Studio. However, the emulator is more unstable now, often crashes when
the guest reboots. It's a shame; I was hoping maybe there was an easy fix.
> Note: The source says that there are 4 types of devices: serial,
> parallel, pty and midi, and that it returns an openErr if an attempt
> is made to open a midi device. So I wonder what kind of device it
> thinks it has.
The behavior I'm seeing is very different in different applications.
It'd be interesting to see all the different ways different software is
trying to access the port, but I'm starting to see why this was never
implemented. Maybe I will give up on this after all.
--
- Brent Busby + ===============================================
+ "The introduction of a new kind of music must
-- Studio -- + be shunned as imperiling the whole state, for
-- Amadeus/ -- + styles of music are never disturbed without
-- Keycorner -- + without affecting the most important political
-- Recording -- + institutions." --Plato, "Republic"
----------------+ ===============================================
|
|
From: Em A. <ade...@gm...> - 2018-07-05 00:04:08
|
As someone involved in a number of those threads... it seems to me it should be possible to implement MIDI on modern hardware via BII — the big issue was that the emulation isn’t fully documented, and nobody was working on the source to the degree that updates would be feasible for the serial emulation. Fusion emulates MIDI, so it’s definitely possible, even if the timing isn’t accurate or a carrier has to be emulated. I’m pretty sure Fusion does it by patching through to DOS MIDI.ignoring clock emulation and carrier signal. A few years back we tried piping serial to a command line program that would respond with the expected signal, but somehow we still ended up with buffers that weren’t emptying and the MIDI throughput would just stop. We even tried only MIDI input to DMCS from a .mid file, but had the same issues with the buffer filling and the data stream stopping. > On Jul 2, 2018, at 3:54 PM, Brent Busby <br...@ke...> wrote: > > Ricky Zhang <zha...@gm...> writes: > > [...] >> TBH, I still don’t understand the MIDI application INs and OUTs. How >> and why do you expose serial port in guest OS to the serial port in >> host OS? Do you have serial/parallel port MIDI keyboard (a physical >> hardware in host OS)? > > Yes, the usefulness of this is for people who want to run legacy Midi > applications in the real world outside the emulator, either with > physical equipment (my case), or to communicate with software > instruments/effects running in the host OS, or possibly doing both at > the same time. I've seen some threads in the E-maculation forums from > people wanting similar things over the years, and generally they were > told that the time synchronization would be too difficult to provide > steady tempo, so it wasn't worth doing. > > So I went into this thinking that if that were the only hindrance, then > don't worry about it and just let the bytes come out as they will. A > patch editor doesn't need steady tempo, and probably in many cases the > timing jitter for actual sequencer playback wouldn't be that bad on a > modern machine anyway, especially if the software running in the > emulator was slaved to time from the host OS. > > And it turns out that old Mac serial ports are a much murkier subject > than the aforementioned concerns about time stability allude to. Like, > lions and tigers and bears, oh my sort of murkier. It wants a 1MHz > signal of some kind coming into a pin on the port that normal telecomm > doesn't even use, which would probably have to be emulated to satisfy > what applications like SPVE are wanting to see. (Or at least the driver > would have to be lied to so it thinks the signal is there, while > actually getting the 31250 baud timing another way.) > > Here are a few links to the threads I saw, just so you know I'm not the > only person who'd like to do something like this: > > https://www.emaculation.com/forum/viewtopic.php?f=1&t=9103 > https://www.emaculation.com/forum/viewtopic.php?f=6&t=8364 > https://www.emaculation.com/forum/viewtopic.php?t=7277 > https://www.emaculation.com/forum/viewtopic.php?f=1&t=7674 > https://www.emaculation.com/forum/viewtopic.php?f=20&t=7668 > https://www.emaculation.com/forum/viewtopic.php?f=6&t=8439&start=50 > https://www.emaculation.com/forum/viewtopic.php?f=20&t=9459 > https://www.emaculation.com/forum/viewtopic.php?t=5657 > https://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start=1025 > > Here's someone wanting to try QEMU for this, with different problems (of > course, because true VM's are very isolated from their hosts): > https://www.emaculation.com/forum/viewtopic.php?f=34&t=9601 > > Also, there's a whole web site for running studio apps on pre-OSX here, > but they seem to be very hostile to any kind of emulation. They want > real old Macs, which doesn't seem to me like a solution that will last > too long: http://www.macos9lives.com/ > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Michael S. <msb...@me...> - 2018-07-04 21:31:44
|
Does it print the unimplemented control code value? What is it?
Is it 15 (kSERDClockMidi, as defined in serial_defs.h)?
I wonder what would happen if you just changed the switch/case block to return noErr for that code.
Note: The source says that there are 4 types of devices: serial, parallel, pty and midi, and that it returns an openErr if an attempt is made to open a midi device. So I wonder what kind of device it thinks it has.
> On Jul 4, 2018, at 2:56 PM, Brent Busby <br...@ke...> wrote:
>
> There's a long switch/case block "int16 XSERDPort::control" starting at
> line 312 of serial_unix.cpp, at least in my git checkout from May 1st
> (don't know how often you commit). If nothing in the switch/case block
> matches, it ends up defaulting to 'printf("WARNING: SerialControl():
> unimplemented control code %d\n", code);', and that's exactly what I get
> echoed to stderr in my terminal when an application tries to use MIDI.
|
|
From: Josh J. <jj...@gm...> - 2018-07-04 21:31:05
|
On Jul 4, 2018, at 3:56 PM, Brent Busby <br...@ke...> wrote: > As the gladiators used to say, we who are about to die salute you. ;-) Death smiles at us all. :-) > (Is there software to help with porting > Classic MacOS stuff to OSX?) I don't know about conversion tools, but I've created some libraries to smooth over some of the differences between classic and Carbon. The best help is experience, i.e. knowing what to expect and how to deal with it by having done it before. I recently ported Glypha III to run on macOS <https://github.com/jjuran/glypha3-fork/>. The commit history contains a sampling of the sorts of issues that come up in porting Mac applications forward, everything from updating old routine names to implementing Apple events to dealing with Carbon, Aqua, umbrella frameworks, gcc, little-endian, clang, retired headers, and even bugs in newer OSes. Josh |
|
From: Brent B. <br...@ke...> - 2018-07-04 19:56:55
|
bjj_Rosemount--- via basilisk-devel
<bas...@li...> writes:
> Sounds like a cool project.
>
> I have a vague memory that the BII serial code gets a value from the
> guest saying which mode it would like to use when opening the port,
> and that one of the possibilities is MIDI. So maybe you could modify
> the serial code to use the host's MIDI infrastructure (ALSA,
> PulseAudio, SDL, etc. -- probably whatever BII is using for audio) in
> that case. I doubt you'd have to deal with the low level details of
> Mac serial port clocking. BII doesn't really emulate hardware, it
> intercepts driver calls in software.
Well, Linux has two different low-level ways of providing MIDI (actually
three, but the third one's not pertinent here). The native way, ALSA,
needs library calls and specific support in the application, so you have
to specially code for it, and I don't want to go through all that just
to pass bytes that are already being made available to me on the Mac
serial port which are literally the bytes you'd send to the physical
studio equipment over cable, if you could find a way to get them there.
Also, ALSA is Linux specific, so if you supported it that way, it won't
help any other host platform but Linux.
The other way of providing MIDI, OSS, is available on most UNIX flavors,
even fairly old ones that no one particularly thinks of as multimedia
OS's you'd want to do MIDI work on. ALSA provides a kernel module to
emulate OSS on Linux for backward compatibility. UNIX flavors that use
OSS normally provide character device nodes under /dev that you just
send bytes in and out of, like a serial FIFO. All that's needed is for
the Linux machine to load the snd-seq-oss kernel module (most distros do
it by default), and it will create the emulated OSS device nodes under
/dev, which can be used alongside with and interchangeably with the
native ALSA library calls on the same machine. So you can run apps that
do things the ALSA way with library calls (which is Linux-specific), and
on the same machine at the same time you can also run apps doing MIDI
the OSS way through nodes in /dev (the older UNIX way). For our
purposes, using the OSS compatible character FIFO's is way less work
(since old Macs want to do MIDI through serial i/o, the same as OSS
expects already), and also is compatible with more UNIX platforms than
just Linux.
DOSEMU is providing the kind of MIDI support I'm wanting for DOS apps by
doing it this way: It doesn't do direct calls to ALSA, it just sends
bytes that were meant to go to your DOS MIDI port to /dev nodes of your
choice on the host, and likewise for listening to MIDI input coming back
the other way, and it works. That's all I'm wanting here, more of less
just a character FIFO to/from a /dev node on the host. Basilisk seems
to already be doing that for its emulated Mac serial ports...almost.
It's just not letting the data flow if it's MIDI for some reason, but
allows it if it's a telecomm program like ZTerm. If I make some
progress with this, I will provide patches.
> Disclaimer: I haven't looked at the code, or used Basilisk, in 15
> years or so... I'm amazed I'm still on this mailing list. :) So I may
> be way off base.
No, that sounds exactly right from what I see in the Basilisk code.
There's a long switch/case block "int16 XSERDPort::control" starting at
line 312 of serial_unix.cpp, at least in my git checkout from May 1st
(don't know how often you commit). If nothing in the switch/case block
matches, it ends up defaulting to 'printf("WARNING: SerialControl():
unimplemented control code %d\n", code);', and that's exactly what I get
echoed to stderr in my terminal when an application tries to use MIDI.
And nothing ever comes out of the port. Then I go into ZTerm and send
Hayes modem commands and it works like a charm. I could call a BBS. :)
It would really be nice, as you're suggesting, if I didn't have to
actually fake the 1MHz signal coming into the pin on a real Mac that a
hardware MIDI interface would produce, though I suppose if I had to,
that could be done. Really I'm just trying to let bytes in and out
unhindered by code that says, "I don't know what this is, so I'll just
throw an exception and skip it," which looks like what that last part of
the switch/case block is doing.
> Good luck,
I'm gonna need it.
As the gladiators used to say, we who are about to die salute you. ;-)
Addendum: I'm also making an effort to reach the author of Sound Process
Visual Editor postally (since his email no longer exists), to see if
he's interested in releasing the code. While that wouldn't solve
anything for people wanting to run other old Mac MIDI applications, it
would be the best answer for this one, so others can take over
maintenance rather than letting it die or having to run it in an
emulator. We'll see if anything comes of that I guess. A GPL-licensed
native Linux version of SVPE would be really nice, or maybe OSX if that
would make it easier to port. (Is there software to help with porting
Classic MacOS stuff to OSX?)
--
- Brent Busby + ===============================================
+ "The introduction of a new kind of music must
-- Studio -- + be shunned as imperiling the whole state, for
-- Amadeus/ -- + styles of music are never disturbed without
-- Keycorner -- + without affecting the most important political
-- Recording -- + institutions." --Plato, "Republic"
----------------+ ===============================================
|
|
From: <bjj...@ya...> - 2018-07-04 16:02:44
|
Sounds like a cool project. I have a vague memory that the BII serial code gets a value from the guest saying which mode it would like to use when opening the port, and that one of the possibilities is MIDI. So maybe you could modify the serial code to use the host's MIDI infrastructure (ALSA, PulseAudio, SDL, etc. -- probably whatever BII is using for audio) in that case. I doubt you'd have to deal with the low level details of Mac serial port clocking. BII doesn't really emulate hardware, it intercepts driver calls in software. Disclaimer: I haven't looked at the code, or used Basilisk, in 15 years or so... I'm amazed I'm still on this mailing list. :) So I may be way off base. Good luck, Brian Sent from my android device. -----Original Message----- From: Brent Busby <br...@ke...> To: Discussions related to the development of Basilisk II <bas...@li...> Sent: Mon, 02 Jul 2018 5:55 PM Subject: Re: [B2-devel] Midi support in Basilisk (by hook or by crook) Ricky Zhang <zha...@gm...> writes: [...] > TBH, I still don’t understand the MIDI application INs and OUTs. How > and why do you expose serial port in guest OS to the serial port in > host OS? Do you have serial/parallel port MIDI keyboard (a physical > hardware in host OS)? Yes, the usefulness of this is for people who want to run legacy Midi applications in the real world outside the emulator, either with physical equipment (my case), or to communicate with software instruments/effects running in the host OS, or possibly doing both at the same time. I've seen some threads in the E-maculation forums from people wanting similar things over the years, and generally they were told that the time synchronization would be too difficult to provide steady tempo, so it wasn't worth doing. So I went into this thinking that if that were the only hindrance, then don't worry about it and just let the bytes come out as they will. A patch editor doesn't need steady tempo, and probably in many cases the timing jitter for actual sequencer playback wouldn't be that bad on a modern machine anyway, especially if the software running in the emulator was slaved to time from the host OS. And it turns out that old Mac serial ports are a much murkier subject than the aforementioned concerns about time stability allude to. Like, lions and tigers and bears, oh my sort of murkier. It wants a 1MHz signal of some kind coming into a pin on the port that normal telecomm doesn't even use, which would probably have to be emulated to satisfy what applications like SPVE are wanting to see. (Or at least the driver would have to be lied to so it thinks the signal is there, while actually getting the 31250 baud timing another way.) Here are a few links to the threads I saw, just so you know I'm not the only person who'd like to do something like this: https://www.emaculation.com/forum/viewtopic.php?f=1&t=9103 https://www.emaculation.com/forum/viewtopic.php?f=6&t=8364 https://www.emaculation.com/forum/viewtopic.php?t=7277 https://www.emaculation.com/forum/viewtopic.php?f=1&t=7674 https://www.emaculation.com/forum/viewtopic.php?f=20&t=7668 https://www.emaculation.com/forum/viewtopic.php?f=6&t=8439&start=50 https://www.emaculation.com/forum/viewtopic.php?f=20&t=9459 https://www.emaculation.com/forum/viewtopic.php?t=5657 https://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start=1025 Here's someone wanting to try QEMU for this, with different problems (of course, because true VM's are very isolated from their hosts): https://www.emaculation.com/forum/viewtopic.php?f=34&t=9601 Also, there's a whole web site for running studio apps on pre-OSX here, but they seem to be very hostile to any kind of emulation. They want real old Macs, which doesn't seem to me like a solution that will last too long: http://www.macos9lives.com/ |
|
From: Brent B. <br...@ke...> - 2018-07-02 22:55:35
|
Ricky Zhang <zha...@gm...> writes: [...] > TBH, I still don’t understand the MIDI application INs and OUTs. How > and why do you expose serial port in guest OS to the serial port in > host OS? Do you have serial/parallel port MIDI keyboard (a physical > hardware in host OS)? Yes, the usefulness of this is for people who want to run legacy Midi applications in the real world outside the emulator, either with physical equipment (my case), or to communicate with software instruments/effects running in the host OS, or possibly doing both at the same time. I've seen some threads in the E-maculation forums from people wanting similar things over the years, and generally they were told that the time synchronization would be too difficult to provide steady tempo, so it wasn't worth doing. So I went into this thinking that if that were the only hindrance, then don't worry about it and just let the bytes come out as they will. A patch editor doesn't need steady tempo, and probably in many cases the timing jitter for actual sequencer playback wouldn't be that bad on a modern machine anyway, especially if the software running in the emulator was slaved to time from the host OS. And it turns out that old Mac serial ports are a much murkier subject than the aforementioned concerns about time stability allude to. Like, lions and tigers and bears, oh my sort of murkier. It wants a 1MHz signal of some kind coming into a pin on the port that normal telecomm doesn't even use, which would probably have to be emulated to satisfy what applications like SPVE are wanting to see. (Or at least the driver would have to be lied to so it thinks the signal is there, while actually getting the 31250 baud timing another way.) Here are a few links to the threads I saw, just so you know I'm not the only person who'd like to do something like this: https://www.emaculation.com/forum/viewtopic.php?f=1&t=9103 https://www.emaculation.com/forum/viewtopic.php?f=6&t=8364 https://www.emaculation.com/forum/viewtopic.php?t=7277 https://www.emaculation.com/forum/viewtopic.php?f=1&t=7674 https://www.emaculation.com/forum/viewtopic.php?f=20&t=7668 https://www.emaculation.com/forum/viewtopic.php?f=6&t=8439&start=50 https://www.emaculation.com/forum/viewtopic.php?f=20&t=9459 https://www.emaculation.com/forum/viewtopic.php?t=5657 https://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start=1025 Here's someone wanting to try QEMU for this, with different problems (of course, because true VM's are very isolated from their hosts): https://www.emaculation.com/forum/viewtopic.php?f=34&t=9601 Also, there's a whole web site for running studio apps on pre-OSX here, but they seem to be very hostile to any kind of emulation. They want real old Macs, which doesn't seem to me like a solution that will last too long: http://www.macos9lives.com/ |
|
From: Ricky Z. <zha...@gm...> - 2018-07-02 19:45:32
|
You can always make any changes to BII. Because BII code base is extremely stable (I mean code structure change) and there is nothing change in guest OS. I recently patched 24 bit ROM to emulate the hard drive in System 6. The hard part is to find the right spot to add features. I haven’t read how serial port is emulated in BII. But I did RTFC on 68K CPU emulation, Macintosh ROM and emulate 8 bit frame buffer to SDL. If you are interested in contribution of your serial port research, you are welcome add yours in the wiki: https://github.com/cebix/macemu/wiki/Basilisk-II-Peripheral-Hardware-Emulation-Analysis <https://github.com/cebix/macemu/wiki/Basilisk-II-Peripheral-Hardware-Emulation-Analysis>. There are more stuffs I wrote. But maybe nobody is interested it in. To emulate a virtual device in guest OS, you must know how to develop serial port driver or whatever manager in System 7 (or 6). Synchronization or asynchronization does not really matter. Because you can either redirect the pipe from guest OS to host OS in asynchronization or just control the timer in synchronization. TBH, I still don’t understand the MIDI application INs and OUTs. How and why do you expose serial port in guest OS to the serial port in host OS? Do you have serial/parallel port MIDI keyboard (a physical hardware in host OS)? The more related infos you can provide from the programming point of view, the better people can help. thanks, Ricky > On Jul 2, 2018, at 11:54 AM, Brent Busby <br...@ke...> wrote: > > Signed PGP part > Ricky Zhang <zha...@gm...> writes: > >> I’m not clear what is the in and out of your application running >> inside BII. What’s the connection between virtual tty in host OS Linux >> and your application in guest OS? > > Well, Midi applications in the old classic Mac environment usually > offered a choice of using your modem or printer port, and Basilisk > connects both of those to serial device nodes on the UNIX side. For > telecomm programs, this seems to work flawlessly. ZTerm works so well > in Basilisk that I could hookup a Hayes modem and call BBS's if I knew > any dialup BBS's to call these days. > > For Midi, it seems that things are more complicated on the classic Mac > platform than it is in emulators for other OS's, due to old style Mac > serial ports being asynchronous. Midi runs at the oddball baud rate of > 31250bps, not a multiple of 300 like one normally expects. Since serial > ports on a Mac don't really have any baud rate of their own, they depend > on an adapter device to send a 1MHz clock signal _into_ the port, then > divide that into 1/32nds to obtain that exact baud rate of 31250bps. > > I don't know what would be needed to fake that, but I think that's why > on any other platform emulator, getting Midi bytes out just amounts to > letting the data go out the port, but the old m68k Mac is depending on > some external hardware to do something from the outside to generate > sync. Pin 7 of the DIN connector was the GPi pin, which received this > signal (potentially 500kHz, 1MHz, or 2MHz, but usually 1MHz). The > serial ports were capable of being driven very fast this way, and could > even be used as network ports for AppleTalk, but Midi doesn't need to > clock them anywhere near that fast. > > And yet...wouldn't it need the same thing from a modem, and have the > same problem? The port is asynchronous when modems use it too, and yet > programs like ZTerm are able to get bytes in and out just fine. Perhaps > it's because the term program is providing the baud rate itself, whereas > a classic Mac Midi program would be expecting some sort of 1MHz sync to > be provided in hardware externally? > > That's what I'm not understanding. If the Mac serial port needs > external clock to get anything done, how come a terminal program can use > it but a Midi application can't? > >> A side topic — Basilisk II can build with SDL V1. We can enable >> playing midi by SDL mixer — >> https://www.libsdl.org/projects/SDL_mixer/docs/index.html >> <https://www.libsdl.org/projects/SDL_mixer/docs/index.html>. >> >> Don’t count on anyone implement this feature for you. You’d better get your hand dirty. > > Believe me, I've already been digging around in the source for Basilisk, > ttymidi, hairless-midiserial, the Alsa libraries, etc. I'm convinced > now though that the data is being stopped in Basilisk. If the Mac > application producing the data is a terminal program like ZTerm, all I > need to get data from the serial device on the Linux side is 'cat': > > cat /dev/tnt1 > > will echo to my terminal whatever goes into ZTerm, and I don't even have > to care about the baud rate on either end. That means it's trivial to > get data from the serial device if it went in at all. But Midi data > never comes out, not with cat, not with ttymidi, not with anything. > > I think what I'm wanting though is guidance from people who already know > how the Basilisk code works. I've been digging around in serial.cpp and > serial_unix.cpp, and I'm afraid I don't understand the state of the code > as it is now enough to make any changes to it. > > |
|
From: Brent B. <br...@ke...> - 2018-07-02 15:55:33
|
Ricky Zhang <zha...@gm...> writes: > I’m not clear what is the in and out of your application running > inside BII. What’s the connection between virtual tty in host OS Linux > and your application in guest OS? Well, Midi applications in the old classic Mac environment usually offered a choice of using your modem or printer port, and Basilisk connects both of those to serial device nodes on the UNIX side. For telecomm programs, this seems to work flawlessly. ZTerm works so well in Basilisk that I could hookup a Hayes modem and call BBS's if I knew any dialup BBS's to call these days. For Midi, it seems that things are more complicated on the classic Mac platform than it is in emulators for other OS's, due to old style Mac serial ports being asynchronous. Midi runs at the oddball baud rate of 31250bps, not a multiple of 300 like one normally expects. Since serial ports on a Mac don't really have any baud rate of their own, they depend on an adapter device to send a 1MHz clock signal _into_ the port, then divide that into 1/32nds to obtain that exact baud rate of 31250bps. I don't know what would be needed to fake that, but I think that's why on any other platform emulator, getting Midi bytes out just amounts to letting the data go out the port, but the old m68k Mac is depending on some external hardware to do something from the outside to generate sync. Pin 7 of the DIN connector was the GPi pin, which received this signal (potentially 500kHz, 1MHz, or 2MHz, but usually 1MHz). The serial ports were capable of being driven very fast this way, and could even be used as network ports for AppleTalk, but Midi doesn't need to clock them anywhere near that fast. And yet...wouldn't it need the same thing from a modem, and have the same problem? The port is asynchronous when modems use it too, and yet programs like ZTerm are able to get bytes in and out just fine. Perhaps it's because the term program is providing the baud rate itself, whereas a classic Mac Midi program would be expecting some sort of 1MHz sync to be provided in hardware externally? That's what I'm not understanding. If the Mac serial port needs external clock to get anything done, how come a terminal program can use it but a Midi application can't? > A side topic — Basilisk II can build with SDL V1. We can enable > playing midi by SDL mixer — > https://www.libsdl.org/projects/SDL_mixer/docs/index.html > <https://www.libsdl.org/projects/SDL_mixer/docs/index.html>. > > Don’t count on anyone implement this feature for you. You’d better get your hand dirty. Believe me, I've already been digging around in the source for Basilisk, ttymidi, hairless-midiserial, the Alsa libraries, etc. I'm convinced now though that the data is being stopped in Basilisk. If the Mac application producing the data is a terminal program like ZTerm, all I need to get data from the serial device on the Linux side is 'cat': cat /dev/tnt1 will echo to my terminal whatever goes into ZTerm, and I don't even have to care about the baud rate on either end. That means it's trivial to get data from the serial device if it went in at all. But Midi data never comes out, not with cat, not with ttymidi, not with anything. I think what I'm wanting though is guidance from people who already know how the Basilisk code works. I've been digging around in serial.cpp and serial_unix.cpp, and I'm afraid I don't understand the state of the code as it is now enough to make any changes to it. |
|
From: Ricky Z. <zha...@gm...> - 2018-07-02 09:20:37
|
I’m not clear what is the in and out of your application running inside BII. What’s the connection between virtual tty in host OS Linux and your application in guest OS? A side topic — Basilisk II can build with SDL V1. We can enable playing midi by SDL mixer — https://www.libsdl.org/projects/SDL_mixer/docs/index.html <https://www.libsdl.org/projects/SDL_mixer/docs/index.html>. Don’t count on anyone implement this feature for you. You’d better get your hand dirty. thanks, Ricky > On Jul 2, 2018, at 2:19 AM, Brent Busby <br...@ke...> wrote: > > Short version: > I have been trying to run Sound Process Visual Editor in emulation. It > is a unique program that runs only on classic MacOS, and when m68k Macs > are no longer physically supportable, there will be no program that can > do what it does. > > Long version: > It's truly amazing, the trip I've been on trying to do this. > > Details: > This application controls the voice engine of an Ensoniq Mirage sampler, > to assist in building patches. There are a number of reasons why you'd > want to do this: > > More modern samplers do not have analog filters. The Mirage had Curtis > chips. The OS that Ensoniq shipped with the Mirage (which is called > MASOS, and which does have a lot of software support on various OS's) is > not really optimized for synthesis though; it's optimized to use the > sampler as a sampler. (The difference may be more information than > should really be in this email.) So you only have decent software > support for the Mirage if you're running an OS on it that's not much > good for synthesis. > > SoundProcess is a third party (non-Ensoniq) OS that the Mirage can boot > from which provides an entirely different voice architecture than what > it normally supports. It is optimized for people who want to use the > Mirage for synthesis instead of traditional sampling. > > There is only one program on the computer side that allows you to edit > sounds on a Mirage sampler running SoundProcess (instead of the > manufacturer provided MASOS OS), and it is a third-party app called > Sound Process Visual Editor. It is a 68k Mac application made in the > 90's by an individual who has disappeared. > > Basilisk: > From what I've been able to see in the forums, Midi support in Basilisk > was abandoned because it would be too complex to guarantee stable timing > for sequencer playback. > > However, for programs like this, which don't aim to play music but only > send raw data to a device, stable timing isn't really even important. > As long as the bytes get in and out, you can still edit patches. For > that matter, the behavior of Basilisk that I've seen running on my Linux > machine with a 4-core 3.2GHz AMD Phenom II X4 955 CPU is extremely > glitch free and responsive, far faster than any real Mac Quadra I've > ever been on. I really doubt the timing would be all that terrible even > if there were no realtime or guarantees provided. (I've seen hardware > sequencers that didn't even have any other jobs besides being sequencers > that were truly awful in that respect, just for comparison.) > > Environment: > I have setup a Linux kernel module called tty0tty on my machine. It's > very useful, as it provides four pairs of virtual serial ports connected > by virtual nullmodems. You get /dev/tnt0 through /dev/tnt7, with each > odd numbered device node connected bidirectionally to its even numbered > next device (0<=>1, 2<=>3, 4<=>5, 6<=>7). This allows you to connect > any program that expects a serial port to any other program that expects > a serial port, without getting any real serial ports involved. One > interesting benefit of this that I've observed has been that when you > use these virtual ports, it seems you can set any baud rate you want on > either side, and they don't seem to have to match. The data will simply > come across regardless, even if one side is 2400 baud and the other is > 115200, which makes sense considering there really is no actual medium. > > It has been very frustrating though seeing that I can do this, and have > Hayes modem commands come through the virtual nullmodem, but even the > simplest Midi strings produce "unimplemented control code" errors on > stderr, and not a single byte makes it through the nullmodem. > > Prognosis: > All I really need it to do is pass bytes. It doesn't have to do it > well, just let them through. > > Is there any hope that in the future Basilisk will get any kind of Midi > support, even for applications like this where timing isn't important? > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Brent B. <br...@ke...> - 2018-07-02 06:19:42
|
Short version: I have been trying to run Sound Process Visual Editor in emulation. It is a unique program that runs only on classic MacOS, and when m68k Macs are no longer physically supportable, there will be no program that can do what it does. Long version: It's truly amazing, the trip I've been on trying to do this. Details: This application controls the voice engine of an Ensoniq Mirage sampler, to assist in building patches. There are a number of reasons why you'd want to do this: More modern samplers do not have analog filters. The Mirage had Curtis chips. The OS that Ensoniq shipped with the Mirage (which is called MASOS, and which does have a lot of software support on various OS's) is not really optimized for synthesis though; it's optimized to use the sampler as a sampler. (The difference may be more information than should really be in this email.) So you only have decent software support for the Mirage if you're running an OS on it that's not much good for synthesis. SoundProcess is a third party (non-Ensoniq) OS that the Mirage can boot from which provides an entirely different voice architecture than what it normally supports. It is optimized for people who want to use the Mirage for synthesis instead of traditional sampling. There is only one program on the computer side that allows you to edit sounds on a Mirage sampler running SoundProcess (instead of the manufacturer provided MASOS OS), and it is a third-party app called Sound Process Visual Editor. It is a 68k Mac application made in the 90's by an individual who has disappeared. Basilisk: From what I've been able to see in the forums, Midi support in Basilisk was abandoned because it would be too complex to guarantee stable timing for sequencer playback. However, for programs like this, which don't aim to play music but only send raw data to a device, stable timing isn't really even important. As long as the bytes get in and out, you can still edit patches. For that matter, the behavior of Basilisk that I've seen running on my Linux machine with a 4-core 3.2GHz AMD Phenom II X4 955 CPU is extremely glitch free and responsive, far faster than any real Mac Quadra I've ever been on. I really doubt the timing would be all that terrible even if there were no realtime or guarantees provided. (I've seen hardware sequencers that didn't even have any other jobs besides being sequencers that were truly awful in that respect, just for comparison.) Environment: I have setup a Linux kernel module called tty0tty on my machine. It's very useful, as it provides four pairs of virtual serial ports connected by virtual nullmodems. You get /dev/tnt0 through /dev/tnt7, with each odd numbered device node connected bidirectionally to its even numbered next device (0<=>1, 2<=>3, 4<=>5, 6<=>7). This allows you to connect any program that expects a serial port to any other program that expects a serial port, without getting any real serial ports involved. One interesting benefit of this that I've observed has been that when you use these virtual ports, it seems you can set any baud rate you want on either side, and they don't seem to have to match. The data will simply come across regardless, even if one side is 2400 baud and the other is 115200, which makes sense considering there really is no actual medium. It has been very frustrating though seeing that I can do this, and have Hayes modem commands come through the virtual nullmodem, but even the simplest Midi strings produce "unimplemented control code" errors on stderr, and not a single byte makes it through the nullmodem. Prognosis: All I really need it to do is pass bytes. It doesn't have to do it well, just let them through. Is there any hope that in the future Basilisk will get any kind of Midi support, even for applications like this where timing isn't important? |
|
From: Ricky Z. <zha...@gm...> - 2017-09-23 23:04:40
|
Hi Simon, Any idea why your PR only works for X11 DGA but not SDL? If we could make it works in SDL, we can leverage David’s work in SDL2 that can zoom 512x384 in the hi-res screen. Also, we may be able to enable sound manager as well. Just for fun. BTW, I fixed emulated hard drive for Mac SE and Mac Classic ROM on top of my another patch in ROM break point. Now you can give a try of my fix in your repo. thanks, Ricky > On Sep 10, 2017, at 6:33 PM, Simon Frankau <sg...@ar...> wrote: > > Hi. > > Sorry I didn't reply earlier - spam filters. :( > > I'm definitely using 24-bit mode. I'm building to use X11, configured in banked mode. The ROMs are assuming the framebuffer lives at the end of RAM. Moreover, the framebuffer is not aligned to a 64K bank, so the existing framebuffer banking code doesn't work. > > I've written a pull request that copies these writes to the framebuffer - https://github.com/cebix/macemu/pull/131 <https://github.com/cebix/macemu/pull/131>. A slightly more "Basilisk-II-style" solution might be to map the framebuffer somewhere else into the 24-bit address space in 24-bit mode and tweak the ROM to write there instead, but that's beyond my knowledge. > > Cheers, > Simon. > > On 21 August 2017 at 23:49, Ricky Zhang <zha...@gm... <mailto:zha...@gm...>> wrote: > 1. Only virtual addressing a.k.a memory bank supports 24 bit mode. First of all, you need to confirm you are in 24bit mode. > > 2. I assume you use SDL, the virtual addressing mode divides memory into banks (RTFM https://github.com/cebix/macemu/wiki/Basilisk-II-Core-Emulation-Analysis#virtual-addressing <https://github.com/cebix/macemu/wiki/Basilisk-II-Core-Emulation-Analysis#virtual-addressing>) and assign corresponding RAM, ROM and frame buffer read/write function by map_bank function during initialization. > > 3. I’m not sure what frame layout you use, but if you check any frame buffer read/write function frame_host_xxx_xxx in src/uae_cpu/memory.cpp. The mapping only applies difference between MacFrameBaseHost and MacFrameBaseMac directly to guest Mac frame buffer address to get host frame buffer. > > 4. I’m not sure how Macintosh guest OS handles 0xa0000000 in 24 bit addressing. I hope someone can help us on this. > > 0530 <> void memory_init <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=memory_init>(void) > 0531 <> { > 0532 <> for(long i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i>=0; i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i><65536; i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i>++) > 0533 <> put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank>(i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i><<16, &dummy_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=dummy_bank>); > 0534 <> > 0535 <> // Limit RAM size to not overlap ROM > 0536 <> uint32 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uint32> ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> = RAMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMSize> > ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> ? ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> : RAMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMSize>; > 0537 <> > 0538 <> RAMBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)RAMBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac>; > 0539 <> ROMBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)ROMBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac>; > 0540 <> FrameBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FrameBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)MacFrameBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac>; > 0541 <> > 0542 <> // Map RAM and ROM > 0543 <> if (TwentyFourBitAddressing <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=TwentyFourBitAddressing>) { > 0544 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&ram24_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram24_bank>, RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac> >> 16, ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> >> 16); > 0545 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&rom24_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=rom24_bank>, ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> >> 16, ROMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMSize> >> 16); > 0546 <> } else { > 0547 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&ram_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_bank>, RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac> >> 16, ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> >> 16); > 0548 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&rom_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=rom_bank>, ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> >> 16, ROMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMSize> >> 16); > 0549 <> } > 0550 <> > 0551 <> // Map frame buffer > 0552 <> switch (MacFrameLayout <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameLayout>) { > 0553 <> case FLAYOUT_DIRECT <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_DIRECT>: > 0554 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_direct_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_direct_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); > 0555 <> break; > 0556 <> case FLAYOUT_HOST_555 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_555>: > 0557 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_555_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_555_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); > 0558 <> break; > 0559 <> case FLAYOUT_HOST_565 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_565>: > 0560 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_565_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_565_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); > 0561 <> break; > 0562 <> case FLAYOUT_HOST_888 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_888>: > 0563 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_888_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_888_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); > 0564 <> break; > 0565 <> } > 0566 <> } > 0567 <> > 0568 <> void map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(addrbank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=addrbank> *bank, int start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>, int size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>) > 0569 <> { > 0570 <> int bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>; > 0571 <> unsigned long int hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> = 0, endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs> = 0x100; > 0572 <> > 0573 <> if (start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start> >= 0x100) { > 0574 <> for (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> = start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> < start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start> + size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>++) > 0575 <> put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank> (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> << 16, bank); > 0576 <> return; > 0577 <> } > 0578 <> if (TwentyFourBitAddressing <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=TwentyFourBitAddressing>) endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs> = 0x10000; > 0579 <> for (hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> = 0; hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> < endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs>; hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> += 0x100) > 0580 <> for (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> = start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> < start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>+size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>++) > 0581 <> put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank>((bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> + hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs>) << 16, bank); > 0582 <> } > 0583 <> > 0584 <> #endif /* !REAL_ADDRESSING && !DIRECT_ADDRESSING */ > > >> On Aug 21, 2017, at 5:33 PM, Simon Frankau <sg...@ar... <mailto:sg...@ar...>> wrote: >> >> Hi. >> >> I'm trying to use Basilisk II to emulate a Mac Classic - I want to emulate a Mac running in 24-bit mode. My attempts to make it work using unpatched source didn't work. I'm not sure how it's intended to work, but I saw: >> >> const uint32 MacFrameBaseMac = 0xa0000000; >> >> in cpu_emulation.h. In 24-bit mode this aliases with 0x000000, and on the Classic the framebuffer is expected to live at 0x3fa700. >> >> Given this, I'm not sure how the display is expected to work in Basilisk II for a Classic or other 24-bit mode Macs. I've created a patch to make the Classic framebuffer work (and it boots up 6.0.8 ok). However, I wanted to check if I've missed something silly, and if there's just a flag I should be specifying to make it work. If not, what's the appropriate way to suggest a patch? >> >> Thanks, >> Simon. >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________> >> basilisk-devel mailing list >> bas...@li... <mailto:bas...@li...> >> https://lists.sourceforge.net/lists/listinfo/basilisk-devel <https://lists.sourceforge.net/lists/listinfo/basilisk-devel> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot> > _______________________________________________ > basilisk-devel mailing list > bas...@li... <mailto:bas...@li...> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel <https://lists.sourceforge.net/lists/listinfo/basilisk-devel> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Ricky Z. <zha...@gm...> - 2017-09-23 11:25:05
|
Hi, I’m poking around BII display internal. I wondered if anyone can share a copy of Display Device Driver Guide PDF in the web archive link below: http://web.archive.org/web/20020208203027/http://developer.apple.com/techpubs/hardware/DeviceManagers/displaydevices/displaydevices.html <http://web.archive.org/web/20020208203027/http://developer.apple.com/techpubs/hardware/DeviceManagers/displaydevices/displaydevices.html> thanks, Ricky |
|
From: Simon F. <sg...@ar...> - 2017-09-10 22:33:52
|
Hi. Sorry I didn't reply earlier - spam filters. :( I'm definitely using 24-bit mode. I'm building to use X11, configured in banked mode. The ROMs are assuming the framebuffer lives at the end of RAM. Moreover, the framebuffer is not aligned to a 64K bank, so the existing framebuffer banking code doesn't work. I've written a pull request that copies these writes to the framebuffer - https://github.com/cebix/macemu/pull/131. A slightly more "Basilisk-II-style" solution might be to map the framebuffer somewhere else into the 24-bit address space in 24-bit mode and tweak the ROM to write there instead, but that's beyond my knowledge. Cheers, Simon. On 21 August 2017 at 23:49, Ricky Zhang <zha...@gm...> wrote: > 1. Only virtual addressing a.k.a memory bank supports 24 bit mode. First > of all, you need to confirm you are in 24bit mode. > > 2. I assume you use SDL, the virtual addressing mode divides memory into > banks (RTFM https://github.com/cebix/macemu/wiki/Basilisk-II- > Core-Emulation-Analysis#virtual-addressing) and assign corresponding RAM, > ROM and frame buffer read/write function by map_bank function during > initialization. > > 3. I’m not sure what frame layout you use, but if you check any frame > buffer read/write function frame_host_xxx_xxx in src/uae_cpu/memory.cpp. > The mapping only applies difference between MacFrameBaseHost and > MacFrameBaseMac directly to guest Mac frame buffer address to get host > frame buffer. > > 4. I’m not sure how Macintosh guest OS handles 0xa0000000 in 24 bit > addressing. I hope someone can help us on this. > > 0530 void memory_init <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=memory_init>(void)0531 {0532 for(long i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i>=0; i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i><65536; i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i>++)0533 put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank>(i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i><<16, &dummy_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=dummy_bank>);0534 0535 // Limit RAM size to not overlap ROM0536 uint32 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uint32> ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> = RAMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMSize> > ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> ? ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> : RAMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMSize>;0537 0538 RAMBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)RAMBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac>;0539 ROMBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)ROMBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac>;0540 FrameBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FrameBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)MacFrameBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac>;0541 0542 // Map RAM and ROM0543 if (TwentyFourBitAddressing <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=TwentyFourBitAddressing>) {0544 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&ram24_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram24_bank>, RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac> >> 16, ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> >> 16);0545 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&rom24_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=rom24_bank>, ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> >> 16, ROMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMSize> >> 16);0546 } else {0547 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&ram_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_bank>, RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac> >> 16, ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> >> 16);0548 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&rom_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=rom_bank>, ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> >> 16, ROMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMSize> >> 16);0549 }0550 0551 // Map frame buffer0552 switch (MacFrameLayout <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameLayout>) {0553 case FLAYOUT_DIRECT <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_DIRECT>:0554 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_direct_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_direct_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1);0555 break;0556 case FLAYOUT_HOST_555 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_555>:0557 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_555_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_555_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1);0558 break;0559 case FLAYOUT_HOST_565 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_565>:0560 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_565_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_565_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1);0561 break;0562 case FLAYOUT_HOST_888 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_888>:0563 map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_888_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_888_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1);0564 break;0565 }0566 }0567 0568 void map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(addrbank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=addrbank> *bank, int start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>, int size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>)0569 {0570 int bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>;0571 unsigned long int hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> = 0, endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs> = 0x100;0572 0573 if (start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start> >= 0x100) {0574 for (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> = start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> < start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start> + size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>++)0575 put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank> (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> << 16, bank);0576 return;0577 }0578 if (TwentyFourBitAddressing <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=TwentyFourBitAddressing>) endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs> = 0x10000;0579 for (hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> = 0; hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> < endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs>; hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> += 0x100)0580 for (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> = start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> < start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>+size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>++)0581 put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank>((bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> + hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs>) << 16, bank);0582 }0583 0584 #endif /* !REAL_ADDRESSING && !DIRECT_ADDRESSING */ > > > > On Aug 21, 2017, at 5:33 PM, Simon Frankau <sg...@ar...> wrote: > > Hi. > > I'm trying to use Basilisk II to emulate a Mac Classic - I want to emulate > a Mac running in 24-bit mode. My attempts to make it work using unpatched > source didn't work. I'm not sure how it's intended to work, but I saw: > > const uint32 MacFrameBaseMac = 0xa0000000; > > in cpu_emulation.h. In 24-bit mode this aliases with 0x000000, and on the > Classic the framebuffer is expected to live at 0x3fa700. > > Given this, I'm not sure how the display is expected to work in Basilisk > II for a Classic or other 24-bit mode Macs. I've created a patch to make > the Classic framebuffer work (and it boots up 6.0.8 ok). However, I wanted > to check if I've missed something silly, and if there's just a flag I > should be specifying to make it work. If not, what's the appropriate way to > suggest a patch? > > Thanks, > Simon. > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot______ > _________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > |
|
From: Ricky Z. <zha...@gm...> - 2017-08-23 01:02:59
|
Hi all, I'm reading BII emulation code. I'm poking around ROM patch. I wonder if anyone has ever annotate or write in-line document on 68k assembly code from Performa ROM. I got cxmon and radare2 to disassemble Performa. But it will be great if I can find some notes of Performa ROM like mini vmac provides fdiasm + annotation for Mac Plus ROM ( http://www.gryphel.com/c/minivmac/extras/fdisasm/roms.html) thanks, Ricky |
|
From: Ricky Z. <zha...@gm...> - 2017-08-21 22:49:30
|
1. Only virtual addressing a.k.a memory bank supports 24 bit mode. First of all, you need to confirm you are in 24bit mode. 2. I assume you use SDL, the virtual addressing mode divides memory into banks (RTFM https://github.com/cebix/macemu/wiki/Basilisk-II-Core-Emulation-Analysis#virtual-addressing <https://github.com/cebix/macemu/wiki/Basilisk-II-Core-Emulation-Analysis#virtual-addressing>) and assign corresponding RAM, ROM and frame buffer read/write function by map_bank function during initialization. 3. I’m not sure what frame layout you use, but if you check any frame buffer read/write function frame_host_xxx_xxx in src/uae_cpu/memory.cpp. The mapping only applies difference between MacFrameBaseHost and MacFrameBaseMac directly to guest Mac frame buffer address to get host frame buffer. 4. I’m not sure how Macintosh guest OS handles 0xa0000000 in 24 bit addressing. I hope someone can help us on this. 0530 <> void memory_init <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=memory_init>(void) 0531 <> { 0532 <> for(long i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i>=0; i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i><65536; i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i>++) 0533 <> put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank>(i <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=i><<16, &dummy_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=dummy_bank>); 0534 <> 0535 <> // Limit RAM size to not overlap ROM 0536 <> uint32 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uint32> ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> = RAMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMSize> > ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> ? ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> : RAMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMSize>; 0537 <> 0538 <> RAMBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)RAMBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac>; 0539 <> ROMBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)ROMBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac>; 0540 <> FrameBaseDiff <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FrameBaseDiff> = (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)MacFrameBaseHost <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseHost> - (uintptr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=uintptr>)MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac>; 0541 <> 0542 <> // Map RAM and ROM 0543 <> if (TwentyFourBitAddressing <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=TwentyFourBitAddressing>) { 0544 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&ram24_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram24_bank>, RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac> >> 16, ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> >> 16); 0545 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&rom24_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=rom24_bank>, ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> >> 16, ROMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMSize> >> 16); 0546 <> } else { 0547 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&ram_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_bank>, RAMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=RAMBaseMac> >> 16, ram_size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ram_size> >> 16); 0548 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&rom_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=rom_bank>, ROMBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMBaseMac> >> 16, ROMSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=ROMSize> >> 16); 0549 <> } 0550 <> 0551 <> // Map frame buffer 0552 <> switch (MacFrameLayout <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameLayout>) { 0553 <> case FLAYOUT_DIRECT <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_DIRECT>: 0554 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_direct_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_direct_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); 0555 <> break; 0556 <> case FLAYOUT_HOST_555 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_555>: 0557 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_555_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_555_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); 0558 <> break; 0559 <> case FLAYOUT_HOST_565 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_565>: 0560 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_565_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_565_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); 0561 <> break; 0562 <> case FLAYOUT_HOST_888 <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=FLAYOUT_HOST_888>: 0563 <> map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(&frame_host_888_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=frame_host_888_bank>, MacFrameBaseMac <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameBaseMac> >> 16, (MacFrameSize <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=MacFrameSize> >> 16) + 1); 0564 <> break; 0565 <> } 0566 <> } 0567 <> 0568 <> void map_banks <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=map_banks>(addrbank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=addrbank> *bank, int start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>, int size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>) 0569 <> { 0570 <> int bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>; 0571 <> unsigned long int hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> = 0, endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs> = 0x100; 0572 <> 0573 <> if (start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start> >= 0x100) { 0574 <> for (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> = start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> < start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start> + size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>++) 0575 <> put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank> (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> << 16, bank); 0576 <> return; 0577 <> } 0578 <> if (TwentyFourBitAddressing <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=TwentyFourBitAddressing>) endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs> = 0x10000; 0579 <> for (hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> = 0; hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> < endhioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=endhioffs>; hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs> += 0x100) 0580 <> for (bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> = start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> < start <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=start>+size <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=size>; bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr>++) 0581 <> put_mem_bank <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=put_mem_bank>((bnr <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=bnr> + hioffs <http://192.168.2.213/lxr/ident/bii?v=15Aug2017&_i=hioffs>) << 16, bank); 0582 <> } 0583 <> 0584 <> #endif /* !REAL_ADDRESSING && !DIRECT_ADDRESSING */ > On Aug 21, 2017, at 5:33 PM, Simon Frankau <sg...@ar...> wrote: > > Hi. > > I'm trying to use Basilisk II to emulate a Mac Classic - I want to emulate a Mac running in 24-bit mode. My attempts to make it work using unpatched source didn't work. I'm not sure how it's intended to work, but I saw: > > const uint32 MacFrameBaseMac = 0xa0000000; > > in cpu_emulation.h. In 24-bit mode this aliases with 0x000000, and on the Classic the framebuffer is expected to live at 0x3fa700. > > Given this, I'm not sure how the display is expected to work in Basilisk II for a Classic or other 24-bit mode Macs. I've created a patch to make the Classic framebuffer work (and it boots up 6.0.8 ok). However, I wanted to check if I've missed something silly, and if there's just a flag I should be specifying to make it work. If not, what's the appropriate way to suggest a patch? > > Thanks, > Simon. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
9 messages has been excluded from this view by a project administrator.
