Home Page Forums Active Threads

Has anyone actually played both of these? It's hard to tell for sure from the pictures on my site, but it kind of looks like they might be the same game, just with different LCD panels. The artwork on both of the games seems to suggest the object is to get away from someone/thing throwing stuff at you...

I've opened a tabletop before, and it's still just a blob like the little handhelds... So would require a decapping to figure it out.

At the moment it looks like only nes.xml includes dipswitch tags from the DTD. They don't seem to show up in the UI as far as I can tell. Are they even exposed via the UI or command line? I'm guessing no, since nwc90 has working dips but uses the ioport stuff.

in this case z80 ice will help. I am preparing a stand.

It’s because the snapshot directory is actually an output directory for saving snapshots/videos that the UI happens to re-use, while the others are just for UI assets.

Time to find more software then

It takes an unusually long time to boot up for me (I actually thought it was broken at first) but it did come up.

Some additional 680x0 FPU fixes allow us to load and view wireframes in Strata StudioPro, a popular early 3D modeling program for the Mac. (Strata was used to render the graphics in Myst).

I have gotten this PPA that resolves qt4 dependencies, but "libphonon-dev" is still missing.
Qt4 for Ubuntu 20.04

Anyway I get an error trying to compile:


Looking for Qt5?

Hopefully the disk image I linked to above will help. it's a very complete SunOS 3.2 install with every single component installed (including all the dev tools and compilers)

-Thom

The guide's usage of the name MESS shows its age. That said, I think there are still a few instances of "MESS" in the MAME source code where the comments haven't been updated.

Emulation can do what the original hardware could do. But if there isn't, or wasn't, original hardware that actually did what you want it to do, then don't be surprised when you have to "get out and push" a little bit.

I'm not at all familiar with the Channel F, but being familiar with the layout of the MAME codebase, I took a quick look at src/devices/chanf/slot.cpp.

The long and short of it is that the software-list hash file is what primarily describes which type of PCB was used by a given cartridge. If you open hash/channelf.xml in a text editor, you can see how the type of cartridge PCB is specified for each cartridge, using the following attribute:


Where "std" is for standard cartridges, and the remaining options are "maze", "hangman", "chess", "multi_old", and "multi".

If you don't want to deal with XML files, then your options are more limited. There isn't a really good way of examining a loose file and determining what cartridge type it should use, so MAME makes some assumptions based on the file length, as seen in the previously-mentioned src/devices/chanf/slot.cpp:


Just by looking at the usage patterns in the files in src/devices/bus/chanf/, and looking at the additional per-cartridge-type logic in src/mame/drivers/channelf.cpp, you should be able to trivially work out how to add whatever hypothetical cartridge type you're thinking of, with whatever arrangement of address mapping you want.

Just be aware that such changes will most likely not be rolled into mainline MAME until and unless you actually make some sort of cartridge that uses whatever memory configuration you finally decide on. Your opinion of what an emulator should be able to do does not really align with the goal of MAME, which is to accurately represent hardware that actually existed. Having been involved in making homebrew cartridges yourself, you should know that there are many different means of hooking RAM up to a cartridge, and many different types of RAM chip: What exactly is MAME supposed to do in that case? You didn't just snap your fingers and boom, RAM was on the cartridge, you had to actually select what type of RAM chip you wanted.

Beyond all that, I would agree that the current implementation of the cartridge bus in MAME is very poor. The driver itself should not need to be installing this or that set of handlers based on cartridge type. It should simply be exposing the entire address bus to the slot device, and a line to indicate whether a given R/W cycle is to program space or IO space. It should be easier than it currently is to add a new hypothetical cartridge type.

But it's still very easy to do, so I don't understand the level of moaning about it.

Find out that the problem is not with the stepper motor. I checked two of its windings, the resistance of both is 22 ohms. oiled the spindle but did not give any results. the motors are controlled by two Darlington assemblies of the STA434A transistor. they are very hot over 50-60 degrees Celsius. I watched the signals with an oscilloscope on these assemblies of transformers, at one output of a constant voltage of 12 volts, and at the other output a high-frequency signal of more than 1 MHz and an amplitude of 12 volts is generated. It looks like self-excitation, due to the breakdown of the trasistor. if I move the head from the initial position with my hands (it is mandatory with rotating discs), then when I turn it on again, the head returns to its initial position. assuming Darlington transistors are punctured. I'm currently looking for where to buy them.

I've added an archive with the newly dumped ROMs of the Philips :YES from the vcfed forum thread to the FTP.

MAMEdev's moving our MAME IRC channels to Libera.Chat!

Along with a growing list of Open Source and Free Software projects (https://github.com/siraben/freenode-exodus) and other communities, we’re moving our official IRC presence off freenode.

Our new home is #mame (ircs://irc.libera.chat:6697/#mame) on Libera.Chat (https://libera.chat/).

Drop by and say hello if you have a chance! For more information, see our our IRC page: https://www.mamedev.org/irc.html

The change looks rather sane.

Sorry for stressing, didn't want this to die out as it seems to have done the last time I asked (in February), so I tried to motivate my concerns with a few images as well to explain the "problem".



@AJR
Having H, K, Q as it is displayed right now is actually better than the H and L for each, good one, thanks!.

Yes octal numbers are just used for the ISAR but handled a lot. When optimizing for speed you just want to change high or low octal digit and not use the option to first load a number and set that to ISAR. It's often done in 1 cycle instead of 2 or 3 - it adds up - especially with the slowest graphics update for any color videogame ever(?). Using cartridge SRAM is at least 2,5 cycle for any read or write.

To be able to work with it I have used a register list at the top of the code document - with a translation list in octal, decimal and hex.
Reason for this is that coding is done with octal numbers, the debugger registers are listed in decimal and register selection in ISAR is shown in hex.
If "IS" displays "34" in the debugger - which register is it, what is set in the code? (value can be viewed in R52 and it's set as the octal number 64 in the code).
It's important for speed as well as keeping track as an increase or decrease (with this system) doesn't use carry. Increase 67 and you get 60, decrease 50 and you get 57 - the individual octal digits matter, it's an octal banks of registers. You can toggle circular in eight banks.

If a register list is reintroduced and instead got names with hex numbers - it would save the extra decimal translation (for me at least). I'm sure there are people doing this translation in their heads - I do too, some decimal vs hex - but octal... it's a bit odd, only a few values have stuck.

Ideally would be to see the same information in the debugger as is used in the code - octal numbers in the register names and octal numbers shown in "IS" but I understand it's odd and perhaps difficult to include as it's a special case.

I like the "Registers as memory" it's great to be able to watch it that way as well.

I was able to get the buttons hooked up and working:




Gonna have to leave this for awhile, but it's fun to make progress!

Woot! Looking forward to trying Mrs. Dynamite! P.S. Is it too late to fix a grammar typo in the announcement? "Mrs. Dynamite is believed to had performed" -> "to have performed".

I'd love to see them displayed in the MAME disk image selection dialogue - I'm still mostly treating disk images like I used to treat lose floppy disks, and I'm only just about warming up to the softlist feature.

I'm still on 10.13 and compile fine.

Although fellow devs are itching to use more advance C++ features which will necessitate upgrading soon.

Outputs don’t work well with multiple instances of the same device, and mouse input makes a lot of assumptions. Both will be addressed eventually, but require substantial effort.