New MAME release

[+hloberg]

34 minutes ago, mizapf said:

Nope, I did not touch anything. I sometimes had an effect that MAME performed differently between builds (of the same source code); maybe the compiler creates better code from time to time. (This is not as unlikely as it sounds, since the compilers do heavy optimization, and sometimes building from clean yields better results.)

 

Maybe you had a CPU hog among your processes.

nope no change on the i3 that I'm aware of.  could be the build. I've seen that too with different performance from build to build. Well, whatever you did, keep doing it and good job. ??? 

[+mizapf]

I generally have differences between gcc and clang builds. And even though I know there are many dedicated clang fans out there, I have to say that the clang build consistently delivers less percent in benchmarks for MAME.

[+mizapf]

Somewhat unnoticed, release 0.223 of MAME was issued on August 06, 2020. (Usually, there is a message on the MAME forum, but not this time.)

 

You can download pre-built binaries from our WHTech server:

 

https://ftp.whtech.com/emulators/MAME/full/windows/

https://ftp.whtech.com/emulators/MAME/ti99/linux/

https://ftp.whtech.com/emulators/MAME/ti99/raspbian/

 

Interesting changes:

• In the debugger, writing to addresses in the Peripheral box works again. This was broken since release 0.173 (more than 4 years ago).
• The TI-99/2 now has an Expansion Port (-expport), and currently the only choice is "ram32k".

[+mizapf]

Added for the next release (End of September).

Cool? (Just started with it this afternoon, seems to work so far.)

 

[+arcadeshopper]

cool thanks for adding that!  when do you plan on adding tipi?    

[+mizapf]

In fact, I had to do a small change in the TI emulation for the unconventional CRU selection of the SID Master: It gets active whenever there is a CRU access below 0x1000. In the TI console this is the case for the 9901 accesses; as it was done until now, the 9901 consumed the access, and the PEB was not involved (which meant that the SID Master never got selected).

 

Actually, I am not sure whether the SGCPU propagates the CRU address every time to the external bus, neither am I sure for the Geneve with its Gate Array. As it was quite easy to do, I added the SID Master to the SGCPU; I'd have to do some more changes for the Geneve, and before I try it, maybe a Geneve user with a SID Master can tell me whether it works.

 

I noted Marc Hull and Jim Fetzner as creators of the card in 2010, is that correct?

[+OLD CS1]

47 minutes ago, mizapf said:

It gets active whenever there is a CRU access below 0x1000. In the TI console this is the case for the 9901 accesses; as it was done until now, the 9901 consumed the access, and the PEB was not involved (which meant that the SID Master never got selected).

Wonder if that is why the LED on the card stays on all the time.  I have been wanting to find a way to fix that.

[+InsaneMultitasker]

1 hour ago, mizapf said:

IAs it was quite easy to do, I added the SID Master to the SGCPU; I'd have to do some more changes for the Geneve, and before I try it, maybe a Geneve user with a SID Master can tell me whether it works.

 

Yes, SID master works with a Geneve.  IIRC, the player also maps in one of the peripheral bus pages - probably BA - but it's been a long time since I looked at the code.

 

Edit: My copy of the source has page 0xBA mapped into >8002 (the DSR space) but no apparent code to restore the mapper prior to calling DSRLNK / exiting the program. If the final release was set up this way, file IO will respond as if you used the ROMPAGE option.  Not ideal nor intended.

[+arcadeshopper]

1 hour ago, mizapf said:

In fact, I had to do a small change in the TI emulation for the unconventional CRU selection of the SID Master: It gets active whenever there is a CRU access below 0x1000. In the TI console this is the case for the 9901 accesses; as it was done until now, the 9901 consumed the access, and the PEB was not involved (which meant that the SID Master never got selected).

 

Actually, I am not sure whether the SGCPU propagates the CRU address every time to the external bus, neither am I sure for the Geneve with its Gate Array. As it was quite easy to do, I added the SID Master to the SGCPU; I'd have to do some more changes for the Geneve, and before I try it, maybe a Geneve user with a SID Master can tell me whether it works.

 

I noted Marc Hull and Jim Fetzner as creators of the card in 2010, is that correct?

 

yeah on real hw the light sits on unless you are accessing another cru>1000 then it turns off while the other is on, back on again when done

 

Yes Marc and Jim.. Jim did the layout and pcboards for Marc

[+Ksarul]

56 minutes ago, arcadeshopper said:

 

yeah on real hw the light sits on unless you are accessing another cru>1000 then it turns off while the other is on, back on again when done

 

Yes Marc and Jim.. Jim did the layout and pcboards for Marc

Yes, and then I obtained the complete rights to the board when Marc sold off his TI stuff last year. I plan on a new run of boards soon.

[+mizapf]

14 hours ago, arcadeshopper said:

When do you plan on adding tipi?    

Not in short term. As with all modern controller-based devices, I first have to set up a concept to treat this device as immutable, since I cannot emulate a complete Pi.

[+arcadeshopper]

You don't have to. That part is handled by qemu you can just do the communications and DSR part same as js99er is

Sent from my LM-V600 using Tapatalk

[+mizapf]

17 hours ago, InsaneMultitasker said:

Yes, SID master works with a Geneve.  IIRC, the player also maps in one of the peripheral bus pages - probably BA - but it's been a long time since I looked at the code.

 

Edit: My copy of the source has page 0xBA mapped into >8002 (the DSR space) but no apparent code to restore the mapper prior to calling DSRLNK / exiting the program. If the final release was set up this way, file IO will respond as if you used the ROMPAGE option.  Not ideal nor intended.

 

OK, I got it running with the Geneve, but I have to use ROMPAGE to get a directory listing of the floppy. Otherwise, the floppy starts, no output, stops, and the program hangs.

[+arcadeshopper]

@mizapf on the latest version I had a hair pulling time figuring out how to load a cart. In the past I could just arrow down to a cart zip or a cart file and it worked to load a zip or rpk or even a fileg.bin and none of that works now..

 

I ended up downloading your all_carts file and putting that in a folder then HAD to put that folder in the roms= path for mame to get it to even load extended basic.. 

 

frustrating

 

anyway also I want to use 3 disks on CCFDC how in the heck do i configure the third drive with command line? I can do it in the gui.. by adding the 3rd drive in ioslot:x:2  but that syntax doesnt work for commandline at all..

 

Greg 

[+mizapf]

Hi Greg,

 

the direct cartridge loading as "fileg.bin" should not work for 10 years by now, or you had a very old MESS version. You should be able to load a cartridge zip via the OSD menu: File Manager -> cartridge (cart) -> [software list] -> TI-99/4A cartridges -> there is the list (just checked).

 

To load a RPK you go this way: File manager -> cartridge (cart) -> follow the path to the desired cartridge

 

To do this from the command line:

 

zip file: mame64 ti99_4a -cart exbasic

rpk file: mame64 ti99_4a -cart somefolder/mycartridges/extended_basic.rpk  (\ for Windows)

 

The allcarts.zip file must be unpacked into the rompath. This is correct. You can extend the rompath by more path elements if desired.

 

But - to be honest - this has NOT changed for quite a long time by now. I don't know what your last MAME/MESS version was, but the usage should be stable since at least 0.174 (four years ago) or even 0.149 (seven years old).

 

In order to connect a third drive to the ccfdc, you just do this on the command line:

 

mame64 ti99_4a -ioport peb -ioport:peb:slot8 ccfdc -ioport:peb:slot8:ccfdc:2 525dd

 

(the drive connectors are numbered 0, 1, 2, 3 for DSK1,...DSK4)

[+arcadeshopper]

Thanks it may very well have been 10 yr old mess I last tried to load a cart directly from the file with but I don't think so

It says invalid image when I point to a zip etc

Thanks for the command line

We were testing Adams beta of his crpg today and it fails to work in mame he'll be reaching out I'm sure

Is Sams 1024?

Sent from my LM-V600 using Tapatalk

[+mizapf]

Always remember: The ZIP cartridges are not specified by path, but only by name. The name is the cartridge zip file name minus ".zip".

 

This is wrong:

mame64 ti99_4a -cart exbasic.zip

 

This is correct:

mame64 ti99_4a -cart exbasic

 

You cannot specify a path for the zip cartridges; they must be found in the rompath.

[+arcadeshopper]

Always remember: The ZIP cartridges are not specified by path, but only by name. The name is the cartridge zip file name minus ".zip".
 
This is wrong:

mame64 ti99_4a -cart exbasic.zip

 
This is correct:

mame64 ti99_4a -cart exbasic

 
You cannot specify a path for the zip cartridges; they must be found in the rompath.

K

Is Sams 1024k?

Sent from my LM-V600 using Tapatalk

[+mizapf]

Yes.

[+mizapf]

Concerning the changes over longer periods of time, I added another table to my MAME pages that informs you about significant changes by new MAME releases. These changes typically require you to update your configuration (change scripts, launchers, get new ROMs etc.) because the former usage has changed. I guess this is easier than browsing through the long table of changes over the last 13 years of work that I invested in MESS/MAME.

 

So if someone of you with an older MAME or MESS release decides to catch up, this table will tell you what you need to do to get things going again.

 

https://www.mizapf.de/en/ti99/mame/changes

("Important changes")

[+hloberg]

There something annoying in MAME/MESS that, maybe I just don't get and may have a reason for. When you remove a .DSK file after you closed MAME/MESS which MAME/MESS was attached to, (say you just want to put the file in another dir) when you restart MAME it creates a blank file .DSK where the file previously was with the previous name.

 

[+mizapf]

I never had this behavior. Do you have a mame.ini file, and do you have both readconfig and writeconfig set to 0 (right at the top)? If not, try that. My guess is that disks belong to a "configuration" in the view of the MAME kernel, and when it does not find the image, it creates a new one.

[+adamantyr]

Hi Michael,

 

Good news, I've gotten my CRPG to work on MAME. I am not certain that the Corcomp controller works though, I ended up having to use BWG.

 

One question, I have a custom 256k cartridge that I'm using for easier load times. How do I set up a custom cartridge in MAME?

[+mizapf]

Can you give me some details about your issues with the Corcomp FDC? 

 

About the cartridge, is it similar to other well-known cartridges? The point is that I have to know the type of it to make it run.

[+adamantyr]

5 hours ago, mizapf said:

Can you give me some details about your issues with the Corcomp FDC? 

 

About the cartridge, is it similar to other well-known cartridges? The point is that I have to know the type of it to make it run.

The cartridge is a finalgrom compatible. I see that the likely issue is I don't have it in an RPK format. If you can point me to instructions to converting a cartridge binary to that I should be good.

 

The Corcomp controller loads the game all right, but fails to load the SAV file, which is a 768 byte raw image file on the disk. This subsequently makes it impossible to start the game. I actually own a Corcomp FDC myself with the Miller Graphics upgrade so I know it works in hardware without issue.

 

Disk images attached, just put the GAME disk in 1, and WORLD1 and WORLD 2 in disks 2 and 3 respectively.

ROA.zip