New MAME release

[+OLD CS1]

 

It's totally true. I got back into the Amiga 2000 after nearly 20 years away, and not just the performance, but how primitive the UI felt really struck me. We're very spoiled.

 

I... um, no sir!

[Tursi]

 

I... um, no sir!

 

Sorry, but I want my right-click context-sensitive pop up menus. Moving the mouse in Directory Opus felt so old fashioned.

 

Still remembering the tricks though... going to take time for it all to come back.

[Casey]

Just more of a curiosity question than anything else - but what's left in the TI-99 family to emulate that hasn't been? 99/4B and 99/5 ? Or is the 99/4B = 99/5 ? I had a look over at Fabrice's site and it looks like the OS in the 99/4B (or 99/5) is a bit unique as well. What about the 99/7 - did that even make it far enough that one exists that could be emulated?

[+mizapf]

99/4B and 99/5 are on my list, now that the Hexbus is working. The only challenge is that TI packed a lot into custom chips so that I will have to analyse the ROMs to find out the relevant CRU ports and mapped addresses, i.e. it will become a behavioral-based emulation rather than a circuit-based emulation. I don't want to give a date when this will be done, though.

[+9640News]

OK,

 

Some people have seen the TIPI in action using a card to communicate with a Raspberry PI.

 

Is there some way the TIPI can be emulated in MAME and then use TIIMAGETOOL to interface the TIPI to a socket specifically for TCP access? Obviously, it does not make sense and is highly unlikely an emulated system could be used to talk to a secondary (RPI) system, so what I am wondering is if there some other application the TIPI interface can communicate to accomplish the TCP access?

 

If there is no tool for the final communication piece from TIIMAGETOOL to some other tool say under a Windows system, then it all meaningless anyway.

 

This assumes we have Matt's blessing for TIPI emulation, etc. Just trying to think how we can expedite application development.

 

Beery

[+arcadeshopper]

OK,

 

Some people have seen the TIPI in action using a card to communicate with a Raspberry PI.

 

Is there some way the TIPI can be emulated in MAME and then use TIIMAGETOOL to interface the TIPI to a socket specifically for TCP access? Obviously, it does not make sense and is highly unlikely an emulated system could be used to talk to a secondary (RPI) system, so what I am wondering is if there some other application the TIPI interface can communicate to accomplish the TCP access?

 

If there is no tool for the final communication piece from TIIMAGETOOL to some other tool say under a Windows system, then it all meaningless anyway.

 

This assumes we have Matt's blessing for TIPI emulation, etc. Just trying to think how we can expedite application development.

 

Beery

 

Basically.. you don't need the pi at all.. everything on the pi side is python which can run on the PEECEE running mame.. we just need the socket emulation and dsr to pipe to a python engine

 

Greg

[Asmusr]

 

Basically.. you don't need the pi at all.. everything on the pi side is python which can run on the PEECEE running mame.. we just need the socket emulation and dsr to pipe to a python engine

 

Greg

 

Sorry for hijacking this thread, but I have been pondering how to do this in JS99'er. I don't think running the python code within the browser is going to work without major changes, even though implementations of python exist, e.g. http://www.skulpt.org/. So the python code would have to run separately, either on the user's local machine, which would permit it to access the file system, or on the server with some kind of cloud storage, which again would require changes.

 

The main problem is that exposing the raw socket interface over HTTP is probably going to be way too slow since it had to be coded in c on the PPi to keep up with the TI. So instead of sending individual bytes JS99'er would probably need to send full messages over the wire, but that might not even be fast enough and I'm not sure if that would work for all purposes.

 

I imagine it would also be difficult to fit something very bespoke like this into the MAME code. Tursi would probably have the best chance of emulating the TIPI since he could use a native interface between Classic99's c code and the python code.

[ralphb]

How on earth do I set the window size on the command line in version 204? There are options for fullscreen (laaarge) and -no-max (the size of a stamp). The -prescale option has no effect at all, and -window-resolution seems to be retired. The venerable -display option is also not known.

 

It seems that the internet also doesn't know how to get decently sized windows.

[+mizapf]

I'm using the resolution switch in mame.ini, setting it to e.g. 960x720. It is located in the section "OSD PER-WINDOW VIDEO OPTIONS".

 

If you want to set in on the command line:

 

 

./mame64 ti99_4ae -window -resolution 960x720

 

I don't know the switches -no-max and -window-resolution you mentioned, though. Mind that there is a blank between -window and -resolution.

[ralphb]

I have a new feature request.

 

It's not TI 99-specific, but is there a way to enable the memory window (and possible others) to allow copying? It's no fun typing >80 bytes into my editor.

 

You could also have an option to save the displayed data, but this is less versatile, and probably more work.

[ralphb]

And what happens if I modify one of the system ROMs? MAME says "WRONG CHECKSUMS. The machine might not run correctly." But is this ROM still used, or ignored entirely?

 

If it's ignored, how can I convince MAME to still use it (i.e., which file do I have to edit )?

[+mizapf]

This is just a warning (it says it "might not run correctly"). The checksums are contained in the respective components - drivers/ti99_4x.cpp contains the checksums of its ROMs and GROMs, the checksums of cartridges are contained in hash/ti99_cart.xml, and each PEB card has its own checksums.

[+mizapf]

Something you don't find too often: I just discovered a bug in the tms9900 emulation in MAME that is there since at least 4 years (as I found by checking out an old MAME version).

 

 

m_byteop = ((decoded.format==1 && ((IR & 0x1000)!=0))
    || (decoded.format==4 && (((IR >> 6)&0x000f) > 0) && (((IR >> 6)&0x000f) > 9)));

 

The ">9" is of course wrong, it must be "<9". I wondered why it had no obvious effects. Indeed, it only affects LDCR and STCR when used with register indirect auto-increment mode (since the m_byteop is used there). I could verify it with a short assembly language program.

 

 

       DEF  RUN

RUN     LWPI >C000
        LI   R12,>1E00
        LI   R1,>B000
        LDCR *R1+,10
        JMP  $

        END

 

The debugger reveals that address C002 (R1) contains B001 at the end. This is wrong, it must be B002 when more than 8 bits are used, a consequence of the wrong comparison.

 

I'm really curious whether this had an effect after all, and we never found the reason why that went wrong. This is just another example that errors may go unnoticed for years, until something really dramatic happens.

[Tursi]

Classic99 had a similar bug a few years back... it's just not a very commonly used sequence! (Unfortunately too far back for me to find it in Github). IIRC it came up when I was testing the F18A upgrader, since that uses LDCR to access the flash EEPROM.

 

(Ah, found it:

http://atariage.com/forums/topic/165901-classic99-updates/?p=3705635

 

Unfortunately that was the day of first commit to github, so no easy history. But I find it interesting how we all tend to hit very similar bugs in our CPU cores... keeps sharing of data important. )

Edited April 4, 2019 by Tursi

[+9640News]

Need some information on the MAME hard disk structure we use for the TI-99/4A and Geneve 9640 images. Can someone point me towards what the structure is?

 

I have a DREM hard disk image I just created at 128 MB. The plan is to copy a large volume of source files from the Geneve and TI's history to the latest MAME image format. More Geneve than TI, but at least it will be a common repository.

The DREM image is a straight sector by sector format file with no header, etc. The image is "formatted" at 8 heads, 32 sectors/track, 2048 cylinders, for a total size of 128 MB. Bytewise count, it is hex >800,000 in length. When I was looking at the MAME 128 MB image I had, it was actually smaller. I'm not sure why.

 

I know back somewhere around V2 of the structure, there was something like a 128 to 512 byte header with a structure, and then the rest of the image laid out. This newer format I am not so sure.

 

What I want to do is copy the DREM image to whatever offset was necessary for a MAME image if it was still following the same format, but things did not appear as I would have expected.

 

Any feedback is appreciated.

Beery

[+mizapf]

Hello Beery,

 

is this helpful for you: https://github.com/mizapf/tiimagetool/blob/master/src/de/mizapf/timt/files/MameCHDFormat.java

 

Also note that the CHD format does not store tracks that are empty. Accordingly, the CHD file starts small and grows over time.

 

Michael

Edited May 21, 2019 by mizapf

[+jedimatt42]

Super basic mame question, that I can't find the answer too on the internet...

 

I don't have a scrolllock key... so what do I do to get the ui mode? I tried:

 

-uimodekey KEYCODE_ESC

 

I'm on a laptop running linux. 

 

Mame docs say:

 

-uimodekey [keystring]

Key used to enable/disable MAME keyboard controls when the emulated system has keyboard inputs. The default setting is Forward Delete on macOS or SCRLOCK on other operating systems (including Windows and Linux). Use FN-Delete on Macintosh computers with notebook/compact keyboards.

[+mizapf]

Yes, we also have that on Ninerpedia: https://www.ninerpedia.org/wiki/Change_MESS_menu_mode_key

?

 

Actually, were you successful with the command line option? Was this your actual question?

 

(You can put many settings of the command line into the mame.ini file. Call mame64 -createconfig before.)

[+jedimatt42]

No, that command line option -uimodekey did not work for me at all... 

 

I found that if I use the -ui_active  option, then I don't need a uimodekey, and the UI keys like TAB can just be used... but that circumvent the value of the ui mode key.

 

I haven't been using a mess.ini ( mame.ini now, I suppose ) just trying to pass command line arguments to mame from a bash script.  I guess per ninerpedia, I will try to force the creation of an ini, and see if modifying that works.

 

What I'm trying to do is test Force Command with hardware I don't own, such as the mame supported HFDC, SCSI, and IDE.  Mame should be the perfect tool for that. 

 

-M@

[+mizapf]

Just tried it ... seems to work quite well with -uimodekey. You have to use a string from the list on Ninerpedia as argument -  and the MAME release that matches this description. I don't know since when this command line argument is available.

[+jedimatt42]

The secret is understanding what set of key strings matter. The generic mame documentation said something about using codes in the controller.ini... some google searching led me to stupid words like KEYCODE_F1 or KEYCODE_ESC... So, it seems these are dependent on the controller for the system being emulated? 

 

Simply 'F1' works well...  'ESC'  not so much... it quits mame. 

 

Working option:

 

-uimodekey F1

 

THANKS!

[+mizapf]

I seem to remember that KEYCODE_xx is outdated. ESC is not a good choice because there should be one key that allows MAME to exit.

 

I think a good choice could be CapsLock: I don't use it for AlphaLock because I sometimes find it getting out of sync with the PC key; I'm using another key for Alpha Lock instead.

[+9640News]

On 5/21/2019 at 2:36 PM, mizapf said:

Hello Beery,

 

is this helpful for you: https://github.com/mizapf/tiimagetool/blob/master/src/de/mizapf/timt/files/MameCHDFormat.java

 

Also note that the CHD format does not store tracks that are empty. Accordingly, the CHD file starts small and grows over time.

 

Michael

Michael,

I previously created a 128 MB image back over 15 years ago that has been upgraded to the later CHD formats.  As such, the image is 128 MB's in size.  So, I would presume the file does not grow over time.  Besides, wouldn't the image during a format/verify fill in blank sector information?

 

Beery

 

[+mizapf]

Yes, when the image has reached the actual capacity, it will not grow further. The CHD file for our hard disks is not compressed, despite its name ("Compressed hunks of data").

 

In TIImageTool I offer the option (by default) to fill vacant space with 0. This has the effect that those hunks are not stored in the CHD file but will be delivered as 0-filled when being read. The CHD file will be really small (much smaller than a DSK image).

 

When you use MDM to format the hard disk, it will fill the sectors with E5 (I think), which means those hunks will be created, and the CHD expands to the fill size.

 

The CHD file is quite similar to DSK in the sense that only sector contents are stored. There are no headers, gaps, ID marks, CRC (ECC), or interleave. However, I store this information as meta-information in the header of the CHD file. When the CHD is mounted in MAME, and a cylinder is accessed, an MFM image with all gaps and ID marks and so on will be created on the fly. To make this more efficient, 10 cylinders are cached in the emulation by a LRU strategy.

 

[+9640News]

OK, so I have a question.

 

With the DREM, it has a CFG file that specifies the number of cylinders, sector size, sectors/cylinder, and a few other pieces of configuration information.  The actual hard drive image, to my knowledge, is a sector by sector layout.

 

Does the meta-information stored in the header of the CHD file for the gaps, ID marks, CRC, etc. change when sectors are rewritten?  I've never fully grasped that level of hardware detail to know for sure, and even more unsure with MAME.

 

If they don't, what would be the easiest process to do a copy of the DREM hard drive image onto a similar (say 40 MB) MAME CHD image?  I've got the utilities to copy "bytes" from one image to any location of another image.

 

Where I am going with this is that I have created a DREM image I am building source code files to make sure we always have them.  Few people will have a DREM, but many more people would have access to MAME.  Just wanting to make sure history is preserved, etc.

 

Worse case, I suppose I could write a transfer program linking a Geneve to a Geneve/MAME emulation and read sector by sector from one image and write to the other with emulated hard drives configured the same.

 

Beery