Jump to content
IGNORED

New MAME release


mizapf

Recommended Posts

Just a short explanation what this circuitry is supposed to do:

 

When the DSR writes a byte to 5FF8, it is loaded into the XDR (transfer data register). This causes a 0/1 transition for the signal XDRLD* (middle, left). Now the flipflop switches to 1, the output goes to WBUSY, which indicates that a write process over hexbus is about to happen. This flag is readable from the status register at 5FFA. The flipflop is reset by RESET or when the write process proceeds.

 

The byte is transferred in two phases, since the hexbus is a 4-bit parallel bus. The flag WNP determines which nibble is to be written. The two flipflops at the upper right side have this meaning: WQ1=WQ2=0: passive, WQ1=0, WQ2=1: first nibble (lower), WQ1=1, WQ2=0: second nibble (higher), WQ1=WQ2=1: end of phase.

 

When both WQ1 and WQ2 have the same level, the counting circuitry in the lower half is reset and disabled. When they differ, it counts up to 30. The trigger is Phi3, a clock signal of 372ns period (1 / (10,7386 MHz/4)). When it reaches 30, it triggers some action for the WQ flipflops. In the first case, it counts to 30 and switches the nibble and is reset. When it reaches 30 again, with WQ1=1, another step is done (31), and now the WQ1 and WQ2 are reset, and WBUSY goes to 0, depending on SHSK.

 

During the first phase, for the lower nibble, the HSK line is pulled down. When the counter is reset after reaching 30, HSK is released. If some slave device on the bus needs more time to process that byte, it holds down the HSK line by itself, which (by means of another circuitry) produces SHSK=1. While this is 1, the flipflops do not switch. When the slave/s release/s the HSK line, SHSK goes to 0, and the second phase is entered. During that phase, the HSK is not pulled down again (what I believe to be a glitch; but it is short enough not to cause a timeout), but just when it reaches 30 again. Then it waits for SHSK=0, which clears WBUSY and locks the counter to 0.

 

--

 

It is interesting to see what can be done in hardware, although this would have been perfectly possible to be done in software, as is the case in the HX5102 floppy drive firmware. The TI engineers seemed to have felt like "if we're building custom chips anyway, let's put as much magic into them as possible".

 

If you wonder how many lines this requires in the emulation: about 60 (not counting comments and lines with braces only). It looks much simpler in code. Since I was not fully sure about the effects of the circuits, I tried to emulate the flipflops by bool flags directly. The only high level part is the counter, which is an int variable.

 

 

   bool cnt30 = ((m_clkcount & 0x1e) == 30);
   bool cont = (m_wrst && !m_wq2 && !m_wq1) || (cnt30 && m_wq2 && !m_wq1)
   || (cnt30 && !m_wq2 && m_wq1) || (m_shsk && m_wq2 && m_wq1);
   bool jwq1 = cont && m_wq2;
   bool kwq1 = !((cont && !m_wq2) || (!cont && m_wq2 && m_wnp));
   bool jwq2 = cont;
   bool kwq2 = !(m_wq1 && !cont);
   ...

 

jwq1 means "J input of WQ1 flipflop".

 

This was the hardest part inside OSO; the read circuitry is much simpler, because it fully depends on the slave's timing. When that is done, I can start to implement the HX5102.

  • Like 2
Link to comment
Share on other sites

I guess it cannot be done much shorter without using a special installer program.

 

One thing that came to my mind is an installer that fetches the current version (or an older one if desired) by analyzing the web page of mamedev.org. However, the page just refers to the Releases subdirectory on Github.

 

Does anybody here have some experiences with the Github API? How would one write a client that downloads the list of releases and indicates the current one? I mean, using the API is certainly described somewhere, but this means for me to open a new barrel, as we say.

Link to comment
Share on other sites

That would not help too much, since we have a new release every month, and this would mean to update the installer every time. The installer should not be specific for a release, instead, the goal should be to make it easy to get the latest release. I'm even dreaming of a tool that automatically checks whether there has been a new release and offers to update the installed version automatically (optionally keeping the old one), just the way you typically have it in Windows where many applications bring their own updater.

  • Like 1
Link to comment
Share on other sites

That would not help too much, since we have a new release every month, and this would mean to update the installer every time. The installer should not be specific for a release, instead, the goal should be to make it easy to get the latest release. I'm even dreaming of a tool that automatically checks whether there has been a new release and offers to update the installed version automatically (optionally keeping the old one), just the way you typically have it in Windows where many applications bring their own updater.

 

I could see this beneficial. Of course I also see one issue. I know on many MAME roms they are not compatible with newer versions and they have to be converted. Could the updater be coded to update the rom's within the ROMS folder to be compatible as well for configured systems?

Link to comment
Share on other sites

I imagine to set up subfolders on WHTech for release-specific ROM dumps. For example, we could have /SystemRoms/MAME/current, /SystemRoms/MAME/pre180, and /SystemRoms/MAME/pre0140. The installer should then say something like "You are about to upgrade to release 0.xxx. Your ROMs need to be updated. Download and install now?"

 

It would be much more efficient to replace the ROMs instead of converting them.

 

By the way, ROM formats only changed very rarely, so this is not an everyday problem. These changes seem to be pretty traumatic, though... ;-)

Link to comment
Share on other sites

I just built the TI part of MAME with my new desktop system using

 

 

make -j4 SOURCES=src/mame/drivers/ti99_2.cpp,src/mame/drivers/cortex.cpp,src/mame/drivers/ti99_4x.cpp,src/mame/drivers/ti99_8.cpp,src/mame/drivers/geneve.cpp,src/mame/drivers/ti99_4p.cpp,src/mame/drivers/cc40.cpp REGENIE=1

 

in a mere 184 seconds! Wow.

 

This is a Kaby Lake Core i7-7700K @4.20 GHz, 16 GiB RAM, and a Samsung SSD 850.

 

It's hard to believe, but they are still getting the PC faster and faster, even notably. This is roughly double speed of my second system that I screwed together one year ago. I thought this curve would flatten out by now.

 

As a strong contrast, the Raspi3 that I recently used to try to build and run MAME took several hours for the same job (http://atariage.com/forums/topic/232622-raspberry-pi-and-emulation/?p=3852177). The Raspi1 that I used some more time ago needed 24 hours for building.

  • Like 2
Link to comment
Share on other sites

What is also true, no doubt, is that only few people can make use of such a computing power. You won't notice it with your mail client or browser, your office tool, and not even when editing pictures, unless the operations are really complex. Compiling is one of the jobs where your computer cannot be too fast, also gaming, or video editing. Maybe more people should compile ... could make the world a better place. (If I think long enough I'll surely find a good reason for that claim. :-) )

  • Like 2
Link to comment
Share on other sites

I just built the TI part of MAME with my new desktop system using

 

make -j4 SOURCES=src/mame/drivers/ti99_2.cpp,src/mame/drivers/cortex.cpp,src/mame/drivers/ti99_4x.cpp,src/mame/drivers/ti99_8.cpp,src/mame/drivers/geneve.cpp,src/mame/drivers/ti99_4p.cpp,src/mame/drivers/cc40.cpp REGENIE=1

in a mere 184 seconds! Wow.

 

This is a Kaby Lake Core i7-7700K @4.20 GHz, 16 GiB RAM, and a Samsung SSD 850.

 

It's hard to believe, but they are still getting the PC faster and faster, even notably. This is roughly double speed of my second system that I screwed together one year ago. I thought this curve would flatten out by now.

 

As a strong contrast, the Raspi3 that I recently used to try to build and run MAME took several hours for the same job (http://atariage.com/forums/topic/232622-raspberry-pi-and-emulation/?p=3852177). The Raspi1 that I used some more time ago needed 24 hours for building.

I haven’t really investigated upgrading my I5-3470 and 3570 desktops since those systems pretty much still fly after five years. They benchmark around 7000 on the CPUBenchmark site. I wonder how long they’d take to compile.

Link to comment
Share on other sites

It's hard to believe, but they are still getting the PC faster and faster, even notably. This is roughly double speed of my second system that I screwed together one year ago. I thought this curve would flatten out by now.

 

There's nothing surprising about the continued increases in speed. If we don't get it through raw GHz we'll get it through architectural advances like instruction set evolution, parallelism, new bus technologies for better inter-core communication, aux fgpa.. and more!

 

We're not all that far away from real-time compiling on the desktop. Edit your code, and type "RUN", and there it is. Instant. It'll feel like an interpreted language.

  • Like 1
Link to comment
Share on other sites

That would not help too much, since we have a new release every month, and this would mean to update the installer every time. The installer should not be specific for a release, instead, the goal should be to make it easy to get the latest release. I'm even dreaming of a tool that automatically checks whether there has been a new release and offers to update the installed version automatically (optionally keeping the old one), just the way you typically have it in Windows where many applications bring their own updater.

Dependence on loading a Compiler fetching a list of files you have to find and download is exactly the reason that Unix and Linux are so small world wide.

 

No own wants to have to do that much work and research just to use or get a product.

 

It is like having to totally assemble you car from parts and shipping containers, it is only done by mechanics and everyone else will take a pass.

 

So yea you are right the only way to put out a package is to make it self sustained.

Edited by RXB
  • Like 1
Link to comment
Share on other sites

I'm far from critizing people using outdated versions, but nevertheless, maybe for a second...

 

... one should imagine that this feels like you just don't care about the work of the last 10 years that I invested in MAME, to fix its flaws, to improve its precision, to add new features.

 

Sometimes it seems to me as if people believe to be forced to decide for one version. This is not true, though. You can always use several versions along with each other, since MAME does not apply any persistent changes outside of its folder.

  • Like 2
Link to comment
Share on other sites

I'm far from critizing people using outdated versions, but nevertheless, maybe for a second...

 

... one should imagine that this feels like you just don't care about the work of the last 10 years that I invested in MAME, to fix its flaws, to improve its precision, to add new features.

 

Sometimes it seems to me as if people believe to be forced to decide for one version. This is not true, though. You can always use several versions along with each other, since MAME does not apply any persistent changes outside of its folder.

I can only imagine the pain you feel on this.

 

I know I include with RXB a Classic99 BIN folder, GRAM KRACKER version Folder, Source Text DOS folder, TI Source Text DV80 Folder, GPL OBJECT COMPRESSED folder and the list goes on...,

Link to comment
Share on other sites

This is not really a pain, at least I try not to let it become one. MAME's mission is still there even when no one would be actively using it. There is an abundance of systems inside MAME which are just there, for the sake of being emulated, and I'd say the TI part of MAME is one of the most frequently used ones. I dare to say it is the most stable one, in fact.

 

Still, I'm not immune to the sensation of appreciation when people are actually using it. I mean, who is? :-)

  • Like 6
Link to comment
Share on other sites

This is not really a pain, at least I try not to let it become one. MAME's mission is still there even when no one would be actively using it. There is an abundance of systems inside MAME which are just there, for the sake of being emulated, and I'd say the TI part of MAME is one of the most frequently used ones. I dare to say it is the most stable one, in fact.

 

Still, I'm not immune to the sensation of appreciation when people are actually using it. I mean, who is? :-)

 

So I'm setting up mame 0.189 on my ubuntu box..

 

i created a mame dir under my home dir and in that dir put roms in the roms dir, software dir has a subdir for ti99_4a and then i put cartridges in the carts folder, doesnt see them in the mame ui for loading, looked at your wiki, says cartridges instead of carts.. renamed carts to cartridges.. nope still doesn't work.. where do I put the cart rpks? and where is this documented?

 

also getting REAL tired of resetting up my hardware every time i load mame and I know i can make a batch file or use a front end..but really how hard is it to remember the last state or make it loadable?

 

Greg

Link to comment
Share on other sites

I suggest you set up the following structure:

~/mame
~/mame/roms
~/mame/carts

Put the executable file in ~/mame, the system ROMs in ~/mame/roms, and the cartridge zips in ~/mame/carts. In the ~/mame directory, you should also have the hash, cfg, ini, and snap subdirectories. I don't know how you got the package; typically, by unzipping, the subdirectories are automatically created.

 

Run

$ ./mame64 -createconfig

Open the mame.ini file, edit rompath as "roms;carts".

 

The RPKs are outdated and will not be seen in the software list, only the zips. You can, however, load the RPKs from any location on the file system, but you must provide the path name.

 

The first example is the Extended Basic zip cartridge, the second one is for the Extended Basic RPK.

./mame64 -cart exbasic
./mame64 -cart /home/userdir/mame/mycarts/whatever/extended_basic.rpk

If you run Ubuntu, what could be easier than to write a bash script that mounts the hardware that you want to use? You can save the current state (please search this forum; I posted it at some time), but I highly recommend to use scripts. This is much safer than anything else.

Edited by mizapf
Link to comment
Share on other sites

I suggest you set up the following structure:

~/mame
~/mame/roms
~/mame/carts

Put the executable file in ~/mame, the system ROMs in ~/mame/roms, and the cartridge zips in ~/mame/carts. In the ~/mame directory, you should also have the hash, cfg, ini, and snap subdirectories. I don't know how you got the package; typically, by unzipping, the subdirectories are automatically created.

 

Run

$ ./mame64 -createconfig

Open the mame.ini file, edit rompath as "roms;carts".

 

The RPKs are outdated and will not be seen in the software list, only the zips. You can, however, load the RPKs from any location on the file system, but you must provide the path name.

 

The first example is the Extended Basic zip cartridge, the second one is for the Extended Basic RPK.

./mame64 -cart exbasic
./mame64 -cart /home/userdir/mame/mycarts/whatever/extended_basic.rpk

If you run Ubuntu, what could be easier than to write a bash script that mounts the hardware that you want to use? You can save the current state (please search this forum; I posted it at some time), but I highly recommend to use scripts. This is much safer than anything else.

 

Thanks, this just illustrates how the notsavvy can't easily get set up with available information though.. I'll create a config and the other dirs, when you install from the ppa in ubuntu the latest you get is 189 and i think it creates .mame not mame :D

 

Greg

Link to comment
Share on other sites

OK, I found the repository where the 0.189 release is available and installed the package on my Ubuntu 16.04 release (running in a VM).

 

You should create ~/mame and ~/mame/roms, and put the system zips and the cartridge zips in the latter one. Then you can run "mame ti99_4a". As said above, you can use RPKs as well, but they do not show up in the software list. Rather, you'd have to mount them in the file manager.

 

To avoid the not-so-comfortable OSD menu, you should make use of script files. Note that the menu key is INS here, not ScrlLock.

Link to comment
Share on other sites

OK, I found the repository where the 0.189 release is available and installed the package on my Ubuntu 16.04 release (running in a VM).

 

You should create ~/mame and ~/mame/roms, and put the system zips and the cartridge zips in the latter one. Then you can run "mame ti99_4a". As said above, you can use RPKs as well, but they do not show up in the software list. Rather, you'd have to mount them in the file manager.

 

To avoid the not-so-comfortable OSD menu, you should make use of script files. Note that the menu key is INS here, not ScrlLock.

 

that's what I found .. ok thanks! I hate mingling roms there's already 5000 arcade roms in that dir :D

Link to comment
Share on other sites

You can still create an ini file using "-createconfig". You can start mame with that ini file in a specific folder. Suppose you have a folder ~/mameti99, then you can run "mame64 -createconfig in that folder and create a separate environment. Usually, one can run MAME in that folder, and it takes that mame.ini file. If not, you can explicitly specify the inipath with "mame64 -inipath /home/user/mameti99 ...".

 

(I noticed that it suffices for me to set up that second folder and run MAME from there in my normal environment, but in Ubuntu (where we use a PPA) I had to explicitly set the new inipath)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...