Wanted: feedback from Mac OS X users

Page 4/18
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

By sd_snatcher

Prophet (3471)

sd_snatcher's picture

06-11-2013, 21:53

Quote:

The OSD menu offers a selection of the most used/important functionality. We didn't consider changing harddisk images being amongst that... that's why it's not in. Of course you can still use the IDE extension with the default harddisk image (via the hardware menu).

Let's talk a little about this one. Smile

Keep in mind that I'm not arguing for a feature that I would use myself (since I use NekoLauncher when not developing, and the plain command line when developing), but instead it's for the easy of use that I hear other users complaining about.

The OSD-Menu seems to have been designed with the "regular user" (as opposite to "advanced user") use-case in mind, right? This means that it is a interface to allow this kind of user to enjoy openMSX easily, in any platform, without having to learn any command line parameters.

With that in mind, it really reach this goal when ROMs, tapes, floppy disks and extensions are involved. I guess that the "boosted MSX" machines were also built with kind of user in mind, right? It's a type of machine with "everything on top" that makes running any program much easier and without worries about which extension to add for which games.

In a test drive I did with some friends, the following list explains what they felt that was missing in the OSD-Menu that only could be achieved by fiddling with command line commands that they didn't wanted to learn (putting this in a funny way, one mentioned that he "had allergies to unknown command prompts" Smile ).

- A way to save the current running machine as the default one, to be used instead of the current C-BIOS one.
- An easy way to use harddisks. There are even ready-to-use IDE HDD images on the Net, but they weren't able to plug/use them easily
- A way to operate the OSD-Menu using only the mouse. Currently it doesn't seem possible to click away from an already selected menu option to close it. Also, it's not possible to click in the tabs of each running machine to select or close them.
- A Boosted MSX Turbo-R machine (similar to the Boosted MSX2+JP) with IDE interface, could be present.
- Lacks a way to create a blank tape easily. This is useful for games with savegames on tape, like Metal Gear 1. It could be similar to the savestate handling.
- Lack of a per-chip volume adjustment inside the sound-settings menu, mainly to adjust the FM/PSG volume ratio for some games
- Should ask for a name when creating new savestates (or use the game name), and allow savestate deletion

Apart from those features they felt that were missing, they praised the many other OSD-Menu qualities, such as:

- Allows openMSX to be operated with minimal knowledge of MSX hardware or the emulator's command line parameters/built-in commands. A frontend doesn't seem necessary anymore.
- Scalers and video configuration is easy
- Joyport devices can be easily plugged
- Even the toys can be easily enabled/disabled
- ROMs and disks can be inserted/ejected/changed without pain
- Save state load/save interface is still very good

By Manuel

Ascended (18148)

Manuel's picture

06-11-2013, 22:45

Wow, thanks for this awesome feedback!

Several of these things I've thought about, but they were often in the category "most users won't use it" (e.g. the harddisk thing) or "bound by limitations of the OSD menu". Note that the OSD menu was mostly developed for handhelds without keyboards and later extended for touch/mouse usage (mostly for Android).

Anyway, thanks again, I'll carefully look at these things and think about how they could be (partly or completely) implemented.

Did you know you *can* operate laser discs with the OSD menu? ;-)

Some detailed personal reactions:
- funny that you actually used the tabbed MSX'ing! It's a feature I implemented years ago (in July 2009, mostly for fun), but it seems like no one ever used it before. Mouse controlled OSD exists only less than a year, so I never made mouse support for the tabbed MSX'ing
- Better mouse control for OSD: I'll check what's possible to improve it. Should not be too hard to make a 'close current menu' thing, e.g. by clicking outside of it.
- Setting the current MSX as default is a good point. A workaround is to use a savestate where you can start with (that also makes it possible to have default extensions loaded, as it were)
- Boosted turboR: yes, thought about it. I actually thought I had made one, but I couldn't find it anymore. What would be the ultimate configuration for that?
- Tape control could be greatly extended (with a timer etc.), but I thought 'most people just play the games'. There is no tape management indeed (create new ones), but the same is true for disks.
- Chip volume control: not very hard to create, but I thought again: "most users don't use it", so it was low priority
- Asking for names etc. is very tricky, as the OSD menu doesn't allow an easy way for keyboard input (again, it was made for handhelds). So don't count on that one soon.

By sd_snatcher

Prophet (3471)

sd_snatcher's picture

06-11-2013, 23:26

Quote:

Did you know you *can* operate laser discs with the OSD menu? ;-)

No, I didn't! That's a nice surprise! Smile

But I never tried any games of this kind mainly because I don't have any LaserDisc games dumps at hand. I was only able to find them on a single website behind a paywall, but there nothing to assure that those images are indeed working.

By Manuel

Ascended (18148)

Manuel's picture

06-11-2013, 23:39

Oh, about the VDP access: to be able to emulate it, we really need to know in more details how it works. The WAIT pin of the V9958 for instance: when exactly is it set? And how exactly do these delay devices work? Creating something that seems to do it is not that hard, but it would be mostly guesswork on how it really behaves...

By sd_snatcher

Prophet (3471)

sd_snatcher's picture

07-11-2013, 00:49

I did some very rudimentary tests connecting a LED to the /WAIT signal of the V9958 some years ago. This is the best I could do, since I have no logic analyzer at hand. The LED lit stronger as the speed increased, meaning that the V9958 generated more WAITs to accommodate that.

My educated guess is that when the Z80 tries a write to the VRAM and there's no free timeslot to do it, the V9958 asserts the /WAIT until a free timeslot to the VRAM is available.

The /WAIT generation must be enabled on VDP R#25, bit2. Otherwise no WAIT will be generated at all. The ExpertTurbo BIOS has some extra routines built-in to enable/disable this bit when the turbo is enabled/disabled. If the turbo clock is enabled by direct I/O without enabling the VDP R#25 bit2, VRAM corruption will happen.

--------

The Panasonic MSX2+ machines, OTOH, uses a completely different mechanism, done entirely by the 6140140 custom chipset (I linked the service manual in my previous post). Its seems to be a superset of the way the homebrew turbo kits slow down the CPU clock on VDP I/O.

The 6140140 chipset receives the CSYNC, CPUCLK (3.57MHz) and DHCLK (10.74MHz) from the V9958, which suggests that the clock speed selection probably takes the VBLANK/HBLANK into account when deciding which CPU speed it will use. More details could be only be obtained if someone someday connects a logic analyzer to all those inputs/outputs to understand what's going on.

Conclusion:

IMHO, for now, openMSX could just implement a 3.57MHz clock slowdown for all VDP I/O on Panasonic MSX2+ machines. Probably this isn't too far from what the 6140140 chipset does. This can be improved in the future when more details arise.

The ExpertTurbo OTOH, will require the V9958 /WAIT generation to be emulated (even if it is an educated guess of how it works), because it does all it's I/O at full 7.14MHz.

By wouter_

Champion (467)

wouter_'s picture

07-11-2013, 19:09

sd_snatcher wrote:

I did some very rudimentary tests connecting a LED to the /WAIT signal of the V9958 ...

My educated guess is that when the Z80 tries a write to the VRAM and there's no free timeslot to do it, the V9958 asserts the /WAIT until a free timeslot to the VRAM is available.

This is indeed what you'd hope would happen. At least if I understood you correctly, to make sure, let me try to rephrase: Ideally you'd only like to see an active WAIT signal in those cases where not slowing down the Z80 would otherwise result in corrupt VRAM. Or in other words you don't want to unnecessarily slow down the Z80. Though this is (all) what the V9958 datasheet says about the /WAIT signal:

V9958_datasheet wrote:

When the CPU accesses the VRAM, accesses to all ports on V9958 is held in the WAIT state until access to the VRAM of V9958 is completed.

This is a very vague description. My first interpretation of this quote would be that /WAIT is activated when the VDP receives a VRAM request (read or write) and deactivated when that request is handled. But this interpretation will slow down the VDP unnecessarily.

@sd_snatcher: Do you remember whether in your experiment the LED lit at all in 3.5MHz mode? In the ideal scenario the LED should not lit when running normal MSX software because that software works without problems (so without extra wait states) on a regular MSX.

@sd_snatcher: Do you know whether the VDP-WAIT output signal is directly connected to the Z80 WAIT input. Or is it still combined with other VDP control signals? So maybe only wait when the VDP WAIT signal is active AND the Z80 is accessing the VDP?

By PingPong

Prophet (3760)

PingPong's picture

07-11-2013, 22:03

wouter_ wrote:

This is a very vague description. My first interpretation of this quote would be that /WAIT is activated when the VDP receives a VRAM request (read or write) and deactivated when that request is handled. But this interpretation will slow down the VDP unnecessarily.

@wouter. Effectively is unclear when this wait is asserted. I like to know your guess about the following situations:
- one can do vram address setup using 0x99 ports. Is the signal activated?
- one can do vdp register write that use 0x99 port too. Is the signal activated?
- one can write to vdp command registers ( even the register used to perform VRAM<->z80 byte transfers, when using vdp commands). Is the signal activated?
thx

By sd_snatcher

Prophet (3471)

sd_snatcher's picture

08-11-2013, 01:15

I agree with you that the Z80 should not be slowed down unnecessarily, and it indeed seems to be the case as at 3.57Mhz the led didn't seem to lit at all.

Also, the V9958 /WAIT output is directly connected to the Z80 /WAIT line, after being ANDed with the /WAIT line from the slot connectors.

But it's important to remember two important premises though:

P1) The Z80 only samples the /WAIT pin at the TW stage of the I/O instruction execution. This is mentioned in the Z80 User Manual, pages 14 & 15 (“Input or Output cycles”).

So, if the /WAIT is asserted by the VDP for a period of time smaller than the TW cycle of the next instruction, that wait request will go ignored Z80 will not be slowed down at all. This mechanism allows CPUs with different clocks to deal with the same signals without modification. Only the faster CPUs will be able to see the smaller /WAIT requests. And since VRAM writes are usually done by a OTIR or a sequence of OUTIs, this explains why the LED wasn’t lit at all.

P2) A CPU-VRAM read operation effectively begins inside the VDP after the Z80 writes the 2nd byte at the port 99h. A CPU-VRAM write operation effectively begins inside the VDP after the Z80 writes the data byte at the port 98h.

That said, it's possible to detail the algorithm a bit more: breaking that V9958 datasheet paragraph you quoted in smaller pieces gives me something that seems to have been written in a very algorithm-like style:

(1) “When the CPU accesses the VRAM",

(2) ”accesses to all ports on V9958 is held in the WAIT state"

(3) "until access to the VRAM of V9958 is completed."

Combining this algorithm with the mentioned premises and your reverse engineering means that

For CPU-VRAM write, a (1) 98h port write goes to the buffer and sets an internal waiting_access_slot_flag that will only will be turned off after (3) the VRAM operation is completed. Any (2) /CSW or /CSR activation in this period will cause a /WAIT to be issued. By inference, this means that if both /CSR or /CSW are off, then no /WAIT is issued.

For CPU-VRAM read, a (1) 99h second port write immediately sets an internal waiting_access_slot_flag that will only will be turned off after (3) the VRAM operation is completed. Any (2) /CSW or /CSR activation in this period will cause a /WAIT to be issued. By inference, if both /CSR or /CSW are off, then no /WAIT is issued.

The truth table for the WAIT generation engine inside the V9958 probably goes like this:

waiting_access_slot_flag	/CSW	/CSR		outputs /WAIT
0				any	any		1
1				1	0		0
1				0	1		0
1				1	1		1

This logic and the fact that the Z80 only samples /WAIT on TW state for I/O instructions means that a VRAM write sequence will go like this:

1) After the Z80 writes 98h I/O port, the /WR will be raised and no /WAIT will be issued yet by the V9958, even if waiting_access_slot is true;
2) If a next Z80 write to any VDP I/O port happens before waiting_acces_slot_flag is cleared, /WAIT will be issued as soon as /CSW or /CSR is activated. Any other Z80 instruction not related to accessing the VDP ports will not result in the VDP issuing a /WAIT signal

For a Z80 VRAM read, the sequence goes like this:

1) After the Z80 writes 99h I/O port for the 2nd time, the /WR will be raised and no /WAIT will be issued yet by the V9958, even if waiting_access_slot is true;
2) If a next Z80 read to any VDP I/O port happens before waiting_acces_slot_flag is cleared, /WAIT will be issued as soon as /CSW or /CSR is activated. Any other Z80 instruction not related to accessing the VDP ports will not result in the VDP issuing a /WAIT signal.

I hope I was able to clarify things, and not make them even more confusing. Smile

KdL: I think that the information disclosed here is important even for the One Chip MSX. Probably it isn’t being able to run stable at faster than 10MHz because of the lack of this V9958 /WAIT signal.

By sd_snatcher

Prophet (3471)

sd_snatcher's picture

12-11-2013, 00:51

@Manuel

I built the cable accordingly to the MSX FAQ and the F1XD service manual, but unfortunately it didn't work properly. The recordings it produces are very faint. Sad

Loading tapes and the remote relay seems to work fine though.

Any expert in electronics could give some advice? If I connect the tape output to my stereo player input, the sound is very faint, almost inaudible.

I checked all the connections with a multimeter and they seem to be Ok.

Note: I don't have a real cassette recorder anymore.

By sd_snatcher

Prophet (3471)

sd_snatcher's picture

12-11-2013, 01:32

Ok, the cable is Ok. The problem is that the iPhone mic-in adapter I have seems specific for PC headsets and non-powered microphones, similar to this one.

Probably th MSX output would require some adapter similar to this one. Or even this one.

O connected the cable to my old notebook mic-in, and it worked fine for loading/saving BASIC programs.

Page 4/18
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9