New MAME release

[RXB]

27 minutes ago, mizapf said:

To compare system speeds, I built MAME on my PC and on the Raspi4:

 

Full MAME build

Raspi4: 19099 sec

PC: 2463 sec

 

TI family-only build

Raspi4: 2129 sec

PC: 448 sec

 

(PC has a Core i7-6700K from 2016)

 

The full build time on the Raspi4 is still quite good, compared to earlier versions, where it took more than a day for building. Also, it seems as if more file operations have a worse impact on performance (PC with SSD, Raspi4 with microSD class 10).

Wonder how fast it would be on my AMD Ryzen 9 12-core Processor 3.79 Ghz that turbos up to 4.2 Ghrz?

I should get another M2 drive and put Mess on it using Unbuntu or Unix.

Would like a Hackntosh but upkeep on that is intensive.

[JamesD]

From the source code... it looks like someone else had the same issues I did with the HD6301 series microcontroller support.

Edited May 8, 2020 by JamesD

[+hloberg]

how do you attach a HD in the command line? what I previously had doesn't still work in v220.

[+mizapf]

You have to plug the HFDC into the PEB, and then specify that you want to connect a harddisk to connector h1.

mame ti99_4a -ioport peb -ioport:peb:slot8 hfdc -ioport:peb:slot8:hfdc:h1 generic -hard1 myharddisk.hd

 

If you use the Geneve, the "ioport" path elements must be removed (and -ioport peb).

Edited May 8, 2020 by mizapf

[+hloberg]

26 minutes ago, mizapf said:

You have to plug the HFDC into the PEB, and then specify that you want to connect a harddisk to connector h1.

mame ti99_4a -ioport peb -ioport:peb:slot8 hfdc -ioport:peb:slot8:hfdc:h1 generic -hard1 myharddisk.hd

 

If you use the Geneve, the "ioport" path elements must be removed (and -ioport peb).

works with TI99 but doesn't seem to work with the GENEVE. comes up with  Error: unknown option: -ioport:peb:slot8:hfdc:h1

 

edit: this, on the other hand, does work: genmod -window -skip_gameinfo -inipath ini\geneve -peb:slot4 speech -peb:slot6 tirs232 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 ..\software\disks\geneve\bootdisk3.hd

[+mizapf]

Did you read what I wrote under the code section?

 

Edit: geneve, genmod, and ti99_4p do not have an I/O port. Hence, there is no "ioport" in the command line. I once thought about removing the "peb" part for them as well, defining the Geneve (and the others) as being composed of the card and the PEB as a union, but this would have caused a lot of double implementation.

Edited May 8, 2020 by mizapf

[+hloberg]

12 minutes ago, mizapf said:

Did you read what I wrote under the code section?

on my todo list.

 

 

[+mizapf]

As you upgraded from 0.192, I recommend that you check the updates that happened in between: https://www.mizapf.de/en/ti99/mame/changes

 

For instance, the Geneve mouse must now be plugged into the colorbus ("-colorbus busmouse") if you intend to use it. I made it detachable so that MAME does not grab the mouse pointer when running in Windows.

[+hloberg]

I added the change log to my TI99RESOURCES so I remember to check it next time.

[+jedimatt42]

Thought I'd debug ForceCommand against a Horizon ramdisk, but on the way, I wanted to try out the myarcmem ramdisk cause I have a foundation card with the myarc rom... 

 

Anyway, I'm running into a really odd behavior... my cartridge doesn't show up in the TI menu, if myarcmem is enabled. It shows up if 32kmem or samsmem are there... 

I suspect, the myarcmem ROM's powerup routine attempts to smudge the cartridge RAM, to determine if the 128k OS ram cartridge is available or not.. so maybe my RPK layout.xml is not specifying read-only memory? 

 

<?xml version="1.0" encoding="utf-8"?>
<romset version="1.0">
   <resources>
      <rom id="romimage" file="FCMDC.bin"/>
   </resources>
   <configuration>
      <pcb type="paged377">
         <socket id="rom_socket" uses="romimage"/>
      </pcb>
   </configuration>
</romset>

Any ideas? looks very 'ROM'y to me...

 

My mame machine config as bash script:

 

#!/bin/bash

mame=/home/matthew/mame/mame64

$mame ti99_4a \
        -ka -nomax -window -resolution 840x648 \
        -ioport peb \
        -ioport:peb:slot7 myarcmem \
        -ioport:peb:slot8 hfdc \
        "$@"

exit $?

 

If I load an ssram based cartridge, the myarcmem does indeed initialize it to '128k O.S.' loader. --- so the machine config all seems correct... but I need a layout.xml that prevents this writing behavior for ForceCommand? 

 

[PeteE]

4 hours ago, jedimatt42 said:

Anyway, I'm running into a really odd behavior... my cartridge doesn't show up in the TI menu, if myarcmem is enabled. It shows up if 32kmem or samsmem are there... 

I suspect, the myarcmem ROM's powerup routine attempts to smudge the cartridge RAM, to determine if the 128k OS ram cartridge is available or not.. so maybe my RPK layout.xml is not specifying read-only memory?

 

Do you have the right cartridge pcb type?  My understanding is paged378 for normal banked roms and paged379 for inverted.  Does the cartridge have the startup header in every bank, so that it can start from any initial bank?

[+jedimatt42]

59 minutes ago, PeteE said:

Do you have the right cartridge pcb type?  My understanding is paged378 for normal banked roms and paged379 for inverted.  Does the cartridge have the startup header in every bank, so that it can start from any initial bank?

 

yep, I have the header in all the banks... and see the same behavior with the paged378...  I'll try and learn the mame debugger so I can verify if the header is being smudged out. 

[+mizapf]

Hmm, the MEXP-1 should not react to accesses in the cartridge space (6000-7fff). Can you send me your cartridge for testing?

[+jedimatt42]

7 hours ago, mizapf said:

Hmm, the MEXP-1 should not react to accesses in the cartridge space (6000-7fff). Can you send me your cartridge for testing?

In real life, and in MAME, the MEXP-1 DSR ROM Powerup routine writes to the cartridge space if it can and creates the menu item for loading Myarc Extended BASIC II. 

 

The one I'm having trouble with: FCMD.RPK(deleted)

 

Here is a ssram type module that shows what happens when RAM is in the cartridge slot: myxbii.rpk while a myarcmem expansion card is enabled.

 

If it was as simple as it writes all over the cart ROM, then I'd expect the 128K O.S. menu to show up.. but that isn't the case. My ROM just doesn't show up... 

Edited May 16, 2020 by jedimatt42
delete Force Command binary - keep it out of the wild if possible..

[+jedimatt42]

I believe what is happening is this:

  THe MExp-1 powerup copies a bunch of code to the 0x6000 address space.. it doesn't care if that succeeds or not.. not testing.. just does it. 

  That is trashing the bank switch latch, but not overwriting my rom... 

  However the bank selected when it is done is outside the range of my rom... 

 

There isn't a way to specify the ROM size for the pcb, when it is less than the max... so I suggest that I pad my ROM to the max size of the board.   I chose the board type vaguely... my rom is built for the final grom, it'll be 128k soon, but is only 64k presently... I'd expect it to work with the 378 or 377 type latch.   In real hardware from a rom board, if address lines are ignored, you get an implicit rolling effect. However also in real hardware you have to pad up to the capacity of the ROM used... 

 

So, seems like a docs issue... the paged377 docs say loosely that the it handles ROMs upto 2Meg... but there is no way to configure it for a smaller ROM size, so it seems the ROM must be precisely 2Meg.

 

 

[+jedimatt42]

redundant padding the ROM out to 2MEG fixes my issue.

 

So partial stack-overflow-style-up-vote goes to PeteE - for making me think about how the paging could be going wrong. Effectively, no I didn't have the header in all pages.. cause there were more pages than I provided.

 

Happy Saturday!

 

 

[globeron]

On 3/22/2020 at 7:10 AM, mizapf said:

Does that look promising?

 

I guess it won't make it into the next release, because we always have a freeze one week before last Wednesday, but it will very likely be in next month's release. Anyway, I still have to do tests and see whether everything runs well. But as you see, CALL PG is already working, the clock is there, so things look positive.

 

You may wonder why there are noticeably many new features in the TI emulation in MAME right now.

 

It does have to do with the Corona crisis. Our university has postponed all lectures by five weeks ... although I wonder whether we will really start on April 20. We have some concepts for preparing our lectures in digital form, but on the other hand, the university administration said we must not assume that all students have sufficient technical infrastructure at home, so all material that we upload now is understood to be consumed on a voluntary base, and must be repeated when the lectures actually start. Then we will have to work until mid-August (instead of mid-July).

 

I am far from complaining, though. I can't do much more but to wait, and I can't really do productive home office work. Maybe I'll start to work over my slides starting from next week, see how far I'll get. At least I don't get bored yet.

 

 

 

 

Hi @mizapf  is this already part of the latest MAME release, if so how do we start it and in which TI emulator?

 

 

[+mizapf]

We have some delays for the 0.221 release which was scheduled for end of April; should be coming in short term. It contains the PGRAM+ as well as the IDE adapter card.

[+mizapf]

0.221 has been published today. Since I already talked about it, no big surprises:

• IDE adapter card working; options for clock chip: RTC65271, BQ4842, BQ4852, BQ4847. Proved to work with Thierry's IDEAL (65271) and Fred's IDEDSR.
• PGRAM and PGRAM+ added. Proved to work with P-GRAM Utilities v2.3

You can find release 0.221 on WHTech.

 

/emulators/MAME/full/windows/

/emulators/MAME/ti99/linux/

/emulators/MAME/ti99/raspbian/

 

Windows: Run the downloaded archive exe file; don't get irritated by Microsoft Defender's warning (More options, run anyway.) Unpack into a folder like "C:\prg\mame". If you want to run my autoconfiguration script, you need to get and install Cygwin as well (www.cygwin.com). Activate unzip and wget in the Cygwin installer options. The autoconfigure script is named "mameprep_cygwin" and is also available on WHTech at the same location. Put it in your MAME installation folder, open a Cygwin shell, go to the MAME installation folder (cd /cygdrive/c/mame) and run "./mameprep_cygwin".

 

Raspbian/Linux: Unpack the tar.gz file in some folder, like ~/mame. It already contains the mameprep script. Go into the mame folder and run it by "./mameprep".

 

[+hloberg]

did you get the TI-99/8 disk issues working. I got it to read and write a disk fine for a while but then it corrupted. but I used TI-dir with the .dsk and I'm not sure if that was what corrupted the disk.

[+mizapf]

I remember that you reported issues for the 99/2, which were fixed since January:

 

I did not have problems with the Hexbus floppy on the 99/8 yet. Maybe you could try working with it and regularly create backups and do a file system check with TIImageTool.

[+hloberg]

3 hours ago, mizapf said:

I remember that you reported issues for the 99/2, which were fixed since January:

 

I did not have problems with the Hexbus floppy on the 99/8 yet. Maybe you could try working with it and regularly create backups and do a file system check with TIImageTool.

the ti99-8 didn't error out till I tried adding files using TI-Dir. but only after a few attempts. not right at 1st. I'll play around with it more & use TIImageTool instead.

ya, and the 99/2 still has 'issues'. but since it just has >4k not a lot can be done with it anyway. wish you could find the 16k module to emulate, if it exist.

[+hloberg]

on the 99/8 these type of files DO seem to work: TEST998.dsk 255k - which I think are PC99 files? I have wrote and read from this dsk several times without issue.

But using V9t9 320k files don't work? after about a dozen files on the disk the disk is no longer readable by the 99/8. PROJDSDD.dsk but are readable by TIImageTool & TiDir.

[+mizapf]

Take care - the HX5102 defines double density as 320K (16 sectors/track), not 360K as usual (18 sectors/track). You should not use double density between HX5102 and the other TI controllers.

 

You are safe with single density, though. (TEST998.dsk is a track dump, double sided, single density; PROJDSDD.dsk is DSDD.)

Edited May 22, 2020 by mizapf

[+mizapf]

2 hours ago, hloberg said:

ya, and the 99/2 still has 'issues'. but since it just has >4k not a lot can be done with it anyway. wish you could find the 16k module to emulate, if it exist.

 

I did not have any issues with the 99/2 last time. The issue was that no files longer than 1 sector could be read or written, but I solved that one. Please give me another error description so that I can check.

 

Maybe there is also a problem with double density? For all operation with the HX5102 (99/2 and 99/8), I recommend to use single density only, since the DD formats do not match with the 99/4A (and I cannot even guarantee that my TIImageTool would not break the disk format when you use it with the DD16 disks).