New MAME release

[HackMac]

For quite some time I've been thinking about writing a tool that allows you to install and update MAME and all necessary files by a single click (where 0 < single < 10). The tool should offer a graphical user interface, and it should be platform-independent (i.e. running in Windows, MacOS, Linux). Maybe we could even do that together, that is, if some of you are interested.

"Single Click Install and Update Procedure" sound like it gets to an Apple Macintosh application...

(By the way: "SCIUP" could be the name for that tool!?)

 

I like to contribute to your idea, but sadly I don't use any TI-99 emulators / simulators. But when, I tried out MAME. What I'm trying to say, I don't think I have any ideas I can contribute to such a project right now because of the rare use of MAME.

But we both already have some experience in working together on some lines of code. I've always enjoyed it.

 

What would be the preferred language for this?

My preferred language is definitely German! But I also speak Java very well and also C/Objective-C (and even C++ is not very far away). So I can bring in my special knowledge of macOS.

Phyton will work seamless on macOS. But this programming language is a mess! Every time I try to get a closer look at the code of XDT99 (for the Objective-C wrapper classes I write) I'll get eye cancer. (And if I can't get my eyes off the code, I will get brain cancer.)

Sorry Ralph, I don't mean to offend you, it is definitivly not your fault! The fault is mine, because I can't read that kind of coding style.

 

Meine eMail hast Du ja, Michael. Wir bleiben in Kontakt!

 

P.S.

This text was written with the kind support of https://www.deepl.com

Edited August 31, 2018 by HackMac

[Casey]

I did run into an issue just now with the newest MAME release.

 

In the 99/2 32K emulation, I created a new tape image (I named it ti992.tap) and I saved, then did a new, then did loaded a small program back in successfully. I then went over to the 99/4A 2.2 emulation to see if I could load the tape in and got an "Internal error" when I tried to mount the tape file. I went back to the 99/2 32K emulation and tried to mount the same tape file again and also got an "Internal error" - so it appears I've somehow corrupted my tape image file. I didn't have any problem though using the Hex-Bus device to save a 99/2 program on an existing disk image and load it back into the 99/8.

 

Did I perhaps do something wrong with the tape?

[+mizapf]

"Internal error" means the OSD message, right? There is an INTERNAL ERROR message in the 99/2 as well.

 

Try to save a program on the 99/2, then exit the emulation completely, then start again the 99/2 and load. I was successful with the attached file. Then try on your 99/4A.

 

(Just a wild guess, name your files *.wav)

new992.wav

[+9640News]

Matt,

 

I thought I read somewhere you had MAME with the TI or Geneve emulation working with the HFDC and using MDM5 for formatting.

 

Does that create a full image with all in-between sector information?

 

If it doesn't, is there any way to write out a file that would capture all that information for the DREM emulator device? I believe, not 100% sure, I need a formatted image to work from and the examples DREM provides just doesn't match up with our HFDC formats.

 

Right now, just wondering what our potential is for capturing a raw formatted image file without headers, etc. It is not obvious to me the capabilities are there, but if they are buried somewhere, it would be nice to know.

Thanks.

 

Beery

[+mizapf]

Hello Berry,

 

I think I'll be better able to give you the details, since I implemented that part.

 

a) MAME uses sector dumps for hard disk images. That means that only the sector contents are preserved, no inter-sector data. That means there is no "pc99" format for the hard disk.

b) There is some meta data that is stored in the CHD container besides the sector contents. This is the sector interleave and skew, the data for write precompensation and reduced write current, and gap sizes.

c) Internally, MAME rebuilds the whole track according to these data, so the HFDC chip will see the track with all inter-sector data. Also, when you stop the emulation, the hard disk is rewritten by extracting the sector contents, detecting the sequence, and the CHD is rewritten by saving the sector data and writing the CHD header with these meta data.

[+9640News]

I want to confirm a few things to make sure I am not mistaken about anything. With a MFM hard drive, the hard drive is formatted as 256 byte sectors? I recall the SCSI may have had the ability to go to 512 bytes. Just want to make sure I am not thinking of something different.

 

I have Gap 0 as >F0, Gap 1 as >F0, Gap 2 as >F0, Gap 3 as >EA, and the Gap Byte as >F2.

 

Thanks.

Beery

[+mizapf]

The gaps are too long. Where do you have those data from?

 

The MFM drives are soft-sectored (like floppy disks), so you can use any format. Yes, 256 bytes is the sector length that is used by the HFDC. I don't know details about SCSI drives. It is not unlikely that sectors are 512 bytes, and TI file system sectors are mapped to them (like sectors n and n+1 mapped to drive sector n/2).

 

This is the log output of the Geneve emulation in MAME regarding the MFM drive:

 

 

[:peb:slot8:hfdc:h1:generic] CHD metadata: CYLS:1984,HEADS:16,SECS:32,BPS:256
[:peb:slot8:hfdc:h1:generic] Set encoding to 1
[:peb:slot8:hfdc:h1:generic] CHD image has geometry cyl=1984, head=16, sect=32, size=256
[:peb:slot8:hfdc:h1:generic] MFM HD rec specs: interleave=4, cylskew=0, headskew=0, wpcom=-1, rwc=-1
[:peb:slot8:hfdc:h1:generic] MFM HD gap specs: gap1=16, gap2=3, gap3=18, sync=13, headerlen=5, ecctype=-1
[:peb:slot8:hfdc:h1:generic] Calculated settle time: 9.80 ms, step: 195 us

[+9640News]

I got those gaps from the MDM5 formatting code.

 

Beery

[+mizapf]

Are you aware of the two's complement that is used here? Have a look at the HDC9234 spec, page 14, right column at the top.

Edited September 3, 2018 by mizapf

[+InsaneMultitasker]

 

I don't know details about SCSI drives. It is not unlikely that sectors are 512 bytes, and TI file system sectors are mapped to them (like sectors n and n+1 mapped to drive sector n/2).

This is correct. The TI and Geneve SCSI DSR expects the drive is formatted as 512 byte sectors. The DSR handles the necessary read before write to map the sectors. (MDOS 7.00 had an early option to only use the first 256 bytes of each sector, to improve disk write speeds however, there was read performance hit and immediate incompatibility between Geneve and TI DSRs.)

[+mizapf]

Another suggestion, when you want to figure out what is happening, and you don't really want to spend hours on understanding assembly code: Activate the debug flags in the hdc92x4.cpp file in MAME and rebuild. This is as simple as it sounds, at least much simpler than going through assembly code. After doing this, check the log file.

 

For instance, when you add the flags LOG_SETREG and LOG_FORMAT in the hdc92x4.cpp file, you get this log output:

 

 

[:ioport:peb:slot8:hfdc:hdc9234] register[0] <- f0
[:ioport:peb:slot8:hfdc:hdc9234] register[1] <- f0
[:ioport:peb:slot8:hfdc:hdc9234] register[2] <- fd
[:ioport:peb:slot8:hfdc:hdc9234] register[3] <- ea
[:ioport:peb:slot8:hfdc:hdc9234] register[4] <- 00
[:ioport:peb:slot8:hfdc:hdc9234] register[5] <- f2
[:ioport:peb:slot8:hfdc:hdc9234] register[6] <- df
[:ioport:peb:slot8:hfdc:hdc9234] register[7] <- fd
[:ioport:peb:slot8:hfdc:hdc9234] register[8] <- e1
[:ioport:peb:slot8:hfdc:hdc9234] Setting interrupt trigger DONE=1 READY=0
[:ioport:peb:slot8:hfdc:hdc9234] FORMAT TRACK command 62, head = 0
...
[:ioport:peb:slot8:hfdc:hdc9234] register[0] <- f0
[:ioport:peb:slot8:hfdc:hdc9234] register[1] <- f0
[:ioport:peb:slot8:hfdc:hdc9234] register[2] <- fd
[:ioport:peb:slot8:hfdc:hdc9234] register[3] <- ea
[:ioport:peb:slot8:hfdc:hdc9234] register[4] <- 01
[:ioport:peb:slot8:hfdc:hdc9234] register[5] <- f2
[:ioport:peb:slot8:hfdc:hdc9234] register[6] <- df
[:ioport:peb:slot8:hfdc:hdc9234] register[7] <- fd
[:ioport:peb:slot8:hfdc:hdc9234] register[8] <- e1
[:ioport:peb:slot8:hfdc:hdc9234] Setting interrupt trigger DONE=1 READY=0
[:ioport:peb:slot8:hfdc:hdc9234] FORMAT TRACK command 62, head = 1
...
[:ioport:peb:slot8:hfdc:hdc9234] register[0] <- f0
[:ioport:peb:slot8:hfdc:hdc9234] register[1] <- f0
[:ioport:peb:slot8:hfdc:hdc9234] register[2] <- fd
[:ioport:peb:slot8:hfdc:hdc9234] register[3] <- ea
[:ioport:peb:slot8:hfdc:hdc9234] register[4] <- 00
[:ioport:peb:slot8:hfdc:hdc9234] register[5] <- f2
[:ioport:peb:slot8:hfdc:hdc9234] register[6] <- df
[:ioport:peb:slot8:hfdc:hdc9234] register[7] <- fd
[:ioport:peb:slot8:hfdc:hdc9234] register[8] <- e1
[:ioport:peb:slot8:hfdc:hdc9234] Setting interrupt trigger DONE=1 READY=0
[:ioport:peb:slot8:hfdc:hdc9234] FORMAT TRACK command 62, head = 0
...

[+9640News]

Are you aware of the two's complement that is used here? Have a look at the HDC9234 spec, page 14, right column at the top.

 

Nope, wasn't aware.

 

At the moment, I do not have MAME setup where I could do a build. Another day maybe...…..

 

Beery

[Rossman]

For quite some time I've been thinking about writing a tool that allows you to install and update MAME and all necessary files by a single click (where 0 < single < 10). The tool should offer a graphical user interface, and it should be platform-independent (i.e. running in Windows, MacOS, Linux). Maybe we could even do that together, that is, if some of you are interested.

 

What would be the preferred language for this?

 

- Java:

 

- Python:

 

- C++:

 

Something else?

 

 

I'd choose Python.

 

Versus Java: This utility will be, what, 5k? 10k, tops? So why require a 125mb JRE to run a 10k function? Sledgehammer, thumbtack.

 

Versus C++: Python code is easier for humans to read.

 

My two cents.

[Rossman]

• The HX5102 got its internal connector, which allows us to run two drives on the 99/8 (driven by the same controller in the HX5102).
• The HX5102 now properly recognizes two-sided disks; the track count (40/77) can be set by dip switches.

 

 

This MAME project is a fantastic feat of engineering. A lot of people in the community benefit from what you do, so thank you. Having 2 drives makes things infinitely easier: it very much appears that the engineers behind the p-system implementation on the TI assumed the user had at least 2 disk drives. That informed a lot of use cases, testing, etc. So thank you for figuring out two drives on the hexbus.

 

I was able to launch MAME, boot into the p-system, and run my little card game program. And, it works. But the p-code emulation appears to be slower on the 99/8 than it is on the 99/4A. I am not sure why. May be a setting on my configuration, may be the nature of the p-system architecture. I did try going into the set speed option, just to see if there was any difference, and there was none.

 

It may not be unreasonable to expect no better performance in Pascal on the 99/8 versus the 99/4A. As I understand it, booting into the p-system is effectively bypassing the TI CPU in favor of the p-system. If that is true, the faster 9995 would be of no benefit except for assembly language routines. I also haven't looked into the chipset supporting the p-system, but if it was only marginally different, and if it was the primary chipset, it probably wouldn't perform any differently.

 

That said, I am using the 99/4 Pascal diskettes (supporting version IV.0) as I don't have an image of the 99/8 disks (which support IV.12). Perhaps that makes a difference, perhaps not.

 

Again, this is not a complaint: the 99/8 emulation works in all its different forms, which is an amazing thing. And I am a user base of one (Pascal + 99/8 == very small community) so this is not a priority. But if it is reasonable to expect faster performance on the p-system on the 99/8, let me know if there are any configuration things I should investigate.

 

Best regards,

 

 

R.

[+retroclouds]

 

..

It may not be unreasonable to expect no better performance in Pascal on the 99/8 versus the 99/4A. As I understand it, booting into the p-system is effectively bypassing the TI CPU in favor of the p-system. If that is true, the faster 9995 would be of no benefit except for assembly language routines.

..

 

I was under the impression that the p-system is a pure software solution on hardware (peripheral card on the TI-99/4a, onboard on the TI-99/8), with the p-code (virtual) machine running on the TI CPU. Or am I missing something?

[+mizapf]

This MAME project is a fantastic feat of engineering. A lot of people in the community benefit from what you do, so thank you. Having 2 drives makes things infinitely easier: it very much appears that the engineers behind the p-system implementation on the TI assumed the user had at least 2 disk drives. That informed a lot of use cases, testing, etc. So thank you for figuring out two drives on the hexbus.

For some strange reason, I found myself starting to duck and cover.

 

But the p-code emulation appears to be slower on the 99/8 than it is on the 99/4A. I am not sure why.

First check: Add "-bench 20" in your command line and check whether you are above 100%. Try with and without the HX5102. If you are above, the perceived speed should be the real one.

 

Also, the 99/8 hosts an abundance of GROMs (22 altogether), and a lot of stuff is packed into these comparatively slow devices. That is, the execution speed is likely dominated by these devices, while the 9995 starts to get bored (likely, because I do not really know which parts are in the GROMs, and there is also a ROM).

 

We need a real 99/8 with Pascal to be sure, I am afraid.

 

Again, this is not a complaint [...]

 

<message rerouted by keyword>

 

Greetings citizen. The user feedback department is currently on vacation. This is a recorded message. If you want to talk to a real person, press "1".

 

[+mizapf]

Speaking of vacation, I'll be away from the keyboard for the next 12 days, going for a tour through Ireland. (After destinations like Laos/Cambodia, USA, Mongolia in the last years, I thought why not continue with European options again ... no 6h flight but 1.5h).

[Tursi]

 

I was under the impression that the p-system is a pure software solution on hardware (peripheral card on the TI-99/4a, onboard on the TI-99/8), with the p-code (virtual) machine running on the TI CPU. Or am I missing something?

 

It is. It's also running on "custom" GROMs -- the chips themselves are not unusual, but they are not on the normal GROM bus. They are instead memory mapped into the DSR space and clocked by a slightly slower GROM clock than the one in the console. In theory the 9995 could run it faster but only if the GROMs themselves are not the performance bottleneck (and I don't know if it is. If I were to bet, I'd expect better performance, but the thing with emulation is you only get the right answer by comparing to hardware, not to theory. )

 

Also, my understanding is the the 99/8 p-Code is built into the console. It seems likely there at least some differences compared to the p-Code card for the PEB.

[Rossman]

For some strange reason, I found myself starting to duck and cover.

 

 

 

Not at all. I'm just some goofball screwing around with the 99/8 p-system to re-work a software development project I first did in the early 1980s. What I am doing pales in comparison to the sophistication and complexity of emulating a machine that never made it out of the prototype phase. Any comments I have about things like "performance" have to be taken in this light. If I'm not sure why it is slow, I want you to know that I mean no disrespect, nor am I being critical of MAME.

 

I'll try the command line setting you suggested.

 

Enjoy your holiday. Years ago, I went on vacation to Ireland with my family while I was in the middle of a very stressful program rescue (the vacation was on the books before I was asked to take on the rescue). 48 hours in, we're at a national park that was a medieval walled village castle property somewhere outside of Galway, and it was among the most peaceful experiences I have ever had. Nobody there but my family and the person handling admission. Before the week was out, I realized that driving on rural Irish roads was more exciting than any video game I have ever played. It wasn't reckless or aggressive. It was just fun.

 

Best regards,

 

 

R.

[Rossman]

 

It is. It's also running on "custom" GROMs -- the chips themselves are not unusual, but they are not on the normal GROM bus. They are instead memory mapped into the DSR space and clocked by a slightly slower GROM clock than the one in the console. In theory the 9995 could run it faster but only if the GROMs themselves are not the performance bottleneck (and I don't know if it is. If I were to bet, I'd expect better performance, but the thing with emulation is you only get the right answer by comparing to hardware, not to theory. )

 

Also, my understanding is the the 99/8 p-Code is built into the console. It seems likely there at least some differences compared to the p-Code card for the PEB.

 

@tursi You wrote this infinitely more eloquently - not to mention accurately! - than I could have. This is how I understand it.

 

The p-system is a virtual machine from which things like the JVM are modeled. The JVM is a soft implementation while the p-system is a hard implementation, in that it is encoded onto ROMs. We take it for granted now, but RAM was expensive way back when.

[Rossman]

For some strange reason, I found myself starting to duck and cover.

 

First check: Add "-bench 20" in your command line and check whether you are above 100%. Try with and without the HX5102. If you are above, the perceived speed should be the real one.

 

Also, the 99/8 hosts an abundance of GROMs (22 altogether), and a lot of stuff is packed into these comparatively slow devices. That is, the execution speed is likely dominated by these devices, while the 9995 starts to get bored (likely, because I do not really know which parts are in the GROMs, and there is also a ROM).

 

We need a real 99/8 with Pascal to be sure, I am afraid.

 

 

 

I used the -bench 20 setting as you suggested. With the hx5102 the results were 51%, 54% and 55% on multiple runs. Without, they were 80%, 81% and 82%. So I'm nowhere close to 100%. I'll look at the MAME configuration options to figure out if I can allocate more resources to it while it is running.

[+mizapf]

Guys, I'm back, trying to catch up with all messages of the last 12 days..

 

 

I used the -bench 20 setting as you suggested. With the hx5102 the results were 51%, 54% and 55% on multiple runs. Without, they were 80%, 81% and 82%. So I'm nowhere close to 100%. I'll look at the MAME configuration options to figure out if I can allocate more resources to it while it is running.

 

This is way too slow. If you use the "bench" parameter, the screen output is inhibited, so that there is no cpu load from rendering. I'm afraid I cannot give you any recommendation in this case because the highest impact comes from rendering.

 

I wonder what machine you use to get such a bad bench value. Even my 2012 laptop with a Core i5 performs better.

[Rossman]

 

I wonder what machine you use to get such a bad bench value. Even my 2012 laptop with a Core i5 performs better.

 

It's an old HP laptop (vintage 2011) that I pulled out of the scratched-and-dented pile. It's not a development machine. One day a few years ago I found myself running Classic 99 and it just became one.

 

I'll give it a try on my work laptop (vintage 2017) to compare the numbers.

[+mizapf]

Most people probably never notice how much faster PCs have become during the last decade. Web surfing, chatting, checking E-mails are not really demanding applications. It needs tasks like image and video clip manipulation, entertainment (some people still call them "computer games"), simulations, emulations, and similar to really appreciate the power.

 

You will be surprised to see the effect.

[Tursi]

Most people probably never notice how much faster PCs have become during the last decade. Web surfing, chatting, checking E-mails are not really demanding applications. It needs tasks like image and video clip manipulation, entertainment (some people still call them "computer games"), simulations, emulations, and similar to really appreciate the power.

 

You will be surprised to see the effect.

 

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.